säuberung repo
This commit is contained in:
parent
93b9576bc6
commit
9788e273ed
80 changed files with 47758 additions and 48172 deletions
File diff suppressed because it is too large
Load diff
|
|
@ -1,403 +1,403 @@
|
|||
meta:
|
||||
typ: "review_framework"
|
||||
framework_name: "Demand-Portfolio Review"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen: true
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
kontext_tags:
|
||||
- "review"
|
||||
- "demand-portfolio"
|
||||
- "governance"
|
||||
- "kpi"
|
||||
- "kontinuierliche-verbesserung"
|
||||
- "quartalsweise"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND ZIELSETZUNG
|
||||
# ========================================
|
||||
|
||||
zweck_und_zielsetzung:
|
||||
kernaussage: >
|
||||
Das quartalsweise Demand-Portfolio Review dient der systematischen Analyse
|
||||
der Demand-Portfolio-Dynamik und der kontinuierlichen Verbesserung des
|
||||
Demand-Management-Prozesses. Es identifiziert Muster, bewertet die
|
||||
Systemgesundheit und leitet strategische Erkenntnisse für das Mission Board ab.
|
||||
|
||||
kernziele:
|
||||
- id: "KZ-1"
|
||||
name: "Mustererkennung"
|
||||
beschreibung: "Identifikation wiederkehrender Themen und Herausforderungen"
|
||||
|
||||
- id: "KZ-2"
|
||||
name: "Workflow-Optimierung"
|
||||
beschreibung: "Ableitung von Verbesserungspotenzialen"
|
||||
|
||||
- id: "KZ-3"
|
||||
name: "Strategische Rueckkopplung"
|
||||
beschreibung: "Erkenntnisse fuer uebergeordnete Steuerungsentscheidungen"
|
||||
|
||||
- id: "KZ-4"
|
||||
name: "Qualitaetssicherung"
|
||||
beschreibung: "Ueberpruefung der Governance-Effektivitaet"
|
||||
|
||||
# ========================================
|
||||
# 2. TEILNEHMER:INNEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
teilnehmer_verantwortlichkeiten:
|
||||
|
||||
rollen:
|
||||
- rolle_id: "al_planung"
|
||||
name: "AL Planung"
|
||||
funktion: "Leitung"
|
||||
verantwortung:
|
||||
- "Einberufung"
|
||||
- "Moderation"
|
||||
- "Ergebniskonsolidierung"
|
||||
- "MB-Berichterstattung"
|
||||
|
||||
- rolle_id: "dpm"
|
||||
name: "DPM"
|
||||
funktion: "Datenverantwortung"
|
||||
verantwortung:
|
||||
- "Datenaufbereitung"
|
||||
- "Portfolio-Analyse"
|
||||
- "Priorisierungs-Retrospektive"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
name: "PPM"
|
||||
funktion: "Projekt-Perspektive"
|
||||
verantwortung:
|
||||
- "Projekt-Pipeline-Analyse"
|
||||
- "Ressourcenauslastung"
|
||||
- "Umsetzungs-Feedback"
|
||||
|
||||
- rolle_id: "spm"
|
||||
name: "SPM"
|
||||
funktion: "Service-Perspektive"
|
||||
verantwortung:
|
||||
- "Service-Impact-Analyse"
|
||||
- "Betriebsbereitschaft"
|
||||
- "Transition-Erfahrungen"
|
||||
|
||||
- rolle_id: "shm"
|
||||
name: "SHM"
|
||||
funktion: "Stakeholder-Perspektive"
|
||||
verantwortung:
|
||||
- "Stakeholder-Trends"
|
||||
- "Bedarfsmuster"
|
||||
- "Kommunikations-Feedback"
|
||||
|
||||
# ========================================
|
||||
# 3. TURNUS UND ZEITPLANUNG
|
||||
# ========================================
|
||||
|
||||
turnus_zeitplanung:
|
||||
|
||||
regelmaessigkeit:
|
||||
frequenz: "quartalsweise"
|
||||
zeitpunkt: "erste Monatshaelfte nach Quartalsende"
|
||||
dauer: "3 Stunden (inkl. Pausen)"
|
||||
vorlaufzeit_unterlagen: "1 Woche vor Termin"
|
||||
|
||||
zeitlicher_ablauf:
|
||||
- zeitpunkt: "T-14 Tage"
|
||||
verantwortlich: "AL Planung"
|
||||
aktivitaeten:
|
||||
- "Prozess initiieren"
|
||||
- "Reminder verschicken"
|
||||
- "Datensammlung beginnen"
|
||||
|
||||
- zeitpunkt: "T-10 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Aktualisierung Portfolio-Uebersichten"
|
||||
|
||||
- zeitpunkt: "T-7 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Input zu Beobachtungen/Mustern an DPM"
|
||||
|
||||
- zeitpunkt: "T-3 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung Analysebericht (Draft) an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T-1 Tag"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Durchsicht der Unterlagen"
|
||||
|
||||
- zeitpunkt: "T-0 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Review-Durchfuehrung"
|
||||
|
||||
- zeitpunkt: "T+7 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung des Review-Berichts an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T+14 Tage"
|
||||
verantwortlich: "AL Planung / DPM"
|
||||
aktivitaeten:
|
||||
- "MB-Berichterstattung (Praesentation + Review-Bericht)"
|
||||
|
||||
# ========================================
|
||||
# 4. VORBEREITUNG
|
||||
# ========================================
|
||||
|
||||
vorbereitung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 DATENSAMMLUNG
|
||||
# ----------------------------------
|
||||
|
||||
datensammlung:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Aufbereitung der Demand-Portfolio-Daten anhand des Demand-KPI-Frameworks"
|
||||
referenz:
|
||||
dokument: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 VORANALYSE
|
||||
# ----------------------------------
|
||||
|
||||
voranalyse:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Strukturierte Voranalyse"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "VA-1"
|
||||
name: "KPI-Auswertung"
|
||||
inhalte:
|
||||
- "Aufbereitung aller KPIs gemaess Demand-KPI-Framework"
|
||||
- "Vergleich mit Vorquartal (Trends)"
|
||||
- "Identifikation von Ausreissern und Auffaelligkeiten"
|
||||
|
||||
- id: "VA-2"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Clustering der Demand-Themen"
|
||||
- "Analyse wiederkehrender Ablehnungsgruende"
|
||||
- "Identifikation systematischer Verzoegerungen"
|
||||
- "Stakeholder-Verhaltensmuster"
|
||||
|
||||
- id: "VA-3"
|
||||
name: "Deep-Dive Vorbereitung"
|
||||
inhalte:
|
||||
- "Liste lange liegender Demands mit Handlungsempfehlung"
|
||||
- "Analyse der Wiedervorlagen"
|
||||
- "Dokumentation kritischer Einzelfaelle"
|
||||
- "Prozess-Bottleneck-Analyse"
|
||||
|
||||
- id: "VA-4"
|
||||
name: "Optimierungs-Massnahmen-Review"
|
||||
inhalte:
|
||||
- "Status offener Optimierungsmassnahmen aus dem Massnahmenkatalog"
|
||||
- "Wirksamkeit umgesetzter Massnahmen"
|
||||
- "Neue Optimierungspotenziale"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 UNTERLAGENERSTELLUNG
|
||||
# ----------------------------------
|
||||
|
||||
unterlagenerstellung:
|
||||
versand: "T-3 Tage"
|
||||
name: "Review-Package"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "UP-1"
|
||||
name: "Management Summary"
|
||||
umfang: "1 Seite"
|
||||
inhalte:
|
||||
- "Quartals-Highlights"
|
||||
- "Kritische Entwicklungen"
|
||||
- "Top-3 Handlungsbedarfe"
|
||||
|
||||
- id: "UP-2"
|
||||
name: "KPI-Dashboard"
|
||||
inhalte:
|
||||
- "Alle Metriken mit Trend und Bewertung"
|
||||
- "Grafische Aufbereitung der Entwicklung"
|
||||
- "Kommentierung von Auffaelligkeiten"
|
||||
|
||||
- id: "UP-3"
|
||||
name: "Demand-Portfolio-Uebersicht"
|
||||
inhalte:
|
||||
- "Aktueller Bestand nach Status"
|
||||
- "Demand-Pipeline-Visualisierung"
|
||||
- "Thematische Verteilung"
|
||||
|
||||
- id: "UP-4"
|
||||
name: "Detailanalysen"
|
||||
inhalte:
|
||||
- "Durchlaufzeit-Analyse"
|
||||
- "Entscheidungsanalyse"
|
||||
- "Engpass-Dokumentation"
|
||||
|
||||
- id: "UP-5"
|
||||
name: "Anhaenge"
|
||||
inhalte:
|
||||
- "Standard-Agenda mit Zeitplan"
|
||||
- "Status Massnahmenkatalog"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATION UND BERICHTERSTATTUNG
|
||||
# ========================================
|
||||
|
||||
dokumentation_berichterstattung:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 REVIEW-ERGEBNISDOKUMENT
|
||||
# ----------------------------------
|
||||
|
||||
review_ergebnisdokument:
|
||||
name: "Review-Ergebnisbericht"
|
||||
|
||||
struktur:
|
||||
|
||||
- id: "EB-1"
|
||||
name: "Executive Summary"
|
||||
inhalte:
|
||||
- "Top-3-Erkenntnisse"
|
||||
- "Kritische Handlungsfelder"
|
||||
- "Empfohlene Sofortmassnahmen"
|
||||
|
||||
- id: "EB-2"
|
||||
name: "Portfolio-Performance"
|
||||
inhalte:
|
||||
- "KPIs mit Trend"
|
||||
- "Demand-Zusammensetzung"
|
||||
- "Durchlauf-Analyse"
|
||||
|
||||
- id: "EB-3"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Identifizierte Trends"
|
||||
- "Wiederkehrende Herausforderungen"
|
||||
- "Positive Entwicklungen"
|
||||
|
||||
- id: "EB-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
inhalte:
|
||||
- "Priorisierte Massnahmenliste"
|
||||
- "Verantwortlichkeiten und Zeitrahmen"
|
||||
- "Erwarteter Impact"
|
||||
|
||||
- id: "EB-5"
|
||||
name: "Anhang"
|
||||
inhalte:
|
||||
- "Detaildaten"
|
||||
- "Einzelfallanalysen"
|
||||
- "Prozessverbesserungsvorschlaege"
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 MISSION BOARD PRAESENTATION
|
||||
# ----------------------------------
|
||||
|
||||
mission_board_praesentation:
|
||||
format: "Informationspunkt in naechster MB-Sitzung"
|
||||
umfang: "10-15 Minuten Praesentation + Diskussion"
|
||||
|
||||
inhalt:
|
||||
- "Portfolio-Entwicklung im Ueberblick"
|
||||
- "Zentrale Erkenntnisse und Muster"
|
||||
- "Kritische Handlungsbedarfe"
|
||||
- "Empfehlungen fuer strategische Anpassungen"
|
||||
|
||||
# ========================================
|
||||
# 6. KONTINUIERLICHE VERBESSERUNG
|
||||
# ========================================
|
||||
|
||||
kontinuierliche_verbesserung:
|
||||
|
||||
optimierung_review_prozess:
|
||||
aktivitaeten:
|
||||
- "Jaehrliche Evaluation der Review-Methodik"
|
||||
- "Anpassung der KPIs"
|
||||
- "Integration neuer Analysedimensionen bei Bedarf"
|
||||
|
||||
lessons_learned_integration:
|
||||
aktivitaeten:
|
||||
- "Systematische Erfassung von Prozessverbesserungen"
|
||||
- "Best Practice Dokumentation"
|
||||
- "Wissenstransfer in die Organisation"
|
||||
|
||||
# ========================================
|
||||
# 7. WERKZEUGE UND VORLAGEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_vorlagen:
|
||||
|
||||
benoetigte_unterlagen:
|
||||
- id: "WV-1"
|
||||
name: "Demand-Portfolio-Export"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-2"
|
||||
name: "DSR-Protokolle des Quartals"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-3"
|
||||
name: "MB-Entscheidungsprotokolle"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-4"
|
||||
name: "Stakeholder-Feedback-Sammlung"
|
||||
status: "erforderlich"
|
||||
|
||||
# ========================================
|
||||
# 8. PILOTPHASE-SPEZIFIKA
|
||||
# ========================================
|
||||
|
||||
pilotphase_spezifika:
|
||||
|
||||
waehrend_pilotphase:
|
||||
charakteristiken:
|
||||
- aspekt: "Keine festen Benchmarks"
|
||||
beschreibung: "Sammlung von Baseline-Daten"
|
||||
|
||||
- aspekt: "Experimenteller Charakter"
|
||||
beschreibung: "Iterative Anpassung der Methodik"
|
||||
|
||||
- aspekt: "Fokus auf Lernen"
|
||||
beschreibung: "Identifikation sinnvoller KPIs"
|
||||
|
||||
- aspekt: "Dokumentation"
|
||||
beschreibung: "Besonders sorgfaeltige Erfassung fuer spaetere Evaluation"
|
||||
|
||||
nach_2_3_reviews:
|
||||
aktivitaeten:
|
||||
- "Definition realistischer Zielwerte"
|
||||
- "Festlegung kritischer Schwellenwerte"
|
||||
- "Standardisierung der Analysemethoden"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
|
||||
interne_dokumente:
|
||||
- titel: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
relevanz: "Grundlage fuer Datensammlung und KPI-Auswertung"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml"
|
||||
relevanz: "Uebergeordnetes Governance-Framework"
|
||||
|
||||
- titel: "DSR-Geschaeftsordnung"
|
||||
relevanz: "Operative Regelungen fuer DSR"
|
||||
|
||||
- titel: "Massnahmenkatalog"
|
||||
relevanz: "Tracking von Optimierungsmassnahmen"
|
||||
meta:
|
||||
typ: "review_framework"
|
||||
framework_name: "Demand-Portfolio Review"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen: true
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
kontext_tags:
|
||||
- "review"
|
||||
- "demand-portfolio"
|
||||
- "governance"
|
||||
- "kpi"
|
||||
- "kontinuierliche-verbesserung"
|
||||
- "quartalsweise"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND ZIELSETZUNG
|
||||
# ========================================
|
||||
|
||||
zweck_und_zielsetzung:
|
||||
kernaussage: >
|
||||
Das quartalsweise Demand-Portfolio Review dient der systematischen Analyse
|
||||
der Demand-Portfolio-Dynamik und der kontinuierlichen Verbesserung des
|
||||
Demand-Management-Prozesses. Es identifiziert Muster, bewertet die
|
||||
Systemgesundheit und leitet strategische Erkenntnisse für das Mission Board ab.
|
||||
|
||||
kernziele:
|
||||
- id: "KZ-1"
|
||||
name: "Mustererkennung"
|
||||
beschreibung: "Identifikation wiederkehrender Themen und Herausforderungen"
|
||||
|
||||
- id: "KZ-2"
|
||||
name: "Workflow-Optimierung"
|
||||
beschreibung: "Ableitung von Verbesserungspotenzialen"
|
||||
|
||||
- id: "KZ-3"
|
||||
name: "Strategische Rueckkopplung"
|
||||
beschreibung: "Erkenntnisse fuer uebergeordnete Steuerungsentscheidungen"
|
||||
|
||||
- id: "KZ-4"
|
||||
name: "Qualitaetssicherung"
|
||||
beschreibung: "Ueberpruefung der Governance-Effektivitaet"
|
||||
|
||||
# ========================================
|
||||
# 2. TEILNEHMER:INNEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
teilnehmer_verantwortlichkeiten:
|
||||
|
||||
rollen:
|
||||
- rolle_id: "al_planung"
|
||||
name: "AL Planung"
|
||||
funktion: "Leitung"
|
||||
verantwortung:
|
||||
- "Einberufung"
|
||||
- "Moderation"
|
||||
- "Ergebniskonsolidierung"
|
||||
- "MB-Berichterstattung"
|
||||
|
||||
- rolle_id: "dpm"
|
||||
name: "DPM"
|
||||
funktion: "Datenverantwortung"
|
||||
verantwortung:
|
||||
- "Datenaufbereitung"
|
||||
- "Portfolio-Analyse"
|
||||
- "Priorisierungs-Retrospektive"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
name: "PPM"
|
||||
funktion: "Projekt-Perspektive"
|
||||
verantwortung:
|
||||
- "Projekt-Pipeline-Analyse"
|
||||
- "Ressourcenauslastung"
|
||||
- "Umsetzungs-Feedback"
|
||||
|
||||
- rolle_id: "spm"
|
||||
name: "SPM"
|
||||
funktion: "Service-Perspektive"
|
||||
verantwortung:
|
||||
- "Service-Impact-Analyse"
|
||||
- "Betriebsbereitschaft"
|
||||
- "Transition-Erfahrungen"
|
||||
|
||||
- rolle_id: "shm"
|
||||
name: "SHM"
|
||||
funktion: "Stakeholder-Perspektive"
|
||||
verantwortung:
|
||||
- "Stakeholder-Trends"
|
||||
- "Bedarfsmuster"
|
||||
- "Kommunikations-Feedback"
|
||||
|
||||
# ========================================
|
||||
# 3. TURNUS UND ZEITPLANUNG
|
||||
# ========================================
|
||||
|
||||
turnus_zeitplanung:
|
||||
|
||||
regelmaessigkeit:
|
||||
frequenz: "quartalsweise"
|
||||
zeitpunkt: "erste Monatshaelfte nach Quartalsende"
|
||||
dauer: "3 Stunden (inkl. Pausen)"
|
||||
vorlaufzeit_unterlagen: "1 Woche vor Termin"
|
||||
|
||||
zeitlicher_ablauf:
|
||||
- zeitpunkt: "T-14 Tage"
|
||||
verantwortlich: "AL Planung"
|
||||
aktivitaeten:
|
||||
- "Prozess initiieren"
|
||||
- "Reminder verschicken"
|
||||
- "Datensammlung beginnen"
|
||||
|
||||
- zeitpunkt: "T-10 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Aktualisierung Portfolio-Uebersichten"
|
||||
|
||||
- zeitpunkt: "T-7 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Input zu Beobachtungen/Mustern an DPM"
|
||||
|
||||
- zeitpunkt: "T-3 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung Analysebericht (Draft) an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T-1 Tag"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Durchsicht der Unterlagen"
|
||||
|
||||
- zeitpunkt: "T-0 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Review-Durchfuehrung"
|
||||
|
||||
- zeitpunkt: "T+7 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung des Review-Berichts an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T+14 Tage"
|
||||
verantwortlich: "AL Planung / DPM"
|
||||
aktivitaeten:
|
||||
- "MB-Berichterstattung (Praesentation + Review-Bericht)"
|
||||
|
||||
# ========================================
|
||||
# 4. VORBEREITUNG
|
||||
# ========================================
|
||||
|
||||
vorbereitung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 DATENSAMMLUNG
|
||||
# ----------------------------------
|
||||
|
||||
datensammlung:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Aufbereitung der Demand-Portfolio-Daten anhand des Demand-KPI-Frameworks"
|
||||
referenz:
|
||||
dokument: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 VORANALYSE
|
||||
# ----------------------------------
|
||||
|
||||
voranalyse:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Strukturierte Voranalyse"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "VA-1"
|
||||
name: "KPI-Auswertung"
|
||||
inhalte:
|
||||
- "Aufbereitung aller KPIs gemaess Demand-KPI-Framework"
|
||||
- "Vergleich mit Vorquartal (Trends)"
|
||||
- "Identifikation von Ausreissern und Auffaelligkeiten"
|
||||
|
||||
- id: "VA-2"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Clustering der Demand-Themen"
|
||||
- "Analyse wiederkehrender Ablehnungsgruende"
|
||||
- "Identifikation systematischer Verzoegerungen"
|
||||
- "Stakeholder-Verhaltensmuster"
|
||||
|
||||
- id: "VA-3"
|
||||
name: "Deep-Dive Vorbereitung"
|
||||
inhalte:
|
||||
- "Liste lange liegender Demands mit Handlungsempfehlung"
|
||||
- "Analyse der Wiedervorlagen"
|
||||
- "Dokumentation kritischer Einzelfaelle"
|
||||
- "Prozess-Bottleneck-Analyse"
|
||||
|
||||
- id: "VA-4"
|
||||
name: "Optimierungs-Massnahmen-Review"
|
||||
inhalte:
|
||||
- "Status offener Optimierungsmassnahmen aus dem Massnahmenkatalog"
|
||||
- "Wirksamkeit umgesetzter Massnahmen"
|
||||
- "Neue Optimierungspotenziale"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 UNTERLAGENERSTELLUNG
|
||||
# ----------------------------------
|
||||
|
||||
unterlagenerstellung:
|
||||
versand: "T-3 Tage"
|
||||
name: "Review-Package"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "UP-1"
|
||||
name: "Management Summary"
|
||||
umfang: "1 Seite"
|
||||
inhalte:
|
||||
- "Quartals-Highlights"
|
||||
- "Kritische Entwicklungen"
|
||||
- "Top-3 Handlungsbedarfe"
|
||||
|
||||
- id: "UP-2"
|
||||
name: "KPI-Dashboard"
|
||||
inhalte:
|
||||
- "Alle Metriken mit Trend und Bewertung"
|
||||
- "Grafische Aufbereitung der Entwicklung"
|
||||
- "Kommentierung von Auffaelligkeiten"
|
||||
|
||||
- id: "UP-3"
|
||||
name: "Demand-Portfolio-Uebersicht"
|
||||
inhalte:
|
||||
- "Aktueller Bestand nach Status"
|
||||
- "Demand-Pipeline-Visualisierung"
|
||||
- "Thematische Verteilung"
|
||||
|
||||
- id: "UP-4"
|
||||
name: "Detailanalysen"
|
||||
inhalte:
|
||||
- "Durchlaufzeit-Analyse"
|
||||
- "Entscheidungsanalyse"
|
||||
- "Engpass-Dokumentation"
|
||||
|
||||
- id: "UP-5"
|
||||
name: "Anhaenge"
|
||||
inhalte:
|
||||
- "Standard-Agenda mit Zeitplan"
|
||||
- "Status Massnahmenkatalog"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATION UND BERICHTERSTATTUNG
|
||||
# ========================================
|
||||
|
||||
dokumentation_berichterstattung:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 REVIEW-ERGEBNISDOKUMENT
|
||||
# ----------------------------------
|
||||
|
||||
review_ergebnisdokument:
|
||||
name: "Review-Ergebnisbericht"
|
||||
|
||||
struktur:
|
||||
|
||||
- id: "EB-1"
|
||||
name: "Executive Summary"
|
||||
inhalte:
|
||||
- "Top-3-Erkenntnisse"
|
||||
- "Kritische Handlungsfelder"
|
||||
- "Empfohlene Sofortmassnahmen"
|
||||
|
||||
- id: "EB-2"
|
||||
name: "Portfolio-Performance"
|
||||
inhalte:
|
||||
- "KPIs mit Trend"
|
||||
- "Demand-Zusammensetzung"
|
||||
- "Durchlauf-Analyse"
|
||||
|
||||
- id: "EB-3"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Identifizierte Trends"
|
||||
- "Wiederkehrende Herausforderungen"
|
||||
- "Positive Entwicklungen"
|
||||
|
||||
- id: "EB-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
inhalte:
|
||||
- "Priorisierte Massnahmenliste"
|
||||
- "Verantwortlichkeiten und Zeitrahmen"
|
||||
- "Erwarteter Impact"
|
||||
|
||||
- id: "EB-5"
|
||||
name: "Anhang"
|
||||
inhalte:
|
||||
- "Detaildaten"
|
||||
- "Einzelfallanalysen"
|
||||
- "Prozessverbesserungsvorschlaege"
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 MISSION BOARD PRAESENTATION
|
||||
# ----------------------------------
|
||||
|
||||
mission_board_praesentation:
|
||||
format: "Informationspunkt in naechster MB-Sitzung"
|
||||
umfang: "10-15 Minuten Praesentation + Diskussion"
|
||||
|
||||
inhalt:
|
||||
- "Portfolio-Entwicklung im Ueberblick"
|
||||
- "Zentrale Erkenntnisse und Muster"
|
||||
- "Kritische Handlungsbedarfe"
|
||||
- "Empfehlungen fuer strategische Anpassungen"
|
||||
|
||||
# ========================================
|
||||
# 6. KONTINUIERLICHE VERBESSERUNG
|
||||
# ========================================
|
||||
|
||||
kontinuierliche_verbesserung:
|
||||
|
||||
optimierung_review_prozess:
|
||||
aktivitaeten:
|
||||
- "Jaehrliche Evaluation der Review-Methodik"
|
||||
- "Anpassung der KPIs"
|
||||
- "Integration neuer Analysedimensionen bei Bedarf"
|
||||
|
||||
lessons_learned_integration:
|
||||
aktivitaeten:
|
||||
- "Systematische Erfassung von Prozessverbesserungen"
|
||||
- "Best Practice Dokumentation"
|
||||
- "Wissenstransfer in die Organisation"
|
||||
|
||||
# ========================================
|
||||
# 7. WERKZEUGE UND VORLAGEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_vorlagen:
|
||||
|
||||
benoetigte_unterlagen:
|
||||
- id: "WV-1"
|
||||
name: "Demand-Portfolio-Export"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-2"
|
||||
name: "DSR-Protokolle des Quartals"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-3"
|
||||
name: "MB-Entscheidungsprotokolle"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-4"
|
||||
name: "Stakeholder-Feedback-Sammlung"
|
||||
status: "erforderlich"
|
||||
|
||||
# ========================================
|
||||
# 8. PILOTPHASE-SPEZIFIKA
|
||||
# ========================================
|
||||
|
||||
pilotphase_spezifika:
|
||||
|
||||
waehrend_pilotphase:
|
||||
charakteristiken:
|
||||
- aspekt: "Keine festen Benchmarks"
|
||||
beschreibung: "Sammlung von Baseline-Daten"
|
||||
|
||||
- aspekt: "Experimenteller Charakter"
|
||||
beschreibung: "Iterative Anpassung der Methodik"
|
||||
|
||||
- aspekt: "Fokus auf Lernen"
|
||||
beschreibung: "Identifikation sinnvoller KPIs"
|
||||
|
||||
- aspekt: "Dokumentation"
|
||||
beschreibung: "Besonders sorgfaeltige Erfassung fuer spaetere Evaluation"
|
||||
|
||||
nach_2_3_reviews:
|
||||
aktivitaeten:
|
||||
- "Definition realistischer Zielwerte"
|
||||
- "Festlegung kritischer Schwellenwerte"
|
||||
- "Standardisierung der Analysemethoden"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
|
||||
interne_dokumente:
|
||||
- titel: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
relevanz: "Grundlage fuer Datensammlung und KPI-Auswertung"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml"
|
||||
relevanz: "Uebergeordnetes Governance-Framework"
|
||||
|
||||
- titel: "DSR-Geschaeftsordnung"
|
||||
relevanz: "Operative Regelungen fuer DSR"
|
||||
|
||||
- titel: "Massnahmenkatalog"
|
||||
relevanz: "Tracking von Optimierungsmassnahmen"
|
||||
|
|
|
|||
|
|
@ -1,490 +1,490 @@
|
|||
meta:
|
||||
typ: "governance_framework"
|
||||
framework_name: "Demand-Portfolio Governance"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "governance"
|
||||
- "demand-portfolio"
|
||||
- "steuerung"
|
||||
- "entscheidungsarchitektur"
|
||||
- "portfolio-management"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck_und_geltungsbereich:
|
||||
zweck:
|
||||
kernaussage: "Orchestriert den Fluss von Bedarfen durch die DIGIT-Organisation"
|
||||
|
||||
fluss:
|
||||
start: "Erste Erfassung eines Stakeholder-Wunsches"
|
||||
ende: "Integration als laufender Service"
|
||||
|
||||
ergaenzung_zu: "DSR-Geschäftsordnung"
|
||||
ergaenzungs_perspektive: "Übergreifende Steuerungsperspektive"
|
||||
|
||||
zentrale_klaerungen:
|
||||
- thema: "Rolle des Demand-Portfolio-Managements"
|
||||
klarstellung: "Zentrale Priorisierungsinstanz"
|
||||
|
||||
- thema: "Portfolio-Überwachung"
|
||||
klarstellung: "Mechanismen zur Portfolio-Überwachung definiert"
|
||||
|
||||
verweis_portfolio_kontext:
|
||||
dokument: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
inhalt: "Details zu den drei Portfolios und Kernprozessen (Demand-Lifecycle (Change) & Service-Lifecycle (Run))"
|
||||
|
||||
# ========================================
|
||||
# 2. GOVERNANCE-ARCHITEKTUR
|
||||
# ========================================
|
||||
|
||||
governance_architektur:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 ENTSCHEIDUNGSEBENEN
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungsebenen:
|
||||
beschreibung: "DIGITOM definiert vier Entscheidungsinstanzen mit unterschiedlichen Kompetenzen"
|
||||
anzahl: 4
|
||||
|
||||
ebenen:
|
||||
- ebene_id: "vision_board"
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Verantwortet das Operating Model"
|
||||
- "Setzt strategische Leitplanken für die Digitalisierung"
|
||||
|
||||
entscheidungen:
|
||||
- "Grundlegende Governance-Änderungen"
|
||||
- "Investitionsschwerpunkte"
|
||||
|
||||
hierarchie_stufe: 4
|
||||
|
||||
- ebene_id: "mission_board"
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch-strategisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "MB-Demands"
|
||||
beispiele: ["transformative Anforderungen", "hochkomplexe Anforderungen"]
|
||||
- typ: "Gesamtressourcenallokation"
|
||||
beschreibung: "Steuert die Gesamtressourcenallokation"
|
||||
- typ: "Konfliktlösung"
|
||||
beschreibung: "Löst Konflikte zwischen Abteilungen"
|
||||
|
||||
informations_input:
|
||||
- quelle: "quartals_portfolio_reviews"
|
||||
frequenz: "quartalsweise"
|
||||
von: "abteilungsleitung_planung"
|
||||
|
||||
hierarchie_stufe: 3
|
||||
|
||||
- ebene_id: "abteilungsleitung_planung"
|
||||
name: "Abteilungsleitung Planung"
|
||||
kurzform: "AL-P"
|
||||
ebene: "taktisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Quartalsweise Portfolio-Reviews"
|
||||
- "Disziplinarische Führung des DPM"
|
||||
|
||||
funktion: "Brücke zwischen operativer Portfolio-Steuerung und taktischer Entscheidungsebene"
|
||||
|
||||
aufgaben:
|
||||
- "Portfolio-Muster und -Trends analysieren"
|
||||
- "Erkenntnisse ableiten"
|
||||
- "Berichten ans Mission Board"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei strategischer Relevanz"
|
||||
an: "vision_board"
|
||||
|
||||
hierarchie_stufe: 2
|
||||
|
||||
- ebene_id: "dsr"
|
||||
name: "Demand & Stakeholder Runde"
|
||||
kurzform: "DSR"
|
||||
ebene: "operativ-taktisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
delegation:
|
||||
kann_delegieren_an: "mission_board"
|
||||
bedingung: "bei entsprechendem Klassifizierungsmuster"
|
||||
|
||||
hierarchie_stufe: 1
|
||||
|
||||
referenz:
|
||||
dokument: "dsr-geschaeftsordnung.yaml"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
|
||||
- ebene_id: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
kurzform: "DPM"
|
||||
ebene: "operativ"
|
||||
typ: "fachrolle"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Klassifizierung aller Demands im Portfolio"
|
||||
- "Analyse aller Demands im Portfolio"
|
||||
- "Bewertung aller Demands im Portfolio"
|
||||
- "Priorisierung aller Demands im Portfolio"
|
||||
|
||||
output: "Entscheidungsvorlage für jeweiliges Entscheidungsgremium"
|
||||
|
||||
governance_prinzip:
|
||||
trennung: "Entscheidungsgremium ≠ DPM"
|
||||
|
||||
sicherstellung:
|
||||
- aspekt: "Fachlich-objektive Arbeit"
|
||||
durch: "dpm"
|
||||
umfasst: ["Klassifizierung", "Analyse", "Bewertung", "Priorisierung"]
|
||||
|
||||
- aspekt: "Multiperspektivische Freigabe"
|
||||
durch: ["dsr", "mission_board"]
|
||||
umfasst: "Finale Entscheidung unter Berücksichtigung aller Perspektiven"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
- abschnitt: "Schnittstellen und Verantwortlichkeiten"
|
||||
siehe: "Abschnitt 5 in diesem Dokument"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 ENTSCHEIDUNGS-ROUTING
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungs_routing:
|
||||
beschreibung: "Systematische Zuordnung von Demands zu Entscheidungsebenen"
|
||||
|
||||
basis: "Klassifizierungslogik auf vier Dimensionen"
|
||||
|
||||
dimensionen:
|
||||
- id: "treiber"
|
||||
name: "Treiber"
|
||||
bedeutung: "Impulsquelle"
|
||||
|
||||
- id: "tragweite"
|
||||
name: "Tragweite"
|
||||
bedeutung: "Veränderungstiefe"
|
||||
|
||||
- id: "systemebene"
|
||||
name: "Systemebene"
|
||||
bedeutung: "Technisch-fachliche Verortung"
|
||||
|
||||
- id: "komplexitaet"
|
||||
name: "Komplexität"
|
||||
bedeutung: "Lösungsunsicherheit"
|
||||
|
||||
routing_optionen:
|
||||
- ziel: "mission_board"
|
||||
beschreibung: "Direkt an Mission Board"
|
||||
trigger: ["hochkomplex", "transformativ"]
|
||||
|
||||
- ziel: "dsr_mit_delegationsoption"
|
||||
beschreibung: "An DSR mit Option zur Delegation ans Mission Board"
|
||||
trigger: "entsprechendes Klassifizierungsmuster"
|
||||
|
||||
- ziel: "dsr"
|
||||
beschreibung: "An DSR ohne Delegationsoption"
|
||||
trigger: "inkrementelle Themen"
|
||||
|
||||
prinzip: |
|
||||
Entscheidungen werden auf der zuständigen Organisationsebene getroffen:
|
||||
- Hochkomplexe und transformative Demands → Mission Board
|
||||
- Inkrementelle Themen → Demand & Stakeholder-Runde
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Klassifizierung"
|
||||
abschnitt: "3.2 Routing-Logik: Die Klassifizierung bestimmt die Entscheidungsebene"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 3. DEMAND-PORTFOLIO-STEUERUNG UND REVIEWS
|
||||
# ========================================
|
||||
|
||||
portfolio_steuerung:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 STEUERUNGSEBENE DSR
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_dsr:
|
||||
ebene: "Demand & Stakeholder-Runde"
|
||||
|
||||
aufgaben:
|
||||
- id: "DSR-E1"
|
||||
name: "Entscheidung über DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
- id: "DSR-E2"
|
||||
name: "Delegations-Entscheidung"
|
||||
beschreibung: "Entscheidung über Delegation von Demands ans Mission Board"
|
||||
|
||||
- id: "DSR-I1"
|
||||
name: "Feedback-Aufnahme"
|
||||
beschreibung: "Aufnahme von Feedback zu laufenden Umsetzungen"
|
||||
|
||||
- id: "DSR-P1"
|
||||
name: "Problemklärung"
|
||||
beschreibung: "Klärung akuter Problemstellungen"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 STEUERUNGSEBENE MISSION BOARD
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_mission_board:
|
||||
ebene: "Mission Board"
|
||||
|
||||
aufgaben:
|
||||
- id: "MB-E1"
|
||||
name: "Freigabe von MB-Demands"
|
||||
beschreibung: "Entscheidung über hochkomplexe und transformative Demands"
|
||||
|
||||
- id: "MB-K1"
|
||||
name: "Ressourcenkonflikte lösen"
|
||||
beschreibung: "Auflösung von Ressourcenkonflikten zwischen Abteilungen"
|
||||
|
||||
- id: "MB-S1"
|
||||
name: "Gesamtportfolio steuern"
|
||||
beschreibung: "Steuerung des Gesamtportfolios aus Demands und Projekten"
|
||||
|
||||
referenz:
|
||||
dokument: "Geschäftsordnung des Mission Boards"
|
||||
hinweis: "Detaillierte Arbeitsweise"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 PORTFOLIO-REVIEWS (QUARTALSWEISE)
|
||||
# ----------------------------------
|
||||
|
||||
quartals_portfolio_reviews:
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "abteilungsleitung_planung"
|
||||
|
||||
teilnehmende:
|
||||
- "dpm"
|
||||
- "ppm"
|
||||
- "spm"
|
||||
- "shm"
|
||||
|
||||
berichterstattung:
|
||||
an: "mission_board"
|
||||
form: "Informationspunkt in der nächsten Sitzung"
|
||||
|
||||
zweck:
|
||||
hauptzweck: "Systematische Analyse der Portfolio-Dynamik"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit anhand KPIs bewerten"
|
||||
- "Verbesserungspotenziale ableiten"
|
||||
|
||||
nutzung_durch_al_p:
|
||||
zweck: "Abteilungsleitung Planung nutzt Erkenntnisse für"
|
||||
|
||||
nutzungen:
|
||||
- "Trends und wiederkehrende Herausforderungen erkennen"
|
||||
- "Effektivität der Governance bewerten"
|
||||
- "Anpassungsbedarfe identifizieren"
|
||||
- "Empfehlungen für Mission Board formulieren"
|
||||
|
||||
kern_inhalte:
|
||||
- id: "REV-1"
|
||||
name: "Portfolio-Überblick"
|
||||
aspekte: ["Volumen", "Durchsatz", "Themencluster"]
|
||||
|
||||
- id: "REV-2"
|
||||
name: "KPI-Analyse"
|
||||
beschreibung: "Analyse der definierten KPIs"
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Musteranalyse"
|
||||
aspekte: ["Engpässe", "Ablehnungsgründe", "Verzögerungen"]
|
||||
|
||||
- id: "REV-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
beschreibung: "Ableitung von Handlungsempfehlungen"
|
||||
|
||||
charakter:
|
||||
output_typ: "strategische Erkenntnisse"
|
||||
nicht: "operative Entscheidungen"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei Bedarf für kritische Themen"
|
||||
pfad: "Mission Board → Vision Board"
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Detaillierte Agenda, Analysevorlagen und Durchführungshinweise"
|
||||
|
||||
# ========================================
|
||||
# 4. DEMAND-PORTFOLIO KPIs
|
||||
# ========================================
|
||||
|
||||
demand_portfolio_kpis:
|
||||
zweck: "Systematische Analyse der Demand-Portfolio-Dynamik und kontinuierliche Verbesserung"
|
||||
|
||||
verwendung:
|
||||
kontext: "Quartalsweises Demand-Portfolio Review"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit bewerten"
|
||||
- "Strategische Erkenntnisse für Mission Board ableiten"
|
||||
|
||||
entwicklungsansatz:
|
||||
phase: "pilotphase"
|
||||
vorgehen: "Erste KPIs werden als Benchmarks erhoben und sukzessive weiterentwickelt"
|
||||
|
||||
referenzen:
|
||||
- dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Definition und Erhebungsmethodik"
|
||||
|
||||
- dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# 5. SCHNITTSTELLEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen_verantwortlichkeiten:
|
||||
|
||||
rollenmatrix:
|
||||
beschreibung: "DIGITOM nutzt ein differenziertes RACI-Modell mit unterschiedlichen Verantwortungslogiken"
|
||||
|
||||
referenz:
|
||||
dokument: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
|
||||
informationsfluesse:
|
||||
beschreibung: "Governance basiert auf definierten Informationsflüssen"
|
||||
|
||||
fluesse:
|
||||
- richtung: "bottom_up"
|
||||
name: "Bottom-up"
|
||||
beschreibung: "Demands fließen von Stakeholdern über SHM und DPM in die Entscheidungsgremien"
|
||||
pfad: "Stakeholder → SHM → DPM → DSR/MB"
|
||||
|
||||
- richtung: "top_down"
|
||||
name: "Top-down"
|
||||
beschreibung: "Strategische Vorgaben fließen vom Vision Board über Mission Board zur operativen Umsetzung"
|
||||
pfad: "Vision Board → Mission Board → operative Umsetzung"
|
||||
|
||||
- richtung: "horizontal"
|
||||
name: "Horizontal"
|
||||
beschreibung: "Abstimmung zwischen DPM, PPM und SPM zur Portfolio-Synchronisation"
|
||||
zwischen: ["dpm", "ppm", "spm"]
|
||||
zweck: "Portfolio-Synchronisation"
|
||||
|
||||
# ========================================
|
||||
# 6. PILOT-EVALUATION
|
||||
# ========================================
|
||||
|
||||
pilot_evaluation:
|
||||
zeitpunkt: "nach Pilotbetrieb"
|
||||
|
||||
status:
|
||||
evaluationskriterien: "in Erarbeitung"
|
||||
dokumentation: "separat"
|
||||
|
||||
referenz:
|
||||
dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# SYSTEMISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
systemische_einordnung:
|
||||
framework_charakter:
|
||||
typ: "übergeordnetes Governance-Framework"
|
||||
funktion: "Orchestrierung"
|
||||
scope: "Ende-zu-Ende (Stakeholder-Wunsch bis laufender Service)"
|
||||
|
||||
beziehung_zu_anderen_dokumenten:
|
||||
ergaenzt:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
art: "operative Regelungen"
|
||||
ergaenzung: "um übergreifende Steuerungsperspektive"
|
||||
|
||||
definiert_kontext_fuer:
|
||||
- dokument: "Demand-Klassifizierung"
|
||||
aspekt: "Routing-Logik erhält Governance-Kontext"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
aspekt: "Verantwortlichkeiten in Governance-Architektur eingebettet"
|
||||
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
aspekt: "Rolle in Governance-System verortet"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
governance_dokumente:
|
||||
- titel: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Operative Regelungen für DSR"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten"
|
||||
|
||||
methodische_dokumente:
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Routing-Logik und Klassifizierungskriterien"
|
||||
|
||||
- titel: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
relevanz: "KPIs und Review-Prozess"
|
||||
|
||||
prozess_dokumente:
|
||||
- titel: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
relevanz: "Operativer Ablauf DSR"
|
||||
|
||||
rollen_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Zentrale Rolle im Governance-System"
|
||||
|
||||
externe_referenzen:
|
||||
- titel: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
beschreibung: "Details zu drei Portfolios und Kernprozessen"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Geschäftsordnung Mission Board"
|
||||
beschreibung: "Detaillierte Arbeitsweise des Mission Board"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
meta:
|
||||
typ: "governance_framework"
|
||||
framework_name: "Demand-Portfolio Governance"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "governance"
|
||||
- "demand-portfolio"
|
||||
- "steuerung"
|
||||
- "entscheidungsarchitektur"
|
||||
- "portfolio-management"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck_und_geltungsbereich:
|
||||
zweck:
|
||||
kernaussage: "Orchestriert den Fluss von Bedarfen durch die DIGIT-Organisation"
|
||||
|
||||
fluss:
|
||||
start: "Erste Erfassung eines Stakeholder-Wunsches"
|
||||
ende: "Integration als laufender Service"
|
||||
|
||||
ergaenzung_zu: "DSR-Geschäftsordnung"
|
||||
ergaenzungs_perspektive: "Übergreifende Steuerungsperspektive"
|
||||
|
||||
zentrale_klaerungen:
|
||||
- thema: "Rolle des Demand-Portfolio-Managements"
|
||||
klarstellung: "Zentrale Priorisierungsinstanz"
|
||||
|
||||
- thema: "Portfolio-Überwachung"
|
||||
klarstellung: "Mechanismen zur Portfolio-Überwachung definiert"
|
||||
|
||||
verweis_portfolio_kontext:
|
||||
dokument: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
inhalt: "Details zu den drei Portfolios und Kernprozessen (Demand-Lifecycle (Change) & Service-Lifecycle (Run))"
|
||||
|
||||
# ========================================
|
||||
# 2. GOVERNANCE-ARCHITEKTUR
|
||||
# ========================================
|
||||
|
||||
governance_architektur:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 ENTSCHEIDUNGSEBENEN
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungsebenen:
|
||||
beschreibung: "DIGITOM definiert vier Entscheidungsinstanzen mit unterschiedlichen Kompetenzen"
|
||||
anzahl: 4
|
||||
|
||||
ebenen:
|
||||
- ebene_id: "vision_board"
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Verantwortet das Operating Model"
|
||||
- "Setzt strategische Leitplanken für die Digitalisierung"
|
||||
|
||||
entscheidungen:
|
||||
- "Grundlegende Governance-Änderungen"
|
||||
- "Investitionsschwerpunkte"
|
||||
|
||||
hierarchie_stufe: 4
|
||||
|
||||
- ebene_id: "mission_board"
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch-strategisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "MB-Demands"
|
||||
beispiele: ["transformative Anforderungen", "hochkomplexe Anforderungen"]
|
||||
- typ: "Gesamtressourcenallokation"
|
||||
beschreibung: "Steuert die Gesamtressourcenallokation"
|
||||
- typ: "Konfliktlösung"
|
||||
beschreibung: "Löst Konflikte zwischen Abteilungen"
|
||||
|
||||
informations_input:
|
||||
- quelle: "quartals_portfolio_reviews"
|
||||
frequenz: "quartalsweise"
|
||||
von: "abteilungsleitung_planung"
|
||||
|
||||
hierarchie_stufe: 3
|
||||
|
||||
- ebene_id: "abteilungsleitung_planung"
|
||||
name: "Abteilungsleitung Planung"
|
||||
kurzform: "AL-P"
|
||||
ebene: "taktisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Quartalsweise Portfolio-Reviews"
|
||||
- "Disziplinarische Führung des DPM"
|
||||
|
||||
funktion: "Brücke zwischen operativer Portfolio-Steuerung und taktischer Entscheidungsebene"
|
||||
|
||||
aufgaben:
|
||||
- "Portfolio-Muster und -Trends analysieren"
|
||||
- "Erkenntnisse ableiten"
|
||||
- "Berichten ans Mission Board"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei strategischer Relevanz"
|
||||
an: "vision_board"
|
||||
|
||||
hierarchie_stufe: 2
|
||||
|
||||
- ebene_id: "dsr"
|
||||
name: "Demand & Stakeholder Runde"
|
||||
kurzform: "DSR"
|
||||
ebene: "operativ-taktisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
delegation:
|
||||
kann_delegieren_an: "mission_board"
|
||||
bedingung: "bei entsprechendem Klassifizierungsmuster"
|
||||
|
||||
hierarchie_stufe: 1
|
||||
|
||||
referenz:
|
||||
dokument: "dsr-geschaeftsordnung.yaml"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
|
||||
- ebene_id: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
kurzform: "DPM"
|
||||
ebene: "operativ"
|
||||
typ: "fachrolle"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Klassifizierung aller Demands im Portfolio"
|
||||
- "Analyse aller Demands im Portfolio"
|
||||
- "Bewertung aller Demands im Portfolio"
|
||||
- "Priorisierung aller Demands im Portfolio"
|
||||
|
||||
output: "Entscheidungsvorlage für jeweiliges Entscheidungsgremium"
|
||||
|
||||
governance_prinzip:
|
||||
trennung: "Entscheidungsgremium ≠ DPM"
|
||||
|
||||
sicherstellung:
|
||||
- aspekt: "Fachlich-objektive Arbeit"
|
||||
durch: "dpm"
|
||||
umfasst: ["Klassifizierung", "Analyse", "Bewertung", "Priorisierung"]
|
||||
|
||||
- aspekt: "Multiperspektivische Freigabe"
|
||||
durch: ["dsr", "mission_board"]
|
||||
umfasst: "Finale Entscheidung unter Berücksichtigung aller Perspektiven"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
- abschnitt: "Schnittstellen und Verantwortlichkeiten"
|
||||
siehe: "Abschnitt 5 in diesem Dokument"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 ENTSCHEIDUNGS-ROUTING
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungs_routing:
|
||||
beschreibung: "Systematische Zuordnung von Demands zu Entscheidungsebenen"
|
||||
|
||||
basis: "Klassifizierungslogik auf vier Dimensionen"
|
||||
|
||||
dimensionen:
|
||||
- id: "treiber"
|
||||
name: "Treiber"
|
||||
bedeutung: "Impulsquelle"
|
||||
|
||||
- id: "tragweite"
|
||||
name: "Tragweite"
|
||||
bedeutung: "Veränderungstiefe"
|
||||
|
||||
- id: "systemebene"
|
||||
name: "Systemebene"
|
||||
bedeutung: "Technisch-fachliche Verortung"
|
||||
|
||||
- id: "komplexitaet"
|
||||
name: "Komplexität"
|
||||
bedeutung: "Lösungsunsicherheit"
|
||||
|
||||
routing_optionen:
|
||||
- ziel: "mission_board"
|
||||
beschreibung: "Direkt an Mission Board"
|
||||
trigger: ["hochkomplex", "transformativ"]
|
||||
|
||||
- ziel: "dsr_mit_delegationsoption"
|
||||
beschreibung: "An DSR mit Option zur Delegation ans Mission Board"
|
||||
trigger: "entsprechendes Klassifizierungsmuster"
|
||||
|
||||
- ziel: "dsr"
|
||||
beschreibung: "An DSR ohne Delegationsoption"
|
||||
trigger: "inkrementelle Themen"
|
||||
|
||||
prinzip: |
|
||||
Entscheidungen werden auf der zuständigen Organisationsebene getroffen:
|
||||
- Hochkomplexe und transformative Demands → Mission Board
|
||||
- Inkrementelle Themen → Demand & Stakeholder-Runde
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Klassifizierung"
|
||||
abschnitt: "3.2 Routing-Logik: Die Klassifizierung bestimmt die Entscheidungsebene"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 3. DEMAND-PORTFOLIO-STEUERUNG UND REVIEWS
|
||||
# ========================================
|
||||
|
||||
portfolio_steuerung:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 STEUERUNGSEBENE DSR
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_dsr:
|
||||
ebene: "Demand & Stakeholder-Runde"
|
||||
|
||||
aufgaben:
|
||||
- id: "DSR-E1"
|
||||
name: "Entscheidung über DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
- id: "DSR-E2"
|
||||
name: "Delegations-Entscheidung"
|
||||
beschreibung: "Entscheidung über Delegation von Demands ans Mission Board"
|
||||
|
||||
- id: "DSR-I1"
|
||||
name: "Feedback-Aufnahme"
|
||||
beschreibung: "Aufnahme von Feedback zu laufenden Umsetzungen"
|
||||
|
||||
- id: "DSR-P1"
|
||||
name: "Problemklärung"
|
||||
beschreibung: "Klärung akuter Problemstellungen"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 STEUERUNGSEBENE MISSION BOARD
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_mission_board:
|
||||
ebene: "Mission Board"
|
||||
|
||||
aufgaben:
|
||||
- id: "MB-E1"
|
||||
name: "Freigabe von MB-Demands"
|
||||
beschreibung: "Entscheidung über hochkomplexe und transformative Demands"
|
||||
|
||||
- id: "MB-K1"
|
||||
name: "Ressourcenkonflikte lösen"
|
||||
beschreibung: "Auflösung von Ressourcenkonflikten zwischen Abteilungen"
|
||||
|
||||
- id: "MB-S1"
|
||||
name: "Gesamtportfolio steuern"
|
||||
beschreibung: "Steuerung des Gesamtportfolios aus Demands und Projekten"
|
||||
|
||||
referenz:
|
||||
dokument: "Geschäftsordnung des Mission Boards"
|
||||
hinweis: "Detaillierte Arbeitsweise"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 PORTFOLIO-REVIEWS (QUARTALSWEISE)
|
||||
# ----------------------------------
|
||||
|
||||
quartals_portfolio_reviews:
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "abteilungsleitung_planung"
|
||||
|
||||
teilnehmende:
|
||||
- "dpm"
|
||||
- "ppm"
|
||||
- "spm"
|
||||
- "shm"
|
||||
|
||||
berichterstattung:
|
||||
an: "mission_board"
|
||||
form: "Informationspunkt in der nächsten Sitzung"
|
||||
|
||||
zweck:
|
||||
hauptzweck: "Systematische Analyse der Portfolio-Dynamik"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit anhand KPIs bewerten"
|
||||
- "Verbesserungspotenziale ableiten"
|
||||
|
||||
nutzung_durch_al_p:
|
||||
zweck: "Abteilungsleitung Planung nutzt Erkenntnisse für"
|
||||
|
||||
nutzungen:
|
||||
- "Trends und wiederkehrende Herausforderungen erkennen"
|
||||
- "Effektivität der Governance bewerten"
|
||||
- "Anpassungsbedarfe identifizieren"
|
||||
- "Empfehlungen für Mission Board formulieren"
|
||||
|
||||
kern_inhalte:
|
||||
- id: "REV-1"
|
||||
name: "Portfolio-Überblick"
|
||||
aspekte: ["Volumen", "Durchsatz", "Themencluster"]
|
||||
|
||||
- id: "REV-2"
|
||||
name: "KPI-Analyse"
|
||||
beschreibung: "Analyse der definierten KPIs"
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Musteranalyse"
|
||||
aspekte: ["Engpässe", "Ablehnungsgründe", "Verzögerungen"]
|
||||
|
||||
- id: "REV-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
beschreibung: "Ableitung von Handlungsempfehlungen"
|
||||
|
||||
charakter:
|
||||
output_typ: "strategische Erkenntnisse"
|
||||
nicht: "operative Entscheidungen"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei Bedarf für kritische Themen"
|
||||
pfad: "Mission Board → Vision Board"
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Detaillierte Agenda, Analysevorlagen und Durchführungshinweise"
|
||||
|
||||
# ========================================
|
||||
# 4. DEMAND-PORTFOLIO KPIs
|
||||
# ========================================
|
||||
|
||||
demand_portfolio_kpis:
|
||||
zweck: "Systematische Analyse der Demand-Portfolio-Dynamik und kontinuierliche Verbesserung"
|
||||
|
||||
verwendung:
|
||||
kontext: "Quartalsweises Demand-Portfolio Review"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit bewerten"
|
||||
- "Strategische Erkenntnisse für Mission Board ableiten"
|
||||
|
||||
entwicklungsansatz:
|
||||
phase: "pilotphase"
|
||||
vorgehen: "Erste KPIs werden als Benchmarks erhoben und sukzessive weiterentwickelt"
|
||||
|
||||
referenzen:
|
||||
- dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Definition und Erhebungsmethodik"
|
||||
|
||||
- dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# 5. SCHNITTSTELLEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen_verantwortlichkeiten:
|
||||
|
||||
rollenmatrix:
|
||||
beschreibung: "DIGITOM nutzt ein differenziertes RACI-Modell mit unterschiedlichen Verantwortungslogiken"
|
||||
|
||||
referenz:
|
||||
dokument: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
|
||||
informationsfluesse:
|
||||
beschreibung: "Governance basiert auf definierten Informationsflüssen"
|
||||
|
||||
fluesse:
|
||||
- richtung: "bottom_up"
|
||||
name: "Bottom-up"
|
||||
beschreibung: "Demands fließen von Stakeholdern über SHM und DPM in die Entscheidungsgremien"
|
||||
pfad: "Stakeholder → SHM → DPM → DSR/MB"
|
||||
|
||||
- richtung: "top_down"
|
||||
name: "Top-down"
|
||||
beschreibung: "Strategische Vorgaben fließen vom Vision Board über Mission Board zur operativen Umsetzung"
|
||||
pfad: "Vision Board → Mission Board → operative Umsetzung"
|
||||
|
||||
- richtung: "horizontal"
|
||||
name: "Horizontal"
|
||||
beschreibung: "Abstimmung zwischen DPM, PPM und SPM zur Portfolio-Synchronisation"
|
||||
zwischen: ["dpm", "ppm", "spm"]
|
||||
zweck: "Portfolio-Synchronisation"
|
||||
|
||||
# ========================================
|
||||
# 6. PILOT-EVALUATION
|
||||
# ========================================
|
||||
|
||||
pilot_evaluation:
|
||||
zeitpunkt: "nach Pilotbetrieb"
|
||||
|
||||
status:
|
||||
evaluationskriterien: "in Erarbeitung"
|
||||
dokumentation: "separat"
|
||||
|
||||
referenz:
|
||||
dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# SYSTEMISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
systemische_einordnung:
|
||||
framework_charakter:
|
||||
typ: "übergeordnetes Governance-Framework"
|
||||
funktion: "Orchestrierung"
|
||||
scope: "Ende-zu-Ende (Stakeholder-Wunsch bis laufender Service)"
|
||||
|
||||
beziehung_zu_anderen_dokumenten:
|
||||
ergaenzt:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
art: "operative Regelungen"
|
||||
ergaenzung: "um übergreifende Steuerungsperspektive"
|
||||
|
||||
definiert_kontext_fuer:
|
||||
- dokument: "Demand-Klassifizierung"
|
||||
aspekt: "Routing-Logik erhält Governance-Kontext"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
aspekt: "Verantwortlichkeiten in Governance-Architektur eingebettet"
|
||||
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
aspekt: "Rolle in Governance-System verortet"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
governance_dokumente:
|
||||
- titel: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Operative Regelungen für DSR"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten"
|
||||
|
||||
methodische_dokumente:
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Routing-Logik und Klassifizierungskriterien"
|
||||
|
||||
- titel: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
relevanz: "KPIs und Review-Prozess"
|
||||
|
||||
prozess_dokumente:
|
||||
- titel: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
relevanz: "Operativer Ablauf DSR"
|
||||
|
||||
rollen_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Zentrale Rolle im Governance-System"
|
||||
|
||||
externe_referenzen:
|
||||
- titel: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
beschreibung: "Details zu drei Portfolios und Kernprozessen"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Geschäftsordnung Mission Board"
|
||||
beschreibung: "Detaillierte Arbeitsweise des Mission Board"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
|
@ -1,481 +1,481 @@
|
|||
meta:
|
||||
typ: "bewertungsmethodik"
|
||||
methode: "demand_bewertung"
|
||||
titel: "Bewertungskriterien für das Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf:
|
||||
- "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
- "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
fuehrt_zu: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "bewertung"
|
||||
- "qualitative-analyse"
|
||||
- "cluster-bewertung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: "Die Demand-Bewertung dient als Koordinationsinstrument für Priorisierungsentscheidungen"
|
||||
|
||||
zentrale_funktionen:
|
||||
- id: "F01"
|
||||
name: "Ressourcenallokation"
|
||||
beschreibung: "Fundierte Entscheidungsgrundlage bei begrenzten Kapazitäten zur optimalen Verteilung von Personal, Budget und Zeit"
|
||||
|
||||
- id: "F02"
|
||||
name: "Strategische Ausrichtung"
|
||||
beschreibung: "Sicherstellung, dass priorisierte Demands den größtmöglichen Beitrag zu den Organisationszielen leisten"
|
||||
|
||||
- id: "F03"
|
||||
name: "Transparenz"
|
||||
beschreibung: "Nachvollziehbare Dokumentation von Bewertungen und Entscheidungen für alle beteiligten Stakeholder"
|
||||
|
||||
- id: "F04"
|
||||
name: "Portfolio-Balance"
|
||||
beschreibung: "Ausgewogene Mischung aus strategischen Initiativen, operativen Verbesserungen und regulatorischen Anforderungen"
|
||||
|
||||
grundprinzipien:
|
||||
- prinzip: "Qualitative Bewertung"
|
||||
beschreibung: "Keine mathematischen Scoring-Modelle, sondern begründete qualitative Einschätzungen"
|
||||
|
||||
- prinzip: "Kontextbezug"
|
||||
beschreibung: "Bewertung erfolgt situationsspezifisch, nicht nach starrem Schema"
|
||||
|
||||
- prinzip: "Konsensorientierung"
|
||||
beschreibung: "Unterschiedliche Einschätzungen werden dialogisch geklärt"
|
||||
|
||||
# ========================================
|
||||
# 2. ÜBERSICHT DER BEWERTUNGSKRITERIEN
|
||||
# ========================================
|
||||
|
||||
bewertungskriterien:
|
||||
anzahl: 9
|
||||
cluster_anzahl: 3
|
||||
beschreibung: "Neun Kriterien gruppiert in drei thematische Cluster"
|
||||
|
||||
cluster_uebersicht:
|
||||
- cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
fokus: "Wertbeitrag des Demands"
|
||||
kriterien_ids: ["strategische_passung", "nutzen", "integrationswirkung"]
|
||||
|
||||
- cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
fokus: "Handlungsdruck und Risiko"
|
||||
kriterien_ids: ["organisationsrelevanz", "zeitliche_dringlichkeit", "risiko_nicht_umsetzung"]
|
||||
|
||||
- cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
fokus: "Realisierbarkeit und Ressourcenbedarf"
|
||||
kriterien_ids: ["technische_machbarkeit", "organisatorische_umsetzbarkeit", "ressourceneffizienz"]
|
||||
|
||||
# ========================================
|
||||
# 3. BEWERTUNGSKRITERIEN IM DETAIL
|
||||
# ========================================
|
||||
|
||||
kriterien_detail:
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 1: NUTZEN & WIRKUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_1_nutzen_wirkung:
|
||||
cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "strategische_passung"
|
||||
name: "Strategische Passung"
|
||||
kernfrage: "Wie gut unterstützt der Demand die Strategie?"
|
||||
fokus: "Strategiebeitrag & Innovation"
|
||||
|
||||
beschreibung: |
|
||||
Die strategische Passung bewertet den Beitrag des Demands zu den
|
||||
übergeordneten Zielen der Organisation und ihrer digitalen Transformation.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Übereinstimmung mit der Digitalisierungsstrategie der Verwaltung"
|
||||
- "Beitrag zu definierten Schwerpunktthemen und Leitprojekten"
|
||||
- "Unterstützung der Verwaltungsmodernisierung"
|
||||
- "Förderung zukunftsfähiger Verwaltungsstrukturen"
|
||||
- "Innovationspotenzial: Erschließung neuer Möglichkeiten oder Technologien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Kein erkennbarer Bezug zu strategischen Zielen"
|
||||
punkte_3: "Teilweise Übereinstimmung, unterstützt Einzelaspekte"
|
||||
punkte_5: "Kernbestandteil der Strategie mit hohem Innovationsgrad"
|
||||
|
||||
- kriterium_id: "nutzen"
|
||||
name: "Nutzen"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft der Demand?"
|
||||
fokus: "Public Value & Effizienz"
|
||||
|
||||
beschreibung: |
|
||||
Der Nutzen misst den konkreten Mehrwert des Demands in verschiedenen
|
||||
Dimensionen mit besonderem Fokus auf den Public Value.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Public Value"
|
||||
aspekte:
|
||||
- "Verbesserung der Lebensqualität für Bürger:innen"
|
||||
- "Steigerung der Servicequalität und Zugänglichkeit"
|
||||
- "Beitrag zur Daseinsvorsorge und Gemeinwohl"
|
||||
|
||||
- titel: "Effizienzsteigerung"
|
||||
aspekte:
|
||||
- "Prozessoptimierung und Automatisierung"
|
||||
- "Reduktion von Bearbeitungszeiten"
|
||||
- "Ressourceneinsparung und Fehlerminimierung"
|
||||
|
||||
- titel: "Qualitätsverbesserung"
|
||||
aspekte:
|
||||
- "Erhöhung der Datenqualität"
|
||||
- "Verbesserung der Entscheidungsgrundlagen"
|
||||
- "Steigerung der Servicequalität"
|
||||
|
||||
- titel: "Befähigung"
|
||||
aspekte:
|
||||
- "Schaffung neuer Handlungsmöglichkeiten"
|
||||
- "Kompetenzaufbau in der Organisation"
|
||||
- "Grundlage für weitere Digitalisierungsschritte"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Nutzen nur in Einzelaspekten erkennbar"
|
||||
punkte_3: "Mehrere Nutzendimensionen werden adressiert"
|
||||
punkte_5: "Umfassender Nutzen mit hohem Public Value"
|
||||
|
||||
- kriterium_id: "integrationswirkung"
|
||||
name: "Integrationswirkung"
|
||||
kernfrage: "Welche Synergien und Standards entstehen?"
|
||||
fokus: "Architektur & Wiederverwendung"
|
||||
|
||||
beschreibung: |
|
||||
Die Integrationswirkung bewertet den Beitrag zur Verbesserung der
|
||||
Gesamtarchitektur und Schaffung von Synergien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Schaffung wiederverwendbarer Komponenten oder Standards"
|
||||
- "Reduktion technischer Schulden und Komplexität"
|
||||
- "Harmonisierung von Prozessen und Schnittstellen"
|
||||
- "Beitrag zur Architekturkonvergenz"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Isolierte Einzellösung ohne Synergieeffekte"
|
||||
punkte_3: "Lokale Verbesserungen mit begrenztem Wiederverwendungspotenzial"
|
||||
punkte_5: "Grundlegende Plattform oder Standard mit breiter Nutzbarkeit"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
# ----------------------------------
|
||||
|
||||
cluster_2_druck_notwendigkeit:
|
||||
cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "organisationsrelevanz"
|
||||
name: "Organisationsrelevanz"
|
||||
kernfrage: "Wie wichtig ist der Demand für die Verwaltung?"
|
||||
fokus: "Interne Priorität & Unterstützung"
|
||||
|
||||
beschreibung: |
|
||||
Die Organisationsrelevanz erfasst die Bedeutung des Demands innerhalb
|
||||
der DIGIT-Strukturen und -Prozesse.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Priorität in den Abteilungen und Führungsebenen"
|
||||
- "Betroffenheit kritischer Prozesse"
|
||||
- "Anzahl betroffener Organisationseinheiten"
|
||||
- "Unterstützung durch Schlüsselpersonen"
|
||||
- "Verbindlichkeit durch Gremienbeschlüsse"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Einzelinteresse ohne breite Unterstützung"
|
||||
punkte_3: "Bereichsübergreifende Relevanz mit moderater Priorität"
|
||||
punkte_5: "Organisationsweite Priorität mit starker Führungsunterstützung"
|
||||
|
||||
- kriterium_id: "zeitliche_dringlichkeit"
|
||||
name: "Zeitliche Dringlichkeit"
|
||||
kernfrage: "Bis wann muss umgesetzt werden?"
|
||||
fokus: "Fristen & Handlungsdruck"
|
||||
|
||||
beschreibung: |
|
||||
Die zeitliche Dringlichkeit erfasst externe und interne Zeitvorgaben.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Harte Fristen"
|
||||
aspekte:
|
||||
- "Gesetzliche Umsetzungsfristen"
|
||||
- "Vertragsablauf oder Kündigungsfristen"
|
||||
- "Technische End-of-Life-Termine"
|
||||
|
||||
- titel: "Weiche Fristen"
|
||||
aspekte:
|
||||
- "Politische Zusagen und Termine"
|
||||
- "Budgetjahre und Fördermittelfristen"
|
||||
- "Koordination mit anderen Vorhaben"
|
||||
|
||||
- titel: "Handlungsdruck"
|
||||
aspekte:
|
||||
- "Akkumulierter Problemdruck"
|
||||
- "Erwartungshaltung der Stakeholder"
|
||||
- "Verfügbare Zeitfenster für Umsetzung"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Flexible Zeithorizonte (> 18 Monate)"
|
||||
punkte_3: "Mittelfristiger Handlungsbedarf (6-18 Monate)"
|
||||
punkte_5: "Sofortiger Handlungsbedarf (< 6 Monate)"
|
||||
|
||||
- kriterium_id: "risiko_nicht_umsetzung"
|
||||
name: "Risiko bei Nicht-Umsetzung"
|
||||
kernfrage: "Was passiert ohne Realisierung?"
|
||||
fokus: "Rechtliche, operative & Reputationsrisiken"
|
||||
|
||||
beschreibung: |
|
||||
Diese Kategorie analysiert die negativen Konsequenzen einer
|
||||
Nicht-Realisierung des Demands.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Rechtliche Risiken"
|
||||
aspekte:
|
||||
- "Drohende Sanktionen oder Bußgelder"
|
||||
- "Verletzung gesetzlicher Vorgaben"
|
||||
- "Haftungsrisiken für die Verwaltung"
|
||||
|
||||
- titel: "Operative Risiken"
|
||||
aspekte:
|
||||
- "Gefährdung der Handlungsfähigkeit"
|
||||
- "Systemausfälle oder Sicherheitslücken"
|
||||
- "Prozessunterbrechungen"
|
||||
|
||||
- titel: "Reputationsrisiken"
|
||||
aspekte:
|
||||
- "Vertrauensverlust bei Bürger:innen"
|
||||
- "Negative Außenwirkung"
|
||||
- "Politische Konsequenzen"
|
||||
|
||||
- titel: "Opportunitätskosten"
|
||||
aspekte:
|
||||
- "Entgangene Fördermittel"
|
||||
- "Verpasste Einsparpotenziale"
|
||||
- "Wettbewerbsnachteile"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Marginale Auswirkungen absehbar"
|
||||
punkte_3: "Mittelfristig spürbare negative Effekte"
|
||||
punkte_5: "Kritische Risiken mit unmittelbaren Konsequenzen"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
# ----------------------------------
|
||||
|
||||
cluster_3_machbarkeit_aufwand:
|
||||
cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "technische_machbarkeit"
|
||||
name: "Technische Machbarkeit"
|
||||
kernfrage: "Ist die Lösung technisch realisierbar?"
|
||||
fokus: "Technologie & Architektur"
|
||||
|
||||
beschreibung: |
|
||||
Die technische Machbarkeit prüft die Realisierbarkeit mit verfügbaren
|
||||
Mitteln und Technologien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit erprobter Technologien und Lösungsansätze"
|
||||
- "Kompatibilität mit der Bestandslandschaft"
|
||||
- "Erfüllbarkeit von Sicherheits- und Datenschutzanforderungen"
|
||||
- "Skalierbarkeit und Performance-Anforderungen"
|
||||
- "Verfügbarkeit technischer Expertise"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Erhebliche technische Herausforderungen, Neuland"
|
||||
punkte_3: "Lösbar mit vertretbarem Aufwand und bekannten Ansätzen"
|
||||
punkte_5: "Standardlösung mit minimalem technischen Risiko"
|
||||
|
||||
- kriterium_id: "organisatorische_umsetzbarkeit"
|
||||
name: "Organisatorische Umsetzbarkeit"
|
||||
kernfrage: "Sind die organisatorischen Voraussetzungen gegeben?"
|
||||
fokus: "Change & Ressourcen"
|
||||
|
||||
beschreibung: |
|
||||
Die organisatorische Umsetzbarkeit bewertet die Rahmenbedingungen für
|
||||
eine erfolgreiche Realisierung.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit notwendiger Kompetenzen und Ressourcen"
|
||||
- "Veränderungsbereitschaft in betroffenen Bereichen"
|
||||
- "Klarheit der Zuständigkeiten und Verantwortlichkeiten"
|
||||
- "Tragfähigkeit des geplanten Betriebsmodells"
|
||||
- "Unterstützung durch relevante Stakeholder"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Grundlegende organisatorische Hindernisse"
|
||||
punkte_3: "Umsetzbar mit moderaten Anpassungen"
|
||||
punkte_5: "Optimale organisatorische Voraussetzungen"
|
||||
|
||||
- kriterium_id: "ressourceneffizienz"
|
||||
name: "Ressourceneffizienz"
|
||||
kernfrage: "Steht der Aufwand im Verhältnis zum Nutzen?"
|
||||
fokus: "Kosten-Nutzen-Relation"
|
||||
|
||||
beschreibung: |
|
||||
Die Ressourceneffizienz bewertet das Verhältnis von Aufwand zu
|
||||
erwartetem Nutzen.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Investitionsvolumen in Relation zum erwarteten Nutzen"
|
||||
- "Folgekosten und Betriebsaufwände"
|
||||
- "Personalbindung und Opportunitätskosten"
|
||||
- "Wiederverwendbarkeit von Ergebnissen"
|
||||
- "Skaleneffekte und Synergien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
hinweis: "Inverse Skala"
|
||||
punkte_1: "Sehr ungünstiges Aufwand-Nutzen-Verhältnis"
|
||||
punkte_3: "Angemessener Ressourceneinsatz"
|
||||
punkte_5: "Exzellentes Aufwand-Nutzen-Verhältnis"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 PROJEKT-PORTFOLIO-ABGLEICH
|
||||
# ----------------------------------
|
||||
|
||||
projekt_portfolio_abgleich:
|
||||
beschreibung: |
|
||||
Vor der Bewertung erfolgt ein systematischer Abgleich mit dem bestehenden
|
||||
Projekt-Portfolio. Der DPM initiiert diesen Abgleich in Zusammenarbeit mit dem PPM.
|
||||
|
||||
szenarien:
|
||||
- szenario: "integration_laufendes_projekt"
|
||||
name: "Szenario 1: Integration in laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird direkt an das Projektteam übergeben"
|
||||
- "Integration in bestehende Projektstrukturen"
|
||||
- "Keine separate Bewertung erforderlich"
|
||||
|
||||
- szenario: "abhaengigkeit_laufendes_projekt"
|
||||
name: "Szenario 2: Abhängigkeit von laufendem Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird zurückgestellt bis Projektabschluss"
|
||||
- "Aufnahme ins Backlog mit Wiedervorlage"
|
||||
- "Bewertung erfolgt nach Projektabschluss"
|
||||
|
||||
- szenario: "beeinflussung_laufendes_projekt"
|
||||
name: "Szenario 3: Beeinflussung durch laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Neubewertung des Bedarfs im Projektkontext"
|
||||
- "Abstimmung mit Stakeholder über angepassten Bedarf"
|
||||
- "Bewertung auf Basis der veränderten Ausgangslage"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 CLUSTER-BASIERTE BEWERTUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_bewertung:
|
||||
beschreibung: |
|
||||
Die operative Bewertung erfolgt als strukturierter Prozess, der die neun
|
||||
Kriterien über ihre drei Cluster handhabbar macht.
|
||||
|
||||
bewertungsprozess:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Projekt-Portfolio-Abgleich als Vorstufe"
|
||||
referenz: "siehe 4.1"
|
||||
|
||||
- schritt: 2
|
||||
name: "Clusterweise Bewertung"
|
||||
beschreibung: "Die Bewertung erfolgt clusterweise, um thematisch zusammenhängende Aspekte im Kontext zu betrachten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vergabe von Orientierungswerten"
|
||||
skala: "1-5 Punkte"
|
||||
|
||||
- schritt: 4
|
||||
name: "Mustererkennung"
|
||||
fokus: "Innerhalb und zwischen Clustern"
|
||||
|
||||
- schritt: 5
|
||||
name: "Qualitative Interpretation"
|
||||
output: "Cluster-Fazit mit Handlungsimplikationen"
|
||||
|
||||
ergebnisdokumentation:
|
||||
beschreibung: "Für jedes Cluster entsteht ein Fazit, das die Einzelwerte interpretiert und Handlungsimplikationen ableitet"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 DOKUMENTATIONSFORMAT
|
||||
# ----------------------------------
|
||||
|
||||
dokumentationsformat:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
CLUSTER 1: NUTZEN & WIRKUNG
|
||||
|
||||
Strategische Passung: [○○○○○] [(x/5)]
|
||||
Nutzen: [○○○○○] [(x/5)]
|
||||
Integrationswirkung: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 1 Fazit: [Qualitative Einschätzung der Stärken und Schwächen]
|
||||
|
||||
CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
|
||||
Organisationsrelevanz: [○○○○○] [(x/5)]
|
||||
Risiko bei Nicht-Umsetzung:[○○○○○] [(x/5)]
|
||||
Zeitliche Dringlichkeit: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 2 Fazit: [Interpretation des Handlungsdrucks]
|
||||
|
||||
CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
|
||||
Technische Machbarkeit: [○○○○○] [(x/5)]
|
||||
Organisatorische Umsetzbarkeit: [○○○○○] [(x/5)]
|
||||
Ressourceneffizienz: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 3 Fazit: [Einschätzung der Realisierbarkeit]
|
||||
|
||||
GESAMTBEURTEILUNG: [Zusammenfassende Bewertung mit konkreter Handlungsempfehlung]
|
||||
|
||||
# ========================================
|
||||
# 5. MULTI-STAKEHOLDER-PERSPEKTIVE
|
||||
# ========================================
|
||||
|
||||
multi_stakeholder_perspektive:
|
||||
beschreibung: "Integration unterschiedlicher Stakeholder-Perspektiven in die Demand-Bewertung (DIGIT-intern)"
|
||||
|
||||
funktionen:
|
||||
- "Früherkennung von Konflikten: Divergierende Bewertungen identifizieren potenzielle Widerstände vor der Umsetzung"
|
||||
- "Vollständigeres Bild: Verschiedene Blickwinkel decken blinde Flecken in der Bewertung auf"
|
||||
- "Erhöhte Akzeptanz: Einbeziehung verschiedener Perspektiven schafft Commitment für spätere Entscheidungen"
|
||||
- "Risikominimierung: Fundamentale Interessenskonflikte werden sichtbar bevor Ressourcen gebunden werden"
|
||||
|
||||
dokumentation:
|
||||
beschreibung: "Divergierende Einschätzungen werden mit Begründung erfasst"
|
||||
|
||||
template: |
|
||||
MULTI-STAKEHOLDER PERSPEKTIVE
|
||||
|
||||
KRITERIUM: [Bewertungskriterium, das divergent ist]
|
||||
|
||||
[Stakeholder A] [○○○○○] [(x/5)] [Begründung Stakeholder A]
|
||||
[Stakeholder B] [○○○○○] [(x/5)] [Begründung Stakeholder B]
|
||||
|
||||
meta:
|
||||
typ: "bewertungsmethodik"
|
||||
methode: "demand_bewertung"
|
||||
titel: "Bewertungskriterien für das Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf:
|
||||
- "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
- "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
fuehrt_zu: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "bewertung"
|
||||
- "qualitative-analyse"
|
||||
- "cluster-bewertung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: "Die Demand-Bewertung dient als Koordinationsinstrument für Priorisierungsentscheidungen"
|
||||
|
||||
zentrale_funktionen:
|
||||
- id: "F01"
|
||||
name: "Ressourcenallokation"
|
||||
beschreibung: "Fundierte Entscheidungsgrundlage bei begrenzten Kapazitäten zur optimalen Verteilung von Personal, Budget und Zeit"
|
||||
|
||||
- id: "F02"
|
||||
name: "Strategische Ausrichtung"
|
||||
beschreibung: "Sicherstellung, dass priorisierte Demands den größtmöglichen Beitrag zu den Organisationszielen leisten"
|
||||
|
||||
- id: "F03"
|
||||
name: "Transparenz"
|
||||
beschreibung: "Nachvollziehbare Dokumentation von Bewertungen und Entscheidungen für alle beteiligten Stakeholder"
|
||||
|
||||
- id: "F04"
|
||||
name: "Portfolio-Balance"
|
||||
beschreibung: "Ausgewogene Mischung aus strategischen Initiativen, operativen Verbesserungen und regulatorischen Anforderungen"
|
||||
|
||||
grundprinzipien:
|
||||
- prinzip: "Qualitative Bewertung"
|
||||
beschreibung: "Keine mathematischen Scoring-Modelle, sondern begründete qualitative Einschätzungen"
|
||||
|
||||
- prinzip: "Kontextbezug"
|
||||
beschreibung: "Bewertung erfolgt situationsspezifisch, nicht nach starrem Schema"
|
||||
|
||||
- prinzip: "Konsensorientierung"
|
||||
beschreibung: "Unterschiedliche Einschätzungen werden dialogisch geklärt"
|
||||
|
||||
# ========================================
|
||||
# 2. ÜBERSICHT DER BEWERTUNGSKRITERIEN
|
||||
# ========================================
|
||||
|
||||
bewertungskriterien:
|
||||
anzahl: 9
|
||||
cluster_anzahl: 3
|
||||
beschreibung: "Neun Kriterien gruppiert in drei thematische Cluster"
|
||||
|
||||
cluster_uebersicht:
|
||||
- cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
fokus: "Wertbeitrag des Demands"
|
||||
kriterien_ids: ["strategische_passung", "nutzen", "integrationswirkung"]
|
||||
|
||||
- cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
fokus: "Handlungsdruck und Risiko"
|
||||
kriterien_ids: ["organisationsrelevanz", "zeitliche_dringlichkeit", "risiko_nicht_umsetzung"]
|
||||
|
||||
- cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
fokus: "Realisierbarkeit und Ressourcenbedarf"
|
||||
kriterien_ids: ["technische_machbarkeit", "organisatorische_umsetzbarkeit", "ressourceneffizienz"]
|
||||
|
||||
# ========================================
|
||||
# 3. BEWERTUNGSKRITERIEN IM DETAIL
|
||||
# ========================================
|
||||
|
||||
kriterien_detail:
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 1: NUTZEN & WIRKUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_1_nutzen_wirkung:
|
||||
cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "strategische_passung"
|
||||
name: "Strategische Passung"
|
||||
kernfrage: "Wie gut unterstützt der Demand die Strategie?"
|
||||
fokus: "Strategiebeitrag & Innovation"
|
||||
|
||||
beschreibung: |
|
||||
Die strategische Passung bewertet den Beitrag des Demands zu den
|
||||
übergeordneten Zielen der Organisation und ihrer digitalen Transformation.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Übereinstimmung mit der Digitalisierungsstrategie der Verwaltung"
|
||||
- "Beitrag zu definierten Schwerpunktthemen und Leitprojekten"
|
||||
- "Unterstützung der Verwaltungsmodernisierung"
|
||||
- "Förderung zukunftsfähiger Verwaltungsstrukturen"
|
||||
- "Innovationspotenzial: Erschließung neuer Möglichkeiten oder Technologien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Kein erkennbarer Bezug zu strategischen Zielen"
|
||||
punkte_3: "Teilweise Übereinstimmung, unterstützt Einzelaspekte"
|
||||
punkte_5: "Kernbestandteil der Strategie mit hohem Innovationsgrad"
|
||||
|
||||
- kriterium_id: "nutzen"
|
||||
name: "Nutzen"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft der Demand?"
|
||||
fokus: "Public Value & Effizienz"
|
||||
|
||||
beschreibung: |
|
||||
Der Nutzen misst den konkreten Mehrwert des Demands in verschiedenen
|
||||
Dimensionen mit besonderem Fokus auf den Public Value.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Public Value"
|
||||
aspekte:
|
||||
- "Verbesserung der Lebensqualität für Bürger:innen"
|
||||
- "Steigerung der Servicequalität und Zugänglichkeit"
|
||||
- "Beitrag zur Daseinsvorsorge und Gemeinwohl"
|
||||
|
||||
- titel: "Effizienzsteigerung"
|
||||
aspekte:
|
||||
- "Prozessoptimierung und Automatisierung"
|
||||
- "Reduktion von Bearbeitungszeiten"
|
||||
- "Ressourceneinsparung und Fehlerminimierung"
|
||||
|
||||
- titel: "Qualitätsverbesserung"
|
||||
aspekte:
|
||||
- "Erhöhung der Datenqualität"
|
||||
- "Verbesserung der Entscheidungsgrundlagen"
|
||||
- "Steigerung der Servicequalität"
|
||||
|
||||
- titel: "Befähigung"
|
||||
aspekte:
|
||||
- "Schaffung neuer Handlungsmöglichkeiten"
|
||||
- "Kompetenzaufbau in der Organisation"
|
||||
- "Grundlage für weitere Digitalisierungsschritte"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Nutzen nur in Einzelaspekten erkennbar"
|
||||
punkte_3: "Mehrere Nutzendimensionen werden adressiert"
|
||||
punkte_5: "Umfassender Nutzen mit hohem Public Value"
|
||||
|
||||
- kriterium_id: "integrationswirkung"
|
||||
name: "Integrationswirkung"
|
||||
kernfrage: "Welche Synergien und Standards entstehen?"
|
||||
fokus: "Architektur & Wiederverwendung"
|
||||
|
||||
beschreibung: |
|
||||
Die Integrationswirkung bewertet den Beitrag zur Verbesserung der
|
||||
Gesamtarchitektur und Schaffung von Synergien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Schaffung wiederverwendbarer Komponenten oder Standards"
|
||||
- "Reduktion technischer Schulden und Komplexität"
|
||||
- "Harmonisierung von Prozessen und Schnittstellen"
|
||||
- "Beitrag zur Architekturkonvergenz"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Isolierte Einzellösung ohne Synergieeffekte"
|
||||
punkte_3: "Lokale Verbesserungen mit begrenztem Wiederverwendungspotenzial"
|
||||
punkte_5: "Grundlegende Plattform oder Standard mit breiter Nutzbarkeit"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
# ----------------------------------
|
||||
|
||||
cluster_2_druck_notwendigkeit:
|
||||
cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "organisationsrelevanz"
|
||||
name: "Organisationsrelevanz"
|
||||
kernfrage: "Wie wichtig ist der Demand für die Verwaltung?"
|
||||
fokus: "Interne Priorität & Unterstützung"
|
||||
|
||||
beschreibung: |
|
||||
Die Organisationsrelevanz erfasst die Bedeutung des Demands innerhalb
|
||||
der DIGIT-Strukturen und -Prozesse.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Priorität in den Abteilungen und Führungsebenen"
|
||||
- "Betroffenheit kritischer Prozesse"
|
||||
- "Anzahl betroffener Organisationseinheiten"
|
||||
- "Unterstützung durch Schlüsselpersonen"
|
||||
- "Verbindlichkeit durch Gremienbeschlüsse"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Einzelinteresse ohne breite Unterstützung"
|
||||
punkte_3: "Bereichsübergreifende Relevanz mit moderater Priorität"
|
||||
punkte_5: "Organisationsweite Priorität mit starker Führungsunterstützung"
|
||||
|
||||
- kriterium_id: "zeitliche_dringlichkeit"
|
||||
name: "Zeitliche Dringlichkeit"
|
||||
kernfrage: "Bis wann muss umgesetzt werden?"
|
||||
fokus: "Fristen & Handlungsdruck"
|
||||
|
||||
beschreibung: |
|
||||
Die zeitliche Dringlichkeit erfasst externe und interne Zeitvorgaben.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Harte Fristen"
|
||||
aspekte:
|
||||
- "Gesetzliche Umsetzungsfristen"
|
||||
- "Vertragsablauf oder Kündigungsfristen"
|
||||
- "Technische End-of-Life-Termine"
|
||||
|
||||
- titel: "Weiche Fristen"
|
||||
aspekte:
|
||||
- "Politische Zusagen und Termine"
|
||||
- "Budgetjahre und Fördermittelfristen"
|
||||
- "Koordination mit anderen Vorhaben"
|
||||
|
||||
- titel: "Handlungsdruck"
|
||||
aspekte:
|
||||
- "Akkumulierter Problemdruck"
|
||||
- "Erwartungshaltung der Stakeholder"
|
||||
- "Verfügbare Zeitfenster für Umsetzung"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Flexible Zeithorizonte (> 18 Monate)"
|
||||
punkte_3: "Mittelfristiger Handlungsbedarf (6-18 Monate)"
|
||||
punkte_5: "Sofortiger Handlungsbedarf (< 6 Monate)"
|
||||
|
||||
- kriterium_id: "risiko_nicht_umsetzung"
|
||||
name: "Risiko bei Nicht-Umsetzung"
|
||||
kernfrage: "Was passiert ohne Realisierung?"
|
||||
fokus: "Rechtliche, operative & Reputationsrisiken"
|
||||
|
||||
beschreibung: |
|
||||
Diese Kategorie analysiert die negativen Konsequenzen einer
|
||||
Nicht-Realisierung des Demands.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Rechtliche Risiken"
|
||||
aspekte:
|
||||
- "Drohende Sanktionen oder Bußgelder"
|
||||
- "Verletzung gesetzlicher Vorgaben"
|
||||
- "Haftungsrisiken für die Verwaltung"
|
||||
|
||||
- titel: "Operative Risiken"
|
||||
aspekte:
|
||||
- "Gefährdung der Handlungsfähigkeit"
|
||||
- "Systemausfälle oder Sicherheitslücken"
|
||||
- "Prozessunterbrechungen"
|
||||
|
||||
- titel: "Reputationsrisiken"
|
||||
aspekte:
|
||||
- "Vertrauensverlust bei Bürger:innen"
|
||||
- "Negative Außenwirkung"
|
||||
- "Politische Konsequenzen"
|
||||
|
||||
- titel: "Opportunitätskosten"
|
||||
aspekte:
|
||||
- "Entgangene Fördermittel"
|
||||
- "Verpasste Einsparpotenziale"
|
||||
- "Wettbewerbsnachteile"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Marginale Auswirkungen absehbar"
|
||||
punkte_3: "Mittelfristig spürbare negative Effekte"
|
||||
punkte_5: "Kritische Risiken mit unmittelbaren Konsequenzen"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
# ----------------------------------
|
||||
|
||||
cluster_3_machbarkeit_aufwand:
|
||||
cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "technische_machbarkeit"
|
||||
name: "Technische Machbarkeit"
|
||||
kernfrage: "Ist die Lösung technisch realisierbar?"
|
||||
fokus: "Technologie & Architektur"
|
||||
|
||||
beschreibung: |
|
||||
Die technische Machbarkeit prüft die Realisierbarkeit mit verfügbaren
|
||||
Mitteln und Technologien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit erprobter Technologien und Lösungsansätze"
|
||||
- "Kompatibilität mit der Bestandslandschaft"
|
||||
- "Erfüllbarkeit von Sicherheits- und Datenschutzanforderungen"
|
||||
- "Skalierbarkeit und Performance-Anforderungen"
|
||||
- "Verfügbarkeit technischer Expertise"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Erhebliche technische Herausforderungen, Neuland"
|
||||
punkte_3: "Lösbar mit vertretbarem Aufwand und bekannten Ansätzen"
|
||||
punkte_5: "Standardlösung mit minimalem technischen Risiko"
|
||||
|
||||
- kriterium_id: "organisatorische_umsetzbarkeit"
|
||||
name: "Organisatorische Umsetzbarkeit"
|
||||
kernfrage: "Sind die organisatorischen Voraussetzungen gegeben?"
|
||||
fokus: "Change & Ressourcen"
|
||||
|
||||
beschreibung: |
|
||||
Die organisatorische Umsetzbarkeit bewertet die Rahmenbedingungen für
|
||||
eine erfolgreiche Realisierung.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit notwendiger Kompetenzen und Ressourcen"
|
||||
- "Veränderungsbereitschaft in betroffenen Bereichen"
|
||||
- "Klarheit der Zuständigkeiten und Verantwortlichkeiten"
|
||||
- "Tragfähigkeit des geplanten Betriebsmodells"
|
||||
- "Unterstützung durch relevante Stakeholder"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Grundlegende organisatorische Hindernisse"
|
||||
punkte_3: "Umsetzbar mit moderaten Anpassungen"
|
||||
punkte_5: "Optimale organisatorische Voraussetzungen"
|
||||
|
||||
- kriterium_id: "ressourceneffizienz"
|
||||
name: "Ressourceneffizienz"
|
||||
kernfrage: "Steht der Aufwand im Verhältnis zum Nutzen?"
|
||||
fokus: "Kosten-Nutzen-Relation"
|
||||
|
||||
beschreibung: |
|
||||
Die Ressourceneffizienz bewertet das Verhältnis von Aufwand zu
|
||||
erwartetem Nutzen.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Investitionsvolumen in Relation zum erwarteten Nutzen"
|
||||
- "Folgekosten und Betriebsaufwände"
|
||||
- "Personalbindung und Opportunitätskosten"
|
||||
- "Wiederverwendbarkeit von Ergebnissen"
|
||||
- "Skaleneffekte und Synergien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
hinweis: "Inverse Skala"
|
||||
punkte_1: "Sehr ungünstiges Aufwand-Nutzen-Verhältnis"
|
||||
punkte_3: "Angemessener Ressourceneinsatz"
|
||||
punkte_5: "Exzellentes Aufwand-Nutzen-Verhältnis"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 PROJEKT-PORTFOLIO-ABGLEICH
|
||||
# ----------------------------------
|
||||
|
||||
projekt_portfolio_abgleich:
|
||||
beschreibung: |
|
||||
Vor der Bewertung erfolgt ein systematischer Abgleich mit dem bestehenden
|
||||
Projekt-Portfolio. Der DPM initiiert diesen Abgleich in Zusammenarbeit mit dem PPM.
|
||||
|
||||
szenarien:
|
||||
- szenario: "integration_laufendes_projekt"
|
||||
name: "Szenario 1: Integration in laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird direkt an das Projektteam übergeben"
|
||||
- "Integration in bestehende Projektstrukturen"
|
||||
- "Keine separate Bewertung erforderlich"
|
||||
|
||||
- szenario: "abhaengigkeit_laufendes_projekt"
|
||||
name: "Szenario 2: Abhängigkeit von laufendem Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird zurückgestellt bis Projektabschluss"
|
||||
- "Aufnahme ins Backlog mit Wiedervorlage"
|
||||
- "Bewertung erfolgt nach Projektabschluss"
|
||||
|
||||
- szenario: "beeinflussung_laufendes_projekt"
|
||||
name: "Szenario 3: Beeinflussung durch laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Neubewertung des Bedarfs im Projektkontext"
|
||||
- "Abstimmung mit Stakeholder über angepassten Bedarf"
|
||||
- "Bewertung auf Basis der veränderten Ausgangslage"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 CLUSTER-BASIERTE BEWERTUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_bewertung:
|
||||
beschreibung: |
|
||||
Die operative Bewertung erfolgt als strukturierter Prozess, der die neun
|
||||
Kriterien über ihre drei Cluster handhabbar macht.
|
||||
|
||||
bewertungsprozess:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Projekt-Portfolio-Abgleich als Vorstufe"
|
||||
referenz: "siehe 4.1"
|
||||
|
||||
- schritt: 2
|
||||
name: "Clusterweise Bewertung"
|
||||
beschreibung: "Die Bewertung erfolgt clusterweise, um thematisch zusammenhängende Aspekte im Kontext zu betrachten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vergabe von Orientierungswerten"
|
||||
skala: "1-5 Punkte"
|
||||
|
||||
- schritt: 4
|
||||
name: "Mustererkennung"
|
||||
fokus: "Innerhalb und zwischen Clustern"
|
||||
|
||||
- schritt: 5
|
||||
name: "Qualitative Interpretation"
|
||||
output: "Cluster-Fazit mit Handlungsimplikationen"
|
||||
|
||||
ergebnisdokumentation:
|
||||
beschreibung: "Für jedes Cluster entsteht ein Fazit, das die Einzelwerte interpretiert und Handlungsimplikationen ableitet"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 DOKUMENTATIONSFORMAT
|
||||
# ----------------------------------
|
||||
|
||||
dokumentationsformat:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
CLUSTER 1: NUTZEN & WIRKUNG
|
||||
|
||||
Strategische Passung: [○○○○○] [(x/5)]
|
||||
Nutzen: [○○○○○] [(x/5)]
|
||||
Integrationswirkung: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 1 Fazit: [Qualitative Einschätzung der Stärken und Schwächen]
|
||||
|
||||
CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
|
||||
Organisationsrelevanz: [○○○○○] [(x/5)]
|
||||
Risiko bei Nicht-Umsetzung:[○○○○○] [(x/5)]
|
||||
Zeitliche Dringlichkeit: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 2 Fazit: [Interpretation des Handlungsdrucks]
|
||||
|
||||
CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
|
||||
Technische Machbarkeit: [○○○○○] [(x/5)]
|
||||
Organisatorische Umsetzbarkeit: [○○○○○] [(x/5)]
|
||||
Ressourceneffizienz: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 3 Fazit: [Einschätzung der Realisierbarkeit]
|
||||
|
||||
GESAMTBEURTEILUNG: [Zusammenfassende Bewertung mit konkreter Handlungsempfehlung]
|
||||
|
||||
# ========================================
|
||||
# 5. MULTI-STAKEHOLDER-PERSPEKTIVE
|
||||
# ========================================
|
||||
|
||||
multi_stakeholder_perspektive:
|
||||
beschreibung: "Integration unterschiedlicher Stakeholder-Perspektiven in die Demand-Bewertung (DIGIT-intern)"
|
||||
|
||||
funktionen:
|
||||
- "Früherkennung von Konflikten: Divergierende Bewertungen identifizieren potenzielle Widerstände vor der Umsetzung"
|
||||
- "Vollständigeres Bild: Verschiedene Blickwinkel decken blinde Flecken in der Bewertung auf"
|
||||
- "Erhöhte Akzeptanz: Einbeziehung verschiedener Perspektiven schafft Commitment für spätere Entscheidungen"
|
||||
- "Risikominimierung: Fundamentale Interessenskonflikte werden sichtbar bevor Ressourcen gebunden werden"
|
||||
|
||||
dokumentation:
|
||||
beschreibung: "Divergierende Einschätzungen werden mit Begründung erfasst"
|
||||
|
||||
template: |
|
||||
MULTI-STAKEHOLDER PERSPEKTIVE
|
||||
|
||||
KRITERIUM: [Bewertungskriterium, das divergent ist]
|
||||
|
||||
[Stakeholder A] [○○○○○] [(x/5)] [Begründung Stakeholder A]
|
||||
[Stakeholder B] [○○○○○] [(x/5)] [Begründung Stakeholder B]
|
||||
|
||||
Handlungsbedarf: [Beschreibung]
|
||||
|
|
@ -1,421 +1,421 @@
|
|||
meta:
|
||||
typ: "priorisierungsmethodik"
|
||||
methode: "demand_priorisierung"
|
||||
titel: "Priorisierungsverfahren im Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf: "#01.4_methodik/demand-bewertung.yaml"
|
||||
erzeugt: "handlungsempfehlungen_fuer_gremien"
|
||||
|
||||
kontext_tags:
|
||||
- "priorisierung"
|
||||
- "eisenhower-matrix"
|
||||
- "handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND FUNKTION
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Das Priorisierungsverfahren bildet den finalen Schritt der Demand-Bewertung
|
||||
und überführt die qualitative Analyse in konkrete Handlungsempfehlungen.
|
||||
|
||||
funktionen:
|
||||
- "Entscheidungsvorbereitung: Strukturierte Aufbereitung für Gremienentscheidungen"
|
||||
- "Ressourcenoptimierung: Fokussierung auf die wirkungsvollsten Demands bei begrenzten Kapazitäten"
|
||||
- "Transparenz: Nachvollziehbare Darstellung von Prioritäten für alle Stakeholder"
|
||||
- "Handlungsorientierung: Klare Strategien für unterschiedliche Demand-Typen"
|
||||
|
||||
methodik: |
|
||||
Die Priorisierung erfolgt mittels einer erweiterten Eisenhower-Matrix, die
|
||||
durch eine Farbcodierung zur Entscheidungsgrundlage wird.
|
||||
|
||||
# ========================================
|
||||
# 2. DIE ERWEITERTE EISENHOWER-MATRIX
|
||||
# ========================================
|
||||
|
||||
eisenhower_matrix:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 GRUNDSTRUKTUR
|
||||
# ----------------------------------
|
||||
|
||||
grundstruktur:
|
||||
beschreibung: "Die Matrix strukturiert Demands anhand zweier primärer Dimensionen"
|
||||
|
||||
dimension_y:
|
||||
name: "Wichtigkeit"
|
||||
beschreibung: "Der strategische und operative Wert des Demands"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Nutzen & Wirkung\""
|
||||
bewertet: "Langfristigen Beitrag zu Organisationszielen"
|
||||
|
||||
dimension_x:
|
||||
name: "Dringlichkeit"
|
||||
beschreibung: "Der zeitliche und situative Handlungsdruck"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Druck & Notwendigkeit\""
|
||||
bewertet: "Notwendigkeit zeitnaher Umsetzung"
|
||||
|
||||
einordnung: |
|
||||
Die Einordnung erfolgt nicht mechanisch über Schwellenwerte, sondern durch
|
||||
interpretative Zuordnung basierend auf den qualitativen Cluster-Bewertungen.
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 DIE VIER QUADRANTEN
|
||||
# ----------------------------------
|
||||
|
||||
quadranten:
|
||||
- quadrant_id: "q1"
|
||||
name: "Quadrant 1: Sofort angehen"
|
||||
achsen: "Wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Handlungsdruck bei gleichzeitig hoher strategischer Relevanz"
|
||||
- "Kritische Abhängigkeiten oder externe Anforderungen"
|
||||
- "Signifikante Risiken bei Verzögerung"
|
||||
- "Unmittelbare Auswirkungen auf Kernprozesse"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Regulatorische Vorgaben mit festen Fristen"
|
||||
- "Sicherheitskritische Anforderungen"
|
||||
- "Ausfälle geschäftskritischer Systeme"
|
||||
- "Verbindliche politische Zusagen"
|
||||
|
||||
- quadrant_id: "q2"
|
||||
name: "Quadrant 2: Strategisch planen"
|
||||
achsen: "Wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Wertbeitrag ohne unmittelbaren Zeitdruck"
|
||||
- "Strukturverändernde Vorhaben mit Zukunftspotenzial"
|
||||
- "Befähigung für weitere Entwicklungsschritte"
|
||||
- "Nachhaltige Verbesserung der Leistungsfähigkeit"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "IT-Architekturmodernisierungen"
|
||||
- "Strategische Digitalisierungsinitiativen"
|
||||
- "Kompetenzaufbau und Befähigungsprojekte"
|
||||
- "Grundlegende Prozessoptimierungen"
|
||||
|
||||
- quadrant_id: "q3"
|
||||
name: "Quadrant 3: Effizient abarbeiten"
|
||||
achsen: "Nicht wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Zeitlicher Druck ohne strategische Bedeutung"
|
||||
- "Lokale oder temporäre Problemstellungen"
|
||||
- "Erfüllung operativer Notwendigkeiten"
|
||||
- "Vermeidung kurzfristiger Störungen"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Kleinere Compliance-Anpassungen"
|
||||
- "Behebung operativer Engpässe"
|
||||
- "Erfüllung von Einzelanfragen mit Terminvorgabe"
|
||||
- "Technische Wartungsarbeiten"
|
||||
|
||||
- quadrant_id: "q4"
|
||||
name: "Quadrant 4: Kritisch prüfen"
|
||||
achsen: "Nicht wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Geringer Wertbeitrag ohne Handlungsdruck"
|
||||
- "Isolierte Verbesserungswünsche"
|
||||
- "Optionale Erweiterungen"
|
||||
- "Unclear Business Case"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Nice-to-have Features"
|
||||
- "Einzelinteressen ohne breiten Nutzen"
|
||||
- "Technologiegetriebene Experimente"
|
||||
- "Redundante Anforderungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.3 DRITTE DIMENSION: FARBCODIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
farbcodierung:
|
||||
beschreibung: |
|
||||
Die Farbcodierung visualisiert die Umsetzungskomplexität basierend auf dem
|
||||
Cluster-Fazit "Machbarkeit & Aufwand". Sie erfolgt durch qualitative Interpretation.
|
||||
|
||||
ableitung: "Aus Cluster 3: Machbarkeit & Aufwand"
|
||||
|
||||
farben:
|
||||
- farbe: "gruen"
|
||||
symbol: "🟢"
|
||||
name: "Grün - Gut machbar"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt keine kritischen Hindernisse. Die Umsetzung ist
|
||||
mit vorhandenen Mitteln und etablierten Vorgehensweisen möglich.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch mit Bordmitteln umsetzbar, Organisation vorbereitet, Ressourcen im Rahmen"
|
||||
- "Bewährte Lösungsansätze vorhanden, moderate Komplexität, gute Akzeptanz erwartet"
|
||||
|
||||
- farbe: "gelb"
|
||||
symbol: "🟡"
|
||||
name: "Gelb - Herausfordernd"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit identifiziert überwindbare Hürden. Die Umsetzung erfordert
|
||||
zusätzlichen Aufwand, besondere Koordination oder externe Unterstützung.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch machbar aber komplex, erhöhter Koordinationsaufwand, Ressourcen knapp"
|
||||
- "Neue Technologie erforderlich, Change-Management notwendig, externe Expertise benötigt"
|
||||
|
||||
- farbe: "rot"
|
||||
symbol: "🔴"
|
||||
name: "Rot - Kritisch"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt fundamentale Hindernisse. Mindestens ein Aspekt wirkt
|
||||
blockierend (Dominanz-Prinzip) oder die Gesamtkonstellation ist hochproblematisch.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technologie noch nicht ausgereift, massive organisatorische Widerstände, Ressourcen nicht darstellbar"
|
||||
- "Grundlegende Architekturprobleme, fehlendes Know-how, prohibitive Kosten"
|
||||
|
||||
# ========================================
|
||||
# 3. HANDLUNGSSTRATEGIEN
|
||||
# ========================================
|
||||
|
||||
handlungsstrategien:
|
||||
beschreibung: |
|
||||
Die Kombination aus Quadrant (Was ist zu tun?) und Farbe (Wie komplex ist es?)
|
||||
bestimmt die spezifische Handlungsstrategie.
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 1: SOFORT ANGEHEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_1_strategien:
|
||||
quadrant: "q1"
|
||||
name: "Sofort angehen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direkte Aufbereitung für DSR-Entscheidung"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Sprint-Organisation mit dediziertem Team"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Identifikation kritischer Erfolgsfaktoren und Risiken"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Task-Force mit Expertenbeteiligung und engem Monitoring"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Sofortige Eskalation mit Lösungsoptionen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Krisenstab unter Führungsebene mit externen Ressourcen"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 2: STRATEGISCH PLANEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_2_strategien:
|
||||
quadrant: "q2"
|
||||
name: "Strategisch planen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Integration in Quartalsplanung vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Aufnahme in kurzfristige Roadmap"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Initiierung einer Machbarkeitsstudie empfehlen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Mittelfristige Planung mit Vorbereitungsphase"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Grundlagenanalyse und Transformationsplan anregen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Langfriststrategie mit fundamentalen Vorarbeiten"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 3: EFFIZIENT ABARBEITEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_3_strategien:
|
||||
quadrant: "q3"
|
||||
name: "Effizient abarbeiten"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direktzuweisung an operative Teams vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Delegation mit Standardvorgehen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Alternative Lösungswege aufzeigen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Pragmatische Alternativlösung oder Workaround"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Notwendigkeit grundsätzlich hinterfragen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Ablehnung oder Verschiebung nach Q4"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 4: KRITISCH PRÜFEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_4_strategien:
|
||||
quadrant: "q4"
|
||||
name: "Kritisch prüfen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "In Backlog aufnehmen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Bei Kapazitäten als Lernprojekt nutzen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Periodische Neubewertung vorsehen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Zurückstellung mit jährlicher Überprüfung"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Ablehnungsempfehlung vorbereiten"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Definitive Ablehnung aus Portfoliosicht"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
prozess:
|
||||
schritt_1:
|
||||
name: "Ableitung der Dimensionen"
|
||||
aktivitaeten:
|
||||
- dimension: "wichtigkeit"
|
||||
quelle: "Cluster \"Nutzen & Wirkung\""
|
||||
- dimension: "dringlichkeit"
|
||||
quelle: "Cluster \"Druck & Notwendigkeit\""
|
||||
- dimension: "farbe"
|
||||
quelle: "Cluster \"Machbarkeit & Aufwand\""
|
||||
|
||||
schritt_2:
|
||||
name: "Qualitative Einordnung"
|
||||
aktivitaeten:
|
||||
- "Interpretation der Cluster-Fazits"
|
||||
- "Keine mechanische Punkteaggregation"
|
||||
- "Begründete Zuordnung zu Quadranten und Farbe"
|
||||
|
||||
schritt_3:
|
||||
name: "Strategieableitung"
|
||||
aktivitaeten:
|
||||
- "Handlungsempfehlung gemäß Matrix"
|
||||
- "Berücksichtigung der Farbcodierung"
|
||||
- "Anpassung an organisatorischen Kontext"
|
||||
|
||||
schritt_4:
|
||||
name: "Dokumentation"
|
||||
aktivitaeten:
|
||||
- "Transparente Darstellung der Einordnung"
|
||||
- "Nachvollziehbare Begründung"
|
||||
- "Klare Handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATIONSSTANDARD
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 PRIORISIERUNGSDOKUMENTATION
|
||||
# ----------------------------------
|
||||
|
||||
priorisierungsdokumentation:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
PRIORISIERUNG:
|
||||
|
||||
Wichtigkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 1]
|
||||
|
||||
Dringlichkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 2]
|
||||
|
||||
Machbarkeit: [Ausprägung] + [Ampel]
|
||||
Begründung: [Basierend auf Cluster 3]
|
||||
|
||||
Einordnung: [Quadrant]
|
||||
|
||||
HANDLUNGSEMPFEHLUNG:
|
||||
|
||||
DPM-Aktion: [Was tut der DPM]
|
||||
|
||||
Gremienempfehlung: [Was empfiehlt der DPM]
|
||||
|
||||
Nächste Schritte: [Konkrete Maßnahmen]
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 DEMAND-PORTFOLIO-ÜBERSICHT
|
||||
# ----------------------------------
|
||||
|
||||
portfolio_dashboard:
|
||||
beschreibung: "Aggregierte Darstellung für DSR/MB"
|
||||
|
||||
template_struktur: |
|
||||
DEMAND-PORTFOLIO DASHBOARD
|
||||
|
||||
Quadrant 🟢 🟡 🔴 Gesamt Hinweise
|
||||
-------------------------------------------------------
|
||||
Q1 Sofort 2 1 1 4 ! Rot → MB-Delegation
|
||||
Q2 Planen 3 2 0 5 ✓ Ausgewogen
|
||||
Q3 Abarbeiten 4 1 0 5 ✓ Gut delegierbar
|
||||
Q4 Prüfen 1 1 2 4 ! Rote ablehnen
|
||||
-------------------------------------------------------
|
||||
Gesamt: 10 5 3 18
|
||||
|
||||
interpretation:
|
||||
gruen_dominant: "Gut umsetzbare Demands dominieren - positive Portfoliogesundheit"
|
||||
gelb_haeufung: "Viele Herausforderungen - Ressourcenplanung kritisch"
|
||||
rot_in_q1: "Kritische Demands mit Druck - MB-Eskalation prüfen"
|
||||
rot_in_q4: "Eindeutige Ablehnungskandidaten"
|
||||
|
||||
# ========================================
|
||||
# VISUALISIERUNG FÜR GREMIEN
|
||||
# ========================================
|
||||
|
||||
visualisierung:
|
||||
hinweis: "Die Matrix wird typischerweise als 2x2-Grid mit farbigen Punkten für Demands visualisiert"
|
||||
|
||||
best_practices:
|
||||
- "Demands als Punkte mit Beschriftung in der Matrix platzieren"
|
||||
- "Farbcodierung für schnelle Erfassung der Machbarkeit"
|
||||
- "Clustering ähnlicher Demands erkennbar machen"
|
||||
meta:
|
||||
typ: "priorisierungsmethodik"
|
||||
methode: "demand_priorisierung"
|
||||
titel: "Priorisierungsverfahren im Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf: "#01.4_methodik/demand-bewertung.yaml"
|
||||
erzeugt: "handlungsempfehlungen_fuer_gremien"
|
||||
|
||||
kontext_tags:
|
||||
- "priorisierung"
|
||||
- "eisenhower-matrix"
|
||||
- "handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND FUNKTION
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Das Priorisierungsverfahren bildet den finalen Schritt der Demand-Bewertung
|
||||
und überführt die qualitative Analyse in konkrete Handlungsempfehlungen.
|
||||
|
||||
funktionen:
|
||||
- "Entscheidungsvorbereitung: Strukturierte Aufbereitung für Gremienentscheidungen"
|
||||
- "Ressourcenoptimierung: Fokussierung auf die wirkungsvollsten Demands bei begrenzten Kapazitäten"
|
||||
- "Transparenz: Nachvollziehbare Darstellung von Prioritäten für alle Stakeholder"
|
||||
- "Handlungsorientierung: Klare Strategien für unterschiedliche Demand-Typen"
|
||||
|
||||
methodik: |
|
||||
Die Priorisierung erfolgt mittels einer erweiterten Eisenhower-Matrix, die
|
||||
durch eine Farbcodierung zur Entscheidungsgrundlage wird.
|
||||
|
||||
# ========================================
|
||||
# 2. DIE ERWEITERTE EISENHOWER-MATRIX
|
||||
# ========================================
|
||||
|
||||
eisenhower_matrix:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 GRUNDSTRUKTUR
|
||||
# ----------------------------------
|
||||
|
||||
grundstruktur:
|
||||
beschreibung: "Die Matrix strukturiert Demands anhand zweier primärer Dimensionen"
|
||||
|
||||
dimension_y:
|
||||
name: "Wichtigkeit"
|
||||
beschreibung: "Der strategische und operative Wert des Demands"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Nutzen & Wirkung\""
|
||||
bewertet: "Langfristigen Beitrag zu Organisationszielen"
|
||||
|
||||
dimension_x:
|
||||
name: "Dringlichkeit"
|
||||
beschreibung: "Der zeitliche und situative Handlungsdruck"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Druck & Notwendigkeit\""
|
||||
bewertet: "Notwendigkeit zeitnaher Umsetzung"
|
||||
|
||||
einordnung: |
|
||||
Die Einordnung erfolgt nicht mechanisch über Schwellenwerte, sondern durch
|
||||
interpretative Zuordnung basierend auf den qualitativen Cluster-Bewertungen.
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 DIE VIER QUADRANTEN
|
||||
# ----------------------------------
|
||||
|
||||
quadranten:
|
||||
- quadrant_id: "q1"
|
||||
name: "Quadrant 1: Sofort angehen"
|
||||
achsen: "Wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Handlungsdruck bei gleichzeitig hoher strategischer Relevanz"
|
||||
- "Kritische Abhängigkeiten oder externe Anforderungen"
|
||||
- "Signifikante Risiken bei Verzögerung"
|
||||
- "Unmittelbare Auswirkungen auf Kernprozesse"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Regulatorische Vorgaben mit festen Fristen"
|
||||
- "Sicherheitskritische Anforderungen"
|
||||
- "Ausfälle geschäftskritischer Systeme"
|
||||
- "Verbindliche politische Zusagen"
|
||||
|
||||
- quadrant_id: "q2"
|
||||
name: "Quadrant 2: Strategisch planen"
|
||||
achsen: "Wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Wertbeitrag ohne unmittelbaren Zeitdruck"
|
||||
- "Strukturverändernde Vorhaben mit Zukunftspotenzial"
|
||||
- "Befähigung für weitere Entwicklungsschritte"
|
||||
- "Nachhaltige Verbesserung der Leistungsfähigkeit"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "IT-Architekturmodernisierungen"
|
||||
- "Strategische Digitalisierungsinitiativen"
|
||||
- "Kompetenzaufbau und Befähigungsprojekte"
|
||||
- "Grundlegende Prozessoptimierungen"
|
||||
|
||||
- quadrant_id: "q3"
|
||||
name: "Quadrant 3: Effizient abarbeiten"
|
||||
achsen: "Nicht wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Zeitlicher Druck ohne strategische Bedeutung"
|
||||
- "Lokale oder temporäre Problemstellungen"
|
||||
- "Erfüllung operativer Notwendigkeiten"
|
||||
- "Vermeidung kurzfristiger Störungen"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Kleinere Compliance-Anpassungen"
|
||||
- "Behebung operativer Engpässe"
|
||||
- "Erfüllung von Einzelanfragen mit Terminvorgabe"
|
||||
- "Technische Wartungsarbeiten"
|
||||
|
||||
- quadrant_id: "q4"
|
||||
name: "Quadrant 4: Kritisch prüfen"
|
||||
achsen: "Nicht wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Geringer Wertbeitrag ohne Handlungsdruck"
|
||||
- "Isolierte Verbesserungswünsche"
|
||||
- "Optionale Erweiterungen"
|
||||
- "Unclear Business Case"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Nice-to-have Features"
|
||||
- "Einzelinteressen ohne breiten Nutzen"
|
||||
- "Technologiegetriebene Experimente"
|
||||
- "Redundante Anforderungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.3 DRITTE DIMENSION: FARBCODIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
farbcodierung:
|
||||
beschreibung: |
|
||||
Die Farbcodierung visualisiert die Umsetzungskomplexität basierend auf dem
|
||||
Cluster-Fazit "Machbarkeit & Aufwand". Sie erfolgt durch qualitative Interpretation.
|
||||
|
||||
ableitung: "Aus Cluster 3: Machbarkeit & Aufwand"
|
||||
|
||||
farben:
|
||||
- farbe: "gruen"
|
||||
symbol: "🟢"
|
||||
name: "Grün - Gut machbar"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt keine kritischen Hindernisse. Die Umsetzung ist
|
||||
mit vorhandenen Mitteln und etablierten Vorgehensweisen möglich.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch mit Bordmitteln umsetzbar, Organisation vorbereitet, Ressourcen im Rahmen"
|
||||
- "Bewährte Lösungsansätze vorhanden, moderate Komplexität, gute Akzeptanz erwartet"
|
||||
|
||||
- farbe: "gelb"
|
||||
symbol: "🟡"
|
||||
name: "Gelb - Herausfordernd"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit identifiziert überwindbare Hürden. Die Umsetzung erfordert
|
||||
zusätzlichen Aufwand, besondere Koordination oder externe Unterstützung.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch machbar aber komplex, erhöhter Koordinationsaufwand, Ressourcen knapp"
|
||||
- "Neue Technologie erforderlich, Change-Management notwendig, externe Expertise benötigt"
|
||||
|
||||
- farbe: "rot"
|
||||
symbol: "🔴"
|
||||
name: "Rot - Kritisch"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt fundamentale Hindernisse. Mindestens ein Aspekt wirkt
|
||||
blockierend (Dominanz-Prinzip) oder die Gesamtkonstellation ist hochproblematisch.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technologie noch nicht ausgereift, massive organisatorische Widerstände, Ressourcen nicht darstellbar"
|
||||
- "Grundlegende Architekturprobleme, fehlendes Know-how, prohibitive Kosten"
|
||||
|
||||
# ========================================
|
||||
# 3. HANDLUNGSSTRATEGIEN
|
||||
# ========================================
|
||||
|
||||
handlungsstrategien:
|
||||
beschreibung: |
|
||||
Die Kombination aus Quadrant (Was ist zu tun?) und Farbe (Wie komplex ist es?)
|
||||
bestimmt die spezifische Handlungsstrategie.
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 1: SOFORT ANGEHEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_1_strategien:
|
||||
quadrant: "q1"
|
||||
name: "Sofort angehen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direkte Aufbereitung für DSR-Entscheidung"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Sprint-Organisation mit dediziertem Team"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Identifikation kritischer Erfolgsfaktoren und Risiken"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Task-Force mit Expertenbeteiligung und engem Monitoring"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Sofortige Eskalation mit Lösungsoptionen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Krisenstab unter Führungsebene mit externen Ressourcen"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 2: STRATEGISCH PLANEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_2_strategien:
|
||||
quadrant: "q2"
|
||||
name: "Strategisch planen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Integration in Quartalsplanung vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Aufnahme in kurzfristige Roadmap"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Initiierung einer Machbarkeitsstudie empfehlen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Mittelfristige Planung mit Vorbereitungsphase"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Grundlagenanalyse und Transformationsplan anregen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Langfriststrategie mit fundamentalen Vorarbeiten"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 3: EFFIZIENT ABARBEITEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_3_strategien:
|
||||
quadrant: "q3"
|
||||
name: "Effizient abarbeiten"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direktzuweisung an operative Teams vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Delegation mit Standardvorgehen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Alternative Lösungswege aufzeigen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Pragmatische Alternativlösung oder Workaround"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Notwendigkeit grundsätzlich hinterfragen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Ablehnung oder Verschiebung nach Q4"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 4: KRITISCH PRÜFEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_4_strategien:
|
||||
quadrant: "q4"
|
||||
name: "Kritisch prüfen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "In Backlog aufnehmen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Bei Kapazitäten als Lernprojekt nutzen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Periodische Neubewertung vorsehen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Zurückstellung mit jährlicher Überprüfung"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Ablehnungsempfehlung vorbereiten"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Definitive Ablehnung aus Portfoliosicht"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
prozess:
|
||||
schritt_1:
|
||||
name: "Ableitung der Dimensionen"
|
||||
aktivitaeten:
|
||||
- dimension: "wichtigkeit"
|
||||
quelle: "Cluster \"Nutzen & Wirkung\""
|
||||
- dimension: "dringlichkeit"
|
||||
quelle: "Cluster \"Druck & Notwendigkeit\""
|
||||
- dimension: "farbe"
|
||||
quelle: "Cluster \"Machbarkeit & Aufwand\""
|
||||
|
||||
schritt_2:
|
||||
name: "Qualitative Einordnung"
|
||||
aktivitaeten:
|
||||
- "Interpretation der Cluster-Fazits"
|
||||
- "Keine mechanische Punkteaggregation"
|
||||
- "Begründete Zuordnung zu Quadranten und Farbe"
|
||||
|
||||
schritt_3:
|
||||
name: "Strategieableitung"
|
||||
aktivitaeten:
|
||||
- "Handlungsempfehlung gemäß Matrix"
|
||||
- "Berücksichtigung der Farbcodierung"
|
||||
- "Anpassung an organisatorischen Kontext"
|
||||
|
||||
schritt_4:
|
||||
name: "Dokumentation"
|
||||
aktivitaeten:
|
||||
- "Transparente Darstellung der Einordnung"
|
||||
- "Nachvollziehbare Begründung"
|
||||
- "Klare Handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATIONSSTANDARD
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 PRIORISIERUNGSDOKUMENTATION
|
||||
# ----------------------------------
|
||||
|
||||
priorisierungsdokumentation:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
PRIORISIERUNG:
|
||||
|
||||
Wichtigkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 1]
|
||||
|
||||
Dringlichkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 2]
|
||||
|
||||
Machbarkeit: [Ausprägung] + [Ampel]
|
||||
Begründung: [Basierend auf Cluster 3]
|
||||
|
||||
Einordnung: [Quadrant]
|
||||
|
||||
HANDLUNGSEMPFEHLUNG:
|
||||
|
||||
DPM-Aktion: [Was tut der DPM]
|
||||
|
||||
Gremienempfehlung: [Was empfiehlt der DPM]
|
||||
|
||||
Nächste Schritte: [Konkrete Maßnahmen]
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 DEMAND-PORTFOLIO-ÜBERSICHT
|
||||
# ----------------------------------
|
||||
|
||||
portfolio_dashboard:
|
||||
beschreibung: "Aggregierte Darstellung für DSR/MB"
|
||||
|
||||
template_struktur: |
|
||||
DEMAND-PORTFOLIO DASHBOARD
|
||||
|
||||
Quadrant 🟢 🟡 🔴 Gesamt Hinweise
|
||||
-------------------------------------------------------
|
||||
Q1 Sofort 2 1 1 4 ! Rot → MB-Delegation
|
||||
Q2 Planen 3 2 0 5 ✓ Ausgewogen
|
||||
Q3 Abarbeiten 4 1 0 5 ✓ Gut delegierbar
|
||||
Q4 Prüfen 1 1 2 4 ! Rote ablehnen
|
||||
-------------------------------------------------------
|
||||
Gesamt: 10 5 3 18
|
||||
|
||||
interpretation:
|
||||
gruen_dominant: "Gut umsetzbare Demands dominieren - positive Portfoliogesundheit"
|
||||
gelb_haeufung: "Viele Herausforderungen - Ressourcenplanung kritisch"
|
||||
rot_in_q1: "Kritische Demands mit Druck - MB-Eskalation prüfen"
|
||||
rot_in_q4: "Eindeutige Ablehnungskandidaten"
|
||||
|
||||
# ========================================
|
||||
# VISUALISIERUNG FÜR GREMIEN
|
||||
# ========================================
|
||||
|
||||
visualisierung:
|
||||
hinweis: "Die Matrix wird typischerweise als 2x2-Grid mit farbigen Punkten für Demands visualisiert"
|
||||
|
||||
best_practices:
|
||||
- "Demands als Punkte mit Beschriftung in der Matrix platzieren"
|
||||
- "Farbcodierung für schnelle Erfassung der Machbarkeit"
|
||||
- "Clustering ähnlicher Demands erkennbar machen"
|
||||
- "Bewegung von Demands zwischen Quadranten im Zeitverlauf zeigen"
|
||||
|
|
@ -1,401 +1,401 @@
|
|||
meta:
|
||||
typ: "geschaeftsordnung"
|
||||
gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
aliases: ["DSR", "Demand-Runde", "Stakeholder-Runde"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
abstimmung:
|
||||
sparring_mit: ["shm", "spm"]
|
||||
abgestimmt_mit: ["DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "governance"
|
||||
- "entscheidungsgremium"
|
||||
- "demand-lifecycle"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
verankerung: "Steuerungs- und Entscheidungsgremium im DIGITOM"
|
||||
|
||||
funktion: |
|
||||
Brücke zwischen Bedarfserfassung (Stakeholder-Management) und
|
||||
Projektinitiierung (Projekt-Portfolio-Management).
|
||||
|
||||
regelungsumfang:
|
||||
- "Arbeitsweise der DSR"
|
||||
- "Entscheidungsverfahren"
|
||||
- "Schnittstellen im Demand-Lifecycle"
|
||||
|
||||
geltungsbereich:
|
||||
inkludiert:
|
||||
- typ: "DSR-Demands"
|
||||
beschreibung: "Demands ohne automatische MB-Trigger gemäß Demand-Klassifizierung"
|
||||
|
||||
- typ: "DSR-Demands mit Delegationsoption"
|
||||
beschreibung: "Demands mit Option zur Delegation ans Mission Board"
|
||||
|
||||
rolle_bei_mb_demands: "vorbereitendes und empfehlendes Gremium"
|
||||
|
||||
# ========================================
|
||||
# 2. AUFGABEN UND KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
aufgaben:
|
||||
charakter: "hybrides Gremium mit zwei Funktionsbereichen"
|
||||
|
||||
entscheidungsfunktion:
|
||||
gueltig_fuer: "DSR-Demands"
|
||||
|
||||
entscheidungsoptionen:
|
||||
- option: "freigabe_zur_umsetzung"
|
||||
beschreibung: "Freigabe zur Umsetzungsplanung und Übergabe an PPM"
|
||||
naechster_schritt: "Projekt-Initiierung durch PPM"
|
||||
|
||||
- option: "ablehnung"
|
||||
beschreibung: "Ablehnung und Weitergabe ans SHM für Stakeholder-Kommunikation"
|
||||
naechster_schritt: "SHM kommuniziert Ablehnung"
|
||||
|
||||
- option: "delegation_mission_board"
|
||||
trigger: ["strategische_relevanz", "kompetenzueberschreitung"]
|
||||
beschreibung: "Delegation ans Mission Board"
|
||||
naechster_schritt: "Mission Board entscheidet"
|
||||
|
||||
- option: "vertagung_fehlende_grundlagen"
|
||||
trigger: "fehlende_entscheidungsgrundlagen"
|
||||
beschreibung: "Weitere Aufarbeitung durch DPM erforderlich"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- option: "vertagung_einwand"
|
||||
trigger: "begruendeter_einwand"
|
||||
beschreibung: "Weitere Aufarbeitung durch einwendende Rolle (Konsent-Prinzip)"
|
||||
verantwortlich: "einwendende_rolle"
|
||||
|
||||
informations_und_abstimmungsfunktion:
|
||||
aktivitaeten:
|
||||
- name: "Informationsaustausch"
|
||||
gegenstand:
|
||||
- "offene Demands"
|
||||
- "laufende Projekte (durch DSR freigegeben)"
|
||||
|
||||
- name: "Abstimmung"
|
||||
themen:
|
||||
- "Abhängigkeiten zwischen Demands/Projekten"
|
||||
- "Ressourcen-Bedarfe für DSR-freigegebene Projekte"
|
||||
|
||||
# ========================================
|
||||
# 3. ZUSAMMENSETZUNG
|
||||
# ========================================
|
||||
|
||||
zusammensetzung:
|
||||
stimmberechtigte_mitglieder:
|
||||
anzahl: 4
|
||||
|
||||
rationale: |
|
||||
Vollständiger Demand-Lifecycle abgebildet: Bedarfserfassung (SHM) →
|
||||
Qualifizierung (DPM) → Service-Impact-Analyse (SPM) → Projekt-Integration (PPM)
|
||||
|
||||
mitglieder:
|
||||
- rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Management"
|
||||
funktion: "vorsitz"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
vertretungsregelung:
|
||||
flexibel: true
|
||||
beschreibung: "Mitglieder benennen ihre Vertretungen flexibel"
|
||||
vertretungs_kompetenzen: "Vertretungen sind stimmberechtigt und haben volle Kompetenzen der vertretenen Rolle"
|
||||
|
||||
zusaetzliche_teilnehmende:
|
||||
erlaubt: true
|
||||
status: "beratend"
|
||||
stimmberechtigt: false
|
||||
|
||||
typische_teilnehmende:
|
||||
- "Owner betroffener Services"
|
||||
- "Owner betroffener Produkte"
|
||||
- "Owner betroffener Infrastruktur-Komponenten"
|
||||
- "Fachexperten (z.B. IT-Architektur)"
|
||||
|
||||
einladung_durch: "dpm"
|
||||
|
||||
# ========================================
|
||||
# 4. ARBEITSWEISE
|
||||
# ========================================
|
||||
|
||||
arbeitsweise:
|
||||
sitzungsrhythmus:
|
||||
pilotphase:
|
||||
frequenz: "woechentlich"
|
||||
termin: "fester Termin"
|
||||
dauer_minuten: 90
|
||||
|
||||
regelzeit:
|
||||
hinweis: "wird nach Pilotphase definiert"
|
||||
|
||||
sondersitzungen:
|
||||
erfragen_durch: "jedes Mitglied"
|
||||
einberufung_durch: "dpm"
|
||||
|
||||
vorbereitung_und_dokumentation:
|
||||
vorbereitung:
|
||||
verantwortlich: "dpm"
|
||||
unterlagen_vorlauf_stunden: 24
|
||||
beschreibung: "Unterlagen müssen 24h vor Sitzung verfügbar sein"
|
||||
|
||||
protokollfuehrung:
|
||||
verantwortlich: "dpm"
|
||||
typ: "Entscheidungsprotokoll"
|
||||
basis: "Demand-Portfolio-Übersicht"
|
||||
|
||||
ablage:
|
||||
ort: "Confluence"
|
||||
zugriff: "DIGIT-weit"
|
||||
|
||||
kommunikation:
|
||||
timing: "unmittelbar nach Sitzung"
|
||||
gegenstand: "Entscheidungen werden kommuniziert"
|
||||
|
||||
agenda_struktur:
|
||||
referenz: "dsr-standard-agenda.yaml"
|
||||
hinweis: "Detaillierte Agenda-Struktur in separatem Dokument definiert"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSVERFAHREN
|
||||
# ========================================
|
||||
|
||||
entscheidungsverfahren:
|
||||
prinzip: "konsent_mit_alternativzwang"
|
||||
|
||||
konsent_ablauf:
|
||||
schritt_1:
|
||||
name: "Vorschlag einbringen"
|
||||
akteur: "dpm"
|
||||
inhalt: "DPM bringt Entscheidungsvorschlag ein"
|
||||
|
||||
schritt_2:
|
||||
name: "Verständnisfragen klären"
|
||||
bedingung: "sofern vorhanden"
|
||||
|
||||
schritt_3:
|
||||
name: "Einwände prüfen"
|
||||
regel: "Ohne schwerwiegenden, begründeten Einwand gilt Vorschlag als angenommen"
|
||||
|
||||
bei_einwand:
|
||||
verantwortung: "einwendende Rolle"
|
||||
verpflichtung: "muss Entscheidungsvorlage überarbeiten und konstruktive Alternative einbringen"
|
||||
|
||||
bei_mehreren_einwaenden:
|
||||
prozess: "gemeinsame Erarbeitung des Alternativ-Vorschlags"
|
||||
|
||||
iteratives_verfahren:
|
||||
beschreibung: "Überarbeitete Entscheidungsvorlage unterliegt selbst wieder dem Konsent-Prinzip"
|
||||
|
||||
eskalation:
|
||||
trigger: "nach zwei Iterationen ohne Einigung (bei drittem Einwand)"
|
||||
option: "DPM kann ans Mission Board eskalieren"
|
||||
|
||||
beschlussfaehigkeit:
|
||||
bedingung: "alle vier Rollen durch Mitglieder oder Vertretungen besetzt"
|
||||
|
||||
entscheidungen_unter_auflagen:
|
||||
erlaubt: true
|
||||
beschreibung: "DSR kann Demands unter Auflagen freigeben"
|
||||
status: "verbindlicher Teil des Beschlusses"
|
||||
|
||||
erfuellung:
|
||||
zeitpunkt: "vor/während der Umsetzung"
|
||||
ueberwachung_durch: "ppm"
|
||||
|
||||
bei_nicht_erfuellung:
|
||||
massnahme: "Umsetzung stoppen"
|
||||
naechster_schritt: "Vorlage an DSR zur Neuentscheidung"
|
||||
|
||||
virtuelle_hybride_asynchrone:
|
||||
virtuell_hybrid:
|
||||
status: "gleichwertig zu Präsenzsitzungen"
|
||||
|
||||
asynchron:
|
||||
status: "in Entwicklung"
|
||||
hinweis: "Werden bei Bedarf während Pilotphase entwickelt und getestet"
|
||||
moegliche_mechanismen:
|
||||
- "Kommentierungsfunktion"
|
||||
- "Voting"
|
||||
|
||||
entscheidungsvarianten_nach_demand_typ:
|
||||
mb_demand:
|
||||
beschreibung: "Mission Board-Demand (wird durch DSR vorbereitet)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung"
|
||||
|
||||
dsr_demand_mit_delegation:
|
||||
beschreibung: "DSR-Demand mit Delegationsoption ans Mission Board"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Delegationsempfehlung/Begründung"
|
||||
|
||||
dsr_demand:
|
||||
beschreibung: "DSR-Demand (DSR entscheidet final)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung: Freigabe oder Ablehnung"
|
||||
|
||||
# ========================================
|
||||
# 6. RESSOURCENMOBILISIERUNG UND PROJEKTUMSETZUNG
|
||||
# ========================================
|
||||
|
||||
ressourcenmobilisierung:
|
||||
beschreibung: "Prozess nach Freigabe eines DSR-Demands"
|
||||
|
||||
projektinitiierung:
|
||||
schritt_1:
|
||||
name: "Projekt-Aufnahme"
|
||||
beschreibung: "Demand wird formal als Projekt ins Projekt-Portfolio aufgenommen"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
schritt_2:
|
||||
name: "Sponsoring"
|
||||
regelfall: "SPM übernimmt Sponsor:innen-Rolle bei service-/produkt-/infrastrukturbezogenen DSR-Demands"
|
||||
verantwortlich: "spm"
|
||||
|
||||
projektleitung_und_ressourcen:
|
||||
projektleitung_benennung:
|
||||
verantwortlich: "spm"
|
||||
prozess: "SPM benennt abgestimmte Projektleitung und meldet an PPM"
|
||||
regelfall: "Owner des betroffenen Services/Produkts wird Projektleitung"
|
||||
|
||||
scope_definition:
|
||||
verantwortlich: ["spm", "projektleitung"]
|
||||
prozess: "SPM definiert gemeinsam mit Projektleitung den Scope"
|
||||
|
||||
ressourcenmobilisierung:
|
||||
verantwortlich: "projektleitung"
|
||||
prozess: "Projektleitung mobilisiert Ressourcen"
|
||||
|
||||
bei_konflikten:
|
||||
eskalation_ueber: "ppm_oder_spm"
|
||||
eskalation_an: "dsr"
|
||||
weitere_eskalation_moeglich_an: "mission_board"
|
||||
|
||||
monitoring_und_steuerung:
|
||||
projekt_monitoring:
|
||||
verantwortlich: "ppm"
|
||||
umfang: "alle Projekte im Portfolio"
|
||||
|
||||
status_reporting:
|
||||
von: "ppm"
|
||||
an: "dsr"
|
||||
frequenz: "regelmäßig"
|
||||
gegenstand: "Projekte, die durch DSR beauftragt wurden"
|
||||
|
||||
bei_konflikten:
|
||||
inhaltliche_konflikte:
|
||||
klaerung_in: "dsr"
|
||||
eskalation_moeglich_an: "mission_board"
|
||||
|
||||
projektabschluss:
|
||||
inhaltliche_abnahme:
|
||||
verantwortlich: "spm"
|
||||
|
||||
formaler_abschluss:
|
||||
verantwortlich: "ppm"
|
||||
prozess: "Projekt formal im Portfolio schließen"
|
||||
|
||||
# ========================================
|
||||
# 7. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
- ausloeser: "DSR Freigabe (DSR-Demand)"
|
||||
von: "dsr"
|
||||
zu: "ppm"
|
||||
zweck: "Projektaufnahme, Umsetzung starten"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
- "Auflagen"
|
||||
verantwortlich: ["dpm", "ppm"]
|
||||
|
||||
- ausloeser: "Service-Betroffenheit, Sponsoring & Owner-Einbindung"
|
||||
zwischen: ["dsr", "spm"]
|
||||
art: "bidirektional"
|
||||
zweck: "Sponsoring, Owner-Einbindung"
|
||||
artefakte:
|
||||
- "Protokoll"
|
||||
- "Owner-Liste"
|
||||
verantwortlich: "spm"
|
||||
|
||||
- ausloeser: "Delegation ans MB"
|
||||
von: "dsr"
|
||||
zu: "mission_board"
|
||||
zweck: "Strategische Entscheidung herbeiführen"
|
||||
artefakte:
|
||||
- "MB Vorlage"
|
||||
- "DSR Empfehlung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Rückmeldungen an Stakeholder"
|
||||
kontext: "Freigaben/Zurückstellungen mit Auflagen, Übergabe in Projekt-/Umsetzungssteuerung, Reporting"
|
||||
von: ["dsr", "ppm", "spm"]
|
||||
zu: "shm"
|
||||
zweck: "Entscheidung/Begründung kommunizieren"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
verantwortlich: "shm"
|
||||
|
||||
themen:
|
||||
- "Wiedervorlagen"
|
||||
- "Steckbrief-/User-Story-Bezug"
|
||||
|
||||
- ausloeser: "Architektur-Grundsatzfrage"
|
||||
von: "dsr"
|
||||
zu: "it_architektur_board"
|
||||
zweck: "Klärung technischer Leitplanken"
|
||||
artefakte:
|
||||
- "Kurzlage/Fragestellung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Projekt Reporting"
|
||||
von: "ppm"
|
||||
zu: ["dsr", "mission_board"]
|
||||
zweck: "Status, Risiken, Ressourcenlage kommunizieren"
|
||||
artefakte:
|
||||
- "Projekt-Portfolio Bericht"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
# ========================================
|
||||
# 8. KONFLIKTBEHANDLUNG
|
||||
# ========================================
|
||||
|
||||
konfliktbehandlung:
|
||||
regelung: "Verantwortlichkeiten in Konfliktsituationen sind in RACI-Matrix geregelt"
|
||||
meta:
|
||||
typ: "geschaeftsordnung"
|
||||
gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
aliases: ["DSR", "Demand-Runde", "Stakeholder-Runde"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
abstimmung:
|
||||
sparring_mit: ["shm", "spm"]
|
||||
abgestimmt_mit: ["DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "governance"
|
||||
- "entscheidungsgremium"
|
||||
- "demand-lifecycle"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
verankerung: "Steuerungs- und Entscheidungsgremium im DIGITOM"
|
||||
|
||||
funktion: |
|
||||
Brücke zwischen Bedarfserfassung (Stakeholder-Management) und
|
||||
Projektinitiierung (Projekt-Portfolio-Management).
|
||||
|
||||
regelungsumfang:
|
||||
- "Arbeitsweise der DSR"
|
||||
- "Entscheidungsverfahren"
|
||||
- "Schnittstellen im Demand-Lifecycle"
|
||||
|
||||
geltungsbereich:
|
||||
inkludiert:
|
||||
- typ: "DSR-Demands"
|
||||
beschreibung: "Demands ohne automatische MB-Trigger gemäß Demand-Klassifizierung"
|
||||
|
||||
- typ: "DSR-Demands mit Delegationsoption"
|
||||
beschreibung: "Demands mit Option zur Delegation ans Mission Board"
|
||||
|
||||
rolle_bei_mb_demands: "vorbereitendes und empfehlendes Gremium"
|
||||
|
||||
# ========================================
|
||||
# 2. AUFGABEN UND KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
aufgaben:
|
||||
charakter: "hybrides Gremium mit zwei Funktionsbereichen"
|
||||
|
||||
entscheidungsfunktion:
|
||||
gueltig_fuer: "DSR-Demands"
|
||||
|
||||
entscheidungsoptionen:
|
||||
- option: "freigabe_zur_umsetzung"
|
||||
beschreibung: "Freigabe zur Umsetzungsplanung und Übergabe an PPM"
|
||||
naechster_schritt: "Projekt-Initiierung durch PPM"
|
||||
|
||||
- option: "ablehnung"
|
||||
beschreibung: "Ablehnung und Weitergabe ans SHM für Stakeholder-Kommunikation"
|
||||
naechster_schritt: "SHM kommuniziert Ablehnung"
|
||||
|
||||
- option: "delegation_mission_board"
|
||||
trigger: ["strategische_relevanz", "kompetenzueberschreitung"]
|
||||
beschreibung: "Delegation ans Mission Board"
|
||||
naechster_schritt: "Mission Board entscheidet"
|
||||
|
||||
- option: "vertagung_fehlende_grundlagen"
|
||||
trigger: "fehlende_entscheidungsgrundlagen"
|
||||
beschreibung: "Weitere Aufarbeitung durch DPM erforderlich"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- option: "vertagung_einwand"
|
||||
trigger: "begruendeter_einwand"
|
||||
beschreibung: "Weitere Aufarbeitung durch einwendende Rolle (Konsent-Prinzip)"
|
||||
verantwortlich: "einwendende_rolle"
|
||||
|
||||
informations_und_abstimmungsfunktion:
|
||||
aktivitaeten:
|
||||
- name: "Informationsaustausch"
|
||||
gegenstand:
|
||||
- "offene Demands"
|
||||
- "laufende Projekte (durch DSR freigegeben)"
|
||||
|
||||
- name: "Abstimmung"
|
||||
themen:
|
||||
- "Abhängigkeiten zwischen Demands/Projekten"
|
||||
- "Ressourcen-Bedarfe für DSR-freigegebene Projekte"
|
||||
|
||||
# ========================================
|
||||
# 3. ZUSAMMENSETZUNG
|
||||
# ========================================
|
||||
|
||||
zusammensetzung:
|
||||
stimmberechtigte_mitglieder:
|
||||
anzahl: 4
|
||||
|
||||
rationale: |
|
||||
Vollständiger Demand-Lifecycle abgebildet: Bedarfserfassung (SHM) →
|
||||
Qualifizierung (DPM) → Service-Impact-Analyse (SPM) → Projekt-Integration (PPM)
|
||||
|
||||
mitglieder:
|
||||
- rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Management"
|
||||
funktion: "vorsitz"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
vertretungsregelung:
|
||||
flexibel: true
|
||||
beschreibung: "Mitglieder benennen ihre Vertretungen flexibel"
|
||||
vertretungs_kompetenzen: "Vertretungen sind stimmberechtigt und haben volle Kompetenzen der vertretenen Rolle"
|
||||
|
||||
zusaetzliche_teilnehmende:
|
||||
erlaubt: true
|
||||
status: "beratend"
|
||||
stimmberechtigt: false
|
||||
|
||||
typische_teilnehmende:
|
||||
- "Owner betroffener Services"
|
||||
- "Owner betroffener Produkte"
|
||||
- "Owner betroffener Infrastruktur-Komponenten"
|
||||
- "Fachexperten (z.B. IT-Architektur)"
|
||||
|
||||
einladung_durch: "dpm"
|
||||
|
||||
# ========================================
|
||||
# 4. ARBEITSWEISE
|
||||
# ========================================
|
||||
|
||||
arbeitsweise:
|
||||
sitzungsrhythmus:
|
||||
pilotphase:
|
||||
frequenz: "woechentlich"
|
||||
termin: "fester Termin"
|
||||
dauer_minuten: 90
|
||||
|
||||
regelzeit:
|
||||
hinweis: "wird nach Pilotphase definiert"
|
||||
|
||||
sondersitzungen:
|
||||
erfragen_durch: "jedes Mitglied"
|
||||
einberufung_durch: "dpm"
|
||||
|
||||
vorbereitung_und_dokumentation:
|
||||
vorbereitung:
|
||||
verantwortlich: "dpm"
|
||||
unterlagen_vorlauf_stunden: 24
|
||||
beschreibung: "Unterlagen müssen 24h vor Sitzung verfügbar sein"
|
||||
|
||||
protokollfuehrung:
|
||||
verantwortlich: "dpm"
|
||||
typ: "Entscheidungsprotokoll"
|
||||
basis: "Demand-Portfolio-Übersicht"
|
||||
|
||||
ablage:
|
||||
ort: "Confluence"
|
||||
zugriff: "DIGIT-weit"
|
||||
|
||||
kommunikation:
|
||||
timing: "unmittelbar nach Sitzung"
|
||||
gegenstand: "Entscheidungen werden kommuniziert"
|
||||
|
||||
agenda_struktur:
|
||||
referenz: "dsr-standard-agenda.yaml"
|
||||
hinweis: "Detaillierte Agenda-Struktur in separatem Dokument definiert"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSVERFAHREN
|
||||
# ========================================
|
||||
|
||||
entscheidungsverfahren:
|
||||
prinzip: "konsent_mit_alternativzwang"
|
||||
|
||||
konsent_ablauf:
|
||||
schritt_1:
|
||||
name: "Vorschlag einbringen"
|
||||
akteur: "dpm"
|
||||
inhalt: "DPM bringt Entscheidungsvorschlag ein"
|
||||
|
||||
schritt_2:
|
||||
name: "Verständnisfragen klären"
|
||||
bedingung: "sofern vorhanden"
|
||||
|
||||
schritt_3:
|
||||
name: "Einwände prüfen"
|
||||
regel: "Ohne schwerwiegenden, begründeten Einwand gilt Vorschlag als angenommen"
|
||||
|
||||
bei_einwand:
|
||||
verantwortung: "einwendende Rolle"
|
||||
verpflichtung: "muss Entscheidungsvorlage überarbeiten und konstruktive Alternative einbringen"
|
||||
|
||||
bei_mehreren_einwaenden:
|
||||
prozess: "gemeinsame Erarbeitung des Alternativ-Vorschlags"
|
||||
|
||||
iteratives_verfahren:
|
||||
beschreibung: "Überarbeitete Entscheidungsvorlage unterliegt selbst wieder dem Konsent-Prinzip"
|
||||
|
||||
eskalation:
|
||||
trigger: "nach zwei Iterationen ohne Einigung (bei drittem Einwand)"
|
||||
option: "DPM kann ans Mission Board eskalieren"
|
||||
|
||||
beschlussfaehigkeit:
|
||||
bedingung: "alle vier Rollen durch Mitglieder oder Vertretungen besetzt"
|
||||
|
||||
entscheidungen_unter_auflagen:
|
||||
erlaubt: true
|
||||
beschreibung: "DSR kann Demands unter Auflagen freigeben"
|
||||
status: "verbindlicher Teil des Beschlusses"
|
||||
|
||||
erfuellung:
|
||||
zeitpunkt: "vor/während der Umsetzung"
|
||||
ueberwachung_durch: "ppm"
|
||||
|
||||
bei_nicht_erfuellung:
|
||||
massnahme: "Umsetzung stoppen"
|
||||
naechster_schritt: "Vorlage an DSR zur Neuentscheidung"
|
||||
|
||||
virtuelle_hybride_asynchrone:
|
||||
virtuell_hybrid:
|
||||
status: "gleichwertig zu Präsenzsitzungen"
|
||||
|
||||
asynchron:
|
||||
status: "in Entwicklung"
|
||||
hinweis: "Werden bei Bedarf während Pilotphase entwickelt und getestet"
|
||||
moegliche_mechanismen:
|
||||
- "Kommentierungsfunktion"
|
||||
- "Voting"
|
||||
|
||||
entscheidungsvarianten_nach_demand_typ:
|
||||
mb_demand:
|
||||
beschreibung: "Mission Board-Demand (wird durch DSR vorbereitet)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung"
|
||||
|
||||
dsr_demand_mit_delegation:
|
||||
beschreibung: "DSR-Demand mit Delegationsoption ans Mission Board"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Delegationsempfehlung/Begründung"
|
||||
|
||||
dsr_demand:
|
||||
beschreibung: "DSR-Demand (DSR entscheidet final)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung: Freigabe oder Ablehnung"
|
||||
|
||||
# ========================================
|
||||
# 6. RESSOURCENMOBILISIERUNG UND PROJEKTUMSETZUNG
|
||||
# ========================================
|
||||
|
||||
ressourcenmobilisierung:
|
||||
beschreibung: "Prozess nach Freigabe eines DSR-Demands"
|
||||
|
||||
projektinitiierung:
|
||||
schritt_1:
|
||||
name: "Projekt-Aufnahme"
|
||||
beschreibung: "Demand wird formal als Projekt ins Projekt-Portfolio aufgenommen"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
schritt_2:
|
||||
name: "Sponsoring"
|
||||
regelfall: "SPM übernimmt Sponsor:innen-Rolle bei service-/produkt-/infrastrukturbezogenen DSR-Demands"
|
||||
verantwortlich: "spm"
|
||||
|
||||
projektleitung_und_ressourcen:
|
||||
projektleitung_benennung:
|
||||
verantwortlich: "spm"
|
||||
prozess: "SPM benennt abgestimmte Projektleitung und meldet an PPM"
|
||||
regelfall: "Owner des betroffenen Services/Produkts wird Projektleitung"
|
||||
|
||||
scope_definition:
|
||||
verantwortlich: ["spm", "projektleitung"]
|
||||
prozess: "SPM definiert gemeinsam mit Projektleitung den Scope"
|
||||
|
||||
ressourcenmobilisierung:
|
||||
verantwortlich: "projektleitung"
|
||||
prozess: "Projektleitung mobilisiert Ressourcen"
|
||||
|
||||
bei_konflikten:
|
||||
eskalation_ueber: "ppm_oder_spm"
|
||||
eskalation_an: "dsr"
|
||||
weitere_eskalation_moeglich_an: "mission_board"
|
||||
|
||||
monitoring_und_steuerung:
|
||||
projekt_monitoring:
|
||||
verantwortlich: "ppm"
|
||||
umfang: "alle Projekte im Portfolio"
|
||||
|
||||
status_reporting:
|
||||
von: "ppm"
|
||||
an: "dsr"
|
||||
frequenz: "regelmäßig"
|
||||
gegenstand: "Projekte, die durch DSR beauftragt wurden"
|
||||
|
||||
bei_konflikten:
|
||||
inhaltliche_konflikte:
|
||||
klaerung_in: "dsr"
|
||||
eskalation_moeglich_an: "mission_board"
|
||||
|
||||
projektabschluss:
|
||||
inhaltliche_abnahme:
|
||||
verantwortlich: "spm"
|
||||
|
||||
formaler_abschluss:
|
||||
verantwortlich: "ppm"
|
||||
prozess: "Projekt formal im Portfolio schließen"
|
||||
|
||||
# ========================================
|
||||
# 7. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
- ausloeser: "DSR Freigabe (DSR-Demand)"
|
||||
von: "dsr"
|
||||
zu: "ppm"
|
||||
zweck: "Projektaufnahme, Umsetzung starten"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
- "Auflagen"
|
||||
verantwortlich: ["dpm", "ppm"]
|
||||
|
||||
- ausloeser: "Service-Betroffenheit, Sponsoring & Owner-Einbindung"
|
||||
zwischen: ["dsr", "spm"]
|
||||
art: "bidirektional"
|
||||
zweck: "Sponsoring, Owner-Einbindung"
|
||||
artefakte:
|
||||
- "Protokoll"
|
||||
- "Owner-Liste"
|
||||
verantwortlich: "spm"
|
||||
|
||||
- ausloeser: "Delegation ans MB"
|
||||
von: "dsr"
|
||||
zu: "mission_board"
|
||||
zweck: "Strategische Entscheidung herbeiführen"
|
||||
artefakte:
|
||||
- "MB Vorlage"
|
||||
- "DSR Empfehlung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Rückmeldungen an Stakeholder"
|
||||
kontext: "Freigaben/Zurückstellungen mit Auflagen, Übergabe in Projekt-/Umsetzungssteuerung, Reporting"
|
||||
von: ["dsr", "ppm", "spm"]
|
||||
zu: "shm"
|
||||
zweck: "Entscheidung/Begründung kommunizieren"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
verantwortlich: "shm"
|
||||
|
||||
themen:
|
||||
- "Wiedervorlagen"
|
||||
- "Steckbrief-/User-Story-Bezug"
|
||||
|
||||
- ausloeser: "Architektur-Grundsatzfrage"
|
||||
von: "dsr"
|
||||
zu: "it_architektur_board"
|
||||
zweck: "Klärung technischer Leitplanken"
|
||||
artefakte:
|
||||
- "Kurzlage/Fragestellung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Projekt Reporting"
|
||||
von: "ppm"
|
||||
zu: ["dsr", "mission_board"]
|
||||
zweck: "Status, Risiken, Ressourcenlage kommunizieren"
|
||||
artefakte:
|
||||
- "Projekt-Portfolio Bericht"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
# ========================================
|
||||
# 8. KONFLIKTBEHANDLUNG
|
||||
# ========================================
|
||||
|
||||
konfliktbehandlung:
|
||||
regelung: "Verantwortlichkeiten in Konfliktsituationen sind in RACI-Matrix geregelt"
|
||||
referenz: "raci-matrix-demand-portfolio-management.yaml"
|
||||
|
|
@ -1,460 +1,460 @@
|
|||
meta:
|
||||
typ: "funktionsbeschreibung"
|
||||
funktion_id: "dpm"
|
||||
funktion_name: "Demand-Portfolio-Management"
|
||||
aliases: ["DPM", "Demand-Portfolio-Funktion"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "funktion"
|
||||
- "systemische-perspektive"
|
||||
- "orchestrierung"
|
||||
- "neutralitaet"
|
||||
|
||||
# ========================================
|
||||
# ABKÜRZUNGSVERZEICHNIS
|
||||
# ========================================
|
||||
|
||||
abkuerzungen:
|
||||
dpm: "Demand-Portfolio-Management"
|
||||
dsr: "Demand & Stakeholder-Runde"
|
||||
mb: "Mission Board"
|
||||
vb: "Vision Board"
|
||||
shm: "Stakeholder-Management"
|
||||
spm: "Service-Portfolio-Management"
|
||||
ppm: "Projekt-Portfolio-Management"
|
||||
al_p: "Abteilungsleitung Planung"
|
||||
pl: "Projektleitung"
|
||||
pzm: "Prozess-Management"
|
||||
ita: "IT-Architektur-Board"
|
||||
sh: "Stakeholder"
|
||||
kpi: "Key Performance Indicator (Kennzahl)"
|
||||
raci: "Responsible / Accountable / Consulted / Informed"
|
||||
d2p: "Demand-to-Project (Prozess)"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
wozu_existiert_diese_funktion:
|
||||
kurz: "Koordiniert den Fluss aller Demands im DIGIT vom vorqualifizierten Demand bis zur entscheidungsreifen Vorlage"
|
||||
|
||||
ausfuehrlich: |
|
||||
Das Demand-Portfolio-Management (DPM) übernimmt Demands aus dem Stakeholder-Management (SHM),
|
||||
klassifiziert, analysiert, bewertet und priorisiert sie und bringt sie als strukturierte
|
||||
Entscheidungsvorlagen in die zuständigen Gremien Demand & Stakeholder Runde (DSR) und
|
||||
Mission Board (MB) ein.
|
||||
|
||||
wertbeitrag:
|
||||
- "Transparenz"
|
||||
- "Vergleichbarkeit"
|
||||
- "Entscheidungsfähigkeit"
|
||||
|
||||
kritisches_merkmal: "Getrennt von der eigentlichen Freigabeentscheidung der Gremien"
|
||||
|
||||
hauptziel:
|
||||
beschreibung: "Ein kohärentes, strategiekonformes und entscheidungsfähiges Demand-Portfolio sicherstellen"
|
||||
|
||||
erreicht_durch:
|
||||
- id: "Z1"
|
||||
aktivitaet: "Systematische Überführung"
|
||||
beschreibung: "Vorqualifizierte Demands systematisch in Entscheidungsvorlagen überführen"
|
||||
umfasst:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
|
||||
- id: "Z2"
|
||||
aktivitaet: "Informationsfluss orchestrieren"
|
||||
beschreibung: "Informationsfluss zwischen SHM, DPM und Entscheidungsgremien orchestrieren"
|
||||
richtungen:
|
||||
- "Bottom-up"
|
||||
- "Top-down"
|
||||
- "Horizontal"
|
||||
|
||||
- id: "Z3"
|
||||
aktivitaet: "Trennung wahren"
|
||||
beschreibung: "Trennung von fachlicher Bewertung (DPM) und Entscheidung (DSR/MB) wahren"
|
||||
effekt: "Objektivität und Akzeptanz als neutrale Koordinationsinstanz stärken"
|
||||
|
||||
- id: "Z4"
|
||||
aktivitaet: "Portfolio-Erkenntnisse aufbereiten"
|
||||
beschreibung: "Demand-Portfolio-Erkenntnisse regelmäßig aufbereiten (Reviews)"
|
||||
effekt: "Bessere Koordination durch Mission Board und Abteilungsleitung Planung ermöglichen"
|
||||
|
||||
- id: "Z5"
|
||||
aktivitaet: "Zielbeitrag sichtbar machen"
|
||||
beschreibung: "Zielbeitrag anhand klarer KPIs sichtbar machen"
|
||||
|
||||
# ========================================
|
||||
# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG
|
||||
# ========================================
|
||||
|
||||
funktionsverstaendnis:
|
||||
charakterisierung:
|
||||
typ: "Bewertungs- und Orchestrierungsfunktion"
|
||||
|
||||
beschreibung: |
|
||||
Die neutrale Instanz, die Demands strukturiert bewertet, priorisiert und als
|
||||
Entscheidungsvorlagen in die zuständigen Gremien einbringt. Die Funktion hält
|
||||
Methodik, Routing und Demand-Portfolio-Transparenz zusammen – getrennt von der
|
||||
finalen Entscheidung und der operativen Umsetzung.
|
||||
|
||||
grundprinzipien:
|
||||
verantwortung_bleibt_wo_sie_hingehoert:
|
||||
beschreibung: "Klare Trennung zwischen Vorbereitung und Entscheidung"
|
||||
|
||||
entscheidungen:
|
||||
wo: "Gremien (DSR, MB)"
|
||||
was: "Freigabe, Ablehnung oder Delegation"
|
||||
dpm_rolle: "Bereitet vor, präsentiert, führt Beschlüsse nach – entscheidet aber nicht anstelle der Gremien"
|
||||
|
||||
linien_budget_verantwortung:
|
||||
wo: "MB und Fachbereiche"
|
||||
dpm_rolle: "Stellt Systematik und Entscheidungsreife sicher"
|
||||
|
||||
partnerschaft_statt_kontrolle:
|
||||
beschreibung: "DPM arbeitet auf Augenhöhe mit anderen Portfolio-Funktionen"
|
||||
|
||||
partnerschaften:
|
||||
- partner: "shm"
|
||||
beziehung: "SHM speist vorqualifizierte Demands ein"
|
||||
|
||||
- partner: "dpm"
|
||||
beziehung: "DPM qualifiziert und bündelt"
|
||||
|
||||
- partner: "spm"
|
||||
beziehung: "SPM bewertet Service-Auswirkungen"
|
||||
|
||||
- partner: "ppm"
|
||||
beziehung: "PPM integriert in das Projektportfolio"
|
||||
|
||||
institutionalisierung: "Diese Partnerschaft ist im DSR institutionalisiert (stimmberechtigte Kernrollen)"
|
||||
|
||||
arbeitsweise: "Folgt definierten Informationsflüssen (Bottom-up, Top-down, Horizontal) und fördert schnelle, anschlussfähige Entscheidungen statt 'Kontrolle'"
|
||||
|
||||
systematische_bewertung_transparenz:
|
||||
verantwortung_dpm:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Erstellung Entscheidungsvorlagen"
|
||||
- "Sauberes Entscheidungs-Routing (je nach Tragweite, Komplexität, Systemebene, Treiber)"
|
||||
|
||||
transparenz: "DPM stellt Transparenz über ein zentrales Demand-Portfolio her und bereitet Reviews für MB/AL-Planung vor"
|
||||
|
||||
nicht_teil_des_mandats:
|
||||
- "Operative Projektentscheidungen"
|
||||
- "Umsetzungsleistungen"
|
||||
|
||||
abgrenzung_zu_angrenzenden_funktionen:
|
||||
- funktion: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
tut: "Erfasst und klärt den Bedarf mit Stakeholdern"
|
||||
uebergabe: "Übergibt vorqualifiziert an DPM"
|
||||
|
||||
- funktion: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
tut: "Klassifiziert, analysiert, bewertet, priorisiert, routet"
|
||||
uebergabe: "Bringt Vorlagen in DSR/MB ein"
|
||||
|
||||
- funktion: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
tut: "Prüft Service-Fit/-Impact und katalogseitige Konsequenzen"
|
||||
|
||||
- funktion: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
tut: "Integriert freigegebene Demands in das Projektportfolio"
|
||||
und: "Steuert Projektumsetzungen"
|
||||
|
||||
# ========================================
|
||||
# 3. VERANTWORTUNGSBEREICHE
|
||||
# ========================================
|
||||
|
||||
verantwortungsbereiche:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 DEMAND-PORTFOLIO-MANAGEMENT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_1_portfolio_management:
|
||||
id: "VB1"
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
was:
|
||||
- "Zentrales Demand-Portfolio führen und aktuell halten"
|
||||
- "Trends und Muster analysieren"
|
||||
- "Demand-Portfolio-Methodiken optimieren"
|
||||
- "Entlang Vision-Board-Leitplanken bewerten und priorisieren"
|
||||
|
||||
warum:
|
||||
- "Strategiekonforme, ressourcenfähige Auswahl durch MB ermöglichen"
|
||||
- "DPM liefert die strukturierte Grundlage, MB trifft die Allokationsentscheidungen"
|
||||
- "Objektivität sichern durch Trennung von Bewertung (DPM) und Entscheidung (DSR/MB)"
|
||||
|
||||
wie:
|
||||
routinen:
|
||||
- frequenz: "woechentlich"
|
||||
was: "DSR"
|
||||
|
||||
- frequenz: "quartalsweise"
|
||||
was: "Demand-Portfolio-Review"
|
||||
|
||||
reporting:
|
||||
an: "mb"
|
||||
format: "MB-Kurzpräsentation"
|
||||
inhalte:
|
||||
- "Demand-Portfolio-Entwicklung"
|
||||
- "Muster"
|
||||
- "Handlungsbedarfe"
|
||||
- "Empfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 KLASSIFIZIERUNG, ANALYSE, BEWERTUNG, PRIORISIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
bereich_2_qualifizierung:
|
||||
id: "VB2"
|
||||
name: "Demand-Klassifizierung, Analyse, Bewertung und Priorisierung"
|
||||
|
||||
was:
|
||||
- "Klassifizierung nach vordefinierten Dimensionen"
|
||||
- "Unzureichend qualifizierte Demands zurückweisen"
|
||||
- "Dubletten konsolidieren"
|
||||
- "Fachexpert:innen einbeziehen"
|
||||
- "Anwendung von Kategorien & Bewertungskriterien"
|
||||
- "Nutzung Bedarfs-Steckbrief und Demand-Entscheidungsvorlage"
|
||||
|
||||
warum:
|
||||
- "Klaren Prozess und Verfahren gegenüber Stakeholder sicherstellen"
|
||||
- "Entscheidungsfähigkeit herstellen und Vergleichbarkeit sichern"
|
||||
|
||||
wie:
|
||||
methodik:
|
||||
beschreibung: "Standardisierte Klassifizierung/Bewertung/Priorisierung"
|
||||
referenz: "DPM-Framework"
|
||||
|
||||
interaktion:
|
||||
- mit: "shm"
|
||||
was: "Rückfragen/Nachforderungen"
|
||||
|
||||
- mit: ["spm", "ppm", "ita"]
|
||||
was: "Abstimmung bei Service-, Projekt- oder Technikfragen"
|
||||
|
||||
dokumentation:
|
||||
- "Laufende Statuspflege im Ticketsystem"
|
||||
- "Statuspflege in weiteren genutzten Tools im Demand-Portfolio"
|
||||
- "Portfolio-Abgleich"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 GREMIENARBEIT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
id: "VB3"
|
||||
name: "Gremienarbeit"
|
||||
|
||||
was:
|
||||
- "DSR vorbereiten, in der Sitzung präsentieren, Beschlüsse dokumentieren"
|
||||
- "MB-Vorstellung MB-relevanter Demands"
|
||||
- "Nachbearbeitung und Umsetzungsvorbereitung gemäß Beschlüssen"
|
||||
|
||||
warum:
|
||||
- "Klare, effiziente Entscheidungen im Konsent-Verfahren"
|
||||
- "Eskalationsfähigkeit zum MB bei Uneinigkeit oder Kompetenzüberschreitung"
|
||||
|
||||
wie:
|
||||
rhythmus_rolle:
|
||||
- frequenz: "woechentlich"
|
||||
gremium: "dsr"
|
||||
|
||||
- frequenz: "ad_hoc"
|
||||
was: "Sondersitzungen auf Antrag"
|
||||
|
||||
arbeitsweise:
|
||||
- "Standard-Agenda"
|
||||
- "Unterlagen vorab"
|
||||
- "Confluence-Ablage"
|
||||
- "Unmittelbare Ergebnis-Kommunikation"
|
||||
|
||||
outputs:
|
||||
- "Beschlussprotokolle"
|
||||
- "Aktualisierte Demand-Portfolio-/Ticket-Einträge"
|
||||
- "Übergabe an PPM bei Freigabe"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
beschreibung: "Input/Output/Typische Abstimmungswege"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 INPUTS
|
||||
# ----------------------------------
|
||||
|
||||
inputs:
|
||||
beschreibung: "Was das DPM empfängt"
|
||||
|
||||
quellen:
|
||||
- von: "vision_board"
|
||||
inhalt: "Strategische Leitplanken und Top-down-Vorgaben, die den Priorisierungsrahmen für Demands setzen"
|
||||
|
||||
- von: "mission_board"
|
||||
inhalt: "Beschlüsse und Prioritäten für MB-relevante Demands; Rückfragen oder Arbeitsaufträge an DPM bei Vertagung/Delegation"
|
||||
|
||||
- von: "shm"
|
||||
inhalt: "Übergabe vorqualifizierter Demands inkl. Bedarfs-Steckbrief; Nachlieferungen bei Rückfragen; Statuswechsel 'an DPM übergeben' mit SHM-Einschätzung"
|
||||
|
||||
- von: "spm"
|
||||
inhalt: "Input zu Service-Fit und -Konsequenzen; Abstimmung, wenn direkte Service-Umsetzung möglich oder Service-Impact zu prüfen ist"
|
||||
|
||||
- von: "ppm"
|
||||
inhalt: "Informationen zu laufenden/geplanten Projekten zur Überschneidungsprüfung; Abgleich bei potenziellen Projekt-Kollisionen"
|
||||
|
||||
- von: "ita"
|
||||
inhalt: "Strategische/technische Grundsatz-Inputs zur Machbarkeit und Architekturrahmen"
|
||||
|
||||
- von: "fachexpertinnen"
|
||||
inhalt: "Punktuelle Expertise für Bewertung/Qualifizierung (fachlich/technisch)"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 OUTPUTS
|
||||
# ----------------------------------
|
||||
|
||||
outputs:
|
||||
beschreibung: "Was das DPM weitergibt"
|
||||
|
||||
ziele:
|
||||
- an: "dsr"
|
||||
inhalt: "Standardisierte Entscheidungsvorlage je Demand (Klassifizierung, Optionen, Empfehlung, Auswirkungen, Risiken), Vorstellung in der Sitzung, Beschluss-/Aufgabenüberführung"
|
||||
|
||||
- an: "mb"
|
||||
inhalt: "Entscheidungsvorlage für MB-relevante Demands inkl. Priorisierungsempfehlung, strategischer Fit, Ressourcen-/Portfolio-Auswirkungen, Alternativen; Kurzbericht Entscheidung/Nachverfolgung"
|
||||
|
||||
- an: "shm"
|
||||
inhalt: "Rückmeldung zum Bewertungsergebnis (z.B. Nachlieferung benötigt, Konsolidierung mit ähnlichen Demands, Routing in DSR/MB, Ablehnungs-/Delegationsbegründung); aktualisierte Steckbrief-Anforderungen"
|
||||
|
||||
- an: "spm"
|
||||
inhalt: "Klärungsanfragen zu Service-Fit/-Impact, dokumentierte Ergebnisse für Entscheidungsvorlage; Hinweise auf Servicekatalog-Anpassungen"
|
||||
|
||||
- an: "ppm"
|
||||
inhalt: "Übergabe freigegebener Demands in die Projektpipeline inkl. Beschlussreferenz, Priorität, Abhängigkeiten, initialer Projektsteckbrief/Startkonditionen"
|
||||
|
||||
- an: ["ita", "fachexpertinnen"]
|
||||
inhalt: "Gezielte Architektur-/Fachabfragen zur Entscheidungsreife; zusammengefasste Einschätzungen für die Vorlage (Machbarkeit, Standards, Risiken)"
|
||||
|
||||
- an: "al_p"
|
||||
inhalt: "Quartalsweiser Demand-Portfolio-Report: KPI-Dashboard, Muster/Trends, Handlungs-/Priorisierungsempfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 TYPISCHE ABSTIMMUNGSWEGE
|
||||
# ----------------------------------
|
||||
|
||||
typische_abstimmungswege:
|
||||
beschreibung: "Standardisierte Interaktionsformate"
|
||||
|
||||
formate:
|
||||
- format: "dsr_regulaer"
|
||||
name: "DSR – Regulär"
|
||||
frequenz: "woechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Vorstellung der Entscheidungsvorlagen durch DPM"
|
||||
- "Gemeinsame Bewertung/Klassifizierung"
|
||||
- "Beschluss (Freigabe, Ablehnung, Zurückstellung, Delegation ans MB)"
|
||||
- "Protokoll und Ticket-Update"
|
||||
|
||||
- format: "sonder_dsr"
|
||||
name: "Sonder-DSR"
|
||||
frequenz: "ad_hoc"
|
||||
|
||||
inhalt:
|
||||
- "Kurzfristige Klärung dringlicher Themen oder Konflikte"
|
||||
- "Einberufung auf Anfrage eines DSR-Mitglieds"
|
||||
- "Entscheidung über Einberufung liegt beim DPM"
|
||||
- "Eskalationsweg bei Bedarf"
|
||||
|
||||
- format: "mission_board"
|
||||
name: "Mission Board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Finale Entscheidung zu MB-relevanten Demands"
|
||||
- "Priorisierung/Ressourcen"
|
||||
- "DPM liefert MB-Vorlage"
|
||||
- "PPM/SHM übernehmen Folgekommunikation und Statusupdates"
|
||||
|
||||
- format: "shm_dpm_klaerung"
|
||||
name: "SHM ↔ DPM – Klärungsschleifen"
|
||||
frequenz: "laufend"
|
||||
|
||||
inhalt:
|
||||
- "Nachforderungen bei unvollständigen Demands"
|
||||
- "Persönliche Kurzabstimmungen/E-Mail"
|
||||
- "SHM aktualisiert Steckbrief/Ticket"
|
||||
|
||||
- format: "dpm_spm_service"
|
||||
name: "DPM ↔ SPM – Service-Fit/Impact"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Abgleich Service-Bezug"
|
||||
- "Direkte Umsetzung kleiner Demands mit SPM/Service Manager"
|
||||
- "Ergebnissicherung für die Entscheidungsvorlage"
|
||||
|
||||
- format: "dpm_ppm_projekt"
|
||||
name: "DPM ↔ PPM – Projekt-Abgleich/Übergabe"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Prüfen von Überschneidungen mit laufenden/geplanten Projekten"
|
||||
- "Übergabe freigegebener Demands in die Projektpipeline"
|
||||
- "Status-Reporting zurück an DSR/MB"
|
||||
|
||||
- format: "dpm_ita_grundsatz"
|
||||
name: "DPM ↔ IT-Architektur-Board"
|
||||
frequenz: "bei_grundsatzfragen"
|
||||
|
||||
inhalt:
|
||||
- "Technische Leitplanken/Machbarkeit klären"
|
||||
- "Kurzlage/Fragestellung aus DSR/DPM"
|
||||
|
||||
- format: "portfolio_review"
|
||||
name: "Demand-Portfolio-Review"
|
||||
frequenz: "quartalsweise"
|
||||
|
||||
inhalt:
|
||||
- "Muster-/Trendanalysen"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
verwandte_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen für DPM-Funktion"
|
||||
|
||||
- titel: "RACI-Matrix DPM"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten über Phasen hinweg"
|
||||
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
meta:
|
||||
typ: "funktionsbeschreibung"
|
||||
funktion_id: "dpm"
|
||||
funktion_name: "Demand-Portfolio-Management"
|
||||
aliases: ["DPM", "Demand-Portfolio-Funktion"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "funktion"
|
||||
- "systemische-perspektive"
|
||||
- "orchestrierung"
|
||||
- "neutralitaet"
|
||||
|
||||
# ========================================
|
||||
# ABKÜRZUNGSVERZEICHNIS
|
||||
# ========================================
|
||||
|
||||
abkuerzungen:
|
||||
dpm: "Demand-Portfolio-Management"
|
||||
dsr: "Demand & Stakeholder-Runde"
|
||||
mb: "Mission Board"
|
||||
vb: "Vision Board"
|
||||
shm: "Stakeholder-Management"
|
||||
spm: "Service-Portfolio-Management"
|
||||
ppm: "Projekt-Portfolio-Management"
|
||||
al_p: "Abteilungsleitung Planung"
|
||||
pl: "Projektleitung"
|
||||
pzm: "Prozess-Management"
|
||||
ita: "IT-Architektur-Board"
|
||||
sh: "Stakeholder"
|
||||
kpi: "Key Performance Indicator (Kennzahl)"
|
||||
raci: "Responsible / Accountable / Consulted / Informed"
|
||||
d2p: "Demand-to-Project (Prozess)"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
wozu_existiert_diese_funktion:
|
||||
kurz: "Koordiniert den Fluss aller Demands im DIGIT vom vorqualifizierten Demand bis zur entscheidungsreifen Vorlage"
|
||||
|
||||
ausfuehrlich: |
|
||||
Das Demand-Portfolio-Management (DPM) übernimmt Demands aus dem Stakeholder-Management (SHM),
|
||||
klassifiziert, analysiert, bewertet und priorisiert sie und bringt sie als strukturierte
|
||||
Entscheidungsvorlagen in die zuständigen Gremien Demand & Stakeholder Runde (DSR) und
|
||||
Mission Board (MB) ein.
|
||||
|
||||
wertbeitrag:
|
||||
- "Transparenz"
|
||||
- "Vergleichbarkeit"
|
||||
- "Entscheidungsfähigkeit"
|
||||
|
||||
kritisches_merkmal: "Getrennt von der eigentlichen Freigabeentscheidung der Gremien"
|
||||
|
||||
hauptziel:
|
||||
beschreibung: "Ein kohärentes, strategiekonformes und entscheidungsfähiges Demand-Portfolio sicherstellen"
|
||||
|
||||
erreicht_durch:
|
||||
- id: "Z1"
|
||||
aktivitaet: "Systematische Überführung"
|
||||
beschreibung: "Vorqualifizierte Demands systematisch in Entscheidungsvorlagen überführen"
|
||||
umfasst:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
|
||||
- id: "Z2"
|
||||
aktivitaet: "Informationsfluss orchestrieren"
|
||||
beschreibung: "Informationsfluss zwischen SHM, DPM und Entscheidungsgremien orchestrieren"
|
||||
richtungen:
|
||||
- "Bottom-up"
|
||||
- "Top-down"
|
||||
- "Horizontal"
|
||||
|
||||
- id: "Z3"
|
||||
aktivitaet: "Trennung wahren"
|
||||
beschreibung: "Trennung von fachlicher Bewertung (DPM) und Entscheidung (DSR/MB) wahren"
|
||||
effekt: "Objektivität und Akzeptanz als neutrale Koordinationsinstanz stärken"
|
||||
|
||||
- id: "Z4"
|
||||
aktivitaet: "Portfolio-Erkenntnisse aufbereiten"
|
||||
beschreibung: "Demand-Portfolio-Erkenntnisse regelmäßig aufbereiten (Reviews)"
|
||||
effekt: "Bessere Koordination durch Mission Board und Abteilungsleitung Planung ermöglichen"
|
||||
|
||||
- id: "Z5"
|
||||
aktivitaet: "Zielbeitrag sichtbar machen"
|
||||
beschreibung: "Zielbeitrag anhand klarer KPIs sichtbar machen"
|
||||
|
||||
# ========================================
|
||||
# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG
|
||||
# ========================================
|
||||
|
||||
funktionsverstaendnis:
|
||||
charakterisierung:
|
||||
typ: "Bewertungs- und Orchestrierungsfunktion"
|
||||
|
||||
beschreibung: |
|
||||
Die neutrale Instanz, die Demands strukturiert bewertet, priorisiert und als
|
||||
Entscheidungsvorlagen in die zuständigen Gremien einbringt. Die Funktion hält
|
||||
Methodik, Routing und Demand-Portfolio-Transparenz zusammen – getrennt von der
|
||||
finalen Entscheidung und der operativen Umsetzung.
|
||||
|
||||
grundprinzipien:
|
||||
verantwortung_bleibt_wo_sie_hingehoert:
|
||||
beschreibung: "Klare Trennung zwischen Vorbereitung und Entscheidung"
|
||||
|
||||
entscheidungen:
|
||||
wo: "Gremien (DSR, MB)"
|
||||
was: "Freigabe, Ablehnung oder Delegation"
|
||||
dpm_rolle: "Bereitet vor, präsentiert, führt Beschlüsse nach – entscheidet aber nicht anstelle der Gremien"
|
||||
|
||||
linien_budget_verantwortung:
|
||||
wo: "MB und Fachbereiche"
|
||||
dpm_rolle: "Stellt Systematik und Entscheidungsreife sicher"
|
||||
|
||||
partnerschaft_statt_kontrolle:
|
||||
beschreibung: "DPM arbeitet auf Augenhöhe mit anderen Portfolio-Funktionen"
|
||||
|
||||
partnerschaften:
|
||||
- partner: "shm"
|
||||
beziehung: "SHM speist vorqualifizierte Demands ein"
|
||||
|
||||
- partner: "dpm"
|
||||
beziehung: "DPM qualifiziert und bündelt"
|
||||
|
||||
- partner: "spm"
|
||||
beziehung: "SPM bewertet Service-Auswirkungen"
|
||||
|
||||
- partner: "ppm"
|
||||
beziehung: "PPM integriert in das Projektportfolio"
|
||||
|
||||
institutionalisierung: "Diese Partnerschaft ist im DSR institutionalisiert (stimmberechtigte Kernrollen)"
|
||||
|
||||
arbeitsweise: "Folgt definierten Informationsflüssen (Bottom-up, Top-down, Horizontal) und fördert schnelle, anschlussfähige Entscheidungen statt 'Kontrolle'"
|
||||
|
||||
systematische_bewertung_transparenz:
|
||||
verantwortung_dpm:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Erstellung Entscheidungsvorlagen"
|
||||
- "Sauberes Entscheidungs-Routing (je nach Tragweite, Komplexität, Systemebene, Treiber)"
|
||||
|
||||
transparenz: "DPM stellt Transparenz über ein zentrales Demand-Portfolio her und bereitet Reviews für MB/AL-Planung vor"
|
||||
|
||||
nicht_teil_des_mandats:
|
||||
- "Operative Projektentscheidungen"
|
||||
- "Umsetzungsleistungen"
|
||||
|
||||
abgrenzung_zu_angrenzenden_funktionen:
|
||||
- funktion: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
tut: "Erfasst und klärt den Bedarf mit Stakeholdern"
|
||||
uebergabe: "Übergibt vorqualifiziert an DPM"
|
||||
|
||||
- funktion: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
tut: "Klassifiziert, analysiert, bewertet, priorisiert, routet"
|
||||
uebergabe: "Bringt Vorlagen in DSR/MB ein"
|
||||
|
||||
- funktion: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
tut: "Prüft Service-Fit/-Impact und katalogseitige Konsequenzen"
|
||||
|
||||
- funktion: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
tut: "Integriert freigegebene Demands in das Projektportfolio"
|
||||
und: "Steuert Projektumsetzungen"
|
||||
|
||||
# ========================================
|
||||
# 3. VERANTWORTUNGSBEREICHE
|
||||
# ========================================
|
||||
|
||||
verantwortungsbereiche:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 DEMAND-PORTFOLIO-MANAGEMENT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_1_portfolio_management:
|
||||
id: "VB1"
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
was:
|
||||
- "Zentrales Demand-Portfolio führen und aktuell halten"
|
||||
- "Trends und Muster analysieren"
|
||||
- "Demand-Portfolio-Methodiken optimieren"
|
||||
- "Entlang Vision-Board-Leitplanken bewerten und priorisieren"
|
||||
|
||||
warum:
|
||||
- "Strategiekonforme, ressourcenfähige Auswahl durch MB ermöglichen"
|
||||
- "DPM liefert die strukturierte Grundlage, MB trifft die Allokationsentscheidungen"
|
||||
- "Objektivität sichern durch Trennung von Bewertung (DPM) und Entscheidung (DSR/MB)"
|
||||
|
||||
wie:
|
||||
routinen:
|
||||
- frequenz: "woechentlich"
|
||||
was: "DSR"
|
||||
|
||||
- frequenz: "quartalsweise"
|
||||
was: "Demand-Portfolio-Review"
|
||||
|
||||
reporting:
|
||||
an: "mb"
|
||||
format: "MB-Kurzpräsentation"
|
||||
inhalte:
|
||||
- "Demand-Portfolio-Entwicklung"
|
||||
- "Muster"
|
||||
- "Handlungsbedarfe"
|
||||
- "Empfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 KLASSIFIZIERUNG, ANALYSE, BEWERTUNG, PRIORISIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
bereich_2_qualifizierung:
|
||||
id: "VB2"
|
||||
name: "Demand-Klassifizierung, Analyse, Bewertung und Priorisierung"
|
||||
|
||||
was:
|
||||
- "Klassifizierung nach vordefinierten Dimensionen"
|
||||
- "Unzureichend qualifizierte Demands zurückweisen"
|
||||
- "Dubletten konsolidieren"
|
||||
- "Fachexpert:innen einbeziehen"
|
||||
- "Anwendung von Kategorien & Bewertungskriterien"
|
||||
- "Nutzung Bedarfs-Steckbrief und Demand-Entscheidungsvorlage"
|
||||
|
||||
warum:
|
||||
- "Klaren Prozess und Verfahren gegenüber Stakeholder sicherstellen"
|
||||
- "Entscheidungsfähigkeit herstellen und Vergleichbarkeit sichern"
|
||||
|
||||
wie:
|
||||
methodik:
|
||||
beschreibung: "Standardisierte Klassifizierung/Bewertung/Priorisierung"
|
||||
referenz: "DPM-Framework"
|
||||
|
||||
interaktion:
|
||||
- mit: "shm"
|
||||
was: "Rückfragen/Nachforderungen"
|
||||
|
||||
- mit: ["spm", "ppm", "ita"]
|
||||
was: "Abstimmung bei Service-, Projekt- oder Technikfragen"
|
||||
|
||||
dokumentation:
|
||||
- "Laufende Statuspflege im Ticketsystem"
|
||||
- "Statuspflege in weiteren genutzten Tools im Demand-Portfolio"
|
||||
- "Portfolio-Abgleich"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 GREMIENARBEIT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
id: "VB3"
|
||||
name: "Gremienarbeit"
|
||||
|
||||
was:
|
||||
- "DSR vorbereiten, in der Sitzung präsentieren, Beschlüsse dokumentieren"
|
||||
- "MB-Vorstellung MB-relevanter Demands"
|
||||
- "Nachbearbeitung und Umsetzungsvorbereitung gemäß Beschlüssen"
|
||||
|
||||
warum:
|
||||
- "Klare, effiziente Entscheidungen im Konsent-Verfahren"
|
||||
- "Eskalationsfähigkeit zum MB bei Uneinigkeit oder Kompetenzüberschreitung"
|
||||
|
||||
wie:
|
||||
rhythmus_rolle:
|
||||
- frequenz: "woechentlich"
|
||||
gremium: "dsr"
|
||||
|
||||
- frequenz: "ad_hoc"
|
||||
was: "Sondersitzungen auf Antrag"
|
||||
|
||||
arbeitsweise:
|
||||
- "Standard-Agenda"
|
||||
- "Unterlagen vorab"
|
||||
- "Confluence-Ablage"
|
||||
- "Unmittelbare Ergebnis-Kommunikation"
|
||||
|
||||
outputs:
|
||||
- "Beschlussprotokolle"
|
||||
- "Aktualisierte Demand-Portfolio-/Ticket-Einträge"
|
||||
- "Übergabe an PPM bei Freigabe"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
beschreibung: "Input/Output/Typische Abstimmungswege"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 INPUTS
|
||||
# ----------------------------------
|
||||
|
||||
inputs:
|
||||
beschreibung: "Was das DPM empfängt"
|
||||
|
||||
quellen:
|
||||
- von: "vision_board"
|
||||
inhalt: "Strategische Leitplanken und Top-down-Vorgaben, die den Priorisierungsrahmen für Demands setzen"
|
||||
|
||||
- von: "mission_board"
|
||||
inhalt: "Beschlüsse und Prioritäten für MB-relevante Demands; Rückfragen oder Arbeitsaufträge an DPM bei Vertagung/Delegation"
|
||||
|
||||
- von: "shm"
|
||||
inhalt: "Übergabe vorqualifizierter Demands inkl. Bedarfs-Steckbrief; Nachlieferungen bei Rückfragen; Statuswechsel 'an DPM übergeben' mit SHM-Einschätzung"
|
||||
|
||||
- von: "spm"
|
||||
inhalt: "Input zu Service-Fit und -Konsequenzen; Abstimmung, wenn direkte Service-Umsetzung möglich oder Service-Impact zu prüfen ist"
|
||||
|
||||
- von: "ppm"
|
||||
inhalt: "Informationen zu laufenden/geplanten Projekten zur Überschneidungsprüfung; Abgleich bei potenziellen Projekt-Kollisionen"
|
||||
|
||||
- von: "ita"
|
||||
inhalt: "Strategische/technische Grundsatz-Inputs zur Machbarkeit und Architekturrahmen"
|
||||
|
||||
- von: "fachexpertinnen"
|
||||
inhalt: "Punktuelle Expertise für Bewertung/Qualifizierung (fachlich/technisch)"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 OUTPUTS
|
||||
# ----------------------------------
|
||||
|
||||
outputs:
|
||||
beschreibung: "Was das DPM weitergibt"
|
||||
|
||||
ziele:
|
||||
- an: "dsr"
|
||||
inhalt: "Standardisierte Entscheidungsvorlage je Demand (Klassifizierung, Optionen, Empfehlung, Auswirkungen, Risiken), Vorstellung in der Sitzung, Beschluss-/Aufgabenüberführung"
|
||||
|
||||
- an: "mb"
|
||||
inhalt: "Entscheidungsvorlage für MB-relevante Demands inkl. Priorisierungsempfehlung, strategischer Fit, Ressourcen-/Portfolio-Auswirkungen, Alternativen; Kurzbericht Entscheidung/Nachverfolgung"
|
||||
|
||||
- an: "shm"
|
||||
inhalt: "Rückmeldung zum Bewertungsergebnis (z.B. Nachlieferung benötigt, Konsolidierung mit ähnlichen Demands, Routing in DSR/MB, Ablehnungs-/Delegationsbegründung); aktualisierte Steckbrief-Anforderungen"
|
||||
|
||||
- an: "spm"
|
||||
inhalt: "Klärungsanfragen zu Service-Fit/-Impact, dokumentierte Ergebnisse für Entscheidungsvorlage; Hinweise auf Servicekatalog-Anpassungen"
|
||||
|
||||
- an: "ppm"
|
||||
inhalt: "Übergabe freigegebener Demands in die Projektpipeline inkl. Beschlussreferenz, Priorität, Abhängigkeiten, initialer Projektsteckbrief/Startkonditionen"
|
||||
|
||||
- an: ["ita", "fachexpertinnen"]
|
||||
inhalt: "Gezielte Architektur-/Fachabfragen zur Entscheidungsreife; zusammengefasste Einschätzungen für die Vorlage (Machbarkeit, Standards, Risiken)"
|
||||
|
||||
- an: "al_p"
|
||||
inhalt: "Quartalsweiser Demand-Portfolio-Report: KPI-Dashboard, Muster/Trends, Handlungs-/Priorisierungsempfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 TYPISCHE ABSTIMMUNGSWEGE
|
||||
# ----------------------------------
|
||||
|
||||
typische_abstimmungswege:
|
||||
beschreibung: "Standardisierte Interaktionsformate"
|
||||
|
||||
formate:
|
||||
- format: "dsr_regulaer"
|
||||
name: "DSR – Regulär"
|
||||
frequenz: "woechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Vorstellung der Entscheidungsvorlagen durch DPM"
|
||||
- "Gemeinsame Bewertung/Klassifizierung"
|
||||
- "Beschluss (Freigabe, Ablehnung, Zurückstellung, Delegation ans MB)"
|
||||
- "Protokoll und Ticket-Update"
|
||||
|
||||
- format: "sonder_dsr"
|
||||
name: "Sonder-DSR"
|
||||
frequenz: "ad_hoc"
|
||||
|
||||
inhalt:
|
||||
- "Kurzfristige Klärung dringlicher Themen oder Konflikte"
|
||||
- "Einberufung auf Anfrage eines DSR-Mitglieds"
|
||||
- "Entscheidung über Einberufung liegt beim DPM"
|
||||
- "Eskalationsweg bei Bedarf"
|
||||
|
||||
- format: "mission_board"
|
||||
name: "Mission Board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Finale Entscheidung zu MB-relevanten Demands"
|
||||
- "Priorisierung/Ressourcen"
|
||||
- "DPM liefert MB-Vorlage"
|
||||
- "PPM/SHM übernehmen Folgekommunikation und Statusupdates"
|
||||
|
||||
- format: "shm_dpm_klaerung"
|
||||
name: "SHM ↔ DPM – Klärungsschleifen"
|
||||
frequenz: "laufend"
|
||||
|
||||
inhalt:
|
||||
- "Nachforderungen bei unvollständigen Demands"
|
||||
- "Persönliche Kurzabstimmungen/E-Mail"
|
||||
- "SHM aktualisiert Steckbrief/Ticket"
|
||||
|
||||
- format: "dpm_spm_service"
|
||||
name: "DPM ↔ SPM – Service-Fit/Impact"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Abgleich Service-Bezug"
|
||||
- "Direkte Umsetzung kleiner Demands mit SPM/Service Manager"
|
||||
- "Ergebnissicherung für die Entscheidungsvorlage"
|
||||
|
||||
- format: "dpm_ppm_projekt"
|
||||
name: "DPM ↔ PPM – Projekt-Abgleich/Übergabe"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Prüfen von Überschneidungen mit laufenden/geplanten Projekten"
|
||||
- "Übergabe freigegebener Demands in die Projektpipeline"
|
||||
- "Status-Reporting zurück an DSR/MB"
|
||||
|
||||
- format: "dpm_ita_grundsatz"
|
||||
name: "DPM ↔ IT-Architektur-Board"
|
||||
frequenz: "bei_grundsatzfragen"
|
||||
|
||||
inhalt:
|
||||
- "Technische Leitplanken/Machbarkeit klären"
|
||||
- "Kurzlage/Fragestellung aus DSR/DPM"
|
||||
|
||||
- format: "portfolio_review"
|
||||
name: "Demand-Portfolio-Review"
|
||||
frequenz: "quartalsweise"
|
||||
|
||||
inhalt:
|
||||
- "Muster-/Trendanalysen"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
verwandte_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen für DPM-Funktion"
|
||||
|
||||
- titel: "RACI-Matrix DPM"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten über Phasen hinweg"
|
||||
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Methodischer Kern der DPM-Funktion"
|
||||
|
|
@ -1,329 +1,329 @@
|
|||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "komplexitaet"
|
||||
titel: "Klassifizierungsmatrix Komplexität"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "komplexitaet"
|
||||
- "loesungsunsicherheit"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands.
|
||||
Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell
|
||||
und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert
|
||||
zu bewerten.
|
||||
|
||||
grundverstaendnis: |
|
||||
Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit,
|
||||
sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch
|
||||
einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen
|
||||
Interessen involviert sind.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
bewertungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: STAKEHOLDER & KOORDINATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_stakeholder_koordination:
|
||||
id: "stakeholder_koordination"
|
||||
name: "Stakeholder & Koordination"
|
||||
leitfrage: "Wie viele Akteure müssen koordiniert werden?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "beteiligte_teams"
|
||||
name: "Beteiligte Teams"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Teams"
|
||||
komplex: "3-4 Teams"
|
||||
hochkomplex: "5+ Teams"
|
||||
|
||||
- kriterium_id: "stakeholder_gruppen"
|
||||
name: "Stakeholder-Gruppen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Gruppen"
|
||||
komplex: "3-5 Gruppen"
|
||||
hochkomplex: "6+ Gruppen"
|
||||
|
||||
- kriterium_id: "entscheidungsebene"
|
||||
name: "Entscheidungsebene"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Arbeitsebene"
|
||||
komplex: "Abteilungsleitung"
|
||||
hochkomplex: "Amtsleitung/Politik"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_loesungsraum_unsicherheit:
|
||||
id: "loesungsraum_unsicherheit"
|
||||
name: "Lösungsraum & Unsicherheit"
|
||||
leitfrage: "Wie klar ist der Weg zur Lösung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "loesungsklarheit"
|
||||
name: "Lösungsklarheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Eindeutige Lösung"
|
||||
komplex: "2-3 Optionen"
|
||||
hochkomplex: "Unklar/Exploration nötig"
|
||||
|
||||
- kriterium_id: "technologie_reife"
|
||||
name: "Technologie-Reife"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Bewährt im DIGIT"
|
||||
komplex: "Neu für DIGIT"
|
||||
hochkomplex: "Innovativ/Experimentell"
|
||||
|
||||
- kriterium_id: "anforderungsstabilitaet"
|
||||
name: "Anforderungsstabilität"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Stabil & klar"
|
||||
komplex: "Teilweise unklar"
|
||||
hochkomplex: "Volatil/Undefiniert"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_abhaengigkeiten_integration:
|
||||
id: "abhaengigkeiten_integration"
|
||||
name: "Abhängigkeiten & Integration"
|
||||
leitfrage: "Wie vernetzt ist der Demand?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "externe_partner"
|
||||
name: "Externe Partner"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "1-2 Partner"
|
||||
hochkomplex: "3+ Partner"
|
||||
|
||||
- kriterium_id: "system_schnittstellen"
|
||||
name: "System-Schnittstellen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Systeme"
|
||||
komplex: "3-4 Systeme"
|
||||
hochkomplex: "5+ Systeme"
|
||||
|
||||
- kriterium_id: "zeitliche_abhaengigkeiten"
|
||||
name: "Zeitliche Abhängigkeiten"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Flexibel planbar"
|
||||
komplex: "Teilweise gebunden"
|
||||
hochkomplex: "Kritische Verkettung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: RISIKEN & UNWÄGBARKEITEN
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_risiken_unwaegbarkeiten:
|
||||
id: "risiken_unwaegbarkeiten"
|
||||
name: "Risiken & Unwägbarkeiten"
|
||||
leitfrage: "Wie beherrschbar sind die Risiken?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "budget_unsicherheit"
|
||||
name: "Budget-Unsicherheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Verlässlich planbar"
|
||||
komplex: "Bandbreiten-Schätzung"
|
||||
hochkomplex: "Unkalkulierbar"
|
||||
|
||||
- kriterium_id: "termin_risiko"
|
||||
name: "Termin-Risiko"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Gering"
|
||||
komplex: "Mittel"
|
||||
hochkomplex: "Hoch/Unklar"
|
||||
|
||||
- kriterium_id: "compliance_risiken"
|
||||
name: "Compliance-Risiken"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "Handhabbar"
|
||||
hochkomplex: "Kritisch/Unklar"
|
||||
|
||||
# ========================================
|
||||
# SIGNALE FÜR HOCHKOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
signale_hochkomplexitaet:
|
||||
beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten"
|
||||
|
||||
signale:
|
||||
- id: "paradoxe_anforderungen"
|
||||
signal: "Paradoxe Anforderungen"
|
||||
beispiel: "\"Soll alles können, darf nichts kosten\""
|
||||
interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
- id: "moving_targets"
|
||||
signal: "Moving Targets"
|
||||
beschreibung: "Anforderungen ändern sich während der Analyse"
|
||||
interpretation: "Instabile Ausgangslage, hohe Unsicherheit"
|
||||
|
||||
- id: "interessenskomplexitaet"
|
||||
signal: "Interessenskomplexität"
|
||||
beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen"
|
||||
interpretation: "Verdeckte Agenden, schwierige Konsensfindung"
|
||||
|
||||
- id: "regulatorische_grauzonen"
|
||||
signal: "Regulatorische Grauzonen"
|
||||
beschreibung: "Rechtslage unklar oder im Wandel"
|
||||
interpretation: "Compliance-Risiko, Neuorientierung erforderlich"
|
||||
|
||||
- id: "praezedenzfall"
|
||||
signal: "Präzedenzfall"
|
||||
beschreibung: "Erstmalige Herausforderung ohne Referenz"
|
||||
interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungsverfahren:
|
||||
beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung"
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Dimension-Scoring"
|
||||
beschreibung: "Jede der vier Dimensionen separat bewerten"
|
||||
output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Komplexitäts-Aggregation"
|
||||
beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen"
|
||||
logik: "siehe aggregationslogik unten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Kontextuelle Anpassung"
|
||||
beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren"
|
||||
|
||||
aggregationslogik:
|
||||
titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\""
|
||||
|
||||
regeln:
|
||||
- bedingung: "1 Dimension = \"Hochkomplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Ein hochkomplexer Aspekt dominiert"
|
||||
|
||||
- bedingung: "3 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Kumulative Komplexität führt zu Hochkomplexität"
|
||||
|
||||
- bedingung: "2 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Komplex"
|
||||
rationale: "Moderate kumulative Komplexität"
|
||||
|
||||
- bedingung: "ansonsten"
|
||||
ergebnis: "Moderat"
|
||||
rationale: "Überschaubare Komplexität"
|
||||
|
||||
# ========================================
|
||||
# KONSEQUENZEN DER BEWERTUNG
|
||||
# ========================================
|
||||
|
||||
konsequenzen:
|
||||
- komplexitaet: "moderat"
|
||||
konsequenz: "Direkte Umsetzung"
|
||||
typische_massnahmen:
|
||||
- "Standardprozess"
|
||||
- "Keine Sonderanalysen"
|
||||
|
||||
- komplexitaet: "komplex"
|
||||
konsequenz: "Strukturierte Analyse"
|
||||
typische_massnahmen:
|
||||
- "Vorprojekt empfohlen"
|
||||
- "Experteneinbindung"
|
||||
- "Risikomanagement"
|
||||
|
||||
- komplexitaet: "hochkomplex"
|
||||
konsequenz: "Sondierung zwingend"
|
||||
typische_massnahmen:
|
||||
- "Machbarkeitsstudie"
|
||||
- "Pilot/PoC"
|
||||
- "Steering Committee"
|
||||
|
||||
# ========================================
|
||||
# UMGANG MIT KOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
umgang_mit_komplexitaet:
|
||||
bei_hochkomplexitaet:
|
||||
massnahmen:
|
||||
- id: "M1"
|
||||
name: "Komplexitätsreduktion prüfen"
|
||||
frage: "Kann der Demand geteilt werden?"
|
||||
ziel: "Reduzierung auf handhabbare Teilprobleme"
|
||||
|
||||
- id: "M2"
|
||||
name: "Sondierung priorisieren"
|
||||
prinzip: "Keine vorschnellen Lösungsversprechen"
|
||||
ziel: "Exploration vor Commitment"
|
||||
|
||||
- id: "M3"
|
||||
name: "Stakeholder-Zielausrichtung"
|
||||
aktivitaet: "Frühzeitige Erwartungsklärung"
|
||||
ziel: "Konvergenz der Interessen"
|
||||
|
||||
- id: "M4"
|
||||
name: "Iteratives Vorgehen"
|
||||
prinzip: "Schritt-für-Schritt statt \"Big Bang\""
|
||||
ziel: "Schrittweise Komplexitätsreduktion"
|
||||
|
||||
komplexitaetsfallen_vermeiden:
|
||||
beschreibung: "Typische Denkfehler im Umgang mit Komplexität"
|
||||
|
||||
fallen:
|
||||
- falle: "Schein-Einfachheit"
|
||||
beispiel: "\"Wir brauchen nur Tool X\""
|
||||
gegenmassnahme: "Immer nach dem \"Warum\" fragen"
|
||||
|
||||
- falle: "Komplexitäts-Paralysis"
|
||||
beschreibung: "Nicht alles Komplexe ist unlösbar"
|
||||
gegenmassnahme: "Handlungsfähigkeit bewahren"
|
||||
|
||||
- falle: "Oversimplification"
|
||||
beschreibung: "Komplexität nicht wegdefinieren"
|
||||
gegenmassnahme: "Realistische Einschätzung"
|
||||
|
||||
- falle: "Analysis-Paralysis"
|
||||
beschreibung: "Irgendwann muss entschieden werden"
|
||||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "komplexitaet"
|
||||
titel: "Klassifizierungsmatrix Komplexität"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "komplexitaet"
|
||||
- "loesungsunsicherheit"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands.
|
||||
Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell
|
||||
und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert
|
||||
zu bewerten.
|
||||
|
||||
grundverstaendnis: |
|
||||
Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit,
|
||||
sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch
|
||||
einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen
|
||||
Interessen involviert sind.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
bewertungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: STAKEHOLDER & KOORDINATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_stakeholder_koordination:
|
||||
id: "stakeholder_koordination"
|
||||
name: "Stakeholder & Koordination"
|
||||
leitfrage: "Wie viele Akteure müssen koordiniert werden?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "beteiligte_teams"
|
||||
name: "Beteiligte Teams"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Teams"
|
||||
komplex: "3-4 Teams"
|
||||
hochkomplex: "5+ Teams"
|
||||
|
||||
- kriterium_id: "stakeholder_gruppen"
|
||||
name: "Stakeholder-Gruppen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Gruppen"
|
||||
komplex: "3-5 Gruppen"
|
||||
hochkomplex: "6+ Gruppen"
|
||||
|
||||
- kriterium_id: "entscheidungsebene"
|
||||
name: "Entscheidungsebene"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Arbeitsebene"
|
||||
komplex: "Abteilungsleitung"
|
||||
hochkomplex: "Amtsleitung/Politik"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_loesungsraum_unsicherheit:
|
||||
id: "loesungsraum_unsicherheit"
|
||||
name: "Lösungsraum & Unsicherheit"
|
||||
leitfrage: "Wie klar ist der Weg zur Lösung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "loesungsklarheit"
|
||||
name: "Lösungsklarheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Eindeutige Lösung"
|
||||
komplex: "2-3 Optionen"
|
||||
hochkomplex: "Unklar/Exploration nötig"
|
||||
|
||||
- kriterium_id: "technologie_reife"
|
||||
name: "Technologie-Reife"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Bewährt im DIGIT"
|
||||
komplex: "Neu für DIGIT"
|
||||
hochkomplex: "Innovativ/Experimentell"
|
||||
|
||||
- kriterium_id: "anforderungsstabilitaet"
|
||||
name: "Anforderungsstabilität"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Stabil & klar"
|
||||
komplex: "Teilweise unklar"
|
||||
hochkomplex: "Volatil/Undefiniert"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_abhaengigkeiten_integration:
|
||||
id: "abhaengigkeiten_integration"
|
||||
name: "Abhängigkeiten & Integration"
|
||||
leitfrage: "Wie vernetzt ist der Demand?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "externe_partner"
|
||||
name: "Externe Partner"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "1-2 Partner"
|
||||
hochkomplex: "3+ Partner"
|
||||
|
||||
- kriterium_id: "system_schnittstellen"
|
||||
name: "System-Schnittstellen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Systeme"
|
||||
komplex: "3-4 Systeme"
|
||||
hochkomplex: "5+ Systeme"
|
||||
|
||||
- kriterium_id: "zeitliche_abhaengigkeiten"
|
||||
name: "Zeitliche Abhängigkeiten"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Flexibel planbar"
|
||||
komplex: "Teilweise gebunden"
|
||||
hochkomplex: "Kritische Verkettung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: RISIKEN & UNWÄGBARKEITEN
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_risiken_unwaegbarkeiten:
|
||||
id: "risiken_unwaegbarkeiten"
|
||||
name: "Risiken & Unwägbarkeiten"
|
||||
leitfrage: "Wie beherrschbar sind die Risiken?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "budget_unsicherheit"
|
||||
name: "Budget-Unsicherheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Verlässlich planbar"
|
||||
komplex: "Bandbreiten-Schätzung"
|
||||
hochkomplex: "Unkalkulierbar"
|
||||
|
||||
- kriterium_id: "termin_risiko"
|
||||
name: "Termin-Risiko"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Gering"
|
||||
komplex: "Mittel"
|
||||
hochkomplex: "Hoch/Unklar"
|
||||
|
||||
- kriterium_id: "compliance_risiken"
|
||||
name: "Compliance-Risiken"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "Handhabbar"
|
||||
hochkomplex: "Kritisch/Unklar"
|
||||
|
||||
# ========================================
|
||||
# SIGNALE FÜR HOCHKOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
signale_hochkomplexitaet:
|
||||
beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten"
|
||||
|
||||
signale:
|
||||
- id: "paradoxe_anforderungen"
|
||||
signal: "Paradoxe Anforderungen"
|
||||
beispiel: "\"Soll alles können, darf nichts kosten\""
|
||||
interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
- id: "moving_targets"
|
||||
signal: "Moving Targets"
|
||||
beschreibung: "Anforderungen ändern sich während der Analyse"
|
||||
interpretation: "Instabile Ausgangslage, hohe Unsicherheit"
|
||||
|
||||
- id: "interessenskomplexitaet"
|
||||
signal: "Interessenskomplexität"
|
||||
beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen"
|
||||
interpretation: "Verdeckte Agenden, schwierige Konsensfindung"
|
||||
|
||||
- id: "regulatorische_grauzonen"
|
||||
signal: "Regulatorische Grauzonen"
|
||||
beschreibung: "Rechtslage unklar oder im Wandel"
|
||||
interpretation: "Compliance-Risiko, Neuorientierung erforderlich"
|
||||
|
||||
- id: "praezedenzfall"
|
||||
signal: "Präzedenzfall"
|
||||
beschreibung: "Erstmalige Herausforderung ohne Referenz"
|
||||
interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungsverfahren:
|
||||
beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung"
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Dimension-Scoring"
|
||||
beschreibung: "Jede der vier Dimensionen separat bewerten"
|
||||
output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Komplexitäts-Aggregation"
|
||||
beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen"
|
||||
logik: "siehe aggregationslogik unten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Kontextuelle Anpassung"
|
||||
beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren"
|
||||
|
||||
aggregationslogik:
|
||||
titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\""
|
||||
|
||||
regeln:
|
||||
- bedingung: "1 Dimension = \"Hochkomplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Ein hochkomplexer Aspekt dominiert"
|
||||
|
||||
- bedingung: "3 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Kumulative Komplexität führt zu Hochkomplexität"
|
||||
|
||||
- bedingung: "2 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Komplex"
|
||||
rationale: "Moderate kumulative Komplexität"
|
||||
|
||||
- bedingung: "ansonsten"
|
||||
ergebnis: "Moderat"
|
||||
rationale: "Überschaubare Komplexität"
|
||||
|
||||
# ========================================
|
||||
# KONSEQUENZEN DER BEWERTUNG
|
||||
# ========================================
|
||||
|
||||
konsequenzen:
|
||||
- komplexitaet: "moderat"
|
||||
konsequenz: "Direkte Umsetzung"
|
||||
typische_massnahmen:
|
||||
- "Standardprozess"
|
||||
- "Keine Sonderanalysen"
|
||||
|
||||
- komplexitaet: "komplex"
|
||||
konsequenz: "Strukturierte Analyse"
|
||||
typische_massnahmen:
|
||||
- "Vorprojekt empfohlen"
|
||||
- "Experteneinbindung"
|
||||
- "Risikomanagement"
|
||||
|
||||
- komplexitaet: "hochkomplex"
|
||||
konsequenz: "Sondierung zwingend"
|
||||
typische_massnahmen:
|
||||
- "Machbarkeitsstudie"
|
||||
- "Pilot/PoC"
|
||||
- "Steering Committee"
|
||||
|
||||
# ========================================
|
||||
# UMGANG MIT KOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
umgang_mit_komplexitaet:
|
||||
bei_hochkomplexitaet:
|
||||
massnahmen:
|
||||
- id: "M1"
|
||||
name: "Komplexitätsreduktion prüfen"
|
||||
frage: "Kann der Demand geteilt werden?"
|
||||
ziel: "Reduzierung auf handhabbare Teilprobleme"
|
||||
|
||||
- id: "M2"
|
||||
name: "Sondierung priorisieren"
|
||||
prinzip: "Keine vorschnellen Lösungsversprechen"
|
||||
ziel: "Exploration vor Commitment"
|
||||
|
||||
- id: "M3"
|
||||
name: "Stakeholder-Zielausrichtung"
|
||||
aktivitaet: "Frühzeitige Erwartungsklärung"
|
||||
ziel: "Konvergenz der Interessen"
|
||||
|
||||
- id: "M4"
|
||||
name: "Iteratives Vorgehen"
|
||||
prinzip: "Schritt-für-Schritt statt \"Big Bang\""
|
||||
ziel: "Schrittweise Komplexitätsreduktion"
|
||||
|
||||
komplexitaetsfallen_vermeiden:
|
||||
beschreibung: "Typische Denkfehler im Umgang mit Komplexität"
|
||||
|
||||
fallen:
|
||||
- falle: "Schein-Einfachheit"
|
||||
beispiel: "\"Wir brauchen nur Tool X\""
|
||||
gegenmassnahme: "Immer nach dem \"Warum\" fragen"
|
||||
|
||||
- falle: "Komplexitäts-Paralysis"
|
||||
beschreibung: "Nicht alles Komplexe ist unlösbar"
|
||||
gegenmassnahme: "Handlungsfähigkeit bewahren"
|
||||
|
||||
- falle: "Oversimplification"
|
||||
beschreibung: "Komplexität nicht wegdefinieren"
|
||||
gegenmassnahme: "Realistische Einschätzung"
|
||||
|
||||
- falle: "Analysis-Paralysis"
|
||||
beschreibung: "Irgendwann muss entschieden werden"
|
||||
gegenmassnahme: "Entscheidungszeitpunkt definieren"
|
||||
|
|
@ -1,295 +1,295 @@
|
|||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "tragweite"
|
||||
titel: "Klassifizierungsmatrix Tragweite"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "tragweite"
|
||||
- "veraenderungstiefe"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix dient der detaillierten Einordnung von Demands in die
|
||||
Dimension "Tragweite". Sie erweitert die Grunddefinitionen aus dem
|
||||
Klassifizierungsmodell um konkrete Bewertungskriterien und unterstützt DPMs
|
||||
bei der Einschätzung der Veränderungstiefe.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSPERSPEKTIVEN
|
||||
# ========================================
|
||||
|
||||
bewertungsperspektiven:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier komplementäre Perspektiven zur Bewertung der Tragweite"
|
||||
prinzip: "Dominanz-Prinzip: Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 1: NUTZER:INNEN
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_1_nutzerinnen:
|
||||
id: "nutzerinnen"
|
||||
name: "Nutzer:innen-Perspektive"
|
||||
leitfrage: "Wie stark verändert sich die Arbeitsweise der Endanwender:innen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "schulungsbedarf"
|
||||
name: "Schulungsbedarf"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Schulungen nötig"
|
||||
ausbau: "Punktuelle Schulungen"
|
||||
neugestaltung: "Flächendeckende Schulungen"
|
||||
|
||||
- kriterium_id: "verhaltensaenderung"
|
||||
name: "Verhaltensänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Minimale Anpassung"
|
||||
ausbau: "Neue Funktionen lernen"
|
||||
neugestaltung: "Neue Arbeitsweisen"
|
||||
|
||||
- kriterium_id: "nutzer_impact"
|
||||
name: "Nutzer-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% merken Veränderung"
|
||||
ausbau: "20-70% betroffen"
|
||||
neugestaltung: "> 70% der Nutzer betroffen"
|
||||
|
||||
- kriterium_id: "rueckfallmoeglichkeit"
|
||||
name: "Rückfallmöglichkeit"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Jederzeit möglich"
|
||||
ausbau: "Mit Aufwand möglich"
|
||||
neugestaltung: "Nicht mehr möglich"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 2: TECHNISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_2_technisch:
|
||||
id: "technisch"
|
||||
name: "Technische Perspektive"
|
||||
leitfrage: "Wie tiefgreifend sind die technischen Veränderungen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "betroffenheit_anwendungen"
|
||||
name: "Betroffenheit von Anwendungen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% Anwendungen betroffen"
|
||||
ausbau: "20-70% Anwendungen betroffen"
|
||||
neugestaltung: "> 70% Anwendungen betroffen"
|
||||
|
||||
- kriterium_id: "systemgrenzen"
|
||||
name: "Systemgrenzen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Innerhalb eines Systems"
|
||||
ausbau: "Systemübergreifend"
|
||||
neugestaltung: "Systemlandschaft-Umbau"
|
||||
|
||||
- kriterium_id: "technologie_stack"
|
||||
name: "Technologie-Stack"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Bestehende Technologien"
|
||||
ausbau: "Ergänzung neuer Technologie"
|
||||
neugestaltung: "Technologiewechsel"
|
||||
|
||||
- kriterium_id: "datenmigration"
|
||||
name: "Datenmigration"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine erforderlich"
|
||||
ausbau: "Teilmigration"
|
||||
neugestaltung: "Vollmigration"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 3: ORGANISATORISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_3_organisatorisch:
|
||||
id: "organisatorisch"
|
||||
name: "Organisatorische Perspektive"
|
||||
leitfrage: "Wie stark verändern sich Prozesse und Strukturen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "prozessaenderung"
|
||||
name: "Prozessänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Optimierung im Detail"
|
||||
ausbau: "Prozesserweiterung"
|
||||
neugestaltung: "Prozess-Neudesign"
|
||||
|
||||
- kriterium_id: "rollenveraenderung"
|
||||
name: "Rollenveränderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine"
|
||||
ausbau: "Neue/veränderte Aufgaben"
|
||||
neugestaltung: "Neue Rollen/Stellen"
|
||||
|
||||
- kriterium_id: "aemter_uebergreifend"
|
||||
name: "Ämter-übergreifend"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Ein Amt"
|
||||
ausbau: "2-3 Ämter"
|
||||
neugestaltung: "Gesamtorganisation"
|
||||
|
||||
- kriterium_id: "abteilungs_uebergreifend_digit"
|
||||
name: "Abteilungs-übergreifend (DIGIT)"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Eine Abteilung"
|
||||
ausbau: "2-3 Abteilungen"
|
||||
neugestaltung: "Gesamt-DIGIT"
|
||||
|
||||
- kriterium_id: "governance_impact"
|
||||
name: "Governance-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Änderung"
|
||||
ausbau: "Anpassung nötig"
|
||||
neugestaltung: "Neue Governance"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 4: FINANZIELL
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_4_finanziell:
|
||||
id: "finanziell"
|
||||
name: "Finanzielle Perspektive"
|
||||
leitfrage: "Welche finanziellen Auswirkungen hat die Veränderung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "investitionsvolumen_extern"
|
||||
name: "Externes Investitionsvolumen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 50.000 €"
|
||||
ausbau: "50.000 - 200.000 €"
|
||||
neugestaltung: "> 200.000 €"
|
||||
|
||||
- kriterium_id: "folgekosten"
|
||||
name: "Folgekosten"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Marginal"
|
||||
ausbau: "Moderat"
|
||||
neugestaltung: "Erheblich"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungslogik:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Perspektiven-Bewertung"
|
||||
beschreibung: "Jede der vier Perspektiven wird separat bewertet"
|
||||
output: "4 Einzelbewertungen (Optimierung/Ausbau/Neugestaltung)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Dominanz-Prinzip"
|
||||
beschreibung: "Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
rationale: "Ein transformativer Aspekt reicht, um den gesamten Demand als transformativ einzustufen"
|
||||
|
||||
- schritt: 3
|
||||
name: "Begründungspflicht"
|
||||
beschreibung: "Bei Abweichungen zwischen Perspektiven ist eine explizite Begründung erforderlich"
|
||||
ziel: "Nachvollziehbarkeit und Lerneffekte"
|
||||
|
||||
# ========================================
|
||||
# GRENZFÄLLE UND INTERPRETATIONSHILFEN
|
||||
# ========================================
|
||||
|
||||
grenzfaelle:
|
||||
typische_indikatoren_neugestaltung:
|
||||
beschreibung: "Signale für transformative/neugestaltende Demands"
|
||||
|
||||
indikatoren:
|
||||
- "Ablösung von Altsystemen"
|
||||
- "Gesetzlich getriebene Paradigmenwechsel"
|
||||
- "Einführung völlig neuer Geschäftsmodelle"
|
||||
- "Fundamentale Änderung der Nutzer:innen-Interaktion"
|
||||
|
||||
abgrenzung_optimierung_vs_ausbau:
|
||||
optimierung_inkrementell:
|
||||
beschreibung: "Verbesserung des Bestehenden ohne neue Konzepte"
|
||||
beispiele:
|
||||
- "UI-Verbesserungen"
|
||||
- "Performance-Optimierung"
|
||||
- "Bugfixes"
|
||||
|
||||
ausbau_evolutionaer:
|
||||
beschreibung: "Hinzufügen neuer Fähigkeiten zum bestehenden System"
|
||||
beispiele:
|
||||
- "Neue Module"
|
||||
- "API-Erweiterungen"
|
||||
- "Prozessdigitalisierung"
|
||||
|
||||
umgang_mit_unsicherheit:
|
||||
beschreibung: "Vorgehen bei unklarer Einordnung"
|
||||
|
||||
massnahmen:
|
||||
- schritt: 1
|
||||
name: "Workshop mit betroffenen Stakeholdern"
|
||||
ziel: "Verschiedene Perspektiven integrieren"
|
||||
|
||||
- schritt: 2
|
||||
name: "Pilot-Phase zur Validierung der Tragweite"
|
||||
ziel: "Empirische Klärung"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vorsichtsprinzip"
|
||||
regel: "Im Zweifel: Höhere Kategorie wählen"
|
||||
rationale: "Unterschätzung vermeiden"
|
||||
|
||||
# ========================================
|
||||
# DOKUMENTATIONSANFORDERUNG
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
template:
|
||||
struktur: |
|
||||
TRAGWEITEN-ANALYSE
|
||||
|
||||
Nutzer:innen: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Technisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Organisatorisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Finanziell: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
GESAMTTRAGWEITE: [Kategorie]
|
||||
|
||||
BEGRÜNDUNG: [Warum diese Einordnung, insb. bei Divergenz]
|
||||
|
||||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "tragweite"
|
||||
titel: "Klassifizierungsmatrix Tragweite"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "tragweite"
|
||||
- "veraenderungstiefe"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix dient der detaillierten Einordnung von Demands in die
|
||||
Dimension "Tragweite". Sie erweitert die Grunddefinitionen aus dem
|
||||
Klassifizierungsmodell um konkrete Bewertungskriterien und unterstützt DPMs
|
||||
bei der Einschätzung der Veränderungstiefe.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSPERSPEKTIVEN
|
||||
# ========================================
|
||||
|
||||
bewertungsperspektiven:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier komplementäre Perspektiven zur Bewertung der Tragweite"
|
||||
prinzip: "Dominanz-Prinzip: Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 1: NUTZER:INNEN
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_1_nutzerinnen:
|
||||
id: "nutzerinnen"
|
||||
name: "Nutzer:innen-Perspektive"
|
||||
leitfrage: "Wie stark verändert sich die Arbeitsweise der Endanwender:innen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "schulungsbedarf"
|
||||
name: "Schulungsbedarf"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Schulungen nötig"
|
||||
ausbau: "Punktuelle Schulungen"
|
||||
neugestaltung: "Flächendeckende Schulungen"
|
||||
|
||||
- kriterium_id: "verhaltensaenderung"
|
||||
name: "Verhaltensänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Minimale Anpassung"
|
||||
ausbau: "Neue Funktionen lernen"
|
||||
neugestaltung: "Neue Arbeitsweisen"
|
||||
|
||||
- kriterium_id: "nutzer_impact"
|
||||
name: "Nutzer-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% merken Veränderung"
|
||||
ausbau: "20-70% betroffen"
|
||||
neugestaltung: "> 70% der Nutzer betroffen"
|
||||
|
||||
- kriterium_id: "rueckfallmoeglichkeit"
|
||||
name: "Rückfallmöglichkeit"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Jederzeit möglich"
|
||||
ausbau: "Mit Aufwand möglich"
|
||||
neugestaltung: "Nicht mehr möglich"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 2: TECHNISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_2_technisch:
|
||||
id: "technisch"
|
||||
name: "Technische Perspektive"
|
||||
leitfrage: "Wie tiefgreifend sind die technischen Veränderungen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "betroffenheit_anwendungen"
|
||||
name: "Betroffenheit von Anwendungen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% Anwendungen betroffen"
|
||||
ausbau: "20-70% Anwendungen betroffen"
|
||||
neugestaltung: "> 70% Anwendungen betroffen"
|
||||
|
||||
- kriterium_id: "systemgrenzen"
|
||||
name: "Systemgrenzen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Innerhalb eines Systems"
|
||||
ausbau: "Systemübergreifend"
|
||||
neugestaltung: "Systemlandschaft-Umbau"
|
||||
|
||||
- kriterium_id: "technologie_stack"
|
||||
name: "Technologie-Stack"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Bestehende Technologien"
|
||||
ausbau: "Ergänzung neuer Technologie"
|
||||
neugestaltung: "Technologiewechsel"
|
||||
|
||||
- kriterium_id: "datenmigration"
|
||||
name: "Datenmigration"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine erforderlich"
|
||||
ausbau: "Teilmigration"
|
||||
neugestaltung: "Vollmigration"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 3: ORGANISATORISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_3_organisatorisch:
|
||||
id: "organisatorisch"
|
||||
name: "Organisatorische Perspektive"
|
||||
leitfrage: "Wie stark verändern sich Prozesse und Strukturen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "prozessaenderung"
|
||||
name: "Prozessänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Optimierung im Detail"
|
||||
ausbau: "Prozesserweiterung"
|
||||
neugestaltung: "Prozess-Neudesign"
|
||||
|
||||
- kriterium_id: "rollenveraenderung"
|
||||
name: "Rollenveränderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine"
|
||||
ausbau: "Neue/veränderte Aufgaben"
|
||||
neugestaltung: "Neue Rollen/Stellen"
|
||||
|
||||
- kriterium_id: "aemter_uebergreifend"
|
||||
name: "Ämter-übergreifend"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Ein Amt"
|
||||
ausbau: "2-3 Ämter"
|
||||
neugestaltung: "Gesamtorganisation"
|
||||
|
||||
- kriterium_id: "abteilungs_uebergreifend_digit"
|
||||
name: "Abteilungs-übergreifend (DIGIT)"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Eine Abteilung"
|
||||
ausbau: "2-3 Abteilungen"
|
||||
neugestaltung: "Gesamt-DIGIT"
|
||||
|
||||
- kriterium_id: "governance_impact"
|
||||
name: "Governance-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Änderung"
|
||||
ausbau: "Anpassung nötig"
|
||||
neugestaltung: "Neue Governance"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 4: FINANZIELL
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_4_finanziell:
|
||||
id: "finanziell"
|
||||
name: "Finanzielle Perspektive"
|
||||
leitfrage: "Welche finanziellen Auswirkungen hat die Veränderung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "investitionsvolumen_extern"
|
||||
name: "Externes Investitionsvolumen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 50.000 €"
|
||||
ausbau: "50.000 - 200.000 €"
|
||||
neugestaltung: "> 200.000 €"
|
||||
|
||||
- kriterium_id: "folgekosten"
|
||||
name: "Folgekosten"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Marginal"
|
||||
ausbau: "Moderat"
|
||||
neugestaltung: "Erheblich"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungslogik:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Perspektiven-Bewertung"
|
||||
beschreibung: "Jede der vier Perspektiven wird separat bewertet"
|
||||
output: "4 Einzelbewertungen (Optimierung/Ausbau/Neugestaltung)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Dominanz-Prinzip"
|
||||
beschreibung: "Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
rationale: "Ein transformativer Aspekt reicht, um den gesamten Demand als transformativ einzustufen"
|
||||
|
||||
- schritt: 3
|
||||
name: "Begründungspflicht"
|
||||
beschreibung: "Bei Abweichungen zwischen Perspektiven ist eine explizite Begründung erforderlich"
|
||||
ziel: "Nachvollziehbarkeit und Lerneffekte"
|
||||
|
||||
# ========================================
|
||||
# GRENZFÄLLE UND INTERPRETATIONSHILFEN
|
||||
# ========================================
|
||||
|
||||
grenzfaelle:
|
||||
typische_indikatoren_neugestaltung:
|
||||
beschreibung: "Signale für transformative/neugestaltende Demands"
|
||||
|
||||
indikatoren:
|
||||
- "Ablösung von Altsystemen"
|
||||
- "Gesetzlich getriebene Paradigmenwechsel"
|
||||
- "Einführung völlig neuer Geschäftsmodelle"
|
||||
- "Fundamentale Änderung der Nutzer:innen-Interaktion"
|
||||
|
||||
abgrenzung_optimierung_vs_ausbau:
|
||||
optimierung_inkrementell:
|
||||
beschreibung: "Verbesserung des Bestehenden ohne neue Konzepte"
|
||||
beispiele:
|
||||
- "UI-Verbesserungen"
|
||||
- "Performance-Optimierung"
|
||||
- "Bugfixes"
|
||||
|
||||
ausbau_evolutionaer:
|
||||
beschreibung: "Hinzufügen neuer Fähigkeiten zum bestehenden System"
|
||||
beispiele:
|
||||
- "Neue Module"
|
||||
- "API-Erweiterungen"
|
||||
- "Prozessdigitalisierung"
|
||||
|
||||
umgang_mit_unsicherheit:
|
||||
beschreibung: "Vorgehen bei unklarer Einordnung"
|
||||
|
||||
massnahmen:
|
||||
- schritt: 1
|
||||
name: "Workshop mit betroffenen Stakeholdern"
|
||||
ziel: "Verschiedene Perspektiven integrieren"
|
||||
|
||||
- schritt: 2
|
||||
name: "Pilot-Phase zur Validierung der Tragweite"
|
||||
ziel: "Empirische Klärung"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vorsichtsprinzip"
|
||||
regel: "Im Zweifel: Höhere Kategorie wählen"
|
||||
rationale: "Unterschätzung vermeiden"
|
||||
|
||||
# ========================================
|
||||
# DOKUMENTATIONSANFORDERUNG
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
template:
|
||||
struktur: |
|
||||
TRAGWEITEN-ANALYSE
|
||||
|
||||
Nutzer:innen: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Technisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Organisatorisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Finanziell: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
GESAMTTRAGWEITE: [Kategorie]
|
||||
|
||||
BEGRÜNDUNG: [Warum diese Einordnung, insb. bei Divergenz]
|
||||
|
||||
hinweis: "Bei divergierenden Perspektiven muss erklärt werden, warum eine Perspektive dominiert"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -1,493 +1,493 @@
|
|||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Manager:in"
|
||||
aliases: ["DPM", "Portfolio-Manager", "Demand-Manager"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
ueberprueft_durch: "DPM-Teammitglied"
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
hinweis: "anpassen auf Basis der weiteren Workstream-Ergebnisse"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "portfolio-steuerung"
|
||||
- "qualifizierung"
|
||||
- "bewertung"
|
||||
- "priorisierung"
|
||||
|
||||
# ========================================
|
||||
# 1. ROLLENZWECK
|
||||
# ========================================
|
||||
|
||||
rollenzweck:
|
||||
kurz: "Zentrale Instanz für Qualifizierung, Bewertung und Portfolio-Steuerung aller Demands im DIGIT"
|
||||
|
||||
ausfuehrlich: |
|
||||
Der:die Demand-Portfolio-Manager:in transformiert vorqualifizierte Demands in
|
||||
Demand-Entscheidungsvorlagen und schafft die Grundlage für optimale
|
||||
Ressourcensteuerung durch die verantwortlichen Gremien.
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "nach erfolgter Bedarfsklärung durch Stakeholder-Management"
|
||||
fuer: "alle Demands"
|
||||
bis: "Aufbereitung für Entscheidungsgremien"
|
||||
|
||||
entscheidungsgremien:
|
||||
- gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
- gremium_id: "mission_board"
|
||||
gremium_name: "Mission Board"
|
||||
|
||||
# ========================================
|
||||
# 2. ORGANISATORISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
organisatorische_einordnung:
|
||||
zuordnung:
|
||||
abteilung: "Abteilung Planung"
|
||||
abteilungskuerzel: "AL-P"
|
||||
|
||||
auspraegungen:
|
||||
beschreibung: "Spezialisierungen nach Themenfeld oder Kapazität möglich, aber nicht strukturell vorgegeben"
|
||||
hinweis: |
|
||||
Die frühere Unterscheidung in DPM Core-IT und DPM Non-Core-IT entfällt.
|
||||
Alle Demands – unabhängig von ihrer Herkunft (Betrieb oder Innovation) –
|
||||
durchlaufen denselben Prozess. Spezialisierungen können bei Bedarf
|
||||
themenfeld- oder kapazitätsbezogen entstehen.
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "Abteilungsleitung Planung"
|
||||
berichtet_an_rolle_id: "al_p"
|
||||
|
||||
arbeitsmodell:
|
||||
typ: "Vollzeitfunktion"
|
||||
vertretung: "gegenseitige Vertretungsregelung zwischen DPM-Mitarbeitenden"
|
||||
|
||||
# ========================================
|
||||
# 3. KERNVERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
kernverantwortlichkeiten:
|
||||
bereich_1_portfolio_management:
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
aufgaben:
|
||||
- id: "PM-01"
|
||||
titel: "Portfolio-Aufbau und -Pflege"
|
||||
beschreibung: "Aufbau und Pflege eines transparenten Demand-Portfolios"
|
||||
frequenz: "kontinuierlich"
|
||||
output: "aktuelles_demand_portfolio"
|
||||
|
||||
- id: "PM-02"
|
||||
titel: "Strategische Portfolio-Analyse"
|
||||
beschreibung: "Strategische Analyse des Demand-Portfolios und Identifizierung von Trends für das Mission Board"
|
||||
frequenz: "quartalsweise"
|
||||
output: "portfolio_trend_analyse"
|
||||
empfaenger: "mission_board"
|
||||
|
||||
- id: "PM-03"
|
||||
titel: "Portfolio-Optimierung"
|
||||
beschreibung: "Kontinuierliche Optimierung der Demand-Portfolio-Zusammensetzung"
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
- id: "PM-04"
|
||||
titel: "Strategiekonformität sicherstellen"
|
||||
beschreibung: "Bewertung und Priorisierung von Demands gemäß der strategischen Leitplanken des Vision Board"
|
||||
referenz_zu: "vision_board"
|
||||
frequenz: "pro_demand"
|
||||
|
||||
bereich_2_demand_qualifizierung:
|
||||
name: "Demand-Qualifizierung, Bewertung und Priorisierung"
|
||||
|
||||
aufgaben:
|
||||
- id: "QBP-01"
|
||||
titel: "Demand-Übernahme"
|
||||
beschreibung: "Übernahme vorqualifizierter Demands vom Stakeholder-Management"
|
||||
von_rolle: "shm"
|
||||
trigger: "demand_uebergabe_quality_gate_1"
|
||||
|
||||
- id: "QBP-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands nach vordefinierten Dimensionen"
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
output: "demand_kategorie"
|
||||
|
||||
- id: "QBP-03"
|
||||
titel: "Demand-Analyse"
|
||||
beschreibung: "Analyse von Demands nach fachlichen und technischen Aspekten und Abhängigkeiten"
|
||||
aspekte:
|
||||
- "fachliche Anforderungen"
|
||||
- "technische Machbarkeit"
|
||||
- "Abhängigkeiten zu anderen Demands/Projekten"
|
||||
output: "analyse_ergebnis"
|
||||
|
||||
- id: "QBP-04"
|
||||
titel: "Demand-Bewertung"
|
||||
beschreibung: "Bewertung und Clusterung von Demands nach qualitativen Bewertungskategorien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
|
||||
- id: "QBP-05"
|
||||
titel: "Demand-Priorisierung"
|
||||
beschreibung: "Priorisierung von Demands nach definiertem Standard und Ableitung von Handlungsempfehlungen"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
|
||||
- id: "QBP-06"
|
||||
titel: "Entscheidungsvorlagen erstellen"
|
||||
beschreibung: "Erstellung von Demand-Entscheidungsvorlagen für Entscheidungsgremien"
|
||||
output: "demand_entscheidungsvorlage"
|
||||
empfaenger: ["dsr", "mission_board"]
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
name: "Gremienarbeit"
|
||||
|
||||
aufgaben:
|
||||
- id: "GR-01"
|
||||
titel: "DSR-Vorbereitung"
|
||||
beschreibung: "Vorbereitung und Präsentation/Diskussion in der Demand & Stakeholder-Runde (DSR) zur Entscheidung"
|
||||
gremium: "dsr"
|
||||
rolle_in_gremium: "vorsitz"
|
||||
frequenz: "woechentlich"
|
||||
aktivitaeten:
|
||||
- "Agenda erstellen"
|
||||
- "Materialien vorbereiten"
|
||||
- "Präsentation vorbereiten"
|
||||
- "Moderation durchführen"
|
||||
|
||||
- id: "GR-02"
|
||||
titel: "Portfolio-Überblick Mission Board"
|
||||
beschreibung: "Demand-Portfolio Überblick im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
output: "portfolio_status_update"
|
||||
|
||||
- id: "GR-03"
|
||||
titel: "Entscheidungsvorlagen präsentieren"
|
||||
beschreibung: "Vorstellung der Demand-Entscheidungsvorlagen im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
- id: "GR-04"
|
||||
titel: "Entscheidungsfähigkeit sicherstellen"
|
||||
beschreibung: "Sicherstellung der Entscheidungsfähigkeit durch Bereitstellung der Demand-Entscheidungsvorlage"
|
||||
kritikalitaet: "hoch"
|
||||
qualitaetskriterium: "vollständige und präzise Entscheidungsgrundlagen"
|
||||
|
||||
- id: "GR-05"
|
||||
titel: "Gremienbeschlüsse umsetzen"
|
||||
beschreibung: "Umsetzung und Nachbearbeitung auf Basis von Gremienbeschlüssen"
|
||||
aktivitaeten:
|
||||
- "Statusänderungen im Portfolio"
|
||||
- "Kommunikation an Stakeholder (via SHM)"
|
||||
- "Übergabe an PPM (bei Freigabe)"
|
||||
- "Dokumentation"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN UND ZUSAMMENARBEIT
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
primaer:
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_shm_zu_dpm"
|
||||
themen:
|
||||
- "Übernahme vorqualifizierter Demands"
|
||||
- "Rückfragen bei Unvollständigkeit"
|
||||
frequenz: "kontinuierlich"
|
||||
artefakte:
|
||||
input: "bedarfs_steckbrief"
|
||||
output: "rueckfragen_oder_uebernahmebestaetigung"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_dpm_zu_ppm"
|
||||
themen:
|
||||
- "Übergabe freigegebener Demands zur (Vor-)Projektumsetzung"
|
||||
trigger: "demand_freigabe_durch_gremium"
|
||||
artefakte:
|
||||
input: "freigegebener_demand"
|
||||
output: "projektaufnahme_bestaetigung"
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
art: "koordinativ"
|
||||
richtung: "bidirektional"
|
||||
themen:
|
||||
- "Abstimmung zu Service-Bezug"
|
||||
- "Klärung: direkte Umsetzung vs. Projekt"
|
||||
frequenz: "bei_bedarf_pro_demand"
|
||||
kontext: "Besonders relevant bei Demands mit Service-Impact"
|
||||
|
||||
sekundaer:
|
||||
- rolle_id: "it_architektur"
|
||||
rolle_name: "IT-Architektur"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Klärung strategischer Grundsatzfragen"
|
||||
- "Klärung technischer Grundsatzfragen"
|
||||
frequenz: "bei_bedarf"
|
||||
trigger: "komplexe_technische_anforderungen"
|
||||
|
||||
- bezeichnung: "Fachexpert:innen"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Einholung spezifischer Expertise"
|
||||
frequenz: "bei_bedarf"
|
||||
beispiele:
|
||||
- "Datenschutzexpert:innen"
|
||||
- "Sicherheitsexpert:innen"
|
||||
- "Fachbereichsexpert:innen"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ========================================
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
eigenstaendige_entscheidungen:
|
||||
beschreibung: "Entscheidungen, die der DPM ohne Gremienabstimmung treffen kann"
|
||||
|
||||
liste:
|
||||
- id: "ENT-01"
|
||||
titel: "Demand-Rückweisung"
|
||||
beschreibung: "Rückweisung unzureichend vorqualifizierter Demands an das Stakeholder-Management zur konkreten Nachbearbeitung"
|
||||
bedingung: "unzureichende_qualitaet_oder_vollstaendigkeit"
|
||||
rueckweisung_an: "shm"
|
||||
|
||||
- id: "ENT-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands gemäß der vordefinierten Dimensionen"
|
||||
bindend: true
|
||||
kann_ueberstimmt_werden_von: ["dsr", "mission_board"]
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "ENT-03"
|
||||
titel: "Demand-Konsolidierung"
|
||||
beschreibung: "Konsolidierung ähnlicher oder zusammengehöriger Demands"
|
||||
rationale: "Vermeidung von Redundanzen und Synergienutzung"
|
||||
|
||||
- id: "ENT-04"
|
||||
titel: "Expert:innen-Einbindung"
|
||||
beschreibung: "Einbeziehung von Fachexpert:innen"
|
||||
kontext: "Bei Bedarf für fundierte Analyse und Bewertung"
|
||||
|
||||
empfehlungen_fuer_gremien:
|
||||
beschreibung: "DPM bereitet Entscheidungen vor, finales Votum liegt bei Gremien"
|
||||
|
||||
liste:
|
||||
- id: "EMP-01"
|
||||
titel: "Bewertungsprofile"
|
||||
beschreibung: "Bewertungsprofile mit qualitativen Cluster-Fazits als Diskussionsgrundlage für Gremien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
- id: "EMP-02"
|
||||
titel: "Priorisierungs-Empfehlung"
|
||||
beschreibung: "Priorisierung- und Handlungsempfehlung für Demands"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
qualitaetssicherung:
|
||||
beschreibung: "Recht und Pflicht zur Sicherstellung methodischer und prozessualer Qualität"
|
||||
|
||||
liste:
|
||||
- id: "QS-01"
|
||||
titel: "Standards durchsetzen"
|
||||
beschreibung: "Standards für Demand-Dokumentationen und -Bewertung durchzusetzen"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-02"
|
||||
titel: "Methodentreue einfordern"
|
||||
beschreibung: "Methodentreue bei allen Prozessbeteiligten einzufordern"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-03"
|
||||
titel: "Transparenz sicherstellen"
|
||||
beschreibung: "Transparenz durch vollständige Demand-Portfolio-Dokumentation sicherzustellen"
|
||||
output: "vollstaendiges_demand_portfolio"
|
||||
|
||||
- id: "QS-04"
|
||||
titel: "Verbesserungen vorschlagen"
|
||||
beschreibung: "Verbesserungen für Prozesse und Methoden basierend auf Erfahrungswerten vorzuschlagen"
|
||||
empfaenger: ["al_p", "mission_board"]
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
# ========================================
|
||||
# 6. WERKZEUGE UND METHODEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_und_methoden:
|
||||
it_werkzeuge:
|
||||
- id: "TOOL-01"
|
||||
name: "Ticketsystem"
|
||||
zweck: "Zentrale Dokumentation und Statusverfolgung"
|
||||
verwendung: "alle_demands"
|
||||
|
||||
- id: "TOOL-02"
|
||||
name: "Demand-Portfolio-Datenbank"
|
||||
zweck: "Transparente Übersicht aller Demands"
|
||||
features:
|
||||
- "Portfolio-Übersicht"
|
||||
- "Status-Tracking"
|
||||
- "Reporting-Funktionen"
|
||||
|
||||
standardvorlagen:
|
||||
- id: "TPL-01"
|
||||
name: "Demand-Entscheidungsvorlage"
|
||||
verwendung: "für_gremienpraesentation"
|
||||
zielgruppe: ["dsr", "mission_board"]
|
||||
|
||||
- id: "TPL-02"
|
||||
name: "Bedarfs-Steckbrief"
|
||||
verwendung: "input_von_shm"
|
||||
status: "wird_geprueft_und_erweitert"
|
||||
|
||||
methoden:
|
||||
- id: "METH-01"
|
||||
name: "Demand-Kategorien"
|
||||
beschreibung: "Standardisierte Methodik zur Qualifizierung und Kategorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "METH-02"
|
||||
name: "Bewertungskriterien"
|
||||
beschreibung: "Standardisierte Methodik zur Bewertung von Demands"
|
||||
referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
- id: "METH-03"
|
||||
name: "Priorisierungsmethodik"
|
||||
beschreibung: "Standardisierte Methodik zur Priorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 7. ERFORDERLICHE KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
erforderliche_kompetenzen:
|
||||
fachlich:
|
||||
- id: "FK-01"
|
||||
kompetenz: "IT-Landschaft"
|
||||
beschreibung: "Fundiertes Verständnis der IT-Landschaft und digitalen Services"
|
||||
niveau: "fundiert"
|
||||
|
||||
- id: "FK-02"
|
||||
kompetenz: "Demand-Portfolio-Management"
|
||||
beschreibung: "Expertise in Demand-Portfolio-Management und Business-Analyse"
|
||||
niveau: "expertise"
|
||||
|
||||
- id: "FK-03"
|
||||
kompetenz: "Projektmanagement"
|
||||
beschreibung: "Kenntnisse in Projektmanagement"
|
||||
niveau: "kenntnisse"
|
||||
|
||||
- id: "FK-04"
|
||||
kompetenz: "Verwaltungsprozesse"
|
||||
beschreibung: "Verwaltungsspezifisches Prozessverständnis"
|
||||
niveau: "verstaendnis"
|
||||
kontext: "Öffentliche Verwaltung, kommunale Strukturen"
|
||||
|
||||
methodisch:
|
||||
- id: "MK-01"
|
||||
kompetenz: "Analytisches Denken"
|
||||
beschreibung: "Analytisches und strategisches Denkvermögen"
|
||||
anwendung: "Demand-Analyse, Portfolio-Trends identifizieren"
|
||||
|
||||
- id: "MK-02"
|
||||
kompetenz: "Strukturierte Arbeitsweise"
|
||||
beschreibung: "Strukturierte Arbeitsweise und Komplexitätsmanagement"
|
||||
anwendung: "Parallele Bearbeitung vieler Demands"
|
||||
|
||||
- id: "MK-03"
|
||||
kompetenz: "Präsentation und Moderation"
|
||||
beschreibung: "Präsentations- und Moderationskompetenz"
|
||||
anwendung: "Gremienarbeit, DSR-Vorsitz"
|
||||
|
||||
- id: "MK-04"
|
||||
kompetenz: "Konfliktlösung"
|
||||
beschreibung: "Konfliktlösungsfähigkeit"
|
||||
anwendung: "Dissens in DSR, konkurrierende Stakeholder-Interessen"
|
||||
|
||||
sozial:
|
||||
- id: "SK-01"
|
||||
kompetenz: "Kommunikation"
|
||||
beschreibung: "Exzellente Kommunikationsfähigkeit über alle Hierarchieebenen"
|
||||
kritikalitaet: "hoch"
|
||||
kontext: "Von Fachexpert:innen bis Amtsleitung"
|
||||
|
||||
- id: "SK-02"
|
||||
kompetenz: "Diplomatisches Geschick"
|
||||
beschreibung: "Diplomatisches Geschick und Neutralität"
|
||||
anwendung: "Vermittlung zwischen divergierenden Interessen"
|
||||
kritikalitaet: "hoch"
|
||||
|
||||
- id: "SK-03"
|
||||
kompetenz: "Teamfähigkeit"
|
||||
beschreibung: "Teamfähigkeit und Serviceorientierung"
|
||||
kontext: "Zusammenarbeit mit SHM, SPM, PPM"
|
||||
|
||||
- id: "SK-04"
|
||||
kompetenz: "Durchsetzungsvermögen"
|
||||
beschreibung: "Durchsetzungsvermögen bei gleichzeitiger Kompromissbereitschaft"
|
||||
anwendung: "Methodentreue einfordern vs. pragmatische Lösungen finden"
|
||||
|
||||
# ========================================
|
||||
# 8. ERFOLGSFAKTOREN
|
||||
# ========================================
|
||||
|
||||
erfolgsfaktoren:
|
||||
beschreibung: "Kritische Rahmenbedingungen für erfolgreiche Rollenausübung"
|
||||
|
||||
faktoren:
|
||||
- id: "EF-01"
|
||||
titel: "Klare Prozessdefinition"
|
||||
beschreibung: "Umfängliche Nutzung des Demand-to-Project-Prozesses"
|
||||
abhaengigkeit: "Alle Beteiligten halten sich an definierten Prozess"
|
||||
risiko_bei_fehlen: "Umgehung des DPM, inkonsistente Demand-Behandlung"
|
||||
|
||||
- id: "EF-02"
|
||||
titel: "Management-Unterstützung"
|
||||
beschreibung: "Rückendeckung durch Amtsleitung und Gremien"
|
||||
abhaengigkeit: "Amtsleitung stärkt DPM-Rolle aktiv"
|
||||
risiko_bei_fehlen: "DPM-Entscheidungen werden nicht akzeptiert"
|
||||
|
||||
- id: "EF-03"
|
||||
titel: "Systemunterstützung"
|
||||
beschreibung: "Funktionsfähige IT-Werkzeuge und Vorlagen"
|
||||
abhaengigkeit: "Ticketsystem, Portfolio-Datenbank, Templates verfügbar"
|
||||
risiko_bei_fehlen: "Manuelle Arbeit, Intransparenz, Ineffizienz"
|
||||
|
||||
- id: "EF-04"
|
||||
titel: "Akzeptanz"
|
||||
beschreibung: "Anerkennung als neutrale Koordinationsinstanz"
|
||||
abhaengigkeit: "Stakeholder vertrauen auf Objektivität des DPM"
|
||||
risiko_bei_fehlen: "Politisierung von Entscheidungen, Umgehung"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
beschreibung: "Weiterführende Dokumente zur DPM-Rolle"
|
||||
|
||||
dokumente:
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Governance-Rahmen für DPM-Arbeit"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-demand-portfolio-management.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten im Prozess"
|
||||
|
||||
- titel: "Demand & Stakeholder-Runde (DSR) Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Manager:in"
|
||||
aliases: ["DPM", "Portfolio-Manager", "Demand-Manager"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
ueberprueft_durch: "DPM-Teammitglied"
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
hinweis: "anpassen auf Basis der weiteren Workstream-Ergebnisse"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "portfolio-steuerung"
|
||||
- "qualifizierung"
|
||||
- "bewertung"
|
||||
- "priorisierung"
|
||||
|
||||
# ========================================
|
||||
# 1. ROLLENZWECK
|
||||
# ========================================
|
||||
|
||||
rollenzweck:
|
||||
kurz: "Zentrale Instanz für Qualifizierung, Bewertung und Portfolio-Steuerung aller Demands im DIGIT"
|
||||
|
||||
ausfuehrlich: |
|
||||
Der:die Demand-Portfolio-Manager:in transformiert vorqualifizierte Demands in
|
||||
Demand-Entscheidungsvorlagen und schafft die Grundlage für optimale
|
||||
Ressourcensteuerung durch die verantwortlichen Gremien.
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "nach erfolgter Bedarfsklärung durch Stakeholder-Management"
|
||||
fuer: "alle Demands"
|
||||
bis: "Aufbereitung für Entscheidungsgremien"
|
||||
|
||||
entscheidungsgremien:
|
||||
- gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
- gremium_id: "mission_board"
|
||||
gremium_name: "Mission Board"
|
||||
|
||||
# ========================================
|
||||
# 2. ORGANISATORISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
organisatorische_einordnung:
|
||||
zuordnung:
|
||||
abteilung: "Abteilung Planung"
|
||||
abteilungskuerzel: "AL-P"
|
||||
|
||||
auspraegungen:
|
||||
beschreibung: "Spezialisierungen nach Themenfeld oder Kapazität möglich, aber nicht strukturell vorgegeben"
|
||||
hinweis: |
|
||||
Die frühere Unterscheidung in DPM Core-IT und DPM Non-Core-IT entfällt.
|
||||
Alle Demands – unabhängig von ihrer Herkunft (Betrieb oder Innovation) –
|
||||
durchlaufen denselben Prozess. Spezialisierungen können bei Bedarf
|
||||
themenfeld- oder kapazitätsbezogen entstehen.
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "Abteilungsleitung Planung"
|
||||
berichtet_an_rolle_id: "al_p"
|
||||
|
||||
arbeitsmodell:
|
||||
typ: "Vollzeitfunktion"
|
||||
vertretung: "gegenseitige Vertretungsregelung zwischen DPM-Mitarbeitenden"
|
||||
|
||||
# ========================================
|
||||
# 3. KERNVERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
kernverantwortlichkeiten:
|
||||
bereich_1_portfolio_management:
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
aufgaben:
|
||||
- id: "PM-01"
|
||||
titel: "Portfolio-Aufbau und -Pflege"
|
||||
beschreibung: "Aufbau und Pflege eines transparenten Demand-Portfolios"
|
||||
frequenz: "kontinuierlich"
|
||||
output: "aktuelles_demand_portfolio"
|
||||
|
||||
- id: "PM-02"
|
||||
titel: "Strategische Portfolio-Analyse"
|
||||
beschreibung: "Strategische Analyse des Demand-Portfolios und Identifizierung von Trends für das Mission Board"
|
||||
frequenz: "quartalsweise"
|
||||
output: "portfolio_trend_analyse"
|
||||
empfaenger: "mission_board"
|
||||
|
||||
- id: "PM-03"
|
||||
titel: "Portfolio-Optimierung"
|
||||
beschreibung: "Kontinuierliche Optimierung der Demand-Portfolio-Zusammensetzung"
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
- id: "PM-04"
|
||||
titel: "Strategiekonformität sicherstellen"
|
||||
beschreibung: "Bewertung und Priorisierung von Demands gemäß der strategischen Leitplanken des Vision Board"
|
||||
referenz_zu: "vision_board"
|
||||
frequenz: "pro_demand"
|
||||
|
||||
bereich_2_demand_qualifizierung:
|
||||
name: "Demand-Qualifizierung, Bewertung und Priorisierung"
|
||||
|
||||
aufgaben:
|
||||
- id: "QBP-01"
|
||||
titel: "Demand-Übernahme"
|
||||
beschreibung: "Übernahme vorqualifizierter Demands vom Stakeholder-Management"
|
||||
von_rolle: "shm"
|
||||
trigger: "demand_uebergabe_quality_gate_1"
|
||||
|
||||
- id: "QBP-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands nach vordefinierten Dimensionen"
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
output: "demand_kategorie"
|
||||
|
||||
- id: "QBP-03"
|
||||
titel: "Demand-Analyse"
|
||||
beschreibung: "Analyse von Demands nach fachlichen und technischen Aspekten und Abhängigkeiten"
|
||||
aspekte:
|
||||
- "fachliche Anforderungen"
|
||||
- "technische Machbarkeit"
|
||||
- "Abhängigkeiten zu anderen Demands/Projekten"
|
||||
output: "analyse_ergebnis"
|
||||
|
||||
- id: "QBP-04"
|
||||
titel: "Demand-Bewertung"
|
||||
beschreibung: "Bewertung und Clusterung von Demands nach qualitativen Bewertungskategorien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
|
||||
- id: "QBP-05"
|
||||
titel: "Demand-Priorisierung"
|
||||
beschreibung: "Priorisierung von Demands nach definiertem Standard und Ableitung von Handlungsempfehlungen"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
|
||||
- id: "QBP-06"
|
||||
titel: "Entscheidungsvorlagen erstellen"
|
||||
beschreibung: "Erstellung von Demand-Entscheidungsvorlagen für Entscheidungsgremien"
|
||||
output: "demand_entscheidungsvorlage"
|
||||
empfaenger: ["dsr", "mission_board"]
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
name: "Gremienarbeit"
|
||||
|
||||
aufgaben:
|
||||
- id: "GR-01"
|
||||
titel: "DSR-Vorbereitung"
|
||||
beschreibung: "Vorbereitung und Präsentation/Diskussion in der Demand & Stakeholder-Runde (DSR) zur Entscheidung"
|
||||
gremium: "dsr"
|
||||
rolle_in_gremium: "vorsitz"
|
||||
frequenz: "woechentlich"
|
||||
aktivitaeten:
|
||||
- "Agenda erstellen"
|
||||
- "Materialien vorbereiten"
|
||||
- "Präsentation vorbereiten"
|
||||
- "Moderation durchführen"
|
||||
|
||||
- id: "GR-02"
|
||||
titel: "Portfolio-Überblick Mission Board"
|
||||
beschreibung: "Demand-Portfolio Überblick im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
output: "portfolio_status_update"
|
||||
|
||||
- id: "GR-03"
|
||||
titel: "Entscheidungsvorlagen präsentieren"
|
||||
beschreibung: "Vorstellung der Demand-Entscheidungsvorlagen im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
- id: "GR-04"
|
||||
titel: "Entscheidungsfähigkeit sicherstellen"
|
||||
beschreibung: "Sicherstellung der Entscheidungsfähigkeit durch Bereitstellung der Demand-Entscheidungsvorlage"
|
||||
kritikalitaet: "hoch"
|
||||
qualitaetskriterium: "vollständige und präzise Entscheidungsgrundlagen"
|
||||
|
||||
- id: "GR-05"
|
||||
titel: "Gremienbeschlüsse umsetzen"
|
||||
beschreibung: "Umsetzung und Nachbearbeitung auf Basis von Gremienbeschlüssen"
|
||||
aktivitaeten:
|
||||
- "Statusänderungen im Portfolio"
|
||||
- "Kommunikation an Stakeholder (via SHM)"
|
||||
- "Übergabe an PPM (bei Freigabe)"
|
||||
- "Dokumentation"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN UND ZUSAMMENARBEIT
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
primaer:
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_shm_zu_dpm"
|
||||
themen:
|
||||
- "Übernahme vorqualifizierter Demands"
|
||||
- "Rückfragen bei Unvollständigkeit"
|
||||
frequenz: "kontinuierlich"
|
||||
artefakte:
|
||||
input: "bedarfs_steckbrief"
|
||||
output: "rueckfragen_oder_uebernahmebestaetigung"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_dpm_zu_ppm"
|
||||
themen:
|
||||
- "Übergabe freigegebener Demands zur (Vor-)Projektumsetzung"
|
||||
trigger: "demand_freigabe_durch_gremium"
|
||||
artefakte:
|
||||
input: "freigegebener_demand"
|
||||
output: "projektaufnahme_bestaetigung"
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
art: "koordinativ"
|
||||
richtung: "bidirektional"
|
||||
themen:
|
||||
- "Abstimmung zu Service-Bezug"
|
||||
- "Klärung: direkte Umsetzung vs. Projekt"
|
||||
frequenz: "bei_bedarf_pro_demand"
|
||||
kontext: "Besonders relevant bei Demands mit Service-Impact"
|
||||
|
||||
sekundaer:
|
||||
- rolle_id: "it_architektur"
|
||||
rolle_name: "IT-Architektur"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Klärung strategischer Grundsatzfragen"
|
||||
- "Klärung technischer Grundsatzfragen"
|
||||
frequenz: "bei_bedarf"
|
||||
trigger: "komplexe_technische_anforderungen"
|
||||
|
||||
- bezeichnung: "Fachexpert:innen"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Einholung spezifischer Expertise"
|
||||
frequenz: "bei_bedarf"
|
||||
beispiele:
|
||||
- "Datenschutzexpert:innen"
|
||||
- "Sicherheitsexpert:innen"
|
||||
- "Fachbereichsexpert:innen"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ========================================
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
eigenstaendige_entscheidungen:
|
||||
beschreibung: "Entscheidungen, die der DPM ohne Gremienabstimmung treffen kann"
|
||||
|
||||
liste:
|
||||
- id: "ENT-01"
|
||||
titel: "Demand-Rückweisung"
|
||||
beschreibung: "Rückweisung unzureichend vorqualifizierter Demands an das Stakeholder-Management zur konkreten Nachbearbeitung"
|
||||
bedingung: "unzureichende_qualitaet_oder_vollstaendigkeit"
|
||||
rueckweisung_an: "shm"
|
||||
|
||||
- id: "ENT-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands gemäß der vordefinierten Dimensionen"
|
||||
bindend: true
|
||||
kann_ueberstimmt_werden_von: ["dsr", "mission_board"]
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "ENT-03"
|
||||
titel: "Demand-Konsolidierung"
|
||||
beschreibung: "Konsolidierung ähnlicher oder zusammengehöriger Demands"
|
||||
rationale: "Vermeidung von Redundanzen und Synergienutzung"
|
||||
|
||||
- id: "ENT-04"
|
||||
titel: "Expert:innen-Einbindung"
|
||||
beschreibung: "Einbeziehung von Fachexpert:innen"
|
||||
kontext: "Bei Bedarf für fundierte Analyse und Bewertung"
|
||||
|
||||
empfehlungen_fuer_gremien:
|
||||
beschreibung: "DPM bereitet Entscheidungen vor, finales Votum liegt bei Gremien"
|
||||
|
||||
liste:
|
||||
- id: "EMP-01"
|
||||
titel: "Bewertungsprofile"
|
||||
beschreibung: "Bewertungsprofile mit qualitativen Cluster-Fazits als Diskussionsgrundlage für Gremien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
- id: "EMP-02"
|
||||
titel: "Priorisierungs-Empfehlung"
|
||||
beschreibung: "Priorisierung- und Handlungsempfehlung für Demands"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
qualitaetssicherung:
|
||||
beschreibung: "Recht und Pflicht zur Sicherstellung methodischer und prozessualer Qualität"
|
||||
|
||||
liste:
|
||||
- id: "QS-01"
|
||||
titel: "Standards durchsetzen"
|
||||
beschreibung: "Standards für Demand-Dokumentationen und -Bewertung durchzusetzen"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-02"
|
||||
titel: "Methodentreue einfordern"
|
||||
beschreibung: "Methodentreue bei allen Prozessbeteiligten einzufordern"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-03"
|
||||
titel: "Transparenz sicherstellen"
|
||||
beschreibung: "Transparenz durch vollständige Demand-Portfolio-Dokumentation sicherzustellen"
|
||||
output: "vollstaendiges_demand_portfolio"
|
||||
|
||||
- id: "QS-04"
|
||||
titel: "Verbesserungen vorschlagen"
|
||||
beschreibung: "Verbesserungen für Prozesse und Methoden basierend auf Erfahrungswerten vorzuschlagen"
|
||||
empfaenger: ["al_p", "mission_board"]
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
# ========================================
|
||||
# 6. WERKZEUGE UND METHODEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_und_methoden:
|
||||
it_werkzeuge:
|
||||
- id: "TOOL-01"
|
||||
name: "Ticketsystem"
|
||||
zweck: "Zentrale Dokumentation und Statusverfolgung"
|
||||
verwendung: "alle_demands"
|
||||
|
||||
- id: "TOOL-02"
|
||||
name: "Demand-Portfolio-Datenbank"
|
||||
zweck: "Transparente Übersicht aller Demands"
|
||||
features:
|
||||
- "Portfolio-Übersicht"
|
||||
- "Status-Tracking"
|
||||
- "Reporting-Funktionen"
|
||||
|
||||
standardvorlagen:
|
||||
- id: "TPL-01"
|
||||
name: "Demand-Entscheidungsvorlage"
|
||||
verwendung: "für_gremienpraesentation"
|
||||
zielgruppe: ["dsr", "mission_board"]
|
||||
|
||||
- id: "TPL-02"
|
||||
name: "Bedarfs-Steckbrief"
|
||||
verwendung: "input_von_shm"
|
||||
status: "wird_geprueft_und_erweitert"
|
||||
|
||||
methoden:
|
||||
- id: "METH-01"
|
||||
name: "Demand-Kategorien"
|
||||
beschreibung: "Standardisierte Methodik zur Qualifizierung und Kategorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "METH-02"
|
||||
name: "Bewertungskriterien"
|
||||
beschreibung: "Standardisierte Methodik zur Bewertung von Demands"
|
||||
referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
- id: "METH-03"
|
||||
name: "Priorisierungsmethodik"
|
||||
beschreibung: "Standardisierte Methodik zur Priorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 7. ERFORDERLICHE KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
erforderliche_kompetenzen:
|
||||
fachlich:
|
||||
- id: "FK-01"
|
||||
kompetenz: "IT-Landschaft"
|
||||
beschreibung: "Fundiertes Verständnis der IT-Landschaft und digitalen Services"
|
||||
niveau: "fundiert"
|
||||
|
||||
- id: "FK-02"
|
||||
kompetenz: "Demand-Portfolio-Management"
|
||||
beschreibung: "Expertise in Demand-Portfolio-Management und Business-Analyse"
|
||||
niveau: "expertise"
|
||||
|
||||
- id: "FK-03"
|
||||
kompetenz: "Projektmanagement"
|
||||
beschreibung: "Kenntnisse in Projektmanagement"
|
||||
niveau: "kenntnisse"
|
||||
|
||||
- id: "FK-04"
|
||||
kompetenz: "Verwaltungsprozesse"
|
||||
beschreibung: "Verwaltungsspezifisches Prozessverständnis"
|
||||
niveau: "verstaendnis"
|
||||
kontext: "Öffentliche Verwaltung, kommunale Strukturen"
|
||||
|
||||
methodisch:
|
||||
- id: "MK-01"
|
||||
kompetenz: "Analytisches Denken"
|
||||
beschreibung: "Analytisches und strategisches Denkvermögen"
|
||||
anwendung: "Demand-Analyse, Portfolio-Trends identifizieren"
|
||||
|
||||
- id: "MK-02"
|
||||
kompetenz: "Strukturierte Arbeitsweise"
|
||||
beschreibung: "Strukturierte Arbeitsweise und Komplexitätsmanagement"
|
||||
anwendung: "Parallele Bearbeitung vieler Demands"
|
||||
|
||||
- id: "MK-03"
|
||||
kompetenz: "Präsentation und Moderation"
|
||||
beschreibung: "Präsentations- und Moderationskompetenz"
|
||||
anwendung: "Gremienarbeit, DSR-Vorsitz"
|
||||
|
||||
- id: "MK-04"
|
||||
kompetenz: "Konfliktlösung"
|
||||
beschreibung: "Konfliktlösungsfähigkeit"
|
||||
anwendung: "Dissens in DSR, konkurrierende Stakeholder-Interessen"
|
||||
|
||||
sozial:
|
||||
- id: "SK-01"
|
||||
kompetenz: "Kommunikation"
|
||||
beschreibung: "Exzellente Kommunikationsfähigkeit über alle Hierarchieebenen"
|
||||
kritikalitaet: "hoch"
|
||||
kontext: "Von Fachexpert:innen bis Amtsleitung"
|
||||
|
||||
- id: "SK-02"
|
||||
kompetenz: "Diplomatisches Geschick"
|
||||
beschreibung: "Diplomatisches Geschick und Neutralität"
|
||||
anwendung: "Vermittlung zwischen divergierenden Interessen"
|
||||
kritikalitaet: "hoch"
|
||||
|
||||
- id: "SK-03"
|
||||
kompetenz: "Teamfähigkeit"
|
||||
beschreibung: "Teamfähigkeit und Serviceorientierung"
|
||||
kontext: "Zusammenarbeit mit SHM, SPM, PPM"
|
||||
|
||||
- id: "SK-04"
|
||||
kompetenz: "Durchsetzungsvermögen"
|
||||
beschreibung: "Durchsetzungsvermögen bei gleichzeitiger Kompromissbereitschaft"
|
||||
anwendung: "Methodentreue einfordern vs. pragmatische Lösungen finden"
|
||||
|
||||
# ========================================
|
||||
# 8. ERFOLGSFAKTOREN
|
||||
# ========================================
|
||||
|
||||
erfolgsfaktoren:
|
||||
beschreibung: "Kritische Rahmenbedingungen für erfolgreiche Rollenausübung"
|
||||
|
||||
faktoren:
|
||||
- id: "EF-01"
|
||||
titel: "Klare Prozessdefinition"
|
||||
beschreibung: "Umfängliche Nutzung des Demand-to-Project-Prozesses"
|
||||
abhaengigkeit: "Alle Beteiligten halten sich an definierten Prozess"
|
||||
risiko_bei_fehlen: "Umgehung des DPM, inkonsistente Demand-Behandlung"
|
||||
|
||||
- id: "EF-02"
|
||||
titel: "Management-Unterstützung"
|
||||
beschreibung: "Rückendeckung durch Amtsleitung und Gremien"
|
||||
abhaengigkeit: "Amtsleitung stärkt DPM-Rolle aktiv"
|
||||
risiko_bei_fehlen: "DPM-Entscheidungen werden nicht akzeptiert"
|
||||
|
||||
- id: "EF-03"
|
||||
titel: "Systemunterstützung"
|
||||
beschreibung: "Funktionsfähige IT-Werkzeuge und Vorlagen"
|
||||
abhaengigkeit: "Ticketsystem, Portfolio-Datenbank, Templates verfügbar"
|
||||
risiko_bei_fehlen: "Manuelle Arbeit, Intransparenz, Ineffizienz"
|
||||
|
||||
- id: "EF-04"
|
||||
titel: "Akzeptanz"
|
||||
beschreibung: "Anerkennung als neutrale Koordinationsinstanz"
|
||||
abhaengigkeit: "Stakeholder vertrauen auf Objektivität des DPM"
|
||||
risiko_bei_fehlen: "Politisierung von Entscheidungen, Umgehung"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
beschreibung: "Weiterführende Dokumente zur DPM-Rolle"
|
||||
|
||||
dokumente:
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Governance-Rahmen für DPM-Arbeit"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-demand-portfolio-management.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten im Prozess"
|
||||
|
||||
- titel: "Demand & Stakeholder-Runde (DSR) Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Arbeitsweise des wichtigsten Gremiums für DPM"
|
||||
|
|
@ -1,123 +1,123 @@
|
|||
phase:
|
||||
id: 1
|
||||
titel: "Initiierung und Erfassung"
|
||||
ziel: "Identifikation von Bedarfen durch Stakeholder und Überführung in qualifizierte Bedarfssteckbriefe durch das Stakeholder-Management, inklusive Abgrenzung zum bestehenden Service-Katalog."
|
||||
verantwortlich_rolle: "Stakeholder-Management (SHM)"
|
||||
|
||||
schema_referenzen:
|
||||
bedarfs_steckbrief:
|
||||
pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml"
|
||||
version: "1.1"
|
||||
bedarfsbewertung:
|
||||
pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||||
beschreibung: "Routing-Logik und Entscheidungsbaum"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "1.1"
|
||||
titel: "Bedarfsidentifikation"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Ein Stakeholder erkennt einen fachlichen Bedarf, der nicht durch die bestehende Arbeitsumgebung abgedeckt ist."
|
||||
input: "Fachlicher Auslöser (z.B. Gesetzesänderung, Prozessoptimierung)"
|
||||
output: "Initialer Bedarfsgedanke"
|
||||
raci_referenz: "1.1"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.2"
|
||||
titel: "Bedarfsmeldung"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Der Stakeholder meldet den Bedarf über definierte Kanäle (z.B. Service Desk Ticket, direkte Ansprache) an DIGIT."
|
||||
input: "Initialer Bedarfsgedanke"
|
||||
output: "Unqualifizierte Bedarfsmeldung (Ticket)"
|
||||
system: "Ticketsystem"
|
||||
raci_referenz: "1.2"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.3"
|
||||
titel: "Initiale Qualifizierung (Triage)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Erste Sichtung der Meldung. Prüfung auf Vollständigkeit der Basisinformationen und Zuständigkeit."
|
||||
input: "Unqualifizierte Bedarfsmeldung"
|
||||
output: "Qualifizierungsstatus"
|
||||
raci_referenz: "1.3"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.4"
|
||||
titel: "Service-Katalog-Prüfung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
support_akteur: "Service-Portfolio-Management (SPM)"
|
||||
beschreibung: "Abgleich des Bedarfs mit dem existierenden Service-Katalog. Entscheidung, ob es sich um einen Standard-Request handelt."
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Bedarf durch bestehenden Service-Katalog abdeckbar?"
|
||||
option_ja: "Routing in Request Fulfilment Prozess (Out of Demand Scope)"
|
||||
option_nein: "Weiter in Demand-Prozess (Schritt 1.5)"
|
||||
routing_pfad_bei_ja:
|
||||
id: "ROUTE-REQ"
|
||||
name: "Request Fulfilment"
|
||||
ziel: "Service Desk"
|
||||
steckbrief_erforderlich: false
|
||||
hinweis: "Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung"
|
||||
raci_referenz: "1.4"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.5"
|
||||
titel: "Bedarfsklärungsgespräch"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
partner_akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Strukturiertes Interview zur Erhebung der funktionalen und nicht-funktionalen Anforderungen, des Nutzens und der Rahmenbedingungen."
|
||||
input: "Qualifizierte Meldung"
|
||||
output: "Protokollierte Anforderungen"
|
||||
artefakte: "Bedarfs-Steckbrief (Draft)"
|
||||
raci_referenz: "1.5"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.6"
|
||||
titel: "User Story Erstellung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Übersetzung der Anforderungen in strukturierte User Stories (Wer möchte was warum?) zur Sicherstellung der fachlichen Perspektive."
|
||||
input: "Protokollierte Anforderungen"
|
||||
output: "Fertiger Bedarfs-Steckbrief"
|
||||
artefakte:
|
||||
- "Bedarfs-Steckbrief (Final)"
|
||||
- "Leitfaden User Stories"
|
||||
raci_referenz: "1.6"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.7"
|
||||
titel: "Bedarfs-Routing (Quality Gate 1)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: |
|
||||
Routing-Entscheidung basierend auf Bedarfsbewertung.
|
||||
Je nach Ergebnis erfolgt Übergabe an unterschiedliche Empfänger.
|
||||
input: "Bedarfs-Steckbrief (Final oder reduziert je nach Routing)"
|
||||
system: "Ticketsystem / Demand-Portfolio-Datenbank"
|
||||
raci_referenz: "1.7"
|
||||
citation: [506]
|
||||
|
||||
routing_optionen:
|
||||
- routing_id: "ROUTE-DPM"
|
||||
name: "Demand Portfolio Management"
|
||||
empfaenger: "Demand-Portfolio-Management (DPM)"
|
||||
bedingung: "Neuer Service oder grundlegende Neugestaltung erforderlich"
|
||||
output: "Demand (Status: an_dpm_uebergeben)"
|
||||
steckbrief_vollstaendig: true
|
||||
trigger_next_phase: "Phase 2: Qualifizierung und Priorisierung"
|
||||
quality_gate: true
|
||||
|
||||
- routing_id: "ROUTE-SPM"
|
||||
name: "Service Portfolio Management (Change)"
|
||||
empfaenger: "Service-Portfolio-Management (SPM)"
|
||||
bedingung: "Änderung an bestehendem Service"
|
||||
output: "Change Request (Status: an_spm_uebergeben)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Reduzierter Steckbrief ausreichend"
|
||||
|
||||
- routing_id: "ROUTE-SO"
|
||||
name: "Service-Owner-Klärung"
|
||||
empfaenger: "Service Owner (über Service-Portfolio / SPM)"
|
||||
bedingung: "Routing unklar – bilaterale Klärung mit Service Owner"
|
||||
output: "Klärungsfall (Status: in_so_klaerung)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Wenn Service Owner identifizierbar: direkte bilaterale Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR."
|
||||
referenz: "GOV-SHM-029"
|
||||
|
||||
phase:
|
||||
id: 1
|
||||
titel: "Initiierung und Erfassung"
|
||||
ziel: "Identifikation von Bedarfen durch Stakeholder und Überführung in qualifizierte Bedarfssteckbriefe durch das Stakeholder-Management, inklusive Abgrenzung zum bestehenden Service-Katalog."
|
||||
verantwortlich_rolle: "Stakeholder-Management (SHM)"
|
||||
|
||||
schema_referenzen:
|
||||
bedarfs_steckbrief:
|
||||
pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml"
|
||||
version: "1.1"
|
||||
bedarfsbewertung:
|
||||
pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||||
beschreibung: "Routing-Logik und Entscheidungsbaum"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "1.1"
|
||||
titel: "Bedarfsidentifikation"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Ein Stakeholder erkennt einen fachlichen Bedarf, der nicht durch die bestehende Arbeitsumgebung abgedeckt ist."
|
||||
input: "Fachlicher Auslöser (z.B. Gesetzesänderung, Prozessoptimierung)"
|
||||
output: "Initialer Bedarfsgedanke"
|
||||
raci_referenz: "1.1"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.2"
|
||||
titel: "Bedarfsmeldung"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Der Stakeholder meldet den Bedarf über definierte Kanäle (z.B. Service Desk Ticket, direkte Ansprache) an DIGIT."
|
||||
input: "Initialer Bedarfsgedanke"
|
||||
output: "Unqualifizierte Bedarfsmeldung (Ticket)"
|
||||
system: "Ticketsystem"
|
||||
raci_referenz: "1.2"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.3"
|
||||
titel: "Initiale Qualifizierung (Triage)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Erste Sichtung der Meldung. Prüfung auf Vollständigkeit der Basisinformationen und Zuständigkeit."
|
||||
input: "Unqualifizierte Bedarfsmeldung"
|
||||
output: "Qualifizierungsstatus"
|
||||
raci_referenz: "1.3"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.4"
|
||||
titel: "Service-Katalog-Prüfung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
support_akteur: "Service-Portfolio-Management (SPM)"
|
||||
beschreibung: "Abgleich des Bedarfs mit dem existierenden Service-Katalog. Entscheidung, ob es sich um einen Standard-Request handelt."
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Bedarf durch bestehenden Service-Katalog abdeckbar?"
|
||||
option_ja: "Routing in Request Fulfilment Prozess (Out of Demand Scope)"
|
||||
option_nein: "Weiter in Demand-Prozess (Schritt 1.5)"
|
||||
routing_pfad_bei_ja:
|
||||
id: "ROUTE-REQ"
|
||||
name: "Request Fulfilment"
|
||||
ziel: "Service Desk"
|
||||
steckbrief_erforderlich: false
|
||||
hinweis: "Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung"
|
||||
raci_referenz: "1.4"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.5"
|
||||
titel: "Bedarfsklärungsgespräch"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
partner_akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Strukturiertes Interview zur Erhebung der funktionalen und nicht-funktionalen Anforderungen, des Nutzens und der Rahmenbedingungen."
|
||||
input: "Qualifizierte Meldung"
|
||||
output: "Protokollierte Anforderungen"
|
||||
artefakte: "Bedarfs-Steckbrief (Draft)"
|
||||
raci_referenz: "1.5"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.6"
|
||||
titel: "User Story Erstellung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Übersetzung der Anforderungen in strukturierte User Stories (Wer möchte was warum?) zur Sicherstellung der fachlichen Perspektive."
|
||||
input: "Protokollierte Anforderungen"
|
||||
output: "Fertiger Bedarfs-Steckbrief"
|
||||
artefakte:
|
||||
- "Bedarfs-Steckbrief (Final)"
|
||||
- "Leitfaden User Stories"
|
||||
raci_referenz: "1.6"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.7"
|
||||
titel: "Bedarfs-Routing (Quality Gate 1)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: |
|
||||
Routing-Entscheidung basierend auf Bedarfsbewertung.
|
||||
Je nach Ergebnis erfolgt Übergabe an unterschiedliche Empfänger.
|
||||
input: "Bedarfs-Steckbrief (Final oder reduziert je nach Routing)"
|
||||
system: "Ticketsystem / Demand-Portfolio-Datenbank"
|
||||
raci_referenz: "1.7"
|
||||
citation: [506]
|
||||
|
||||
routing_optionen:
|
||||
- routing_id: "ROUTE-DPM"
|
||||
name: "Demand Portfolio Management"
|
||||
empfaenger: "Demand-Portfolio-Management (DPM)"
|
||||
bedingung: "Neuer Service oder grundlegende Neugestaltung erforderlich"
|
||||
output: "Demand (Status: an_dpm_uebergeben)"
|
||||
steckbrief_vollstaendig: true
|
||||
trigger_next_phase: "Phase 2: Qualifizierung und Priorisierung"
|
||||
quality_gate: true
|
||||
|
||||
- routing_id: "ROUTE-SPM"
|
||||
name: "Service Portfolio Management (Change)"
|
||||
empfaenger: "Service-Portfolio-Management (SPM)"
|
||||
bedingung: "Änderung an bestehendem Service"
|
||||
output: "Change Request (Status: an_spm_uebergeben)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Reduzierter Steckbrief ausreichend"
|
||||
|
||||
- routing_id: "ROUTE-SO"
|
||||
name: "Service-Owner-Klärung"
|
||||
empfaenger: "Service Owner (über Service-Portfolio / SPM)"
|
||||
bedingung: "Routing unklar – bilaterale Klärung mit Service Owner"
|
||||
output: "Klärungsfall (Status: in_so_klaerung)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Wenn Service Owner identifizierbar: direkte bilaterale Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR."
|
||||
referenz: "GOV-SHM-029"
|
||||
|
||||
validierungsprofile_referenz: "shm_schema_bedarfssteckbrief.yaml#validierungsprofile"
|
||||
|
|
@ -1,71 +1,71 @@
|
|||
phase:
|
||||
id: 2
|
||||
titel: "Qualifizierung und Priorisierung"
|
||||
ziel: "Systematische Analyse, Bewertung und Priorisierung des Demands zur Herstellung der Entscheidungsreife für das zuständige Gremium."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "2.1"
|
||||
titel: "Vollständigkeitsprüfung (Quality Gate 2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Prüfung des übergebenen Bedarfs-Steckbriefs auf formale Vollständigkeit und inhaltliche Plausibilität."
|
||||
input: "Bedarfs-Steckbrief (Final)"
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Steckbrief ausreichend qualifiziert?"
|
||||
option_ja: "Weiter zur Klassifizierung (Schritt 2.2)"
|
||||
option_nein: "Rückweisung an Stakeholder-Management zur Nachbesserung"
|
||||
raci_referenz: "2.1"
|
||||
citation: [376, 196]
|
||||
|
||||
- schritt_id: "2.2"
|
||||
titel: "Demand-Klassifizierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Einordnung des Demands in die vier Steuerungsdimensionen: Treiber, Tragweite, Systemebene, Komplexität."
|
||||
input: "Bedarfs-Steckbrief"
|
||||
output: "Klassifizierter Demand mit initialem Routing-Vorschlag"
|
||||
artefakte: "Klassifizierungsmatrix"
|
||||
raci_referenz: "2.2"
|
||||
citation: [376, 1048]
|
||||
|
||||
- schritt_id: "2.3"
|
||||
titel: "Inhaltliche Analyse & Abhängigkeitsprüfung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
support_akteure:
|
||||
- "IT-Architektur-Board (bei Architekturrelevanz)"
|
||||
- "Projekt-Portfolio-Management (PPM) (für Portfolio-Check)"
|
||||
- "Service-Portfolio-Management (SPM) (für Service-Impact)"
|
||||
beschreibung: "Tiefenprüfung der Anforderungen, Identifikation technischer/fachlicher Abhängigkeiten zu anderen Demands/Projekten und Ersteinschätzung des Lösungsraums."
|
||||
input: "Klassifizierter Demand"
|
||||
output: "Analyseergebnisse & identifizierte Abhängigkeiten"
|
||||
raci_referenz: "2.3"
|
||||
citation: [376, 113]
|
||||
|
||||
- schritt_id: "2.4"
|
||||
titel: "Demand-Bewertung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Qualitative Bewertung anhand der drei Cluster: Nutzen & Wirkung, Druck & Notwendigkeit, Machbarkeit & Aufwand."
|
||||
input: "Analyseergebnisse"
|
||||
output: "Bewertungs-Scores je Cluster"
|
||||
raci_referenz: "2.4"
|
||||
citation: [376, 1309]
|
||||
|
||||
- schritt_id: "2.5"
|
||||
titel: "Priorisierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Überführung der Bewertungsergebnisse in die Priorisierungs-Matrix (Wichtigkeit vs. Dringlichkeit) zur Ermittlung der Handlungsempfehlung."
|
||||
input: "Bewertungs-Scores"
|
||||
output: "Priorisierter Demand (Quadrant + Machbarkeits-Ampel)"
|
||||
artefakte: "Priorisierungs-Matrix"
|
||||
raci_referenz: "2.5"
|
||||
citation: [376, 1593]
|
||||
|
||||
- schritt_id: "2.6"
|
||||
titel: "Erstellung Entscheidungsvorlage"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Zusammenführung aller Ergebnisse in eine standardisierte Vorlage für das Entscheidungsgremium inklusive finalem Routing-Vorschlag."
|
||||
input: "Priorisierter Demand"
|
||||
output: "Entscheidungsreife Vorlage"
|
||||
artefakte: "Demand-Entscheidungsvorlage"
|
||||
trigger_next_phase: "Phase 3: Entscheidung und Freigabe"
|
||||
raci_referenz: "2.6"
|
||||
phase:
|
||||
id: 2
|
||||
titel: "Qualifizierung und Priorisierung"
|
||||
ziel: "Systematische Analyse, Bewertung und Priorisierung des Demands zur Herstellung der Entscheidungsreife für das zuständige Gremium."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "2.1"
|
||||
titel: "Vollständigkeitsprüfung (Quality Gate 2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Prüfung des übergebenen Bedarfs-Steckbriefs auf formale Vollständigkeit und inhaltliche Plausibilität."
|
||||
input: "Bedarfs-Steckbrief (Final)"
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Steckbrief ausreichend qualifiziert?"
|
||||
option_ja: "Weiter zur Klassifizierung (Schritt 2.2)"
|
||||
option_nein: "Rückweisung an Stakeholder-Management zur Nachbesserung"
|
||||
raci_referenz: "2.1"
|
||||
citation: [376, 196]
|
||||
|
||||
- schritt_id: "2.2"
|
||||
titel: "Demand-Klassifizierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Einordnung des Demands in die vier Steuerungsdimensionen: Treiber, Tragweite, Systemebene, Komplexität."
|
||||
input: "Bedarfs-Steckbrief"
|
||||
output: "Klassifizierter Demand mit initialem Routing-Vorschlag"
|
||||
artefakte: "Klassifizierungsmatrix"
|
||||
raci_referenz: "2.2"
|
||||
citation: [376, 1048]
|
||||
|
||||
- schritt_id: "2.3"
|
||||
titel: "Inhaltliche Analyse & Abhängigkeitsprüfung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
support_akteure:
|
||||
- "IT-Architektur-Board (bei Architekturrelevanz)"
|
||||
- "Projekt-Portfolio-Management (PPM) (für Portfolio-Check)"
|
||||
- "Service-Portfolio-Management (SPM) (für Service-Impact)"
|
||||
beschreibung: "Tiefenprüfung der Anforderungen, Identifikation technischer/fachlicher Abhängigkeiten zu anderen Demands/Projekten und Ersteinschätzung des Lösungsraums."
|
||||
input: "Klassifizierter Demand"
|
||||
output: "Analyseergebnisse & identifizierte Abhängigkeiten"
|
||||
raci_referenz: "2.3"
|
||||
citation: [376, 113]
|
||||
|
||||
- schritt_id: "2.4"
|
||||
titel: "Demand-Bewertung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Qualitative Bewertung anhand der drei Cluster: Nutzen & Wirkung, Druck & Notwendigkeit, Machbarkeit & Aufwand."
|
||||
input: "Analyseergebnisse"
|
||||
output: "Bewertungs-Scores je Cluster"
|
||||
raci_referenz: "2.4"
|
||||
citation: [376, 1309]
|
||||
|
||||
- schritt_id: "2.5"
|
||||
titel: "Priorisierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Überführung der Bewertungsergebnisse in die Priorisierungs-Matrix (Wichtigkeit vs. Dringlichkeit) zur Ermittlung der Handlungsempfehlung."
|
||||
input: "Bewertungs-Scores"
|
||||
output: "Priorisierter Demand (Quadrant + Machbarkeits-Ampel)"
|
||||
artefakte: "Priorisierungs-Matrix"
|
||||
raci_referenz: "2.5"
|
||||
citation: [376, 1593]
|
||||
|
||||
- schritt_id: "2.6"
|
||||
titel: "Erstellung Entscheidungsvorlage"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Zusammenführung aller Ergebnisse in eine standardisierte Vorlage für das Entscheidungsgremium inklusive finalem Routing-Vorschlag."
|
||||
input: "Priorisierter Demand"
|
||||
output: "Entscheidungsreife Vorlage"
|
||||
artefakte: "Demand-Entscheidungsvorlage"
|
||||
trigger_next_phase: "Phase 3: Entscheidung und Freigabe"
|
||||
raci_referenz: "2.6"
|
||||
citation: [376, 1770]
|
||||
|
|
@ -1,74 +1,74 @@
|
|||
phase:
|
||||
id: 3
|
||||
titel: "Entscheidung und Freigabe"
|
||||
ziel: "Herbeiführung einer verbindlichen Entscheidung (Freigabe, Ablehnung, Delegation) durch das zuständige Gremium inklusive Definition notwendiger Rahmenbedingungen."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "3.1"
|
||||
titel: "DSR-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Finale Qualitätssicherung der Vorlage und Versand der Unterlagen an DSR-Mitglieder (min. 24h vor Sitzung)."
|
||||
input: "Entscheidungsreife Vorlage"
|
||||
output: "Versendete Sitzungsunterlagen"
|
||||
raci_referenz: "3.1"
|
||||
citation: [378, 461]
|
||||
|
||||
- schritt_id: "3.2"
|
||||
titel: "DSR-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand & Stakeholder Runde (DSR)"
|
||||
moderator: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Präsentation des Demands und Entscheidungsfindung im Konsent-Verfahren."
|
||||
entscheidungspunkt:
|
||||
frage: "DSR-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_delegation: "Weiter zu Schritt 3.3 (MB-Vorbereitung)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung erforderlich)"
|
||||
raci_referenz: "3.2, 3.3, 3.4"
|
||||
citation: [378, 470]
|
||||
|
||||
- schritt_id: "3.3"
|
||||
titel: "MB-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR (aus 3.2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Aufbereitung der Entscheidungsvorlage für die strategische Perspektive des Mission Boards."
|
||||
input: "Vorlage (ggf. mit Delegationsvotum der DSR)"
|
||||
output: "MB-Sitzungsunterlagen"
|
||||
raci_referenz: "3.5"
|
||||
citation: [378]
|
||||
|
||||
- schritt_id: "3.4"
|
||||
titel: "MB-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR"
|
||||
akteur: "Mission Board (MB)"
|
||||
support_akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Strategische Diskussion und finale Entscheidung über MB-relevante Demands."
|
||||
entscheidungspunkt:
|
||||
frage: "MB-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung) oder 3.3 (Wiedervorlage)"
|
||||
raci_referenz: "3.6, 3.7"
|
||||
citation: [378, 381]
|
||||
|
||||
- schritt_id: "3.5"
|
||||
titel: "Entscheidungs-Finalisierung"
|
||||
bedingung: "Nur bei Freigabe (durch DSR oder MB)"
|
||||
akteur: "Entscheidungsgremium (DSR/MB)"
|
||||
beschreibung: "Festlegung verbindlicher Auflagen für die Umsetzung und Benennung eines fachlichen Sponsors."
|
||||
output: "Vollständiger Gremienbeschluss mit Auflagen & Sponsor"
|
||||
raci_referenz: "3.8, 3.9, 3.10"
|
||||
citation: [381, 482]
|
||||
|
||||
- schritt_id: "3.6"
|
||||
titel: "Kommunikation & Routing (Quality Gate 3)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Formale Dokumentation des Beschlusses, Information an Stakeholder (via SHM) und Routing in die nächste Phase."
|
||||
input: "Gremienbeschluss"
|
||||
output: "Aktualisierter Demand-Status"
|
||||
trigger_next_phase: "Phase 4: Projektinitiierung (bei Freigabe) ODER Archivierung (bei Ablehnung)"
|
||||
raci_referenz: "3.11"
|
||||
phase:
|
||||
id: 3
|
||||
titel: "Entscheidung und Freigabe"
|
||||
ziel: "Herbeiführung einer verbindlichen Entscheidung (Freigabe, Ablehnung, Delegation) durch das zuständige Gremium inklusive Definition notwendiger Rahmenbedingungen."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "3.1"
|
||||
titel: "DSR-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Finale Qualitätssicherung der Vorlage und Versand der Unterlagen an DSR-Mitglieder (min. 24h vor Sitzung)."
|
||||
input: "Entscheidungsreife Vorlage"
|
||||
output: "Versendete Sitzungsunterlagen"
|
||||
raci_referenz: "3.1"
|
||||
citation: [378, 461]
|
||||
|
||||
- schritt_id: "3.2"
|
||||
titel: "DSR-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand & Stakeholder Runde (DSR)"
|
||||
moderator: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Präsentation des Demands und Entscheidungsfindung im Konsent-Verfahren."
|
||||
entscheidungspunkt:
|
||||
frage: "DSR-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_delegation: "Weiter zu Schritt 3.3 (MB-Vorbereitung)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung erforderlich)"
|
||||
raci_referenz: "3.2, 3.3, 3.4"
|
||||
citation: [378, 470]
|
||||
|
||||
- schritt_id: "3.3"
|
||||
titel: "MB-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR (aus 3.2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Aufbereitung der Entscheidungsvorlage für die strategische Perspektive des Mission Boards."
|
||||
input: "Vorlage (ggf. mit Delegationsvotum der DSR)"
|
||||
output: "MB-Sitzungsunterlagen"
|
||||
raci_referenz: "3.5"
|
||||
citation: [378]
|
||||
|
||||
- schritt_id: "3.4"
|
||||
titel: "MB-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR"
|
||||
akteur: "Mission Board (MB)"
|
||||
support_akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Strategische Diskussion und finale Entscheidung über MB-relevante Demands."
|
||||
entscheidungspunkt:
|
||||
frage: "MB-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung) oder 3.3 (Wiedervorlage)"
|
||||
raci_referenz: "3.6, 3.7"
|
||||
citation: [378, 381]
|
||||
|
||||
- schritt_id: "3.5"
|
||||
titel: "Entscheidungs-Finalisierung"
|
||||
bedingung: "Nur bei Freigabe (durch DSR oder MB)"
|
||||
akteur: "Entscheidungsgremium (DSR/MB)"
|
||||
beschreibung: "Festlegung verbindlicher Auflagen für die Umsetzung und Benennung eines fachlichen Sponsors."
|
||||
output: "Vollständiger Gremienbeschluss mit Auflagen & Sponsor"
|
||||
raci_referenz: "3.8, 3.9, 3.10"
|
||||
citation: [381, 482]
|
||||
|
||||
- schritt_id: "3.6"
|
||||
titel: "Kommunikation & Routing (Quality Gate 3)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Formale Dokumentation des Beschlusses, Information an Stakeholder (via SHM) und Routing in die nächste Phase."
|
||||
input: "Gremienbeschluss"
|
||||
output: "Aktualisierter Demand-Status"
|
||||
trigger_next_phase: "Phase 4: Projektinitiierung (bei Freigabe) ODER Archivierung (bei Ablehnung)"
|
||||
raci_referenz: "3.11"
|
||||
citation: [381]
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,184 +1,193 @@
|
|||
metadata:
|
||||
name: "Design"
|
||||
yasm_referenz: "LP2: Design new or changed services"
|
||||
version: "3.0"
|
||||
status: "draft"
|
||||
erstellt: "2026-01-22"
|
||||
aktualisiert: "2026-02-18"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Strategische und architektonische Gestaltung neuer oder wesentlich
|
||||
geänderter Services. Umfasst Service-Definition, Architektur-Design
|
||||
und Implementation Blueprint.
|
||||
|
||||
Diese Phase entspricht YASM LP2 (Design new or changed services) und
|
||||
fokussiert auf die Planung und das Design, NICHT auf die Implementierung.
|
||||
|
||||
aenderungen:
|
||||
- version: "3.0"
|
||||
datum: "2026-02-18"
|
||||
beschreibung: >
|
||||
Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase
|
||||
verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1
|
||||
ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design.
|
||||
|
||||
- version: "2.1"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft"
|
||||
(g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR
|
||||
Beginn der Transition geprüft werden, um Ressourcenverschwendung zu
|
||||
vermeiden. Alle Prüfdimensionen nun explizit dokumentiert.
|
||||
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_
|
||||
umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2026-01-22"
|
||||
beschreibung: "Initiale Erstellung nach YASM LP2"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Demand Lifecycle Phase 4"
|
||||
artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)"
|
||||
beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert"
|
||||
ausgang:
|
||||
- ziel: "Transition"
|
||||
artefakt: "Service Design Document + Implementation Blueprint"
|
||||
beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase"
|
||||
|
||||
hinweis: >
|
||||
Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung).
|
||||
Nach YASM LP2 werden hier alle strategischen und architektonischen
|
||||
Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt
|
||||
als erste Aktivität der Transition-Phase (tr_01).
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_01
|
||||
name: "Definieren der erforderlichen Service-Eigenschaften"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Definition (Utility & Warranty)"
|
||||
ehemals: "sd_01"
|
||||
|
||||
beschreibung: >
|
||||
Grundlegende Definition des neuen oder geänderten Services aus
|
||||
fachlicher Perspektive.
|
||||
|
||||
umfasst:
|
||||
- "Definition von Zweck, Nutzen, Zielgruppen"
|
||||
- "Definition der Utility & Warranty des Services"
|
||||
- "Ableitung der SLA-/SLO-Anforderungen"
|
||||
- "Ermittlung unterstützender Services und Abhängigkeiten"
|
||||
- "Identifikation fachlicher und technischer Anforderungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: architektur
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_02
|
||||
name: "Designen der erforderlichen Service- und Service-Management-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Architecture Design"
|
||||
ehemals: "sd_02"
|
||||
|
||||
beschreibung: >
|
||||
Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell.
|
||||
|
||||
umfasst:
|
||||
- "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)"
|
||||
- "Design der Betriebs- und Supportprozesse"
|
||||
- "Sicherheits-, Compliance- und Datenschutzanforderungen"
|
||||
- "Monitoring & Reporting-Anforderungen"
|
||||
- "Tool-/Konfigurationsanforderungen"
|
||||
- "Rollenmodell (Support, Betrieb, Governance)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: architektur
|
||||
raci: R
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_03
|
||||
name: "Beschreiben des Vorgehens zur Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Implementation Blueprint"
|
||||
ehemals: "sd_03"
|
||||
|
||||
beschreibung: >
|
||||
Planen, WIE der Service organisatorisch eingeführt wird
|
||||
(nicht technisch deployt wird).
|
||||
|
||||
umfasst:
|
||||
- "Plan für organisatorische Integration"
|
||||
- "Definition aller Rollenübergaben"
|
||||
- "Anpassung von Richtlinien, Prozessen, Toolkonfiguration"
|
||||
- "Definition benötigter Trainings / Kommunikation"
|
||||
- "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_04
|
||||
name: "Vorbereiten der Service-Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Organizational Integration Planning"
|
||||
ehemals: "sd_04"
|
||||
|
||||
beschreibung: >
|
||||
Finalisieren aller organisatorischen Voraussetzungen für die
|
||||
spätere Übergabe in den Betrieb.
|
||||
|
||||
umfasst:
|
||||
- "Abstimmung mit Betrieb & Support"
|
||||
- "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind"
|
||||
- "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht"
|
||||
- "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
metadata:
|
||||
name: "Design"
|
||||
yasm_referenz: "LP2: Design new or changed services"
|
||||
version: "3.0"
|
||||
status: "draft"
|
||||
erstellt: "2026-01-22"
|
||||
aktualisiert: "2026-02-18"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Strategische und architektonische Gestaltung neuer oder wesentlich
|
||||
geänderter Services. Umfasst Service-Definition, Architektur-Design
|
||||
und Implementation Blueprint.
|
||||
|
||||
Diese Phase entspricht YASM LP2 (Design new or changed services) und
|
||||
fokussiert auf die Planung und das Design, NICHT auf die Implementierung.
|
||||
|
||||
aenderungen:
|
||||
- version: "3.0"
|
||||
datum: "2026-02-18"
|
||||
beschreibung: >
|
||||
Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase
|
||||
verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1
|
||||
ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design.
|
||||
|
||||
- version: "2.1"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft"
|
||||
(g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR
|
||||
Beginn der Transition geprüft werden, um Ressourcenverschwendung zu
|
||||
vermeiden. Alle Prüfdimensionen nun explizit dokumentiert.
|
||||
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_
|
||||
umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2026-01-22"
|
||||
beschreibung: "Initiale Erstellung nach YASM LP2"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Demand Lifecycle Phase 4"
|
||||
artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)"
|
||||
beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert"
|
||||
ausgang:
|
||||
- ziel: "Transition"
|
||||
artefakt: "Service Design Document + Implementation Blueprint"
|
||||
beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase"
|
||||
|
||||
hinweis: >
|
||||
Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung).
|
||||
Nach YASM LP2 werden hier alle strategischen und architektonischen
|
||||
Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt
|
||||
als erste Aktivität der Transition-Phase (tr_01).
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_01
|
||||
name: "Definieren der erforderlichen Service-Eigenschaften"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Definition (Utility & Warranty)"
|
||||
ehemals: "sd_01"
|
||||
|
||||
beschreibung: >
|
||||
Grundlegende Definition des neuen oder geänderten Services aus
|
||||
fachlicher Perspektive. Diese Aktivität bildet den Startpunkt für
|
||||
die Erstellung der Service-Definition als zentrales Artefakt.
|
||||
|
||||
umfasst:
|
||||
- "Definition von Zweck, Nutzen, Zielgruppen"
|
||||
- "Definition der Utility & Warranty des Services"
|
||||
- "Ableitung der SLA-/SLO-Anforderungen"
|
||||
- "Ermittlung unterstützender Services und Abhängigkeiten"
|
||||
- "Identifikation fachlicher und technischer Anforderungen"
|
||||
|
||||
hinweis_rollen: >
|
||||
In der Design-Phase agiert die Rolle service_owner als designierter
|
||||
Service Owner, da der Service noch nicht im Betrieb existiert und die
|
||||
formale Übernahme der SO-Rolle erst bei Gate 1 (tr_01) erfolgt
|
||||
(vgl. GOV-TR-004, GOV-TR-006). Die Empfehlung ist eine frühzeitige
|
||||
Benennung bei/kurz nach Projektfreigabe; der harte Constraint liegt
|
||||
bei Gate 1. Dieser Hinweis gilt für alle Aktivitäten ds_01 bis ds_04.
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: architektur
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_02
|
||||
name: "Designen der erforderlichen Service- und Service-Management-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Architecture Design"
|
||||
ehemals: "sd_02"
|
||||
|
||||
beschreibung: >
|
||||
Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell.
|
||||
|
||||
umfasst:
|
||||
- "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)"
|
||||
- "Design der Betriebs- und Supportprozesse"
|
||||
- "Sicherheits-, Compliance- und Datenschutzanforderungen"
|
||||
- "Monitoring & Reporting-Anforderungen"
|
||||
- "Tool-/Konfigurationsanforderungen"
|
||||
- "Rollenmodell (Support, Betrieb, Governance)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: architektur
|
||||
raci: R
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_03
|
||||
name: "Beschreiben des Vorgehens zur Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Implementation Blueprint"
|
||||
ehemals: "sd_03"
|
||||
|
||||
beschreibung: >
|
||||
Planen, WIE der Service organisatorisch eingeführt wird
|
||||
(nicht technisch deployt wird).
|
||||
|
||||
umfasst:
|
||||
- "Plan für organisatorische Integration"
|
||||
- "Definition aller Rollenübergaben"
|
||||
- "Anpassung von Richtlinien, Prozessen, Toolkonfiguration"
|
||||
- "Definition benötigter Trainings / Kommunikation"
|
||||
- "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_04
|
||||
name: "Vorbereiten der Service-Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Organizational Integration Planning"
|
||||
ehemals: "sd_04"
|
||||
|
||||
beschreibung: >
|
||||
Finalisieren aller organisatorischen Voraussetzungen für die
|
||||
spätere Übergabe in den Betrieb.
|
||||
|
||||
umfasst:
|
||||
- "Abstimmung mit Betrieb & Support"
|
||||
- "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind"
|
||||
- "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht"
|
||||
- "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
|
|
|
|||
|
|
@ -1,268 +1,268 @@
|
|||
metadata:
|
||||
name: "Review"
|
||||
yasm_referenz: "LP5: Improve the services"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Periodische und anlassbezogene Bewertung der Service-Performance.
|
||||
Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung
|
||||
von Verbesserungsmaßnahmen bis hin zur Stilllegung.
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review"
|
||||
zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt.
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2025-12-17"
|
||||
beschreibung: |
|
||||
- Referenz auf spm_konzept_service-review.yaml hinzugefügt
|
||||
- Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001)
|
||||
- Output-Präzisierung für Handlungsempfehlungen ergänzt
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-11-26"
|
||||
beschreibung: "Initiale Erstellung"
|
||||
|
||||
referenzen:
|
||||
konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Operation"
|
||||
artefakt: "Service-Qualitätsbericht, Monitoring-Daten"
|
||||
- quelle: "Support"
|
||||
artefakt: "Support-KPIs, Problem Records, Incident-Trends"
|
||||
ausgang:
|
||||
- ziel: "Operation"
|
||||
artefakt: "Freigegebene Verbesserungsmaßnahmen"
|
||||
bedingung: "Bei Service Improvement"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Demand für strukturelle Änderung"
|
||||
bedingung: "Bei Service Redesign / Erweiterung"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan, Decommissioning-Auftrag"
|
||||
bedingung: "Bei Service außer Betrieb nehmen"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_01
|
||||
name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_01"
|
||||
|
||||
beschreibung: >
|
||||
Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs,
|
||||
um mittelfristige Verbesserungen anzustoßen.
|
||||
|
||||
umfasst:
|
||||
- "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)"
|
||||
- "Identifikation wiederkehrender Tickets und systemischer Ursachen"
|
||||
- "Abgleich mit Problem Records"
|
||||
- "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Priorisiert und bestätigt Maßnahmen"
|
||||
- rolle: problem_manager
|
||||
raci: R
|
||||
kontext: "Führt taktische Analyse durch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_02
|
||||
name: "Service Performance & Improvement Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_02"
|
||||
|
||||
beschreibung: >
|
||||
Operativer Review des Servicezustands basierend auf Qualitätsberichten,
|
||||
Supportdaten und Problem-Analysen.
|
||||
|
||||
konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
methodik:
|
||||
beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung"
|
||||
dimensionen:
|
||||
- "SR-D1: Leistungserbringung"
|
||||
- "SR-D2: Betriebsstabilität"
|
||||
- "SR-D3: Nutzerzufriedenheit"
|
||||
- "SR-D4: Zukunftsfähigkeit"
|
||||
bewertungsskala: "Grün / Gelb / Rot"
|
||||
|
||||
umfasst:
|
||||
- "Abgleich der Service-Leistung gegen Ziele und SLAs"
|
||||
- "Bewertung des Gesamterfüllungsgrades der Serviceerbringung"
|
||||
- "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe"
|
||||
- "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)"
|
||||
- "Vorbereitung für SOR-Review"
|
||||
- "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist"
|
||||
|
||||
output_praezisierung:
|
||||
handlungsempfehlung:
|
||||
optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"]
|
||||
dokumentation: "Service-Definition -> service_review"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Review durch"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_03
|
||||
name: "SOR: Periodischer Service Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_03"
|
||||
|
||||
beschreibung: >
|
||||
Die SOR bewertet regelmäßig die Serviceleistung und trifft operative
|
||||
Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Sichtung des Service Performance & Improvement Reviews"
|
||||
- "Bewertung der Stabilität & Betriebsreife"
|
||||
- "Priorisierung operativer Verbesserungen"
|
||||
- "Freigabe kleinerer Verbesserungsmaßnahmen"
|
||||
- "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist"
|
||||
- "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Trifft Entscheidungen"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Berichtet & präsentiert"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: ep_weiter
|
||||
name: "Weiter wie bisher"
|
||||
bedingung: "Service stabil, keine Maßnahmen erforderlich"
|
||||
ziel_aktivitaet: null
|
||||
ziel_phase: "Operation"
|
||||
|
||||
- id: ep_improvement
|
||||
name: "Verbesserung nötig (klein)"
|
||||
bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung"
|
||||
ziel_aktivitaet: "rv_04"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_redesign
|
||||
name: "Strukturelle Überarbeitung nötig"
|
||||
bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht"
|
||||
ziel_aktivitaet: "rv_05"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_retirement
|
||||
name: "Service End-of-Life"
|
||||
bedingung: "Service soll stillgelegt werden"
|
||||
ziel_aktivitaet: "rv_06"
|
||||
ziel_phase: null
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_04
|
||||
name: "Service Improvement"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_04"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Planung und Steuerung von kleineren
|
||||
Verbesserungsmaßnahmen innerhalb des Service.
|
||||
|
||||
umfasst:
|
||||
- "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen"
|
||||
- "Aufwandsschätzung und Priorisierung"
|
||||
- "Festlegen der Zielmetriken für Verbesserung"
|
||||
- "Zuweisung der Verantwortlichkeiten"
|
||||
- "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Improvements, steuert Maßnahmen"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Für portfolio-relevante Anpassungen"
|
||||
- rolle: problem_manager
|
||||
raci: C
|
||||
kontext: "Für Problem-bezogene Maßnahmen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Operation"
|
||||
beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_05
|
||||
name: "Service Redesign / Erweiterung"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_05"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service
|
||||
auf Basis von SOR- oder Review-Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Überarbeitung der Service-Definitionen"
|
||||
- "Anpassung von Komponenten, Prozessen oder Rollen"
|
||||
- "Identifikation von Anforderungen für Entwicklungsprozess"
|
||||
- "Übergabe an Demand-Lifecycle-Prozess"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Redesign"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Anpassungen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Neuer Demand"
|
||||
beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_06
|
||||
name: "Service außer Betrieb nehmen"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_06"
|
||||
|
||||
beschreibung: >
|
||||
Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.
|
||||
|
||||
umfasst:
|
||||
- "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)"
|
||||
- "Bewertung durch SOR"
|
||||
- "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)"
|
||||
- "Koordination mit Portfolio (SPM)"
|
||||
- "Übergabe an Projekt-/Transitionsthemen falls notwendig"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Entscheidet"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Führt Retire-Plan aus"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Aktualisiert Portfolio"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan / Decommissioning-Auftrag"
|
||||
beschreibung: "Stilllegung wird als Demand/Projekt koordiniert"
|
||||
metadata:
|
||||
name: "Review"
|
||||
yasm_referenz: "LP5: Improve the services"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Periodische und anlassbezogene Bewertung der Service-Performance.
|
||||
Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung
|
||||
von Verbesserungsmaßnahmen bis hin zur Stilllegung.
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review"
|
||||
zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt.
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2025-12-17"
|
||||
beschreibung: |
|
||||
- Referenz auf spm_konzept_service-review.yaml hinzugefügt
|
||||
- Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001)
|
||||
- Output-Präzisierung für Handlungsempfehlungen ergänzt
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-11-26"
|
||||
beschreibung: "Initiale Erstellung"
|
||||
|
||||
referenzen:
|
||||
konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Operation"
|
||||
artefakt: "Service-Qualitätsbericht, Monitoring-Daten"
|
||||
- quelle: "Support"
|
||||
artefakt: "Support-KPIs, Problem Records, Incident-Trends"
|
||||
ausgang:
|
||||
- ziel: "Operation"
|
||||
artefakt: "Freigegebene Verbesserungsmaßnahmen"
|
||||
bedingung: "Bei Service Improvement"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Demand für strukturelle Änderung"
|
||||
bedingung: "Bei Service Redesign / Erweiterung"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan, Decommissioning-Auftrag"
|
||||
bedingung: "Bei Service außer Betrieb nehmen"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_01
|
||||
name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_01"
|
||||
|
||||
beschreibung: >
|
||||
Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs,
|
||||
um mittelfristige Verbesserungen anzustoßen.
|
||||
|
||||
umfasst:
|
||||
- "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)"
|
||||
- "Identifikation wiederkehrender Tickets und systemischer Ursachen"
|
||||
- "Abgleich mit Problem Records"
|
||||
- "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Priorisiert und bestätigt Maßnahmen"
|
||||
- rolle: problem_manager
|
||||
raci: R
|
||||
kontext: "Führt taktische Analyse durch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_02
|
||||
name: "Service Performance & Improvement Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_02"
|
||||
|
||||
beschreibung: >
|
||||
Operativer Review des Servicezustands basierend auf Qualitätsberichten,
|
||||
Supportdaten und Problem-Analysen.
|
||||
|
||||
konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
methodik:
|
||||
beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung"
|
||||
dimensionen:
|
||||
- "SR-D1: Leistungserbringung"
|
||||
- "SR-D2: Betriebsstabilität"
|
||||
- "SR-D3: Nutzerzufriedenheit"
|
||||
- "SR-D4: Zukunftsfähigkeit"
|
||||
bewertungsskala: "Grün / Gelb / Rot"
|
||||
|
||||
umfasst:
|
||||
- "Abgleich der Service-Leistung gegen Ziele und SLAs"
|
||||
- "Bewertung des Gesamterfüllungsgrades der Serviceerbringung"
|
||||
- "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe"
|
||||
- "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)"
|
||||
- "Vorbereitung für SOR-Review"
|
||||
- "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist"
|
||||
|
||||
output_praezisierung:
|
||||
handlungsempfehlung:
|
||||
optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"]
|
||||
dokumentation: "Service-Definition -> service_review"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Review durch"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_03
|
||||
name: "SOR: Periodischer Service Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_03"
|
||||
|
||||
beschreibung: >
|
||||
Die SOR bewertet regelmäßig die Serviceleistung und trifft operative
|
||||
Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Sichtung des Service Performance & Improvement Reviews"
|
||||
- "Bewertung der Stabilität & Betriebsreife"
|
||||
- "Priorisierung operativer Verbesserungen"
|
||||
- "Freigabe kleinerer Verbesserungsmaßnahmen"
|
||||
- "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist"
|
||||
- "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Trifft Entscheidungen"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Berichtet & präsentiert"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: ep_weiter
|
||||
name: "Weiter wie bisher"
|
||||
bedingung: "Service stabil, keine Maßnahmen erforderlich"
|
||||
ziel_aktivitaet: null
|
||||
ziel_phase: "Operation"
|
||||
|
||||
- id: ep_improvement
|
||||
name: "Verbesserung nötig (klein)"
|
||||
bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung"
|
||||
ziel_aktivitaet: "rv_04"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_redesign
|
||||
name: "Strukturelle Überarbeitung nötig"
|
||||
bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht"
|
||||
ziel_aktivitaet: "rv_05"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_retirement
|
||||
name: "Service End-of-Life"
|
||||
bedingung: "Service soll stillgelegt werden"
|
||||
ziel_aktivitaet: "rv_06"
|
||||
ziel_phase: null
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_04
|
||||
name: "Service Improvement"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_04"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Planung und Steuerung von kleineren
|
||||
Verbesserungsmaßnahmen innerhalb des Service.
|
||||
|
||||
umfasst:
|
||||
- "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen"
|
||||
- "Aufwandsschätzung und Priorisierung"
|
||||
- "Festlegen der Zielmetriken für Verbesserung"
|
||||
- "Zuweisung der Verantwortlichkeiten"
|
||||
- "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Improvements, steuert Maßnahmen"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Für portfolio-relevante Anpassungen"
|
||||
- rolle: problem_manager
|
||||
raci: C
|
||||
kontext: "Für Problem-bezogene Maßnahmen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Operation"
|
||||
beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_05
|
||||
name: "Service Redesign / Erweiterung"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_05"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service
|
||||
auf Basis von SOR- oder Review-Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Überarbeitung der Service-Definitionen"
|
||||
- "Anpassung von Komponenten, Prozessen oder Rollen"
|
||||
- "Identifikation von Anforderungen für Entwicklungsprozess"
|
||||
- "Übergabe an Demand-Lifecycle-Prozess"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Redesign"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Anpassungen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Neuer Demand"
|
||||
beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_06
|
||||
name: "Service außer Betrieb nehmen"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_06"
|
||||
|
||||
beschreibung: >
|
||||
Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.
|
||||
|
||||
umfasst:
|
||||
- "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)"
|
||||
- "Bewertung durch SOR"
|
||||
- "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)"
|
||||
- "Koordination mit Portfolio (SPM)"
|
||||
- "Übergabe an Projekt-/Transitionsthemen falls notwendig"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Entscheidet"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Führt Retire-Plan aus"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Aktualisiert Portfolio"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan / Decommissioning-Auftrag"
|
||||
beschreibung: "Stilllegung wird als Demand/Projekt koordiniert"
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -1,407 +1,407 @@
|
|||
metadata:
|
||||
name: "Rollendefinitionen Service-Lifecycle"
|
||||
version: "1.1"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-31"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden.
|
||||
Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen.
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.1"
|
||||
datum: "2026-01-31"
|
||||
aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen"
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten"
|
||||
|
||||
# =============================================================================
|
||||
# RACI-Legende (für Referenz in Prozess-YAMLs)
|
||||
# =============================================================================
|
||||
raci_legende:
|
||||
R: "Responsible – führt die Aktivität operativ aus"
|
||||
A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)"
|
||||
C: "Consulted – wird vor Entscheidung/Durchführung einbezogen"
|
||||
I: "Informed – wird über Ergebnis informiert"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENKATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
rollen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GOVERNANCE & STRATEGISCHE STEUERUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
governance:
|
||||
|
||||
- id: spm
|
||||
name: "Service-Portfolio-Manager"
|
||||
kurzbezeichnung: "SPM"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme,
|
||||
Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung,
|
||||
Priorisierung und Wirtschaftlichkeit.
|
||||
verantwortlichkeiten:
|
||||
- "Strategische Portfolio-Steuerung"
|
||||
- "Entscheidungen zu Service-Aufnahme und -Stilllegung"
|
||||
- "Sicherstellung der Wirtschaftlichkeit"
|
||||
- "Portfolio-Konsistenz und Standards"
|
||||
- "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)"
|
||||
- "Identifikation portfolio-uebergreifender Muster aus Reviews"
|
||||
- "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)"
|
||||
- "Vollstaendigkeitspruefung der SOR-Vorlagen"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: sor
|
||||
name: "Service Operations Runde"
|
||||
kurzbezeichnung: "SOR"
|
||||
typ: "Gremium"
|
||||
beschreibung: >
|
||||
Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche
|
||||
Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken
|
||||
und organisatorische Abstimmung.
|
||||
verantwortlichkeiten:
|
||||
- "Freigabe von Service-Aktivierungen"
|
||||
- "Bewertung der Betriebsreife"
|
||||
- "Entscheidung über wesentliche Anpassungen"
|
||||
- "Risikobewertung und organisatorische Abstimmung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: service_owner
|
||||
name: "Service Owner"
|
||||
kurzbezeichnung: "SO"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert
|
||||
Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer
|
||||
Service-Inhalt und -Wert.
|
||||
verantwortlichkeiten:
|
||||
- "End-to-End-Verantwortung fuer den Service"
|
||||
- "Definition von Anforderungen und Qualitaetszielen"
|
||||
- "Steuerung der Weiterentwicklung"
|
||||
- "Fachliche Freigaben und Priorisierungen"
|
||||
- "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002"
|
||||
- "Improvement-Tracking in der Service-Definition (GOV-SR-005)"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MANAGEMENT-ROLLEN (Operative Führung)
|
||||
# ---------------------------------------------------------------------------
|
||||
management:
|
||||
|
||||
- id: al_basis_cloud
|
||||
name: "Abteilungsleitung Basis & Cloud"
|
||||
kurzbezeichnung: "AL B&C"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert
|
||||
die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung
|
||||
von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Infrastruktur-Betrieb"
|
||||
- "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Infrastrukturbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR"
|
||||
themengruppen:
|
||||
- "Netzwerk"
|
||||
- "Cloud"
|
||||
- "Deployment"
|
||||
- "Infrastruktur-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: al_applikationen
|
||||
name: "Abteilungsleitung Applikationen"
|
||||
kurzbezeichnung: "AL App"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen).
|
||||
Koordiniert die Betriebsteams im Anwendungsbereich und stellt die
|
||||
Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Anwendungs-Betrieb"
|
||||
- "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Anwendungsbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Anwendungs-Services in der SOR"
|
||||
themengruppen:
|
||||
- "SAP"
|
||||
- "Ennaio"
|
||||
- "Fachverfahren"
|
||||
- "Anwendungs-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: support_manager
|
||||
name: "Support Manager"
|
||||
kurzbezeichnung: "Sup Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level).
|
||||
Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes
|
||||
Incident/Request-Handling.
|
||||
verantwortlichkeiten:
|
||||
- "Organisation des Service-Supports"
|
||||
- "Qualitätssicherung im Support"
|
||||
- "Prozess- und Leitlinienentwicklung"
|
||||
- "Wissensmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
- id: problem_manager
|
||||
name: "Problem Manager"
|
||||
kurzbezeichnung: "Prob Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Identifiziert wiederkehrende oder strukturelle Störungen, führt
|
||||
Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für
|
||||
dauerhafte Fehlerbehebung und Workarounds.
|
||||
verantwortlichkeiten:
|
||||
- "Identifikation struktureller Störungen"
|
||||
- "Durchführung von Root-Cause-Analysen"
|
||||
- "Steuerung von Problemlösungen"
|
||||
- "Bereitstellung von Workarounds"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
- id: projektleitung
|
||||
name: "Projektleitung"
|
||||
kurzbezeichnung: "PL"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen,
|
||||
Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und
|
||||
qualitätsgesicherte Lieferung der Projektartefakte.
|
||||
verantwortlichkeiten:
|
||||
- "Planung und Steuerung von Entwicklungsprojekten"
|
||||
- "Ressourcen- und Lieferantenkoordination"
|
||||
- "Termin- und Qualitätssicherung"
|
||||
- "Lieferung der Projektartefakte"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# TEAMS (Kollektive Rollen)
|
||||
# ---------------------------------------------------------------------------
|
||||
teams:
|
||||
|
||||
- id: betriebsteam
|
||||
name: "Betriebsteam"
|
||||
kurzbezeichnung: "Betrieb"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Führt alle laufenden Betriebsaktivitäten für den Service aus - von
|
||||
anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung.
|
||||
Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und
|
||||
tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität
|
||||
des Betriebs.
|
||||
verantwortlichkeiten:
|
||||
- "Durchführung laufender Betriebsaufgaben"
|
||||
- "Monitoring und Überwachung"
|
||||
- "Ausführung von Standard-Changes"
|
||||
- "Deployment und Rollout von Komponenten"
|
||||
- "Betreuung technischer Infrastruktur"
|
||||
- "Tiefgehende Diagnosen und Fehleranalyse"
|
||||
- "Systempflege und -wartung"
|
||||
- "Sicherstellung von Stabilität und Verfügbarkeit"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
|
||||
- id: service_support_team
|
||||
name: "Service-Support Team"
|
||||
kurzbezeichnung: "Support"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle
|
||||
Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen
|
||||
Anwendern, Betrieb und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung von Nutzeranfragen"
|
||||
- "Incident-Bearbeitung (1st/2nd Level)"
|
||||
- "Schnelle Wiederherstellung"
|
||||
- "Schnittstelle zu Betrieb und Problemmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Support"
|
||||
|
||||
- id: projektteam
|
||||
name: "Projektteam"
|
||||
kurzbezeichnung: "Projekt"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und
|
||||
Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe
|
||||
und Betriebsbefähigung.
|
||||
verantwortlichkeiten:
|
||||
- "Entwicklung und Konfiguration"
|
||||
- "Testdurchführung"
|
||||
- "Dokumentation"
|
||||
- "Unterstützung bei Übergabe und Betriebsbefähigung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# INDIVIDUELLE OPERATIVE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
operative_rollen:
|
||||
|
||||
- id: queue_koordinator
|
||||
name: "Queue Koordinator"
|
||||
kurzbezeichnung: "Queue Koord"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen
|
||||
und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und
|
||||
effizienten Ticketfluss sicher.
|
||||
verantwortlichkeiten:
|
||||
- "Überwachung des Ticketaufkommens"
|
||||
- "Ticketverteilung und Routing"
|
||||
- "Priorisierung und SLA-Überwachung"
|
||||
- "Sicherstellung des Ticketflusses"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: first_level_agent
|
||||
name: "1st Level Agent"
|
||||
kurzbezeichnung: "L1"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst
|
||||
Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den
|
||||
2nd Level bei Bedarf.
|
||||
verantwortlichkeiten:
|
||||
- "Entgegennahme von Incidents und Requests"
|
||||
- "Lösung von Standardfällen"
|
||||
- "Saubere Dokumentation"
|
||||
- "Fachgerechte Eskalation"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: second_level_agent
|
||||
name: "2nd Level Agent"
|
||||
kurzbezeichnung: "L2"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere
|
||||
Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb,
|
||||
Herstellern und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung komplexer Störungen"
|
||||
- "Tiefere Analysen und Diagnosen"
|
||||
- "Lösungsbereitstellung"
|
||||
- "Kooperation mit Betrieb und Herstellern"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: testmanagement
|
||||
name: "Testmanagement"
|
||||
kurzbezeichnung: "Test Mgmt"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression)
|
||||
während Service-Entwicklung und Transition. Sichert die Qualität und
|
||||
Betriebsreife neuer Service-Komponenten.
|
||||
verantwortlichkeiten:
|
||||
- "Testplanung und -organisation"
|
||||
- "Verantwortung für Testdurchführung"
|
||||
- "Qualitätssicherung neuer Komponenten"
|
||||
- "Nachweis der Betriebsreife"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
- id: architektur
|
||||
name: "Architektur"
|
||||
kurzbezeichnung: "Arch"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen;
|
||||
bewertet Designvarianten und Risiken. Sichert technische Konsistenz und
|
||||
Zukunftsfähigkeit des Service.
|
||||
verantwortlichkeiten:
|
||||
- "Definition technischer Standards"
|
||||
- "Entwicklung von Zielarchitekturen"
|
||||
- "Bewertung von Designvarianten und Risiken"
|
||||
- "Sicherstellung technischer Konsistenz"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# EXTERNE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
externe:
|
||||
|
||||
- id: lieferant
|
||||
name: "Lieferant / Hersteller / Entwickler"
|
||||
kurzbezeichnung: "Lieferant"
|
||||
typ: "Externe Rolle"
|
||||
beschreibung: >
|
||||
Stellt externe System-, Software- oder Infrastrukturkomponenten bereit
|
||||
oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse
|
||||
und Komponentensupport eingebunden.
|
||||
verantwortlichkeiten:
|
||||
- "Bereitstellung externer Komponenten"
|
||||
- "Entwicklung spezifischer Anpassungen"
|
||||
- "Unterstützung bei Fehleranalyse"
|
||||
- "Komponentensupport"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-MAPPING (für schnelle Referenz)
|
||||
# =============================================================================
|
||||
rollen_index:
|
||||
# Kurzreferenz: id -> name
|
||||
spm: "Service-Portfolio-Manager"
|
||||
sor: "Service Operations Runde"
|
||||
service_owner: "Service Owner"
|
||||
al_basis_cloud: "Abteilungsleitung Basis & Cloud"
|
||||
al_applikationen: "Abteilungsleitung Applikationen"
|
||||
support_manager: "Support Manager"
|
||||
problem_manager: "Problem Manager"
|
||||
projektleitung: "Projektleitung"
|
||||
betriebsteam: "Betriebsteam"
|
||||
service_support_team: "Service-Support Team"
|
||||
projektteam: "Projektteam"
|
||||
queue_koordinator: "Queue Koordinator"
|
||||
first_level_agent: "1st Level Agent"
|
||||
second_level_agent: "2nd Level Agent"
|
||||
testmanagement: "Testmanagement"
|
||||
architektur: "Architektur"
|
||||
metadata:
|
||||
name: "Rollendefinitionen Service-Lifecycle"
|
||||
version: "1.1"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-31"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden.
|
||||
Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen.
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.1"
|
||||
datum: "2026-01-31"
|
||||
aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen"
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten"
|
||||
|
||||
# =============================================================================
|
||||
# RACI-Legende (für Referenz in Prozess-YAMLs)
|
||||
# =============================================================================
|
||||
raci_legende:
|
||||
R: "Responsible – führt die Aktivität operativ aus"
|
||||
A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)"
|
||||
C: "Consulted – wird vor Entscheidung/Durchführung einbezogen"
|
||||
I: "Informed – wird über Ergebnis informiert"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENKATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
rollen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GOVERNANCE & STRATEGISCHE STEUERUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
governance:
|
||||
|
||||
- id: spm
|
||||
name: "Service-Portfolio-Manager"
|
||||
kurzbezeichnung: "SPM"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme,
|
||||
Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung,
|
||||
Priorisierung und Wirtschaftlichkeit.
|
||||
verantwortlichkeiten:
|
||||
- "Strategische Portfolio-Steuerung"
|
||||
- "Entscheidungen zu Service-Aufnahme und -Stilllegung"
|
||||
- "Sicherstellung der Wirtschaftlichkeit"
|
||||
- "Portfolio-Konsistenz und Standards"
|
||||
- "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)"
|
||||
- "Identifikation portfolio-uebergreifender Muster aus Reviews"
|
||||
- "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)"
|
||||
- "Vollstaendigkeitspruefung der SOR-Vorlagen"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: sor
|
||||
name: "Service Operations Runde"
|
||||
kurzbezeichnung: "SOR"
|
||||
typ: "Gremium"
|
||||
beschreibung: >
|
||||
Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche
|
||||
Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken
|
||||
und organisatorische Abstimmung.
|
||||
verantwortlichkeiten:
|
||||
- "Freigabe von Service-Aktivierungen"
|
||||
- "Bewertung der Betriebsreife"
|
||||
- "Entscheidung über wesentliche Anpassungen"
|
||||
- "Risikobewertung und organisatorische Abstimmung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: service_owner
|
||||
name: "Service Owner"
|
||||
kurzbezeichnung: "SO"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert
|
||||
Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer
|
||||
Service-Inhalt und -Wert.
|
||||
verantwortlichkeiten:
|
||||
- "End-to-End-Verantwortung fuer den Service"
|
||||
- "Definition von Anforderungen und Qualitaetszielen"
|
||||
- "Steuerung der Weiterentwicklung"
|
||||
- "Fachliche Freigaben und Priorisierungen"
|
||||
- "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002"
|
||||
- "Improvement-Tracking in der Service-Definition (GOV-SR-005)"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MANAGEMENT-ROLLEN (Operative Führung)
|
||||
# ---------------------------------------------------------------------------
|
||||
management:
|
||||
|
||||
- id: al_basis_cloud
|
||||
name: "Abteilungsleitung Basis & Cloud"
|
||||
kurzbezeichnung: "AL B&C"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert
|
||||
die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung
|
||||
von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Infrastruktur-Betrieb"
|
||||
- "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Infrastrukturbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR"
|
||||
themengruppen:
|
||||
- "Netzwerk"
|
||||
- "Cloud"
|
||||
- "Deployment"
|
||||
- "Infrastruktur-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: al_applikationen
|
||||
name: "Abteilungsleitung Applikationen"
|
||||
kurzbezeichnung: "AL App"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen).
|
||||
Koordiniert die Betriebsteams im Anwendungsbereich und stellt die
|
||||
Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Anwendungs-Betrieb"
|
||||
- "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Anwendungsbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Anwendungs-Services in der SOR"
|
||||
themengruppen:
|
||||
- "SAP"
|
||||
- "Ennaio"
|
||||
- "Fachverfahren"
|
||||
- "Anwendungs-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: support_manager
|
||||
name: "Support Manager"
|
||||
kurzbezeichnung: "Sup Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level).
|
||||
Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes
|
||||
Incident/Request-Handling.
|
||||
verantwortlichkeiten:
|
||||
- "Organisation des Service-Supports"
|
||||
- "Qualitätssicherung im Support"
|
||||
- "Prozess- und Leitlinienentwicklung"
|
||||
- "Wissensmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
- id: problem_manager
|
||||
name: "Problem Manager"
|
||||
kurzbezeichnung: "Prob Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Identifiziert wiederkehrende oder strukturelle Störungen, führt
|
||||
Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für
|
||||
dauerhafte Fehlerbehebung und Workarounds.
|
||||
verantwortlichkeiten:
|
||||
- "Identifikation struktureller Störungen"
|
||||
- "Durchführung von Root-Cause-Analysen"
|
||||
- "Steuerung von Problemlösungen"
|
||||
- "Bereitstellung von Workarounds"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
- id: projektleitung
|
||||
name: "Projektleitung"
|
||||
kurzbezeichnung: "PL"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen,
|
||||
Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und
|
||||
qualitätsgesicherte Lieferung der Projektartefakte.
|
||||
verantwortlichkeiten:
|
||||
- "Planung und Steuerung von Entwicklungsprojekten"
|
||||
- "Ressourcen- und Lieferantenkoordination"
|
||||
- "Termin- und Qualitätssicherung"
|
||||
- "Lieferung der Projektartefakte"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# TEAMS (Kollektive Rollen)
|
||||
# ---------------------------------------------------------------------------
|
||||
teams:
|
||||
|
||||
- id: betriebsteam
|
||||
name: "Betriebsteam"
|
||||
kurzbezeichnung: "Betrieb"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Führt alle laufenden Betriebsaktivitäten für den Service aus - von
|
||||
anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung.
|
||||
Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und
|
||||
tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität
|
||||
des Betriebs.
|
||||
verantwortlichkeiten:
|
||||
- "Durchführung laufender Betriebsaufgaben"
|
||||
- "Monitoring und Überwachung"
|
||||
- "Ausführung von Standard-Changes"
|
||||
- "Deployment und Rollout von Komponenten"
|
||||
- "Betreuung technischer Infrastruktur"
|
||||
- "Tiefgehende Diagnosen und Fehleranalyse"
|
||||
- "Systempflege und -wartung"
|
||||
- "Sicherstellung von Stabilität und Verfügbarkeit"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
|
||||
- id: service_support_team
|
||||
name: "Service-Support Team"
|
||||
kurzbezeichnung: "Support"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle
|
||||
Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen
|
||||
Anwendern, Betrieb und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung von Nutzeranfragen"
|
||||
- "Incident-Bearbeitung (1st/2nd Level)"
|
||||
- "Schnelle Wiederherstellung"
|
||||
- "Schnittstelle zu Betrieb und Problemmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Support"
|
||||
|
||||
- id: projektteam
|
||||
name: "Projektteam"
|
||||
kurzbezeichnung: "Projekt"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und
|
||||
Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe
|
||||
und Betriebsbefähigung.
|
||||
verantwortlichkeiten:
|
||||
- "Entwicklung und Konfiguration"
|
||||
- "Testdurchführung"
|
||||
- "Dokumentation"
|
||||
- "Unterstützung bei Übergabe und Betriebsbefähigung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# INDIVIDUELLE OPERATIVE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
operative_rollen:
|
||||
|
||||
- id: queue_koordinator
|
||||
name: "Queue Koordinator"
|
||||
kurzbezeichnung: "Queue Koord"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen
|
||||
und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und
|
||||
effizienten Ticketfluss sicher.
|
||||
verantwortlichkeiten:
|
||||
- "Überwachung des Ticketaufkommens"
|
||||
- "Ticketverteilung und Routing"
|
||||
- "Priorisierung und SLA-Überwachung"
|
||||
- "Sicherstellung des Ticketflusses"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: first_level_agent
|
||||
name: "1st Level Agent"
|
||||
kurzbezeichnung: "L1"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst
|
||||
Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den
|
||||
2nd Level bei Bedarf.
|
||||
verantwortlichkeiten:
|
||||
- "Entgegennahme von Incidents und Requests"
|
||||
- "Lösung von Standardfällen"
|
||||
- "Saubere Dokumentation"
|
||||
- "Fachgerechte Eskalation"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: second_level_agent
|
||||
name: "2nd Level Agent"
|
||||
kurzbezeichnung: "L2"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere
|
||||
Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb,
|
||||
Herstellern und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung komplexer Störungen"
|
||||
- "Tiefere Analysen und Diagnosen"
|
||||
- "Lösungsbereitstellung"
|
||||
- "Kooperation mit Betrieb und Herstellern"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: testmanagement
|
||||
name: "Testmanagement"
|
||||
kurzbezeichnung: "Test Mgmt"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression)
|
||||
während Service-Entwicklung und Transition. Sichert die Qualität und
|
||||
Betriebsreife neuer Service-Komponenten.
|
||||
verantwortlichkeiten:
|
||||
- "Testplanung und -organisation"
|
||||
- "Verantwortung für Testdurchführung"
|
||||
- "Qualitätssicherung neuer Komponenten"
|
||||
- "Nachweis der Betriebsreife"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
- id: architektur
|
||||
name: "Architektur"
|
||||
kurzbezeichnung: "Arch"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen;
|
||||
bewertet Designvarianten und Risiken. Sichert technische Konsistenz und
|
||||
Zukunftsfähigkeit des Service.
|
||||
verantwortlichkeiten:
|
||||
- "Definition technischer Standards"
|
||||
- "Entwicklung von Zielarchitekturen"
|
||||
- "Bewertung von Designvarianten und Risiken"
|
||||
- "Sicherstellung technischer Konsistenz"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# EXTERNE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
externe:
|
||||
|
||||
- id: lieferant
|
||||
name: "Lieferant / Hersteller / Entwickler"
|
||||
kurzbezeichnung: "Lieferant"
|
||||
typ: "Externe Rolle"
|
||||
beschreibung: >
|
||||
Stellt externe System-, Software- oder Infrastrukturkomponenten bereit
|
||||
oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse
|
||||
und Komponentensupport eingebunden.
|
||||
verantwortlichkeiten:
|
||||
- "Bereitstellung externer Komponenten"
|
||||
- "Entwicklung spezifischer Anpassungen"
|
||||
- "Unterstützung bei Fehleranalyse"
|
||||
- "Komponentensupport"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-MAPPING (für schnelle Referenz)
|
||||
# =============================================================================
|
||||
rollen_index:
|
||||
# Kurzreferenz: id -> name
|
||||
spm: "Service-Portfolio-Manager"
|
||||
sor: "Service Operations Runde"
|
||||
service_owner: "Service Owner"
|
||||
al_basis_cloud: "Abteilungsleitung Basis & Cloud"
|
||||
al_applikationen: "Abteilungsleitung Applikationen"
|
||||
support_manager: "Support Manager"
|
||||
problem_manager: "Problem Manager"
|
||||
projektleitung: "Projektleitung"
|
||||
betriebsteam: "Betriebsteam"
|
||||
service_support_team: "Service-Support Team"
|
||||
projektteam: "Projektteam"
|
||||
queue_koordinator: "Queue Koordinator"
|
||||
first_level_agent: "1st Level Agent"
|
||||
second_level_agent: "2nd Level Agent"
|
||||
testmanagement: "Testmanagement"
|
||||
architektur: "Architektur"
|
||||
lieferant: "Lieferant / Hersteller / Entwickler"
|
||||
|
|
@ -1,104 +1,104 @@
|
|||
# =============================================================================
|
||||
# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT)
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "K-BL"
|
||||
name: "Service-Betrieb Light-Weight Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-15"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "konzept"
|
||||
|
||||
beschreibung: >
|
||||
Minimales Strukturkonzept für den Service-Betrieb. Definiert
|
||||
Betriebsrollen und grundlegende Verantwortungsabgrenzungen,
|
||||
um Anschlussfähigkeit an die operative Organisation herzustellen.
|
||||
|
||||
scope_hinweis: >
|
||||
BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine
|
||||
vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase.
|
||||
|
||||
referenzen:
|
||||
blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml"
|
||||
rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# BEGRÜNDUNG
|
||||
# =============================================================================
|
||||
|
||||
begruendung:
|
||||
workshop_befund: >
|
||||
Ohne minimale Strukturelemente für den Service-Betrieb fehlt die
|
||||
Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft
|
||||
muss sich im Modell wiederfinden, sonst keine Legitimation.
|
||||
|
||||
systemtheoretisch: >
|
||||
Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur,
|
||||
die von der Organisation als "Management-Theater" abgekoppelt wird.
|
||||
|
||||
# =============================================================================
|
||||
# GLIEDERUNG (zu entwickeln)
|
||||
# =============================================================================
|
||||
|
||||
gliederung:
|
||||
|
||||
- abschnitt: "Scope und Abgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Was dieses Konzept ist (Strukturanker)"
|
||||
- "Was dieses Konzept nicht ist (kein Betriebshandbuch)"
|
||||
- "Verweis auf Blueprint für Aktivitäten"
|
||||
|
||||
- abschnitt: "Betriebsrollen (Minimum)"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Operations Manager"
|
||||
- "Betriebsteam"
|
||||
- "Technical Lead (optional)"
|
||||
referenz: "spm_rollen.yaml → management, operativ"
|
||||
|
||||
- abschnitt: "Verantwortungsabgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Service Owner vs. Operations Manager"
|
||||
- "Betrieb vs. Support (Incident-Handling)"
|
||||
- "Proaktiv vs. Reaktiv"
|
||||
|
||||
- abschnitt: "Schnittstelle zu Support"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Eskalationswege bei Incidents"
|
||||
- "Problem-Identifikation"
|
||||
- "Wissenstransfer"
|
||||
|
||||
- abschnitt: "Monitoring-Verantwortung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Wer definiert Schwellwerte?"
|
||||
- "Wer reagiert auf Alerts?"
|
||||
- "Wer erstellt Qualitätsberichte?"
|
||||
|
||||
# =============================================================================
|
||||
# EXPLIZITE NICHT-INHALTE
|
||||
# =============================================================================
|
||||
|
||||
nicht_inhalte:
|
||||
themen:
|
||||
- "Detaillierte Betriebsprozesse"
|
||||
- "Monitoring-Tool-Auswahl"
|
||||
- "Kapazitätsplanung"
|
||||
- "Change-Management im Betrieb"
|
||||
hinweis: "Diese Themen werden in Phase X vertieft."
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-15"
|
||||
aenderung: "Placeholder erstellt mit Gliederungsskelett"
|
||||
autor: "DIGITOM-Projekt"
|
||||
# =============================================================================
|
||||
# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT)
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "K-BL"
|
||||
name: "Service-Betrieb Light-Weight Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-15"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "konzept"
|
||||
|
||||
beschreibung: >
|
||||
Minimales Strukturkonzept für den Service-Betrieb. Definiert
|
||||
Betriebsrollen und grundlegende Verantwortungsabgrenzungen,
|
||||
um Anschlussfähigkeit an die operative Organisation herzustellen.
|
||||
|
||||
scope_hinweis: >
|
||||
BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine
|
||||
vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase.
|
||||
|
||||
referenzen:
|
||||
blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml"
|
||||
rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# BEGRÜNDUNG
|
||||
# =============================================================================
|
||||
|
||||
begruendung:
|
||||
workshop_befund: >
|
||||
Ohne minimale Strukturelemente für den Service-Betrieb fehlt die
|
||||
Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft
|
||||
muss sich im Modell wiederfinden, sonst keine Legitimation.
|
||||
|
||||
systemtheoretisch: >
|
||||
Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur,
|
||||
die von der Organisation als "Management-Theater" abgekoppelt wird.
|
||||
|
||||
# =============================================================================
|
||||
# GLIEDERUNG (zu entwickeln)
|
||||
# =============================================================================
|
||||
|
||||
gliederung:
|
||||
|
||||
- abschnitt: "Scope und Abgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Was dieses Konzept ist (Strukturanker)"
|
||||
- "Was dieses Konzept nicht ist (kein Betriebshandbuch)"
|
||||
- "Verweis auf Blueprint für Aktivitäten"
|
||||
|
||||
- abschnitt: "Betriebsrollen (Minimum)"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Operations Manager"
|
||||
- "Betriebsteam"
|
||||
- "Technical Lead (optional)"
|
||||
referenz: "spm_rollen.yaml → management, operativ"
|
||||
|
||||
- abschnitt: "Verantwortungsabgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Service Owner vs. Operations Manager"
|
||||
- "Betrieb vs. Support (Incident-Handling)"
|
||||
- "Proaktiv vs. Reaktiv"
|
||||
|
||||
- abschnitt: "Schnittstelle zu Support"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Eskalationswege bei Incidents"
|
||||
- "Problem-Identifikation"
|
||||
- "Wissenstransfer"
|
||||
|
||||
- abschnitt: "Monitoring-Verantwortung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Wer definiert Schwellwerte?"
|
||||
- "Wer reagiert auf Alerts?"
|
||||
- "Wer erstellt Qualitätsberichte?"
|
||||
|
||||
# =============================================================================
|
||||
# EXPLIZITE NICHT-INHALTE
|
||||
# =============================================================================
|
||||
|
||||
nicht_inhalte:
|
||||
themen:
|
||||
- "Detaillierte Betriebsprozesse"
|
||||
- "Monitoring-Tool-Auswahl"
|
||||
- "Kapazitätsplanung"
|
||||
- "Change-Management im Betrieb"
|
||||
hinweis: "Diese Themen werden in Phase X vertieft."
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-15"
|
||||
aenderung: "Placeholder erstellt mit Gliederungsskelett"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,165 +1,165 @@
|
|||
# =============================================================================
|
||||
# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I)
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Entwurf (Pilotphase)
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-002
|
||||
#
|
||||
# Zweck:
|
||||
# Vorlage zur Erstellung eines Operational Level Agreements (OLA) für
|
||||
# Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase
|
||||
# befüllt, wenn operative Erfahrungswerte vorliegen.
|
||||
#
|
||||
# Abgrenzung:
|
||||
# - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C)
|
||||
# - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I)
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 1. IDENTIFIKATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
identifikation:
|
||||
ola_id: "" # z.B. "OLA-INT-001"
|
||||
ola_titel: "" # z.B. "OLA Active Directory Services"
|
||||
version: "" # z.B. "1.0"
|
||||
status: "" # Entwurf | Aktiv | In Review | Außer Kraft
|
||||
erstellungsdatum: "" # YYYY-MM-DD
|
||||
letzte_aktualisierung: "" # YYYY-MM-DD
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
|
||||
service_referenz:
|
||||
service_name: "" # Name des Internen Services
|
||||
service_id: "" # ID gemäß Service-Definition
|
||||
service_kategorie: "I" # Immer "I" für Interne Services
|
||||
service_owner: "" # Name / Rolle
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 2. VERTRAGSPARTEIEN (INTERN)
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
vertragsparteien:
|
||||
|
||||
liefernde_einheit:
|
||||
name: "" # z.B. "Team Infrastruktur"
|
||||
verantwortlich: "" # Name / Rolle des Ansprechpartners
|
||||
kontakt: "" # E-Mail / Telefon
|
||||
|
||||
nutzende_einheiten:
|
||||
- name: "" # z.B. "Team Applikationsbetrieb"
|
||||
verantwortlich: ""
|
||||
kontakt: ""
|
||||
abhängige_kundenservices: # Welche Kategorie A/B/C-Services hängen davon ab?
|
||||
- ""
|
||||
|
||||
hinweis: |
|
||||
Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden.
|
||||
Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices
|
||||
(Kategorie A/B/C) vom Internen Service abhängen.
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 3. LEISTUNGSBESCHREIBUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
leistungsbeschreibung:
|
||||
|
||||
kurzbeschreibung: "" # 2-3 Sätze: Was leistet der Service?
|
||||
|
||||
leistungsumfang:
|
||||
enthalten:
|
||||
- "" # Auflistung der enthaltenen Leistungen
|
||||
nicht_enthalten:
|
||||
- "" # Explizite Ausschlüsse
|
||||
|
||||
betriebszeiten:
|
||||
regulaer: "" # z.B. "Mo-Fr 07:00-18:00"
|
||||
erweitert: "" # z.B. "24/7 für kritische Systeme"
|
||||
wartungsfenster: "" # z.B. "Sonntag 02:00-06:00"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 4. QUALITÄTSZIELE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
qualitaetsziele:
|
||||
|
||||
verfuegbarkeit:
|
||||
zielwert: "" # z.B. "99,5 %"
|
||||
messperiode: "" # z.B. "Kalendermonat"
|
||||
messmethode: "" # z.B. "Monitoring-Tool X, Uptime-Berechnung"
|
||||
ausnahmen: "" # z.B. "Geplante Wartung ausgenommen"
|
||||
|
||||
performance:
|
||||
- metrik: "" # z.B. "Antwortzeit Authentifizierung"
|
||||
zielwert: "" # z.B. "< 200 ms (95. Perzentil)"
|
||||
messmethode: ""
|
||||
|
||||
kapazitaet:
|
||||
aktuell: "" # z.B. "500 gleichzeitige Nutzer"
|
||||
geplant: "" # z.B. "800 gleichzeitige Nutzer bis Q4/2026"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 5. ESKALATIONSWEGE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
eskalationswege:
|
||||
|
||||
stufe_1:
|
||||
beschreibung: "Operativer Kontakt"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: "" # z.B. "30 Minuten während Betriebszeiten"
|
||||
|
||||
stufe_2:
|
||||
beschreibung: "Teamleitung / Service Owner"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: ""
|
||||
|
||||
stufe_3:
|
||||
beschreibung: "Eskalation an SOR / Mission Board"
|
||||
ausloeser: |
|
||||
- Wiederholte Verfehlung der Qualitätsziele
|
||||
- Cross-Service-Impact auf Kundenservices
|
||||
referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 6. REVIEW-MECHANISMUS
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
review:
|
||||
|
||||
review_zyklus: "" # z.B. "Halbjährlich"
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
review_teilnehmer:
|
||||
- "" # Rollen / Namen
|
||||
|
||||
aenderungsverfahren: |
|
||||
Änderungen am OLA werden vom Service Owner des Internen Services
|
||||
initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen
|
||||
mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich
|
||||
(vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 7. LAUFZEIT UND KÜNDIGUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
laufzeit:
|
||||
beginn: "" # YYYY-MM-DD
|
||||
laufzeit: "" # z.B. "Unbefristet, jährlicher Review"
|
||||
kuendigungsfrist: "" # z.B. "3 Monate zum Quartalsende"
|
||||
kuendigungsbedingungen: |
|
||||
Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den
|
||||
Internen Service durch den SOR voraus (vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung des OLA-Templates"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-002, OQ-001"
|
||||
# =============================================================================
|
||||
# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I)
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Entwurf (Pilotphase)
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-002
|
||||
#
|
||||
# Zweck:
|
||||
# Vorlage zur Erstellung eines Operational Level Agreements (OLA) für
|
||||
# Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase
|
||||
# befüllt, wenn operative Erfahrungswerte vorliegen.
|
||||
#
|
||||
# Abgrenzung:
|
||||
# - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C)
|
||||
# - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I)
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 1. IDENTIFIKATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
identifikation:
|
||||
ola_id: "" # z.B. "OLA-INT-001"
|
||||
ola_titel: "" # z.B. "OLA Active Directory Services"
|
||||
version: "" # z.B. "1.0"
|
||||
status: "" # Entwurf | Aktiv | In Review | Außer Kraft
|
||||
erstellungsdatum: "" # YYYY-MM-DD
|
||||
letzte_aktualisierung: "" # YYYY-MM-DD
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
|
||||
service_referenz:
|
||||
service_name: "" # Name des Internen Services
|
||||
service_id: "" # ID gemäß Service-Definition
|
||||
service_kategorie: "I" # Immer "I" für Interne Services
|
||||
service_owner: "" # Name / Rolle
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 2. VERTRAGSPARTEIEN (INTERN)
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
vertragsparteien:
|
||||
|
||||
liefernde_einheit:
|
||||
name: "" # z.B. "Team Infrastruktur"
|
||||
verantwortlich: "" # Name / Rolle des Ansprechpartners
|
||||
kontakt: "" # E-Mail / Telefon
|
||||
|
||||
nutzende_einheiten:
|
||||
- name: "" # z.B. "Team Applikationsbetrieb"
|
||||
verantwortlich: ""
|
||||
kontakt: ""
|
||||
abhängige_kundenservices: # Welche Kategorie A/B/C-Services hängen davon ab?
|
||||
- ""
|
||||
|
||||
hinweis: |
|
||||
Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden.
|
||||
Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices
|
||||
(Kategorie A/B/C) vom Internen Service abhängen.
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 3. LEISTUNGSBESCHREIBUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
leistungsbeschreibung:
|
||||
|
||||
kurzbeschreibung: "" # 2-3 Sätze: Was leistet der Service?
|
||||
|
||||
leistungsumfang:
|
||||
enthalten:
|
||||
- "" # Auflistung der enthaltenen Leistungen
|
||||
nicht_enthalten:
|
||||
- "" # Explizite Ausschlüsse
|
||||
|
||||
betriebszeiten:
|
||||
regulaer: "" # z.B. "Mo-Fr 07:00-18:00"
|
||||
erweitert: "" # z.B. "24/7 für kritische Systeme"
|
||||
wartungsfenster: "" # z.B. "Sonntag 02:00-06:00"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 4. QUALITÄTSZIELE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
qualitaetsziele:
|
||||
|
||||
verfuegbarkeit:
|
||||
zielwert: "" # z.B. "99,5 %"
|
||||
messperiode: "" # z.B. "Kalendermonat"
|
||||
messmethode: "" # z.B. "Monitoring-Tool X, Uptime-Berechnung"
|
||||
ausnahmen: "" # z.B. "Geplante Wartung ausgenommen"
|
||||
|
||||
performance:
|
||||
- metrik: "" # z.B. "Antwortzeit Authentifizierung"
|
||||
zielwert: "" # z.B. "< 200 ms (95. Perzentil)"
|
||||
messmethode: ""
|
||||
|
||||
kapazitaet:
|
||||
aktuell: "" # z.B. "500 gleichzeitige Nutzer"
|
||||
geplant: "" # z.B. "800 gleichzeitige Nutzer bis Q4/2026"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 5. ESKALATIONSWEGE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
eskalationswege:
|
||||
|
||||
stufe_1:
|
||||
beschreibung: "Operativer Kontakt"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: "" # z.B. "30 Minuten während Betriebszeiten"
|
||||
|
||||
stufe_2:
|
||||
beschreibung: "Teamleitung / Service Owner"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: ""
|
||||
|
||||
stufe_3:
|
||||
beschreibung: "Eskalation an SOR / Mission Board"
|
||||
ausloeser: |
|
||||
- Wiederholte Verfehlung der Qualitätsziele
|
||||
- Cross-Service-Impact auf Kundenservices
|
||||
referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 6. REVIEW-MECHANISMUS
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
review:
|
||||
|
||||
review_zyklus: "" # z.B. "Halbjährlich"
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
review_teilnehmer:
|
||||
- "" # Rollen / Namen
|
||||
|
||||
aenderungsverfahren: |
|
||||
Änderungen am OLA werden vom Service Owner des Internen Services
|
||||
initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen
|
||||
mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich
|
||||
(vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 7. LAUFZEIT UND KÜNDIGUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
laufzeit:
|
||||
beginn: "" # YYYY-MM-DD
|
||||
laufzeit: "" # z.B. "Unbefristet, jährlicher Review"
|
||||
kuendigungsfrist: "" # z.B. "3 Monate zum Quartalsende"
|
||||
kuendigungsbedingungen: |
|
||||
Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den
|
||||
Internen Service durch den SOR voraus (vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung des OLA-Templates"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-002, OQ-001"
|
||||
|
|
|
|||
|
|
@ -1,186 +1,186 @@
|
|||
# =============================================================================
|
||||
# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN
|
||||
# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Final
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-005
|
||||
#
|
||||
# Zweck:
|
||||
# Dieser Leitfaden unterstützt die systematische Einordnung von
|
||||
# Infrastruktur-Komponenten als Interne Services (Kategorie I) oder
|
||||
# als passive Service-Komponenten. Er ist eine Orientierungshilfe,
|
||||
# kein Automatismus – die finale Entscheidung trifft das SPM/SOR.
|
||||
#
|
||||
# Kontext:
|
||||
# Mit der Einführung der Kategorie I (Interne Services) entsteht die
|
||||
# Frage, welche Infrastruktur-Komponenten als eigenständige Governance-
|
||||
# Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare
|
||||
# Kriterien für diese Abgrenzung.
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# DIE SIEBEN FRAGEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
fragen:
|
||||
|
||||
- nr: 1
|
||||
frage: "Gibt es einen identifizierbaren internen 'Kunden'?"
|
||||
erlaeuterung: |
|
||||
Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente
|
||||
als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs-
|
||||
beziehung (Lieferant → Nutzer)?
|
||||
beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt"
|
||||
beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit"
|
||||
|
||||
- nr: 2
|
||||
frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?"
|
||||
erlaeuterung: |
|
||||
Kann eine Person oder Rolle die Gesamtverantwortung für Qualität,
|
||||
Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist
|
||||
diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle
|
||||
abgrenzbar?
|
||||
beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen"
|
||||
beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung"
|
||||
|
||||
- nr: 3
|
||||
frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?"
|
||||
erlaeuterung: |
|
||||
Können Verfügbarkeit, Performance oder andere Qualitätsmetriken
|
||||
für diese Komponente eigenständig definiert und gemessen werden –
|
||||
unabhängig von den darüberliegenden Kundenservices?
|
||||
beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms"
|
||||
beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele"
|
||||
|
||||
- nr: 4
|
||||
frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?"
|
||||
erlaeuterung: |
|
||||
Wird die Komponente als Shared Service von mehr als einem
|
||||
Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen
|
||||
Mehrfachnutzungs-Charakter?
|
||||
beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt"
|
||||
beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service"
|
||||
|
||||
- nr: 5
|
||||
frage: "Gibt es operative Steuerungsnotwendigkeit?"
|
||||
erlaeuterung: |
|
||||
Erfordert die Komponente regelmäßige operative Entscheidungen
|
||||
(Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über
|
||||
den normalen Betrieb hinausgehen?
|
||||
beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform"
|
||||
beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung"
|
||||
|
||||
- nr: 6
|
||||
frage: "Ist die Komponente für Incident Management eigenständig relevant?"
|
||||
erlaeuterung: |
|
||||
Kann es Incidents geben, die primär dieser Komponente zugeordnet
|
||||
werden und nicht sofort einem darüberliegenden Kundenservice?
|
||||
Gibt es einen eigenen Incident-Kontext?
|
||||
beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident"
|
||||
beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet"
|
||||
|
||||
- nr: 7
|
||||
frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?"
|
||||
erlaeuterung: |
|
||||
Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit
|
||||
ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR)
|
||||
vorzulegen – analog zur Stilllegung eines Kundenservices?
|
||||
beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant"
|
||||
beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# AUSWERTUNGSSCHEMA
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
auswertung:
|
||||
|
||||
schema:
|
||||
- bereich: "5–7 × Ja"
|
||||
ergebnis: "Interner Service (Kategorie I)"
|
||||
beschreibung: |
|
||||
Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale
|
||||
eines eigenständigen Governance-Objekts und sollte als Interner
|
||||
Service mit eigener Service-Definition geführt werden.
|
||||
|
||||
- bereich: "3–4 × Ja"
|
||||
ergebnis: "Grenzfall – Entscheidung durch SPM/SOR"
|
||||
beschreibung: |
|
||||
Die Komponente zeigt einige Service-Merkmale, aber nicht alle.
|
||||
Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR
|
||||
zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde)
|
||||
und 2 (Owner-Rolle) haben dabei besonderes Gewicht.
|
||||
|
||||
- bereich: "0–2 × Ja"
|
||||
ergebnis: "Passive Service-Komponente"
|
||||
beschreibung: |
|
||||
Die Komponente ist ein Bestandteil eines übergeordneten Services
|
||||
und wird nicht als eigenständiges Governance-Objekt geführt.
|
||||
Sie erscheint ggf. als Abhängigkeit in der Service-Definition
|
||||
des nutzenden Services.
|
||||
|
||||
hinweis_grenzfaelle: |
|
||||
Der Leitfaden ist eine Orientierungshilfe, kein Automatismus.
|
||||
Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte
|
||||
zusätzlich berücksichtigt werden:
|
||||
- Strategische Bedeutung der Komponente für DIGIT
|
||||
- Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?)
|
||||
- Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?)
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# ANWENDUNGSBEISPIEL
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
anwendungsbeispiel:
|
||||
|
||||
komponente: "Active Directory Services"
|
||||
|
||||
bewertung:
|
||||
- frage_nr: 1
|
||||
antwort: "Ja"
|
||||
begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst"
|
||||
- frage_nr: 2
|
||||
antwort: "Ja"
|
||||
begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen"
|
||||
- frage_nr: 3
|
||||
antwort: "Ja"
|
||||
begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar"
|
||||
- frage_nr: 4
|
||||
antwort: "Ja"
|
||||
begruendung: "Wird von >10 Kundenservices genutzt"
|
||||
- frage_nr: 5
|
||||
antwort: "Ja"
|
||||
begruendung: "Migration zu Entra ID erfordert strategische Steuerung"
|
||||
- frage_nr: 6
|
||||
antwort: "Ja"
|
||||
begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident"
|
||||
- frage_nr: 7
|
||||
antwort: "Ja"
|
||||
begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung"
|
||||
|
||||
ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# REFERENZEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
referenzen:
|
||||
- "GOV-SPM-I-001: Einführung Kategorie I"
|
||||
- "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept"
|
||||
- "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)"
|
||||
- "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung als eigenständiges Arbeitsdokument"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-005, OQ-003"
|
||||
# =============================================================================
|
||||
# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN
|
||||
# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Final
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-005
|
||||
#
|
||||
# Zweck:
|
||||
# Dieser Leitfaden unterstützt die systematische Einordnung von
|
||||
# Infrastruktur-Komponenten als Interne Services (Kategorie I) oder
|
||||
# als passive Service-Komponenten. Er ist eine Orientierungshilfe,
|
||||
# kein Automatismus – die finale Entscheidung trifft das SPM/SOR.
|
||||
#
|
||||
# Kontext:
|
||||
# Mit der Einführung der Kategorie I (Interne Services) entsteht die
|
||||
# Frage, welche Infrastruktur-Komponenten als eigenständige Governance-
|
||||
# Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare
|
||||
# Kriterien für diese Abgrenzung.
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# DIE SIEBEN FRAGEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
fragen:
|
||||
|
||||
- nr: 1
|
||||
frage: "Gibt es einen identifizierbaren internen 'Kunden'?"
|
||||
erlaeuterung: |
|
||||
Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente
|
||||
als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs-
|
||||
beziehung (Lieferant → Nutzer)?
|
||||
beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt"
|
||||
beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit"
|
||||
|
||||
- nr: 2
|
||||
frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?"
|
||||
erlaeuterung: |
|
||||
Kann eine Person oder Rolle die Gesamtverantwortung für Qualität,
|
||||
Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist
|
||||
diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle
|
||||
abgrenzbar?
|
||||
beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen"
|
||||
beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung"
|
||||
|
||||
- nr: 3
|
||||
frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?"
|
||||
erlaeuterung: |
|
||||
Können Verfügbarkeit, Performance oder andere Qualitätsmetriken
|
||||
für diese Komponente eigenständig definiert und gemessen werden –
|
||||
unabhängig von den darüberliegenden Kundenservices?
|
||||
beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms"
|
||||
beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele"
|
||||
|
||||
- nr: 4
|
||||
frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?"
|
||||
erlaeuterung: |
|
||||
Wird die Komponente als Shared Service von mehr als einem
|
||||
Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen
|
||||
Mehrfachnutzungs-Charakter?
|
||||
beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt"
|
||||
beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service"
|
||||
|
||||
- nr: 5
|
||||
frage: "Gibt es operative Steuerungsnotwendigkeit?"
|
||||
erlaeuterung: |
|
||||
Erfordert die Komponente regelmäßige operative Entscheidungen
|
||||
(Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über
|
||||
den normalen Betrieb hinausgehen?
|
||||
beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform"
|
||||
beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung"
|
||||
|
||||
- nr: 6
|
||||
frage: "Ist die Komponente für Incident Management eigenständig relevant?"
|
||||
erlaeuterung: |
|
||||
Kann es Incidents geben, die primär dieser Komponente zugeordnet
|
||||
werden und nicht sofort einem darüberliegenden Kundenservice?
|
||||
Gibt es einen eigenen Incident-Kontext?
|
||||
beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident"
|
||||
beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet"
|
||||
|
||||
- nr: 7
|
||||
frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?"
|
||||
erlaeuterung: |
|
||||
Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit
|
||||
ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR)
|
||||
vorzulegen – analog zur Stilllegung eines Kundenservices?
|
||||
beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant"
|
||||
beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# AUSWERTUNGSSCHEMA
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
auswertung:
|
||||
|
||||
schema:
|
||||
- bereich: "5–7 × Ja"
|
||||
ergebnis: "Interner Service (Kategorie I)"
|
||||
beschreibung: |
|
||||
Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale
|
||||
eines eigenständigen Governance-Objekts und sollte als Interner
|
||||
Service mit eigener Service-Definition geführt werden.
|
||||
|
||||
- bereich: "3–4 × Ja"
|
||||
ergebnis: "Grenzfall – Entscheidung durch SPM/SOR"
|
||||
beschreibung: |
|
||||
Die Komponente zeigt einige Service-Merkmale, aber nicht alle.
|
||||
Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR
|
||||
zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde)
|
||||
und 2 (Owner-Rolle) haben dabei besonderes Gewicht.
|
||||
|
||||
- bereich: "0–2 × Ja"
|
||||
ergebnis: "Passive Service-Komponente"
|
||||
beschreibung: |
|
||||
Die Komponente ist ein Bestandteil eines übergeordneten Services
|
||||
und wird nicht als eigenständiges Governance-Objekt geführt.
|
||||
Sie erscheint ggf. als Abhängigkeit in der Service-Definition
|
||||
des nutzenden Services.
|
||||
|
||||
hinweis_grenzfaelle: |
|
||||
Der Leitfaden ist eine Orientierungshilfe, kein Automatismus.
|
||||
Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte
|
||||
zusätzlich berücksichtigt werden:
|
||||
- Strategische Bedeutung der Komponente für DIGIT
|
||||
- Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?)
|
||||
- Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?)
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# ANWENDUNGSBEISPIEL
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
anwendungsbeispiel:
|
||||
|
||||
komponente: "Active Directory Services"
|
||||
|
||||
bewertung:
|
||||
- frage_nr: 1
|
||||
antwort: "Ja"
|
||||
begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst"
|
||||
- frage_nr: 2
|
||||
antwort: "Ja"
|
||||
begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen"
|
||||
- frage_nr: 3
|
||||
antwort: "Ja"
|
||||
begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar"
|
||||
- frage_nr: 4
|
||||
antwort: "Ja"
|
||||
begruendung: "Wird von >10 Kundenservices genutzt"
|
||||
- frage_nr: 5
|
||||
antwort: "Ja"
|
||||
begruendung: "Migration zu Entra ID erfordert strategische Steuerung"
|
||||
- frage_nr: 6
|
||||
antwort: "Ja"
|
||||
begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident"
|
||||
- frage_nr: 7
|
||||
antwort: "Ja"
|
||||
begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung"
|
||||
|
||||
ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# REFERENZEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
referenzen:
|
||||
- "GOV-SPM-I-001: Einführung Kategorie I"
|
||||
- "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept"
|
||||
- "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)"
|
||||
- "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung als eigenständiges Arbeitsdokument"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-005, OQ-003"
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,215 +1,215 @@
|
|||
metadata:
|
||||
version: "3.7"
|
||||
datum: "2026-03-09"
|
||||
quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
|
||||
basis: "ITIL4 / DIGITOM Begriffsüberleitung"
|
||||
hinweis: >
|
||||
Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
|
||||
ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
|
||||
eins in das DIGIT Service-Management Framework passen (Übernehmen),
|
||||
ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
|
||||
modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
|
||||
keinen erkennbaren Mehrwert bieten (Weglassen).
|
||||
|
||||
glossar:
|
||||
- begriff: "Anforderung"
|
||||
definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
|
||||
synonyme: ["Requirement", "Vorgabe"]
|
||||
|
||||
- begriff: "Anwender*in"
|
||||
definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
|
||||
synonyme: ["Nutzer*in", "User"]
|
||||
|
||||
- begriff: "Auftraggeber*in"
|
||||
definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
|
||||
|
||||
- begriff: "Bedarf"
|
||||
definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
|
||||
|
||||
- begriff: "Change"
|
||||
definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
|
||||
synonyme: ["Änderung"]
|
||||
|
||||
- begriff: "Configuration Item (CI)"
|
||||
definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
|
||||
|
||||
- begriff: "Demand"
|
||||
definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
|
||||
|
||||
- begriff: "Demand-Steckbrief"
|
||||
definition: |
|
||||
Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
|
||||
den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
|
||||
Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
|
||||
abgrenzung:
|
||||
- "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
|
||||
- "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
|
||||
|
||||
- begriff: "Emergency-Change"
|
||||
definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
|
||||
|
||||
- begriff: "Ergebnis"
|
||||
definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
|
||||
synonyme: ["Outcome"]
|
||||
|
||||
- begriff: "Gewährleistung"
|
||||
definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
|
||||
synonyme: ["Qualitätszusage", "Warranty"]
|
||||
|
||||
- begriff: "Geschäftskritikalität"
|
||||
definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
|
||||
synonyme: ["Business Criticality", "Service-Kritikalität"]
|
||||
|
||||
- begriff: "Governance"
|
||||
definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
|
||||
|
||||
- begriff: "Incident"
|
||||
definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
|
||||
synonyme: ["Vorfall", "Störung"]
|
||||
|
||||
- begriff: "Interner Service"
|
||||
definition: |
|
||||
Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
|
||||
DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
|
||||
sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
|
||||
Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
|
||||
eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
|
||||
Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
|
||||
Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
|
||||
abgrenzung:
|
||||
- "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
|
||||
- "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
|
||||
kategorie: "I"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
|
||||
|
||||
- begriff: "Initiative"
|
||||
definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
|
||||
synonyme: ["Chance", "Möglichkeit", "Opportunity"]
|
||||
|
||||
- begriff: "Key Performance Indicator (KPI)"
|
||||
definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
|
||||
|
||||
- begriff: "Kontinuierliche Verbesserung"
|
||||
definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
|
||||
|
||||
- begriff: "Kundenservice"
|
||||
definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
|
||||
|
||||
- begriff: "Kund*in"
|
||||
definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
|
||||
synonyme: ["Service-Konsument"]
|
||||
|
||||
- begriff: "Major-Change"
|
||||
definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
|
||||
synonyme: ["Wesentliche Änderung"]
|
||||
|
||||
- begriff: "Normal-Change"
|
||||
definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
|
||||
|
||||
- begriff: "Nutzen"
|
||||
definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
|
||||
synonyme: ["Utility"]
|
||||
|
||||
- begriff: "Problem (engl.)"
|
||||
definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
|
||||
synonyme: ["Ursache"]
|
||||
|
||||
- begriff: "Produkt"
|
||||
definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
|
||||
synonyme: ["Leistungsbaustein"]
|
||||
|
||||
- begriff: "Recovery Time Objective (RTO)"
|
||||
definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
|
||||
synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
|
||||
|
||||
- begriff: "Request-Katalog"
|
||||
definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
|
||||
|
||||
- begriff: "Request for Change (RFC)"
|
||||
definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
|
||||
synonyme: ["Change Request"]
|
||||
|
||||
- begriff: "Ressource"
|
||||
definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
|
||||
|
||||
- begriff: "Service"
|
||||
definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
|
||||
synonyme: ["Dienstleistung"]
|
||||
|
||||
- begriff: "Service Level"
|
||||
definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
|
||||
synonyme: ["Service-Qualitätsniveau"]
|
||||
|
||||
- begriff: "Operational Level Agreement (OLA)"
|
||||
definition: |
|
||||
Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
|
||||
(Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
|
||||
Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
|
||||
abgrenzung:
|
||||
- "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
|
||||
- "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
- begriff: "Service-Sichtbarkeit"
|
||||
definition: |
|
||||
Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
|
||||
Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
|
||||
Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
|
||||
Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
|
||||
Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
|
||||
governance_referenz: "GOV-SPM-I-003"
|
||||
|
||||
- begriff: "Service Level Agreement (SLA)"
|
||||
definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
|
||||
synonyme: ["Servicevereinbarung"]
|
||||
|
||||
- begriff: "Service Request"
|
||||
definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
|
||||
synonyme: ["Serviceanfrage"]
|
||||
|
||||
- begriff: "Service-Anbieter"
|
||||
definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
|
||||
synonyme: ["Dienstleister", "Service Provider"]
|
||||
|
||||
- begriff: "Service-Angebot"
|
||||
definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
|
||||
synonyme: ["Leistungsangebot"]
|
||||
|
||||
- begriff: "Service-Bereitstellung"
|
||||
definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
|
||||
synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
|
||||
|
||||
- begriff: "Service-Beziehung"
|
||||
definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
|
||||
|
||||
- begriff: "Service-Katalog"
|
||||
definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
|
||||
|
||||
- begriff: "Service-Portfolio"
|
||||
definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
|
||||
synonyme: ["IT-Service-Portfolio"]
|
||||
|
||||
- begriff: "Sponsor*in"
|
||||
definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
|
||||
|
||||
- begriff: "Stakeholder"
|
||||
definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
|
||||
synonyme: ["Anspruchsgruppen"]
|
||||
|
||||
- begriff: "Standard Operating Procedures (SOPs)"
|
||||
definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
|
||||
synonyme: ["Standardvorgehensweise"]
|
||||
|
||||
- begriff: "Standard-Change"
|
||||
definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
|
||||
|
||||
- begriff: "Vital Business Function (VBF)"
|
||||
definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
|
||||
synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
|
||||
|
||||
- begriff: "Wert"
|
||||
definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
|
||||
|
||||
- begriff: "Wissensmanagement"
|
||||
definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."
|
||||
metadata:
|
||||
version: "3.7"
|
||||
datum: "2026-03-09"
|
||||
quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
|
||||
basis: "ITIL4 / DIGITOM Begriffsüberleitung"
|
||||
hinweis: >
|
||||
Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
|
||||
ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
|
||||
eins in das DIGIT Service-Management Framework passen (Übernehmen),
|
||||
ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
|
||||
modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
|
||||
keinen erkennbaren Mehrwert bieten (Weglassen).
|
||||
|
||||
glossar:
|
||||
- begriff: "Anforderung"
|
||||
definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
|
||||
synonyme: ["Requirement", "Vorgabe"]
|
||||
|
||||
- begriff: "Anwender*in"
|
||||
definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
|
||||
synonyme: ["Nutzer*in", "User"]
|
||||
|
||||
- begriff: "Auftraggeber*in"
|
||||
definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
|
||||
|
||||
- begriff: "Bedarf"
|
||||
definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
|
||||
|
||||
- begriff: "Change"
|
||||
definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
|
||||
synonyme: ["Änderung"]
|
||||
|
||||
- begriff: "Configuration Item (CI)"
|
||||
definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
|
||||
|
||||
- begriff: "Demand"
|
||||
definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
|
||||
|
||||
- begriff: "Demand-Steckbrief"
|
||||
definition: |
|
||||
Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
|
||||
den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
|
||||
Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
|
||||
abgrenzung:
|
||||
- "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
|
||||
- "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
|
||||
|
||||
- begriff: "Emergency-Change"
|
||||
definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
|
||||
|
||||
- begriff: "Ergebnis"
|
||||
definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
|
||||
synonyme: ["Outcome"]
|
||||
|
||||
- begriff: "Gewährleistung"
|
||||
definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
|
||||
synonyme: ["Qualitätszusage", "Warranty"]
|
||||
|
||||
- begriff: "Geschäftskritikalität"
|
||||
definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
|
||||
synonyme: ["Business Criticality", "Service-Kritikalität"]
|
||||
|
||||
- begriff: "Governance"
|
||||
definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
|
||||
|
||||
- begriff: "Incident"
|
||||
definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
|
||||
synonyme: ["Vorfall", "Störung"]
|
||||
|
||||
- begriff: "Interner Service"
|
||||
definition: |
|
||||
Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
|
||||
DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
|
||||
sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
|
||||
Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
|
||||
eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
|
||||
Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
|
||||
Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
|
||||
abgrenzung:
|
||||
- "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
|
||||
- "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
|
||||
kategorie: "I"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
|
||||
|
||||
- begriff: "Initiative"
|
||||
definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
|
||||
synonyme: ["Chance", "Möglichkeit", "Opportunity"]
|
||||
|
||||
- begriff: "Key Performance Indicator (KPI)"
|
||||
definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
|
||||
|
||||
- begriff: "Kontinuierliche Verbesserung"
|
||||
definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
|
||||
|
||||
- begriff: "Kundenservice"
|
||||
definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
|
||||
|
||||
- begriff: "Kund*in"
|
||||
definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
|
||||
synonyme: ["Service-Konsument"]
|
||||
|
||||
- begriff: "Major-Change"
|
||||
definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
|
||||
synonyme: ["Wesentliche Änderung"]
|
||||
|
||||
- begriff: "Normal-Change"
|
||||
definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
|
||||
|
||||
- begriff: "Nutzen"
|
||||
definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
|
||||
synonyme: ["Utility"]
|
||||
|
||||
- begriff: "Problem (engl.)"
|
||||
definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
|
||||
synonyme: ["Ursache"]
|
||||
|
||||
- begriff: "Produkt"
|
||||
definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
|
||||
synonyme: ["Leistungsbaustein"]
|
||||
|
||||
- begriff: "Recovery Time Objective (RTO)"
|
||||
definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
|
||||
synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
|
||||
|
||||
- begriff: "Request-Katalog"
|
||||
definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
|
||||
|
||||
- begriff: "Request for Change (RFC)"
|
||||
definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
|
||||
synonyme: ["Change Request"]
|
||||
|
||||
- begriff: "Ressource"
|
||||
definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
|
||||
|
||||
- begriff: "Service"
|
||||
definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
|
||||
synonyme: ["Dienstleistung"]
|
||||
|
||||
- begriff: "Service Level"
|
||||
definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
|
||||
synonyme: ["Service-Qualitätsniveau"]
|
||||
|
||||
- begriff: "Operational Level Agreement (OLA)"
|
||||
definition: |
|
||||
Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
|
||||
(Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
|
||||
Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
|
||||
abgrenzung:
|
||||
- "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
|
||||
- "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
- begriff: "Service-Sichtbarkeit"
|
||||
definition: |
|
||||
Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
|
||||
Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
|
||||
Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
|
||||
Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
|
||||
Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
|
||||
governance_referenz: "GOV-SPM-I-003"
|
||||
|
||||
- begriff: "Service Level Agreement (SLA)"
|
||||
definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
|
||||
synonyme: ["Servicevereinbarung"]
|
||||
|
||||
- begriff: "Service Request"
|
||||
definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
|
||||
synonyme: ["Serviceanfrage"]
|
||||
|
||||
- begriff: "Service-Anbieter"
|
||||
definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
|
||||
synonyme: ["Dienstleister", "Service Provider"]
|
||||
|
||||
- begriff: "Service-Angebot"
|
||||
definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
|
||||
synonyme: ["Leistungsangebot"]
|
||||
|
||||
- begriff: "Service-Bereitstellung"
|
||||
definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
|
||||
synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
|
||||
|
||||
- begriff: "Service-Beziehung"
|
||||
definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
|
||||
|
||||
- begriff: "Service-Katalog"
|
||||
definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
|
||||
|
||||
- begriff: "Service-Portfolio"
|
||||
definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
|
||||
synonyme: ["IT-Service-Portfolio"]
|
||||
|
||||
- begriff: "Sponsor*in"
|
||||
definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
|
||||
|
||||
- begriff: "Stakeholder"
|
||||
definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
|
||||
synonyme: ["Anspruchsgruppen"]
|
||||
|
||||
- begriff: "Standard Operating Procedures (SOPs)"
|
||||
definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
|
||||
synonyme: ["Standardvorgehensweise"]
|
||||
|
||||
- begriff: "Standard-Change"
|
||||
definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
|
||||
|
||||
- begriff: "Vital Business Function (VBF)"
|
||||
definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
|
||||
synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
|
||||
|
||||
- begriff: "Wert"
|
||||
definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
|
||||
|
||||
- begriff: "Wissensmanagement"
|
||||
definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."
|
||||
|
|
|
|||
|
|
@ -1,20 +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]
|
||||
# ========================================
|
||||
# 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]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,20 +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]
|
||||
# ========================================
|
||||
# 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]
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,66 +0,0 @@
|
|||
# =============================================================================
|
||||
# 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"
|
||||
|
|
@ -1,20 +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]
|
||||
# ========================================
|
||||
# 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
|
|
@ -1,470 +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"
|
||||
# =============================================================================
|
||||
# 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"
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# ========================================
|
||||
# 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
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,263 +1,263 @@
|
|||
# =============================================================================
|
||||
# KONZEPTRAHMEN: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "konzeptrahmen"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. DIE HERAUSFORDERUNG
|
||||
# =============================================================================
|
||||
|
||||
herausforderung:
|
||||
titel: "Zwischen Standardisierung und Befähigung"
|
||||
|
||||
beschreibung: |
|
||||
Moderne Verwaltungsorganisationen stehen vor einem fundamentalen Dilemma:
|
||||
Sie müssen gleichzeitig Stabilität gewährleisten und Agilität ermöglichen.
|
||||
Im Kontext des DIGITOM manifestiert sich diese Spannung besonders deutlich
|
||||
in der Frage, wie Prozesse gestaltet und gesteuert werden sollen.
|
||||
|
||||
problemstellung: |
|
||||
Die traditionelle Antwort - zentrale Vorgaben und strikte Kontrolle -
|
||||
greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig
|
||||
führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz.
|
||||
|
||||
ansatz: |
|
||||
Die Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem
|
||||
Spannungsfeld.
|
||||
|
||||
# =============================================================================
|
||||
# 2. DIE LÖSUNG
|
||||
# =============================================================================
|
||||
|
||||
loesung:
|
||||
titel: "Eine mehrdimensionale Organisationsarchitektur"
|
||||
|
||||
beschreibung: |
|
||||
Statt einer monolithischen Struktur wurde für das Prozess-Management
|
||||
eine vielschichtige Architektur entwickelt. Diese erlaubt es, verschiedene
|
||||
organisationale Bedürfnisse gleichzeitig zu adressieren.
|
||||
|
||||
spannungsfelder:
|
||||
- dimension_1: "Strategische Steuerung"
|
||||
dimension_2: "Operative Flexibilität"
|
||||
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Autonomie"
|
||||
|
||||
- dimension_1: "Zentrale Kompetenz"
|
||||
dimension_2: "Dezentrale Befähigung"
|
||||
|
||||
prinzip: |
|
||||
Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv
|
||||
genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige
|
||||
Verbesserung.
|
||||
|
||||
# =============================================================================
|
||||
# 3. DOKUMENTATIONSARCHITEKTUR
|
||||
# =============================================================================
|
||||
|
||||
dokumentationsarchitektur:
|
||||
titel: "Fünf Perspektiven, ein System"
|
||||
|
||||
beschreibung: |
|
||||
Die Komplexität dieser Organisationsform spiegelt sich in der bewusst
|
||||
gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das
|
||||
Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen eigenen Zweck.
|
||||
|
||||
dokumente:
|
||||
- id: "DOK-1"
|
||||
name: "Funktionsbeschreibung"
|
||||
untertitel: "Legitimation und Mandat"
|
||||
kernfrage: "Was darf und soll die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Schafft die formale Grundlage. Definiert den Verantwortungsbereich,
|
||||
grenzt Zuständigkeiten ab und legitimiert das Handeln der PM-Funktion
|
||||
innerhalb der Gesamtorganisation.
|
||||
metapher: "Die 'Verfassung' der Funktion - ihre grundlegenden Rechte und Pflichten"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
|
||||
- id: "DOK-2"
|
||||
name: "Leistungs-Canvas"
|
||||
untertitel: "Der Nutzennachweis"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Zeigt, was tatsächlich geleistet wird. Nimmt konsequent die Perspektive
|
||||
der Nutzer:innen ein und macht sichtbar, wie aus Aktivitäten konkreter
|
||||
Nutzen entsteht.
|
||||
format: "Canvas-Format ermöglicht ganzheitliche Betrachtung aller relevanten Elemente"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
|
||||
- id: "DOK-3"
|
||||
name: "Rollenmodell"
|
||||
untertitel: "Die Arbeitsorganisation"
|
||||
kernfrage: "Wer trägt welche Verantwortung?"
|
||||
beschreibung: |
|
||||
Elf differenzierte Rollen ermöglichen es, verschiedene Aspekte der
|
||||
PM-Arbeit klar zu verteilen. Von der strategischen Führung über
|
||||
methodische Expertise bis zur operativen Beratung.
|
||||
mehrwert: "Verhindert Interessenskonflikte und schafft Klarheit in der Zusammenarbeit"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
|
||||
- id: "DOK-4"
|
||||
name: "Governance-Modell"
|
||||
untertitel: "Die Spielregeln"
|
||||
kernfrage: "Wie werden Entscheidungen getroffen?"
|
||||
beschreibung: |
|
||||
Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Definiert
|
||||
differenzierte Entscheidungswege für verschiedene Leistungstypen.
|
||||
design: "Eskalationspfade sind klar definiert, aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
|
||||
- id: "DOK-5"
|
||||
name: "RACI-Matrix"
|
||||
untertitel: "Das Navigationsinstrument"
|
||||
kernfrage: "Wer ist wofür konkret zuständig?"
|
||||
beschreibung: |
|
||||
Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf
|
||||
einen Blick sichtbar. Dient als praktisches Nachschlagewerk im
|
||||
Arbeitsalltag.
|
||||
mehrwert: "Verhindert Zuständigkeitskonflikte durch klare Rollenzuweisungen"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# 4. SYSTEMISCHE ZUSAMMENHÄNGE
|
||||
# =============================================================================
|
||||
|
||||
systemische_zusammenhaenge:
|
||||
beschreibung: |
|
||||
Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden
|
||||
ein integriertes System. Jedes Element verstärkt und ergänzt die anderen.
|
||||
Gemeinsam schaffen sie ein robustes, aber flexibles Organisationsdesign.
|
||||
|
||||
verknuepfungen:
|
||||
- von: "Funktionsbeschreibung"
|
||||
zu: "Leistungs-Canvas"
|
||||
beziehung: "legitimiert die beschriebenen Leistungen"
|
||||
|
||||
- von: "Rollenmodell"
|
||||
zu: "Leistungserbringung"
|
||||
beziehung: "operationalisiert durch klare Verantwortlichkeiten"
|
||||
|
||||
- von: "Governance-Modell"
|
||||
zu: "Rollen"
|
||||
beziehung: "regelt, wie diese zusammenarbeiten und Entscheidungen treffen"
|
||||
|
||||
- von: "RACI-Matrix"
|
||||
zu: "Zusammenarbeit"
|
||||
beziehung: "macht transparent und nachvollziehbar"
|
||||
|
||||
# =============================================================================
|
||||
# 5. NAVIGATIONSHINWEISE
|
||||
# =============================================================================
|
||||
|
||||
navigationshinweise:
|
||||
beschreibung: |
|
||||
Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche
|
||||
Einstiegspunkte in die Dokumentation.
|
||||
|
||||
zielgruppen:
|
||||
- zielgruppe: "Führungskräfte und Entscheidungsträger:innen"
|
||||
einstieg: "Governance-Modell"
|
||||
zweck: "Entscheidungswege und Steuerungsmechanismen verstehen"
|
||||
dann: "Leistungs-Canvas für den strategischen Nutzen"
|
||||
|
||||
- zielgruppe: "Operative Teams und Fachbereiche"
|
||||
einstieg: "Leistungs-Canvas"
|
||||
zweck: "Verfügbare Services und Zugangswege erkunden"
|
||||
dann: "RACI-Matrix zeigt konkrete Ansprechpersonen"
|
||||
|
||||
- zielgruppe: "Neue Mitarbeitende der PM-Funktion"
|
||||
einstieg: "Funktionsbeschreibung"
|
||||
zweck: "Grundlegendes Verständnis aufbauen"
|
||||
dann: "Rollenmodell für die eigene Verortung im Team"
|
||||
|
||||
- zielgruppe: "Projektleitungen"
|
||||
einstieg: "Governance-Modell (Abschnitt projektzentrierte Prozessgestaltung)"
|
||||
zweck: "PM-Integration in Projekten verstehen"
|
||||
dann: "RACI-Matrix für konkrete Abstimmungswege"
|
||||
|
||||
# =============================================================================
|
||||
# 6. DIE ZENTRALE BALANCE
|
||||
# =============================================================================
|
||||
|
||||
zentrale_balance:
|
||||
titel: "Standardisierung ermöglichen, Autonomie bewahren"
|
||||
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung.
|
||||
Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen
|
||||
fachliche Vielfalt möglich bleibt.
|
||||
|
||||
dimensionen:
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Freiheit"
|
||||
|
||||
- dimension_1: "Zentrale Governance"
|
||||
dimension_2: "Dezentrale Ausführung"
|
||||
|
||||
- dimension_1: "Verbindliche Frameworks"
|
||||
dimension_2: "Situative Anpassung"
|
||||
|
||||
leitsatz: |
|
||||
Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen,
|
||||
ohne die notwendige Flexibilität zu ersticken.
|
||||
|
||||
# =============================================================================
|
||||
# 7. AUSBLICK
|
||||
# =============================================================================
|
||||
|
||||
ausblick:
|
||||
titel: "Ein lernendes System"
|
||||
|
||||
beschreibung: |
|
||||
Die hier dokumentierte Organisationsform ist kein statisches Konstrukt.
|
||||
Sie ist darauf angelegt, sich weiterzuentwickeln - durch Feedback aus
|
||||
der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse.
|
||||
|
||||
anpassungsfaehigkeit: |
|
||||
Die mehrdimensionale Dokumentation ermöglicht gezielte Anpassungen:
|
||||
Einzelne Elemente können weiterentwickelt werden, ohne das Gesamtsystem
|
||||
zu destabilisieren.
|
||||
|
||||
vision: |
|
||||
So entsteht eine Organisation, die gleichzeitig stabil und adaptiv ist -
|
||||
genau das, was moderne Verwaltung braucht.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx
|
||||
|
||||
Inhalte:
|
||||
- Herausforderung: Standardisierung vs. Befähigung
|
||||
- Lösung: Mehrdimensionale Organisationsarchitektur
|
||||
- Dokumentationsarchitektur (5 Dokumente)
|
||||
- Systemische Zusammenhänge
|
||||
- Navigationshinweise nach Zielgruppen
|
||||
- Zentrale Balance
|
||||
- Ausblick: Lernendes System
|
||||
autor: "DIGITOM-Projekt"
|
||||
# =============================================================================
|
||||
# KONZEPTRAHMEN: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "konzeptrahmen"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. DIE HERAUSFORDERUNG
|
||||
# =============================================================================
|
||||
|
||||
herausforderung:
|
||||
titel: "Zwischen Standardisierung und Befähigung"
|
||||
|
||||
beschreibung: |
|
||||
Moderne Verwaltungsorganisationen stehen vor einem fundamentalen Dilemma:
|
||||
Sie müssen gleichzeitig Stabilität gewährleisten und Agilität ermöglichen.
|
||||
Im Kontext des DIGITOM manifestiert sich diese Spannung besonders deutlich
|
||||
in der Frage, wie Prozesse gestaltet und gesteuert werden sollen.
|
||||
|
||||
problemstellung: |
|
||||
Die traditionelle Antwort - zentrale Vorgaben und strikte Kontrolle -
|
||||
greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig
|
||||
führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz.
|
||||
|
||||
ansatz: |
|
||||
Die Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem
|
||||
Spannungsfeld.
|
||||
|
||||
# =============================================================================
|
||||
# 2. DIE LÖSUNG
|
||||
# =============================================================================
|
||||
|
||||
loesung:
|
||||
titel: "Eine mehrdimensionale Organisationsarchitektur"
|
||||
|
||||
beschreibung: |
|
||||
Statt einer monolithischen Struktur wurde für das Prozess-Management
|
||||
eine vielschichtige Architektur entwickelt. Diese erlaubt es, verschiedene
|
||||
organisationale Bedürfnisse gleichzeitig zu adressieren.
|
||||
|
||||
spannungsfelder:
|
||||
- dimension_1: "Strategische Steuerung"
|
||||
dimension_2: "Operative Flexibilität"
|
||||
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Autonomie"
|
||||
|
||||
- dimension_1: "Zentrale Kompetenz"
|
||||
dimension_2: "Dezentrale Befähigung"
|
||||
|
||||
prinzip: |
|
||||
Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv
|
||||
genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige
|
||||
Verbesserung.
|
||||
|
||||
# =============================================================================
|
||||
# 3. DOKUMENTATIONSARCHITEKTUR
|
||||
# =============================================================================
|
||||
|
||||
dokumentationsarchitektur:
|
||||
titel: "Fünf Perspektiven, ein System"
|
||||
|
||||
beschreibung: |
|
||||
Die Komplexität dieser Organisationsform spiegelt sich in der bewusst
|
||||
gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das
|
||||
Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen eigenen Zweck.
|
||||
|
||||
dokumente:
|
||||
- id: "DOK-1"
|
||||
name: "Funktionsbeschreibung"
|
||||
untertitel: "Legitimation und Mandat"
|
||||
kernfrage: "Was darf und soll die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Schafft die formale Grundlage. Definiert den Verantwortungsbereich,
|
||||
grenzt Zuständigkeiten ab und legitimiert das Handeln der PM-Funktion
|
||||
innerhalb der Gesamtorganisation.
|
||||
metapher: "Die 'Verfassung' der Funktion - ihre grundlegenden Rechte und Pflichten"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
|
||||
- id: "DOK-2"
|
||||
name: "Leistungs-Canvas"
|
||||
untertitel: "Der Nutzennachweis"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Zeigt, was tatsächlich geleistet wird. Nimmt konsequent die Perspektive
|
||||
der Nutzer:innen ein und macht sichtbar, wie aus Aktivitäten konkreter
|
||||
Nutzen entsteht.
|
||||
format: "Canvas-Format ermöglicht ganzheitliche Betrachtung aller relevanten Elemente"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
|
||||
- id: "DOK-3"
|
||||
name: "Rollenmodell"
|
||||
untertitel: "Die Arbeitsorganisation"
|
||||
kernfrage: "Wer trägt welche Verantwortung?"
|
||||
beschreibung: |
|
||||
Elf differenzierte Rollen ermöglichen es, verschiedene Aspekte der
|
||||
PM-Arbeit klar zu verteilen. Von der strategischen Führung über
|
||||
methodische Expertise bis zur operativen Beratung.
|
||||
mehrwert: "Verhindert Interessenskonflikte und schafft Klarheit in der Zusammenarbeit"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
|
||||
- id: "DOK-4"
|
||||
name: "Governance-Modell"
|
||||
untertitel: "Die Spielregeln"
|
||||
kernfrage: "Wie werden Entscheidungen getroffen?"
|
||||
beschreibung: |
|
||||
Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Definiert
|
||||
differenzierte Entscheidungswege für verschiedene Leistungstypen.
|
||||
design: "Eskalationspfade sind klar definiert, aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
|
||||
- id: "DOK-5"
|
||||
name: "RACI-Matrix"
|
||||
untertitel: "Das Navigationsinstrument"
|
||||
kernfrage: "Wer ist wofür konkret zuständig?"
|
||||
beschreibung: |
|
||||
Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf
|
||||
einen Blick sichtbar. Dient als praktisches Nachschlagewerk im
|
||||
Arbeitsalltag.
|
||||
mehrwert: "Verhindert Zuständigkeitskonflikte durch klare Rollenzuweisungen"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# 4. SYSTEMISCHE ZUSAMMENHÄNGE
|
||||
# =============================================================================
|
||||
|
||||
systemische_zusammenhaenge:
|
||||
beschreibung: |
|
||||
Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden
|
||||
ein integriertes System. Jedes Element verstärkt und ergänzt die anderen.
|
||||
Gemeinsam schaffen sie ein robustes, aber flexibles Organisationsdesign.
|
||||
|
||||
verknuepfungen:
|
||||
- von: "Funktionsbeschreibung"
|
||||
zu: "Leistungs-Canvas"
|
||||
beziehung: "legitimiert die beschriebenen Leistungen"
|
||||
|
||||
- von: "Rollenmodell"
|
||||
zu: "Leistungserbringung"
|
||||
beziehung: "operationalisiert durch klare Verantwortlichkeiten"
|
||||
|
||||
- von: "Governance-Modell"
|
||||
zu: "Rollen"
|
||||
beziehung: "regelt, wie diese zusammenarbeiten und Entscheidungen treffen"
|
||||
|
||||
- von: "RACI-Matrix"
|
||||
zu: "Zusammenarbeit"
|
||||
beziehung: "macht transparent und nachvollziehbar"
|
||||
|
||||
# =============================================================================
|
||||
# 5. NAVIGATIONSHINWEISE
|
||||
# =============================================================================
|
||||
|
||||
navigationshinweise:
|
||||
beschreibung: |
|
||||
Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche
|
||||
Einstiegspunkte in die Dokumentation.
|
||||
|
||||
zielgruppen:
|
||||
- zielgruppe: "Führungskräfte und Entscheidungsträger:innen"
|
||||
einstieg: "Governance-Modell"
|
||||
zweck: "Entscheidungswege und Steuerungsmechanismen verstehen"
|
||||
dann: "Leistungs-Canvas für den strategischen Nutzen"
|
||||
|
||||
- zielgruppe: "Operative Teams und Fachbereiche"
|
||||
einstieg: "Leistungs-Canvas"
|
||||
zweck: "Verfügbare Services und Zugangswege erkunden"
|
||||
dann: "RACI-Matrix zeigt konkrete Ansprechpersonen"
|
||||
|
||||
- zielgruppe: "Neue Mitarbeitende der PM-Funktion"
|
||||
einstieg: "Funktionsbeschreibung"
|
||||
zweck: "Grundlegendes Verständnis aufbauen"
|
||||
dann: "Rollenmodell für die eigene Verortung im Team"
|
||||
|
||||
- zielgruppe: "Projektleitungen"
|
||||
einstieg: "Governance-Modell (Abschnitt projektzentrierte Prozessgestaltung)"
|
||||
zweck: "PM-Integration in Projekten verstehen"
|
||||
dann: "RACI-Matrix für konkrete Abstimmungswege"
|
||||
|
||||
# =============================================================================
|
||||
# 6. DIE ZENTRALE BALANCE
|
||||
# =============================================================================
|
||||
|
||||
zentrale_balance:
|
||||
titel: "Standardisierung ermöglichen, Autonomie bewahren"
|
||||
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung.
|
||||
Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen
|
||||
fachliche Vielfalt möglich bleibt.
|
||||
|
||||
dimensionen:
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Freiheit"
|
||||
|
||||
- dimension_1: "Zentrale Governance"
|
||||
dimension_2: "Dezentrale Ausführung"
|
||||
|
||||
- dimension_1: "Verbindliche Frameworks"
|
||||
dimension_2: "Situative Anpassung"
|
||||
|
||||
leitsatz: |
|
||||
Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen,
|
||||
ohne die notwendige Flexibilität zu ersticken.
|
||||
|
||||
# =============================================================================
|
||||
# 7. AUSBLICK
|
||||
# =============================================================================
|
||||
|
||||
ausblick:
|
||||
titel: "Ein lernendes System"
|
||||
|
||||
beschreibung: |
|
||||
Die hier dokumentierte Organisationsform ist kein statisches Konstrukt.
|
||||
Sie ist darauf angelegt, sich weiterzuentwickeln - durch Feedback aus
|
||||
der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse.
|
||||
|
||||
anpassungsfaehigkeit: |
|
||||
Die mehrdimensionale Dokumentation ermöglicht gezielte Anpassungen:
|
||||
Einzelne Elemente können weiterentwickelt werden, ohne das Gesamtsystem
|
||||
zu destabilisieren.
|
||||
|
||||
vision: |
|
||||
So entsteht eine Organisation, die gleichzeitig stabil und adaptiv ist -
|
||||
genau das, was moderne Verwaltung braucht.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx
|
||||
|
||||
Inhalte:
|
||||
- Herausforderung: Standardisierung vs. Befähigung
|
||||
- Lösung: Mehrdimensionale Organisationsarchitektur
|
||||
- Dokumentationsarchitektur (5 Dokumente)
|
||||
- Systemische Zusammenhänge
|
||||
- Navigationshinweise nach Zielgruppen
|
||||
- Zentrale Balance
|
||||
- Ausblick: Lernendes System
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
|
|||
|
|
@ -1,481 +1,481 @@
|
|||
# =============================================================================
|
||||
# LEISTUNGS-CANVAS: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "leistungs-canvas"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#03.1 - Prozess-Management: Leistungs-Canvas.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. EINFÜHRUNG
|
||||
# =============================================================================
|
||||
|
||||
einfuehrung:
|
||||
warum_ein_leistungs_canvas: |
|
||||
Das Leistungs-Canvas betrachtet die Prozess-Management-Funktion konsequent
|
||||
aus der Perspektive ihrer Nutzer:innen. Diese Perspektivverschiebung macht
|
||||
sichtbar, was in traditionellen Funktionsbeschreibungen oft untergeht:
|
||||
Wie entsteht konkret Nutzen? Welche Beziehungen ermöglichen wirksame
|
||||
Zusammenarbeit? Über welche Wege werden Leistungen tatsächlich zugänglich?
|
||||
|
||||
leitfragen:
|
||||
- "Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?"
|
||||
- "Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?"
|
||||
- "Welche Voraussetzungen müssen dafür geschaffen werden?"
|
||||
|
||||
funktionen_des_canvas:
|
||||
- "Schafft Klarheit über das Leistungsportfolio"
|
||||
- "Macht Zusammenhänge zwischen verschiedenen Elementen sichtbar"
|
||||
- "Dient als Kommunikationsinstrument zwischen PM-Funktion und Nutzer:innen"
|
||||
- "Steuerungsinstrument für Ressourcen-Investitionen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. CANVAS-LOGIK
|
||||
# =============================================================================
|
||||
|
||||
canvas_logik:
|
||||
beschreibung: |
|
||||
Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander
|
||||
verbundene Bausteine. Die rechte Seite fokussiert auf die Außenperspektive,
|
||||
die linke Seite richtet den Blick nach innen. Im Zentrum steht das
|
||||
Wertversprechen als verbindendes Element.
|
||||
|
||||
bausteine:
|
||||
rechte_seite_aussen:
|
||||
- "Nutzendensegmente"
|
||||
- "Nutzendenbeziehung"
|
||||
- "Kanäle"
|
||||
zentrum:
|
||||
- "Wertversprechen"
|
||||
linke_seite_innen:
|
||||
- "Schlüsselaktivitäten"
|
||||
- "Schlüsselressourcen"
|
||||
- "Schlüsselpartner"
|
||||
|
||||
# =============================================================================
|
||||
# 3. CLUSTER A: FÜR WEN DIE PM-FUNKTION DA IST
|
||||
# =============================================================================
|
||||
|
||||
cluster_a_fuer_wen:
|
||||
name: "Für wen die PM-Funktion da ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 Nutzendensegmente
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendensegmente:
|
||||
beschreibung: |
|
||||
Die verschiedenen internen Zielgruppen, für die die PM-Funktion Leistungen
|
||||
erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen und Arbeitsweisen.
|
||||
|
||||
segmente:
|
||||
- segment: "Management-Gremien"
|
||||
beispiele: "Vision Board, Mission Board"
|
||||
bedarfe:
|
||||
- "Transparenz über die Prozesslandschaft"
|
||||
- "Governance-Berichte"
|
||||
- "Einheitliche Standards zur besseren Steuerung"
|
||||
- "Strategische Ausrichtung der Organisation"
|
||||
|
||||
- segment: "Abteilungsleitungen"
|
||||
bedarfe:
|
||||
- "Prozessperspektive für bessere Ressourcenplanung"
|
||||
- "Steuerung ihrer Bereiche"
|
||||
- "Fundierte Entscheidungen bei bereichsübergreifenden Themen"
|
||||
|
||||
- segment: "Process Owner der Teilprozesse"
|
||||
beispiele: "SHM, DPM, PPM, SPM"
|
||||
bedarfe:
|
||||
- "End-to-End-Verantwortung für ihre jeweiligen Teilprozesse"
|
||||
- "Methodische Unterstützung zur Prozessoptimierung"
|
||||
- "Unterstützung bei Prozesssteuerung"
|
||||
|
||||
- segment: "Fachbereiche und Teams mit Key-Usern"
|
||||
bedarfe:
|
||||
- "Methodische Unterstützung"
|
||||
- "Befähigung und Standards"
|
||||
- "Eigenständige Dokumentation und Verbesserung fachspezifischer Prozesse"
|
||||
|
||||
- segment: "Projekt- und Programmorganisationen"
|
||||
bedarfe:
|
||||
- "Einheitliche Prozessvorgaben"
|
||||
- "Methodische Beratung"
|
||||
- "Sicherstellung der Framework-Compliance in Projekten"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 Nutzendenbeziehung
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendenbeziehung:
|
||||
beschreibung: |
|
||||
Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren
|
||||
Nutzer:innen. Sie definiert das "Wie" der Interaktion.
|
||||
|
||||
beziehungstypen:
|
||||
- typ: "Partnerschaftliche Zusammenarbeit & Co-Kreation"
|
||||
beschreibung: |
|
||||
Aufbau von Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen.
|
||||
Key-User als zentrale Partner:innen eng in Entwicklung und Umsetzung
|
||||
von Prozesslösungen eingebunden.
|
||||
|
||||
- typ: "Persönliche Beratung & Dedizierte Unterstützung"
|
||||
beschreibung: |
|
||||
Direkte Beratung und Coaching, insbesondere bei komplexen
|
||||
Prozessherausforderungen oder strategischen Initiativen.
|
||||
Besonderer Fokus auf Befähigung der Key-User als Multiplikator:innen.
|
||||
|
||||
- typ: "Befähigungsorientierte Begleitung"
|
||||
beschreibung: |
|
||||
Konsequente Fokussierung auf Befähigung statt Ausführung.
|
||||
Ermächtigung der Nutzenden, ihre Prozesse eigenständig zu managen.
|
||||
Key-User als erste Ansprechpartner:innen in ihren Bereichen.
|
||||
|
||||
- typ: "Community Building & Facilitation"
|
||||
beschreibung: |
|
||||
Aktive Förderung und Pflege des Key-User-Netzwerks als zentrales
|
||||
Element für gemeinsames Lernen, Erfahrungsaustausch und kontinuierliche
|
||||
Verbesserung über Abteilungsgrenzen hinweg.
|
||||
|
||||
- typ: "Proaktive Impulsgebung"
|
||||
beschreibung: |
|
||||
Agieren als Impulsgeber durch Vorstellung neuer Methoden, Best Practices
|
||||
und Anregung des Prozessdenkens. Key-User als Multiplikator:innen
|
||||
tragen diese Impulse in ihre Fachbereiche.
|
||||
|
||||
- typ: "Governance-basierte Interaktion"
|
||||
beschreibung: |
|
||||
Formelles Reporting, strategische Abstimmung und Eskalationsmanagement
|
||||
mit Vision/Mission Boards. Regelmäßige Berichte über Entwicklung der
|
||||
dezentralen Prozesskompetenzen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.3 Kanäle
|
||||
# ---------------------------------------------------------------------------
|
||||
kanaele:
|
||||
beschreibung: |
|
||||
Die Wege und Formate, über die PM-Leistungen zugänglich werden.
|
||||
Die Vielfalt der Kanäle sichert niedrigschwelligen Zugang und ermöglicht
|
||||
situationsgerechte Unterstützung.
|
||||
|
||||
kategorien:
|
||||
direkte_interaktion:
|
||||
name: "Direkte Interaktions- & Befähigungskanäle"
|
||||
kanaele:
|
||||
- name: "Workshops und Schulungen"
|
||||
beschreibung: "Vermittlung von Wissen, Methoden und Werkzeugkompetenzen"
|
||||
- name: "Beratungsgespräche und Coaching"
|
||||
beschreibung: "Maßgeschneiderte Unterstützung (individuell oder Team)"
|
||||
- name: "Moderation von Prozess-Workshops"
|
||||
beschreibung: "Kollaborative Prozessarbeit bei komplexen/bereichsübergreifenden Prozessen"
|
||||
- name: "Ticketsystem"
|
||||
beschreibung: "Formaler Kanal für Anfragen mit automatischem Routing ans PM-Team"
|
||||
|
||||
self_service:
|
||||
name: "Self-Service & digitale Lernkanäle"
|
||||
kanaele:
|
||||
- name: "Zentrale Wissensplattform (Confluence)"
|
||||
beschreibung: "PM-Framework, Methodenhandbuch, Templates, Prozessregister, FAQs"
|
||||
- name: "KI-gestützter PM-Assistent"
|
||||
beschreibung: "Interaktiver Dialog für Prozessfragen und kontextspezifische Antworten"
|
||||
- name: "Prozessvisualisierungs-Tool (Picture Prozess Plattform)"
|
||||
beschreibung: "Eigenständige Arbeit mit der Prozesslandschaft"
|
||||
- name: "E-Learning-Module"
|
||||
beschreibung: "Strukturierte Lernpfade für selbstgesteuertes Lernen"
|
||||
|
||||
community:
|
||||
name: "Community- & Kommunikationskanäle"
|
||||
kanaele:
|
||||
- name: "Key-User-Netzwerktreffen und Communities of Practice"
|
||||
beschreibung: "Regelmäßiger Erfahrungsaustausch und kollektives Lernen"
|
||||
- name: "Informationsveranstaltungen und Newsletter"
|
||||
beschreibung: "Framework-Updates und relevante PM-Informationen"
|
||||
- name: "DigiLog Podcast-Format"
|
||||
beschreibung: "Einsichten und Erfolgsgeschichten zur Förderung des Prozessdenkens"
|
||||
|
||||
# =============================================================================
|
||||
# 4. CLUSTER B: WAS DIE PM-FUNKTION BIETET
|
||||
# =============================================================================
|
||||
|
||||
cluster_b_was:
|
||||
name: "Was die PM-Funktion bietet"
|
||||
|
||||
wertversprechen:
|
||||
beschreibung: |
|
||||
Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen
|
||||
Zielgruppen schafft. Es ist das zentrale Element, das alle anderen
|
||||
Bausteine ausrichtet.
|
||||
|
||||
fuer_strategische_gremien:
|
||||
- nutzen: "Strategische Prozess-Governance und Transparenz"
|
||||
beschreibung: "Konsistente, strategisch ausgerichtete Prozesslandschaft"
|
||||
- nutzen: "Messbare Verbesserung und KPI-basierte Steuerung"
|
||||
beschreibung: "Faktenbasierte Bewertung von Prozessleistung und Nachweis von Optimierungserfolgen"
|
||||
- nutzen: "Entscheidungsunterstützung und Risikominimierung"
|
||||
beschreibung: "Konzepte zur Weiterentwicklung des Operating Models und proaktive Meldung von Risiken"
|
||||
- nutzen: "Skalierbare Prozessstrukturen"
|
||||
beschreibung: "Ermöglichung von Organisationswachstum und systematische Erschließung von Automatisierungspotenzialen"
|
||||
|
||||
fuer_fachbereiche_und_teams:
|
||||
- nutzen: "Einheitliches Prozessmanagement-Framework"
|
||||
beschreibung: "Verbindliche Standards, Methoden, Werkzeuge und Templates"
|
||||
- nutzen: "Methodische Beratung und Unterstützung"
|
||||
beschreibung: "Von der Erstaufnahme bis zur Automatisierung"
|
||||
- nutzen: "Systematische Befähigung zur Selbsthilfe"
|
||||
beschreibung: "Schulungen, Coaching, Self-Service-Ressourcen und Key-User-Netzwerk"
|
||||
- nutzen: "Klarheit und Orientierung"
|
||||
beschreibung: "Gemeinsame Prozess-Sprache über alle Hierarchieebenen"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
- nutzen: "Grundlage für Effektivität und kontinuierliche Verbesserung"
|
||||
beschreibung: "Methodische Rahmenbedingungen für anpassungsfähige Arbeitsabläufe"
|
||||
- nutzen: "Automatisierung und Digitalisierung"
|
||||
beschreibung: "Systematische Identifikation von Automatisierungspotenzialen"
|
||||
- nutzen: "Siloüberwindung und Integration"
|
||||
beschreibung: "Transparente End-to-End-Prozesse und einheitliche Standards"
|
||||
|
||||
# =============================================================================
|
||||
# 5. CLUSTER C: WIE DIE PM-FUNKTION ES ERMÖGLICHT
|
||||
# =============================================================================
|
||||
|
||||
cluster_c_wie:
|
||||
name: "Wie die PM-Funktion es ermöglicht"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.1 Schlüsselaktivitäten
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselaktivitaeten:
|
||||
beschreibung: |
|
||||
Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen
|
||||
einlöst. Sie transformieren Ressourcen in konkreten Nutzen.
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Framework-Entwicklung & -Pflege"
|
||||
beschreibung: |
|
||||
Kontinuierliche Definition und Weiterentwicklung des verbindlichen
|
||||
PM-Frameworks inklusive Methoden, Standards, Templates und Governance-Regeln.
|
||||
umfasst:
|
||||
- "Laufende Analyse interner Bedarfe und externer Best Practices"
|
||||
- "Entwicklung standardisierter Templates"
|
||||
|
||||
- aktivitaet: "Management der Prozesslandschaft & Governance"
|
||||
beschreibung: |
|
||||
Aufbau, Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse.
|
||||
umfasst:
|
||||
- "Sicherstellung der Framework-Compliance"
|
||||
- "Aufdecken von Governance-Lücken"
|
||||
- "Bereitstellung des Prozessregisters"
|
||||
|
||||
- aktivitaet: "Tool-Bereitstellung & -Management"
|
||||
beschreibung: |
|
||||
Auswahl, Implementierung und kontinuierliche Wartung zentraler PM-Tools.
|
||||
umfasst:
|
||||
- "Technische Verfügbarkeit, Updates und Support"
|
||||
- "Integration neuer Möglichkeiten wie KI-gestützte Prozessanalyse"
|
||||
|
||||
- aktivitaet: "Beratung & Methodische Unterstützung"
|
||||
beschreibung: |
|
||||
Durchführung von Beratungen, Coachings und Moderation von Workshops
|
||||
zur Prozessanalyse und -optimierung.
|
||||
umfasst:
|
||||
- "Schwerpunkt auf Befähigung der Fachbereiche zur eigenständigen Prozessarbeit"
|
||||
|
||||
- aktivitaet: "Befähigung & Kompetenzaufbau"
|
||||
beschreibung: |
|
||||
Entwicklung und Umsetzung des Befähigungskonzepts.
|
||||
umfasst:
|
||||
- "Qualifizierung und Betreuung des Key-User-Netzwerks"
|
||||
- "Durchführung von Schulungen"
|
||||
|
||||
- aktivitaet: "Kommunikation & Stakeholder-Engagement"
|
||||
beschreibung: |
|
||||
Aktive Kommunikation von Framework-Updates und Prozessänderungen.
|
||||
umfasst:
|
||||
- "Reporting an Gremien"
|
||||
- "Proaktive Information bei identifizierten Governance-Lücken"
|
||||
|
||||
- aktivitaet: "Prozessinnovation & -weiterentwicklung"
|
||||
beschreibung: |
|
||||
Identifikation von Optimierungspotenzialen und Automatisierungsmöglichkeiten.
|
||||
umfasst:
|
||||
- "Zusammenarbeit mit dem KI-Hub für innovative Lösungsansätze"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.2 Schlüsselressourcen
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselressourcen:
|
||||
beschreibung: |
|
||||
Das notwendige Fundament für wirksame PM-Arbeit. Diese Ressourcen ermöglichen
|
||||
erst die Durchführung der Schlüsselaktivitäten.
|
||||
|
||||
kategorien:
|
||||
menschliche_ressourcen:
|
||||
name: "Menschliche Ressourcen"
|
||||
elemente:
|
||||
- "Fachliche und methodische Expertise in PM-Methoden, -Standards und -Governance"
|
||||
- "Beratungs- und Moderationskompetenz"
|
||||
- "Ausreichende personelle Kapazität"
|
||||
|
||||
intellektuelle_ressourcen:
|
||||
name: "Intellektuelle Ressourcen"
|
||||
elemente:
|
||||
- "Dokumentiertes PM-Framework mit Standards und Methoden"
|
||||
- "Prozesslandkarte mit Prozessregister"
|
||||
- "Strukturierte Schulungskonzepte"
|
||||
- "Umfassende Template-Bibliothek"
|
||||
|
||||
technische_ressourcen:
|
||||
name: "Physische/Technische Ressourcen"
|
||||
elemente:
|
||||
- "Zentrale PM-Werkzeuge für Prozessmodellierung und -dokumentation"
|
||||
- "KI-gestützte Assistenzsysteme zur Prozessanalyse"
|
||||
- "Digitale Kollaborationsplattformen"
|
||||
|
||||
beziehungsnetzwerk:
|
||||
name: "Beziehungsnetzwerk & Zugänge"
|
||||
elemente:
|
||||
- "Etablierte Governance-Zugänge zu relevanten Entscheidungsgremien"
|
||||
- "Key-User-Netzwerk als Community dezentraler Prozessansprechpartner"
|
||||
- "Organisationsweites Beziehungsnetzwerk von Mitarbeitenden bis zur Führung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.3 Schlüsselpartner
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselpartner:
|
||||
beschreibung: |
|
||||
Die internen Kooperationspartner, mit denen die PM-Funktion zusammenarbeitet,
|
||||
um ihr volles Potenzial zu entfalten. Erfolgreiche PM-Arbeit ist immer
|
||||
Teamarbeit über Funktionsgrenzen hinweg.
|
||||
|
||||
partner:
|
||||
- partner: "IT-Architektur"
|
||||
beitrag: "Definiert technische Rahmenbedingungen und Standards, die Framework und Werkzeugauswahl beeinflussen"
|
||||
|
||||
- partner: "Informationssicherheitsbeauftragter"
|
||||
beitrag: "Stellt IT-Sicherheit und technische Compliance von Prozessen sicher"
|
||||
|
||||
- partner: "Datenschutzbeauftragte"
|
||||
beitrag: "Gewährleistet datenschutzkonforme Prozessgestaltung"
|
||||
|
||||
- partner: "Business Continuity Management"
|
||||
beitrag: "Kategorisiert kritische Prozesse und integriert Notfallpläne"
|
||||
|
||||
- partner: "Data Excellence Governance"
|
||||
beitrag: "Stimmt datengetriebene Prozesse ab"
|
||||
|
||||
- partner: "KI-Hub"
|
||||
beitrag: "Strategischer Partner für KI-basierte Prozessinnovationen"
|
||||
|
||||
- partner: "Vision Board"
|
||||
beitrag: "Strategischer Auftraggeber für die PM-Ausrichtung"
|
||||
|
||||
- partner: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beitrag: "Verantworten ihre jeweiligen Teilprozesse"
|
||||
|
||||
- partner: "Qualitätsmanagement"
|
||||
beitrag: "Partner zur Abstimmung von QM-Anforderungen und PM-Standards"
|
||||
status: "noch zu klären"
|
||||
|
||||
- partner: "Zentrale GPM (Geschäftsprozess Management)"
|
||||
beitrag: |
|
||||
Ämterübergreifender Prozess-Framework-Verantwortlicher für einheitliche
|
||||
GPM-Standards und -Methoden. Verfügt über vollständige Prozesslandkarte
|
||||
aller Ämter.
|
||||
|
||||
# =============================================================================
|
||||
# 6. ZUSAMMENHÄNGE UND LESEHILFEN
|
||||
# =============================================================================
|
||||
|
||||
zusammenhaenge:
|
||||
gesamtbild: |
|
||||
Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der
|
||||
PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen
|
||||
Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese
|
||||
Bedarfe in konkrete Leistungszusagen.
|
||||
|
||||
wechselwirkungen:
|
||||
- element: "Key-User-Netzwerk"
|
||||
mehrfachrolle:
|
||||
- "Kanal (für dezentrale Unterstützung)"
|
||||
- "Beziehungselement (Community Building)"
|
||||
- "Ressource (Multiplikator:innen)"
|
||||
|
||||
- element: "Framework-Entwicklung"
|
||||
wechselwirkung: "Schlüsselaktivität, deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten ermöglicht"
|
||||
|
||||
lesehilfen_nach_zielgruppe:
|
||||
gremien:
|
||||
fokus:
|
||||
- "Strategisches Wertversprechen"
|
||||
- "Governance-basierte Beziehungen"
|
||||
- "Formelle Berichtskanäle"
|
||||
relevante_aktivitaeten:
|
||||
- "Framework-Entwicklung"
|
||||
- "Prozesslandschafts-Management"
|
||||
|
||||
fachbereiche_und_teams:
|
||||
fokus:
|
||||
- "Operatives Wertversprechen"
|
||||
- "Befähigungsorientierte Beziehungen"
|
||||
- "Vielfältige Zugangskanäle (Beratung bis Self-Service)"
|
||||
relevante_aktivitaeten:
|
||||
- "Beratung"
|
||||
- "Befähigung"
|
||||
- "Tool-Bereitstellung"
|
||||
|
||||
key_user:
|
||||
mehrfachverortung:
|
||||
- "Teil der Nutzendensegmente"
|
||||
- "Element der Community-Beziehungen"
|
||||
- "Wichtiger Kanal"
|
||||
- "Schlüsselressource"
|
||||
bedeutung: "Zentrale Rolle im Gesamtkonzept"
|
||||
|
||||
# =============================================================================
|
||||
# 7. VERBINDUNG ZU ANDEREN KONZEPTBAUSTEINEN
|
||||
# =============================================================================
|
||||
|
||||
verbindung_zu_anderen_dokumenten:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
verbindung: "Definiert die formalen Verantwortlichkeiten, die den Leistungen zugrunde liegen"
|
||||
|
||||
- dokument: "Governance-Modell"
|
||||
verbindung: "Konkretisiert die Entscheidungswege und Beauftragungslogiken"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
verbindung: "Spezifiziert, wer innerhalb der PM-Funktion für welche Canvas-Elemente verantwortlich ist"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
verbindung: "Operationalisiert die Zusammenarbeit mit den Schlüsselpartnern"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #03.1 - Prozess-Management: Leistungs-Canvas.docx
|
||||
|
||||
Inhalte:
|
||||
- Canvas-Logik (7 Bausteine)
|
||||
- Cluster A: Nutzendensegmente, Nutzendenbeziehung, Kanäle
|
||||
- Cluster B: Wertversprechen (nach Zielgruppen)
|
||||
- Cluster C: Schlüsselaktivitäten, -ressourcen, -partner
|
||||
- Zusammenhänge und Lesehilfen
|
||||
- Verbindungen zu anderen Dokumenten
|
||||
autor: "DIGITOM-Projekt"
|
||||
# =============================================================================
|
||||
# LEISTUNGS-CANVAS: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "leistungs-canvas"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#03.1 - Prozess-Management: Leistungs-Canvas.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. EINFÜHRUNG
|
||||
# =============================================================================
|
||||
|
||||
einfuehrung:
|
||||
warum_ein_leistungs_canvas: |
|
||||
Das Leistungs-Canvas betrachtet die Prozess-Management-Funktion konsequent
|
||||
aus der Perspektive ihrer Nutzer:innen. Diese Perspektivverschiebung macht
|
||||
sichtbar, was in traditionellen Funktionsbeschreibungen oft untergeht:
|
||||
Wie entsteht konkret Nutzen? Welche Beziehungen ermöglichen wirksame
|
||||
Zusammenarbeit? Über welche Wege werden Leistungen tatsächlich zugänglich?
|
||||
|
||||
leitfragen:
|
||||
- "Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?"
|
||||
- "Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?"
|
||||
- "Welche Voraussetzungen müssen dafür geschaffen werden?"
|
||||
|
||||
funktionen_des_canvas:
|
||||
- "Schafft Klarheit über das Leistungsportfolio"
|
||||
- "Macht Zusammenhänge zwischen verschiedenen Elementen sichtbar"
|
||||
- "Dient als Kommunikationsinstrument zwischen PM-Funktion und Nutzer:innen"
|
||||
- "Steuerungsinstrument für Ressourcen-Investitionen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. CANVAS-LOGIK
|
||||
# =============================================================================
|
||||
|
||||
canvas_logik:
|
||||
beschreibung: |
|
||||
Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander
|
||||
verbundene Bausteine. Die rechte Seite fokussiert auf die Außenperspektive,
|
||||
die linke Seite richtet den Blick nach innen. Im Zentrum steht das
|
||||
Wertversprechen als verbindendes Element.
|
||||
|
||||
bausteine:
|
||||
rechte_seite_aussen:
|
||||
- "Nutzendensegmente"
|
||||
- "Nutzendenbeziehung"
|
||||
- "Kanäle"
|
||||
zentrum:
|
||||
- "Wertversprechen"
|
||||
linke_seite_innen:
|
||||
- "Schlüsselaktivitäten"
|
||||
- "Schlüsselressourcen"
|
||||
- "Schlüsselpartner"
|
||||
|
||||
# =============================================================================
|
||||
# 3. CLUSTER A: FÜR WEN DIE PM-FUNKTION DA IST
|
||||
# =============================================================================
|
||||
|
||||
cluster_a_fuer_wen:
|
||||
name: "Für wen die PM-Funktion da ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 Nutzendensegmente
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendensegmente:
|
||||
beschreibung: |
|
||||
Die verschiedenen internen Zielgruppen, für die die PM-Funktion Leistungen
|
||||
erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen und Arbeitsweisen.
|
||||
|
||||
segmente:
|
||||
- segment: "Management-Gremien"
|
||||
beispiele: "Vision Board, Mission Board"
|
||||
bedarfe:
|
||||
- "Transparenz über die Prozesslandschaft"
|
||||
- "Governance-Berichte"
|
||||
- "Einheitliche Standards zur besseren Steuerung"
|
||||
- "Strategische Ausrichtung der Organisation"
|
||||
|
||||
- segment: "Abteilungsleitungen"
|
||||
bedarfe:
|
||||
- "Prozessperspektive für bessere Ressourcenplanung"
|
||||
- "Steuerung ihrer Bereiche"
|
||||
- "Fundierte Entscheidungen bei bereichsübergreifenden Themen"
|
||||
|
||||
- segment: "Process Owner der Teilprozesse"
|
||||
beispiele: "SHM, DPM, PPM, SPM"
|
||||
bedarfe:
|
||||
- "End-to-End-Verantwortung für ihre jeweiligen Teilprozesse"
|
||||
- "Methodische Unterstützung zur Prozessoptimierung"
|
||||
- "Unterstützung bei Prozesssteuerung"
|
||||
|
||||
- segment: "Fachbereiche und Teams mit Key-Usern"
|
||||
bedarfe:
|
||||
- "Methodische Unterstützung"
|
||||
- "Befähigung und Standards"
|
||||
- "Eigenständige Dokumentation und Verbesserung fachspezifischer Prozesse"
|
||||
|
||||
- segment: "Projekt- und Programmorganisationen"
|
||||
bedarfe:
|
||||
- "Einheitliche Prozessvorgaben"
|
||||
- "Methodische Beratung"
|
||||
- "Sicherstellung der Framework-Compliance in Projekten"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 Nutzendenbeziehung
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendenbeziehung:
|
||||
beschreibung: |
|
||||
Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren
|
||||
Nutzer:innen. Sie definiert das "Wie" der Interaktion.
|
||||
|
||||
beziehungstypen:
|
||||
- typ: "Partnerschaftliche Zusammenarbeit & Co-Kreation"
|
||||
beschreibung: |
|
||||
Aufbau von Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen.
|
||||
Key-User als zentrale Partner:innen eng in Entwicklung und Umsetzung
|
||||
von Prozesslösungen eingebunden.
|
||||
|
||||
- typ: "Persönliche Beratung & Dedizierte Unterstützung"
|
||||
beschreibung: |
|
||||
Direkte Beratung und Coaching, insbesondere bei komplexen
|
||||
Prozessherausforderungen oder strategischen Initiativen.
|
||||
Besonderer Fokus auf Befähigung der Key-User als Multiplikator:innen.
|
||||
|
||||
- typ: "Befähigungsorientierte Begleitung"
|
||||
beschreibung: |
|
||||
Konsequente Fokussierung auf Befähigung statt Ausführung.
|
||||
Ermächtigung der Nutzenden, ihre Prozesse eigenständig zu managen.
|
||||
Key-User als erste Ansprechpartner:innen in ihren Bereichen.
|
||||
|
||||
- typ: "Community Building & Facilitation"
|
||||
beschreibung: |
|
||||
Aktive Förderung und Pflege des Key-User-Netzwerks als zentrales
|
||||
Element für gemeinsames Lernen, Erfahrungsaustausch und kontinuierliche
|
||||
Verbesserung über Abteilungsgrenzen hinweg.
|
||||
|
||||
- typ: "Proaktive Impulsgebung"
|
||||
beschreibung: |
|
||||
Agieren als Impulsgeber durch Vorstellung neuer Methoden, Best Practices
|
||||
und Anregung des Prozessdenkens. Key-User als Multiplikator:innen
|
||||
tragen diese Impulse in ihre Fachbereiche.
|
||||
|
||||
- typ: "Governance-basierte Interaktion"
|
||||
beschreibung: |
|
||||
Formelles Reporting, strategische Abstimmung und Eskalationsmanagement
|
||||
mit Vision/Mission Boards. Regelmäßige Berichte über Entwicklung der
|
||||
dezentralen Prozesskompetenzen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.3 Kanäle
|
||||
# ---------------------------------------------------------------------------
|
||||
kanaele:
|
||||
beschreibung: |
|
||||
Die Wege und Formate, über die PM-Leistungen zugänglich werden.
|
||||
Die Vielfalt der Kanäle sichert niedrigschwelligen Zugang und ermöglicht
|
||||
situationsgerechte Unterstützung.
|
||||
|
||||
kategorien:
|
||||
direkte_interaktion:
|
||||
name: "Direkte Interaktions- & Befähigungskanäle"
|
||||
kanaele:
|
||||
- name: "Workshops und Schulungen"
|
||||
beschreibung: "Vermittlung von Wissen, Methoden und Werkzeugkompetenzen"
|
||||
- name: "Beratungsgespräche und Coaching"
|
||||
beschreibung: "Maßgeschneiderte Unterstützung (individuell oder Team)"
|
||||
- name: "Moderation von Prozess-Workshops"
|
||||
beschreibung: "Kollaborative Prozessarbeit bei komplexen/bereichsübergreifenden Prozessen"
|
||||
- name: "Ticketsystem"
|
||||
beschreibung: "Formaler Kanal für Anfragen mit automatischem Routing ans PM-Team"
|
||||
|
||||
self_service:
|
||||
name: "Self-Service & digitale Lernkanäle"
|
||||
kanaele:
|
||||
- name: "Zentrale Wissensplattform (Confluence)"
|
||||
beschreibung: "PM-Framework, Methodenhandbuch, Templates, Prozessregister, FAQs"
|
||||
- name: "KI-gestützter PM-Assistent"
|
||||
beschreibung: "Interaktiver Dialog für Prozessfragen und kontextspezifische Antworten"
|
||||
- name: "Prozessvisualisierungs-Tool (Picture Prozess Plattform)"
|
||||
beschreibung: "Eigenständige Arbeit mit der Prozesslandschaft"
|
||||
- name: "E-Learning-Module"
|
||||
beschreibung: "Strukturierte Lernpfade für selbstgesteuertes Lernen"
|
||||
|
||||
community:
|
||||
name: "Community- & Kommunikationskanäle"
|
||||
kanaele:
|
||||
- name: "Key-User-Netzwerktreffen und Communities of Practice"
|
||||
beschreibung: "Regelmäßiger Erfahrungsaustausch und kollektives Lernen"
|
||||
- name: "Informationsveranstaltungen und Newsletter"
|
||||
beschreibung: "Framework-Updates und relevante PM-Informationen"
|
||||
- name: "DigiLog Podcast-Format"
|
||||
beschreibung: "Einsichten und Erfolgsgeschichten zur Förderung des Prozessdenkens"
|
||||
|
||||
# =============================================================================
|
||||
# 4. CLUSTER B: WAS DIE PM-FUNKTION BIETET
|
||||
# =============================================================================
|
||||
|
||||
cluster_b_was:
|
||||
name: "Was die PM-Funktion bietet"
|
||||
|
||||
wertversprechen:
|
||||
beschreibung: |
|
||||
Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen
|
||||
Zielgruppen schafft. Es ist das zentrale Element, das alle anderen
|
||||
Bausteine ausrichtet.
|
||||
|
||||
fuer_strategische_gremien:
|
||||
- nutzen: "Strategische Prozess-Governance und Transparenz"
|
||||
beschreibung: "Konsistente, strategisch ausgerichtete Prozesslandschaft"
|
||||
- nutzen: "Messbare Verbesserung und KPI-basierte Steuerung"
|
||||
beschreibung: "Faktenbasierte Bewertung von Prozessleistung und Nachweis von Optimierungserfolgen"
|
||||
- nutzen: "Entscheidungsunterstützung und Risikominimierung"
|
||||
beschreibung: "Konzepte zur Weiterentwicklung des Operating Models und proaktive Meldung von Risiken"
|
||||
- nutzen: "Skalierbare Prozessstrukturen"
|
||||
beschreibung: "Ermöglichung von Organisationswachstum und systematische Erschließung von Automatisierungspotenzialen"
|
||||
|
||||
fuer_fachbereiche_und_teams:
|
||||
- nutzen: "Einheitliches Prozessmanagement-Framework"
|
||||
beschreibung: "Verbindliche Standards, Methoden, Werkzeuge und Templates"
|
||||
- nutzen: "Methodische Beratung und Unterstützung"
|
||||
beschreibung: "Von der Erstaufnahme bis zur Automatisierung"
|
||||
- nutzen: "Systematische Befähigung zur Selbsthilfe"
|
||||
beschreibung: "Schulungen, Coaching, Self-Service-Ressourcen und Key-User-Netzwerk"
|
||||
- nutzen: "Klarheit und Orientierung"
|
||||
beschreibung: "Gemeinsame Prozess-Sprache über alle Hierarchieebenen"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
- nutzen: "Grundlage für Effektivität und kontinuierliche Verbesserung"
|
||||
beschreibung: "Methodische Rahmenbedingungen für anpassungsfähige Arbeitsabläufe"
|
||||
- nutzen: "Automatisierung und Digitalisierung"
|
||||
beschreibung: "Systematische Identifikation von Automatisierungspotenzialen"
|
||||
- nutzen: "Siloüberwindung und Integration"
|
||||
beschreibung: "Transparente End-to-End-Prozesse und einheitliche Standards"
|
||||
|
||||
# =============================================================================
|
||||
# 5. CLUSTER C: WIE DIE PM-FUNKTION ES ERMÖGLICHT
|
||||
# =============================================================================
|
||||
|
||||
cluster_c_wie:
|
||||
name: "Wie die PM-Funktion es ermöglicht"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.1 Schlüsselaktivitäten
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselaktivitaeten:
|
||||
beschreibung: |
|
||||
Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen
|
||||
einlöst. Sie transformieren Ressourcen in konkreten Nutzen.
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Framework-Entwicklung & -Pflege"
|
||||
beschreibung: |
|
||||
Kontinuierliche Definition und Weiterentwicklung des verbindlichen
|
||||
PM-Frameworks inklusive Methoden, Standards, Templates und Governance-Regeln.
|
||||
umfasst:
|
||||
- "Laufende Analyse interner Bedarfe und externer Best Practices"
|
||||
- "Entwicklung standardisierter Templates"
|
||||
|
||||
- aktivitaet: "Management der Prozesslandschaft & Governance"
|
||||
beschreibung: |
|
||||
Aufbau, Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse.
|
||||
umfasst:
|
||||
- "Sicherstellung der Framework-Compliance"
|
||||
- "Aufdecken von Governance-Lücken"
|
||||
- "Bereitstellung des Prozessregisters"
|
||||
|
||||
- aktivitaet: "Tool-Bereitstellung & -Management"
|
||||
beschreibung: |
|
||||
Auswahl, Implementierung und kontinuierliche Wartung zentraler PM-Tools.
|
||||
umfasst:
|
||||
- "Technische Verfügbarkeit, Updates und Support"
|
||||
- "Integration neuer Möglichkeiten wie KI-gestützte Prozessanalyse"
|
||||
|
||||
- aktivitaet: "Beratung & Methodische Unterstützung"
|
||||
beschreibung: |
|
||||
Durchführung von Beratungen, Coachings und Moderation von Workshops
|
||||
zur Prozessanalyse und -optimierung.
|
||||
umfasst:
|
||||
- "Schwerpunkt auf Befähigung der Fachbereiche zur eigenständigen Prozessarbeit"
|
||||
|
||||
- aktivitaet: "Befähigung & Kompetenzaufbau"
|
||||
beschreibung: |
|
||||
Entwicklung und Umsetzung des Befähigungskonzepts.
|
||||
umfasst:
|
||||
- "Qualifizierung und Betreuung des Key-User-Netzwerks"
|
||||
- "Durchführung von Schulungen"
|
||||
|
||||
- aktivitaet: "Kommunikation & Stakeholder-Engagement"
|
||||
beschreibung: |
|
||||
Aktive Kommunikation von Framework-Updates und Prozessänderungen.
|
||||
umfasst:
|
||||
- "Reporting an Gremien"
|
||||
- "Proaktive Information bei identifizierten Governance-Lücken"
|
||||
|
||||
- aktivitaet: "Prozessinnovation & -weiterentwicklung"
|
||||
beschreibung: |
|
||||
Identifikation von Optimierungspotenzialen und Automatisierungsmöglichkeiten.
|
||||
umfasst:
|
||||
- "Zusammenarbeit mit dem KI-Hub für innovative Lösungsansätze"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.2 Schlüsselressourcen
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselressourcen:
|
||||
beschreibung: |
|
||||
Das notwendige Fundament für wirksame PM-Arbeit. Diese Ressourcen ermöglichen
|
||||
erst die Durchführung der Schlüsselaktivitäten.
|
||||
|
||||
kategorien:
|
||||
menschliche_ressourcen:
|
||||
name: "Menschliche Ressourcen"
|
||||
elemente:
|
||||
- "Fachliche und methodische Expertise in PM-Methoden, -Standards und -Governance"
|
||||
- "Beratungs- und Moderationskompetenz"
|
||||
- "Ausreichende personelle Kapazität"
|
||||
|
||||
intellektuelle_ressourcen:
|
||||
name: "Intellektuelle Ressourcen"
|
||||
elemente:
|
||||
- "Dokumentiertes PM-Framework mit Standards und Methoden"
|
||||
- "Prozesslandkarte mit Prozessregister"
|
||||
- "Strukturierte Schulungskonzepte"
|
||||
- "Umfassende Template-Bibliothek"
|
||||
|
||||
technische_ressourcen:
|
||||
name: "Physische/Technische Ressourcen"
|
||||
elemente:
|
||||
- "Zentrale PM-Werkzeuge für Prozessmodellierung und -dokumentation"
|
||||
- "KI-gestützte Assistenzsysteme zur Prozessanalyse"
|
||||
- "Digitale Kollaborationsplattformen"
|
||||
|
||||
beziehungsnetzwerk:
|
||||
name: "Beziehungsnetzwerk & Zugänge"
|
||||
elemente:
|
||||
- "Etablierte Governance-Zugänge zu relevanten Entscheidungsgremien"
|
||||
- "Key-User-Netzwerk als Community dezentraler Prozessansprechpartner"
|
||||
- "Organisationsweites Beziehungsnetzwerk von Mitarbeitenden bis zur Führung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.3 Schlüsselpartner
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselpartner:
|
||||
beschreibung: |
|
||||
Die internen Kooperationspartner, mit denen die PM-Funktion zusammenarbeitet,
|
||||
um ihr volles Potenzial zu entfalten. Erfolgreiche PM-Arbeit ist immer
|
||||
Teamarbeit über Funktionsgrenzen hinweg.
|
||||
|
||||
partner:
|
||||
- partner: "IT-Architektur"
|
||||
beitrag: "Definiert technische Rahmenbedingungen und Standards, die Framework und Werkzeugauswahl beeinflussen"
|
||||
|
||||
- partner: "Informationssicherheitsbeauftragter"
|
||||
beitrag: "Stellt IT-Sicherheit und technische Compliance von Prozessen sicher"
|
||||
|
||||
- partner: "Datenschutzbeauftragte"
|
||||
beitrag: "Gewährleistet datenschutzkonforme Prozessgestaltung"
|
||||
|
||||
- partner: "Business Continuity Management"
|
||||
beitrag: "Kategorisiert kritische Prozesse und integriert Notfallpläne"
|
||||
|
||||
- partner: "Data Excellence Governance"
|
||||
beitrag: "Stimmt datengetriebene Prozesse ab"
|
||||
|
||||
- partner: "KI-Hub"
|
||||
beitrag: "Strategischer Partner für KI-basierte Prozessinnovationen"
|
||||
|
||||
- partner: "Vision Board"
|
||||
beitrag: "Strategischer Auftraggeber für die PM-Ausrichtung"
|
||||
|
||||
- partner: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beitrag: "Verantworten ihre jeweiligen Teilprozesse"
|
||||
|
||||
- partner: "Qualitätsmanagement"
|
||||
beitrag: "Partner zur Abstimmung von QM-Anforderungen und PM-Standards"
|
||||
status: "noch zu klären"
|
||||
|
||||
- partner: "Zentrale GPM (Geschäftsprozess Management)"
|
||||
beitrag: |
|
||||
Ämterübergreifender Prozess-Framework-Verantwortlicher für einheitliche
|
||||
GPM-Standards und -Methoden. Verfügt über vollständige Prozesslandkarte
|
||||
aller Ämter.
|
||||
|
||||
# =============================================================================
|
||||
# 6. ZUSAMMENHÄNGE UND LESEHILFEN
|
||||
# =============================================================================
|
||||
|
||||
zusammenhaenge:
|
||||
gesamtbild: |
|
||||
Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der
|
||||
PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen
|
||||
Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese
|
||||
Bedarfe in konkrete Leistungszusagen.
|
||||
|
||||
wechselwirkungen:
|
||||
- element: "Key-User-Netzwerk"
|
||||
mehrfachrolle:
|
||||
- "Kanal (für dezentrale Unterstützung)"
|
||||
- "Beziehungselement (Community Building)"
|
||||
- "Ressource (Multiplikator:innen)"
|
||||
|
||||
- element: "Framework-Entwicklung"
|
||||
wechselwirkung: "Schlüsselaktivität, deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten ermöglicht"
|
||||
|
||||
lesehilfen_nach_zielgruppe:
|
||||
gremien:
|
||||
fokus:
|
||||
- "Strategisches Wertversprechen"
|
||||
- "Governance-basierte Beziehungen"
|
||||
- "Formelle Berichtskanäle"
|
||||
relevante_aktivitaeten:
|
||||
- "Framework-Entwicklung"
|
||||
- "Prozesslandschafts-Management"
|
||||
|
||||
fachbereiche_und_teams:
|
||||
fokus:
|
||||
- "Operatives Wertversprechen"
|
||||
- "Befähigungsorientierte Beziehungen"
|
||||
- "Vielfältige Zugangskanäle (Beratung bis Self-Service)"
|
||||
relevante_aktivitaeten:
|
||||
- "Beratung"
|
||||
- "Befähigung"
|
||||
- "Tool-Bereitstellung"
|
||||
|
||||
key_user:
|
||||
mehrfachverortung:
|
||||
- "Teil der Nutzendensegmente"
|
||||
- "Element der Community-Beziehungen"
|
||||
- "Wichtiger Kanal"
|
||||
- "Schlüsselressource"
|
||||
bedeutung: "Zentrale Rolle im Gesamtkonzept"
|
||||
|
||||
# =============================================================================
|
||||
# 7. VERBINDUNG ZU ANDEREN KONZEPTBAUSTEINEN
|
||||
# =============================================================================
|
||||
|
||||
verbindung_zu_anderen_dokumenten:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
verbindung: "Definiert die formalen Verantwortlichkeiten, die den Leistungen zugrunde liegen"
|
||||
|
||||
- dokument: "Governance-Modell"
|
||||
verbindung: "Konkretisiert die Entscheidungswege und Beauftragungslogiken"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
verbindung: "Spezifiziert, wer innerhalb der PM-Funktion für welche Canvas-Elemente verantwortlich ist"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
verbindung: "Operationalisiert die Zusammenarbeit mit den Schlüsselpartnern"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #03.1 - Prozess-Management: Leistungs-Canvas.docx
|
||||
|
||||
Inhalte:
|
||||
- Canvas-Logik (7 Bausteine)
|
||||
- Cluster A: Nutzendensegmente, Nutzendenbeziehung, Kanäle
|
||||
- Cluster B: Wertversprechen (nach Zielgruppen)
|
||||
- Cluster C: Schlüsselaktivitäten, -ressourcen, -partner
|
||||
- Zusammenhänge und Lesehilfen
|
||||
- Verbindungen zu anderen Dokumenten
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
|
|||
|
|
@ -1,337 +0,0 @@
|
|||
# =============================================================================
|
||||
# PILOTKONZEPT: WORKING STREAM "PROZESSMANAGEMENT"
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "pilotkonzept"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#07 - Pilot-Konzept.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. KONTEXT & KONZEPTBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
kontext:
|
||||
pilotgegenstand: |
|
||||
Einführung und Erprobung der neuen Prozess-Management-Funktionsbereich
|
||||
nach DIGITOM-Modell
|
||||
|
||||
voraussetzungen:
|
||||
titel: "Was benötigen wir zur Zielerreichung?"
|
||||
anforderungen:
|
||||
- id: "VA-1"
|
||||
beschreibung: "Prozess-Management-Tool & Methodik (Auswahl und Setup)"
|
||||
|
||||
- id: "VA-2"
|
||||
beschreibung: "Key-User aus verschiedenen Fachbereichen, je nach Prozessauswahl"
|
||||
|
||||
- id: "VA-3"
|
||||
beschreibung: "Zugang zu bestehender Prozessdokumentation"
|
||||
|
||||
- id: "VA-4"
|
||||
beschreibung: "Workshops-Räume und Moderationsausstattung"
|
||||
|
||||
- id: "VA-5"
|
||||
beschreibung: |
|
||||
Zugriff auf Prozess-Funktions-Mitglieder (Kapazität muss vorhanden sein,
|
||||
Coaching für Framework-Schulungen durchführen zu können)
|
||||
|
||||
- id: "VA-6"
|
||||
beschreibung: |
|
||||
Schulung und Coaching für PM-Team (Coaching für ein Train-the-Trainer-Konzept)
|
||||
und Key-User (Qualifizierungsmaßnahmen intern/extern).
|
||||
Bei Bedarf Einbindung externer Trainer.
|
||||
|
||||
- id: "VA-7"
|
||||
beschreibung: |
|
||||
Auswahl mindestens eines passenden Prozesses zum Prüfen der Wirksamkeit
|
||||
und Arbeitsweise des PM-Teams im Rahmen der Funktion
|
||||
|
||||
hypothesen:
|
||||
titel: "Was wollen wir mit dem Pilot beweisen/widerlegen?"
|
||||
items:
|
||||
- id: "HYP-1"
|
||||
hypothese: |
|
||||
Der definierte PM-Funktionsbereich ist in der Praxis funktionsfähig
|
||||
und wird von den Fachbereichen akzeptiert
|
||||
|
||||
- id: "HYP-2"
|
||||
hypothese: |
|
||||
Key-User können nach entsprechender Befähigung eigenständig Prozesse
|
||||
dokumentieren und optimieren
|
||||
|
||||
- id: "HYP-3"
|
||||
hypothese: |
|
||||
Die Prozessberater sind fähig, die Key-User bei ihrer Aufgabe zu
|
||||
befähigen und zu unterstützen
|
||||
|
||||
- id: "HYP-4"
|
||||
hypothese: |
|
||||
Die Aufnahme eines Prozesses bis in das Prozesstool Picture schafft
|
||||
einen Mehrwert bei der täglichen Arbeit
|
||||
|
||||
- id: "HYP-5"
|
||||
hypothese: "Das Governance-Modell funktioniert effektiv"
|
||||
|
||||
risiken:
|
||||
titel: "Welche potenziellen Risiken sehen wir im Zuge des Piloten?"
|
||||
items:
|
||||
- id: "RISK-1"
|
||||
risiko: |
|
||||
Keine verfügbaren Ressourcen in der Pilotphase, die konkret
|
||||
(verfügbare Zeit) mit der Abteilungsleitung abgestimmt wurden
|
||||
|
||||
- id: "RISK-2"
|
||||
risiko: |
|
||||
Fachbereich kooperiert nicht mit dem Key-User oder Prozessberater
|
||||
(Zeit-Konflikt oder Akzeptanz)
|
||||
|
||||
- id: "RISK-3"
|
||||
risiko: |
|
||||
Keine externe Unterstützung in der anvisierten Zeit
|
||||
(Dienstleister, HPA...)
|
||||
|
||||
- id: "RISK-4"
|
||||
risiko: "Zu starke Anpassungen am Pilotkonzept im Pilotzeitraum"
|
||||
|
||||
# =============================================================================
|
||||
# 2. ROLLENVERGABE
|
||||
# =============================================================================
|
||||
|
||||
rollenvergabe:
|
||||
pilot_sponsor:
|
||||
rolle: "Pilot-Sponsor"
|
||||
person: "Lisa Schroth"
|
||||
|
||||
coaches:
|
||||
rolle: "Coaches"
|
||||
personen:
|
||||
- "Patrick Breitenbach"
|
||||
- "Human Nagafi"
|
||||
|
||||
pilot_lead_operativ:
|
||||
rolle: "Pilot-Lead operativ"
|
||||
person: "Martin Mayer"
|
||||
|
||||
pilot_lead_konsultativ:
|
||||
rolle: "Pilot-Lead konsultativ"
|
||||
person: "Patrick Breitenbach"
|
||||
|
||||
pilot_team:
|
||||
titel: "Pilot-Team"
|
||||
mitglieder:
|
||||
- rolle: "PFM (Prozess-Framework-Manager)"
|
||||
person: "Martin Mayer"
|
||||
|
||||
- rolle: "PB (Prozess-Berater)"
|
||||
personen:
|
||||
- "Gordian Gossen"
|
||||
- "Jannik Eisenmann"
|
||||
- "David Trenkle"
|
||||
|
||||
- rolle: "PLK (Prozesslandschafts-Koordinator)"
|
||||
personen:
|
||||
- "David Trenkle"
|
||||
- "Gordian Gossen"
|
||||
|
||||
hinweis: "Key-User und Process Owner werden im Pilotplan bestimmt"
|
||||
|
||||
# =============================================================================
|
||||
# 3. ARBEITSPAKETE
|
||||
# =============================================================================
|
||||
|
||||
arbeitspakete:
|
||||
- id: "AP-1"
|
||||
name: "Kick-off"
|
||||
aktivitaeten:
|
||||
- "Kick-off mit dem Funktions-Team"
|
||||
output: "Pilotvorstellungs-Präsentation"
|
||||
|
||||
- id: "AP-2"
|
||||
name: "Planungsphase"
|
||||
aktivitaeten:
|
||||
- "Projektmanagement: Projektplan, Risikobewertung, Stakeholder, Ressourceplanung etc."
|
||||
- "Kommunikationsmaßnahmen"
|
||||
- "Schulungsbedarf und Durchführung der Schulungen (Prozess-Berater und Key-User)"
|
||||
- "Tool-Setup"
|
||||
- "Prozessmanagement-Leistungsangebot"
|
||||
- "Methodenübersicht (z.B. Prozess- und Methodenhandbuch)"
|
||||
- "GPM-Kreislauf für die Prozess-Management-Funktion"
|
||||
- "Onboarding Key-User"
|
||||
- "Aufbau Prozessartefakte: Prozessteckbriefe, Prozesslandkarte, Prozessregister"
|
||||
output: "Pilotplan"
|
||||
|
||||
- id: "AP-3"
|
||||
name: "Onboarding und Informationsphase"
|
||||
aktivitaeten:
|
||||
- "Pilotprozesse auswählen"
|
||||
- "Prozess-Berater onboarden"
|
||||
- "Key-User auswählen und onboarden"
|
||||
output: "Bei Bedarf aktualisierter Pilotplan"
|
||||
|
||||
- id: "AP-4"
|
||||
name: "Umsetzungsphase"
|
||||
aktivitaeten:
|
||||
- "Pilotprozess aufnehmen in definierten Bereichen"
|
||||
- "Pilotdurchführung monitoren (Quantitativ und Qualitativ)"
|
||||
- "Pilotdurchführung reviewen (Was läuft gut? / Was lernen wir unterwegs? / Wo haben wir Probleme?)"
|
||||
output: "Prozess-Artefakte, Bei Bedarf aktualisierter Pilotplan"
|
||||
|
||||
- id: "AP-5"
|
||||
name: "Retrospektive"
|
||||
aktivitaeten:
|
||||
- "Retrospektive vorbereiten und durchführen"
|
||||
- "Empfehlung weitere Vorgehen durch 1789 ausarbeiten"
|
||||
output: "Ergebnisbericht Pilotdurchführung, Empfehlungsbericht"
|
||||
|
||||
# =============================================================================
|
||||
# 4. KOMMUNIKATIONSWEGE
|
||||
# =============================================================================
|
||||
|
||||
kommunikation:
|
||||
intern:
|
||||
titel: "Interne Kommunikation"
|
||||
kanaele:
|
||||
- kanal: "Mission Board"
|
||||
zweck: "Vorstellung Pilotkonzept und Retroergebnisse"
|
||||
|
||||
- kanal: "SyncUp PzM"
|
||||
rhythmus: "1x Woche"
|
||||
format: "Teil für Pilot-Team, Teil für restliches Funktions-Team"
|
||||
|
||||
- kanal: "Key-User Runde"
|
||||
|
||||
- kanal: "Abteilungsleitungen"
|
||||
|
||||
- kanal: "DIGIT Allgemein"
|
||||
|
||||
- kanal: "Process Owner"
|
||||
|
||||
- kanal: "Weekly Check-In Pilotstatus und Review"
|
||||
rhythmus: "Wöchentlich"
|
||||
dauer: "Maximal 30 Minuten"
|
||||
verantwortlich: "1789 inkl. PzM-Team"
|
||||
|
||||
- kanal: "Ad-Hoc Coaching"
|
||||
format: "Auf Anfrage durch 1789"
|
||||
|
||||
- kanal: "Moderierte Retrospektive"
|
||||
anzahl: "1x"
|
||||
verantwortlich: "1789"
|
||||
|
||||
hinweis: "Weitere Maßnahmen gemäß Ergebnisse Kommunikationsplanung (Maßnahme)"
|
||||
|
||||
extern:
|
||||
titel: "Externe Schnittstellen"
|
||||
partner:
|
||||
- "Zentrales GPM der Stadt Freiburg"
|
||||
|
||||
# =============================================================================
|
||||
# 5. TIMELINE / RHYTHMUS
|
||||
# =============================================================================
|
||||
|
||||
timeline:
|
||||
hinweis: |
|
||||
Folgende Phasenzeitplanung wird angenommen. Anpassungen können während
|
||||
der Pilotphase erfolgen.
|
||||
|
||||
verlaengerung: |
|
||||
Bei Bedarf Verlängerung bis Anfang 2026. Die Retrospektive sowie die
|
||||
Empfehlungsdokumente von 1789 sind dann davon nicht betroffen.
|
||||
|
||||
phasen:
|
||||
- phase: "Kick-off"
|
||||
termin: "ca. 27.08.2025"
|
||||
typ: "Meilenstein"
|
||||
|
||||
- phase: "Pilotphase allgemein"
|
||||
start: "15.08.2025"
|
||||
ende: "31.12.2025"
|
||||
typ: "Rahmen"
|
||||
|
||||
- phase: "Planungsphase"
|
||||
start: "15.08.2025"
|
||||
ende: "30.09.2025"
|
||||
arbeitspaket: "AP-2"
|
||||
|
||||
- phase: "Onboarding und Informationsphase"
|
||||
start: "01.10.2025"
|
||||
ende: "15.11.2025"
|
||||
arbeitspaket: "AP-3"
|
||||
|
||||
- phase: "Umsetzungsphase"
|
||||
start: "15.10.2025"
|
||||
ende: "15.12.2025"
|
||||
arbeitspaket: "AP-4"
|
||||
|
||||
- phase: "Retrospektive"
|
||||
termin: "ca. 16.12.2025"
|
||||
typ: "Meilenstein"
|
||||
arbeitspaket: "AP-5"
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNGEN
|
||||
# =============================================================================
|
||||
|
||||
verknuepfungen:
|
||||
referenzierte_dokumente:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
relevanz: "Definiert die zu pilotierende Funktion"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
relevanz: "Beschreibt die Rollen PFM, PB, PLK, KNM, KU, PO"
|
||||
|
||||
- dokument: "Governance-Framework"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
relevanz: "Hypothese HYP-5 testet dessen Wirksamkeit"
|
||||
|
||||
- dokument: "Leistungs-Canvas"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
relevanz: "Definiert das Leistungsangebot"
|
||||
|
||||
externe_partner:
|
||||
- partner: "1789"
|
||||
rolle: "Coaching und Moderation"
|
||||
leistungen:
|
||||
- "Weekly Check-In"
|
||||
- "Ad-Hoc Coaching"
|
||||
- "Moderierte Retrospektive"
|
||||
- "Empfehlungsbericht"
|
||||
|
||||
- partner: "Zentrales GPM Stadt Freiburg (HPA)"
|
||||
rolle: "Externe Schnittstelle"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #07 - Pilot-Konzept.docx
|
||||
|
||||
Inhalte:
|
||||
- Kontext & Konzeptbeschreibung (7 Voraussetzungen, 5 Hypothesen, 4 Risiken)
|
||||
- Rollenvergabe (Sponsor, Coaches, Leads, Team)
|
||||
- 5 Arbeitspakete (Kick-off bis Retrospektive)
|
||||
- Kommunikationswege (intern und extern)
|
||||
- Timeline (15.08.2025 - 31.12.2025)
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -1,162 +1,162 @@
|
|||
# =============================================================================
|
||||
# ROLLENMODELL: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "rollenmodell"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#04 - Prozess-Management: Rollenmodell.docx"
|
||||
|
||||
# =============================================================================
|
||||
# STRATEGISCHE ARCHITEKTUR-PRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
architektur_prinzipien:
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM operiert als Enabling-Funktion mit klarer
|
||||
Trennung zwischen methodischer Beratung und operativer PM-Governance.
|
||||
Die Rollen-Architektur folgt dem Prinzip der dezentralen Befähigung bei
|
||||
zentraler Methodenkompetenz.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Enabling-Funktion"
|
||||
beschreibung: "PM unterstützt und befähigt, kontrolliert nicht"
|
||||
|
||||
- prinzip: "Dezentrale Befähigung"
|
||||
beschreibung: "Prozess-Kompetenz wird in die Fachbereiche getragen"
|
||||
|
||||
- prinzip: "Zentrale Methodenkompetenz"
|
||||
beschreibung: "Framework und Standards werden zentral gepflegt"
|
||||
|
||||
- prinzip: "Beratung-vs.-Governance-Trennung"
|
||||
beschreibung: |
|
||||
Methodische Unterstützung und PM-Compliance-Überwachung werden auf
|
||||
unterschiedliche Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten.
|
||||
|
||||
hinweis: |
|
||||
Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare Verantwortungsschnitte
|
||||
und vermeidet Interessenskonflikte (z.B. zwischen PM-Governance-Überwachung und
|
||||
PM-Framework-Gestaltung).
|
||||
|
||||
# =============================================================================
|
||||
# BEGRIFFSDEFINITION: END-TO-END VERANTWORTUNG
|
||||
# =============================================================================
|
||||
|
||||
begriffsdefinitionen:
|
||||
end_to_end_verantwortung:
|
||||
definition: |
|
||||
Im DIGITOM-Kontext bedeutet "End-to-End Verantwortung" die vollständige
|
||||
Verantwortung für einen definierten Prozessabschnitt über alle beteiligten
|
||||
Funktionen und Abteilungen hinweg.
|
||||
|
||||
abgrenzungen:
|
||||
- "End-to-End bezieht sich auf Teilprozesse, nicht auf den Gesamtprozess"
|
||||
- "Der Process Owner trägt die Verantwortung innerhalb seiner Prozessebene"
|
||||
- "Aktive Gestaltung der Schnittstellen zu vor- und nachgelagerten Prozessen"
|
||||
|
||||
verantwortung_umfasst:
|
||||
- "Performance und Qualität des eigenen Teilprozesses"
|
||||
- "Schnittstellen-Vereinbarungen mit angrenzenden Process Ownern"
|
||||
- "Eskalation bei Problemen in verbundenen Prozessen"
|
||||
- "Kontinuierliche Optimierung inkl. schnittstellenübergreifender Verbesserungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
rollen_uebersicht:
|
||||
|
||||
kernrollen_intern:
|
||||
beschreibung: "Interne PM-Organisation"
|
||||
rollen:
|
||||
- id: "R1"
|
||||
name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
datei: "rolle_leiter-pm.yaml"
|
||||
|
||||
- id: "R2"
|
||||
name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
datei: "rolle_prozess-framework-manager.yaml"
|
||||
|
||||
- id: "R3"
|
||||
name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
datei: "rolle_prozesslandschafts-koordinator.yaml"
|
||||
|
||||
- id: "R4"
|
||||
name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
datei: "rolle_prozess-berater.yaml"
|
||||
|
||||
- id: "R5"
|
||||
name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
datei: "rolle_key-user-netzwerk-manager.yaml"
|
||||
|
||||
schnittstellenrollen:
|
||||
beschreibung: "Rollen an der Schnittstelle zwischen PM und Organisation"
|
||||
rollen:
|
||||
- id: "R6"
|
||||
name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
datei: "rolle_process-owner.yaml"
|
||||
hinweis: "Übernommen von SHM, DPM, PPM, SPM"
|
||||
|
||||
- id: "R7"
|
||||
name: "Key-User"
|
||||
kurzform: "KU"
|
||||
datei: "rolle_key-user.yaml"
|
||||
hinweis: "Formale Rolle in den Fachbereichen"
|
||||
|
||||
- id: "R8"
|
||||
name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
datei: "rolle_auftraggeber-pm.yaml"
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
governance_support_rollen:
|
||||
beschreibung: "Governance- und Support-Rollen"
|
||||
rollen:
|
||||
- id: "R9"
|
||||
name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
datei: "rolle_it-architektur.yaml"
|
||||
hinweis: "Technische Schnittstelle"
|
||||
|
||||
- id: "R10"
|
||||
name: "ISB / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
datei: "rolle_isb-dsb.yaml"
|
||||
|
||||
- id: "R11"
|
||||
name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
datei: "rolle_gremien.yaml"
|
||||
hinweis: "Vision Board, Mission Board, DSR"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #04 - Prozess-Management: Rollenmodell.docx
|
||||
autor: "DIGITOM-Projekt"
|
||||
# =============================================================================
|
||||
# ROLLENMODELL: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "rollenmodell"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#04 - Prozess-Management: Rollenmodell.docx"
|
||||
|
||||
# =============================================================================
|
||||
# STRATEGISCHE ARCHITEKTUR-PRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
architektur_prinzipien:
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM operiert als Enabling-Funktion mit klarer
|
||||
Trennung zwischen methodischer Beratung und operativer PM-Governance.
|
||||
Die Rollen-Architektur folgt dem Prinzip der dezentralen Befähigung bei
|
||||
zentraler Methodenkompetenz.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Enabling-Funktion"
|
||||
beschreibung: "PM unterstützt und befähigt, kontrolliert nicht"
|
||||
|
||||
- prinzip: "Dezentrale Befähigung"
|
||||
beschreibung: "Prozess-Kompetenz wird in die Fachbereiche getragen"
|
||||
|
||||
- prinzip: "Zentrale Methodenkompetenz"
|
||||
beschreibung: "Framework und Standards werden zentral gepflegt"
|
||||
|
||||
- prinzip: "Beratung-vs.-Governance-Trennung"
|
||||
beschreibung: |
|
||||
Methodische Unterstützung und PM-Compliance-Überwachung werden auf
|
||||
unterschiedliche Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten.
|
||||
|
||||
hinweis: |
|
||||
Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare Verantwortungsschnitte
|
||||
und vermeidet Interessenskonflikte (z.B. zwischen PM-Governance-Überwachung und
|
||||
PM-Framework-Gestaltung).
|
||||
|
||||
# =============================================================================
|
||||
# BEGRIFFSDEFINITION: END-TO-END VERANTWORTUNG
|
||||
# =============================================================================
|
||||
|
||||
begriffsdefinitionen:
|
||||
end_to_end_verantwortung:
|
||||
definition: |
|
||||
Im DIGITOM-Kontext bedeutet "End-to-End Verantwortung" die vollständige
|
||||
Verantwortung für einen definierten Prozessabschnitt über alle beteiligten
|
||||
Funktionen und Abteilungen hinweg.
|
||||
|
||||
abgrenzungen:
|
||||
- "End-to-End bezieht sich auf Teilprozesse, nicht auf den Gesamtprozess"
|
||||
- "Der Process Owner trägt die Verantwortung innerhalb seiner Prozessebene"
|
||||
- "Aktive Gestaltung der Schnittstellen zu vor- und nachgelagerten Prozessen"
|
||||
|
||||
verantwortung_umfasst:
|
||||
- "Performance und Qualität des eigenen Teilprozesses"
|
||||
- "Schnittstellen-Vereinbarungen mit angrenzenden Process Ownern"
|
||||
- "Eskalation bei Problemen in verbundenen Prozessen"
|
||||
- "Kontinuierliche Optimierung inkl. schnittstellenübergreifender Verbesserungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
rollen_uebersicht:
|
||||
|
||||
kernrollen_intern:
|
||||
beschreibung: "Interne PM-Organisation"
|
||||
rollen:
|
||||
- id: "R1"
|
||||
name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
datei: "rolle_leiter-pm.yaml"
|
||||
|
||||
- id: "R2"
|
||||
name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
datei: "rolle_prozess-framework-manager.yaml"
|
||||
|
||||
- id: "R3"
|
||||
name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
datei: "rolle_prozesslandschafts-koordinator.yaml"
|
||||
|
||||
- id: "R4"
|
||||
name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
datei: "rolle_prozess-berater.yaml"
|
||||
|
||||
- id: "R5"
|
||||
name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
datei: "rolle_key-user-netzwerk-manager.yaml"
|
||||
|
||||
schnittstellenrollen:
|
||||
beschreibung: "Rollen an der Schnittstelle zwischen PM und Organisation"
|
||||
rollen:
|
||||
- id: "R6"
|
||||
name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
datei: "rolle_process-owner.yaml"
|
||||
hinweis: "Übernommen von SHM, DPM, PPM, SPM"
|
||||
|
||||
- id: "R7"
|
||||
name: "Key-User"
|
||||
kurzform: "KU"
|
||||
datei: "rolle_key-user.yaml"
|
||||
hinweis: "Formale Rolle in den Fachbereichen"
|
||||
|
||||
- id: "R8"
|
||||
name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
datei: "rolle_auftraggeber-pm.yaml"
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
governance_support_rollen:
|
||||
beschreibung: "Governance- und Support-Rollen"
|
||||
rollen:
|
||||
- id: "R9"
|
||||
name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
datei: "rolle_it-architektur.yaml"
|
||||
hinweis: "Technische Schnittstelle"
|
||||
|
||||
- id: "R10"
|
||||
name: "ISB / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
datei: "rolle_isb-dsb.yaml"
|
||||
|
||||
- id: "R11"
|
||||
name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
datei: "rolle_gremien.yaml"
|
||||
hinweis: "Vision Board, Mission Board, DSR"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #04 - Prozess-Management: Rollenmodell.docx
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
|
|||
|
|
@ -1,69 +1,69 @@
|
|||
# =============================================================================
|
||||
# ROLLE: AUFTRAGGEBER PROZESS-MANAGEMENT (AG-PM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R8-AG-PM"
|
||||
rolle_name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Bedarfs-Artikulation und Beauftragung der PM-Funktion zur zielgerichteten
|
||||
Nutzung der PM-Services für spezifische organisatorische Herausforderungen.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation und Artikulation von Prozess-Management-Bedarfen"
|
||||
- "Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder Projekten"
|
||||
- "Bereitstellung notwendiger Ressourcen und Informationen für PM-Services"
|
||||
- "Definition von Erfolgserwartungen und Zielen für PM-Unterstützung"
|
||||
- "Feedback und Bewertung der erbrachten PM-Leistungen"
|
||||
- "Sicherstellung der Implementierung von PM-Empfehlungen"
|
||||
|
||||
# =============================================================================
|
||||
# AUFTRAGGEBER-KATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
auftraggeber_kategorien:
|
||||
- kategorie: "Abteilungsleitung"
|
||||
fokus: "Bereichsspezifische Prozessoptimierungen"
|
||||
|
||||
- kategorie: "Projektleitungen"
|
||||
fokus: "Projektbezogene Prozess-Unterstützung"
|
||||
|
||||
- kategorie: "Vision Board / Mission Board"
|
||||
fokus: "Strategische PM-Initiativen"
|
||||
|
||||
- kategorie: "Service-(Portfolio)-Manager"
|
||||
fokus: "Servicebezogene Prozessentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Beauftragung und Zusammenarbeit"
|
||||
- name: "Betroffene Teams und Bereiche"
|
||||
beziehung: "Implementierung"
|
||||
- name: "Übergeordnete Gremien"
|
||||
beziehung: "Bei strategischen Aufträgen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Beauftragung und Priorisierung von PM-Services im eigenen Verantwortungsbereich"
|
||||
- "Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten"
|
||||
- "Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen"
|
||||
- "Stakeholder-Management für Implementierungsmaßnahmen"
|
||||
- "Change-Management-Grundverständnis"
|
||||
- "Budget- und Ressourcen-Verantwortung"
|
||||
# =============================================================================
|
||||
# ROLLE: AUFTRAGGEBER PROZESS-MANAGEMENT (AG-PM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R8-AG-PM"
|
||||
rolle_name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Bedarfs-Artikulation und Beauftragung der PM-Funktion zur zielgerichteten
|
||||
Nutzung der PM-Services für spezifische organisatorische Herausforderungen.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation und Artikulation von Prozess-Management-Bedarfen"
|
||||
- "Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder Projekten"
|
||||
- "Bereitstellung notwendiger Ressourcen und Informationen für PM-Services"
|
||||
- "Definition von Erfolgserwartungen und Zielen für PM-Unterstützung"
|
||||
- "Feedback und Bewertung der erbrachten PM-Leistungen"
|
||||
- "Sicherstellung der Implementierung von PM-Empfehlungen"
|
||||
|
||||
# =============================================================================
|
||||
# AUFTRAGGEBER-KATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
auftraggeber_kategorien:
|
||||
- kategorie: "Abteilungsleitung"
|
||||
fokus: "Bereichsspezifische Prozessoptimierungen"
|
||||
|
||||
- kategorie: "Projektleitungen"
|
||||
fokus: "Projektbezogene Prozess-Unterstützung"
|
||||
|
||||
- kategorie: "Vision Board / Mission Board"
|
||||
fokus: "Strategische PM-Initiativen"
|
||||
|
||||
- kategorie: "Service-(Portfolio)-Manager"
|
||||
fokus: "Servicebezogene Prozessentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Beauftragung und Zusammenarbeit"
|
||||
- name: "Betroffene Teams und Bereiche"
|
||||
beziehung: "Implementierung"
|
||||
- name: "Übergeordnete Gremien"
|
||||
beziehung: "Bei strategischen Aufträgen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Beauftragung und Priorisierung von PM-Services im eigenen Verantwortungsbereich"
|
||||
- "Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten"
|
||||
- "Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen"
|
||||
- "Stakeholder-Management für Implementierungsmaßnahmen"
|
||||
- "Change-Management-Grundverständnis"
|
||||
- "Budget- und Ressourcen-Verantwortung"
|
||||
|
|
|
|||
|
|
@ -1,71 +1,71 @@
|
|||
# =============================================================================
|
||||
# ROLLE: GREMIEN (Vision Board, Mission Board, DSR)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R11-GREMIEN"
|
||||
rolle_name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Vision Board, Mission Board, Digital Services Review"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische und taktische Steuerung der PM-Funktion sowie
|
||||
Entscheidungen zu prozessrelevanten Governance-Fragen.
|
||||
|
||||
# =============================================================================
|
||||
# GREMIEN-SPEZIFISCHE AUFGABEN
|
||||
# =============================================================================
|
||||
|
||||
gremien:
|
||||
vision_board:
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
aufgaben:
|
||||
- "Strategische PM-Ausrichtung und Framework-Grundsätze"
|
||||
- "Budget- und Ressourcen-Entscheidungen für PM-Funktion"
|
||||
- "Grundsatzentscheidungen bei Eskalationen"
|
||||
|
||||
mission_board:
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch"
|
||||
aufgaben:
|
||||
- "Taktische PM-Priorisierung und Konfliktlösung"
|
||||
- "Prozessübergreifende Optimierungsentscheidungen"
|
||||
- "Entscheidungen bei Ressourcenkonflikten"
|
||||
- "Governance-Eskalationen"
|
||||
|
||||
dsr:
|
||||
name: "Digital Services Review (DSR)"
|
||||
ebene: "operativ"
|
||||
aufgaben:
|
||||
- "Operative Prozess-Entscheidungen im Kontext des Service-Portfolios"
|
||||
|
||||
# =============================================================================
|
||||
# BEZIEHUNG ZUR PM-FUNKTION
|
||||
# =============================================================================
|
||||
|
||||
beziehung_pm:
|
||||
vision_board:
|
||||
- "Empfängt strategische Berichte und Konzepte von PM"
|
||||
- "Erteilt strategische Aufträge an PM"
|
||||
- "Entscheidet über Framework-Transformationen"
|
||||
|
||||
mission_board:
|
||||
- "Empfängt operative Berichte von PM"
|
||||
- "Entscheidet über Projekt-Leistungen"
|
||||
- "Löst Prioritätskonflikte"
|
||||
|
||||
dsr:
|
||||
- "Abstimmung servicebezogener Prozessfragen"
|
||||
# =============================================================================
|
||||
# ROLLE: GREMIEN (Vision Board, Mission Board, DSR)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R11-GREMIEN"
|
||||
rolle_name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Vision Board, Mission Board, Digital Services Review"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische und taktische Steuerung der PM-Funktion sowie
|
||||
Entscheidungen zu prozessrelevanten Governance-Fragen.
|
||||
|
||||
# =============================================================================
|
||||
# GREMIEN-SPEZIFISCHE AUFGABEN
|
||||
# =============================================================================
|
||||
|
||||
gremien:
|
||||
vision_board:
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
aufgaben:
|
||||
- "Strategische PM-Ausrichtung und Framework-Grundsätze"
|
||||
- "Budget- und Ressourcen-Entscheidungen für PM-Funktion"
|
||||
- "Grundsatzentscheidungen bei Eskalationen"
|
||||
|
||||
mission_board:
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch"
|
||||
aufgaben:
|
||||
- "Taktische PM-Priorisierung und Konfliktlösung"
|
||||
- "Prozessübergreifende Optimierungsentscheidungen"
|
||||
- "Entscheidungen bei Ressourcenkonflikten"
|
||||
- "Governance-Eskalationen"
|
||||
|
||||
dsr:
|
||||
name: "Digital Services Review (DSR)"
|
||||
ebene: "operativ"
|
||||
aufgaben:
|
||||
- "Operative Prozess-Entscheidungen im Kontext des Service-Portfolios"
|
||||
|
||||
# =============================================================================
|
||||
# BEZIEHUNG ZUR PM-FUNKTION
|
||||
# =============================================================================
|
||||
|
||||
beziehung_pm:
|
||||
vision_board:
|
||||
- "Empfängt strategische Berichte und Konzepte von PM"
|
||||
- "Erteilt strategische Aufträge an PM"
|
||||
- "Entscheidet über Framework-Transformationen"
|
||||
|
||||
mission_board:
|
||||
- "Empfängt operative Berichte von PM"
|
||||
- "Entscheidet über Projekt-Leistungen"
|
||||
- "Löst Prioritätskonflikte"
|
||||
|
||||
dsr:
|
||||
- "Abstimmung servicebezogener Prozessfragen"
|
||||
|
|
|
|||
|
|
@ -1,40 +1,40 @@
|
|||
# =============================================================================
|
||||
# ROLLE: ISB / DATENSCHUTZBEAUFTRAGTE*R
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R10-ISB-DSB"
|
||||
rolle_name: "Informationssicherheitsbeauftragte*r / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der Compliance von Prozessen und PM-Tools mit
|
||||
Sicherheits- und Datenschutzvorgaben.
|
||||
|
||||
kernaufgaben:
|
||||
- "Compliance-Prüfung von Prozess-Designs und PM-Tools"
|
||||
- "Definition sicherheitsrelevanter Prozess-Anforderungen"
|
||||
- "Risiko-Assessment für prozessbezogene Datenverarbeitung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Compliance-Beratung und -Freigaben"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene Sicherheitsanforderungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Datenschutz-Compliance"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Compliance-Freigaben für Prozesse und Tools"
|
||||
- "Definition von Sicherheitsanforderungen"
|
||||
# =============================================================================
|
||||
# ROLLE: ISB / DATENSCHUTZBEAUFTRAGTE*R
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R10-ISB-DSB"
|
||||
rolle_name: "Informationssicherheitsbeauftragte*r / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der Compliance von Prozessen und PM-Tools mit
|
||||
Sicherheits- und Datenschutzvorgaben.
|
||||
|
||||
kernaufgaben:
|
||||
- "Compliance-Prüfung von Prozess-Designs und PM-Tools"
|
||||
- "Definition sicherheitsrelevanter Prozess-Anforderungen"
|
||||
- "Risiko-Assessment für prozessbezogene Datenverarbeitung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Compliance-Beratung und -Freigaben"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene Sicherheitsanforderungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Datenschutz-Compliance"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Compliance-Freigaben für Prozesse und Tools"
|
||||
- "Definition von Sicherheitsanforderungen"
|
||||
|
|
|
|||
|
|
@ -1,43 +1,43 @@
|
|||
# =============================================================================
|
||||
# ROLLE: IT-ARCHITEKTUR (Technische Schnittstelle)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R9-ITA"
|
||||
rolle_name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Technische Schnittstelle zur PM-Funktion"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der technischen Machbarkeit und Integration von
|
||||
Prozess-Lösungen in die DIGITOM-IT-Landschaft.
|
||||
|
||||
kernaufgaben:
|
||||
- "Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen"
|
||||
- "Definition technischer Rahmenbedingungen für Prozess-Tools und -systeme"
|
||||
- "Sicherstellung der Systemkompatibilität bei prozessbezogenen IT-Lösungen"
|
||||
- "Beratung zu technischen Möglichkeiten und Grenzen bei Prozessoptimierungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Technische Beratung und Abstimmung"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene IT-Anforderungen"
|
||||
- name: "IT-Betrieb"
|
||||
beziehung: "Systemintegration und -betrieb"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Technische Architektur-Vorgaben für Prozess-Tools"
|
||||
- "System-Kompatibilitäts-Bewertungen"
|
||||
# =============================================================================
|
||||
# ROLLE: IT-ARCHITEKTUR (Technische Schnittstelle)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R9-ITA"
|
||||
rolle_name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Technische Schnittstelle zur PM-Funktion"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der technischen Machbarkeit und Integration von
|
||||
Prozess-Lösungen in die DIGITOM-IT-Landschaft.
|
||||
|
||||
kernaufgaben:
|
||||
- "Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen"
|
||||
- "Definition technischer Rahmenbedingungen für Prozess-Tools und -systeme"
|
||||
- "Sicherstellung der Systemkompatibilität bei prozessbezogenen IT-Lösungen"
|
||||
- "Beratung zu technischen Möglichkeiten und Grenzen bei Prozessoptimierungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Technische Beratung und Abstimmung"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene IT-Anforderungen"
|
||||
- name: "IT-Betrieb"
|
||||
beziehung: "Systemintegration und -betrieb"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Technische Architektur-Vorgaben für Prozess-Tools"
|
||||
- "System-Kompatibilitäts-Bewertungen"
|
||||
|
|
|
|||
|
|
@ -1,57 +1,57 @@
|
|||
# =============================================================================
|
||||
# ROLLE: KEY-USER-NETZWERK-MANAGER*IN (KNM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R5-KNM"
|
||||
rolle_name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Systematischer Aufbau und Betreuung eines dezentralen Netzwerks von
|
||||
Prozess-Champions zur Skalierung der PM-Kompetenz in die gesamte
|
||||
DIGITOM-Organisation.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation, Rekrutierung und Onboarding geeigneter Key-User in allen Abteilungen"
|
||||
- "Entwicklung und Durchführung strukturierter Qualifizierungsprogramme für Key-User"
|
||||
- "Community-Management durch regelmäßige Netzwerk-Events und Erfahrungsaustausch"
|
||||
- "Aufbau und Pflege der zentralen Wissensplattform mit Self-Service-Ressourcen"
|
||||
- "Best-Practice-Transfer zwischen Abteilungen durch das Key-User-Netzwerk"
|
||||
- "Performance-Management des Key-User-Netzwerks und kontinuierliche Weiterentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "Key-User in allen Fachbereichen/Abteilungen"
|
||||
beziehung: "Direkte Betreuung und Entwicklung"
|
||||
- name: "Fachbereichsleitungen"
|
||||
beziehung: "Key-User-Nominierung und Freistellung"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Operative Zusammenarbeit bei Fachbereichs-Support"
|
||||
- name: "IT-Abteilung"
|
||||
beziehung: "Wissensplattform-Entwicklung und -betrieb"
|
||||
- name: "Personalentwicklung"
|
||||
beziehung: "Qualifizierungskoordination"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design"
|
||||
- "Community-Event-Planung und Ressourcen-Allokation"
|
||||
- "Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung"
|
||||
- "Key-User-Performance-Bewertung und Entwicklungsempfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Community-Building und Netzwerk-Management für diverse organisatorische Kontexte"
|
||||
- "Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung"
|
||||
- "Content-Management für digitale Wissensplattformen"
|
||||
- "Motivations- und Engagement-Management für freiwillige Communities"
|
||||
- "Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung"
|
||||
# =============================================================================
|
||||
# ROLLE: KEY-USER-NETZWERK-MANAGER*IN (KNM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R5-KNM"
|
||||
rolle_name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Systematischer Aufbau und Betreuung eines dezentralen Netzwerks von
|
||||
Prozess-Champions zur Skalierung der PM-Kompetenz in die gesamte
|
||||
DIGITOM-Organisation.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation, Rekrutierung und Onboarding geeigneter Key-User in allen Abteilungen"
|
||||
- "Entwicklung und Durchführung strukturierter Qualifizierungsprogramme für Key-User"
|
||||
- "Community-Management durch regelmäßige Netzwerk-Events und Erfahrungsaustausch"
|
||||
- "Aufbau und Pflege der zentralen Wissensplattform mit Self-Service-Ressourcen"
|
||||
- "Best-Practice-Transfer zwischen Abteilungen durch das Key-User-Netzwerk"
|
||||
- "Performance-Management des Key-User-Netzwerks und kontinuierliche Weiterentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "Key-User in allen Fachbereichen/Abteilungen"
|
||||
beziehung: "Direkte Betreuung und Entwicklung"
|
||||
- name: "Fachbereichsleitungen"
|
||||
beziehung: "Key-User-Nominierung und Freistellung"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Operative Zusammenarbeit bei Fachbereichs-Support"
|
||||
- name: "IT-Abteilung"
|
||||
beziehung: "Wissensplattform-Entwicklung und -betrieb"
|
||||
- name: "Personalentwicklung"
|
||||
beziehung: "Qualifizierungskoordination"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design"
|
||||
- "Community-Event-Planung und Ressourcen-Allokation"
|
||||
- "Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung"
|
||||
- "Key-User-Performance-Bewertung und Entwicklungsempfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Community-Building und Netzwerk-Management für diverse organisatorische Kontexte"
|
||||
- "Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung"
|
||||
- "Content-Management für digitale Wissensplattformen"
|
||||
- "Motivations- und Engagement-Management für freiwillige Communities"
|
||||
- "Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung"
|
||||
|
|
|
|||
|
|
@ -1,59 +1,59 @@
|
|||
# =============================================================================
|
||||
# ROLLE: KEY-USER (KU)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R7-KU"
|
||||
rolle_name: "Key-User"
|
||||
kurzform: "KU"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Formale Rolle in den Fachbereichen/Abteilungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Dezentrale PM-Kompetenz und Change-Agenten in den Fachbereichen/Abteilungen
|
||||
zur lokalen Prozessexpertise und Schnittstelle zur zentralen PM-Funktion.
|
||||
|
||||
kernaufgaben:
|
||||
- "Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im eigenen Fachbereich/Abteilung"
|
||||
- "Lokale Prozessexpertise und Unterstützung der Kollegen bei Prozessarbeit"
|
||||
- "Schnittstelle zwischen Fachbereichen/Abteilungen und zentraler PM-Funktion"
|
||||
- "Modellierung spezifischer (Fach-)Prozesse"
|
||||
- "Implementierung von Framework-Updates und Prozessänderungen im Fachbereich"
|
||||
- "Identifikation lokaler Optimierungspotenziale und Weiterleitung an PM-Funktion"
|
||||
- "Multiplikator für Prozess-Know-how und Best Practices"
|
||||
|
||||
stakeholder:
|
||||
- name: "Kolleg:innen im eigenen Fachbereich/Abteilung"
|
||||
beziehung: "Direkte Unterstützung"
|
||||
- name: "Key-User-Netzwerk-Manager:in"
|
||||
beziehung: "Qualifizierung und Community"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Bei komplexeren Herausforderungen"
|
||||
- name: "Fachbereichs-/Abteilungsleitung"
|
||||
beziehung: "Lokale PM-Vertretung"
|
||||
- name: "Andere Key-User"
|
||||
beziehung: "Erfahrungsaustausch und Peer-Learning"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Erste Bewertung und Priorisierung lokaler Prozess-Anfragen"
|
||||
- "Methodische Empfehlungen für Standardsituationen im Rahmen des Frameworks"
|
||||
- "Weiterleitung komplexerer Fälle an zentrale PM-Funktion"
|
||||
- "Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner"
|
||||
|
||||
kompetenzen:
|
||||
- "Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden"
|
||||
- "Beratungs- und Unterstützungskompetenz für Kolleg:innen"
|
||||
- "Fachbereichs-spezifisches Prozess-Know-how"
|
||||
- "Netzwerk- und Community-Fähigkeiten"
|
||||
- "Change-Agent-Qualitäten für lokale Prozessverbesserungen"
|
||||
# =============================================================================
|
||||
# ROLLE: KEY-USER (KU)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R7-KU"
|
||||
rolle_name: "Key-User"
|
||||
kurzform: "KU"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Formale Rolle in den Fachbereichen/Abteilungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Dezentrale PM-Kompetenz und Change-Agenten in den Fachbereichen/Abteilungen
|
||||
zur lokalen Prozessexpertise und Schnittstelle zur zentralen PM-Funktion.
|
||||
|
||||
kernaufgaben:
|
||||
- "Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im eigenen Fachbereich/Abteilung"
|
||||
- "Lokale Prozessexpertise und Unterstützung der Kollegen bei Prozessarbeit"
|
||||
- "Schnittstelle zwischen Fachbereichen/Abteilungen und zentraler PM-Funktion"
|
||||
- "Modellierung spezifischer (Fach-)Prozesse"
|
||||
- "Implementierung von Framework-Updates und Prozessänderungen im Fachbereich"
|
||||
- "Identifikation lokaler Optimierungspotenziale und Weiterleitung an PM-Funktion"
|
||||
- "Multiplikator für Prozess-Know-how und Best Practices"
|
||||
|
||||
stakeholder:
|
||||
- name: "Kolleg:innen im eigenen Fachbereich/Abteilung"
|
||||
beziehung: "Direkte Unterstützung"
|
||||
- name: "Key-User-Netzwerk-Manager:in"
|
||||
beziehung: "Qualifizierung und Community"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Bei komplexeren Herausforderungen"
|
||||
- name: "Fachbereichs-/Abteilungsleitung"
|
||||
beziehung: "Lokale PM-Vertretung"
|
||||
- name: "Andere Key-User"
|
||||
beziehung: "Erfahrungsaustausch und Peer-Learning"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Erste Bewertung und Priorisierung lokaler Prozess-Anfragen"
|
||||
- "Methodische Empfehlungen für Standardsituationen im Rahmen des Frameworks"
|
||||
- "Weiterleitung komplexerer Fälle an zentrale PM-Funktion"
|
||||
- "Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner"
|
||||
|
||||
kompetenzen:
|
||||
- "Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden"
|
||||
- "Beratungs- und Unterstützungskompetenz für Kolleg:innen"
|
||||
- "Fachbereichs-spezifisches Prozess-Know-how"
|
||||
- "Netzwerk- und Community-Fähigkeiten"
|
||||
- "Change-Agent-Qualitäten für lokale Prozessverbesserungen"
|
||||
|
|
|
|||
|
|
@ -1,61 +1,61 @@
|
|||
# =============================================================================
|
||||
# ROLLE: LEITER*IN PROZESS-MANAGEMENT (LPM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R1-LPM"
|
||||
rolle_name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische Führung und operative Steuerung der gesamten PM-Funktion
|
||||
zur Sicherstellung der Wertschöpfung für DIGITOM.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und organisationalen Bedarfen"
|
||||
- "Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Perspektive (z.B. neue Funktionen, Rollenanpassungen, Governance-Strukturen)"
|
||||
- "Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB, KNM)"
|
||||
- "Stakeholder-Management zu Gremien und Fachbereichen/Abteilungen"
|
||||
- "Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der PM-Funktion"
|
||||
- "Eskalationsmanagement bei strategischen Konflikten oder Ressourcenengpässen"
|
||||
- "Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei kritischen Fällen Eskalation ans Mission Board"
|
||||
- "Berichterstattung an Vision Board über PM-Performance und strategische Entwicklungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Vision Board"
|
||||
beziehung: "Auftraggeber und strategische Abstimmung"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Abstimmung"
|
||||
- name: "Interne PM-Rollen"
|
||||
beziehung: "Führung und Koordination"
|
||||
- name: "Abteilungsleitungen"
|
||||
beziehung: "Strategische PM-Partnerschaften"
|
||||
- name: "Amtsleitung DIGIT"
|
||||
beziehung: "Organisatorische Einbindung"
|
||||
- name: "Externe Berater und Dienstleister"
|
||||
beziehung: "Strategische Partnerschaften"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei kritischen Entscheidungen in Konsultation mit Mission Board)"
|
||||
- "Personalentscheidungen für PM-Team (Einstellung, Entwicklung, Zielsetzung)"
|
||||
- "Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung"
|
||||
- "Eskalation an Mission Board bei konkurrierenden Prioritäten"
|
||||
- "PM-Framework-Freigaben nach PFM-Vorschlägen"
|
||||
|
||||
kompetenzen:
|
||||
- "Führungskompetenz für interdisziplinäre Teams mit verschiedenen Expertisen"
|
||||
- "Strategisches Stakeholder-Management und politische Sensibilität in der Verwaltung"
|
||||
- "Verständnis für das DIGITOM und das PM-Framework sowie organisationale Transformationen"
|
||||
- "Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen Fachbereichen/Abteilungen"
|
||||
- "Change Management für komplexe organisatorische Veränderungen"
|
||||
# =============================================================================
|
||||
# ROLLE: LEITER*IN PROZESS-MANAGEMENT (LPM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R1-LPM"
|
||||
rolle_name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische Führung und operative Steuerung der gesamten PM-Funktion
|
||||
zur Sicherstellung der Wertschöpfung für DIGITOM.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und organisationalen Bedarfen"
|
||||
- "Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Perspektive (z.B. neue Funktionen, Rollenanpassungen, Governance-Strukturen)"
|
||||
- "Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB, KNM)"
|
||||
- "Stakeholder-Management zu Gremien und Fachbereichen/Abteilungen"
|
||||
- "Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der PM-Funktion"
|
||||
- "Eskalationsmanagement bei strategischen Konflikten oder Ressourcenengpässen"
|
||||
- "Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei kritischen Fällen Eskalation ans Mission Board"
|
||||
- "Berichterstattung an Vision Board über PM-Performance und strategische Entwicklungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Vision Board"
|
||||
beziehung: "Auftraggeber und strategische Abstimmung"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Abstimmung"
|
||||
- name: "Interne PM-Rollen"
|
||||
beziehung: "Führung und Koordination"
|
||||
- name: "Abteilungsleitungen"
|
||||
beziehung: "Strategische PM-Partnerschaften"
|
||||
- name: "Amtsleitung DIGIT"
|
||||
beziehung: "Organisatorische Einbindung"
|
||||
- name: "Externe Berater und Dienstleister"
|
||||
beziehung: "Strategische Partnerschaften"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei kritischen Entscheidungen in Konsultation mit Mission Board)"
|
||||
- "Personalentscheidungen für PM-Team (Einstellung, Entwicklung, Zielsetzung)"
|
||||
- "Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung"
|
||||
- "Eskalation an Mission Board bei konkurrierenden Prioritäten"
|
||||
- "PM-Framework-Freigaben nach PFM-Vorschlägen"
|
||||
|
||||
kompetenzen:
|
||||
- "Führungskompetenz für interdisziplinäre Teams mit verschiedenen Expertisen"
|
||||
- "Strategisches Stakeholder-Management und politische Sensibilität in der Verwaltung"
|
||||
- "Verständnis für das DIGITOM und das PM-Framework sowie organisationale Transformationen"
|
||||
- "Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen Fachbereichen/Abteilungen"
|
||||
- "Change Management für komplexe organisatorische Veränderungen"
|
||||
|
|
|
|||
|
|
@ -1,80 +1,80 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROCESS OWNER (PO)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R6-PO"
|
||||
rolle_name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: |
|
||||
Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager (DPM),
|
||||
Projekt Portfolio Manager (PPM), Service Portfolio Manager (SPM)
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
End-to-End-Verantwortung für spezifische Teilprozess-Prozesse zur
|
||||
Sicherstellung von Prozess-Performance, Qualität und kontinuierlicher Optimierung.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Verantwortung für Performance und Qualität der zugeordneten End-to-End-Prozesse"
|
||||
- "Definition prozessspezifischer KPIs auf Basis zentral vorgegebener KPI-Kategorien und Standards"
|
||||
- "Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen"
|
||||
- "Koordination prozessbezogener Optimierungsinitiativen zwischen beteiligten Bereichen"
|
||||
- "Eskalationsmanagement bei prozessrelevanten Problemen oder Ressourcenkonflikten"
|
||||
- "Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen Änderungen"
|
||||
- "Sicherstellung der Framework-Compliance in den verantworteten Prozessen"
|
||||
|
||||
# =============================================================================
|
||||
# PROCESS OWNER-ZUORDNUNG
|
||||
# =============================================================================
|
||||
|
||||
spezifische_zuordnung:
|
||||
- funktion: "SHM"
|
||||
name: "Stakeholder-Management"
|
||||
prozess: "Bedarfserfassung und -qualifizierung"
|
||||
|
||||
- funktion: "DPM"
|
||||
name: "Demand-Portfolio-Management"
|
||||
prozess: "Demand-Bewertung und Demand-Portfolio-Steuerung"
|
||||
|
||||
- funktion: "PPM"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
prozess: "Projektsteuerung und -überwachung"
|
||||
|
||||
- funktion: "SPM"
|
||||
name: "Service-Portfolio-Management"
|
||||
prozess: "Service-Integration und Betriebsüberführung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Methodische Unterstützung und Framework-Compliance"
|
||||
- name: "Beteiligte Fachbereiche/Abteilungen"
|
||||
beziehung: "Im jeweiligen End-to-End-Prozess"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Performance-Reporting und strategische Abstimmung"
|
||||
- name: "Key-User"
|
||||
beziehung: "In den prozessrelevanten Bereichen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks"
|
||||
- "Ressourcen-Anfrage/Priorisierung für prozessbezogene Optimierungsmaßnahmen"
|
||||
- "Eskalations-Entscheidungen bei prozessübergreifenden Konflikten"
|
||||
- "KPI-Definition und Performance-Ziele für die verantworteten Prozesse"
|
||||
- "Abnahme-Entscheidungen für Prozessänderungen"
|
||||
|
||||
kompetenzen:
|
||||
- "End-to-End-Prozess-Verständnis mit systemischer Sichtweise"
|
||||
- "Performance-Management mit KPI-Entwicklung und -monitoring"
|
||||
- "Cross-funktionale Koordination zwischen verschiedenen Bereichen"
|
||||
- "Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis"
|
||||
# =============================================================================
|
||||
# ROLLE: PROCESS OWNER (PO)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R6-PO"
|
||||
rolle_name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: |
|
||||
Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager (DPM),
|
||||
Projekt Portfolio Manager (PPM), Service Portfolio Manager (SPM)
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
End-to-End-Verantwortung für spezifische Teilprozess-Prozesse zur
|
||||
Sicherstellung von Prozess-Performance, Qualität und kontinuierlicher Optimierung.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Verantwortung für Performance und Qualität der zugeordneten End-to-End-Prozesse"
|
||||
- "Definition prozessspezifischer KPIs auf Basis zentral vorgegebener KPI-Kategorien und Standards"
|
||||
- "Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen"
|
||||
- "Koordination prozessbezogener Optimierungsinitiativen zwischen beteiligten Bereichen"
|
||||
- "Eskalationsmanagement bei prozessrelevanten Problemen oder Ressourcenkonflikten"
|
||||
- "Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen Änderungen"
|
||||
- "Sicherstellung der Framework-Compliance in den verantworteten Prozessen"
|
||||
|
||||
# =============================================================================
|
||||
# PROCESS OWNER-ZUORDNUNG
|
||||
# =============================================================================
|
||||
|
||||
spezifische_zuordnung:
|
||||
- funktion: "SHM"
|
||||
name: "Stakeholder-Management"
|
||||
prozess: "Bedarfserfassung und -qualifizierung"
|
||||
|
||||
- funktion: "DPM"
|
||||
name: "Demand-Portfolio-Management"
|
||||
prozess: "Demand-Bewertung und Demand-Portfolio-Steuerung"
|
||||
|
||||
- funktion: "PPM"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
prozess: "Projektsteuerung und -überwachung"
|
||||
|
||||
- funktion: "SPM"
|
||||
name: "Service-Portfolio-Management"
|
||||
prozess: "Service-Integration und Betriebsüberführung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Methodische Unterstützung und Framework-Compliance"
|
||||
- name: "Beteiligte Fachbereiche/Abteilungen"
|
||||
beziehung: "Im jeweiligen End-to-End-Prozess"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Performance-Reporting und strategische Abstimmung"
|
||||
- name: "Key-User"
|
||||
beziehung: "In den prozessrelevanten Bereichen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks"
|
||||
- "Ressourcen-Anfrage/Priorisierung für prozessbezogene Optimierungsmaßnahmen"
|
||||
- "Eskalations-Entscheidungen bei prozessübergreifenden Konflikten"
|
||||
- "KPI-Definition und Performance-Ziele für die verantworteten Prozesse"
|
||||
- "Abnahme-Entscheidungen für Prozessänderungen"
|
||||
|
||||
kompetenzen:
|
||||
- "End-to-End-Prozess-Verständnis mit systemischer Sichtweise"
|
||||
- "Performance-Management mit KPI-Entwicklung und -monitoring"
|
||||
- "Cross-funktionale Koordination zwischen verschiedenen Bereichen"
|
||||
- "Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis"
|
||||
|
|
|
|||
|
|
@ -1,57 +1,57 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESS-BERATER*IN (PB)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R4-PB"
|
||||
rolle_name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Direkte, vertrauensvolle methodische Unterstützung der Fachbereiche/Abteilungen
|
||||
bei Prozessanalyse, -gestaltung und -optimierung zur Befähigung für
|
||||
eigenständige Prozessarbeit.
|
||||
|
||||
kernaufgaben:
|
||||
- "Individuelle Beratung und Coaching von Fachbereichen/Abteilungen bei konkreten Prozess-Herausforderungen"
|
||||
- "Moderation von Prozess-Workshops für kollaborative Analyse und Optimierung in definierten Fällen"
|
||||
- "Methodische Unterstützung bei Prozessmodellierung und -dokumentation"
|
||||
- "Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl. Erstbewertung von Anfragen über das Ticketsystem)"
|
||||
- "Identifikation von Optimierungspotenzialen durch Prozess-Assessments"
|
||||
- "Begleitende Umsetzungsunterstützung bei Prozessänderungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Fachbereiche/Abteilungen und deren Teams"
|
||||
beziehung: "Direkte Beratung und Coaching"
|
||||
- name: "Key-User"
|
||||
beziehung: "Operative Zusammenarbeit und Befähigung"
|
||||
- name: "Projektteams"
|
||||
beziehung: "Prozessbezogene Projektunterstützung"
|
||||
- name: "Auftraggeber PM"
|
||||
beziehung: "Bedarfsklärung und Erwartungsmanagement"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Methodische Unterstützung bei End-to-End-Optimierungen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Methodische Empfehlungen im Rahmen des gültigen Frameworks"
|
||||
- "Workshop-Design und Moderations-Ansätze für spezifische Situationen"
|
||||
- "Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen"
|
||||
- "Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven Problemen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessberatungs-Expertise mit breitem Methoden-Portfolio"
|
||||
- "Workshop-Moderation und Facilitierung für diverse Stakeholder-Konstellationen"
|
||||
- "Change Management-Fähigkeiten für begleitende Prozessveränderungen"
|
||||
- "Empathie und Beziehungsaufbau für vertrauensvolle Beratungspartnerschaften"
|
||||
- "Problemlösungs-Kompetenz für komplexe organisatorische Herausforderungen"
|
||||
# =============================================================================
|
||||
# ROLLE: PROZESS-BERATER*IN (PB)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R4-PB"
|
||||
rolle_name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Direkte, vertrauensvolle methodische Unterstützung der Fachbereiche/Abteilungen
|
||||
bei Prozessanalyse, -gestaltung und -optimierung zur Befähigung für
|
||||
eigenständige Prozessarbeit.
|
||||
|
||||
kernaufgaben:
|
||||
- "Individuelle Beratung und Coaching von Fachbereichen/Abteilungen bei konkreten Prozess-Herausforderungen"
|
||||
- "Moderation von Prozess-Workshops für kollaborative Analyse und Optimierung in definierten Fällen"
|
||||
- "Methodische Unterstützung bei Prozessmodellierung und -dokumentation"
|
||||
- "Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl. Erstbewertung von Anfragen über das Ticketsystem)"
|
||||
- "Identifikation von Optimierungspotenzialen durch Prozess-Assessments"
|
||||
- "Begleitende Umsetzungsunterstützung bei Prozessänderungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Fachbereiche/Abteilungen und deren Teams"
|
||||
beziehung: "Direkte Beratung und Coaching"
|
||||
- name: "Key-User"
|
||||
beziehung: "Operative Zusammenarbeit und Befähigung"
|
||||
- name: "Projektteams"
|
||||
beziehung: "Prozessbezogene Projektunterstützung"
|
||||
- name: "Auftraggeber PM"
|
||||
beziehung: "Bedarfsklärung und Erwartungsmanagement"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Methodische Unterstützung bei End-to-End-Optimierungen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Methodische Empfehlungen im Rahmen des gültigen Frameworks"
|
||||
- "Workshop-Design und Moderations-Ansätze für spezifische Situationen"
|
||||
- "Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen"
|
||||
- "Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven Problemen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessberatungs-Expertise mit breitem Methoden-Portfolio"
|
||||
- "Workshop-Moderation und Facilitierung für diverse Stakeholder-Konstellationen"
|
||||
- "Change Management-Fähigkeiten für begleitende Prozessveränderungen"
|
||||
- "Empathie und Beziehungsaufbau für vertrauensvolle Beratungspartnerschaften"
|
||||
- "Problemlösungs-Kompetenz für komplexe organisatorische Herausforderungen"
|
||||
|
|
|
|||
|
|
@ -1,64 +1,64 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESS-FRAMEWORK-MANAGER*IN (PFM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R2-PFM"
|
||||
rolle_name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Entwicklung und Pflege eines einheitlichen, zukunftsfähigen PM-Frameworks,
|
||||
das DIGITOM-weit als methodische Grundlage für qualitativ hochwertige
|
||||
Prozessarbeit dient.
|
||||
|
||||
kernaufgaben:
|
||||
- "Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des verbindlichen PM-Frameworks (Standards, Methoden, Tools, Governance-Regeln)"
|
||||
- "Entwicklung und Pflege eines zentralen KPI-Frameworks mit standardisierten Messkategorien, Berechnungsmethoden und Reporting-Standards"
|
||||
- "Analyse externer Best Practices, Standards und gesetzlicher Anforderungen für Integration ins PM-Framework"
|
||||
- "PM-Framework-Kommunikation und Change Management bei größeren Methodenänderungen"
|
||||
- "Qualitätssicherung des PM-Frameworks durch systematisches Feedback-Management"
|
||||
- "Entwicklung von PM-Framework-Schulungskonzepten und Zertifizierungsstandards"
|
||||
- "Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Sicht"
|
||||
- "Harmonisierung des PM-Frameworks mit dem Service Management Framework"
|
||||
- "Identifikation geeigneter Methoden und technischer Ansätze zur Digitalisierung und (Teil-)Automatisierung von Prozessen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Strategische Abstimmung und Freigaben"
|
||||
- name: "Alle internen PM-Rollen"
|
||||
beziehung: "Framework-Anwendung und Feedback"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Technische Machbarkeit und Systemintegration"
|
||||
- name: "ISB/Datenschutz"
|
||||
beziehung: "Compliance-Anforderungen"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Framework-Implementierung in spezifischen Prozessen"
|
||||
- name: "Externe Standards-Organisationen und Beratungsunternehmen"
|
||||
beziehung: "Best Practices und Standards"
|
||||
- name: "Zentrales GPM (HPA)"
|
||||
beziehung: "Übergeordnete Abstimmung"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben"
|
||||
- "Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen"
|
||||
- "Methodische Standards für einheitliche Prozessarbeit in DIGITOM"
|
||||
- "PM-Framework-Update-Prioritäten basierend auf organisationalen Bedarfen"
|
||||
|
||||
kompetenzen:
|
||||
- "Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design Thinking)"
|
||||
- "Technisches Verständnis für digitale Prozess-Tools und Plattform-Architekturen"
|
||||
- "Systemisches Denken für komplexe organisatorische Zusammenhänge"
|
||||
- "Didaktische Fähigkeiten für Framework-Kommunikation und Wissensvermittlung"
|
||||
- "Analytische Fähigkeiten für Technologie-Assessment und Standards-Evaluierung"
|
||||
# =============================================================================
|
||||
# ROLLE: PROZESS-FRAMEWORK-MANAGER*IN (PFM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R2-PFM"
|
||||
rolle_name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Entwicklung und Pflege eines einheitlichen, zukunftsfähigen PM-Frameworks,
|
||||
das DIGITOM-weit als methodische Grundlage für qualitativ hochwertige
|
||||
Prozessarbeit dient.
|
||||
|
||||
kernaufgaben:
|
||||
- "Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des verbindlichen PM-Frameworks (Standards, Methoden, Tools, Governance-Regeln)"
|
||||
- "Entwicklung und Pflege eines zentralen KPI-Frameworks mit standardisierten Messkategorien, Berechnungsmethoden und Reporting-Standards"
|
||||
- "Analyse externer Best Practices, Standards und gesetzlicher Anforderungen für Integration ins PM-Framework"
|
||||
- "PM-Framework-Kommunikation und Change Management bei größeren Methodenänderungen"
|
||||
- "Qualitätssicherung des PM-Frameworks durch systematisches Feedback-Management"
|
||||
- "Entwicklung von PM-Framework-Schulungskonzepten und Zertifizierungsstandards"
|
||||
- "Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Sicht"
|
||||
- "Harmonisierung des PM-Frameworks mit dem Service Management Framework"
|
||||
- "Identifikation geeigneter Methoden und technischer Ansätze zur Digitalisierung und (Teil-)Automatisierung von Prozessen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Strategische Abstimmung und Freigaben"
|
||||
- name: "Alle internen PM-Rollen"
|
||||
beziehung: "Framework-Anwendung und Feedback"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Technische Machbarkeit und Systemintegration"
|
||||
- name: "ISB/Datenschutz"
|
||||
beziehung: "Compliance-Anforderungen"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Framework-Implementierung in spezifischen Prozessen"
|
||||
- name: "Externe Standards-Organisationen und Beratungsunternehmen"
|
||||
beziehung: "Best Practices und Standards"
|
||||
- name: "Zentrales GPM (HPA)"
|
||||
beziehung: "Übergeordnete Abstimmung"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben"
|
||||
- "Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen"
|
||||
- "Methodische Standards für einheitliche Prozessarbeit in DIGITOM"
|
||||
- "PM-Framework-Update-Prioritäten basierend auf organisationalen Bedarfen"
|
||||
|
||||
kompetenzen:
|
||||
- "Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design Thinking)"
|
||||
- "Technisches Verständnis für digitale Prozess-Tools und Plattform-Architekturen"
|
||||
- "Systemisches Denken für komplexe organisatorische Zusammenhänge"
|
||||
- "Didaktische Fähigkeiten für Framework-Kommunikation und Wissensvermittlung"
|
||||
- "Analytische Fähigkeiten für Technologie-Assessment und Standards-Evaluierung"
|
||||
|
|
|
|||
|
|
@ -1,65 +1,65 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESSLANDSCHAFTS-KOORDINATOR*IN (PLK)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R3-PLK"
|
||||
rolle_name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Operative Governance und Transparenz der DIGITOM-Prozesslandschaft zur
|
||||
Sicherstellung von Framework-Compliance und End-to-End-Prozessqualität.
|
||||
|
||||
kernaufgaben:
|
||||
- "Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen Prozessregisters"
|
||||
- "Monitoring von Framework-Compliance und Identifikation von PM-Governance-Lücken"
|
||||
- "Koordination prozessübergreifender Initiativen zwischen verschiedenen Process Ownern"
|
||||
- "PM-Governance-Reporting für Gremien mit Prozess-KPIs und Compliance-Status"
|
||||
- "Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen"
|
||||
- "Risiko-Assessment für Prozesslandschaft und frühzeitige Problemerkennung"
|
||||
- "Schnittstellen-Governance: Moderation von Schnittstellen-Vereinbarungen zwischen Process Ownern und Konfliktlösung bei schnittstellenübergreifenden Problemen"
|
||||
|
||||
pm_governance_luecken_management:
|
||||
beschreibung: "Systematisches Management von PM-Governance-Lücken"
|
||||
aufgaben:
|
||||
- "Systematische Identifikation von PM-Governance-Lücken im DIGIT/DIGITOM"
|
||||
- "Abstimmung mit Prozessberater:innen für Lösungsansätze"
|
||||
- "Bei kurzfristiger Lösung: Dokumentation und Monitoring"
|
||||
- "Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans Mission Board"
|
||||
|
||||
stakeholder:
|
||||
- name: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beziehung: "End-to-End-Prozess-Koordination"
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Governance-Reporting und Eskalationen"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Governance-Entscheidungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Compliance-Unterstützung und Konfliktlösung"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Systemische Prozess-Dependencies"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Governance-Compliance-Bewertungen und Abweichungsmanagement"
|
||||
- "Prozessregister-Updates und Dokumentationsstandards"
|
||||
- "Eskalations-Empfehlungen bei systematischen Governance-Problemen"
|
||||
- "Priorisierung von prozessübergreifenden Optimierungsmaßnahmen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften"
|
||||
- "Governance-Kompetenz mit Verständnis für Compliance und Risikomanagement"
|
||||
- "Diplomatische Fähigkeiten für Konfliktmediation zwischen Fachbereichen/Abteilungen"
|
||||
- "Analytische Fähigkeiten für KPI-Entwicklung und Performance-Measurement"
|
||||
- "Kommunikationsstärke für verständliches Governance-Reporting"
|
||||
# =============================================================================
|
||||
# ROLLE: PROZESSLANDSCHAFTS-KOORDINATOR*IN (PLK)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R3-PLK"
|
||||
rolle_name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Operative Governance und Transparenz der DIGITOM-Prozesslandschaft zur
|
||||
Sicherstellung von Framework-Compliance und End-to-End-Prozessqualität.
|
||||
|
||||
kernaufgaben:
|
||||
- "Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen Prozessregisters"
|
||||
- "Monitoring von Framework-Compliance und Identifikation von PM-Governance-Lücken"
|
||||
- "Koordination prozessübergreifender Initiativen zwischen verschiedenen Process Ownern"
|
||||
- "PM-Governance-Reporting für Gremien mit Prozess-KPIs und Compliance-Status"
|
||||
- "Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen"
|
||||
- "Risiko-Assessment für Prozesslandschaft und frühzeitige Problemerkennung"
|
||||
- "Schnittstellen-Governance: Moderation von Schnittstellen-Vereinbarungen zwischen Process Ownern und Konfliktlösung bei schnittstellenübergreifenden Problemen"
|
||||
|
||||
pm_governance_luecken_management:
|
||||
beschreibung: "Systematisches Management von PM-Governance-Lücken"
|
||||
aufgaben:
|
||||
- "Systematische Identifikation von PM-Governance-Lücken im DIGIT/DIGITOM"
|
||||
- "Abstimmung mit Prozessberater:innen für Lösungsansätze"
|
||||
- "Bei kurzfristiger Lösung: Dokumentation und Monitoring"
|
||||
- "Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans Mission Board"
|
||||
|
||||
stakeholder:
|
||||
- name: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beziehung: "End-to-End-Prozess-Koordination"
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Governance-Reporting und Eskalationen"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Governance-Entscheidungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Compliance-Unterstützung und Konfliktlösung"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Systemische Prozess-Dependencies"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Governance-Compliance-Bewertungen und Abweichungsmanagement"
|
||||
- "Prozessregister-Updates und Dokumentationsstandards"
|
||||
- "Eskalations-Empfehlungen bei systematischen Governance-Problemen"
|
||||
- "Priorisierung von prozessübergreifenden Optimierungsmaßnahmen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften"
|
||||
- "Governance-Kompetenz mit Verständnis für Compliance und Risikomanagement"
|
||||
- "Diplomatische Fähigkeiten für Konfliktmediation zwischen Fachbereichen/Abteilungen"
|
||||
- "Analytische Fähigkeiten für KPI-Entwicklung und Performance-Measurement"
|
||||
- "Kommunikationsstärke für verständliches Governance-Reporting"
|
||||
|
|
|
|||
|
|
@ -1,353 +1,353 @@
|
|||
# =============================================================================
|
||||
# PROZESS-MANAGEMENT: EXECUTIVE SUMMARY / ÜBERSICHT
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "executive_summary"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#00 - Prozess-Management.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. STRATEGISCHER KONTEXT UND KERNKONZEPT
|
||||
# =============================================================================
|
||||
|
||||
strategischer_kontext:
|
||||
titel: "Strategischer Kontext und Kernkonzept"
|
||||
|
||||
organisationale_herausforderung:
|
||||
titel: "Die organisationale Herausforderung"
|
||||
beschreibung: |
|
||||
Das DIGITOM steht vor einem typischen Widerspruch in modernen
|
||||
Verwaltungen: Es braucht einheitliche Standards für Effektivität und
|
||||
Vergleichbarkeit - gleichzeitig müssen Fachbereiche flexibel auf ihre
|
||||
spezifischen Anforderungen reagieren können.
|
||||
|
||||
ausgangslage:
|
||||
- "Fragmentierte Abläufe"
|
||||
- "Methodische Vielfalt ohne gemeinsame Basis"
|
||||
- "Silos statt Integration"
|
||||
|
||||
konsequenzen:
|
||||
- "Operative Reibungsverluste"
|
||||
- "Verhinderte strategische Weiterentwicklung"
|
||||
- "Ungenutzte Digitalisierungs- und Automatisierungspotenziale"
|
||||
- "Fehlender strukturierter Überblick und notwendige Befähigungen"
|
||||
- "Lokale Optimierungen ohne systemische Wirkung"
|
||||
|
||||
loesungskonzept:
|
||||
titel: "Ein neuer Weg zwischen Kontrolle und Autonomie"
|
||||
beschreibung: |
|
||||
Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung
|
||||
und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn
|
||||
produktiv.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Zentrale Methodenkompetenz trifft dezentrale Umsetzung"
|
||||
beschreibung: |
|
||||
Die PM-Funktion definiert den Rahmen durch einheitliche Standards,
|
||||
Methoden und Werkzeuge. Innerhalb dieses Rahmens gestalten die
|
||||
Fachbereiche ihre Prozesse aktiv und tragen somit die Verantwortung dafür.
|
||||
|
||||
- prinzip: "Befähigung statt Kontrolle"
|
||||
beschreibung: |
|
||||
Die Funktion versteht sich als Ermöglicher, nicht als Wächter.
|
||||
Sie schafft Kompetenzen vor Ort durch ein Netzwerk von "Key-User",
|
||||
die als Multiplikator:innen in ihren Bereichen wirken.
|
||||
|
||||
- prinzip: "Nutzenorientierung statt Strukturfixierung"
|
||||
beschreibung: |
|
||||
Ausgangspunkt sind nicht interne Logiken, sondern die Bedarfe der
|
||||
internen Kund:innen - von strategischen Gremien bis zu operativen Teams.
|
||||
|
||||
erwarteter_mehrwert:
|
||||
titel: "Der erwartete Mehrwert"
|
||||
|
||||
fuer_strategische_entscheider:
|
||||
zielgruppe: "Strategische Entscheider:innen"
|
||||
mehrwert:
|
||||
- "Erstmals Transparenz über die gesamte Prozesslandschaft"
|
||||
- "Ermöglichte strategische Gestaltung"
|
||||
- "Frühzeitige Sichtbarkeit von Risiken"
|
||||
- "Systematische Erschließung von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
|
||||
fuer_operative_teams:
|
||||
zielgruppe: "Operative Teams"
|
||||
mehrwert:
|
||||
- "Methodische Unterstützung genau dann, wenn sie benötigt wird"
|
||||
- "Von schneller Beratung bis zur Begleitung komplexer Transformationen"
|
||||
- "Einheitliche Standards für bereichsübergreifende Zusammenarbeit"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
zielgruppe: "Gesamtorganisation"
|
||||
mehrwert:
|
||||
- "Anpassungsfähigkeit ohne Kontrollverlust"
|
||||
- "Kontinuierliche Prozessverbesserung statt nur Dokumentation"
|
||||
- "Systematische Identifikation von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
- "Adressierung von Fachkräftemangel und steigenden Anforderungen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. ORGANISATIONSDESIGN UND GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
organisationsdesign:
|
||||
titel: "Organisationsdesign und Governance"
|
||||
|
||||
architektur:
|
||||
titel: "Eine Architektur der produktiven Spannung"
|
||||
prinzip: |
|
||||
Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung.
|
||||
Methodische Beratung und operative Governance liegen in unterschiedlichen
|
||||
Händen - so entsteht Vertrauen statt Kontrollangst.
|
||||
|
||||
zentrale_rollen:
|
||||
beschreibung: |
|
||||
Fünf zentrale Rollen im PM-Team decken das Spektrum von strategischer
|
||||
Führung über Methodenentwicklung bis zur operativen Beratung ab.
|
||||
Jede Rolle hat klare Verantwortlichkeiten, Überschneidungen werden vermieden.
|
||||
rollen:
|
||||
- "Leiter*in Prozess-Management"
|
||||
- "Prozess-Framework-Manager*in (PFM)"
|
||||
- "Prozesslandschafts-Koordinator*in (PLK)"
|
||||
- "Prozess-Berater*in (PB)"
|
||||
- "Key-User-Netzwerk-Manager*in (KNM)"
|
||||
|
||||
process_owner:
|
||||
beschreibung: |
|
||||
Process Owner in den Hauptprozessen tragen horizontale und vertikale
|
||||
End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren
|
||||
bereichsübergreifend und sichern Prozessqualität.
|
||||
hauptprozesse:
|
||||
- "Stakeholder-Management"
|
||||
- "Demand-Management"
|
||||
- "Projekt-Management"
|
||||
- "Service-Management"
|
||||
|
||||
key_user:
|
||||
beschreibung: |
|
||||
Key-User werden in allen Fachbereichen identifiziert und zu lokalen
|
||||
Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle vor Ort
|
||||
und Bindeglied zur zentralen PM-Funktion.
|
||||
|
||||
governance:
|
||||
titel: "Governance: So viel wie nötig, so wenig wie möglich"
|
||||
prinzip: "Subsidiaritätsprinzip"
|
||||
|
||||
entscheidungskategorien:
|
||||
- kategorie: "Operative Anpassungen"
|
||||
entscheidungsträger: "PM-Team eigenständig"
|
||||
beispiele:
|
||||
- "Tool-Konfigurationen"
|
||||
- "Template-Updates"
|
||||
- "Schulungsinhalte"
|
||||
|
||||
- kategorie: "Prozessspezifische Anpassungen"
|
||||
entscheidungsträger: "Abstimmung mit jeweiligem Process Owner"
|
||||
beispiele:
|
||||
- "Änderungen an Prozessschnittstellen"
|
||||
- "Neue Metriken für spezifische Prozesse"
|
||||
- "Integration neuer Systeme in bestehende Prozesse"
|
||||
|
||||
- kategorie: "PM-Framework-Weiterentwicklungen"
|
||||
entscheidungsträger: "PM-Team eigenständig (Information an Process Owner)"
|
||||
beispiele:
|
||||
- "Neue Modellierungsstandards"
|
||||
- "Erweiterte Methodenbausteine"
|
||||
- "Übergreifende Bewertungskriterien"
|
||||
|
||||
- kategorie: "Fundamentale Änderungen"
|
||||
entscheidungsträger: "Steuerungsgremien"
|
||||
beispiele:
|
||||
- "Wechsel der Prozessmodellierungssprache"
|
||||
- "Grundlegende Änderung der PM-Strategie"
|
||||
- "Neuausrichtung der Prozessarchitektur"
|
||||
|
||||
leistungsbeauftragung:
|
||||
- typ: "Standard-Leistungen"
|
||||
zugang: "Niedrigschwellig für alle zugänglich"
|
||||
beispiele:
|
||||
- "Beratung"
|
||||
- "Workshops"
|
||||
|
||||
- typ: "Projekt-Leistungen"
|
||||
zugang: "Mission Board-Freigabe erforderlich"
|
||||
beispiele:
|
||||
- "Größere Transformationen"
|
||||
|
||||
- typ: "Strategische Initiativen"
|
||||
zugang: "Direkte Beauftragung durch Vision Board"
|
||||
|
||||
- typ: "Krisen-Interventionen"
|
||||
zugang: "Jederzeit durch Führungskräfte auslösbar"
|
||||
|
||||
eskalationsmodell:
|
||||
beschreibung: "Dreistufiges Eskalationsmodell sichert schnelle Konfliktlösung"
|
||||
stufen:
|
||||
- stufe: 1
|
||||
typ: "Operative Themen"
|
||||
zeitrahmen: "Binnen 48 Stunden"
|
||||
|
||||
- stufe: 2
|
||||
typ: "Taktische Konflikte"
|
||||
gremium: "Mission Board"
|
||||
zeitrahmen: "Binnen einer Woche"
|
||||
|
||||
- stufe: 3
|
||||
typ: "Strategische Grundsatzfragen"
|
||||
gremium: "Vision Board"
|
||||
zeitrahmen: "Binnen eines Monats"
|
||||
|
||||
integration:
|
||||
titel: "Integration statt Parallelstruktur"
|
||||
beschreibung: |
|
||||
Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance
|
||||
ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien.
|
||||
Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor.
|
||||
|
||||
schluesselpartner:
|
||||
- "Zentrales Geschäftsprozessmanagement (HPA)"
|
||||
- "IT-Architektur"
|
||||
- "Datenschutz"
|
||||
- "Informationssicherheit"
|
||||
|
||||
prinzip: |
|
||||
Systematische Einbindung schafft vernetzte Kompetenz statt neuer Silos.
|
||||
|
||||
# =============================================================================
|
||||
# 3. IMPLEMENTIERUNG UND KRITISCHE ERFOLGSFAKTOREN
|
||||
# =============================================================================
|
||||
|
||||
implementierung:
|
||||
titel: "Implementierung und kritische Erfolgsfaktoren"
|
||||
|
||||
leistungsportfolio:
|
||||
titel: "Konkrete Leistungen, klare Zugänge"
|
||||
orientierung: "Reale Bedarfe"
|
||||
|
||||
leistungsbereiche:
|
||||
- bereich: "Prozess-Framework/DIGITOM-Entwicklung"
|
||||
zweck: "Schafft die methodische Basis"
|
||||
|
||||
- bereich: "Beratung und Coaching"
|
||||
zweck: "Unterstützt bei konkreten Herausforderungen"
|
||||
|
||||
- bereich: "Befähigung und Schulung"
|
||||
zweck: "Baut Kompetenzen dezentral auf"
|
||||
|
||||
- bereich: "Transparenz und Reporting"
|
||||
zweck: "Ermöglicht faktenbasierte Steuerung"
|
||||
|
||||
zugangswege:
|
||||
- "Ticketsystem für direkte Hilfe"
|
||||
- "Strukturierte Beauftragungen für größere Vorhaben"
|
||||
- "Informelle Kanäle über das Key-User-Netzwerk"
|
||||
|
||||
ressourcen:
|
||||
titel: "Ressourcen und Voraussetzungen"
|
||||
|
||||
quantitativ:
|
||||
- "Dediziertes PM-Team mit komplementären Kompetenzen"
|
||||
- "Moderne Prozess-Tools"
|
||||
- "Qualifizierungsbudgets"
|
||||
|
||||
qualitativ:
|
||||
wichtigkeit: "Wichtiger als Ressourcen sind die qualitativen Voraussetzungen"
|
||||
faktoren:
|
||||
- faktor: "Klares Mandat der Führung"
|
||||
wirkung: "Legitimiert die Funktion"
|
||||
|
||||
- faktor: "Bereitschaft der Fachbereiche"
|
||||
wirkung: "Zur aktiven Mitgestaltung"
|
||||
|
||||
- faktor: "Einbindung der Schlüsselpartner"
|
||||
wirkung: "Von Anfang an"
|
||||
|
||||
- faktor: "Verständnis von Prozessmanagement"
|
||||
wirkung: "Als kontinuierliche Entwicklung, nicht als Projekt"
|
||||
|
||||
risikomanagement:
|
||||
titel: "Risiken aktiv managen"
|
||||
|
||||
risiken:
|
||||
- risiko: "Akzeptanzrisiken"
|
||||
mitigationsstrategie: |
|
||||
Konsequente Trennung von Beratung und Kontrolle.
|
||||
Erfolgsgeschichten und Key-User als Botschafter:innen schaffen Vertrauen.
|
||||
|
||||
- risiko: "Ressourcenkonflikte"
|
||||
mitigationsstrategie: |
|
||||
Transparentes Priorisierungsmodell. Strategische Initiativen gehen
|
||||
stets vor, konkurrierende Anfragen werden offen abgewogen.
|
||||
|
||||
- risiko: "Qualitätsrisiken"
|
||||
mitigationsstrategie: |
|
||||
Systematische Einbindung von Compliance-Funktionen und
|
||||
Process Owner als Qualitätsgatekeeper.
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNGEN ZU ANDEREN PM-DOKUMENTEN
|
||||
# =============================================================================
|
||||
|
||||
dokumentverknuepfungen:
|
||||
beschreibung: |
|
||||
Diese Executive Summary gibt einen kompakten Überblick. Die Details
|
||||
finden sich in den spezialisierten Dokumenten der PM-Funktion.
|
||||
|
||||
detaildokumente:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
inhalt: "Formale Grundlagen, Verantwortungsbereiche, Mandat"
|
||||
|
||||
- dokument: "Leistungs-Canvas"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
inhalt: "Detaillierte Leistungen, Nutzersegmente, Wertversprechen"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
inhalt: "Alle 11 Rollen mit Aufgaben, Befugnissen, Schnittstellen"
|
||||
|
||||
- dokument: "Governance-Framework"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
inhalt: "Entscheidungswege, Eskalation, Leitprinzipien"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
inhalt: "Verantwortlichkeitsmatrix für alle Leistungen"
|
||||
|
||||
- dokument: "Konzeptrahmen"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml"
|
||||
inhalt: "Dokumentationsarchitektur und Navigationshilfe"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #00 - Prozess-Management.docx
|
||||
|
||||
Inhalte:
|
||||
- Strategischer Kontext und Kernkonzept
|
||||
- Organisationale Herausforderung
|
||||
- Lösungskonzept (3 Kernprinzipien)
|
||||
- Erwarteter Mehrwert (3 Zielgruppen)
|
||||
- Organisationsdesign (Rollen, Process Owner, Key-User)
|
||||
- Governance (4 Entscheidungskategorien, 4 Leistungstypen, 3 Eskalationsstufen)
|
||||
- Implementierung (Leistungsportfolio, Ressourcen, Risikomanagement)
|
||||
autor: "DIGITOM-Projekt"
|
||||
# =============================================================================
|
||||
# PROZESS-MANAGEMENT: EXECUTIVE SUMMARY / ÜBERSICHT
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "executive_summary"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#00 - Prozess-Management.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. STRATEGISCHER KONTEXT UND KERNKONZEPT
|
||||
# =============================================================================
|
||||
|
||||
strategischer_kontext:
|
||||
titel: "Strategischer Kontext und Kernkonzept"
|
||||
|
||||
organisationale_herausforderung:
|
||||
titel: "Die organisationale Herausforderung"
|
||||
beschreibung: |
|
||||
Das DIGITOM steht vor einem typischen Widerspruch in modernen
|
||||
Verwaltungen: Es braucht einheitliche Standards für Effektivität und
|
||||
Vergleichbarkeit - gleichzeitig müssen Fachbereiche flexibel auf ihre
|
||||
spezifischen Anforderungen reagieren können.
|
||||
|
||||
ausgangslage:
|
||||
- "Fragmentierte Abläufe"
|
||||
- "Methodische Vielfalt ohne gemeinsame Basis"
|
||||
- "Silos statt Integration"
|
||||
|
||||
konsequenzen:
|
||||
- "Operative Reibungsverluste"
|
||||
- "Verhinderte strategische Weiterentwicklung"
|
||||
- "Ungenutzte Digitalisierungs- und Automatisierungspotenziale"
|
||||
- "Fehlender strukturierter Überblick und notwendige Befähigungen"
|
||||
- "Lokale Optimierungen ohne systemische Wirkung"
|
||||
|
||||
loesungskonzept:
|
||||
titel: "Ein neuer Weg zwischen Kontrolle und Autonomie"
|
||||
beschreibung: |
|
||||
Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung
|
||||
und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn
|
||||
produktiv.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Zentrale Methodenkompetenz trifft dezentrale Umsetzung"
|
||||
beschreibung: |
|
||||
Die PM-Funktion definiert den Rahmen durch einheitliche Standards,
|
||||
Methoden und Werkzeuge. Innerhalb dieses Rahmens gestalten die
|
||||
Fachbereiche ihre Prozesse aktiv und tragen somit die Verantwortung dafür.
|
||||
|
||||
- prinzip: "Befähigung statt Kontrolle"
|
||||
beschreibung: |
|
||||
Die Funktion versteht sich als Ermöglicher, nicht als Wächter.
|
||||
Sie schafft Kompetenzen vor Ort durch ein Netzwerk von "Key-User",
|
||||
die als Multiplikator:innen in ihren Bereichen wirken.
|
||||
|
||||
- prinzip: "Nutzenorientierung statt Strukturfixierung"
|
||||
beschreibung: |
|
||||
Ausgangspunkt sind nicht interne Logiken, sondern die Bedarfe der
|
||||
internen Kund:innen - von strategischen Gremien bis zu operativen Teams.
|
||||
|
||||
erwarteter_mehrwert:
|
||||
titel: "Der erwartete Mehrwert"
|
||||
|
||||
fuer_strategische_entscheider:
|
||||
zielgruppe: "Strategische Entscheider:innen"
|
||||
mehrwert:
|
||||
- "Erstmals Transparenz über die gesamte Prozesslandschaft"
|
||||
- "Ermöglichte strategische Gestaltung"
|
||||
- "Frühzeitige Sichtbarkeit von Risiken"
|
||||
- "Systematische Erschließung von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
|
||||
fuer_operative_teams:
|
||||
zielgruppe: "Operative Teams"
|
||||
mehrwert:
|
||||
- "Methodische Unterstützung genau dann, wenn sie benötigt wird"
|
||||
- "Von schneller Beratung bis zur Begleitung komplexer Transformationen"
|
||||
- "Einheitliche Standards für bereichsübergreifende Zusammenarbeit"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
zielgruppe: "Gesamtorganisation"
|
||||
mehrwert:
|
||||
- "Anpassungsfähigkeit ohne Kontrollverlust"
|
||||
- "Kontinuierliche Prozessverbesserung statt nur Dokumentation"
|
||||
- "Systematische Identifikation von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
- "Adressierung von Fachkräftemangel und steigenden Anforderungen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. ORGANISATIONSDESIGN UND GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
organisationsdesign:
|
||||
titel: "Organisationsdesign und Governance"
|
||||
|
||||
architektur:
|
||||
titel: "Eine Architektur der produktiven Spannung"
|
||||
prinzip: |
|
||||
Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung.
|
||||
Methodische Beratung und operative Governance liegen in unterschiedlichen
|
||||
Händen - so entsteht Vertrauen statt Kontrollangst.
|
||||
|
||||
zentrale_rollen:
|
||||
beschreibung: |
|
||||
Fünf zentrale Rollen im PM-Team decken das Spektrum von strategischer
|
||||
Führung über Methodenentwicklung bis zur operativen Beratung ab.
|
||||
Jede Rolle hat klare Verantwortlichkeiten, Überschneidungen werden vermieden.
|
||||
rollen:
|
||||
- "Leiter*in Prozess-Management"
|
||||
- "Prozess-Framework-Manager*in (PFM)"
|
||||
- "Prozesslandschafts-Koordinator*in (PLK)"
|
||||
- "Prozess-Berater*in (PB)"
|
||||
- "Key-User-Netzwerk-Manager*in (KNM)"
|
||||
|
||||
process_owner:
|
||||
beschreibung: |
|
||||
Process Owner in den Hauptprozessen tragen horizontale und vertikale
|
||||
End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren
|
||||
bereichsübergreifend und sichern Prozessqualität.
|
||||
hauptprozesse:
|
||||
- "Stakeholder-Management"
|
||||
- "Demand-Management"
|
||||
- "Projekt-Management"
|
||||
- "Service-Management"
|
||||
|
||||
key_user:
|
||||
beschreibung: |
|
||||
Key-User werden in allen Fachbereichen identifiziert und zu lokalen
|
||||
Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle vor Ort
|
||||
und Bindeglied zur zentralen PM-Funktion.
|
||||
|
||||
governance:
|
||||
titel: "Governance: So viel wie nötig, so wenig wie möglich"
|
||||
prinzip: "Subsidiaritätsprinzip"
|
||||
|
||||
entscheidungskategorien:
|
||||
- kategorie: "Operative Anpassungen"
|
||||
entscheidungsträger: "PM-Team eigenständig"
|
||||
beispiele:
|
||||
- "Tool-Konfigurationen"
|
||||
- "Template-Updates"
|
||||
- "Schulungsinhalte"
|
||||
|
||||
- kategorie: "Prozessspezifische Anpassungen"
|
||||
entscheidungsträger: "Abstimmung mit jeweiligem Process Owner"
|
||||
beispiele:
|
||||
- "Änderungen an Prozessschnittstellen"
|
||||
- "Neue Metriken für spezifische Prozesse"
|
||||
- "Integration neuer Systeme in bestehende Prozesse"
|
||||
|
||||
- kategorie: "PM-Framework-Weiterentwicklungen"
|
||||
entscheidungsträger: "PM-Team eigenständig (Information an Process Owner)"
|
||||
beispiele:
|
||||
- "Neue Modellierungsstandards"
|
||||
- "Erweiterte Methodenbausteine"
|
||||
- "Übergreifende Bewertungskriterien"
|
||||
|
||||
- kategorie: "Fundamentale Änderungen"
|
||||
entscheidungsträger: "Steuerungsgremien"
|
||||
beispiele:
|
||||
- "Wechsel der Prozessmodellierungssprache"
|
||||
- "Grundlegende Änderung der PM-Strategie"
|
||||
- "Neuausrichtung der Prozessarchitektur"
|
||||
|
||||
leistungsbeauftragung:
|
||||
- typ: "Standard-Leistungen"
|
||||
zugang: "Niedrigschwellig für alle zugänglich"
|
||||
beispiele:
|
||||
- "Beratung"
|
||||
- "Workshops"
|
||||
|
||||
- typ: "Projekt-Leistungen"
|
||||
zugang: "Mission Board-Freigabe erforderlich"
|
||||
beispiele:
|
||||
- "Größere Transformationen"
|
||||
|
||||
- typ: "Strategische Initiativen"
|
||||
zugang: "Direkte Beauftragung durch Vision Board"
|
||||
|
||||
- typ: "Krisen-Interventionen"
|
||||
zugang: "Jederzeit durch Führungskräfte auslösbar"
|
||||
|
||||
eskalationsmodell:
|
||||
beschreibung: "Dreistufiges Eskalationsmodell sichert schnelle Konfliktlösung"
|
||||
stufen:
|
||||
- stufe: 1
|
||||
typ: "Operative Themen"
|
||||
zeitrahmen: "Binnen 48 Stunden"
|
||||
|
||||
- stufe: 2
|
||||
typ: "Taktische Konflikte"
|
||||
gremium: "Mission Board"
|
||||
zeitrahmen: "Binnen einer Woche"
|
||||
|
||||
- stufe: 3
|
||||
typ: "Strategische Grundsatzfragen"
|
||||
gremium: "Vision Board"
|
||||
zeitrahmen: "Binnen eines Monats"
|
||||
|
||||
integration:
|
||||
titel: "Integration statt Parallelstruktur"
|
||||
beschreibung: |
|
||||
Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance
|
||||
ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien.
|
||||
Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor.
|
||||
|
||||
schluesselpartner:
|
||||
- "Zentrales Geschäftsprozessmanagement (HPA)"
|
||||
- "IT-Architektur"
|
||||
- "Datenschutz"
|
||||
- "Informationssicherheit"
|
||||
|
||||
prinzip: |
|
||||
Systematische Einbindung schafft vernetzte Kompetenz statt neuer Silos.
|
||||
|
||||
# =============================================================================
|
||||
# 3. IMPLEMENTIERUNG UND KRITISCHE ERFOLGSFAKTOREN
|
||||
# =============================================================================
|
||||
|
||||
implementierung:
|
||||
titel: "Implementierung und kritische Erfolgsfaktoren"
|
||||
|
||||
leistungsportfolio:
|
||||
titel: "Konkrete Leistungen, klare Zugänge"
|
||||
orientierung: "Reale Bedarfe"
|
||||
|
||||
leistungsbereiche:
|
||||
- bereich: "Prozess-Framework/DIGITOM-Entwicklung"
|
||||
zweck: "Schafft die methodische Basis"
|
||||
|
||||
- bereich: "Beratung und Coaching"
|
||||
zweck: "Unterstützt bei konkreten Herausforderungen"
|
||||
|
||||
- bereich: "Befähigung und Schulung"
|
||||
zweck: "Baut Kompetenzen dezentral auf"
|
||||
|
||||
- bereich: "Transparenz und Reporting"
|
||||
zweck: "Ermöglicht faktenbasierte Steuerung"
|
||||
|
||||
zugangswege:
|
||||
- "Ticketsystem für direkte Hilfe"
|
||||
- "Strukturierte Beauftragungen für größere Vorhaben"
|
||||
- "Informelle Kanäle über das Key-User-Netzwerk"
|
||||
|
||||
ressourcen:
|
||||
titel: "Ressourcen und Voraussetzungen"
|
||||
|
||||
quantitativ:
|
||||
- "Dediziertes PM-Team mit komplementären Kompetenzen"
|
||||
- "Moderne Prozess-Tools"
|
||||
- "Qualifizierungsbudgets"
|
||||
|
||||
qualitativ:
|
||||
wichtigkeit: "Wichtiger als Ressourcen sind die qualitativen Voraussetzungen"
|
||||
faktoren:
|
||||
- faktor: "Klares Mandat der Führung"
|
||||
wirkung: "Legitimiert die Funktion"
|
||||
|
||||
- faktor: "Bereitschaft der Fachbereiche"
|
||||
wirkung: "Zur aktiven Mitgestaltung"
|
||||
|
||||
- faktor: "Einbindung der Schlüsselpartner"
|
||||
wirkung: "Von Anfang an"
|
||||
|
||||
- faktor: "Verständnis von Prozessmanagement"
|
||||
wirkung: "Als kontinuierliche Entwicklung, nicht als Projekt"
|
||||
|
||||
risikomanagement:
|
||||
titel: "Risiken aktiv managen"
|
||||
|
||||
risiken:
|
||||
- risiko: "Akzeptanzrisiken"
|
||||
mitigationsstrategie: |
|
||||
Konsequente Trennung von Beratung und Kontrolle.
|
||||
Erfolgsgeschichten und Key-User als Botschafter:innen schaffen Vertrauen.
|
||||
|
||||
- risiko: "Ressourcenkonflikte"
|
||||
mitigationsstrategie: |
|
||||
Transparentes Priorisierungsmodell. Strategische Initiativen gehen
|
||||
stets vor, konkurrierende Anfragen werden offen abgewogen.
|
||||
|
||||
- risiko: "Qualitätsrisiken"
|
||||
mitigationsstrategie: |
|
||||
Systematische Einbindung von Compliance-Funktionen und
|
||||
Process Owner als Qualitätsgatekeeper.
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNGEN ZU ANDEREN PM-DOKUMENTEN
|
||||
# =============================================================================
|
||||
|
||||
dokumentverknuepfungen:
|
||||
beschreibung: |
|
||||
Diese Executive Summary gibt einen kompakten Überblick. Die Details
|
||||
finden sich in den spezialisierten Dokumenten der PM-Funktion.
|
||||
|
||||
detaildokumente:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
inhalt: "Formale Grundlagen, Verantwortungsbereiche, Mandat"
|
||||
|
||||
- dokument: "Leistungs-Canvas"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
inhalt: "Detaillierte Leistungen, Nutzersegmente, Wertversprechen"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
inhalt: "Alle 11 Rollen mit Aufgaben, Befugnissen, Schnittstellen"
|
||||
|
||||
- dokument: "Governance-Framework"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
inhalt: "Entscheidungswege, Eskalation, Leitprinzipien"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
inhalt: "Verantwortlichkeitsmatrix für alle Leistungen"
|
||||
|
||||
- dokument: "Konzeptrahmen"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml"
|
||||
inhalt: "Dokumentationsarchitektur und Navigationshilfe"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #00 - Prozess-Management.docx
|
||||
|
||||
Inhalte:
|
||||
- Strategischer Kontext und Kernkonzept
|
||||
- Organisationale Herausforderung
|
||||
- Lösungskonzept (3 Kernprinzipien)
|
||||
- Erwarteter Mehrwert (3 Zielgruppen)
|
||||
- Organisationsdesign (Rollen, Process Owner, Key-User)
|
||||
- Governance (4 Entscheidungskategorien, 4 Leistungstypen, 3 Eskalationsstufen)
|
||||
- Implementierung (Leistungsportfolio, Ressourcen, Risikomanagement)
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue