1112 lines
No EOL
42 KiB
YAML
1112 lines
No EOL
42 KiB
YAML
# =============================================================================
|
||
# FUNKTIONSBESCHREIBUNG: SERVICE-PORTFOLIO-MANAGEMENT (SPM)
|
||
# =============================================================================
|
||
# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/
|
||
# Dateiname: spm_funktionsbeschreibung.yaml
|
||
# =============================================================================
|
||
|
||
meta:
|
||
typ: "funktionsbeschreibung"
|
||
funktion_id: "spm"
|
||
funktion_name: "Service-Portfolio-Management"
|
||
aliases: ["SPM", "Service-Portfolio-Funktion"]
|
||
version: "1.0"
|
||
status: "draft"
|
||
erstellt: "2025-12-17"
|
||
gueltig_ab: "[Datum nach Freigabe]"
|
||
geltungsbereich: "DIGITOM / Service-Lifecycle"
|
||
|
||
status_info:
|
||
inhaltlich_abgenommen_durch: []
|
||
status: "in_abstimmung"
|
||
|
||
kontext_tags:
|
||
- "service-portfolio-management"
|
||
- "funktion"
|
||
- "portfolio-governance"
|
||
- "lifecycle-koordination"
|
||
- "practice-ownership"
|
||
|
||
konsolidierung:
|
||
quellen:
|
||
- "rolle_service-portfolio-manager.yaml"
|
||
- "rolle_service-owner.yaml"
|
||
- "spm_sor_go.yaml"
|
||
- "spm_practice_service-catalog-management.yaml"
|
||
- "spm_practice_service-level-management.yaml"
|
||
- "spm_practice_change-enablement.yaml"
|
||
- "spm_konzept_service-transition.yaml"
|
||
- "spm_konzept_service-portfolio-review.yaml"
|
||
- "spm_governance-entscheidungen-log.yaml"
|
||
governance_entscheidungen: "GOV-001 bis GOV-012, GOV-TR-*, GOV-SR-*"
|
||
|
||
# =============================================================================
|
||
# ABKÜRZUNGSVERZEICHNIS
|
||
# =============================================================================
|
||
|
||
abkuerzungen:
|
||
spm: "Service-Portfolio-Management"
|
||
so: "Service Owner"
|
||
sor: "Service Operations Runde"
|
||
mb: "Mission Board"
|
||
vb: "Vision Board"
|
||
dpm: "Demand-Portfolio-Management"
|
||
shm: "Stakeholder-Management"
|
||
ppm: "Projekt-Portfolio-Management"
|
||
dsr: "Demand & Stakeholder-Runde"
|
||
scm: "Service Catalog Management"
|
||
slm: "Service Level Management"
|
||
ce: "Change Enablement"
|
||
sla: "Service Level Agreement"
|
||
sls: "Service Level Specification"
|
||
els: "Early Life Support"
|
||
raci: "Responsible / Accountable / Consulted / Informed"
|
||
|
||
# =============================================================================
|
||
# 1. ZWECK
|
||
# =============================================================================
|
||
|
||
zweck:
|
||
wozu_existiert_diese_funktion:
|
||
kurz: |
|
||
Steuert das Service-Portfolio über den gesamten Lifecycle und stellt
|
||
Governance-Konformität, Portfolio-Konsistenz und methodische Standards sicher.
|
||
|
||
ausfuehrlich: |
|
||
Das Service-Portfolio-Management (SPM) verantwortet die strategische und
|
||
taktische Steuerung aller Services im DIGIT-Portfolio. Die Funktion stellt
|
||
sicher, dass Services konsistent definiert, qualitätsgesichert erbracht
|
||
und kontinuierlich weiterentwickelt oder stillgelegt werden.
|
||
|
||
SPM verbindet die strategische Ebene (Vision Board, Mission Board) mit der
|
||
operativen Ebene (Service Owner, Betriebsteams) und orchestriert den
|
||
Service-Lifecycle von der Transition bis zur Stilllegung. Als Practice Owner
|
||
für Service Catalog Management, Service Level Management und Change
|
||
Enablement definiert SPM die methodischen Standards, nach denen Services
|
||
dokumentiert, ihre Qualität gemessen und Änderungen kontrolliert
|
||
durchgeführt werden.
|
||
|
||
wertbeitrag:
|
||
- "Portfolio-Transparenz: Gesamtüberblick über alle Services"
|
||
- "Governance-Sicherung: Einheitliche Standards und Prozesse"
|
||
- "Koordination: Vermittlung zwischen Service- und Steuerungsebene"
|
||
- "Methodische Führung: Best Practices für Service Management"
|
||
- "Review-Aggregation: Verdichtung von Service-Erkenntnissen für Steuerung"
|
||
|
||
kritisches_merkmal: |
|
||
SPM ist keine operative Betriebsführungsfunktion und kein "Super-Service-Owner".
|
||
Die fachlich-inhaltliche Verantwortung für einzelne Services liegt bei den
|
||
Service Ownern; SPM sichert die Portfolio-Perspektive und Governance-Konformität.
|
||
|
||
hauptziel:
|
||
beschreibung: |
|
||
Ein konsistentes, strategiekonformes und qualitätsgesichertes Service-Portfolio
|
||
über den gesamten Lifecycle sicherstellen.
|
||
|
||
erreicht_durch:
|
||
- id: "Z1"
|
||
aktivitaet: "Portfolio-Steuerung"
|
||
beschreibung: |
|
||
Aufbau, Pflege und strategische Ausrichtung des Service-Portfolios.
|
||
Sicherstellung von Portfolio-Konsistenz und Redundanzfreiheit.
|
||
umfasst:
|
||
- "Service-Kategorisierung vorbereiten (A/B/C)"
|
||
- "Portfolio-Standards definieren"
|
||
- "Strategischen Portfolio-Input für DIGIT-Strategie liefern"
|
||
|
||
- id: "Z2"
|
||
aktivitaet: "Lifecycle-Koordination"
|
||
beschreibung: |
|
||
Orchestrierung der Service-Lifecycle-Phasen mit definierten Quality Gates.
|
||
umfasst:
|
||
- "Transition-Gates steuern (Gate 1: SOR, Gate 2: SO, Gate 3: SOR)"
|
||
- "Service-Reviews aggregieren"
|
||
- "Stilllegungs-Koordination"
|
||
|
||
- id: "Z3"
|
||
aktivitaet: "Practice Ownership"
|
||
beschreibung: |
|
||
Methodische Verantwortung für Service Catalog Management,
|
||
Service Level Management und Change Enablement.
|
||
umfasst:
|
||
- "Katalog-Governance und -Standards"
|
||
- "SLA-Templates und -Freigabeprozesse"
|
||
- "Change-Typen, Change Authority und Klassifizierungsverfahren"
|
||
- "Qualitätssicherung der Service-Dokumentation"
|
||
|
||
- id: "Z4"
|
||
aktivitaet: "Gremienkoordination"
|
||
beschreibung: |
|
||
Vorsitz und Koordination der Service Operations Runde (SOR) als
|
||
zentrales Governance-Gremium für Service-Angelegenheiten.
|
||
umfasst:
|
||
- "SOR-Vorbereitung und -Moderation"
|
||
- "Entscheidungsvorlagen für MB vorbereiten"
|
||
- "Portfolio-Block in SOR präsentieren"
|
||
|
||
- id: "Z5"
|
||
aktivitaet: "Portfolio-Transparenz herstellen"
|
||
beschreibung: |
|
||
Regelmäßige Aufbereitung von Portfolio-Erkenntnissen für die
|
||
Steuerungsebene.
|
||
umfasst:
|
||
- "Quartalsweise Portfolio-Status-Übersicht (E2)"
|
||
- "Jährlicher Portfolio-Report (E1) für Vision Board"
|
||
- "Muster- und Trendanalysen"
|
||
|
||
# =============================================================================
|
||
# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG
|
||
# =============================================================================
|
||
|
||
funktionsverstaendnis:
|
||
charakterisierung:
|
||
typ: "Portfolio-Governance- und Lifecycle-Koordinationsfunktion"
|
||
|
||
beschreibung: |
|
||
SPM ist die zentrale Instanz für die Steuerung des Service-Portfolios.
|
||
Die Funktion verbindet strategische Portfolio-Entscheidungen mit der
|
||
operativen Service-Erbringung, definiert methodische Standards und
|
||
stellt Governance-Konformität sicher – ohne selbst fachlich-inhaltliche
|
||
Service-Entscheidungen zu treffen.
|
||
|
||
Im Unterschied zu DPM (Durchlaufprozess: Demand → Entscheidung → Übergabe)
|
||
verantwortet SPM einen Bestandsprozess: Das Portfolio existiert dauerhaft
|
||
und muss kontinuierlich gesteuert, weiterentwickelt und bereinigt werden.
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# GRUNDPRINZIPIEN
|
||
# ---------------------------------------------------------------------------
|
||
grundprinzipien:
|
||
|
||
portfolio_vor_service:
|
||
name: "Portfolio-Perspektive vor Service-Perspektive"
|
||
beschreibung: |
|
||
SPM denkt vom Ganzen her: Passt der Service ins Portfolio? Gibt es
|
||
Redundanzen? Sind Standards eingehalten? Diese Perspektive ergänzt
|
||
die Service-Perspektive der Service Owner, die vom einzelnen Service
|
||
her denken.
|
||
auswirkung: |
|
||
Legitimiert SPM-Beteiligung bei Service-Entscheidungen, ohne die
|
||
SO-Accountability zu untergraben.
|
||
|
||
governance_nicht_inhalt:
|
||
name: "Governance-Konformität sichern, nicht Inhalte entscheiden"
|
||
beschreibung: |
|
||
SPM prüft: Ist das Verfahren eingehalten? Ist die Dokumentation
|
||
vollständig? Sind die Gates passiert? SPM entscheidet nicht:
|
||
Ist der Service fachlich gut? Ist die SLA-Zielsetzung richtig?
|
||
auswirkung: |
|
||
Klare Rollentrennung: SO verantwortet Fachlichkeit, SPM verantwortet
|
||
Verfahren und Standards.
|
||
referenz: "rolle_service-portfolio-manager.yaml → rollenzweck"
|
||
|
||
befaehigung_nicht_kontrolle:
|
||
name: "Methodische Befähigung statt operativer Kontrolle"
|
||
beschreibung: |
|
||
SPM als Practice Owner stellt Methodik, Templates und Standards bereit.
|
||
Die operative Durchführung (SLA-Erhebung, Katalogpflege, Reviews)
|
||
liegt bei den Service Ownern und Betriebsteams.
|
||
auswirkung: |
|
||
Vermeidet, dass SPM zum Flaschenhals wird. ITIL4-konform:
|
||
Practice Owner ≠ Prozessausführer.
|
||
|
||
transparenz_durch_aggregation:
|
||
name: "Transparenz durch Aggregation"
|
||
beschreibung: |
|
||
SPM erstellt Portfolio-Übersichten, aggregiert Review-Ergebnisse,
|
||
identifiziert Muster. Einzelne Services sehen ihre eigene Realität;
|
||
SPM sieht die Gesamtlage.
|
||
auswirkung: |
|
||
Rechtfertigt Review-Aggregation (E1/E2-Berichte) und Portfolio-Analysen
|
||
für VB/MB.
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# ABGRENZUNG ZU ANGRENZENDEN FUNKTIONEN
|
||
# ---------------------------------------------------------------------------
|
||
abgrenzung_zu_angrenzenden_funktionen:
|
||
|
||
- funktion: "shm"
|
||
name: "Stakeholder-Management"
|
||
shm_tut: |
|
||
Erfasst und klärt Bedarfe mit Stakeholdern; pflegt Kundenbeziehungen;
|
||
vertritt Kundenperspektive in Gremien.
|
||
spm_tut: |
|
||
Koordiniert Service-bezogene Kundeninteraktion (Kundenforum gemeinsam
|
||
mit SO); prüft Kundenverständlichkeit von Service-Steckbriefen.
|
||
schnittstelle: |
|
||
SHM ist ständiges Mitglied in SOR. Bei Katalogpflege optional
|
||
Einbindung für Kundenverständlichkeit (GOV-009).
|
||
|
||
- funktion: "dpm"
|
||
name: "Demand-Portfolio-Management"
|
||
dpm_tut: |
|
||
Klassifiziert, analysiert, bewertet und priorisiert Demands;
|
||
bringt Entscheidungsvorlagen in DSR/MB ein.
|
||
spm_tut: |
|
||
Bewertet Service-Impact bei Demands (Konsultation in DPM Phase 2);
|
||
prüft Auswirkungen auf bestehende Services und Portfolio-Abhängigkeiten.
|
||
schnittstelle: |
|
||
DPM konsultiert SPM bei Service-bezogenen Demands. Bei REDESIGN/RETIRE
|
||
aus Service-Review: SOR übergibt an DPM (neuer Demand).
|
||
|
||
- funktion: "ppm"
|
||
name: "Projekt-Portfolio-Management"
|
||
ppm_tut: |
|
||
Integriert freigegebene Demands in das Projektportfolio;
|
||
steuert Projektumsetzungen bis zur Übergabe.
|
||
spm_tut: |
|
||
Definiert Übernahme-Kriterien für Transition (Gate 1);
|
||
koordiniert Projekt→Service-Übergabe gemeinsam mit SO.
|
||
schnittstelle: |
|
||
PPM liefert entwickelten Service an Transition. SPM/SO prüfen
|
||
Betriebsreife und steuern Go-Live.
|
||
status: "placeholder"
|
||
offene_fragen:
|
||
- "Wer initiiert die Transition-Ankündigung?"
|
||
- "Wie früh wird SO in Projektphase eingebunden?"
|
||
- "Koordination bei Projekten mit Impact auf bestehende Services?"
|
||
klaerung_bei: "PPM-Konzeption"
|
||
|
||
- funktion: "service_owner"
|
||
name: "Service Owner (Rolle innerhalb SPM)"
|
||
so_tut: |
|
||
End-to-End-Verantwortung für einzelnen Service; fachliche Entscheidungen;
|
||
Change Authority für Normal Changes; SLA-Durchführung.
|
||
spm_tut: |
|
||
Portfolio-Perspektive über alle Services; Governance-Konformität;
|
||
methodische Standards; Aggregation und Eskalation.
|
||
abgrenzung: |
|
||
SPM = Portfolio-Ebene (Was haben wir? Passt es zusammen?)
|
||
SO = Service-Ebene (Wie funktioniert mein Service?)
|
||
|
||
- funktion: "operations_manager"
|
||
name: "Operations Manager"
|
||
ops_tut: |
|
||
Operative Betriebsführung; Koordination Betriebsteams;
|
||
SLA-/Policy-Einhaltung im Tagesgeschäft.
|
||
spm_tut: |
|
||
Erhält aggregierte Betriebsdaten für Portfolio-Steuerung;
|
||
keine operative Betriebsverantwortung.
|
||
schnittstelle: |
|
||
Operations Manager ist ständiges SOR-Mitglied und bringt
|
||
Betriebsperspektive in Governance-Entscheidungen ein.
|
||
|
||
# =============================================================================
|
||
# 3. VERANTWORTUNGSBEREICHE
|
||
# =============================================================================
|
||
|
||
verantwortungsbereiche:
|
||
|
||
beschreibung: |
|
||
Die Kernverantwortungen von SPM gliedern sich in Portfolio-Steuerung,
|
||
Practice Ownership und Gremienkoordination.
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.1 PORTFOLIO-STEUERUNG
|
||
# ---------------------------------------------------------------------------
|
||
bereich_1_portfolio_steuerung:
|
||
id: "VB1"
|
||
name: "Portfolio-Steuerung"
|
||
|
||
was:
|
||
- "Service-Kategorisierung vorbereiten (A/B/C)"
|
||
- "Portfolio-Konsistenz und Redundanzfreiheit sichern"
|
||
- "Portfolio-Standards definieren und pflegen"
|
||
- "Service-Impact bei Demands bewerten (Konsultation)"
|
||
- "Strategischen Portfolio-Input für DIGIT-Strategie liefern"
|
||
|
||
warum:
|
||
- "Gesamtüberblick und strategische Ausrichtung des Portfolios"
|
||
- "Vermeidung von Wildwuchs und Redundanzen"
|
||
- "Entscheidungsfähigkeit für Steuerungsebene"
|
||
|
||
wie:
|
||
governance:
|
||
- "Service-Kategorisierung: SPM bereitet vor, MB entscheidet (GOV-001)"
|
||
- "Portfolio-Standards: SPM definiert, SOR bestätigt"
|
||
- "Service-Impact: DPM konsultiert SPM in Phase 2"
|
||
|
||
frequenz:
|
||
- "Kategorisierung: Bei Bedarf (neue Services, Änderungen)"
|
||
- "Konsistenzprüfung: Kontinuierlich"
|
||
- "Strategie-Input: Jährlich"
|
||
|
||
outputs:
|
||
- "Kategorisierungs-Empfehlung für MB"
|
||
- "Portfolio-Standards-Dokumentation"
|
||
- "Service-Impact-Einschätzung für Entscheidungsvorlagen"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.2 SERVICE CATALOG MANAGEMENT (PRACTICE OWNERSHIP)
|
||
# ---------------------------------------------------------------------------
|
||
bereich_2_service_catalog_management:
|
||
id: "VB2"
|
||
name: "Service Catalog Management"
|
||
rolle: "Practice Owner"
|
||
governance_referenz: "GOV-006"
|
||
|
||
was:
|
||
- "Service-Definitionen validieren und freigeben"
|
||
- "Katalogänderungen nach dreistufiger Governance steuern"
|
||
- "Jährlichen Katalog-Review durchführen"
|
||
- "Service-Stilllegung im Katalog koordinieren"
|
||
- "Kundenverständlichkeit koordinieren (optional im MVP)"
|
||
- "Katalog-Backlog führen"
|
||
|
||
warum:
|
||
- "Einheitliche, aktuelle und vollständige Service-Dokumentation"
|
||
- "Single Source of Truth für Service-Informationen"
|
||
- "Qualitätssicherung der Service-Beschreibungen"
|
||
|
||
wie:
|
||
governance:
|
||
- "Redaktionelle Änderungen: SO autonom"
|
||
- "Minor-Änderungen: SO + SPM bilateral (GOV-008)"
|
||
- "Major-Änderungen / Neuaufnahme: SOR"
|
||
- "Strukturelle Änderungen: MB"
|
||
|
||
frequenz:
|
||
- "Validierung: Bei Bedarf"
|
||
- "Katalog-Review: Jährlich"
|
||
|
||
outputs:
|
||
- "Freigegebene Service-Definitionen"
|
||
- "Katalog-Review-Bericht für SOR"
|
||
- "Maßnahmenliste für Service Owner"
|
||
|
||
referenz: "spm_practice_service-catalog-management.yaml"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.3 SERVICE LEVEL MANAGEMENT (PRACTICE OWNERSHIP)
|
||
# ---------------------------------------------------------------------------
|
||
bereich_3_service_level_management:
|
||
id: "VB3"
|
||
name: "Service Level Management"
|
||
rolle: "Practice Owner"
|
||
|
||
was:
|
||
- "SLA-Governance und methodische Standards sicherstellen"
|
||
- "SLA-Freigabeprozess koordinieren"
|
||
- "Portfolio-Konsistenz bei SLS/SLA prüfen"
|
||
- "SLA-Eskalationen tracken"
|
||
|
||
warum:
|
||
- "Einheitliche SLA-Qualität über das Portfolio"
|
||
- "Governance-konforme SLA-Prozesse"
|
||
- "Transparenz über SLA-Performance auf Portfolio-Ebene"
|
||
|
||
wie:
|
||
governance:
|
||
- "Standard-SLAs: Freigabe über SOR"
|
||
- "Abweichungen / Major-SLAs: Freigabe über MB"
|
||
- "SLA-Partner: Entscheidungsbefugte (GOV-005)"
|
||
|
||
frequenz:
|
||
- "Freigabe-Koordination: Bei Bedarf"
|
||
- "Konsistenzprüfung: Bei SLS/SLA-Erstellung"
|
||
- "Eskalations-Tracking: Kontinuierlich"
|
||
|
||
outputs:
|
||
- "Freigegebene SLA-Templates"
|
||
- "SLA-Eskalations-Dokumentation"
|
||
- "SLA-Status für Portfolio-Review"
|
||
|
||
operative_durchfuehrung: |
|
||
Die operative SLA-Durchführung (Erhebung, Abstimmung, Monitoring)
|
||
liegt bei den Service Ownern. SPM stellt Methodik und Governance.
|
||
|
||
referenz: "spm_practice_service-level-management.yaml"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.4 CHANGE ENABLEMENT (PRACTICE OWNERSHIP)
|
||
# ---------------------------------------------------------------------------
|
||
bereich_4_change_enablement:
|
||
id: "VB3a"
|
||
name: "Change Enablement"
|
||
rolle: "Practice Owner"
|
||
|
||
was:
|
||
- "Change-Typen, Klassifizierungslogik und Autorisierungsverfahren definieren"
|
||
- "Change Authority Matrix pflegen"
|
||
- "Cross-Service-Impact-Prüfung aus Portfolio-Perspektive"
|
||
- "Major-Change-Autorisierung über SOR koordinieren"
|
||
|
||
warum:
|
||
- "Kontrollierte, risikobewusste Durchführung von Service-Änderungen"
|
||
- "Balance zwischen Agilität und Stabilität"
|
||
- "Einheitliche Change-Governance über das Portfolio"
|
||
|
||
wie:
|
||
governance:
|
||
- "Standard Changes: Pre-authorized via Change-Modell"
|
||
- "Normal Changes: SO-Einzelentscheidung (Change Authority)"
|
||
- "Major Changes: SOR-Autorisierung (einmalig), danach regulärer Lifecycle"
|
||
- "Emergency Changes: Sofortumsetzung, nachträgliche Dokumentation"
|
||
|
||
frequenz:
|
||
- "Klassifizierung: Bei jedem Change Request"
|
||
- "Cross-Service-Prüfung: Bei Bedarf (SO-Ermessen)"
|
||
- "Major-Autorisierung: Über SOR-Rhythmus"
|
||
|
||
outputs:
|
||
- "Change Authority Matrix"
|
||
- "Change-Modell-Vorlagen"
|
||
- "Major-Change-Entscheidungsvorlagen für SOR"
|
||
|
||
operative_durchfuehrung: |
|
||
Die operative Change-Durchführung liegt bei den Service Ownern
|
||
(Normal Changes) bzw. Betriebsteams. SPM stellt Methodik und
|
||
Governance-Rahmen bereit und koordiniert bei Cross-Service-Impact.
|
||
|
||
referenz: "spm_practice_change-enablement.yaml"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.5 PORTFOLIO-REVIEW
|
||
# ---------------------------------------------------------------------------
|
||
bereich_5_portfolio_review:
|
||
id: "VB5"
|
||
name: "Portfolio-Review"
|
||
|
||
was:
|
||
- "Service-Review-Ergebnisse sammeln und aggregieren"
|
||
- "Portfolio-Status-Übersicht erstellen (E2)"
|
||
- "Jahres-Portfolio-Report erstellen (E1)"
|
||
- "Muster und Auffälligkeiten identifizieren"
|
||
- "Portfolio-Empfehlungen formulieren"
|
||
|
||
warum:
|
||
- "Verdichtung von Einzelsichten zur Gesamtlage"
|
||
- "Steuerungsfähige Information für MB/VB"
|
||
- "Früherkennung von Portfolio-Risiken"
|
||
|
||
wie:
|
||
frequenz:
|
||
- "E2 (Portfolio-Status): Quartalsweise in SOR"
|
||
- "E1 (Jahresbericht): Jährlich für Vision Board"
|
||
|
||
datenquellen:
|
||
- "Service-Steckbriefe (Ampel-Status)"
|
||
- "Quartalsweise Service-Reviews der SOs"
|
||
- "SLA-Performance-Daten"
|
||
- "Problem-Management-Erkenntnisse"
|
||
|
||
outputs:
|
||
- "E2: Portfolio-Status-Übersicht für SOR"
|
||
- "E1: Jahres-Portfolio-Report für VB"
|
||
- "Maßnahmenempfehlungen"
|
||
|
||
governance_referenz: "GOV-PR-001, GOV-PR-002"
|
||
referenz: "spm_konzept_service-portfolio-review.yaml"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 3.6 GREMIENARBEIT
|
||
# ---------------------------------------------------------------------------
|
||
bereich_6_gremienarbeit:
|
||
id: "VB6"
|
||
name: "Gremienarbeit"
|
||
|
||
was:
|
||
- "SOR vorbereiten, leiten und nachbereiten"
|
||
- "Portfolio-Block in SOR präsentieren"
|
||
- "Entscheidungsvorlagen für MB vorbereiten (bei Eskalation)"
|
||
- "DSR-Teilnahme bei Routing-Klärungen"
|
||
|
||
warum:
|
||
- "Strukturierte Entscheidungsfindung im Service-Portfolio"
|
||
- "Verbindung zwischen operativer und strategischer Ebene"
|
||
- "Klare Eskalationswege"
|
||
|
||
wie:
|
||
rhythmus:
|
||
- gremium: "SOR"
|
||
frequenz: "zweiwöchentlich"
|
||
spm_rolle: "Vorsitz"
|
||
|
||
- gremium: "MB"
|
||
frequenz: "zweiwöchentlich"
|
||
spm_rolle: "Berichtsrecht (kein Stimmrecht)"
|
||
|
||
- gremium: "DSR"
|
||
frequenz: "wöchentlich"
|
||
spm_rolle: "Mitglied bei Routing-Klärungen"
|
||
|
||
- gremium: "VB"
|
||
frequenz: "jährlich"
|
||
spm_rolle: "Liefert E1-Jahresbericht"
|
||
|
||
outputs:
|
||
- "SOR-Protokolle"
|
||
- "Entscheidungsvorlagen"
|
||
- "Eskalationsanträge"
|
||
|
||
referenz: "spm_sor_go.yaml"
|
||
|
||
# =============================================================================
|
||
# 4. SCHNITTSTELLEN
|
||
# =============================================================================
|
||
|
||
schnittstellen:
|
||
beschreibung: "Input/Output und typische Abstimmungswege"
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 4.1 INPUTS
|
||
# ---------------------------------------------------------------------------
|
||
inputs:
|
||
beschreibung: "Was SPM empfängt"
|
||
|
||
quellen:
|
||
- von: "vision_board"
|
||
inhalt: |
|
||
Strategische Leitplanken für Portfolio-Ausrichtung;
|
||
Entgegennahme des E1-Jahresberichts.
|
||
|
||
- von: "mission_board"
|
||
inhalt: |
|
||
Entscheidungen zu Service-Kategorisierung; Freigabe von
|
||
Major-SLAs und strukturellen Katalogänderungen;
|
||
Ressourcenentscheidungen bei Eskalation.
|
||
|
||
- von: "dpm"
|
||
inhalt: |
|
||
Konsultationsanfragen zu Service-Impact bei Demands;
|
||
Information über freigegebene Demands mit Service-Bezug.
|
||
|
||
- von: "ppm"
|
||
inhalt: |
|
||
Übergabe entwickelter Services an Transition;
|
||
Übergabeprotokoll und Dokumentation.
|
||
status: "placeholder - bei PPM-Konzeption zu detaillieren"
|
||
|
||
- von: "shm"
|
||
inhalt: |
|
||
Stakeholder-Perspektive in SOR; Kundenfeedback;
|
||
Hinweise auf Kundenverständlichkeit von Services.
|
||
|
||
- von: "service_owner"
|
||
inhalt: |
|
||
Service-Definitionen zur Validierung; Katalogänderungsanträge;
|
||
Service-Review-Ergebnisse; SLA-Freigabeanträge;
|
||
Gate-Anträge (Transition).
|
||
|
||
- von: "operations_manager"
|
||
inhalt: |
|
||
Betriebsperspektive in SOR; aggregierte Betriebsdaten;
|
||
Betriebsreife-Einschätzung bei Transition.
|
||
|
||
- von: "support_manager"
|
||
inhalt: |
|
||
Support-Perspektive in SOR; Support-Readiness-Einschätzung;
|
||
Problem-Management-Erkenntnisse.
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 4.2 OUTPUTS
|
||
# ---------------------------------------------------------------------------
|
||
outputs:
|
||
beschreibung: "Was SPM liefert"
|
||
|
||
ziele:
|
||
- an: "vision_board"
|
||
inhalt: |
|
||
E1-Jahres-Portfolio-Report; strategische Portfolio-Empfehlungen.
|
||
|
||
- an: "mission_board"
|
||
inhalt: |
|
||
Kategorisierungs-Empfehlungen; Eskalationen aus SOR;
|
||
Entscheidungsvorlagen für Major-SLAs und strukturelle Änderungen.
|
||
|
||
- an: "sor"
|
||
inhalt: |
|
||
Tagesordnung und Entscheidungsvorlagen; Portfolio-Block (E2);
|
||
Gate-2-Freigabeanträge; Review-Eskalationen.
|
||
|
||
- an: "dpm"
|
||
inhalt: |
|
||
Service-Impact-Einschätzung für Entscheidungsvorlagen;
|
||
Hinweise auf Katalog-Anpassungsbedarf;
|
||
REDESIGN/RETIRE-Demands aus Service-Review.
|
||
|
||
- an: "ppm"
|
||
inhalt: |
|
||
Übernahme-Kriterien für Transition (Gate 1);
|
||
Rückmeldung bei Projekten mit Service-Impact.
|
||
status: "placeholder"
|
||
|
||
- an: "shm"
|
||
inhalt: |
|
||
Einladung zu Kundenforum (gemeinsam mit SO);
|
||
Katalog-Informationen für Stakeholder-Kommunikation.
|
||
|
||
- an: "service_owner"
|
||
inhalt: |
|
||
Freigegebene Service-Definitionen; Katalog-Review-Ergebnisse;
|
||
SLA-Governance-Feedback; Gate-Entscheidungen;
|
||
methodische Templates und Standards.
|
||
|
||
- an: "operations_manager"
|
||
inhalt: |
|
||
SOR-Protokolle; Transition-Informationen;
|
||
Portfolio-Entscheidungen mit Betriebsrelevanz.
|
||
|
||
- an: "support_manager"
|
||
inhalt: |
|
||
SOR-Protokolle; Katalog-Updates;
|
||
Transition-Informationen für Support-Vorbereitung.
|
||
|
||
# ---------------------------------------------------------------------------
|
||
# 4.3 TYPISCHE ABSTIMMUNGSWEGE
|
||
# ---------------------------------------------------------------------------
|
||
typische_abstimmungswege:
|
||
beschreibung: "Standardisierte Interaktionsformate"
|
||
|
||
formate:
|
||
- format: "sor_regulaer"
|
||
name: "SOR – Regulär"
|
||
frequenz: "zweiwöchentlich"
|
||
inhalt:
|
||
- "Portfolio-Block: Status, Reviews, Auffälligkeiten"
|
||
- "Entscheidungen: Gate 2, Major Changes, Review-Eskalationen"
|
||
- "Koordination: Status-Austausch Betrieb/Support"
|
||
- "Protokollierung und Nachverfolgung"
|
||
|
||
- format: "sor_sonder"
|
||
name: "Sonder-SOR"
|
||
frequenz: "ad_hoc"
|
||
inhalt:
|
||
- "Dringende Gate-Entscheidungen"
|
||
- "Kritische Service-Situationen"
|
||
- "Einberufung auf Antrag eines SOR-Mitglieds"
|
||
|
||
- format: "spm_so_bilateral"
|
||
name: "SPM ↔ SO – Bilaterale Abstimmung"
|
||
frequenz: "bei_bedarf"
|
||
inhalt:
|
||
- "Minor-Katalogänderungen"
|
||
- "Service-Definition-Validierung"
|
||
- "Cross-Service-Impact-Prüfung ('zweite Augen')"
|
||
- "Gate-1-Vorbereitung"
|
||
|
||
- format: "spm_dpm_service"
|
||
name: "SPM ↔ DPM – Service-Impact"
|
||
frequenz: "bei_bedarf"
|
||
inhalt:
|
||
- "Service-Impact-Bewertung bei Demands"
|
||
- "Portfolio-Abhängigkeiten und betroffene Services identifizieren"
|
||
- "Katalog-Anpassungshinweise"
|
||
|
||
- format: "kundenforum"
|
||
name: "Kundenforum"
|
||
frequenz: "jaehrlich"
|
||
inhalt:
|
||
- "Gemeinsame Moderation SO + SHM"
|
||
- "Integriert: SLM-Review + Beziehungspflege"
|
||
- "Kategorie A/B: Kollektives Format"
|
||
- "Kategorie C: Bilateral mit Amt"
|
||
governance_referenz: "GOV-012"
|
||
|
||
- format: "portfolio_review"
|
||
name: "Portfolio-Review"
|
||
frequenz: "quartalsweise (E2), jährlich (E1)"
|
||
inhalt:
|
||
- "Aggregation Service-Review-Ergebnisse"
|
||
- "Portfolio-Status-Präsentation in SOR"
|
||
- "Jahresbericht für Vision Board"
|
||
|
||
# =============================================================================
|
||
# 5. ORGANISATORISCHE EINORDNUNG
|
||
# =============================================================================
|
||
|
||
organisatorische_einordnung:
|
||
|
||
abteilung: "Planung"
|
||
berichtslinie: "Leitung Planung"
|
||
|
||
designentscheidungen:
|
||
- id: "D-SPM-01"
|
||
entscheidung: |
|
||
Es gibt keine separate "Leitung SPM". Die Leitungsfunktion wird
|
||
durch die Leitung Planung wahrgenommen.
|
||
begruendung: |
|
||
Analog zur DPM-Struktur. Vermeidet Rolleninflation und stellt
|
||
Konsistenz zwischen den Portfolio-Funktionen sicher.
|
||
|
||
- id: "D-SPM-02"
|
||
entscheidung: |
|
||
SPM ist organisatorisch der Abteilung Planung zugeordnet.
|
||
begruendung: |
|
||
Natürliche Nähe zu DPM. Beide Portfolio-Funktionen in einer
|
||
Abteilung gebündelt erleichtert Koordination.
|
||
|
||
- id: "D-SPM-03"
|
||
entscheidung: |
|
||
SPM ist kein Mitglied des Mission Board. Die Leitung Planung
|
||
vertritt SPM im MB. SPM nimmt regelmäßig am MB teil (Berichtsrecht).
|
||
begruendung: |
|
||
MB-Mitgliedschaft auf Leitungsebene. SPM erhält Berichtsrecht
|
||
ohne Stimmrecht, entspricht operativer Rolle.
|
||
|
||
rollen_in_funktion:
|
||
- rolle: "Service-Portfolio-Manager (SPM)"
|
||
typ: "Einzelrolle"
|
||
beschreibung: |
|
||
Zentrale Koordinationsrolle für portfolio-übergreifende
|
||
Service-Management-Aktivitäten.
|
||
referenz: "rolle_service-portfolio-manager.yaml"
|
||
|
||
- rolle: "Service Owner (SO)"
|
||
typ: "Mehrfachrolle (1 pro Service)"
|
||
beschreibung: |
|
||
End-to-End-Verantwortung für einzelnen Service über
|
||
gesamten Lifecycle.
|
||
referenz: "rolle_service-owner.yaml"
|
||
|
||
vertretung:
|
||
regel: |
|
||
Bei Abwesenheit des SPM übernimmt ein von der Leitung Planung
|
||
benannter Vertreter die Koordinationsaufgaben.
|
||
sor_vorsitz: |
|
||
Bei SPM-Abwesenheit kann die SOR-Moderation an ein anderes
|
||
ständiges SOR-Mitglied delegiert werden (z.B. Operations Manager).
|
||
|
||
# =============================================================================
|
||
# 6. VERHÄLTNIS ZUM BETRIEB
|
||
# =============================================================================
|
||
|
||
verhaeltnis_zum_betrieb:
|
||
|
||
beschreibung: |
|
||
SPM ist keine operative Betriebsführungsfunktion. Der laufende Betrieb
|
||
wird vom Operations Manager und den Betriebsteams verantwortet.
|
||
SPM erhält aggregierte Betriebsdaten (Qualitätsberichte, Monitoring-
|
||
Kennzahlen) und nutzt diese für die Portfolio-Steuerung.
|
||
|
||
asymmetrie_im_lifecycle:
|
||
erklaerung: |
|
||
SPM ist in Transition und Review aktiv steuernd, im laufenden
|
||
Betrieb aber passiv konsumierend. Das entspricht der Logik, dass
|
||
Betrieb operativ geführt wird und SPM nur die Portfolio-Sicht benötigt.
|
||
|
||
intensitaet_nach_phase:
|
||
- phase: "Transition"
|
||
spm_intensitaet: "Hoch"
|
||
spm_rolle: "Gate-Entscheidung (SOR), Katalogaufnahme"
|
||
|
||
- phase: "Review"
|
||
spm_intensitaet: "Hoch"
|
||
spm_rolle: "Aggregation, Portfolio-Block in SOR"
|
||
|
||
- phase: "Betrieb"
|
||
spm_intensitaet: "Niedrig"
|
||
spm_rolle: "Informiert, erhält konsolidierte Daten"
|
||
|
||
- phase: "Support"
|
||
spm_intensitaet: "Niedrig"
|
||
spm_rolle: "Informiert, keine direkte Rolle"
|
||
|
||
anknuepfungspunkte_fuer_betrieb:
|
||
- punkt: "Service-Steckbrief"
|
||
beschreibung: "Betriebsteam liefert Daten, SO pflegt"
|
||
|
||
- punkt: "Qualitätsbericht"
|
||
beschreibung: "Betriebsteam erstellt, SPM nutzt für Review-Aggregation"
|
||
|
||
- punkt: "SOR-Mitgliedschaft"
|
||
beschreibung: "Operations Manager ist ständiges Mitglied, bringt Betriebsperspektive ein"
|
||
|
||
- punkt: "Transition-Bewertung"
|
||
beschreibung: "Operations Manager bewertet Betriebsreife bei Gate 2"
|
||
|
||
bewusste_mvp_entscheidung: |
|
||
Im MVP wird der Service-Betrieb als "Strukturanker" modelliert, nicht als
|
||
vollständige Betriebsprozess-Definition. Diese Tiefenschärfe-Entscheidung
|
||
ermöglicht Fokus auf Governance-Strukturen, ohne operative Details
|
||
vorwegzunehmen, die mit DIGIT abgestimmt werden müssen.
|
||
|
||
referenz: "spm_konzept_service-betrieb-light.yaml"
|
||
|
||
# =============================================================================
|
||
# 7. PRACTICES (GEBÜNDELT IN SPM)
|
||
# =============================================================================
|
||
|
||
practices:
|
||
|
||
beschreibung: |
|
||
SPM bündelt mehrere Practices, für die der Service-Portfolio-Manager
|
||
als Practice Owner verantwortlich ist. Die Practices definieren das
|
||
"Was und Wie", die Funktion das "Wer und Warum".
|
||
|
||
practice_liste:
|
||
- id: "P-01"
|
||
name: "Service Catalog Management"
|
||
practice_owner: "SPM"
|
||
beschreibung: |
|
||
Stellt sicher, dass für jeden Service eine klare, aktuelle,
|
||
vollständige und verlässliche Beschreibung existiert.
|
||
referenz: "spm_practice_service-catalog-management.yaml"
|
||
|
||
- id: "P-02"
|
||
name: "Service Level Management"
|
||
practice_owner: "SPM"
|
||
beschreibung: |
|
||
Methodische Standards für Service Level Agreements und
|
||
deren Governance.
|
||
referenz: "spm_practice_service-level-management.yaml"
|
||
|
||
- id: "P-03"
|
||
name: "Change Enablement"
|
||
practice_owner: "SPM"
|
||
beschreibung: |
|
||
Steuerung von Changes an Services mit definierter
|
||
Change Authority je Change-Typ.
|
||
referenz: "spm_practice_change-enablement.yaml"
|
||
hinweis: "Change Authority für Normal Changes liegt bei SO"
|
||
|
||
weitere_practices_in_spm_kontext:
|
||
- name: "Service Support Management"
|
||
beschreibung: |
|
||
Incident, Request, Problem Management. Operative Verantwortung
|
||
bei Support Manager und Service Desk.
|
||
referenz: "spm_practice_service-support-management/"
|
||
spm_rolle: "Informiert, erhält Problem-Erkenntnisse für Review"
|
||
|
||
# =============================================================================
|
||
# 8. GOVERNANCE-ARCHITEKTUR
|
||
# =============================================================================
|
||
|
||
governance_architektur:
|
||
|
||
gremien_mit_spm_beteiligung:
|
||
|
||
- gremium: "SOR"
|
||
name: "Service Operations Runde"
|
||
spm_rolle: "Vorsitz"
|
||
governance_ebene: "koordinativ"
|
||
entscheidungsgegenstaende:
|
||
- "Go-Live-Freigabe (Gate 2)"
|
||
- "Service-Review-Entscheidungen (IMPROVEMENT ressourcenrelevant, REDESIGN, RETIRE)"
|
||
- "Major-Change-Autorisierungen (einmalig, inkl. Einstiegspunkt)"
|
||
- "Major-Katalogänderungen"
|
||
referenz: "spm_sor_go.yaml"
|
||
|
||
- gremium: "DSR"
|
||
name: "Demand & Stakeholder-Runde"
|
||
spm_rolle: "Mitglied (bei Unsicherheit über Demand-Klassifizierung und DPM-Rückkopplung)"
|
||
governance_ebene: "koordinativ"
|
||
spm_beitrag: "Service-Impact-Einschätzung, Unterstützung bei Routing-Klärungen (ROUTE-SO)"
|
||
governance_referenz: "GOV-SHM-029 (aktualisiert GOV-SOR-001)"
|
||
|
||
- gremium: "MB"
|
||
name: "Mission Board"
|
||
spm_rolle: "Berichtsrecht (kein Stimmrecht)"
|
||
governance_ebene: "taktisch"
|
||
entscheidungsgegenstaende_mit_spm_input:
|
||
- "Service-Kategorisierung (A/B/C)"
|
||
- "Major-SLAs und SLA-Abweichungen"
|
||
- "Strukturelle Katalogänderungen (Stilllegung, Kategorie-Wechsel)"
|
||
- "Ressourcen-Eskalationen aus SOR"
|
||
vertretung: "Leitung Planung vertritt SPM-Interessen"
|
||
|
||
- gremium: "VB"
|
||
name: "Vision Board"
|
||
spm_rolle: "Informiert (liefert E1)"
|
||
governance_ebene: "strategisch"
|
||
spm_beitrag: "Jahres-Portfolio-Report, strategische Portfolio-Empfehlungen"
|
||
|
||
entscheidungsmatrix_kurzform:
|
||
- entscheidung: "Gate 1 (Transition Entry)"
|
||
entscheider: "SOR"
|
||
spm_rolle: "SOR-Vorsitz"
|
||
|
||
- entscheidung: "Gate 2 (Entry-Prüfung nach Build)"
|
||
entscheider: "SO"
|
||
spm_rolle: "Informiert (bei Eskalation: Beratung)"
|
||
|
||
- entscheidung: "Gate 3 (Go-Live)"
|
||
entscheider: "SOR"
|
||
spm_rolle: "SOR-Vorsitz"
|
||
|
||
- entscheidung: "Katalog Minor"
|
||
entscheider: "SO + SPM"
|
||
spm_rolle: "Freigabe"
|
||
|
||
- entscheidung: "Katalog Major"
|
||
entscheider: "SOR"
|
||
spm_rolle: "SOR-Vorsitz"
|
||
|
||
- entscheidung: "Katalog Strukturell"
|
||
entscheider: "MB"
|
||
spm_rolle: "Vorlage"
|
||
|
||
- entscheidung: "SLA Standard"
|
||
entscheider: "SOR"
|
||
spm_rolle: "Governance-Prüfung"
|
||
|
||
- entscheidung: "SLA Abweichung"
|
||
entscheider: "MB"
|
||
spm_rolle: "Vorlage"
|
||
|
||
- entscheidung: "Service-Kategorisierung"
|
||
entscheider: "MB"
|
||
spm_rolle: "Empfehlung"
|
||
|
||
# =============================================================================
|
||
# 9. OFFENE PUNKTE
|
||
# =============================================================================
|
||
|
||
offene_punkte:
|
||
|
||
fuer_mvp_nicht_adressiert:
|
||
|
||
- id: "OPEN-SPM-001"
|
||
thema: "Quantitative Portfolio-KPIs"
|
||
beschreibung: |
|
||
Das MVP arbeitet primär qualitativ (Ampel-Aggregation).
|
||
Quantitative Portfolio-KPIs können später ergänzt werden.
|
||
status: "Post-MVP-Erweiterung"
|
||
|
||
- id: "OPEN-SPM-002"
|
||
thema: "SPM-Vertretungsregelung (Detail)"
|
||
beschreibung: |
|
||
Grundregel definiert. Detaillierte Regelung für Langzeitvertretung
|
||
und Kompetenzübertragung noch offen.
|
||
status: "Bei Bedarf zu klären"
|
||
|
||
- id: "OPEN-SPM-003"
|
||
thema: "Schnittstelle PPM"
|
||
beschreibung: |
|
||
Projekt→Service-Übergabe und Koordination bei Projekten mit
|
||
Service-Impact noch nicht detailliert.
|
||
status: "Bei PPM-Konzeption zu klären"
|
||
|
||
- id: "OPEN-SPM-004"
|
||
thema: "Tool-gestützte Portfolio-Steuerung"
|
||
beschreibung: |
|
||
Im MVP manuelle Aggregation durch SPM. Bei wachsendem Portfolio
|
||
kann Tool-Unterstützung sinnvoll werden.
|
||
status: "Post-MVP-Erweiterung"
|
||
|
||
aus_rollenbeschreibungen_uebernommen:
|
||
|
||
- id: "OPEN-SO-001"
|
||
thema: "Budget-Verantwortung SO für laufenden Betrieb"
|
||
quelle: "rolle_service-owner.yaml"
|
||
status: "Für MVP nicht adressiert"
|
||
|
||
- id: "OPEN-SO-002"
|
||
thema: "Disziplinarische Einordnung SO"
|
||
quelle: "rolle_service-owner.yaml"
|
||
status: "Für MVP nicht adressiert"
|
||
|
||
# =============================================================================
|
||
# 10. REFERENZEN
|
||
# =============================================================================
|
||
|
||
referenzen:
|
||
|
||
verwandte_dokumente:
|
||
- titel: "Rollenbeschreibung SPM"
|
||
pfad: "04_rollen/rolle_service-portfolio-manager.yaml"
|
||
unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch"
|
||
|
||
- titel: "Rollenbeschreibung SO"
|
||
pfad: "04_rollen/rolle_service-owner.yaml"
|
||
relevanz: "Zentrale operative Rolle innerhalb SPM-Funktion"
|
||
|
||
- titel: "SOR-Geschäftsordnung"
|
||
pfad: "01_spm_governance/spm_sor_go.yaml"
|
||
relevanz: "Gremien-Governance für Service-Entscheidungen"
|
||
|
||
- titel: "Practice Service Catalog Management"
|
||
pfad: "03_spm_practices/spm_practice_service-catalog-management.yaml"
|
||
relevanz: "Practice mit SPM als Practice Owner"
|
||
|
||
- titel: "Practice Service Level Management"
|
||
pfad: "03_spm_practices/spm_practice_service-level-management.yaml"
|
||
relevanz: "Practice mit SPM als Practice Owner"
|
||
|
||
- titel: "Practice Change Enablement"
|
||
pfad: "03_spm_practices/spm_practice_change-enablement.yaml"
|
||
relevanz: "Practice mit SPM als Practice Owner"
|
||
|
||
- titel: "Konzept Service Transition"
|
||
pfad: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml"
|
||
relevanz: "Gate-Struktur und Transition-Governance"
|
||
|
||
- titel: "Konzept Service Portfolio Review"
|
||
pfad: "02a_lifecycle-konzepte/spm_konzept_service-portfolio-review.yaml"
|
||
relevanz: "Review-Aggregation und Portfolio-Reporting"
|
||
|
||
- titel: "Governance-Entscheidungen-Log"
|
||
pfad: "spm_governance-entscheidungen-log.yaml"
|
||
relevanz: "Alle GOV-IDs mit SPM-Relevanz"
|
||
|
||
- titel: "DIGITOM Taxonomie"
|
||
pfad: "00_meta/digitom_taxonomie.yaml"
|
||
relevanz: "Konzeptuelle Grundlagen (Funktion, Practice, Rolle, Gremium)"
|
||
|
||
- titel: "DPM-Funktionsbeschreibung"
|
||
pfad: "01_demand-portfolio-management/dpm_funktionsbeschreibung.yaml"
|
||
relevanz: "Strukturvorlage; parallele Portfolio-Funktion"
|
||
|
||
# =============================================================================
|
||
# 11. ÄNDERUNGSHISTORIE
|
||
# =============================================================================
|
||
|
||
aenderungshistorie:
|
||
|
||
- version: "1.3"
|
||
datum: "2026-02-19"
|
||
aenderung: |
|
||
Major-Change-Governance vereinfacht (Kundenvorschlag):
|
||
- VB3a: "SOR-Autorisierung + Transition-Gates" → "SOR-Autorisierung (einmalig)"
|
||
- governance_architektur: Major-Change-Freigaben → Autorisierungen (einmalig)
|
||
Konsistent mit spm_practice_change-enablement.yaml v1.3
|
||
autor: "DIGITOM-Projekt"
|
||
|
||
- version: "1.2"
|
||
datum: "2026-02-19"
|
||
aenderung: |
|
||
Change Enablement (P-03) als dritte Practice durchgängig ergänzt:
|
||
- zweck.ausfuehrlich: CE als Practice Owner-Bereich ergänzt
|
||
- Z3 Practice Ownership: CE in Beschreibung und umfasst-Liste aufgenommen
|
||
- Neuer Verantwortungsbereich VB3a (Change Enablement) eingefügt
|
||
- konsolidierung.quellen: spm_practice_change-enablement.yaml ergänzt
|
||
- referenzen: Practice Change Enablement als verwandtes Dokument ergänzt
|
||
- abkuerzungen: CE ergänzt
|
||
Bisher war CE nur in der practice_liste (Abschnitt 7) enthalten,
|
||
fehlte aber in allen beschreibenden Passagen der Funktionsbeschreibung.
|
||
autor: "DIGITOM-Projekt"
|
||
|
||
- version: "1.1"
|
||
datum: "2026-02-18"
|
||
aenderung: |
|
||
Korrektur Gate-Zuordnungen (Konsistenzprüfung):
|
||
- Z2.umfasst: Gate-Auflistung korrigiert (Gate 1: SOR, Gate 2: SO, Gate 3: SOR) und Gate 3 ergänzt
|
||
- governance_architektur.entscheidungsmatrix_kurzform: Gate 1 = SOR, Gate 2 = SO, Gate 3 ergänzt
|
||
Bisher waren Gate 1 und Gate 2 vertauscht und Gate 3 fehlte vollständig.
|
||
autor: "DIGITOM-Projekt"
|
||
|
||
- version: "1.0"
|
||
datum: "2025-12-17"
|
||
aenderung: |
|
||
Initiale Erstellung der SPM-Funktionsbeschreibung.
|
||
|
||
Konsolidiert aus:
|
||
- rolle_service-portfolio-manager.yaml
|
||
- rolle_service-owner.yaml
|
||
- spm_sor_go.yaml
|
||
- spm_practice_service-catalog-management.yaml
|
||
- spm_practice_service-level-management.yaml
|
||
- spm_konzept_service-transition.yaml
|
||
- spm_konzept_service-portfolio-review.yaml
|
||
- spm_governance-entscheidungen-log.yaml
|
||
|
||
Strukturvorlage: dpm_funktionsbeschreibung.yaml
|
||
|
||
Neue Inhalte:
|
||
- Funktions-Charakterisierung ("Portfolio-Governance- und Lifecycle-Koordinationsfunktion")
|
||
- Vier Grundprinzipien (Portfolio vor Service, Governance nicht Inhalt,
|
||
Befähigung nicht Kontrolle, Transparenz durch Aggregation)
|
||
- Schnittstellen-Matrix (konsolidiert aus Rollen und Practices)
|
||
- Verhältnis zum Betrieb (Asymmetrie-Dokumentation)
|
||
- PPM-Schnittstelle als Placeholder
|
||
autor: "DIGITOM-Projekt" |