init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)
This commit is contained in:
commit
f599c7ced7
91 changed files with 56355 additions and 0 deletions
|
|
@ -0,0 +1,668 @@
|
|||
meta:
|
||||
typ: "methodisches_framework"
|
||||
methode: "demand_klassifizierung"
|
||||
methode_name: "Demand-Klassifizierung: Mehrdimensionales Modell"
|
||||
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:
|
||||
- "klassifizierung"
|
||||
- "demand-management"
|
||||
- "entscheidungsunterstuetzung"
|
||||
- "routing-logik"
|
||||
- "gremien-zuordnung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: "Instrument zur besseren Koordination und Entscheidungsfindung in der Organisation"
|
||||
|
||||
funktionen:
|
||||
- id: "F01"
|
||||
name: "Strukturierung"
|
||||
beschreibung: "Überführung unterschiedlicher Anforderungen in ein einheitliches Schema"
|
||||
|
||||
- id: "F02"
|
||||
name: "Kommunikation"
|
||||
beschreibung: "Etablierung einer gemeinsamen Fachsprache zwischen allen Beteiligten"
|
||||
|
||||
- id: "F03"
|
||||
name: "Entscheidungsunterstützung"
|
||||
beschreibung: "Aufbereitung relevanter Informationen für Gremien"
|
||||
zielgruppen: ["dsr", "mission_board"]
|
||||
|
||||
- id: "F04"
|
||||
name: "Transparenz"
|
||||
beschreibung: "Sichtbarmachung von Abhängigkeiten und Bewertungsmechanismen"
|
||||
|
||||
- id: "F05"
|
||||
name: "Steuerung"
|
||||
beschreibung: "Identifikation von Handlungsschwerpunkten im Portfolio"
|
||||
|
||||
# ========================================
|
||||
# 2. KLASSIFIZIERUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
klassifizierungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Dimensionen zur systematischen Einordnung von Demands"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: TREIBER
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_treiber:
|
||||
id: "treiber"
|
||||
name: "Treiber (Impulsquelle)"
|
||||
leitfrage: "Woher kommt der Impuls für diesen Demand?"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "extern_regulatorisch"
|
||||
name: "Extern-Regulatorisch"
|
||||
beschreibung: "Gesetzliche Vorgaben, Compliance-Anforderungen, Aufsichtsbehörden"
|
||||
ursprung: "stadtextern"
|
||||
|
||||
charakteristika:
|
||||
- "Gesetzliche Vorgaben"
|
||||
- "OZG-Umsetzung"
|
||||
- "Compliance-Anforderungen"
|
||||
- "DSGVO-Anpassungen"
|
||||
- "Aufsichtsbehörden"
|
||||
- "IT-Sicherheitsgesetz"
|
||||
- "Barrierefreiheitsrichtlinien"
|
||||
|
||||
beispiele:
|
||||
- "Bürgerportal-Erweiterung (OZG)"
|
||||
- "DSGVO-Compliance-Maßnahme"
|
||||
- "Umsetzung IT-Sicherheitsgesetz"
|
||||
|
||||
handlungslogik: "Pflichtaufgabe, nicht verhandelbar"
|
||||
|
||||
- stufe: "extern_fachlich"
|
||||
name: "Extern-Fachlich"
|
||||
beschreibung: "Anforderungen von anderen Ämtern, Politik, Bürger:innen"
|
||||
ursprung: "stadtextern"
|
||||
|
||||
charakteristika:
|
||||
- "Anforderungen von anderen Ämtern (auch OB)"
|
||||
- "Politik"
|
||||
- "Bürger:innen"
|
||||
- "Strategische Themen anderer Ämter ohne regulatorischen Hintergrund"
|
||||
|
||||
beispiele:
|
||||
- "Anfrage Bürgermeisteramt für neue Plattform"
|
||||
- "Politischer Auftrag zur Digitalisierung"
|
||||
- "Bürger:innen-Initiative"
|
||||
|
||||
handlungslogik: "Aushandlung nötig, politisch sensibel"
|
||||
|
||||
- stufe: "intern_strategisch"
|
||||
name: "Intern-Strategisch"
|
||||
beschreibung: "Digitalisierungsstrategie, Organisationsziele, Innovationsinitiativen"
|
||||
ursprung: "digit_intern"
|
||||
|
||||
charakteristika:
|
||||
- "Digitalisierungsstrategie"
|
||||
- "KI-Strategie"
|
||||
- "Cloud-Migration"
|
||||
- "Organisationsziele"
|
||||
- "Innovationsinitiativen"
|
||||
|
||||
beispiele:
|
||||
- "Prozessautomatisierung"
|
||||
- "Smart-City-Vorhaben"
|
||||
- "KI-Pilotprojekt"
|
||||
|
||||
handlungslogik: "Gestaltungsspielraum vorhanden"
|
||||
|
||||
qualifizierung_hinweis: |
|
||||
Interne Demands durchlaufen einen Fast Track im SHM (10-15min Validation).
|
||||
Die Vorqualifizierung kann weniger detailliert sein als bei externen Demands.
|
||||
DPM kann bei Bedarf Nachforderungen über die Rückkopplungsschleife stellen
|
||||
(siehe shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm).
|
||||
|
||||
innovationsvorhaben_hinweis: |
|
||||
Innovationsvorhaben, die innerhalb einer Organisationseinheit erprobt werden,
|
||||
liegen außerhalb des DIGITOM-Steuerungskreises und erzeugen keinen Demand.
|
||||
|
||||
Ein Demand entsteht, sobald eine der folgenden Bedingungen eintritt:
|
||||
- Das Vorhaben benötigt Ressourcen (Personal, Budget, Infrastruktur) anderer Abteilungen
|
||||
- Das Vorhaben soll in den Regelbetrieb überführt werden (neuer Service)
|
||||
- Das Vorhaben erfordert eine strategische Entscheidung des Mission Boards
|
||||
|
||||
Ab diesem Moment gilt: Das Vorhaben ist ein interner Demand mit Treiber
|
||||
"intern_strategisch" und durchläuft denselben Prozess wie alle anderen Demands.
|
||||
Es gibt keinen gesonderten Innovationstrack innerhalb des DIGITOM.
|
||||
|
||||
- stufe: "intern_operativ"
|
||||
name: "Intern-Operativ"
|
||||
beschreibung: "Effizienzsteigerung, Betriebsoptimierung, technische Notwendigkeiten"
|
||||
ursprung: "digit_intern"
|
||||
|
||||
charakteristika:
|
||||
- "Performance-Verbesserung"
|
||||
- "Bugfixes"
|
||||
- "Wartungsfenster"
|
||||
- "Lizenzmanagement"
|
||||
- "Effizienzsteigerung"
|
||||
- "Betriebsoptimierung"
|
||||
|
||||
beispiele:
|
||||
- "Performance-Optimierung Service"
|
||||
- "Bugfix kritischer Fehler"
|
||||
- "Lizenzmanagement-Tool"
|
||||
|
||||
handlungslogik: "Operative Exzellenz"
|
||||
|
||||
qualifizierung_hinweis: |
|
||||
Interne Demands durchlaufen einen Fast Track im SHM (10-15min Validation).
|
||||
Die Vorqualifizierung kann weniger detailliert sein als bei externen Demands.
|
||||
DPM kann bei Bedarf Nachforderungen über die Rückkopplungsschleife stellen
|
||||
(siehe shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm).
|
||||
|
||||
interpretationshinweise:
|
||||
hierarchie: |
|
||||
Bei Mehrfachzuordnung gilt die Hierarchie:
|
||||
Extern-Regulatorisch > Extern-Fachlich > Intern-Strategisch > Intern-Operativ
|
||||
|
||||
systemgrenze: "\"Extern\" bedeutet: Impuls kommt von außerhalb DIGITs Systemgrenze"
|
||||
|
||||
politische_auftraege: "Politische Aufträge sind meist \"Extern-Fachlich\", es sei denn, sie basieren auf Gesetzen"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: TRAGWEITE
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_tragweite:
|
||||
id: "tragweite"
|
||||
name: "Tragweite (Veränderungstiefe)"
|
||||
leitfrage: "Wie tiefgreifend ist die Veränderung für Nutzer:innen und Organisation?"
|
||||
detail_matrix_referenz: "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "neugestaltung"
|
||||
name: "Neugestaltung (Transformativ)"
|
||||
beschreibung: "Grundlegende Neugestaltung"
|
||||
|
||||
indikatoren:
|
||||
- "Flächendeckende Schulungen"
|
||||
- "Systemablösung"
|
||||
- "Paradigmenwechsel"
|
||||
- "Komplett neue Arbeitsweise"
|
||||
- "Organisationsumbau"
|
||||
- "Kein Rückfall möglich"
|
||||
- "> 70% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "Einführung komplett neues Fachverfahren"
|
||||
- "Organisationsweite Prozessdigitalisierung"
|
||||
- "Systemablösung mit neuem Paradigma"
|
||||
|
||||
- stufe: "ausbau"
|
||||
name: "Ausbau (Evolutionär)"
|
||||
beschreibung: "Ausbau mit neuen Fähigkeiten"
|
||||
|
||||
indikatoren:
|
||||
- "Punktuelle Schulungen erforderlich"
|
||||
- "Neue Module"
|
||||
- "API-Erweiterungen"
|
||||
- "Prozessdigitalisierung"
|
||||
- "Neue Funktionen, aber bekannte Logik"
|
||||
- "Rückfall theoretisch möglich"
|
||||
- "20-70% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "Erweiterung bestehendes System um neue Funktionen"
|
||||
- "Neue Schnittstellen zu Drittsystemen"
|
||||
- "Digitalisierung einzelner Prozesse"
|
||||
|
||||
- stufe: "optimierung"
|
||||
name: "Optimierung (Inkrementell)"
|
||||
beschreibung: "Optimierung im Bestehenden"
|
||||
|
||||
indikatoren:
|
||||
- "Keine neuen Schulungen nötig"
|
||||
- "UI-Verbesserungen"
|
||||
- "Bugfixes"
|
||||
- "Kleinere Features"
|
||||
- "Nutzer:innen merken kaum Veränderung"
|
||||
- "Rückfall jederzeit möglich"
|
||||
- "< 20% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "UI-Redesign ohne funktionale Änderungen"
|
||||
- "Performance-Verbesserungen"
|
||||
- "Bugfixes"
|
||||
|
||||
interpretationshinweise:
|
||||
gesamtbetrachtung: "Die Tragweite bezieht sich auf die Gesamtveränderung, nicht nur auf technische Aspekte"
|
||||
perspektive: "Bei Unsicherheit: Aus Nutzer:innen-Perspektive bewerten"
|
||||
change_management: "\"Transformativ\" impliziert meist Change-Management-Bedarf"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: SYSTEMEBENE
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_systemebene:
|
||||
id: "systemebene"
|
||||
name: "Systemebene (Technisch-fachliche Verortung)"
|
||||
leitfrage: "Auf welcher Ebene der IT-Landschaft wirkt der Demand?"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "infrastruktur"
|
||||
name: "Infrastruktur"
|
||||
beschreibung: "Technische Basiskomponenten ohne direkten Fachbezug"
|
||||
|
||||
beispiele:
|
||||
- "Server"
|
||||
- "Storage"
|
||||
- "Netzwerk"
|
||||
- "Virtualisierung"
|
||||
- "Backup"
|
||||
|
||||
- stufe: "produkt"
|
||||
name: "Produkt"
|
||||
beschreibung: "Bündelung von Ressourcen, die eigenständig Mehrwert liefern"
|
||||
|
||||
beispiele:
|
||||
- "CMS-Plattform"
|
||||
- "Formular-Engine"
|
||||
- "Datenbank-Cluster"
|
||||
|
||||
- stufe: "service"
|
||||
name: "Service"
|
||||
beschreibung: "Anwendung von Produkten in Service-Beziehungen"
|
||||
hinweis: "Service als konkrete Anwendung von Produkten für Nutzer:innen"
|
||||
|
||||
- stufe: "fachverfahren"
|
||||
name: "Fachverfahren"
|
||||
beschreibung: "Spezifische Geschäftsanwendungen für Fachdomänen"
|
||||
|
||||
beispiele:
|
||||
- "Einwohnermeldewesen"
|
||||
- "Kita-Platz-Vergabe"
|
||||
- "Bauakten-Management"
|
||||
|
||||
- stufe: "daten_integration"
|
||||
name: "Daten & Integration"
|
||||
beschreibung: "Schnittstellen, Datenhaltung, Austauschformate"
|
||||
|
||||
beispiele:
|
||||
- "XÖV-Standards"
|
||||
- "Data Warehouse"
|
||||
- "ETL-Prozesse"
|
||||
|
||||
- stufe: "querschnittskomponente"
|
||||
name: "Querschnitts-Komponente"
|
||||
beschreibung: "Übergreifende technische Komponente für multiple Fachverfahren"
|
||||
|
||||
beispiele:
|
||||
- "IAM"
|
||||
- "Monitoring"
|
||||
- "Logging"
|
||||
- "API-Gateway"
|
||||
- "Verschlüsselung"
|
||||
|
||||
interpretationshinweise:
|
||||
mehrfachbetroffenheit: "Ein Demand kann mehrere Ebenen betreffen → Hauptebene identifizieren"
|
||||
stakeholder_implikation: "Die Ebene bestimmt oft die involvierten Stakeholder"
|
||||
schwerpunkt: "Bei Unklarheit: Wo liegt der Schwerpunkt der Veränderung?"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: KOMPLEXITÄT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_komplexitaet:
|
||||
id: "komplexitaet"
|
||||
name: "Komplexität (Lösungsunsicherheit)"
|
||||
leitfrage: "Wie viel Unsicherheit besteht bezüglich Lösung und Umsetzung?"
|
||||
detail_matrix_referenz: "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "moderat"
|
||||
name: "Moderat"
|
||||
|
||||
indikatoren:
|
||||
- "1-2 beteiligte Teams DIGIT-intern"
|
||||
- "Bekannte Technologie"
|
||||
- "Klare Lösung erkennbar"
|
||||
- "< 50 PT Aufwand"
|
||||
- "Geringes Risiko"
|
||||
- "Keine externen Abhängigkeiten"
|
||||
|
||||
konsequenz: "Direkte Umsetzung möglich"
|
||||
|
||||
- stufe: "komplex"
|
||||
name: "Komplex"
|
||||
|
||||
indikatoren:
|
||||
- "3-4 beteiligte Teams DIGIT-intern"
|
||||
- "Analyse erforderlich"
|
||||
- "Lösungsoptionen vorhanden"
|
||||
- "50-200 PT Aufwand"
|
||||
- "Mittleres Risiko"
|
||||
- "1-2 externe Partner/Abhängigkeiten"
|
||||
|
||||
konsequenz: "Vorprojekt empfohlen"
|
||||
|
||||
- stufe: "hochkomplex"
|
||||
name: "Hochkomplex"
|
||||
|
||||
indikatoren:
|
||||
- "5+ Stakeholder"
|
||||
- "Neue Technologien"
|
||||
- "Grundsätzliche Unsicherheit"
|
||||
- "> 200 PT Aufwand"
|
||||
- "Hohes Risiko"
|
||||
- "2+ externe Partner/Abhängigkeiten"
|
||||
|
||||
konsequenz: "Exploration zwingend erforderlich"
|
||||
|
||||
interpretationshinweise:
|
||||
nichtlinearitaet: "Komplexität steigt exponentiell mit der Anzahl der Abhängigkeiten - nicht linear mit dem Aufwand"
|
||||
vorsichtsprinzip: "Bei Unsicherheit zwischen zwei Stufen: Die höhere Komplexität wählen (Vorsichtsprinzip)"
|
||||
zielkonflikte: "\"Hochkomplex\" ist oft ein Signal für grundsätzliche Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
# ========================================
|
||||
# 3. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 KLASSIFIZIERUNGSPROZESS
|
||||
# ----------------------------------
|
||||
|
||||
klassifizierungsprozess:
|
||||
beschreibung: "Strukturierter Ablauf zur Sicherstellung von Qualität und Nachvollziehbarkeit"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "S1"
|
||||
name: "Initiale Einordnung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: |
|
||||
Der:die zuständige DPM nimmt basierend auf den vorliegenden Informationen
|
||||
aus der Bedarfsqualifizierung vom SHM eine erste Einordnung in allen vier
|
||||
Klassifizierungs-Dimensionen vor.
|
||||
input: "bedarfs_steckbrief_von_shm"
|
||||
output: "initiale_klassifizierung_4_dimensionen"
|
||||
|
||||
- schritt_id: "S2"
|
||||
name: "Plausibilitätsprüfung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Prüfung auf Konsistenz und Vollständigkeit"
|
||||
|
||||
typische_prueffragen:
|
||||
- "Passt die Komplexitätseinstufung zur identifizierten Tragweite?"
|
||||
- "Sind alle relevanten Stakeholder berücksichtigt?"
|
||||
- "Gibt es Widersprüche zwischen den Dimensionen?"
|
||||
|
||||
- schritt_id: "S3"
|
||||
name: "Validierung bei Unsicherheit"
|
||||
verantwortlich: "dpm"
|
||||
trigger: "unklarheiten_nach_plausibilitaetspruefung"
|
||||
beschreibung: "Gezieltes Einbeziehen von Fachexpert:innen"
|
||||
art: "kurze Konsultation, nicht formaler Prozess"
|
||||
|
||||
typische_konsultationen:
|
||||
- rolle: "it_architektur"
|
||||
bei: "technische_komplexitaet_unklar"
|
||||
- rolle: "fachexpertinnen"
|
||||
bei: "fachliche_tragweite_unklar"
|
||||
- rolle: "spm"
|
||||
bei: "service_impact_unklar"
|
||||
|
||||
- schritt_id: "S4"
|
||||
name: "Dokumentation"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Validierte Klassifizierung in Demand-Entscheidungsvorlage überführen"
|
||||
|
||||
dokumentationspflicht:
|
||||
- "Einordnungen in allen 4 Dimensionen"
|
||||
- "Begründungen je Dimension"
|
||||
- "Ergänzende Klassifizierungs-Matrix (bei Tragweite & Komplexität)"
|
||||
- "Eventuelle Dissens-Punkte aus Validierung"
|
||||
|
||||
output: "dokumentierte_klassifizierung"
|
||||
|
||||
- schritt_id: "S5"
|
||||
name: "Routing-Entscheidung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Zuordnung zum passenden Gremium basierend auf Klassifizierung"
|
||||
input: "dokumentierte_klassifizierung"
|
||||
output: "routing_entscheidung"
|
||||
|
||||
mechanismus: "Definierte Automatismen greifen, Raum für begründete Abweichungen im Indifferenzraum"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 ROUTING-LOGIK
|
||||
# ----------------------------------
|
||||
|
||||
routing_logik:
|
||||
beschreibung: "Die Klassifizierung bestimmt die Entscheidungsebene"
|
||||
|
||||
routing_regeln:
|
||||
- routing_ziel: "mission_board"
|
||||
gremium_name: "Mission Board"
|
||||
beschreibung: "Strategisch relevante, hochkomplexe oder transformative Demands"
|
||||
|
||||
bedingungen:
|
||||
operator: "OR"
|
||||
regeln:
|
||||
- dimension: "komplexitaet"
|
||||
operator: "="
|
||||
wert: "hochkomplex"
|
||||
|
||||
- dimension: "tragweite"
|
||||
operator: "="
|
||||
wert: "neugestaltung"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "treiber"
|
||||
operator: "="
|
||||
wert: "extern_regulatorisch"
|
||||
- dimension: "komplexitaet"
|
||||
operator: ">="
|
||||
wert: "komplex"
|
||||
|
||||
- routing_ziel: "dsr_mit_delegationsoption"
|
||||
gremium_name: "DSR mit Delegationsoption ans Mission Board"
|
||||
beschreibung: "Grenzfälle, die DSR entscheiden kann, aber Option zur Delegation hat"
|
||||
|
||||
bedingungen:
|
||||
operator: "OR"
|
||||
regeln:
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "tragweite"
|
||||
operator: "="
|
||||
wert: "ausbau"
|
||||
- dimension: "komplexitaet"
|
||||
operator: "="
|
||||
wert: "komplex"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "systemebene"
|
||||
operator: "="
|
||||
wert: "infrastruktur"
|
||||
- dimension: "tragweite"
|
||||
operator: ">="
|
||||
wert: "ausbau"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "systemebene"
|
||||
operator: "="
|
||||
wert: "querschnittskomponente"
|
||||
- dimension: "tragweite"
|
||||
operator: ">="
|
||||
wert: "ausbau"
|
||||
|
||||
- dimension: "treiber"
|
||||
operator: "="
|
||||
wert: "extern_fachlich"
|
||||
|
||||
- routing_ziel: "dsr"
|
||||
gremium_name: "DSR"
|
||||
beschreibung: "Standard-Demands ohne strategische Implikation"
|
||||
|
||||
bedingungen:
|
||||
beschreibung: "Alle anderen Kombinationen, die nicht MB oder DSR-mit-Delegation triggern"
|
||||
typische_faelle:
|
||||
- "Operative Optimierungen"
|
||||
- "Moderate Komplexität"
|
||||
- "Inkrementelle Veränderungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 DELEGATIONSOPTION
|
||||
# ----------------------------------
|
||||
|
||||
delegationsoption:
|
||||
name: "Flexibler Umgang mit Grenzfällen"
|
||||
|
||||
zweck: |
|
||||
In der Praxis gibt es immer wieder Demands, die sich nicht eindeutig zuordnen lassen.
|
||||
Für diese Fälle sieht das Modell eine Delegationsoption vor – die Möglichkeit,
|
||||
Entscheidungen gezielt an das Mission Board weiterzugeben.
|
||||
|
||||
typische_anwendungsfaelle:
|
||||
- "Politisch unklare Themen, deren Auswirkungen schwer abschätzbar sind"
|
||||
- "Anforderungen, die sowohl fachliche als auch strategische Aspekte haben"
|
||||
- "Komplett neue Themen, für die es noch keine Erfahrungswerte gibt"
|
||||
|
||||
funktionsweise:
|
||||
- schritt: "DSR hat grundsätzlich Befugnis, Grenzfälle selbst zu entscheiden"
|
||||
- schritt: "Bei Unsicherheit kann DSR die Entscheidung ans Mission Board delegieren"
|
||||
- schritt: "Gründe für Delegation werden dokumentiert"
|
||||
- schritt: "Einmal pro Quartal prüft DPM, welche Fälle delegiert wurden und warum"
|
||||
|
||||
qualitaetssicherung:
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "dpm"
|
||||
analyse: "Muster in Delegationen identifizieren, ggf. Routing-Regeln anpassen"
|
||||
|
||||
# ========================================
|
||||
# 4. QUALITÄTSSICHERUNG UND WEITERENTWICKLUNG
|
||||
# ========================================
|
||||
|
||||
qualitaetssicherung:
|
||||
|
||||
kontroll_mechanismen:
|
||||
- name: "Quartals-Reviews"
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "dpm"
|
||||
aktivitaet: "Analyse der Routing-Entscheidungen und bei Bedarf Anpassung der Kriterien"
|
||||
|
||||
- name: "Gremien-Rückmeldung"
|
||||
quellen: ["dsr", "mission_board"]
|
||||
gegenstand: "Feedback zur Treffsicherheit der Klassifizierung"
|
||||
verwendung: "Continuous Improvement der Klassifizierungskriterien"
|
||||
|
||||
kontinuierliche_anpassung:
|
||||
prinzip: "Klassifizierungsmodell ist nicht statisch, sondern entwickelt sich bei Bedarf weiter"
|
||||
|
||||
anpassungstypen:
|
||||
- typ: "Neue Kategorien"
|
||||
beschreibung: "Können bei Bedarf ergänzt werden"
|
||||
trigger: "Neue Demand-Typen, die nicht abgebildet sind"
|
||||
|
||||
- typ: "Schwellenwerte"
|
||||
beschreibung: "Werden basierend auf Erfahrungen justiert"
|
||||
beispiel: "PT-Grenzen für Komplexität, Nutzer-%-Grenzen für Tragweite"
|
||||
|
||||
- typ: "Interpretationshilfen"
|
||||
beschreibung: "Werden kontinuierlich präzisiert"
|
||||
quelle: "Learnings aus konkreten Klassifizierungsfällen"
|
||||
|
||||
- typ: "Best Practices"
|
||||
beschreibung: "Werden dokumentiert und geteilt"
|
||||
zielgruppe: "Alle, die klassifizieren (primär DPM)"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATIONSSTANDARD
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
beschreibung: "Jede Klassifizierung wird standardisiert dokumentiert (als Teil der Demand-Entscheidungsvorlage)"
|
||||
|
||||
template_struktur:
|
||||
demand_titel: "[Titel des Demands]"
|
||||
|
||||
klassifizierung:
|
||||
- dimension: "treiber"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "tragweite"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "systemebene"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "komplexitaet"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Unsicherheitsfaktoren]"
|
||||
|
||||
routing:
|
||||
zielgremium: "[Mission Board | DSR mit Delegationsoption | DSR]"
|
||||
begruendung: "[Basierend auf Routing-Logik]"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
detail_matrizen:
|
||||
- titel: "Klassifizierungsmatrix Komplexität"
|
||||
pfad: "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
beschreibung: "Erweiterte Kriterien für Komplexitätsbewertung"
|
||||
|
||||
- titel: "Klassifizierungsmatrix Tragweite"
|
||||
pfad: "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
beschreibung: "Erweiterte Kriterien für Tragweitenbewertung"
|
||||
|
||||
prozess_kontext:
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen"
|
||||
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Verantwortlichkeiten für Klassifizierung"
|
||||
|
||||
# ========================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# ========================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2026-01-22"
|
||||
aenderung: |
|
||||
- qualifizierung_hinweis bei intern_strategisch und intern_operativ ergänzt:
|
||||
Hinweis auf SHM Fast Track (10-15min Validation) und
|
||||
DPM-Rückkopplungsschleife für Nachforderungen
|
||||
- Querverweis auf shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "[ursprüngliches Abnahmedatum]"
|
||||
aenderung: "Initiale Erstellung und Abnahme"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Konzept_DPM_Abnahme20230925"
|
||||
|
|
@ -0,0 +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"
|
||||
|
|
@ -0,0 +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"
|
||||
typ: "confluence"
|
||||
|
|
@ -0,0 +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]
|
||||
|
||||
Handlungsbedarf: [Beschreibung]
|
||||
|
|
@ -0,0 +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"
|
||||
- "Bewegung von Demands zwischen Quadranten im Zeitverlauf zeigen"
|
||||
|
|
@ -0,0 +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"
|
||||
referenz: "raci-matrix-demand-portfolio-management.yaml"
|
||||
|
|
@ -0,0 +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"
|
||||
relevanz: "Methodischer Kern der DPM-Funktion"
|
||||
|
|
@ -0,0 +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"
|
||||
gegenmassnahme: "Entscheidungszeitpunkt definieren"
|
||||
|
|
@ -0,0 +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]
|
||||
|
||||
hinweis: "Bei divergierenden Perspektiven muss erklärt werden, warum eine Perspektive dominiert"
|
||||
|
|
@ -0,0 +1,668 @@
|
|||
meta:
|
||||
typ: "raci_matrix"
|
||||
scope: "Demand-Portfolio-Management"
|
||||
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:
|
||||
- "verantwortlichkeiten"
|
||||
- "raci"
|
||||
- "demand-lifecycle"
|
||||
- "governance"
|
||||
- "prozess"
|
||||
|
||||
# ========================================
|
||||
# GOVERNANCE-PRINZIPIEN
|
||||
# ========================================
|
||||
|
||||
governance_prinzipien:
|
||||
beschreibung: "Differenzierter Ansatz, der Agilität mit notwendiger Governance-Kontrolle balanciert"
|
||||
|
||||
prinzipien:
|
||||
- id: "GP1"
|
||||
name: "Fachexpertise = Verantwortung"
|
||||
regel: "A/R zusammen"
|
||||
beschreibung: "Wo Fachkompetenz entscheidend ist, liegen Ausführung und Verantwortung in einer Hand"
|
||||
begruendung: "Empowerment der Experten, schnelle Entscheidungen, klare Ownership"
|
||||
|
||||
- id: "GP2"
|
||||
name: "Governance-Gates"
|
||||
regel: "A≠R getrennt"
|
||||
beschreibung: "Bei Kontrollpunkten und Gremienentscheidungen wird bewusst getrennt"
|
||||
begruendung: "Vier-Augen-Prinzip, Checks & Balances, Verwaltungssicherheit"
|
||||
|
||||
- id: "GP3"
|
||||
name: "Klare Übergänge"
|
||||
regel: "A≠R an Schnittstellen"
|
||||
beschreibung: "Bei Phasenübergängen erfolgt explizite Verantwortungsübergabe"
|
||||
begruendung: "Eindeutige Verantwortungswechsel, Vermeidung von Lücken"
|
||||
|
||||
# ========================================
|
||||
# RACI-LEGENDE
|
||||
# ========================================
|
||||
|
||||
raci_legende:
|
||||
R:
|
||||
name: "Responsible"
|
||||
beschreibung: "Führt die Aktivität aus, ist operativ verantwortlich"
|
||||
|
||||
A:
|
||||
name: "Accountable"
|
||||
beschreibung: "Hat die finale Verantwortung und Entscheidungsbefugnis"
|
||||
|
||||
C:
|
||||
name: "Consulted"
|
||||
beschreibung: "Wird vor der Entscheidung konsultiert, gibt fachlichen Input"
|
||||
|
||||
I:
|
||||
name: "Informed"
|
||||
beschreibung: "Wird über das Ergebnis informiert"
|
||||
|
||||
# ========================================
|
||||
# ROLLEN
|
||||
# ========================================
|
||||
|
||||
rollen:
|
||||
- rolle_id: "sh"
|
||||
rolle_name: "Stakeholder"
|
||||
fokus: "Bedarfsträger"
|
||||
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
fokus: "Bedarfserfassung und Stakeholder-Kommunikation"
|
||||
|
||||
- rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Management"
|
||||
fokus: "Qualifizierung, Bewertung, Priorisierung"
|
||||
|
||||
- rolle_id: "dsr"
|
||||
rolle_name: "Demand & Stakeholder Runde"
|
||||
fokus: "Entscheidungsinstanz für DSR-Demands (nach Demand-Klassifizierung)"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- rolle_id: "mb"
|
||||
rolle_name: "Mission Board"
|
||||
fokus: "Entscheidungsinstanz für MB-Demands (nach Demand-Klassifizierung)"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
fokus: "Service-Impact und Sponsoring"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
fokus: "Projektinitiierung und -steuerung"
|
||||
|
||||
- rolle_id: "al_p"
|
||||
rolle_name: "Abteilungsleitung Planung"
|
||||
fokus: "Quartals-Reviews und DPM-Führung"
|
||||
|
||||
- rolle_id: "pzm"
|
||||
rolle_name: "Prozess-Management"
|
||||
fokus: "Methodische Governance und Quality Gates"
|
||||
|
||||
- rolle_id: "ita"
|
||||
rolle_name: "IT-Architektur-Board"
|
||||
fokus: "Technische Bewertung"
|
||||
|
||||
- rolle_id: "vb"
|
||||
rolle_name: "Vision Board"
|
||||
fokus: "Strategische Governance"
|
||||
|
||||
- rolle_id: "pl"
|
||||
rolle_name: "Projektleitung"
|
||||
fokus: "Projektdurchführung"
|
||||
|
||||
# ========================================
|
||||
# RACI-ZUORDNUNGEN NACH PHASEN
|
||||
# ========================================
|
||||
|
||||
raci_matrix:
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 1: INITIIERUNG UND ERFASSUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_1_initiierung:
|
||||
phase_id: "phase_1"
|
||||
phase_name: "Initiierung und Erfassung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "1.1"
|
||||
name: "Bedarfsidentifikation"
|
||||
zuordnung:
|
||||
sh: "A/R"
|
||||
shm: "I"
|
||||
|
||||
- aktivitaet_id: "1.2"
|
||||
name: "Bedarfsmeldung"
|
||||
zuordnung:
|
||||
sh: "R"
|
||||
shm: "A"
|
||||
dpm: "I"
|
||||
|
||||
- aktivitaet_id: "1.3"
|
||||
name: "Initiale Qualifizierung"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "A/R"
|
||||
|
||||
- aktivitaet_id: "1.4"
|
||||
name: "Service-Katalog-Prüfung"
|
||||
zuordnung:
|
||||
shm: "A/R"
|
||||
spm: "C"
|
||||
|
||||
- aktivitaet_id: "1.5"
|
||||
name: "Bedarfsklärungsgespräch (optional)"
|
||||
zuordnung:
|
||||
sh: "R"
|
||||
shm: "A/R"
|
||||
|
||||
- aktivitaet_id: "1.6"
|
||||
name: "User Story Erstellung"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "A/R"
|
||||
dpm: "C"
|
||||
|
||||
- aktivitaet_id: "1.7"
|
||||
name: "Demand-Übergabe"
|
||||
beschreibung: "Quality Gate 1: Übergabe von SHM an DPM"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "R"
|
||||
dpm: "A"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 2: QUALIFIZIERUNG UND PRIORISIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_2_qualifizierung:
|
||||
phase_id: "phase_2"
|
||||
phase_name: "Qualifizierung und Priorisierung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "2.1"
|
||||
name: "Vollständigkeitsprüfung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
|
||||
- aktivitaet_id: "2.2"
|
||||
name: "Demand-Klassifizierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
ita: "C"
|
||||
|
||||
- aktivitaet_id: "2.3"
|
||||
name: "Demand-Analyse"
|
||||
zuordnung:
|
||||
dpm: "A/R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
ita: "C"
|
||||
|
||||
- aktivitaet_id: "2.4"
|
||||
name: "Demand-Bewertung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "2.5"
|
||||
name: "Demand-Priorisierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "2.6"
|
||||
name: "Entscheidungsvorlage erstellen"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 3: ENTSCHEIDUNG UND FREIGABE
|
||||
# ----------------------------------
|
||||
|
||||
phase_3_entscheidung:
|
||||
phase_id: "phase_3"
|
||||
phase_name: "Entscheidung und Freigabe"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "3.1"
|
||||
name: "DSR-Vorbereitung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.2"
|
||||
name: "DSR-Präsentation"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.3"
|
||||
name: "DSR-Entscheidung (DSR-Demand)"
|
||||
beschreibung: "Entscheidung über DSR-Demands"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "C"
|
||||
dpm: "R/C"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
hinweis: "DPM ist Teil der DSR-Entscheidung (C) und dokumentiert (R)"
|
||||
|
||||
- aktivitaet_id: "3.4"
|
||||
name: "MB-Delegation"
|
||||
beschreibung: "Delegation eines Demands von DSR ans Mission Board"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R/C"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
hinweis: "DPM ist Teil der Entscheidung und dann verantwortlich, den delegierten Demand ins MB einzubringen"
|
||||
|
||||
- aktivitaet_id: "3.5"
|
||||
name: "MB-Vorbereitung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.6"
|
||||
name: "MB-Präsentation"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.7"
|
||||
name: "MB-Entscheidung (MB-Demand)"
|
||||
beschreibung: "Finale Entscheidung des Mission Board über MB-Demands"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "I"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
|
||||
- aktivitaet_id: "3.8"
|
||||
name: "Auflagen-Definition"
|
||||
beschreibung: "Definition von Auflagen bei bedingter Freigabe"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
hinweis: "DSR für DSR-Demands, MB für MB-Demands"
|
||||
|
||||
- aktivitaet_id: "3.9"
|
||||
name: "Sponsor-Benennung (DSR-Demand)"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.10"
|
||||
name: "Sponsor-Benennung (MB-Demand)"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
mb: "A/R"
|
||||
spm: "I"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.11"
|
||||
name: "Kommunikation Entscheidung"
|
||||
beschreibung: "Kommunikation der Entscheidung an Stakeholder"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "A/R"
|
||||
dpm: "I"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 4: PROJEKTINITIIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_4_projektinitiierung:
|
||||
phase_id: "phase_4"
|
||||
phase_name: "Projektinitiierung (Übergang)"
|
||||
beschreibung: "Übergang von Demand zu Projekt"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "4.1"
|
||||
name: "Projektauftrag erstellen (DSR-Demand)"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "4.2"
|
||||
name: "Projektleitung benennen"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "4.3"
|
||||
name: "Ressourcenmobilisierung"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "C"
|
||||
mb: "C"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
hinweis: "DSR und MB werden nur bei Ressourcenkonflikten konsultiert"
|
||||
|
||||
- aktivitaet_id: "4.4"
|
||||
name: "Demand-Archivierung"
|
||||
beschreibung: "Demand wird als 'in Projekt überführt' archiviert"
|
||||
zuordnung:
|
||||
dpm: "A/R"
|
||||
ppm: "I"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 5: GOVERNANCE UND MONITORING
|
||||
# ----------------------------------
|
||||
|
||||
phase_5_governance:
|
||||
phase_id: "phase_5"
|
||||
phase_name: "Governance und Monitoring"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "5.1"
|
||||
name: "Auflagenerfüllung"
|
||||
beschreibung: "Überwachung der Erfüllung von Auflagen aus Freigabe"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
spm: "C"
|
||||
ppm: "A/R"
|
||||
|
||||
- aktivitaet_id: "5.2"
|
||||
name: "Projekt Status-Reporting an DSR"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "A/R"
|
||||
|
||||
- aktivitaet_id: "5.3"
|
||||
name: "Portfolio-Dashboard"
|
||||
beschreibung: "Pflege und Bereitstellung des Demand-Portfolio-Dashboards"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "C"
|
||||
|
||||
- aktivitaet_id: "5.4"
|
||||
name: "Quartals-Review"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
|
||||
- aktivitaet_id: "5.5"
|
||||
name: "MB-Review Berichterstattung"
|
||||
beschreibung: "Berichterstattung an Mission Board über Portfolio-Review"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
mb: "C"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "A"
|
||||
|
||||
- aktivitaet_id: "5.6"
|
||||
name: "Prozess-Compliance"
|
||||
beschreibung: "Sicherstellung der Einhaltung von Prozess-Standards"
|
||||
zuordnung:
|
||||
dpm: "R"
|
||||
al_p: "C"
|
||||
pzm: "A"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 6: ESKALATIONS- UND SONDERFÄLLE
|
||||
# ----------------------------------
|
||||
|
||||
phase_6_eskalation:
|
||||
phase_id: "phase_6"
|
||||
phase_name: "Eskalations- und Sonderfälle"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "6.1"
|
||||
name: "Sonder-DSR einberufen"
|
||||
zuordnung:
|
||||
shm: "R"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "R"
|
||||
hinweis: "Jedes DSR-Mitglied kann Sonder-DSR anfragen (R). DPM entscheidet über Einberufung (A/R)"
|
||||
|
||||
- aktivitaet_id: "6.2"
|
||||
name: "Fachliche Konflikte"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "(A)"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: DSR → MB → VB. (A) in Klammern zeigt Eskalationsinstanz"
|
||||
|
||||
- aktivitaet_id: "6.3"
|
||||
name: "Ressourcenkonflikte"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "(A)"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: DSR → MB → VB"
|
||||
|
||||
- aktivitaet_id: "6.4"
|
||||
name: "Strategische Konflikte"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
dsr: "R"
|
||||
mb: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: MB → VB"
|
||||
|
||||
- aktivitaet_id: "6.5"
|
||||
name: "Methodische Konflikte"
|
||||
beschreibung: "Konflikte über Prozesse, Methoden, Standards"
|
||||
zuordnung:
|
||||
dpm: "R"
|
||||
al_p: "C"
|
||||
pzm: "A"
|
||||
|
||||
- aktivitaet_id: "6.6"
|
||||
name: "Unauflösbare Konflikte"
|
||||
beschreibung: "Konflikte, die auf lower Ebenen nicht lösbar sind"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "C"
|
||||
|
||||
eskalations_prozess:
|
||||
beschreibung: "Bei Konflikten gilt folgender Prozess"
|
||||
stufen:
|
||||
- stufe: 1
|
||||
name: "Versuch Lösung"
|
||||
beschreibung: "Verantwortliche Instanz (R) versucht Lösung"
|
||||
|
||||
- stufe: 2
|
||||
name: "Eskalation"
|
||||
beschreibung: "Ohne Klärung findet eine Eskalation an nächsthöhere Instanz"
|
||||
pfade:
|
||||
- von: "dsr"
|
||||
zu: "mb"
|
||||
- von: "mb"
|
||||
zu: "vb"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 7: KONTINUIERLICHE VERBESSERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_7_verbesserung:
|
||||
phase_id: "phase_7"
|
||||
phase_name: "Kontinuierliche Verbesserung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "7.1"
|
||||
name: "Prozess-Optimierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "C"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
|
||||
- aktivitaet_id: "7.2"
|
||||
name: "KPI-Definition"
|
||||
beschreibung: "Definition und Anpassung von Portfolio-KPIs"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
vb: "I"
|
||||
|
||||
- aktivitaet_id: "7.3"
|
||||
name: "Lessons Learned"
|
||||
beschreibung: "Systematische Auswertung von Erfahrungen"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "C"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
vb: "I"
|
||||
|
||||
- aktivitaet_id: "7.4"
|
||||
name: "Framework-Updates"
|
||||
beschreibung: "Anpassung von Governance-Frameworks und Methoden"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "I"
|
||||
pzm: "A/R"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNGSHINWEISE
|
||||
# ========================================
|
||||
|
||||
anwendungshinweise:
|
||||
mehrfachzuordnung:
|
||||
beschreibung: "A/R bedeutet: Eine Rolle ist sowohl Responsible als auch Accountable"
|
||||
anwendung: "Bei Fachexpertise = Verantwortung (Prinzip 1)"
|
||||
|
||||
eskalations_kennzeichnung:
|
||||
beschreibung: "(A) in Klammern zeigt Eskalationsinstanz bei Konflikten"
|
||||
anwendung: "Wenn aktuelle Ebene nicht lösen kann, eskaliert zu dieser Instanz"
|
||||
|
||||
optionale_aktivitaeten:
|
||||
beschreibung: "Manche Aktivitäten sind optional (z.B. Bedarfsklärungsgespräch)"
|
||||
kennzeichnung: "Mit '(optional)' im Namen markiert"
|
||||
|
||||
bedingte_zuordnungen:
|
||||
beschreibung: "Manche Zuordnungen gelten nur unter bestimmten Bedingungen"
|
||||
beispiel: "Sponsor-Benennung unterscheidet sich für DSR-Demands vs. MB-Demands"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
prozess_kontext:
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Definiert Routing zu DSR vs. MB"
|
||||
|
||||
- titel: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Detaillierte Arbeitsweise der DSR"
|
||||
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten des DPM"
|
||||
|
|
@ -0,0 +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"
|
||||
relevanz: "Arbeitsweise des wichtigsten Gremiums für DPM"
|
||||
|
|
@ -0,0 +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"
|
||||
|
||||
validierungsprofile_referenz: "shm_schema_bedarfssteckbrief.yaml#validierungsprofile"
|
||||
|
|
@ -0,0 +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"
|
||||
citation: [376, 1770]
|
||||
|
|
@ -0,0 +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"
|
||||
citation: [381]
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
phase:
|
||||
id: 4
|
||||
titel: "Projektinitiierung (Übergang)"
|
||||
ziel: "Geordnete Übergabe des freigegebenen Demands in die Verantwortung des Projekt-Portfolio-Managements zur Initialisierung der Umsetzung."
|
||||
verantwortlich_rolle: "Projekt-Portfolio-Management (PPM) [Übergang von DPM]"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "4.1"
|
||||
titel: "Projektauftrag erstellen"
|
||||
bedingung: "Nur bei freigegebenen Demands (aus Phase 3)"
|
||||
akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
support_akteure:
|
||||
- "Demand-Portfolio-Management (DPM) (Übergabe Historie)"
|
||||
- "Stakeholder-Management (SHM) (Stakeholder-Kontext)"
|
||||
beschreibung: "Formaler Start der Projektinitiierung. Überführung der Demand-Daten (Steckbrief, Beschluss, Auflagen) in einen initialen Projektauftrag."
|
||||
input: "Gremienbeschluss & Demand-Akte"
|
||||
output: "Initialer Projektauftrag"
|
||||
raci_referenz: "4.1"
|
||||
citation: [385]
|
||||
|
||||
- schritt_id: "4.2"
|
||||
titel: "Benennung Projektleitung"
|
||||
akteur: "Service-Portfolio-Management (SPM)"
|
||||
support_akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
beschreibung: "Identifikation und formale Benennung der Projektleitung, idealerweise aus dem Umfeld des zukünftigen Service Owners."
|
||||
input: "Projektauftrag"
|
||||
output: "Benannte Projektleitung"
|
||||
raci_referenz: "4.2"
|
||||
citation: [385, 500]
|
||||
|
||||
- schritt_id: "4.3"
|
||||
titel: "Ressourcenmobilisierung"
|
||||
akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
partner_akteur: "Projektleitung (PL)"
|
||||
beschreibung: "Initiale Zusammenstellung des Projektteams und Sicherstellung der Verfügbarkeit gemäß Gremienbeschluss."
|
||||
input: "Benannte Projektleitung & Ressourcen-Bedarf"
|
||||
output: "Initiales Projektteam"
|
||||
raci_referenz: "4.3"
|
||||
citation: [385, 501]
|
||||
|
||||
- schritt_id: "4.4"
|
||||
titel: "Demand-Archivierung (Abschluss DPM)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Formaler Abschluss des Demand-Prozesses. Der Demand gilt als 'umgesetzt' in ein Projekt. Sicherstellung der Traceability (Demand -> Projekt)."
|
||||
input: "Bestätigung Projektstart"
|
||||
output: "Demand (Status: Abgeschlossen / In Umsetzung)"
|
||||
trigger_next_lifecycle: "Start Service-Lifecycle (Design Phase)"
|
||||
raci_referenz: "4.4"
|
||||
citation: [385]
|
||||
Loading…
Add table
Add a link
Reference in a new issue