# ============================================================================= # 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"