From 9788e273ed7287c2d0e01ac11f118381dada3760 Mon Sep 17 00:00:00 2001 From: breitenbach76 Date: Mon, 23 Mar 2026 22:28:45 +0100 Subject: [PATCH] =?UTF-8?q?s=C3=A4uberung=20repo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../dpm_demand-klassifizierung.yaml | 1334 ++--- .../dpm_demand-portfolio-review.yaml | 806 +-- .../dpm_demand-portfolio_governance.yaml | 978 ++-- .../dpm_demand_bewertung.yaml | 960 ++-- .../dpm_demand_priorisierung.yaml | 840 +-- .../dpm_dsr-go.yaml | 800 +-- .../dpm_funktionsbeschreibung.yaml | 918 +-- ...pm_klassifizierungsmatrix_komplexität.yaml | 656 +-- .../dpm_klassifizierungsmatrix_tragweite.yaml | 588 +- .../dpm_raci.yaml | 1334 ++--- .../dpm_rollenbeschreibung-dpm.yaml | 984 ++-- .../demand-lifecycle-blueprint_phase-1.yaml | 244 +- .../demand-lifecycle-blueprint_phase-2.yaml | 140 +- .../demand-lifecycle-blueprint_phase-3.yaml | 146 +- .../spm_governance_framework.yaml | 2494 ++++---- .../spm_konzept_service-portfolio-review.yaml | 3180 +++++----- .../01_spm_governance/spm_sor_go.yaml | 2314 ++++---- .../service-lifecycle_design.yaml | 377 +- .../service-lifecycle_review.yaml | 536 +- .../service-lifecycle_transition.yaml | 1156 ++-- .../spm_rollen.yaml | 812 +-- .../spm_konzept_service-betrieb-light.yaml | 208 +- .../spm_konzept_service-review.yaml | 2158 +++---- .../spm_konzept_service-transition.yaml | 2170 +++---- .../spm_practice_change-enablement.yaml | 1686 +++--- ...m_practice_service-catalog-management.yaml | 1626 +++--- .../ssm_rollen.yaml | 1000 ++-- .../ssm_schema_ticket.yaml | 1978 +++---- .../ssm_wissensmanagement.yaml | 2426 ++++---- .../sub-practice_problem-management.yaml | 1684 +++--- .../sub-practice_request-management.yaml | 2492 ++++---- .../sub-practice_service-desk.yaml | 1578 ++--- .../04_rollen/rolle_service-owner.yaml | 1902 +++--- .../rolle_service-portfolio-manager.yaml | 2276 ++++---- .../spm_schema_service-definition.yaml | 2064 +++---- .../spm_schema_service-steckbrief.yaml | 1312 ++--- .../spm_schema_transition-steckbrief.yaml | 1264 ++-- .../06_template_ola-kategorie-i.yaml | 330 +- ..._leitfaden_sieben-fragen-orientierung.yaml | 372 +- .../spm_funktionsbeschreibung.yaml | 2222 +++---- .../spm_governance-entscheidungen-log.yaml | 5098 ++++++++--------- .../service-portfolio-management_glossar.yaml | 430 +- .../shm_funktionsbeschreibung.yaml | 40 +- .../#03.1_funktion/shm_rollen.yaml | 1632 +++--- .../shm_governance-framework.yaml | 2336 ++++---- .../#03.2_governance/shm_raci.yaml | 3078 +++++----- .../shm_engagement-framework.yaml | 3614 ++++++------ .../shm_lifecycle-blueprint.yaml | 40 +- .../#03.3_konzepte/shm_sims-konzept.yaml | 1398 ++--- .../shm_stakeholder-portfolio.yaml | 1898 +++--- .../#03.3_konzepte/shm_voice-of-customer.yaml | 2140 +++---- .../#03.4_methodik/shm_bedarfsbewertung.yaml | 2356 ++++---- ..._koordinations-und-steuerungsstruktur.yaml | 1706 +++--- .../#03.4_methodik/shm_voice-of-customer.yaml | 66 - .../shm_sor-integration.yaml | 40 +- .../shm_schema_bedarfssteckbrief.yaml | 2270 ++++---- .../shm_interne-bedarfe-routing.yaml | 1134 ++-- .../shm_leitfaden_user-stories.yaml | 938 +-- .../shm_sims-konzept.yaml | 20 - ...adme_shm_governance-entscheidungs-log.yaml | 2722 ++++----- #04_mission-board/mb_geschaeftsordnung.yaml | 2270 ++++---- .../pm_funktionsbeschreibung.yaml | 1674 +++--- .../pm_governance-framework.yaml | 1056 ++-- .../#05.2_governance/pm_raci.yaml | 1442 ++--- .../#05.3_konzepte/pm_konzeptrahmen.yaml | 526 +- .../#05.3_konzepte/pm_leistungs-canvas.yaml | 962 ++-- .../#05.3_konzepte/pm_pilot-konzept.yaml | 337 -- .../#05.4_rollen/pm_rollenmodell.yaml | 324 +- .../#05.4_rollen/rolle_auftraggeber-pm.yaml | 138 +- .../#05.4_rollen/rolle_gremien.yaml | 142 +- .../#05.4_rollen/rolle_isb-dsb.yaml | 80 +- .../#05.4_rollen/rolle_it-architektur.yaml | 86 +- .../rolle_key-user-netzwerk-manager.yaml | 114 +- .../#05.4_rollen/rolle_key-user.yaml | 118 +- .../#05.4_rollen/rolle_leiter-pm.yaml | 122 +- .../#05.4_rollen/rolle_process-owner.yaml | 160 +- .../#05.4_rollen/rolle_prozess-berater.yaml | 114 +- .../rolle_prozess-framework-manager.yaml | 128 +- .../rolle_prozesslandschafts-koordinator.yaml | 130 +- #05_prozessmanagement/pm_uebersicht.yaml | 706 +-- 80 files changed, 47758 insertions(+), 48172 deletions(-) delete mode 100644 #03_stakeholder-management/#03.4_methodik/shm_voice-of-customer.yaml delete mode 100644 #03_stakeholder-management/#03.7_arbeitsmaterialien/shm_sims-konzept.yaml delete mode 100644 #05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-klassifizierung.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-klassifizierung.yaml index aa44138..25e64b0 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-klassifizierung.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-klassifizierung.yaml @@ -1,668 +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" +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" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml index 2365bf0..e5cdcd0 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml @@ -1,403 +1,403 @@ -meta: - typ: "review_framework" - framework_name: "Demand-Portfolio Review" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen: true - abgenommen_in_gesamtkonzept: false - - kontext_tags: - - "review" - - "demand-portfolio" - - "governance" - - "kpi" - - "kontinuierliche-verbesserung" - - "quartalsweise" - -# ======================================== -# 1. ZWECK UND ZIELSETZUNG -# ======================================== - -zweck_und_zielsetzung: - kernaussage: > - Das quartalsweise Demand-Portfolio Review dient der systematischen Analyse - der Demand-Portfolio-Dynamik und der kontinuierlichen Verbesserung des - Demand-Management-Prozesses. Es identifiziert Muster, bewertet die - Systemgesundheit und leitet strategische Erkenntnisse für das Mission Board ab. - - kernziele: - - id: "KZ-1" - name: "Mustererkennung" - beschreibung: "Identifikation wiederkehrender Themen und Herausforderungen" - - - id: "KZ-2" - name: "Workflow-Optimierung" - beschreibung: "Ableitung von Verbesserungspotenzialen" - - - id: "KZ-3" - name: "Strategische Rueckkopplung" - beschreibung: "Erkenntnisse fuer uebergeordnete Steuerungsentscheidungen" - - - id: "KZ-4" - name: "Qualitaetssicherung" - beschreibung: "Ueberpruefung der Governance-Effektivitaet" - -# ======================================== -# 2. TEILNEHMER:INNEN UND VERANTWORTLICHKEITEN -# ======================================== - -teilnehmer_verantwortlichkeiten: - - rollen: - - rolle_id: "al_planung" - name: "AL Planung" - funktion: "Leitung" - verantwortung: - - "Einberufung" - - "Moderation" - - "Ergebniskonsolidierung" - - "MB-Berichterstattung" - - - rolle_id: "dpm" - name: "DPM" - funktion: "Datenverantwortung" - verantwortung: - - "Datenaufbereitung" - - "Portfolio-Analyse" - - "Priorisierungs-Retrospektive" - - - rolle_id: "ppm" - name: "PPM" - funktion: "Projekt-Perspektive" - verantwortung: - - "Projekt-Pipeline-Analyse" - - "Ressourcenauslastung" - - "Umsetzungs-Feedback" - - - rolle_id: "spm" - name: "SPM" - funktion: "Service-Perspektive" - verantwortung: - - "Service-Impact-Analyse" - - "Betriebsbereitschaft" - - "Transition-Erfahrungen" - - - rolle_id: "shm" - name: "SHM" - funktion: "Stakeholder-Perspektive" - verantwortung: - - "Stakeholder-Trends" - - "Bedarfsmuster" - - "Kommunikations-Feedback" - -# ======================================== -# 3. TURNUS UND ZEITPLANUNG -# ======================================== - -turnus_zeitplanung: - - regelmaessigkeit: - frequenz: "quartalsweise" - zeitpunkt: "erste Monatshaelfte nach Quartalsende" - dauer: "3 Stunden (inkl. Pausen)" - vorlaufzeit_unterlagen: "1 Woche vor Termin" - - zeitlicher_ablauf: - - zeitpunkt: "T-14 Tage" - verantwortlich: "AL Planung" - aktivitaeten: - - "Prozess initiieren" - - "Reminder verschicken" - - "Datensammlung beginnen" - - - zeitpunkt: "T-10 Tage" - verantwortlich: "DPM" - aktivitaeten: - - "Aktualisierung Portfolio-Uebersichten" - - - zeitpunkt: "T-7 Tage" - verantwortlich: "DSR + AL-P" - aktivitaeten: - - "Input zu Beobachtungen/Mustern an DPM" - - - zeitpunkt: "T-3 Tage" - verantwortlich: "DPM" - aktivitaeten: - - "Verteilung Analysebericht (Draft) an DSR + AL-P" - - - zeitpunkt: "T-1 Tag" - verantwortlich: "DSR + AL-P" - aktivitaeten: - - "Durchsicht der Unterlagen" - - - zeitpunkt: "T-0 Tage" - verantwortlich: "DSR + AL-P" - aktivitaeten: - - "Review-Durchfuehrung" - - - zeitpunkt: "T+7 Tage" - verantwortlich: "DPM" - aktivitaeten: - - "Verteilung des Review-Berichts an DSR + AL-P" - - - zeitpunkt: "T+14 Tage" - verantwortlich: "AL Planung / DPM" - aktivitaeten: - - "MB-Berichterstattung (Praesentation + Review-Bericht)" - -# ======================================== -# 4. VORBEREITUNG -# ======================================== - -vorbereitung: - - # ---------------------------------- - # 4.1 DATENSAMMLUNG - # ---------------------------------- - - datensammlung: - verantwortlich: "DPM" - beschreibung: "Aufbereitung der Demand-Portfolio-Daten anhand des Demand-KPI-Frameworks" - referenz: - dokument: "Demand-KPI-Framework" - seite: 58 - - # ---------------------------------- - # 4.2 VORANALYSE - # ---------------------------------- - - voranalyse: - verantwortlich: "DPM" - beschreibung: "Strukturierte Voranalyse" - - bestandteile: - - - id: "VA-1" - name: "KPI-Auswertung" - inhalte: - - "Aufbereitung aller KPIs gemaess Demand-KPI-Framework" - - "Vergleich mit Vorquartal (Trends)" - - "Identifikation von Ausreissern und Auffaelligkeiten" - - - id: "VA-2" - name: "Musteranalyse" - inhalte: - - "Clustering der Demand-Themen" - - "Analyse wiederkehrender Ablehnungsgruende" - - "Identifikation systematischer Verzoegerungen" - - "Stakeholder-Verhaltensmuster" - - - id: "VA-3" - name: "Deep-Dive Vorbereitung" - inhalte: - - "Liste lange liegender Demands mit Handlungsempfehlung" - - "Analyse der Wiedervorlagen" - - "Dokumentation kritischer Einzelfaelle" - - "Prozess-Bottleneck-Analyse" - - - id: "VA-4" - name: "Optimierungs-Massnahmen-Review" - inhalte: - - "Status offener Optimierungsmassnahmen aus dem Massnahmenkatalog" - - "Wirksamkeit umgesetzter Massnahmen" - - "Neue Optimierungspotenziale" - - # ---------------------------------- - # 4.3 UNTERLAGENERSTELLUNG - # ---------------------------------- - - unterlagenerstellung: - versand: "T-3 Tage" - name: "Review-Package" - - bestandteile: - - - id: "UP-1" - name: "Management Summary" - umfang: "1 Seite" - inhalte: - - "Quartals-Highlights" - - "Kritische Entwicklungen" - - "Top-3 Handlungsbedarfe" - - - id: "UP-2" - name: "KPI-Dashboard" - inhalte: - - "Alle Metriken mit Trend und Bewertung" - - "Grafische Aufbereitung der Entwicklung" - - "Kommentierung von Auffaelligkeiten" - - - id: "UP-3" - name: "Demand-Portfolio-Uebersicht" - inhalte: - - "Aktueller Bestand nach Status" - - "Demand-Pipeline-Visualisierung" - - "Thematische Verteilung" - - - id: "UP-4" - name: "Detailanalysen" - inhalte: - - "Durchlaufzeit-Analyse" - - "Entscheidungsanalyse" - - "Engpass-Dokumentation" - - - id: "UP-5" - name: "Anhaenge" - inhalte: - - "Standard-Agenda mit Zeitplan" - - "Status Massnahmenkatalog" - -# ======================================== -# 5. DOKUMENTATION UND BERICHTERSTATTUNG -# ======================================== - -dokumentation_berichterstattung: - - # ---------------------------------- - # 5.1 REVIEW-ERGEBNISDOKUMENT - # ---------------------------------- - - review_ergebnisdokument: - name: "Review-Ergebnisbericht" - - struktur: - - - id: "EB-1" - name: "Executive Summary" - inhalte: - - "Top-3-Erkenntnisse" - - "Kritische Handlungsfelder" - - "Empfohlene Sofortmassnahmen" - - - id: "EB-2" - name: "Portfolio-Performance" - inhalte: - - "KPIs mit Trend" - - "Demand-Zusammensetzung" - - "Durchlauf-Analyse" - - - id: "EB-3" - name: "Musteranalyse" - inhalte: - - "Identifizierte Trends" - - "Wiederkehrende Herausforderungen" - - "Positive Entwicklungen" - - - id: "EB-4" - name: "Handlungsempfehlungen" - inhalte: - - "Priorisierte Massnahmenliste" - - "Verantwortlichkeiten und Zeitrahmen" - - "Erwarteter Impact" - - - id: "EB-5" - name: "Anhang" - inhalte: - - "Detaildaten" - - "Einzelfallanalysen" - - "Prozessverbesserungsvorschlaege" - - # ---------------------------------- - # 5.2 MISSION BOARD PRAESENTATION - # ---------------------------------- - - mission_board_praesentation: - format: "Informationspunkt in naechster MB-Sitzung" - umfang: "10-15 Minuten Praesentation + Diskussion" - - inhalt: - - "Portfolio-Entwicklung im Ueberblick" - - "Zentrale Erkenntnisse und Muster" - - "Kritische Handlungsbedarfe" - - "Empfehlungen fuer strategische Anpassungen" - -# ======================================== -# 6. KONTINUIERLICHE VERBESSERUNG -# ======================================== - -kontinuierliche_verbesserung: - - optimierung_review_prozess: - aktivitaeten: - - "Jaehrliche Evaluation der Review-Methodik" - - "Anpassung der KPIs" - - "Integration neuer Analysedimensionen bei Bedarf" - - lessons_learned_integration: - aktivitaeten: - - "Systematische Erfassung von Prozessverbesserungen" - - "Best Practice Dokumentation" - - "Wissenstransfer in die Organisation" - -# ======================================== -# 7. WERKZEUGE UND VORLAGEN -# ======================================== - -werkzeuge_vorlagen: - - benoetigte_unterlagen: - - id: "WV-1" - name: "Demand-Portfolio-Export" - status: "erforderlich" - - - id: "WV-2" - name: "DSR-Protokolle des Quartals" - status: "erforderlich" - - - id: "WV-3" - name: "MB-Entscheidungsprotokolle" - status: "erforderlich" - - - id: "WV-4" - name: "Stakeholder-Feedback-Sammlung" - status: "erforderlich" - -# ======================================== -# 8. PILOTPHASE-SPEZIFIKA -# ======================================== - -pilotphase_spezifika: - - waehrend_pilotphase: - charakteristiken: - - aspekt: "Keine festen Benchmarks" - beschreibung: "Sammlung von Baseline-Daten" - - - aspekt: "Experimenteller Charakter" - beschreibung: "Iterative Anpassung der Methodik" - - - aspekt: "Fokus auf Lernen" - beschreibung: "Identifikation sinnvoller KPIs" - - - aspekt: "Dokumentation" - beschreibung: "Besonders sorgfaeltige Erfassung fuer spaetere Evaluation" - - nach_2_3_reviews: - aktivitaeten: - - "Definition realistischer Zielwerte" - - "Festlegung kritischer Schwellenwerte" - - "Standardisierung der Analysemethoden" - -# ======================================== -# REFERENZEN -# ======================================== - -referenzen: - - interne_dokumente: - - titel: "Demand-KPI-Framework" - seite: 58 - relevanz: "Grundlage fuer Datensammlung und KPI-Auswertung" - - - titel: "Demand-Portfolio Governance" - pfad: "#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml" - relevanz: "Uebergeordnetes Governance-Framework" - - - titel: "DSR-Geschaeftsordnung" - relevanz: "Operative Regelungen fuer DSR" - - - titel: "Massnahmenkatalog" - relevanz: "Tracking von Optimierungsmassnahmen" +meta: + typ: "review_framework" + framework_name: "Demand-Portfolio Review" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen: true + abgenommen_in_gesamtkonzept: false + + kontext_tags: + - "review" + - "demand-portfolio" + - "governance" + - "kpi" + - "kontinuierliche-verbesserung" + - "quartalsweise" + +# ======================================== +# 1. ZWECK UND ZIELSETZUNG +# ======================================== + +zweck_und_zielsetzung: + kernaussage: > + Das quartalsweise Demand-Portfolio Review dient der systematischen Analyse + der Demand-Portfolio-Dynamik und der kontinuierlichen Verbesserung des + Demand-Management-Prozesses. Es identifiziert Muster, bewertet die + Systemgesundheit und leitet strategische Erkenntnisse für das Mission Board ab. + + kernziele: + - id: "KZ-1" + name: "Mustererkennung" + beschreibung: "Identifikation wiederkehrender Themen und Herausforderungen" + + - id: "KZ-2" + name: "Workflow-Optimierung" + beschreibung: "Ableitung von Verbesserungspotenzialen" + + - id: "KZ-3" + name: "Strategische Rueckkopplung" + beschreibung: "Erkenntnisse fuer uebergeordnete Steuerungsentscheidungen" + + - id: "KZ-4" + name: "Qualitaetssicherung" + beschreibung: "Ueberpruefung der Governance-Effektivitaet" + +# ======================================== +# 2. TEILNEHMER:INNEN UND VERANTWORTLICHKEITEN +# ======================================== + +teilnehmer_verantwortlichkeiten: + + rollen: + - rolle_id: "al_planung" + name: "AL Planung" + funktion: "Leitung" + verantwortung: + - "Einberufung" + - "Moderation" + - "Ergebniskonsolidierung" + - "MB-Berichterstattung" + + - rolle_id: "dpm" + name: "DPM" + funktion: "Datenverantwortung" + verantwortung: + - "Datenaufbereitung" + - "Portfolio-Analyse" + - "Priorisierungs-Retrospektive" + + - rolle_id: "ppm" + name: "PPM" + funktion: "Projekt-Perspektive" + verantwortung: + - "Projekt-Pipeline-Analyse" + - "Ressourcenauslastung" + - "Umsetzungs-Feedback" + + - rolle_id: "spm" + name: "SPM" + funktion: "Service-Perspektive" + verantwortung: + - "Service-Impact-Analyse" + - "Betriebsbereitschaft" + - "Transition-Erfahrungen" + + - rolle_id: "shm" + name: "SHM" + funktion: "Stakeholder-Perspektive" + verantwortung: + - "Stakeholder-Trends" + - "Bedarfsmuster" + - "Kommunikations-Feedback" + +# ======================================== +# 3. TURNUS UND ZEITPLANUNG +# ======================================== + +turnus_zeitplanung: + + regelmaessigkeit: + frequenz: "quartalsweise" + zeitpunkt: "erste Monatshaelfte nach Quartalsende" + dauer: "3 Stunden (inkl. Pausen)" + vorlaufzeit_unterlagen: "1 Woche vor Termin" + + zeitlicher_ablauf: + - zeitpunkt: "T-14 Tage" + verantwortlich: "AL Planung" + aktivitaeten: + - "Prozess initiieren" + - "Reminder verschicken" + - "Datensammlung beginnen" + + - zeitpunkt: "T-10 Tage" + verantwortlich: "DPM" + aktivitaeten: + - "Aktualisierung Portfolio-Uebersichten" + + - zeitpunkt: "T-7 Tage" + verantwortlich: "DSR + AL-P" + aktivitaeten: + - "Input zu Beobachtungen/Mustern an DPM" + + - zeitpunkt: "T-3 Tage" + verantwortlich: "DPM" + aktivitaeten: + - "Verteilung Analysebericht (Draft) an DSR + AL-P" + + - zeitpunkt: "T-1 Tag" + verantwortlich: "DSR + AL-P" + aktivitaeten: + - "Durchsicht der Unterlagen" + + - zeitpunkt: "T-0 Tage" + verantwortlich: "DSR + AL-P" + aktivitaeten: + - "Review-Durchfuehrung" + + - zeitpunkt: "T+7 Tage" + verantwortlich: "DPM" + aktivitaeten: + - "Verteilung des Review-Berichts an DSR + AL-P" + + - zeitpunkt: "T+14 Tage" + verantwortlich: "AL Planung / DPM" + aktivitaeten: + - "MB-Berichterstattung (Praesentation + Review-Bericht)" + +# ======================================== +# 4. VORBEREITUNG +# ======================================== + +vorbereitung: + + # ---------------------------------- + # 4.1 DATENSAMMLUNG + # ---------------------------------- + + datensammlung: + verantwortlich: "DPM" + beschreibung: "Aufbereitung der Demand-Portfolio-Daten anhand des Demand-KPI-Frameworks" + referenz: + dokument: "Demand-KPI-Framework" + seite: 58 + + # ---------------------------------- + # 4.2 VORANALYSE + # ---------------------------------- + + voranalyse: + verantwortlich: "DPM" + beschreibung: "Strukturierte Voranalyse" + + bestandteile: + + - id: "VA-1" + name: "KPI-Auswertung" + inhalte: + - "Aufbereitung aller KPIs gemaess Demand-KPI-Framework" + - "Vergleich mit Vorquartal (Trends)" + - "Identifikation von Ausreissern und Auffaelligkeiten" + + - id: "VA-2" + name: "Musteranalyse" + inhalte: + - "Clustering der Demand-Themen" + - "Analyse wiederkehrender Ablehnungsgruende" + - "Identifikation systematischer Verzoegerungen" + - "Stakeholder-Verhaltensmuster" + + - id: "VA-3" + name: "Deep-Dive Vorbereitung" + inhalte: + - "Liste lange liegender Demands mit Handlungsempfehlung" + - "Analyse der Wiedervorlagen" + - "Dokumentation kritischer Einzelfaelle" + - "Prozess-Bottleneck-Analyse" + + - id: "VA-4" + name: "Optimierungs-Massnahmen-Review" + inhalte: + - "Status offener Optimierungsmassnahmen aus dem Massnahmenkatalog" + - "Wirksamkeit umgesetzter Massnahmen" + - "Neue Optimierungspotenziale" + + # ---------------------------------- + # 4.3 UNTERLAGENERSTELLUNG + # ---------------------------------- + + unterlagenerstellung: + versand: "T-3 Tage" + name: "Review-Package" + + bestandteile: + + - id: "UP-1" + name: "Management Summary" + umfang: "1 Seite" + inhalte: + - "Quartals-Highlights" + - "Kritische Entwicklungen" + - "Top-3 Handlungsbedarfe" + + - id: "UP-2" + name: "KPI-Dashboard" + inhalte: + - "Alle Metriken mit Trend und Bewertung" + - "Grafische Aufbereitung der Entwicklung" + - "Kommentierung von Auffaelligkeiten" + + - id: "UP-3" + name: "Demand-Portfolio-Uebersicht" + inhalte: + - "Aktueller Bestand nach Status" + - "Demand-Pipeline-Visualisierung" + - "Thematische Verteilung" + + - id: "UP-4" + name: "Detailanalysen" + inhalte: + - "Durchlaufzeit-Analyse" + - "Entscheidungsanalyse" + - "Engpass-Dokumentation" + + - id: "UP-5" + name: "Anhaenge" + inhalte: + - "Standard-Agenda mit Zeitplan" + - "Status Massnahmenkatalog" + +# ======================================== +# 5. DOKUMENTATION UND BERICHTERSTATTUNG +# ======================================== + +dokumentation_berichterstattung: + + # ---------------------------------- + # 5.1 REVIEW-ERGEBNISDOKUMENT + # ---------------------------------- + + review_ergebnisdokument: + name: "Review-Ergebnisbericht" + + struktur: + + - id: "EB-1" + name: "Executive Summary" + inhalte: + - "Top-3-Erkenntnisse" + - "Kritische Handlungsfelder" + - "Empfohlene Sofortmassnahmen" + + - id: "EB-2" + name: "Portfolio-Performance" + inhalte: + - "KPIs mit Trend" + - "Demand-Zusammensetzung" + - "Durchlauf-Analyse" + + - id: "EB-3" + name: "Musteranalyse" + inhalte: + - "Identifizierte Trends" + - "Wiederkehrende Herausforderungen" + - "Positive Entwicklungen" + + - id: "EB-4" + name: "Handlungsempfehlungen" + inhalte: + - "Priorisierte Massnahmenliste" + - "Verantwortlichkeiten und Zeitrahmen" + - "Erwarteter Impact" + + - id: "EB-5" + name: "Anhang" + inhalte: + - "Detaildaten" + - "Einzelfallanalysen" + - "Prozessverbesserungsvorschlaege" + + # ---------------------------------- + # 5.2 MISSION BOARD PRAESENTATION + # ---------------------------------- + + mission_board_praesentation: + format: "Informationspunkt in naechster MB-Sitzung" + umfang: "10-15 Minuten Praesentation + Diskussion" + + inhalt: + - "Portfolio-Entwicklung im Ueberblick" + - "Zentrale Erkenntnisse und Muster" + - "Kritische Handlungsbedarfe" + - "Empfehlungen fuer strategische Anpassungen" + +# ======================================== +# 6. KONTINUIERLICHE VERBESSERUNG +# ======================================== + +kontinuierliche_verbesserung: + + optimierung_review_prozess: + aktivitaeten: + - "Jaehrliche Evaluation der Review-Methodik" + - "Anpassung der KPIs" + - "Integration neuer Analysedimensionen bei Bedarf" + + lessons_learned_integration: + aktivitaeten: + - "Systematische Erfassung von Prozessverbesserungen" + - "Best Practice Dokumentation" + - "Wissenstransfer in die Organisation" + +# ======================================== +# 7. WERKZEUGE UND VORLAGEN +# ======================================== + +werkzeuge_vorlagen: + + benoetigte_unterlagen: + - id: "WV-1" + name: "Demand-Portfolio-Export" + status: "erforderlich" + + - id: "WV-2" + name: "DSR-Protokolle des Quartals" + status: "erforderlich" + + - id: "WV-3" + name: "MB-Entscheidungsprotokolle" + status: "erforderlich" + + - id: "WV-4" + name: "Stakeholder-Feedback-Sammlung" + status: "erforderlich" + +# ======================================== +# 8. PILOTPHASE-SPEZIFIKA +# ======================================== + +pilotphase_spezifika: + + waehrend_pilotphase: + charakteristiken: + - aspekt: "Keine festen Benchmarks" + beschreibung: "Sammlung von Baseline-Daten" + + - aspekt: "Experimenteller Charakter" + beschreibung: "Iterative Anpassung der Methodik" + + - aspekt: "Fokus auf Lernen" + beschreibung: "Identifikation sinnvoller KPIs" + + - aspekt: "Dokumentation" + beschreibung: "Besonders sorgfaeltige Erfassung fuer spaetere Evaluation" + + nach_2_3_reviews: + aktivitaeten: + - "Definition realistischer Zielwerte" + - "Festlegung kritischer Schwellenwerte" + - "Standardisierung der Analysemethoden" + +# ======================================== +# REFERENZEN +# ======================================== + +referenzen: + + interne_dokumente: + - titel: "Demand-KPI-Framework" + seite: 58 + relevanz: "Grundlage fuer Datensammlung und KPI-Auswertung" + + - titel: "Demand-Portfolio Governance" + pfad: "#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml" + relevanz: "Uebergeordnetes Governance-Framework" + + - titel: "DSR-Geschaeftsordnung" + relevanz: "Operative Regelungen fuer DSR" + + - titel: "Massnahmenkatalog" + relevanz: "Tracking von Optimierungsmassnahmen" diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml index 0fd4990..3be1f55 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml @@ -1,490 +1,490 @@ -meta: - typ: "governance_framework" - framework_name: "Demand-Portfolio Governance" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - abgestimmt_zwischen: ["human", "DPM-Teammitglied"] - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - kontext_tags: - - "governance" - - "demand-portfolio" - - "steuerung" - - "entscheidungsarchitektur" - - "portfolio-management" - -# ======================================== -# 1. ZWECK UND GELTUNGSBEREICH -# ======================================== - -zweck_und_geltungsbereich: - zweck: - kernaussage: "Orchestriert den Fluss von Bedarfen durch die DIGIT-Organisation" - - fluss: - start: "Erste Erfassung eines Stakeholder-Wunsches" - ende: "Integration als laufender Service" - - ergaenzung_zu: "DSR-Geschäftsordnung" - ergaenzungs_perspektive: "Übergreifende Steuerungsperspektive" - - zentrale_klaerungen: - - thema: "Rolle des Demand-Portfolio-Managements" - klarstellung: "Zentrale Priorisierungsinstanz" - - - thema: "Portfolio-Überwachung" - klarstellung: "Mechanismen zur Portfolio-Überwachung definiert" - - verweis_portfolio_kontext: - dokument: "DIGITOM-Portfolio-Governance + Kernprozesse" - inhalt: "Details zu den drei Portfolios und Kernprozessen (Demand-Lifecycle (Change) & Service-Lifecycle (Run))" - -# ======================================== -# 2. GOVERNANCE-ARCHITEKTUR -# ======================================== - -governance_architektur: - - # ---------------------------------- - # 2.1 ENTSCHEIDUNGSEBENEN - # ---------------------------------- - - entscheidungsebenen: - beschreibung: "DIGITOM definiert vier Entscheidungsinstanzen mit unterschiedlichen Kompetenzen" - anzahl: 4 - - ebenen: - - ebene_id: "vision_board" - name: "Vision Board" - ebene: "strategisch" - - verantwortlichkeiten: - - "Verantwortet das Operating Model" - - "Setzt strategische Leitplanken für die Digitalisierung" - - entscheidungen: - - "Grundlegende Governance-Änderungen" - - "Investitionsschwerpunkte" - - hierarchie_stufe: 4 - - - ebene_id: "mission_board" - name: "Mission Board" - ebene: "taktisch-strategisch" - - entscheidungen: - - typ: "MB-Demands" - beispiele: ["transformative Anforderungen", "hochkomplexe Anforderungen"] - - typ: "Gesamtressourcenallokation" - beschreibung: "Steuert die Gesamtressourcenallokation" - - typ: "Konfliktlösung" - beschreibung: "Löst Konflikte zwischen Abteilungen" - - informations_input: - - quelle: "quartals_portfolio_reviews" - frequenz: "quartalsweise" - von: "abteilungsleitung_planung" - - hierarchie_stufe: 3 - - - ebene_id: "abteilungsleitung_planung" - name: "Abteilungsleitung Planung" - kurzform: "AL-P" - ebene: "taktisch" - - verantwortlichkeiten: - - "Quartalsweise Portfolio-Reviews" - - "Disziplinarische Führung des DPM" - - funktion: "Brücke zwischen operativer Portfolio-Steuerung und taktischer Entscheidungsebene" - - aufgaben: - - "Portfolio-Muster und -Trends analysieren" - - "Erkenntnisse ableiten" - - "Berichten ans Mission Board" - - eskalation: - bedingung: "bei strategischer Relevanz" - an: "vision_board" - - hierarchie_stufe: 2 - - - ebene_id: "dsr" - name: "Demand & Stakeholder Runde" - kurzform: "DSR" - ebene: "operativ-taktisch" - - entscheidungen: - - typ: "DSR-Demands" - optionen: ["Freigabe", "Ablehnung", "Zurückstellung"] - - delegation: - kann_delegieren_an: "mission_board" - bedingung: "bei entsprechendem Klassifizierungsmuster" - - hierarchie_stufe: 1 - - referenz: - dokument: "dsr-geschaeftsordnung.yaml" - pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" - - - ebene_id: "dpm" - name: "Demand-Portfolio-Management" - kurzform: "DPM" - ebene: "operativ" - typ: "fachrolle" - - verantwortlichkeiten: - - "Klassifizierung aller Demands im Portfolio" - - "Analyse aller Demands im Portfolio" - - "Bewertung aller Demands im Portfolio" - - "Priorisierung aller Demands im Portfolio" - - output: "Entscheidungsvorlage für jeweiliges Entscheidungsgremium" - - governance_prinzip: - trennung: "Entscheidungsgremium ≠ DPM" - - sicherstellung: - - aspekt: "Fachlich-objektive Arbeit" - durch: "dpm" - umfasst: ["Klassifizierung", "Analyse", "Bewertung", "Priorisierung"] - - - aspekt: "Multiperspektivische Freigabe" - durch: ["dsr", "mission_board"] - umfasst: "Finale Entscheidung unter Berücksichtigung aller Perspektiven" - - referenzen: - - dokument: "DSR-Geschäftsordnung" - pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" - - dokument: "Rollenbeschreibung DPM" - pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" - - abschnitt: "Schnittstellen und Verantwortlichkeiten" - siehe: "Abschnitt 5 in diesem Dokument" - - # ---------------------------------- - # 2.2 ENTSCHEIDUNGS-ROUTING - # ---------------------------------- - - entscheidungs_routing: - beschreibung: "Systematische Zuordnung von Demands zu Entscheidungsebenen" - - basis: "Klassifizierungslogik auf vier Dimensionen" - - dimensionen: - - id: "treiber" - name: "Treiber" - bedeutung: "Impulsquelle" - - - id: "tragweite" - name: "Tragweite" - bedeutung: "Veränderungstiefe" - - - id: "systemebene" - name: "Systemebene" - bedeutung: "Technisch-fachliche Verortung" - - - id: "komplexitaet" - name: "Komplexität" - bedeutung: "Lösungsunsicherheit" - - routing_optionen: - - ziel: "mission_board" - beschreibung: "Direkt an Mission Board" - trigger: ["hochkomplex", "transformativ"] - - - ziel: "dsr_mit_delegationsoption" - beschreibung: "An DSR mit Option zur Delegation ans Mission Board" - trigger: "entsprechendes Klassifizierungsmuster" - - - ziel: "dsr" - beschreibung: "An DSR ohne Delegationsoption" - trigger: "inkrementelle Themen" - - prinzip: | - Entscheidungen werden auf der zuständigen Organisationsebene getroffen: - - Hochkomplexe und transformative Demands → Mission Board - - Inkrementelle Themen → Demand & Stakeholder-Runde - - referenz: - dokument: "Demand-Klassifizierung" - abschnitt: "3.2 Routing-Logik: Die Klassifizierung bestimmt die Entscheidungsebene" - pfad: "#01.4_methodik/demand-klassifizierung.yaml" - -# ======================================== -# 3. DEMAND-PORTFOLIO-STEUERUNG UND REVIEWS -# ======================================== - -portfolio_steuerung: - - # ---------------------------------- - # 3.1 STEUERUNGSEBENE DSR - # ---------------------------------- - - steuerungsebene_dsr: - ebene: "Demand & Stakeholder-Runde" - - aufgaben: - - id: "DSR-E1" - name: "Entscheidung über DSR-Demands" - optionen: ["Freigabe", "Ablehnung", "Zurückstellung"] - - - id: "DSR-E2" - name: "Delegations-Entscheidung" - beschreibung: "Entscheidung über Delegation von Demands ans Mission Board" - - - id: "DSR-I1" - name: "Feedback-Aufnahme" - beschreibung: "Aufnahme von Feedback zu laufenden Umsetzungen" - - - id: "DSR-P1" - name: "Problemklärung" - beschreibung: "Klärung akuter Problemstellungen" - - referenzen: - - dokument: "DSR-Geschäftsordnung" - pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" - - dokument: "DSR Standard-Agenda" - pfad: "#01.3_prozesse/dsr-standard-agenda.yaml" - - # ---------------------------------- - # 3.2 STEUERUNGSEBENE MISSION BOARD - # ---------------------------------- - - steuerungsebene_mission_board: - ebene: "Mission Board" - - aufgaben: - - id: "MB-E1" - name: "Freigabe von MB-Demands" - beschreibung: "Entscheidung über hochkomplexe und transformative Demands" - - - id: "MB-K1" - name: "Ressourcenkonflikte lösen" - beschreibung: "Auflösung von Ressourcenkonflikten zwischen Abteilungen" - - - id: "MB-S1" - name: "Gesamtportfolio steuern" - beschreibung: "Steuerung des Gesamtportfolios aus Demands und Projekten" - - referenz: - dokument: "Geschäftsordnung des Mission Boards" - hinweis: "Detaillierte Arbeitsweise" - - # ---------------------------------- - # 3.3 PORTFOLIO-REVIEWS (QUARTALSWEISE) - # ---------------------------------- - - quartals_portfolio_reviews: - frequenz: "quartalsweise" - verantwortlich: "abteilungsleitung_planung" - - teilnehmende: - - "dpm" - - "ppm" - - "spm" - - "shm" - - berichterstattung: - an: "mission_board" - form: "Informationspunkt in der nächsten Sitzung" - - zweck: - hauptzweck: "Systematische Analyse der Portfolio-Dynamik" - - aktivitaeten: - - "Muster identifizieren" - - "Systemgesundheit anhand KPIs bewerten" - - "Verbesserungspotenziale ableiten" - - nutzung_durch_al_p: - zweck: "Abteilungsleitung Planung nutzt Erkenntnisse für" - - nutzungen: - - "Trends und wiederkehrende Herausforderungen erkennen" - - "Effektivität der Governance bewerten" - - "Anpassungsbedarfe identifizieren" - - "Empfehlungen für Mission Board formulieren" - - kern_inhalte: - - id: "REV-1" - name: "Portfolio-Überblick" - aspekte: ["Volumen", "Durchsatz", "Themencluster"] - - - id: "REV-2" - name: "KPI-Analyse" - beschreibung: "Analyse der definierten KPIs" - - - id: "REV-3" - name: "Musteranalyse" - aspekte: ["Engpässe", "Ablehnungsgründe", "Verzögerungen"] - - - id: "REV-4" - name: "Handlungsempfehlungen" - beschreibung: "Ableitung von Handlungsempfehlungen" - - charakter: - output_typ: "strategische Erkenntnisse" - nicht: "operative Entscheidungen" - - eskalation: - bedingung: "bei Bedarf für kritische Themen" - pfad: "Mission Board → Vision Board" - - referenz: - dokument: "Demand-Portfolio Review - Framework" - pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" - inhalt: "Detaillierte Agenda, Analysevorlagen und Durchführungshinweise" - -# ======================================== -# 4. DEMAND-PORTFOLIO KPIs -# ======================================== - -demand_portfolio_kpis: - zweck: "Systematische Analyse der Demand-Portfolio-Dynamik und kontinuierliche Verbesserung" - - verwendung: - kontext: "Quartalsweises Demand-Portfolio Review" - - aktivitaeten: - - "Muster identifizieren" - - "Systemgesundheit bewerten" - - "Strategische Erkenntnisse für Mission Board ableiten" - - entwicklungsansatz: - phase: "pilotphase" - vorgehen: "Erste KPIs werden als Benchmarks erhoben und sukzessive weiterentwickelt" - - referenzen: - - dokument: "Demand-Portfolio Review - Framework" - pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" - inhalt: "Definition und Erhebungsmethodik" - - - dokument: "Pilot Dokumentation" - url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" - typ: "confluence" - -# ======================================== -# 5. SCHNITTSTELLEN UND VERANTWORTLICHKEITEN -# ======================================== - -schnittstellen_verantwortlichkeiten: - - rollenmatrix: - beschreibung: "DIGITOM nutzt ein differenziertes RACI-Modell mit unterschiedlichen Verantwortungslogiken" - - referenz: - dokument: "RACI-Matrix Demand-Portfolio-Management" - pfad: "#01.2_governance/raci-matrix-dpm.yaml" - - informationsfluesse: - beschreibung: "Governance basiert auf definierten Informationsflüssen" - - fluesse: - - richtung: "bottom_up" - name: "Bottom-up" - beschreibung: "Demands fließen von Stakeholdern über SHM und DPM in die Entscheidungsgremien" - pfad: "Stakeholder → SHM → DPM → DSR/MB" - - - richtung: "top_down" - name: "Top-down" - beschreibung: "Strategische Vorgaben fließen vom Vision Board über Mission Board zur operativen Umsetzung" - pfad: "Vision Board → Mission Board → operative Umsetzung" - - - richtung: "horizontal" - name: "Horizontal" - beschreibung: "Abstimmung zwischen DPM, PPM und SPM zur Portfolio-Synchronisation" - zwischen: ["dpm", "ppm", "spm"] - zweck: "Portfolio-Synchronisation" - -# ======================================== -# 6. PILOT-EVALUATION -# ======================================== - -pilot_evaluation: - zeitpunkt: "nach Pilotbetrieb" - - status: - evaluationskriterien: "in Erarbeitung" - dokumentation: "separat" - - referenz: - dokument: "Pilot Dokumentation" - url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" - typ: "confluence" - -# ======================================== -# SYSTEMISCHE EINORDNUNG -# ======================================== - -systemische_einordnung: - framework_charakter: - typ: "übergeordnetes Governance-Framework" - funktion: "Orchestrierung" - scope: "Ende-zu-Ende (Stakeholder-Wunsch bis laufender Service)" - - beziehung_zu_anderen_dokumenten: - ergaenzt: - - dokument: "DSR-Geschäftsordnung" - art: "operative Regelungen" - ergaenzung: "um übergreifende Steuerungsperspektive" - - definiert_kontext_fuer: - - dokument: "Demand-Klassifizierung" - aspekt: "Routing-Logik erhält Governance-Kontext" - - - dokument: "RACI-Matrix" - aspekt: "Verantwortlichkeiten in Governance-Architektur eingebettet" - - - dokument: "Rollenbeschreibung DPM" - aspekt: "Rolle in Governance-System verortet" - -# ======================================== -# REFERENZEN -# ======================================== - -referenzen: - governance_dokumente: - - titel: "DSR-Geschäftsordnung" - pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" - relevanz: "Operative Regelungen für DSR" - - - titel: "RACI-Matrix Demand-Portfolio-Management" - pfad: "#01.2_governance/raci-matrix-dpm.yaml" - relevanz: "Detaillierte Verantwortlichkeiten" - - methodische_dokumente: - - titel: "Demand-Klassifizierung" - pfad: "#01.4_methodik/demand-klassifizierung.yaml" - relevanz: "Routing-Logik und Klassifizierungskriterien" - - - titel: "Demand-Portfolio Review - Framework" - pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" - relevanz: "KPIs und Review-Prozess" - - prozess_dokumente: - - titel: "DSR Standard-Agenda" - pfad: "#01.3_prozesse/dsr-standard-agenda.yaml" - relevanz: "Operativer Ablauf DSR" - - rollen_dokumente: - - titel: "Rollenbeschreibung DPM" - pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" - relevanz: "Zentrale Rolle im Governance-System" - - externe_referenzen: - - titel: "DIGITOM-Portfolio-Governance + Kernprozesse" - beschreibung: "Details zu drei Portfolios und Kernprozessen" - status: "separates Dokument" - - - titel: "Geschäftsordnung Mission Board" - beschreibung: "Detaillierte Arbeitsweise des Mission Board" - status: "separates Dokument" - - - titel: "Pilot Dokumentation" - url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" +meta: + typ: "governance_framework" + framework_name: "Demand-Portfolio Governance" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + abgestimmt_zwischen: ["human", "DPM-Teammitglied"] + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + kontext_tags: + - "governance" + - "demand-portfolio" + - "steuerung" + - "entscheidungsarchitektur" + - "portfolio-management" + +# ======================================== +# 1. ZWECK UND GELTUNGSBEREICH +# ======================================== + +zweck_und_geltungsbereich: + zweck: + kernaussage: "Orchestriert den Fluss von Bedarfen durch die DIGIT-Organisation" + + fluss: + start: "Erste Erfassung eines Stakeholder-Wunsches" + ende: "Integration als laufender Service" + + ergaenzung_zu: "DSR-Geschäftsordnung" + ergaenzungs_perspektive: "Übergreifende Steuerungsperspektive" + + zentrale_klaerungen: + - thema: "Rolle des Demand-Portfolio-Managements" + klarstellung: "Zentrale Priorisierungsinstanz" + + - thema: "Portfolio-Überwachung" + klarstellung: "Mechanismen zur Portfolio-Überwachung definiert" + + verweis_portfolio_kontext: + dokument: "DIGITOM-Portfolio-Governance + Kernprozesse" + inhalt: "Details zu den drei Portfolios und Kernprozessen (Demand-Lifecycle (Change) & Service-Lifecycle (Run))" + +# ======================================== +# 2. GOVERNANCE-ARCHITEKTUR +# ======================================== + +governance_architektur: + + # ---------------------------------- + # 2.1 ENTSCHEIDUNGSEBENEN + # ---------------------------------- + + entscheidungsebenen: + beschreibung: "DIGITOM definiert vier Entscheidungsinstanzen mit unterschiedlichen Kompetenzen" + anzahl: 4 + + ebenen: + - ebene_id: "vision_board" + name: "Vision Board" + ebene: "strategisch" + + verantwortlichkeiten: + - "Verantwortet das Operating Model" + - "Setzt strategische Leitplanken für die Digitalisierung" + + entscheidungen: + - "Grundlegende Governance-Änderungen" + - "Investitionsschwerpunkte" + + hierarchie_stufe: 4 + + - ebene_id: "mission_board" + name: "Mission Board" + ebene: "taktisch-strategisch" + + entscheidungen: + - typ: "MB-Demands" + beispiele: ["transformative Anforderungen", "hochkomplexe Anforderungen"] + - typ: "Gesamtressourcenallokation" + beschreibung: "Steuert die Gesamtressourcenallokation" + - typ: "Konfliktlösung" + beschreibung: "Löst Konflikte zwischen Abteilungen" + + informations_input: + - quelle: "quartals_portfolio_reviews" + frequenz: "quartalsweise" + von: "abteilungsleitung_planung" + + hierarchie_stufe: 3 + + - ebene_id: "abteilungsleitung_planung" + name: "Abteilungsleitung Planung" + kurzform: "AL-P" + ebene: "taktisch" + + verantwortlichkeiten: + - "Quartalsweise Portfolio-Reviews" + - "Disziplinarische Führung des DPM" + + funktion: "Brücke zwischen operativer Portfolio-Steuerung und taktischer Entscheidungsebene" + + aufgaben: + - "Portfolio-Muster und -Trends analysieren" + - "Erkenntnisse ableiten" + - "Berichten ans Mission Board" + + eskalation: + bedingung: "bei strategischer Relevanz" + an: "vision_board" + + hierarchie_stufe: 2 + + - ebene_id: "dsr" + name: "Demand & Stakeholder Runde" + kurzform: "DSR" + ebene: "operativ-taktisch" + + entscheidungen: + - typ: "DSR-Demands" + optionen: ["Freigabe", "Ablehnung", "Zurückstellung"] + + delegation: + kann_delegieren_an: "mission_board" + bedingung: "bei entsprechendem Klassifizierungsmuster" + + hierarchie_stufe: 1 + + referenz: + dokument: "dsr-geschaeftsordnung.yaml" + pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" + + - ebene_id: "dpm" + name: "Demand-Portfolio-Management" + kurzform: "DPM" + ebene: "operativ" + typ: "fachrolle" + + verantwortlichkeiten: + - "Klassifizierung aller Demands im Portfolio" + - "Analyse aller Demands im Portfolio" + - "Bewertung aller Demands im Portfolio" + - "Priorisierung aller Demands im Portfolio" + + output: "Entscheidungsvorlage für jeweiliges Entscheidungsgremium" + + governance_prinzip: + trennung: "Entscheidungsgremium ≠ DPM" + + sicherstellung: + - aspekt: "Fachlich-objektive Arbeit" + durch: "dpm" + umfasst: ["Klassifizierung", "Analyse", "Bewertung", "Priorisierung"] + + - aspekt: "Multiperspektivische Freigabe" + durch: ["dsr", "mission_board"] + umfasst: "Finale Entscheidung unter Berücksichtigung aller Perspektiven" + + referenzen: + - dokument: "DSR-Geschäftsordnung" + pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" + - dokument: "Rollenbeschreibung DPM" + pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" + - abschnitt: "Schnittstellen und Verantwortlichkeiten" + siehe: "Abschnitt 5 in diesem Dokument" + + # ---------------------------------- + # 2.2 ENTSCHEIDUNGS-ROUTING + # ---------------------------------- + + entscheidungs_routing: + beschreibung: "Systematische Zuordnung von Demands zu Entscheidungsebenen" + + basis: "Klassifizierungslogik auf vier Dimensionen" + + dimensionen: + - id: "treiber" + name: "Treiber" + bedeutung: "Impulsquelle" + + - id: "tragweite" + name: "Tragweite" + bedeutung: "Veränderungstiefe" + + - id: "systemebene" + name: "Systemebene" + bedeutung: "Technisch-fachliche Verortung" + + - id: "komplexitaet" + name: "Komplexität" + bedeutung: "Lösungsunsicherheit" + + routing_optionen: + - ziel: "mission_board" + beschreibung: "Direkt an Mission Board" + trigger: ["hochkomplex", "transformativ"] + + - ziel: "dsr_mit_delegationsoption" + beschreibung: "An DSR mit Option zur Delegation ans Mission Board" + trigger: "entsprechendes Klassifizierungsmuster" + + - ziel: "dsr" + beschreibung: "An DSR ohne Delegationsoption" + trigger: "inkrementelle Themen" + + prinzip: | + Entscheidungen werden auf der zuständigen Organisationsebene getroffen: + - Hochkomplexe und transformative Demands → Mission Board + - Inkrementelle Themen → Demand & Stakeholder-Runde + + referenz: + dokument: "Demand-Klassifizierung" + abschnitt: "3.2 Routing-Logik: Die Klassifizierung bestimmt die Entscheidungsebene" + pfad: "#01.4_methodik/demand-klassifizierung.yaml" + +# ======================================== +# 3. DEMAND-PORTFOLIO-STEUERUNG UND REVIEWS +# ======================================== + +portfolio_steuerung: + + # ---------------------------------- + # 3.1 STEUERUNGSEBENE DSR + # ---------------------------------- + + steuerungsebene_dsr: + ebene: "Demand & Stakeholder-Runde" + + aufgaben: + - id: "DSR-E1" + name: "Entscheidung über DSR-Demands" + optionen: ["Freigabe", "Ablehnung", "Zurückstellung"] + + - id: "DSR-E2" + name: "Delegations-Entscheidung" + beschreibung: "Entscheidung über Delegation von Demands ans Mission Board" + + - id: "DSR-I1" + name: "Feedback-Aufnahme" + beschreibung: "Aufnahme von Feedback zu laufenden Umsetzungen" + + - id: "DSR-P1" + name: "Problemklärung" + beschreibung: "Klärung akuter Problemstellungen" + + referenzen: + - dokument: "DSR-Geschäftsordnung" + pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" + - dokument: "DSR Standard-Agenda" + pfad: "#01.3_prozesse/dsr-standard-agenda.yaml" + + # ---------------------------------- + # 3.2 STEUERUNGSEBENE MISSION BOARD + # ---------------------------------- + + steuerungsebene_mission_board: + ebene: "Mission Board" + + aufgaben: + - id: "MB-E1" + name: "Freigabe von MB-Demands" + beschreibung: "Entscheidung über hochkomplexe und transformative Demands" + + - id: "MB-K1" + name: "Ressourcenkonflikte lösen" + beschreibung: "Auflösung von Ressourcenkonflikten zwischen Abteilungen" + + - id: "MB-S1" + name: "Gesamtportfolio steuern" + beschreibung: "Steuerung des Gesamtportfolios aus Demands und Projekten" + + referenz: + dokument: "Geschäftsordnung des Mission Boards" + hinweis: "Detaillierte Arbeitsweise" + + # ---------------------------------- + # 3.3 PORTFOLIO-REVIEWS (QUARTALSWEISE) + # ---------------------------------- + + quartals_portfolio_reviews: + frequenz: "quartalsweise" + verantwortlich: "abteilungsleitung_planung" + + teilnehmende: + - "dpm" + - "ppm" + - "spm" + - "shm" + + berichterstattung: + an: "mission_board" + form: "Informationspunkt in der nächsten Sitzung" + + zweck: + hauptzweck: "Systematische Analyse der Portfolio-Dynamik" + + aktivitaeten: + - "Muster identifizieren" + - "Systemgesundheit anhand KPIs bewerten" + - "Verbesserungspotenziale ableiten" + + nutzung_durch_al_p: + zweck: "Abteilungsleitung Planung nutzt Erkenntnisse für" + + nutzungen: + - "Trends und wiederkehrende Herausforderungen erkennen" + - "Effektivität der Governance bewerten" + - "Anpassungsbedarfe identifizieren" + - "Empfehlungen für Mission Board formulieren" + + kern_inhalte: + - id: "REV-1" + name: "Portfolio-Überblick" + aspekte: ["Volumen", "Durchsatz", "Themencluster"] + + - id: "REV-2" + name: "KPI-Analyse" + beschreibung: "Analyse der definierten KPIs" + + - id: "REV-3" + name: "Musteranalyse" + aspekte: ["Engpässe", "Ablehnungsgründe", "Verzögerungen"] + + - id: "REV-4" + name: "Handlungsempfehlungen" + beschreibung: "Ableitung von Handlungsempfehlungen" + + charakter: + output_typ: "strategische Erkenntnisse" + nicht: "operative Entscheidungen" + + eskalation: + bedingung: "bei Bedarf für kritische Themen" + pfad: "Mission Board → Vision Board" + + referenz: + dokument: "Demand-Portfolio Review - Framework" + pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" + inhalt: "Detaillierte Agenda, Analysevorlagen und Durchführungshinweise" + +# ======================================== +# 4. DEMAND-PORTFOLIO KPIs +# ======================================== + +demand_portfolio_kpis: + zweck: "Systematische Analyse der Demand-Portfolio-Dynamik und kontinuierliche Verbesserung" + + verwendung: + kontext: "Quartalsweises Demand-Portfolio Review" + + aktivitaeten: + - "Muster identifizieren" + - "Systemgesundheit bewerten" + - "Strategische Erkenntnisse für Mission Board ableiten" + + entwicklungsansatz: + phase: "pilotphase" + vorgehen: "Erste KPIs werden als Benchmarks erhoben und sukzessive weiterentwickelt" + + referenzen: + - dokument: "Demand-Portfolio Review - Framework" + pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" + inhalt: "Definition und Erhebungsmethodik" + + - dokument: "Pilot Dokumentation" + url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" + typ: "confluence" + +# ======================================== +# 5. SCHNITTSTELLEN UND VERANTWORTLICHKEITEN +# ======================================== + +schnittstellen_verantwortlichkeiten: + + rollenmatrix: + beschreibung: "DIGITOM nutzt ein differenziertes RACI-Modell mit unterschiedlichen Verantwortungslogiken" + + referenz: + dokument: "RACI-Matrix Demand-Portfolio-Management" + pfad: "#01.2_governance/raci-matrix-dpm.yaml" + + informationsfluesse: + beschreibung: "Governance basiert auf definierten Informationsflüssen" + + fluesse: + - richtung: "bottom_up" + name: "Bottom-up" + beschreibung: "Demands fließen von Stakeholdern über SHM und DPM in die Entscheidungsgremien" + pfad: "Stakeholder → SHM → DPM → DSR/MB" + + - richtung: "top_down" + name: "Top-down" + beschreibung: "Strategische Vorgaben fließen vom Vision Board über Mission Board zur operativen Umsetzung" + pfad: "Vision Board → Mission Board → operative Umsetzung" + + - richtung: "horizontal" + name: "Horizontal" + beschreibung: "Abstimmung zwischen DPM, PPM und SPM zur Portfolio-Synchronisation" + zwischen: ["dpm", "ppm", "spm"] + zweck: "Portfolio-Synchronisation" + +# ======================================== +# 6. PILOT-EVALUATION +# ======================================== + +pilot_evaluation: + zeitpunkt: "nach Pilotbetrieb" + + status: + evaluationskriterien: "in Erarbeitung" + dokumentation: "separat" + + referenz: + dokument: "Pilot Dokumentation" + url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" + typ: "confluence" + +# ======================================== +# SYSTEMISCHE EINORDNUNG +# ======================================== + +systemische_einordnung: + framework_charakter: + typ: "übergeordnetes Governance-Framework" + funktion: "Orchestrierung" + scope: "Ende-zu-Ende (Stakeholder-Wunsch bis laufender Service)" + + beziehung_zu_anderen_dokumenten: + ergaenzt: + - dokument: "DSR-Geschäftsordnung" + art: "operative Regelungen" + ergaenzung: "um übergreifende Steuerungsperspektive" + + definiert_kontext_fuer: + - dokument: "Demand-Klassifizierung" + aspekt: "Routing-Logik erhält Governance-Kontext" + + - dokument: "RACI-Matrix" + aspekt: "Verantwortlichkeiten in Governance-Architektur eingebettet" + + - dokument: "Rollenbeschreibung DPM" + aspekt: "Rolle in Governance-System verortet" + +# ======================================== +# REFERENZEN +# ======================================== + +referenzen: + governance_dokumente: + - titel: "DSR-Geschäftsordnung" + pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" + relevanz: "Operative Regelungen für DSR" + + - titel: "RACI-Matrix Demand-Portfolio-Management" + pfad: "#01.2_governance/raci-matrix-dpm.yaml" + relevanz: "Detaillierte Verantwortlichkeiten" + + methodische_dokumente: + - titel: "Demand-Klassifizierung" + pfad: "#01.4_methodik/demand-klassifizierung.yaml" + relevanz: "Routing-Logik und Klassifizierungskriterien" + + - titel: "Demand-Portfolio Review - Framework" + pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml" + relevanz: "KPIs und Review-Prozess" + + prozess_dokumente: + - titel: "DSR Standard-Agenda" + pfad: "#01.3_prozesse/dsr-standard-agenda.yaml" + relevanz: "Operativer Ablauf DSR" + + rollen_dokumente: + - titel: "Rollenbeschreibung DPM" + pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" + relevanz: "Zentrale Rolle im Governance-System" + + externe_referenzen: + - titel: "DIGITOM-Portfolio-Governance + Kernprozesse" + beschreibung: "Details zu drei Portfolios und Kernprozessen" + status: "separates Dokument" + + - titel: "Geschäftsordnung Mission Board" + beschreibung: "Detaillierte Arbeitsweise des Mission Board" + status: "separates Dokument" + + - titel: "Pilot Dokumentation" + url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM" typ: "confluence" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_bewertung.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_bewertung.yaml index 8ce556c..f7a633a 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_bewertung.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_bewertung.yaml @@ -1,481 +1,481 @@ -meta: - typ: "bewertungsmethodik" - methode: "demand_bewertung" - titel: "Bewertungskriterien für das Demand-Portfolio-Management" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - referenzen: - basiert_auf: - - "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml" - - "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml" - fuehrt_zu: "#01.4_methodik/demand-priorisierung.yaml" - - kontext_tags: - - "bewertung" - - "qualitative-analyse" - - "cluster-bewertung" - -# ======================================== -# 1. ZWECK UND EINORDNUNG -# ======================================== - -zweck: - beschreibung: "Die Demand-Bewertung dient als Koordinationsinstrument für Priorisierungsentscheidungen" - - zentrale_funktionen: - - id: "F01" - name: "Ressourcenallokation" - beschreibung: "Fundierte Entscheidungsgrundlage bei begrenzten Kapazitäten zur optimalen Verteilung von Personal, Budget und Zeit" - - - id: "F02" - name: "Strategische Ausrichtung" - beschreibung: "Sicherstellung, dass priorisierte Demands den größtmöglichen Beitrag zu den Organisationszielen leisten" - - - id: "F03" - name: "Transparenz" - beschreibung: "Nachvollziehbare Dokumentation von Bewertungen und Entscheidungen für alle beteiligten Stakeholder" - - - id: "F04" - name: "Portfolio-Balance" - beschreibung: "Ausgewogene Mischung aus strategischen Initiativen, operativen Verbesserungen und regulatorischen Anforderungen" - - grundprinzipien: - - prinzip: "Qualitative Bewertung" - beschreibung: "Keine mathematischen Scoring-Modelle, sondern begründete qualitative Einschätzungen" - - - prinzip: "Kontextbezug" - beschreibung: "Bewertung erfolgt situationsspezifisch, nicht nach starrem Schema" - - - prinzip: "Konsensorientierung" - beschreibung: "Unterschiedliche Einschätzungen werden dialogisch geklärt" - -# ======================================== -# 2. ÜBERSICHT DER BEWERTUNGSKRITERIEN -# ======================================== - -bewertungskriterien: - anzahl: 9 - cluster_anzahl: 3 - beschreibung: "Neun Kriterien gruppiert in drei thematische Cluster" - - cluster_uebersicht: - - cluster_id: "cluster_1" - name: "Nutzen & Wirkung" - fokus: "Wertbeitrag des Demands" - kriterien_ids: ["strategische_passung", "nutzen", "integrationswirkung"] - - - cluster_id: "cluster_2" - name: "Druck & Notwendigkeit" - fokus: "Handlungsdruck und Risiko" - kriterien_ids: ["organisationsrelevanz", "zeitliche_dringlichkeit", "risiko_nicht_umsetzung"] - - - cluster_id: "cluster_3" - name: "Machbarkeit & Aufwand" - fokus: "Realisierbarkeit und Ressourcenbedarf" - kriterien_ids: ["technische_machbarkeit", "organisatorische_umsetzbarkeit", "ressourceneffizienz"] - -# ======================================== -# 3. BEWERTUNGSKRITERIEN IM DETAIL -# ======================================== - -kriterien_detail: - - # ---------------------------------- - # CLUSTER 1: NUTZEN & WIRKUNG - # ---------------------------------- - - cluster_1_nutzen_wirkung: - cluster_id: "cluster_1" - name: "Nutzen & Wirkung" - - kriterien: - - kriterium_id: "strategische_passung" - name: "Strategische Passung" - kernfrage: "Wie gut unterstützt der Demand die Strategie?" - fokus: "Strategiebeitrag & Innovation" - - beschreibung: | - Die strategische Passung bewertet den Beitrag des Demands zu den - übergeordneten Zielen der Organisation und ihrer digitalen Transformation. - - bewertungsaspekte: - - "Übereinstimmung mit der Digitalisierungsstrategie der Verwaltung" - - "Beitrag zu definierten Schwerpunktthemen und Leitprojekten" - - "Unterstützung der Verwaltungsmodernisierung" - - "Förderung zukunftsfähiger Verwaltungsstrukturen" - - "Innovationspotenzial: Erschließung neuer Möglichkeiten oder Technologien" - - orientierung_bewertungsskala: - punkte_1: "Kein erkennbarer Bezug zu strategischen Zielen" - punkte_3: "Teilweise Übereinstimmung, unterstützt Einzelaspekte" - punkte_5: "Kernbestandteil der Strategie mit hohem Innovationsgrad" - - - kriterium_id: "nutzen" - name: "Nutzen" - kernfrage: "Welchen konkreten Mehrwert schafft der Demand?" - fokus: "Public Value & Effizienz" - - beschreibung: | - Der Nutzen misst den konkreten Mehrwert des Demands in verschiedenen - Dimensionen mit besonderem Fokus auf den Public Value. - - bewertungsaspekte: - - titel: "Public Value" - aspekte: - - "Verbesserung der Lebensqualität für Bürger:innen" - - "Steigerung der Servicequalität und Zugänglichkeit" - - "Beitrag zur Daseinsvorsorge und Gemeinwohl" - - - titel: "Effizienzsteigerung" - aspekte: - - "Prozessoptimierung und Automatisierung" - - "Reduktion von Bearbeitungszeiten" - - "Ressourceneinsparung und Fehlerminimierung" - - - titel: "Qualitätsverbesserung" - aspekte: - - "Erhöhung der Datenqualität" - - "Verbesserung der Entscheidungsgrundlagen" - - "Steigerung der Servicequalität" - - - titel: "Befähigung" - aspekte: - - "Schaffung neuer Handlungsmöglichkeiten" - - "Kompetenzaufbau in der Organisation" - - "Grundlage für weitere Digitalisierungsschritte" - - orientierung_bewertungsskala: - punkte_1: "Nutzen nur in Einzelaspekten erkennbar" - punkte_3: "Mehrere Nutzendimensionen werden adressiert" - punkte_5: "Umfassender Nutzen mit hohem Public Value" - - - kriterium_id: "integrationswirkung" - name: "Integrationswirkung" - kernfrage: "Welche Synergien und Standards entstehen?" - fokus: "Architektur & Wiederverwendung" - - beschreibung: | - Die Integrationswirkung bewertet den Beitrag zur Verbesserung der - Gesamtarchitektur und Schaffung von Synergien. - - bewertungsaspekte: - - "Schaffung wiederverwendbarer Komponenten oder Standards" - - "Reduktion technischer Schulden und Komplexität" - - "Harmonisierung von Prozessen und Schnittstellen" - - "Beitrag zur Architekturkonvergenz" - - orientierung_bewertungsskala: - punkte_1: "Isolierte Einzellösung ohne Synergieeffekte" - punkte_3: "Lokale Verbesserungen mit begrenztem Wiederverwendungspotenzial" - punkte_5: "Grundlegende Plattform oder Standard mit breiter Nutzbarkeit" - - # ---------------------------------- - # CLUSTER 2: DRUCK & NOTWENDIGKEIT - # ---------------------------------- - - cluster_2_druck_notwendigkeit: - cluster_id: "cluster_2" - name: "Druck & Notwendigkeit" - - kriterien: - - kriterium_id: "organisationsrelevanz" - name: "Organisationsrelevanz" - kernfrage: "Wie wichtig ist der Demand für die Verwaltung?" - fokus: "Interne Priorität & Unterstützung" - - beschreibung: | - Die Organisationsrelevanz erfasst die Bedeutung des Demands innerhalb - der DIGIT-Strukturen und -Prozesse. - - bewertungsaspekte: - - "Priorität in den Abteilungen und Führungsebenen" - - "Betroffenheit kritischer Prozesse" - - "Anzahl betroffener Organisationseinheiten" - - "Unterstützung durch Schlüsselpersonen" - - "Verbindlichkeit durch Gremienbeschlüsse" - - orientierung_bewertungsskala: - punkte_1: "Einzelinteresse ohne breite Unterstützung" - punkte_3: "Bereichsübergreifende Relevanz mit moderater Priorität" - punkte_5: "Organisationsweite Priorität mit starker Führungsunterstützung" - - - kriterium_id: "zeitliche_dringlichkeit" - name: "Zeitliche Dringlichkeit" - kernfrage: "Bis wann muss umgesetzt werden?" - fokus: "Fristen & Handlungsdruck" - - beschreibung: | - Die zeitliche Dringlichkeit erfasst externe und interne Zeitvorgaben. - - bewertungsaspekte: - - titel: "Harte Fristen" - aspekte: - - "Gesetzliche Umsetzungsfristen" - - "Vertragsablauf oder Kündigungsfristen" - - "Technische End-of-Life-Termine" - - - titel: "Weiche Fristen" - aspekte: - - "Politische Zusagen und Termine" - - "Budgetjahre und Fördermittelfristen" - - "Koordination mit anderen Vorhaben" - - - titel: "Handlungsdruck" - aspekte: - - "Akkumulierter Problemdruck" - - "Erwartungshaltung der Stakeholder" - - "Verfügbare Zeitfenster für Umsetzung" - - orientierung_bewertungsskala: - punkte_1: "Flexible Zeithorizonte (> 18 Monate)" - punkte_3: "Mittelfristiger Handlungsbedarf (6-18 Monate)" - punkte_5: "Sofortiger Handlungsbedarf (< 6 Monate)" - - - kriterium_id: "risiko_nicht_umsetzung" - name: "Risiko bei Nicht-Umsetzung" - kernfrage: "Was passiert ohne Realisierung?" - fokus: "Rechtliche, operative & Reputationsrisiken" - - beschreibung: | - Diese Kategorie analysiert die negativen Konsequenzen einer - Nicht-Realisierung des Demands. - - bewertungsaspekte: - - titel: "Rechtliche Risiken" - aspekte: - - "Drohende Sanktionen oder Bußgelder" - - "Verletzung gesetzlicher Vorgaben" - - "Haftungsrisiken für die Verwaltung" - - - titel: "Operative Risiken" - aspekte: - - "Gefährdung der Handlungsfähigkeit" - - "Systemausfälle oder Sicherheitslücken" - - "Prozessunterbrechungen" - - - titel: "Reputationsrisiken" - aspekte: - - "Vertrauensverlust bei Bürger:innen" - - "Negative Außenwirkung" - - "Politische Konsequenzen" - - - titel: "Opportunitätskosten" - aspekte: - - "Entgangene Fördermittel" - - "Verpasste Einsparpotenziale" - - "Wettbewerbsnachteile" - - orientierung_bewertungsskala: - punkte_1: "Marginale Auswirkungen absehbar" - punkte_3: "Mittelfristig spürbare negative Effekte" - punkte_5: "Kritische Risiken mit unmittelbaren Konsequenzen" - - # ---------------------------------- - # CLUSTER 3: MACHBARKEIT & AUFWAND - # ---------------------------------- - - cluster_3_machbarkeit_aufwand: - cluster_id: "cluster_3" - name: "Machbarkeit & Aufwand" - - kriterien: - - kriterium_id: "technische_machbarkeit" - name: "Technische Machbarkeit" - kernfrage: "Ist die Lösung technisch realisierbar?" - fokus: "Technologie & Architektur" - - beschreibung: | - Die technische Machbarkeit prüft die Realisierbarkeit mit verfügbaren - Mitteln und Technologien. - - bewertungsaspekte: - - "Verfügbarkeit erprobter Technologien und Lösungsansätze" - - "Kompatibilität mit der Bestandslandschaft" - - "Erfüllbarkeit von Sicherheits- und Datenschutzanforderungen" - - "Skalierbarkeit und Performance-Anforderungen" - - "Verfügbarkeit technischer Expertise" - - orientierung_bewertungsskala: - punkte_1: "Erhebliche technische Herausforderungen, Neuland" - punkte_3: "Lösbar mit vertretbarem Aufwand und bekannten Ansätzen" - punkte_5: "Standardlösung mit minimalem technischen Risiko" - - - kriterium_id: "organisatorische_umsetzbarkeit" - name: "Organisatorische Umsetzbarkeit" - kernfrage: "Sind die organisatorischen Voraussetzungen gegeben?" - fokus: "Change & Ressourcen" - - beschreibung: | - Die organisatorische Umsetzbarkeit bewertet die Rahmenbedingungen für - eine erfolgreiche Realisierung. - - bewertungsaspekte: - - "Verfügbarkeit notwendiger Kompetenzen und Ressourcen" - - "Veränderungsbereitschaft in betroffenen Bereichen" - - "Klarheit der Zuständigkeiten und Verantwortlichkeiten" - - "Tragfähigkeit des geplanten Betriebsmodells" - - "Unterstützung durch relevante Stakeholder" - - orientierung_bewertungsskala: - punkte_1: "Grundlegende organisatorische Hindernisse" - punkte_3: "Umsetzbar mit moderaten Anpassungen" - punkte_5: "Optimale organisatorische Voraussetzungen" - - - kriterium_id: "ressourceneffizienz" - name: "Ressourceneffizienz" - kernfrage: "Steht der Aufwand im Verhältnis zum Nutzen?" - fokus: "Kosten-Nutzen-Relation" - - beschreibung: | - Die Ressourceneffizienz bewertet das Verhältnis von Aufwand zu - erwartetem Nutzen. - - bewertungsaspekte: - - "Investitionsvolumen in Relation zum erwarteten Nutzen" - - "Folgekosten und Betriebsaufwände" - - "Personalbindung und Opportunitätskosten" - - "Wiederverwendbarkeit von Ergebnissen" - - "Skaleneffekte und Synergien" - - orientierung_bewertungsskala: - hinweis: "Inverse Skala" - punkte_1: "Sehr ungünstiges Aufwand-Nutzen-Verhältnis" - punkte_3: "Angemessener Ressourceneinsatz" - punkte_5: "Exzellentes Aufwand-Nutzen-Verhältnis" - -# ======================================== -# 4. OPERATIVE ANWENDUNG -# ======================================== - -operative_anwendung: - - # ---------------------------------- - # 4.1 PROJEKT-PORTFOLIO-ABGLEICH - # ---------------------------------- - - projekt_portfolio_abgleich: - beschreibung: | - Vor der Bewertung erfolgt ein systematischer Abgleich mit dem bestehenden - Projekt-Portfolio. Der DPM initiiert diesen Abgleich in Zusammenarbeit mit dem PPM. - - szenarien: - - szenario: "integration_laufendes_projekt" - name: "Szenario 1: Integration in laufendes Projekt" - massnahmen: - - "Demand wird direkt an das Projektteam übergeben" - - "Integration in bestehende Projektstrukturen" - - "Keine separate Bewertung erforderlich" - - - szenario: "abhaengigkeit_laufendes_projekt" - name: "Szenario 2: Abhängigkeit von laufendem Projekt" - massnahmen: - - "Demand wird zurückgestellt bis Projektabschluss" - - "Aufnahme ins Backlog mit Wiedervorlage" - - "Bewertung erfolgt nach Projektabschluss" - - - szenario: "beeinflussung_laufendes_projekt" - name: "Szenario 3: Beeinflussung durch laufendes Projekt" - massnahmen: - - "Neubewertung des Bedarfs im Projektkontext" - - "Abstimmung mit Stakeholder über angepassten Bedarf" - - "Bewertung auf Basis der veränderten Ausgangslage" - - # ---------------------------------- - # 4.2 CLUSTER-BASIERTE BEWERTUNG - # ---------------------------------- - - cluster_bewertung: - beschreibung: | - Die operative Bewertung erfolgt als strukturierter Prozess, der die neun - Kriterien über ihre drei Cluster handhabbar macht. - - bewertungsprozess: - schritte: - - schritt: 1 - name: "Projekt-Portfolio-Abgleich als Vorstufe" - referenz: "siehe 4.1" - - - schritt: 2 - name: "Clusterweise Bewertung" - beschreibung: "Die Bewertung erfolgt clusterweise, um thematisch zusammenhängende Aspekte im Kontext zu betrachten" - - - schritt: 3 - name: "Vergabe von Orientierungswerten" - skala: "1-5 Punkte" - - - schritt: 4 - name: "Mustererkennung" - fokus: "Innerhalb und zwischen Clustern" - - - schritt: 5 - name: "Qualitative Interpretation" - output: "Cluster-Fazit mit Handlungsimplikationen" - - ergebnisdokumentation: - beschreibung: "Für jedes Cluster entsteht ein Fazit, das die Einzelwerte interpretiert und Handlungsimplikationen ableitet" - - # ---------------------------------- - # 4.3 DOKUMENTATIONSFORMAT - # ---------------------------------- - - dokumentationsformat: - template: | - DEMAND: [Titel] - - CLUSTER 1: NUTZEN & WIRKUNG - - Strategische Passung: [○○○○○] [(x/5)] - Nutzen: [○○○○○] [(x/5)] - Integrationswirkung: [○○○○○] [(x/5)] - - Cluster 1 Fazit: [Qualitative Einschätzung der Stärken und Schwächen] - - CLUSTER 2: DRUCK & NOTWENDIGKEIT - - Organisationsrelevanz: [○○○○○] [(x/5)] - Risiko bei Nicht-Umsetzung:[○○○○○] [(x/5)] - Zeitliche Dringlichkeit: [○○○○○] [(x/5)] - - Cluster 2 Fazit: [Interpretation des Handlungsdrucks] - - CLUSTER 3: MACHBARKEIT & AUFWAND - - Technische Machbarkeit: [○○○○○] [(x/5)] - Organisatorische Umsetzbarkeit: [○○○○○] [(x/5)] - Ressourceneffizienz: [○○○○○] [(x/5)] - - Cluster 3 Fazit: [Einschätzung der Realisierbarkeit] - - GESAMTBEURTEILUNG: [Zusammenfassende Bewertung mit konkreter Handlungsempfehlung] - -# ======================================== -# 5. MULTI-STAKEHOLDER-PERSPEKTIVE -# ======================================== - -multi_stakeholder_perspektive: - beschreibung: "Integration unterschiedlicher Stakeholder-Perspektiven in die Demand-Bewertung (DIGIT-intern)" - - funktionen: - - "Früherkennung von Konflikten: Divergierende Bewertungen identifizieren potenzielle Widerstände vor der Umsetzung" - - "Vollständigeres Bild: Verschiedene Blickwinkel decken blinde Flecken in der Bewertung auf" - - "Erhöhte Akzeptanz: Einbeziehung verschiedener Perspektiven schafft Commitment für spätere Entscheidungen" - - "Risikominimierung: Fundamentale Interessenskonflikte werden sichtbar bevor Ressourcen gebunden werden" - - dokumentation: - beschreibung: "Divergierende Einschätzungen werden mit Begründung erfasst" - - template: | - MULTI-STAKEHOLDER PERSPEKTIVE - - KRITERIUM: [Bewertungskriterium, das divergent ist] - - [Stakeholder A] [○○○○○] [(x/5)] [Begründung Stakeholder A] - [Stakeholder B] [○○○○○] [(x/5)] [Begründung Stakeholder B] - +meta: + typ: "bewertungsmethodik" + methode: "demand_bewertung" + titel: "Bewertungskriterien für das Demand-Portfolio-Management" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + referenzen: + basiert_auf: + - "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml" + - "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml" + fuehrt_zu: "#01.4_methodik/demand-priorisierung.yaml" + + kontext_tags: + - "bewertung" + - "qualitative-analyse" + - "cluster-bewertung" + +# ======================================== +# 1. ZWECK UND EINORDNUNG +# ======================================== + +zweck: + beschreibung: "Die Demand-Bewertung dient als Koordinationsinstrument für Priorisierungsentscheidungen" + + zentrale_funktionen: + - id: "F01" + name: "Ressourcenallokation" + beschreibung: "Fundierte Entscheidungsgrundlage bei begrenzten Kapazitäten zur optimalen Verteilung von Personal, Budget und Zeit" + + - id: "F02" + name: "Strategische Ausrichtung" + beschreibung: "Sicherstellung, dass priorisierte Demands den größtmöglichen Beitrag zu den Organisationszielen leisten" + + - id: "F03" + name: "Transparenz" + beschreibung: "Nachvollziehbare Dokumentation von Bewertungen und Entscheidungen für alle beteiligten Stakeholder" + + - id: "F04" + name: "Portfolio-Balance" + beschreibung: "Ausgewogene Mischung aus strategischen Initiativen, operativen Verbesserungen und regulatorischen Anforderungen" + + grundprinzipien: + - prinzip: "Qualitative Bewertung" + beschreibung: "Keine mathematischen Scoring-Modelle, sondern begründete qualitative Einschätzungen" + + - prinzip: "Kontextbezug" + beschreibung: "Bewertung erfolgt situationsspezifisch, nicht nach starrem Schema" + + - prinzip: "Konsensorientierung" + beschreibung: "Unterschiedliche Einschätzungen werden dialogisch geklärt" + +# ======================================== +# 2. ÜBERSICHT DER BEWERTUNGSKRITERIEN +# ======================================== + +bewertungskriterien: + anzahl: 9 + cluster_anzahl: 3 + beschreibung: "Neun Kriterien gruppiert in drei thematische Cluster" + + cluster_uebersicht: + - cluster_id: "cluster_1" + name: "Nutzen & Wirkung" + fokus: "Wertbeitrag des Demands" + kriterien_ids: ["strategische_passung", "nutzen", "integrationswirkung"] + + - cluster_id: "cluster_2" + name: "Druck & Notwendigkeit" + fokus: "Handlungsdruck und Risiko" + kriterien_ids: ["organisationsrelevanz", "zeitliche_dringlichkeit", "risiko_nicht_umsetzung"] + + - cluster_id: "cluster_3" + name: "Machbarkeit & Aufwand" + fokus: "Realisierbarkeit und Ressourcenbedarf" + kriterien_ids: ["technische_machbarkeit", "organisatorische_umsetzbarkeit", "ressourceneffizienz"] + +# ======================================== +# 3. BEWERTUNGSKRITERIEN IM DETAIL +# ======================================== + +kriterien_detail: + + # ---------------------------------- + # CLUSTER 1: NUTZEN & WIRKUNG + # ---------------------------------- + + cluster_1_nutzen_wirkung: + cluster_id: "cluster_1" + name: "Nutzen & Wirkung" + + kriterien: + - kriterium_id: "strategische_passung" + name: "Strategische Passung" + kernfrage: "Wie gut unterstützt der Demand die Strategie?" + fokus: "Strategiebeitrag & Innovation" + + beschreibung: | + Die strategische Passung bewertet den Beitrag des Demands zu den + übergeordneten Zielen der Organisation und ihrer digitalen Transformation. + + bewertungsaspekte: + - "Übereinstimmung mit der Digitalisierungsstrategie der Verwaltung" + - "Beitrag zu definierten Schwerpunktthemen und Leitprojekten" + - "Unterstützung der Verwaltungsmodernisierung" + - "Förderung zukunftsfähiger Verwaltungsstrukturen" + - "Innovationspotenzial: Erschließung neuer Möglichkeiten oder Technologien" + + orientierung_bewertungsskala: + punkte_1: "Kein erkennbarer Bezug zu strategischen Zielen" + punkte_3: "Teilweise Übereinstimmung, unterstützt Einzelaspekte" + punkte_5: "Kernbestandteil der Strategie mit hohem Innovationsgrad" + + - kriterium_id: "nutzen" + name: "Nutzen" + kernfrage: "Welchen konkreten Mehrwert schafft der Demand?" + fokus: "Public Value & Effizienz" + + beschreibung: | + Der Nutzen misst den konkreten Mehrwert des Demands in verschiedenen + Dimensionen mit besonderem Fokus auf den Public Value. + + bewertungsaspekte: + - titel: "Public Value" + aspekte: + - "Verbesserung der Lebensqualität für Bürger:innen" + - "Steigerung der Servicequalität und Zugänglichkeit" + - "Beitrag zur Daseinsvorsorge und Gemeinwohl" + + - titel: "Effizienzsteigerung" + aspekte: + - "Prozessoptimierung und Automatisierung" + - "Reduktion von Bearbeitungszeiten" + - "Ressourceneinsparung und Fehlerminimierung" + + - titel: "Qualitätsverbesserung" + aspekte: + - "Erhöhung der Datenqualität" + - "Verbesserung der Entscheidungsgrundlagen" + - "Steigerung der Servicequalität" + + - titel: "Befähigung" + aspekte: + - "Schaffung neuer Handlungsmöglichkeiten" + - "Kompetenzaufbau in der Organisation" + - "Grundlage für weitere Digitalisierungsschritte" + + orientierung_bewertungsskala: + punkte_1: "Nutzen nur in Einzelaspekten erkennbar" + punkte_3: "Mehrere Nutzendimensionen werden adressiert" + punkte_5: "Umfassender Nutzen mit hohem Public Value" + + - kriterium_id: "integrationswirkung" + name: "Integrationswirkung" + kernfrage: "Welche Synergien und Standards entstehen?" + fokus: "Architektur & Wiederverwendung" + + beschreibung: | + Die Integrationswirkung bewertet den Beitrag zur Verbesserung der + Gesamtarchitektur und Schaffung von Synergien. + + bewertungsaspekte: + - "Schaffung wiederverwendbarer Komponenten oder Standards" + - "Reduktion technischer Schulden und Komplexität" + - "Harmonisierung von Prozessen und Schnittstellen" + - "Beitrag zur Architekturkonvergenz" + + orientierung_bewertungsskala: + punkte_1: "Isolierte Einzellösung ohne Synergieeffekte" + punkte_3: "Lokale Verbesserungen mit begrenztem Wiederverwendungspotenzial" + punkte_5: "Grundlegende Plattform oder Standard mit breiter Nutzbarkeit" + + # ---------------------------------- + # CLUSTER 2: DRUCK & NOTWENDIGKEIT + # ---------------------------------- + + cluster_2_druck_notwendigkeit: + cluster_id: "cluster_2" + name: "Druck & Notwendigkeit" + + kriterien: + - kriterium_id: "organisationsrelevanz" + name: "Organisationsrelevanz" + kernfrage: "Wie wichtig ist der Demand für die Verwaltung?" + fokus: "Interne Priorität & Unterstützung" + + beschreibung: | + Die Organisationsrelevanz erfasst die Bedeutung des Demands innerhalb + der DIGIT-Strukturen und -Prozesse. + + bewertungsaspekte: + - "Priorität in den Abteilungen und Führungsebenen" + - "Betroffenheit kritischer Prozesse" + - "Anzahl betroffener Organisationseinheiten" + - "Unterstützung durch Schlüsselpersonen" + - "Verbindlichkeit durch Gremienbeschlüsse" + + orientierung_bewertungsskala: + punkte_1: "Einzelinteresse ohne breite Unterstützung" + punkte_3: "Bereichsübergreifende Relevanz mit moderater Priorität" + punkte_5: "Organisationsweite Priorität mit starker Führungsunterstützung" + + - kriterium_id: "zeitliche_dringlichkeit" + name: "Zeitliche Dringlichkeit" + kernfrage: "Bis wann muss umgesetzt werden?" + fokus: "Fristen & Handlungsdruck" + + beschreibung: | + Die zeitliche Dringlichkeit erfasst externe und interne Zeitvorgaben. + + bewertungsaspekte: + - titel: "Harte Fristen" + aspekte: + - "Gesetzliche Umsetzungsfristen" + - "Vertragsablauf oder Kündigungsfristen" + - "Technische End-of-Life-Termine" + + - titel: "Weiche Fristen" + aspekte: + - "Politische Zusagen und Termine" + - "Budgetjahre und Fördermittelfristen" + - "Koordination mit anderen Vorhaben" + + - titel: "Handlungsdruck" + aspekte: + - "Akkumulierter Problemdruck" + - "Erwartungshaltung der Stakeholder" + - "Verfügbare Zeitfenster für Umsetzung" + + orientierung_bewertungsskala: + punkte_1: "Flexible Zeithorizonte (> 18 Monate)" + punkte_3: "Mittelfristiger Handlungsbedarf (6-18 Monate)" + punkte_5: "Sofortiger Handlungsbedarf (< 6 Monate)" + + - kriterium_id: "risiko_nicht_umsetzung" + name: "Risiko bei Nicht-Umsetzung" + kernfrage: "Was passiert ohne Realisierung?" + fokus: "Rechtliche, operative & Reputationsrisiken" + + beschreibung: | + Diese Kategorie analysiert die negativen Konsequenzen einer + Nicht-Realisierung des Demands. + + bewertungsaspekte: + - titel: "Rechtliche Risiken" + aspekte: + - "Drohende Sanktionen oder Bußgelder" + - "Verletzung gesetzlicher Vorgaben" + - "Haftungsrisiken für die Verwaltung" + + - titel: "Operative Risiken" + aspekte: + - "Gefährdung der Handlungsfähigkeit" + - "Systemausfälle oder Sicherheitslücken" + - "Prozessunterbrechungen" + + - titel: "Reputationsrisiken" + aspekte: + - "Vertrauensverlust bei Bürger:innen" + - "Negative Außenwirkung" + - "Politische Konsequenzen" + + - titel: "Opportunitätskosten" + aspekte: + - "Entgangene Fördermittel" + - "Verpasste Einsparpotenziale" + - "Wettbewerbsnachteile" + + orientierung_bewertungsskala: + punkte_1: "Marginale Auswirkungen absehbar" + punkte_3: "Mittelfristig spürbare negative Effekte" + punkte_5: "Kritische Risiken mit unmittelbaren Konsequenzen" + + # ---------------------------------- + # CLUSTER 3: MACHBARKEIT & AUFWAND + # ---------------------------------- + + cluster_3_machbarkeit_aufwand: + cluster_id: "cluster_3" + name: "Machbarkeit & Aufwand" + + kriterien: + - kriterium_id: "technische_machbarkeit" + name: "Technische Machbarkeit" + kernfrage: "Ist die Lösung technisch realisierbar?" + fokus: "Technologie & Architektur" + + beschreibung: | + Die technische Machbarkeit prüft die Realisierbarkeit mit verfügbaren + Mitteln und Technologien. + + bewertungsaspekte: + - "Verfügbarkeit erprobter Technologien und Lösungsansätze" + - "Kompatibilität mit der Bestandslandschaft" + - "Erfüllbarkeit von Sicherheits- und Datenschutzanforderungen" + - "Skalierbarkeit und Performance-Anforderungen" + - "Verfügbarkeit technischer Expertise" + + orientierung_bewertungsskala: + punkte_1: "Erhebliche technische Herausforderungen, Neuland" + punkte_3: "Lösbar mit vertretbarem Aufwand und bekannten Ansätzen" + punkte_5: "Standardlösung mit minimalem technischen Risiko" + + - kriterium_id: "organisatorische_umsetzbarkeit" + name: "Organisatorische Umsetzbarkeit" + kernfrage: "Sind die organisatorischen Voraussetzungen gegeben?" + fokus: "Change & Ressourcen" + + beschreibung: | + Die organisatorische Umsetzbarkeit bewertet die Rahmenbedingungen für + eine erfolgreiche Realisierung. + + bewertungsaspekte: + - "Verfügbarkeit notwendiger Kompetenzen und Ressourcen" + - "Veränderungsbereitschaft in betroffenen Bereichen" + - "Klarheit der Zuständigkeiten und Verantwortlichkeiten" + - "Tragfähigkeit des geplanten Betriebsmodells" + - "Unterstützung durch relevante Stakeholder" + + orientierung_bewertungsskala: + punkte_1: "Grundlegende organisatorische Hindernisse" + punkte_3: "Umsetzbar mit moderaten Anpassungen" + punkte_5: "Optimale organisatorische Voraussetzungen" + + - kriterium_id: "ressourceneffizienz" + name: "Ressourceneffizienz" + kernfrage: "Steht der Aufwand im Verhältnis zum Nutzen?" + fokus: "Kosten-Nutzen-Relation" + + beschreibung: | + Die Ressourceneffizienz bewertet das Verhältnis von Aufwand zu + erwartetem Nutzen. + + bewertungsaspekte: + - "Investitionsvolumen in Relation zum erwarteten Nutzen" + - "Folgekosten und Betriebsaufwände" + - "Personalbindung und Opportunitätskosten" + - "Wiederverwendbarkeit von Ergebnissen" + - "Skaleneffekte und Synergien" + + orientierung_bewertungsskala: + hinweis: "Inverse Skala" + punkte_1: "Sehr ungünstiges Aufwand-Nutzen-Verhältnis" + punkte_3: "Angemessener Ressourceneinsatz" + punkte_5: "Exzellentes Aufwand-Nutzen-Verhältnis" + +# ======================================== +# 4. OPERATIVE ANWENDUNG +# ======================================== + +operative_anwendung: + + # ---------------------------------- + # 4.1 PROJEKT-PORTFOLIO-ABGLEICH + # ---------------------------------- + + projekt_portfolio_abgleich: + beschreibung: | + Vor der Bewertung erfolgt ein systematischer Abgleich mit dem bestehenden + Projekt-Portfolio. Der DPM initiiert diesen Abgleich in Zusammenarbeit mit dem PPM. + + szenarien: + - szenario: "integration_laufendes_projekt" + name: "Szenario 1: Integration in laufendes Projekt" + massnahmen: + - "Demand wird direkt an das Projektteam übergeben" + - "Integration in bestehende Projektstrukturen" + - "Keine separate Bewertung erforderlich" + + - szenario: "abhaengigkeit_laufendes_projekt" + name: "Szenario 2: Abhängigkeit von laufendem Projekt" + massnahmen: + - "Demand wird zurückgestellt bis Projektabschluss" + - "Aufnahme ins Backlog mit Wiedervorlage" + - "Bewertung erfolgt nach Projektabschluss" + + - szenario: "beeinflussung_laufendes_projekt" + name: "Szenario 3: Beeinflussung durch laufendes Projekt" + massnahmen: + - "Neubewertung des Bedarfs im Projektkontext" + - "Abstimmung mit Stakeholder über angepassten Bedarf" + - "Bewertung auf Basis der veränderten Ausgangslage" + + # ---------------------------------- + # 4.2 CLUSTER-BASIERTE BEWERTUNG + # ---------------------------------- + + cluster_bewertung: + beschreibung: | + Die operative Bewertung erfolgt als strukturierter Prozess, der die neun + Kriterien über ihre drei Cluster handhabbar macht. + + bewertungsprozess: + schritte: + - schritt: 1 + name: "Projekt-Portfolio-Abgleich als Vorstufe" + referenz: "siehe 4.1" + + - schritt: 2 + name: "Clusterweise Bewertung" + beschreibung: "Die Bewertung erfolgt clusterweise, um thematisch zusammenhängende Aspekte im Kontext zu betrachten" + + - schritt: 3 + name: "Vergabe von Orientierungswerten" + skala: "1-5 Punkte" + + - schritt: 4 + name: "Mustererkennung" + fokus: "Innerhalb und zwischen Clustern" + + - schritt: 5 + name: "Qualitative Interpretation" + output: "Cluster-Fazit mit Handlungsimplikationen" + + ergebnisdokumentation: + beschreibung: "Für jedes Cluster entsteht ein Fazit, das die Einzelwerte interpretiert und Handlungsimplikationen ableitet" + + # ---------------------------------- + # 4.3 DOKUMENTATIONSFORMAT + # ---------------------------------- + + dokumentationsformat: + template: | + DEMAND: [Titel] + + CLUSTER 1: NUTZEN & WIRKUNG + + Strategische Passung: [○○○○○] [(x/5)] + Nutzen: [○○○○○] [(x/5)] + Integrationswirkung: [○○○○○] [(x/5)] + + Cluster 1 Fazit: [Qualitative Einschätzung der Stärken und Schwächen] + + CLUSTER 2: DRUCK & NOTWENDIGKEIT + + Organisationsrelevanz: [○○○○○] [(x/5)] + Risiko bei Nicht-Umsetzung:[○○○○○] [(x/5)] + Zeitliche Dringlichkeit: [○○○○○] [(x/5)] + + Cluster 2 Fazit: [Interpretation des Handlungsdrucks] + + CLUSTER 3: MACHBARKEIT & AUFWAND + + Technische Machbarkeit: [○○○○○] [(x/5)] + Organisatorische Umsetzbarkeit: [○○○○○] [(x/5)] + Ressourceneffizienz: [○○○○○] [(x/5)] + + Cluster 3 Fazit: [Einschätzung der Realisierbarkeit] + + GESAMTBEURTEILUNG: [Zusammenfassende Bewertung mit konkreter Handlungsempfehlung] + +# ======================================== +# 5. MULTI-STAKEHOLDER-PERSPEKTIVE +# ======================================== + +multi_stakeholder_perspektive: + beschreibung: "Integration unterschiedlicher Stakeholder-Perspektiven in die Demand-Bewertung (DIGIT-intern)" + + funktionen: + - "Früherkennung von Konflikten: Divergierende Bewertungen identifizieren potenzielle Widerstände vor der Umsetzung" + - "Vollständigeres Bild: Verschiedene Blickwinkel decken blinde Flecken in der Bewertung auf" + - "Erhöhte Akzeptanz: Einbeziehung verschiedener Perspektiven schafft Commitment für spätere Entscheidungen" + - "Risikominimierung: Fundamentale Interessenskonflikte werden sichtbar bevor Ressourcen gebunden werden" + + dokumentation: + beschreibung: "Divergierende Einschätzungen werden mit Begründung erfasst" + + template: | + MULTI-STAKEHOLDER PERSPEKTIVE + + KRITERIUM: [Bewertungskriterium, das divergent ist] + + [Stakeholder A] [○○○○○] [(x/5)] [Begründung Stakeholder A] + [Stakeholder B] [○○○○○] [(x/5)] [Begründung Stakeholder B] + Handlungsbedarf: [Beschreibung] \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_priorisierung.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_priorisierung.yaml index abe5aad..3259a36 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_priorisierung.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand_priorisierung.yaml @@ -1,421 +1,421 @@ -meta: - typ: "priorisierungsmethodik" - methode: "demand_priorisierung" - titel: "Priorisierungsverfahren im Demand-Portfolio-Management" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - referenzen: - basiert_auf: "#01.4_methodik/demand-bewertung.yaml" - erzeugt: "handlungsempfehlungen_fuer_gremien" - - kontext_tags: - - "priorisierung" - - "eisenhower-matrix" - - "handlungsempfehlung" - -# ======================================== -# 1. ZWECK UND FUNKTION -# ======================================== - -zweck: - beschreibung: | - Das Priorisierungsverfahren bildet den finalen Schritt der Demand-Bewertung - und überführt die qualitative Analyse in konkrete Handlungsempfehlungen. - - funktionen: - - "Entscheidungsvorbereitung: Strukturierte Aufbereitung für Gremienentscheidungen" - - "Ressourcenoptimierung: Fokussierung auf die wirkungsvollsten Demands bei begrenzten Kapazitäten" - - "Transparenz: Nachvollziehbare Darstellung von Prioritäten für alle Stakeholder" - - "Handlungsorientierung: Klare Strategien für unterschiedliche Demand-Typen" - - methodik: | - Die Priorisierung erfolgt mittels einer erweiterten Eisenhower-Matrix, die - durch eine Farbcodierung zur Entscheidungsgrundlage wird. - -# ======================================== -# 2. DIE ERWEITERTE EISENHOWER-MATRIX -# ======================================== - -eisenhower_matrix: - - # ---------------------------------- - # 2.1 GRUNDSTRUKTUR - # ---------------------------------- - - grundstruktur: - beschreibung: "Die Matrix strukturiert Demands anhand zweier primärer Dimensionen" - - dimension_y: - name: "Wichtigkeit" - beschreibung: "Der strategische und operative Wert des Demands" - ableitung: "Abgeleitet aus dem Bewertungscluster \"Nutzen & Wirkung\"" - bewertet: "Langfristigen Beitrag zu Organisationszielen" - - dimension_x: - name: "Dringlichkeit" - beschreibung: "Der zeitliche und situative Handlungsdruck" - ableitung: "Abgeleitet aus dem Bewertungscluster \"Druck & Notwendigkeit\"" - bewertet: "Notwendigkeit zeitnaher Umsetzung" - - einordnung: | - Die Einordnung erfolgt nicht mechanisch über Schwellenwerte, sondern durch - interpretative Zuordnung basierend auf den qualitativen Cluster-Bewertungen. - - # ---------------------------------- - # 2.2 DIE VIER QUADRANTEN - # ---------------------------------- - - quadranten: - - quadrant_id: "q1" - name: "Quadrant 1: Sofort angehen" - achsen: "Wichtig & Dringend" - - charakteristika: - - "Hoher Handlungsdruck bei gleichzeitig hoher strategischer Relevanz" - - "Kritische Abhängigkeiten oder externe Anforderungen" - - "Signifikante Risiken bei Verzögerung" - - "Unmittelbare Auswirkungen auf Kernprozesse" - - typische_demand_kategorien: - - "Regulatorische Vorgaben mit festen Fristen" - - "Sicherheitskritische Anforderungen" - - "Ausfälle geschäftskritischer Systeme" - - "Verbindliche politische Zusagen" - - - quadrant_id: "q2" - name: "Quadrant 2: Strategisch planen" - achsen: "Wichtig & Nicht dringend" - - charakteristika: - - "Hoher Wertbeitrag ohne unmittelbaren Zeitdruck" - - "Strukturverändernde Vorhaben mit Zukunftspotenzial" - - "Befähigung für weitere Entwicklungsschritte" - - "Nachhaltige Verbesserung der Leistungsfähigkeit" - - typische_demand_kategorien: - - "IT-Architekturmodernisierungen" - - "Strategische Digitalisierungsinitiativen" - - "Kompetenzaufbau und Befähigungsprojekte" - - "Grundlegende Prozessoptimierungen" - - - quadrant_id: "q3" - name: "Quadrant 3: Effizient abarbeiten" - achsen: "Nicht wichtig & Dringend" - - charakteristika: - - "Zeitlicher Druck ohne strategische Bedeutung" - - "Lokale oder temporäre Problemstellungen" - - "Erfüllung operativer Notwendigkeiten" - - "Vermeidung kurzfristiger Störungen" - - typische_demand_kategorien: - - "Kleinere Compliance-Anpassungen" - - "Behebung operativer Engpässe" - - "Erfüllung von Einzelanfragen mit Terminvorgabe" - - "Technische Wartungsarbeiten" - - - quadrant_id: "q4" - name: "Quadrant 4: Kritisch prüfen" - achsen: "Nicht wichtig & Nicht dringend" - - charakteristika: - - "Geringer Wertbeitrag ohne Handlungsdruck" - - "Isolierte Verbesserungswünsche" - - "Optionale Erweiterungen" - - "Unclear Business Case" - - typische_demand_kategorien: - - "Nice-to-have Features" - - "Einzelinteressen ohne breiten Nutzen" - - "Technologiegetriebene Experimente" - - "Redundante Anforderungen" - - # ---------------------------------- - # 2.3 DRITTE DIMENSION: FARBCODIERUNG - # ---------------------------------- - - farbcodierung: - beschreibung: | - Die Farbcodierung visualisiert die Umsetzungskomplexität basierend auf dem - Cluster-Fazit "Machbarkeit & Aufwand". Sie erfolgt durch qualitative Interpretation. - - ableitung: "Aus Cluster 3: Machbarkeit & Aufwand" - - farben: - - farbe: "gruen" - symbol: "🟢" - name: "Grün - Gut machbar" - beschreibung: | - Das Cluster-Fazit zeigt keine kritischen Hindernisse. Die Umsetzung ist - mit vorhandenen Mitteln und etablierten Vorgehensweisen möglich. - - interpretationsbeispiele: - - "Technisch mit Bordmitteln umsetzbar, Organisation vorbereitet, Ressourcen im Rahmen" - - "Bewährte Lösungsansätze vorhanden, moderate Komplexität, gute Akzeptanz erwartet" - - - farbe: "gelb" - symbol: "🟡" - name: "Gelb - Herausfordernd" - beschreibung: | - Das Cluster-Fazit identifiziert überwindbare Hürden. Die Umsetzung erfordert - zusätzlichen Aufwand, besondere Koordination oder externe Unterstützung. - - interpretationsbeispiele: - - "Technisch machbar aber komplex, erhöhter Koordinationsaufwand, Ressourcen knapp" - - "Neue Technologie erforderlich, Change-Management notwendig, externe Expertise benötigt" - - - farbe: "rot" - symbol: "🔴" - name: "Rot - Kritisch" - beschreibung: | - Das Cluster-Fazit zeigt fundamentale Hindernisse. Mindestens ein Aspekt wirkt - blockierend (Dominanz-Prinzip) oder die Gesamtkonstellation ist hochproblematisch. - - interpretationsbeispiele: - - "Technologie noch nicht ausgereift, massive organisatorische Widerstände, Ressourcen nicht darstellbar" - - "Grundlegende Architekturprobleme, fehlendes Know-how, prohibitive Kosten" - -# ======================================== -# 3. HANDLUNGSSTRATEGIEN -# ======================================== - -handlungsstrategien: - beschreibung: | - Die Kombination aus Quadrant (Was ist zu tun?) und Farbe (Wie komplex ist es?) - bestimmt die spezifische Handlungsstrategie. - - # ---------------------------------- - # QUADRANT 1: SOFORT ANGEHEN - # ---------------------------------- - - quadrant_1_strategien: - quadrant: "q1" - name: "Sofort angehen" - - strategien: - - farbe: "gruen" - dpm_handlung: - - "Direkte Aufbereitung für DSR-Entscheidung" - - dpm_empfehlung_gremien: - - "Sprint-Organisation mit dediziertem Team" - - - farbe: "gelb" - dpm_handlung: - - "Identifikation kritischer Erfolgsfaktoren und Risiken" - - dpm_empfehlung_gremien: - - "Task-Force mit Expertenbeteiligung und engem Monitoring" - - - farbe: "rot" - dpm_handlung: - - "Sofortige Eskalation mit Lösungsoptionen" - - dpm_empfehlung_gremien: - - "Krisenstab unter Führungsebene mit externen Ressourcen" - - # ---------------------------------- - # QUADRANT 2: STRATEGISCH PLANEN - # ---------------------------------- - - quadrant_2_strategien: - quadrant: "q2" - name: "Strategisch planen" - - strategien: - - farbe: "gruen" - dpm_handlung: - - "Integration in Quartalsplanung vorschlagen" - - dpm_empfehlung_gremien: - - "Aufnahme in kurzfristige Roadmap" - - - farbe: "gelb" - dpm_handlung: - - "Initiierung einer Machbarkeitsstudie empfehlen" - - dpm_empfehlung_gremien: - - "Mittelfristige Planung mit Vorbereitungsphase" - - - farbe: "rot" - dpm_handlung: - - "Grundlagenanalyse und Transformationsplan anregen" - - dpm_empfehlung_gremien: - - "Langfriststrategie mit fundamentalen Vorarbeiten" - - # ---------------------------------- - # QUADRANT 3: EFFIZIENT ABARBEITEN - # ---------------------------------- - - quadrant_3_strategien: - quadrant: "q3" - name: "Effizient abarbeiten" - - strategien: - - farbe: "gruen" - dpm_handlung: - - "Direktzuweisung an operative Teams vorschlagen" - - dpm_empfehlung_gremien: - - "Delegation mit Standardvorgehen" - - - farbe: "gelb" - dpm_handlung: - - "Alternative Lösungswege aufzeigen" - - dpm_empfehlung_gremien: - - "Pragmatische Alternativlösung oder Workaround" - - - farbe: "rot" - dpm_handlung: - - "Notwendigkeit grundsätzlich hinterfragen" - - dpm_empfehlung_gremien: - - "Ablehnung oder Verschiebung nach Q4" - - # ---------------------------------- - # QUADRANT 4: KRITISCH PRÜFEN - # ---------------------------------- - - quadrant_4_strategien: - quadrant: "q4" - name: "Kritisch prüfen" - - strategien: - - farbe: "gruen" - dpm_handlung: - - "In Backlog aufnehmen" - - dpm_empfehlung_gremien: - - "Bei Kapazitäten als Lernprojekt nutzen" - - - farbe: "gelb" - dpm_handlung: - - "Periodische Neubewertung vorsehen" - - dpm_empfehlung_gremien: - - "Zurückstellung mit jährlicher Überprüfung" - - - farbe: "rot" - dpm_handlung: - - "Ablehnungsempfehlung vorbereiten" - - dpm_empfehlung_gremien: - - "Definitive Ablehnung aus Portfoliosicht" - -# ======================================== -# 4. OPERATIVE ANWENDUNG -# ======================================== - -operative_anwendung: - prozess: - schritt_1: - name: "Ableitung der Dimensionen" - aktivitaeten: - - dimension: "wichtigkeit" - quelle: "Cluster \"Nutzen & Wirkung\"" - - dimension: "dringlichkeit" - quelle: "Cluster \"Druck & Notwendigkeit\"" - - dimension: "farbe" - quelle: "Cluster \"Machbarkeit & Aufwand\"" - - schritt_2: - name: "Qualitative Einordnung" - aktivitaeten: - - "Interpretation der Cluster-Fazits" - - "Keine mechanische Punkteaggregation" - - "Begründete Zuordnung zu Quadranten und Farbe" - - schritt_3: - name: "Strategieableitung" - aktivitaeten: - - "Handlungsempfehlung gemäß Matrix" - - "Berücksichtigung der Farbcodierung" - - "Anpassung an organisatorischen Kontext" - - schritt_4: - name: "Dokumentation" - aktivitaeten: - - "Transparente Darstellung der Einordnung" - - "Nachvollziehbare Begründung" - - "Klare Handlungsempfehlung" - -# ======================================== -# 5. DOKUMENTATIONSSTANDARD -# ======================================== - -dokumentationsstandard: - - # ---------------------------------- - # 5.1 PRIORISIERUNGSDOKUMENTATION - # ---------------------------------- - - priorisierungsdokumentation: - template: | - DEMAND: [Titel] - - PRIORISIERUNG: - - Wichtigkeit: [Ausprägung] - Begründung: [Basierend auf Cluster 1] - - Dringlichkeit: [Ausprägung] - Begründung: [Basierend auf Cluster 2] - - Machbarkeit: [Ausprägung] + [Ampel] - Begründung: [Basierend auf Cluster 3] - - Einordnung: [Quadrant] - - HANDLUNGSEMPFEHLUNG: - - DPM-Aktion: [Was tut der DPM] - - Gremienempfehlung: [Was empfiehlt der DPM] - - Nächste Schritte: [Konkrete Maßnahmen] - - # ---------------------------------- - # 5.2 DEMAND-PORTFOLIO-ÜBERSICHT - # ---------------------------------- - - portfolio_dashboard: - beschreibung: "Aggregierte Darstellung für DSR/MB" - - template_struktur: | - DEMAND-PORTFOLIO DASHBOARD - - Quadrant 🟢 🟡 🔴 Gesamt Hinweise - ------------------------------------------------------- - Q1 Sofort 2 1 1 4 ! Rot → MB-Delegation - Q2 Planen 3 2 0 5 ✓ Ausgewogen - Q3 Abarbeiten 4 1 0 5 ✓ Gut delegierbar - Q4 Prüfen 1 1 2 4 ! Rote ablehnen - ------------------------------------------------------- - Gesamt: 10 5 3 18 - - interpretation: - gruen_dominant: "Gut umsetzbare Demands dominieren - positive Portfoliogesundheit" - gelb_haeufung: "Viele Herausforderungen - Ressourcenplanung kritisch" - rot_in_q1: "Kritische Demands mit Druck - MB-Eskalation prüfen" - rot_in_q4: "Eindeutige Ablehnungskandidaten" - -# ======================================== -# VISUALISIERUNG FÜR GREMIEN -# ======================================== - -visualisierung: - hinweis: "Die Matrix wird typischerweise als 2x2-Grid mit farbigen Punkten für Demands visualisiert" - - best_practices: - - "Demands als Punkte mit Beschriftung in der Matrix platzieren" - - "Farbcodierung für schnelle Erfassung der Machbarkeit" - - "Clustering ähnlicher Demands erkennbar machen" +meta: + typ: "priorisierungsmethodik" + methode: "demand_priorisierung" + titel: "Priorisierungsverfahren im Demand-Portfolio-Management" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + referenzen: + basiert_auf: "#01.4_methodik/demand-bewertung.yaml" + erzeugt: "handlungsempfehlungen_fuer_gremien" + + kontext_tags: + - "priorisierung" + - "eisenhower-matrix" + - "handlungsempfehlung" + +# ======================================== +# 1. ZWECK UND FUNKTION +# ======================================== + +zweck: + beschreibung: | + Das Priorisierungsverfahren bildet den finalen Schritt der Demand-Bewertung + und überführt die qualitative Analyse in konkrete Handlungsempfehlungen. + + funktionen: + - "Entscheidungsvorbereitung: Strukturierte Aufbereitung für Gremienentscheidungen" + - "Ressourcenoptimierung: Fokussierung auf die wirkungsvollsten Demands bei begrenzten Kapazitäten" + - "Transparenz: Nachvollziehbare Darstellung von Prioritäten für alle Stakeholder" + - "Handlungsorientierung: Klare Strategien für unterschiedliche Demand-Typen" + + methodik: | + Die Priorisierung erfolgt mittels einer erweiterten Eisenhower-Matrix, die + durch eine Farbcodierung zur Entscheidungsgrundlage wird. + +# ======================================== +# 2. DIE ERWEITERTE EISENHOWER-MATRIX +# ======================================== + +eisenhower_matrix: + + # ---------------------------------- + # 2.1 GRUNDSTRUKTUR + # ---------------------------------- + + grundstruktur: + beschreibung: "Die Matrix strukturiert Demands anhand zweier primärer Dimensionen" + + dimension_y: + name: "Wichtigkeit" + beschreibung: "Der strategische und operative Wert des Demands" + ableitung: "Abgeleitet aus dem Bewertungscluster \"Nutzen & Wirkung\"" + bewertet: "Langfristigen Beitrag zu Organisationszielen" + + dimension_x: + name: "Dringlichkeit" + beschreibung: "Der zeitliche und situative Handlungsdruck" + ableitung: "Abgeleitet aus dem Bewertungscluster \"Druck & Notwendigkeit\"" + bewertet: "Notwendigkeit zeitnaher Umsetzung" + + einordnung: | + Die Einordnung erfolgt nicht mechanisch über Schwellenwerte, sondern durch + interpretative Zuordnung basierend auf den qualitativen Cluster-Bewertungen. + + # ---------------------------------- + # 2.2 DIE VIER QUADRANTEN + # ---------------------------------- + + quadranten: + - quadrant_id: "q1" + name: "Quadrant 1: Sofort angehen" + achsen: "Wichtig & Dringend" + + charakteristika: + - "Hoher Handlungsdruck bei gleichzeitig hoher strategischer Relevanz" + - "Kritische Abhängigkeiten oder externe Anforderungen" + - "Signifikante Risiken bei Verzögerung" + - "Unmittelbare Auswirkungen auf Kernprozesse" + + typische_demand_kategorien: + - "Regulatorische Vorgaben mit festen Fristen" + - "Sicherheitskritische Anforderungen" + - "Ausfälle geschäftskritischer Systeme" + - "Verbindliche politische Zusagen" + + - quadrant_id: "q2" + name: "Quadrant 2: Strategisch planen" + achsen: "Wichtig & Nicht dringend" + + charakteristika: + - "Hoher Wertbeitrag ohne unmittelbaren Zeitdruck" + - "Strukturverändernde Vorhaben mit Zukunftspotenzial" + - "Befähigung für weitere Entwicklungsschritte" + - "Nachhaltige Verbesserung der Leistungsfähigkeit" + + typische_demand_kategorien: + - "IT-Architekturmodernisierungen" + - "Strategische Digitalisierungsinitiativen" + - "Kompetenzaufbau und Befähigungsprojekte" + - "Grundlegende Prozessoptimierungen" + + - quadrant_id: "q3" + name: "Quadrant 3: Effizient abarbeiten" + achsen: "Nicht wichtig & Dringend" + + charakteristika: + - "Zeitlicher Druck ohne strategische Bedeutung" + - "Lokale oder temporäre Problemstellungen" + - "Erfüllung operativer Notwendigkeiten" + - "Vermeidung kurzfristiger Störungen" + + typische_demand_kategorien: + - "Kleinere Compliance-Anpassungen" + - "Behebung operativer Engpässe" + - "Erfüllung von Einzelanfragen mit Terminvorgabe" + - "Technische Wartungsarbeiten" + + - quadrant_id: "q4" + name: "Quadrant 4: Kritisch prüfen" + achsen: "Nicht wichtig & Nicht dringend" + + charakteristika: + - "Geringer Wertbeitrag ohne Handlungsdruck" + - "Isolierte Verbesserungswünsche" + - "Optionale Erweiterungen" + - "Unclear Business Case" + + typische_demand_kategorien: + - "Nice-to-have Features" + - "Einzelinteressen ohne breiten Nutzen" + - "Technologiegetriebene Experimente" + - "Redundante Anforderungen" + + # ---------------------------------- + # 2.3 DRITTE DIMENSION: FARBCODIERUNG + # ---------------------------------- + + farbcodierung: + beschreibung: | + Die Farbcodierung visualisiert die Umsetzungskomplexität basierend auf dem + Cluster-Fazit "Machbarkeit & Aufwand". Sie erfolgt durch qualitative Interpretation. + + ableitung: "Aus Cluster 3: Machbarkeit & Aufwand" + + farben: + - farbe: "gruen" + symbol: "🟢" + name: "Grün - Gut machbar" + beschreibung: | + Das Cluster-Fazit zeigt keine kritischen Hindernisse. Die Umsetzung ist + mit vorhandenen Mitteln und etablierten Vorgehensweisen möglich. + + interpretationsbeispiele: + - "Technisch mit Bordmitteln umsetzbar, Organisation vorbereitet, Ressourcen im Rahmen" + - "Bewährte Lösungsansätze vorhanden, moderate Komplexität, gute Akzeptanz erwartet" + + - farbe: "gelb" + symbol: "🟡" + name: "Gelb - Herausfordernd" + beschreibung: | + Das Cluster-Fazit identifiziert überwindbare Hürden. Die Umsetzung erfordert + zusätzlichen Aufwand, besondere Koordination oder externe Unterstützung. + + interpretationsbeispiele: + - "Technisch machbar aber komplex, erhöhter Koordinationsaufwand, Ressourcen knapp" + - "Neue Technologie erforderlich, Change-Management notwendig, externe Expertise benötigt" + + - farbe: "rot" + symbol: "🔴" + name: "Rot - Kritisch" + beschreibung: | + Das Cluster-Fazit zeigt fundamentale Hindernisse. Mindestens ein Aspekt wirkt + blockierend (Dominanz-Prinzip) oder die Gesamtkonstellation ist hochproblematisch. + + interpretationsbeispiele: + - "Technologie noch nicht ausgereift, massive organisatorische Widerstände, Ressourcen nicht darstellbar" + - "Grundlegende Architekturprobleme, fehlendes Know-how, prohibitive Kosten" + +# ======================================== +# 3. HANDLUNGSSTRATEGIEN +# ======================================== + +handlungsstrategien: + beschreibung: | + Die Kombination aus Quadrant (Was ist zu tun?) und Farbe (Wie komplex ist es?) + bestimmt die spezifische Handlungsstrategie. + + # ---------------------------------- + # QUADRANT 1: SOFORT ANGEHEN + # ---------------------------------- + + quadrant_1_strategien: + quadrant: "q1" + name: "Sofort angehen" + + strategien: + - farbe: "gruen" + dpm_handlung: + - "Direkte Aufbereitung für DSR-Entscheidung" + + dpm_empfehlung_gremien: + - "Sprint-Organisation mit dediziertem Team" + + - farbe: "gelb" + dpm_handlung: + - "Identifikation kritischer Erfolgsfaktoren und Risiken" + + dpm_empfehlung_gremien: + - "Task-Force mit Expertenbeteiligung und engem Monitoring" + + - farbe: "rot" + dpm_handlung: + - "Sofortige Eskalation mit Lösungsoptionen" + + dpm_empfehlung_gremien: + - "Krisenstab unter Führungsebene mit externen Ressourcen" + + # ---------------------------------- + # QUADRANT 2: STRATEGISCH PLANEN + # ---------------------------------- + + quadrant_2_strategien: + quadrant: "q2" + name: "Strategisch planen" + + strategien: + - farbe: "gruen" + dpm_handlung: + - "Integration in Quartalsplanung vorschlagen" + + dpm_empfehlung_gremien: + - "Aufnahme in kurzfristige Roadmap" + + - farbe: "gelb" + dpm_handlung: + - "Initiierung einer Machbarkeitsstudie empfehlen" + + dpm_empfehlung_gremien: + - "Mittelfristige Planung mit Vorbereitungsphase" + + - farbe: "rot" + dpm_handlung: + - "Grundlagenanalyse und Transformationsplan anregen" + + dpm_empfehlung_gremien: + - "Langfriststrategie mit fundamentalen Vorarbeiten" + + # ---------------------------------- + # QUADRANT 3: EFFIZIENT ABARBEITEN + # ---------------------------------- + + quadrant_3_strategien: + quadrant: "q3" + name: "Effizient abarbeiten" + + strategien: + - farbe: "gruen" + dpm_handlung: + - "Direktzuweisung an operative Teams vorschlagen" + + dpm_empfehlung_gremien: + - "Delegation mit Standardvorgehen" + + - farbe: "gelb" + dpm_handlung: + - "Alternative Lösungswege aufzeigen" + + dpm_empfehlung_gremien: + - "Pragmatische Alternativlösung oder Workaround" + + - farbe: "rot" + dpm_handlung: + - "Notwendigkeit grundsätzlich hinterfragen" + + dpm_empfehlung_gremien: + - "Ablehnung oder Verschiebung nach Q4" + + # ---------------------------------- + # QUADRANT 4: KRITISCH PRÜFEN + # ---------------------------------- + + quadrant_4_strategien: + quadrant: "q4" + name: "Kritisch prüfen" + + strategien: + - farbe: "gruen" + dpm_handlung: + - "In Backlog aufnehmen" + + dpm_empfehlung_gremien: + - "Bei Kapazitäten als Lernprojekt nutzen" + + - farbe: "gelb" + dpm_handlung: + - "Periodische Neubewertung vorsehen" + + dpm_empfehlung_gremien: + - "Zurückstellung mit jährlicher Überprüfung" + + - farbe: "rot" + dpm_handlung: + - "Ablehnungsempfehlung vorbereiten" + + dpm_empfehlung_gremien: + - "Definitive Ablehnung aus Portfoliosicht" + +# ======================================== +# 4. OPERATIVE ANWENDUNG +# ======================================== + +operative_anwendung: + prozess: + schritt_1: + name: "Ableitung der Dimensionen" + aktivitaeten: + - dimension: "wichtigkeit" + quelle: "Cluster \"Nutzen & Wirkung\"" + - dimension: "dringlichkeit" + quelle: "Cluster \"Druck & Notwendigkeit\"" + - dimension: "farbe" + quelle: "Cluster \"Machbarkeit & Aufwand\"" + + schritt_2: + name: "Qualitative Einordnung" + aktivitaeten: + - "Interpretation der Cluster-Fazits" + - "Keine mechanische Punkteaggregation" + - "Begründete Zuordnung zu Quadranten und Farbe" + + schritt_3: + name: "Strategieableitung" + aktivitaeten: + - "Handlungsempfehlung gemäß Matrix" + - "Berücksichtigung der Farbcodierung" + - "Anpassung an organisatorischen Kontext" + + schritt_4: + name: "Dokumentation" + aktivitaeten: + - "Transparente Darstellung der Einordnung" + - "Nachvollziehbare Begründung" + - "Klare Handlungsempfehlung" + +# ======================================== +# 5. DOKUMENTATIONSSTANDARD +# ======================================== + +dokumentationsstandard: + + # ---------------------------------- + # 5.1 PRIORISIERUNGSDOKUMENTATION + # ---------------------------------- + + priorisierungsdokumentation: + template: | + DEMAND: [Titel] + + PRIORISIERUNG: + + Wichtigkeit: [Ausprägung] + Begründung: [Basierend auf Cluster 1] + + Dringlichkeit: [Ausprägung] + Begründung: [Basierend auf Cluster 2] + + Machbarkeit: [Ausprägung] + [Ampel] + Begründung: [Basierend auf Cluster 3] + + Einordnung: [Quadrant] + + HANDLUNGSEMPFEHLUNG: + + DPM-Aktion: [Was tut der DPM] + + Gremienempfehlung: [Was empfiehlt der DPM] + + Nächste Schritte: [Konkrete Maßnahmen] + + # ---------------------------------- + # 5.2 DEMAND-PORTFOLIO-ÜBERSICHT + # ---------------------------------- + + portfolio_dashboard: + beschreibung: "Aggregierte Darstellung für DSR/MB" + + template_struktur: | + DEMAND-PORTFOLIO DASHBOARD + + Quadrant 🟢 🟡 🔴 Gesamt Hinweise + ------------------------------------------------------- + Q1 Sofort 2 1 1 4 ! Rot → MB-Delegation + Q2 Planen 3 2 0 5 ✓ Ausgewogen + Q3 Abarbeiten 4 1 0 5 ✓ Gut delegierbar + Q4 Prüfen 1 1 2 4 ! Rote ablehnen + ------------------------------------------------------- + Gesamt: 10 5 3 18 + + interpretation: + gruen_dominant: "Gut umsetzbare Demands dominieren - positive Portfoliogesundheit" + gelb_haeufung: "Viele Herausforderungen - Ressourcenplanung kritisch" + rot_in_q1: "Kritische Demands mit Druck - MB-Eskalation prüfen" + rot_in_q4: "Eindeutige Ablehnungskandidaten" + +# ======================================== +# VISUALISIERUNG FÜR GREMIEN +# ======================================== + +visualisierung: + hinweis: "Die Matrix wird typischerweise als 2x2-Grid mit farbigen Punkten für Demands visualisiert" + + best_practices: + - "Demands als Punkte mit Beschriftung in der Matrix platzieren" + - "Farbcodierung für schnelle Erfassung der Machbarkeit" + - "Clustering ähnlicher Demands erkennbar machen" - "Bewegung von Demands zwischen Quadranten im Zeitverlauf zeigen" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_dsr-go.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_dsr-go.yaml index cb33f2a..79ee150 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_dsr-go.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_dsr-go.yaml @@ -1,401 +1,401 @@ -meta: - typ: "geschaeftsordnung" - gremium_id: "dsr" - gremium_name: "Demand & Stakeholder-Runde" - aliases: ["DSR", "Demand-Runde", "Stakeholder-Runde"] - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - abstimmung: - sparring_mit: ["shm", "spm"] - abgestimmt_mit: ["DPM-Teammitglied"] - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - kontext_tags: - - "demand-management" - - "governance" - - "entscheidungsgremium" - - "demand-lifecycle" - -# ======================================== -# 1. ZWECK UND GELTUNGSBEREICH -# ======================================== - -zweck: - verankerung: "Steuerungs- und Entscheidungsgremium im DIGITOM" - - funktion: | - Brücke zwischen Bedarfserfassung (Stakeholder-Management) und - Projektinitiierung (Projekt-Portfolio-Management). - - regelungsumfang: - - "Arbeitsweise der DSR" - - "Entscheidungsverfahren" - - "Schnittstellen im Demand-Lifecycle" - - geltungsbereich: - inkludiert: - - typ: "DSR-Demands" - beschreibung: "Demands ohne automatische MB-Trigger gemäß Demand-Klassifizierung" - - - typ: "DSR-Demands mit Delegationsoption" - beschreibung: "Demands mit Option zur Delegation ans Mission Board" - - rolle_bei_mb_demands: "vorbereitendes und empfehlendes Gremium" - -# ======================================== -# 2. AUFGABEN UND KOMPETENZEN -# ======================================== - -aufgaben: - charakter: "hybrides Gremium mit zwei Funktionsbereichen" - - entscheidungsfunktion: - gueltig_fuer: "DSR-Demands" - - entscheidungsoptionen: - - option: "freigabe_zur_umsetzung" - beschreibung: "Freigabe zur Umsetzungsplanung und Übergabe an PPM" - naechster_schritt: "Projekt-Initiierung durch PPM" - - - option: "ablehnung" - beschreibung: "Ablehnung und Weitergabe ans SHM für Stakeholder-Kommunikation" - naechster_schritt: "SHM kommuniziert Ablehnung" - - - option: "delegation_mission_board" - trigger: ["strategische_relevanz", "kompetenzueberschreitung"] - beschreibung: "Delegation ans Mission Board" - naechster_schritt: "Mission Board entscheidet" - - - option: "vertagung_fehlende_grundlagen" - trigger: "fehlende_entscheidungsgrundlagen" - beschreibung: "Weitere Aufarbeitung durch DPM erforderlich" - verantwortlich: "dpm" - - - option: "vertagung_einwand" - trigger: "begruendeter_einwand" - beschreibung: "Weitere Aufarbeitung durch einwendende Rolle (Konsent-Prinzip)" - verantwortlich: "einwendende_rolle" - - informations_und_abstimmungsfunktion: - aktivitaeten: - - name: "Informationsaustausch" - gegenstand: - - "offene Demands" - - "laufende Projekte (durch DSR freigegeben)" - - - name: "Abstimmung" - themen: - - "Abhängigkeiten zwischen Demands/Projekten" - - "Ressourcen-Bedarfe für DSR-freigegebene Projekte" - -# ======================================== -# 3. ZUSAMMENSETZUNG -# ======================================== - -zusammensetzung: - stimmberechtigte_mitglieder: - anzahl: 4 - - rationale: | - Vollständiger Demand-Lifecycle abgebildet: Bedarfserfassung (SHM) → - Qualifizierung (DPM) → Service-Impact-Analyse (SPM) → Projekt-Integration (PPM) - - mitglieder: - - rolle_id: "dpm" - rolle_name: "Demand-Portfolio-Management" - funktion: "vorsitz" - stimmberechtigt: true - - - rolle_id: "shm" - rolle_name: "Stakeholder-Management" - funktion: "mitglied" - stimmberechtigt: true - - - rolle_id: "spm" - rolle_name: "Service-Portfolio-Management" - funktion: "mitglied" - stimmberechtigt: true - - - rolle_id: "ppm" - rolle_name: "Projekt-Portfolio-Management" - funktion: "mitglied" - stimmberechtigt: true - - vertretungsregelung: - flexibel: true - beschreibung: "Mitglieder benennen ihre Vertretungen flexibel" - vertretungs_kompetenzen: "Vertretungen sind stimmberechtigt und haben volle Kompetenzen der vertretenen Rolle" - - zusaetzliche_teilnehmende: - erlaubt: true - status: "beratend" - stimmberechtigt: false - - typische_teilnehmende: - - "Owner betroffener Services" - - "Owner betroffener Produkte" - - "Owner betroffener Infrastruktur-Komponenten" - - "Fachexperten (z.B. IT-Architektur)" - - einladung_durch: "dpm" - -# ======================================== -# 4. ARBEITSWEISE -# ======================================== - -arbeitsweise: - sitzungsrhythmus: - pilotphase: - frequenz: "woechentlich" - termin: "fester Termin" - dauer_minuten: 90 - - regelzeit: - hinweis: "wird nach Pilotphase definiert" - - sondersitzungen: - erfragen_durch: "jedes Mitglied" - einberufung_durch: "dpm" - - vorbereitung_und_dokumentation: - vorbereitung: - verantwortlich: "dpm" - unterlagen_vorlauf_stunden: 24 - beschreibung: "Unterlagen müssen 24h vor Sitzung verfügbar sein" - - protokollfuehrung: - verantwortlich: "dpm" - typ: "Entscheidungsprotokoll" - basis: "Demand-Portfolio-Übersicht" - - ablage: - ort: "Confluence" - zugriff: "DIGIT-weit" - - kommunikation: - timing: "unmittelbar nach Sitzung" - gegenstand: "Entscheidungen werden kommuniziert" - - agenda_struktur: - referenz: "dsr-standard-agenda.yaml" - hinweis: "Detaillierte Agenda-Struktur in separatem Dokument definiert" - -# ======================================== -# 5. ENTSCHEIDUNGSVERFAHREN -# ======================================== - -entscheidungsverfahren: - prinzip: "konsent_mit_alternativzwang" - - konsent_ablauf: - schritt_1: - name: "Vorschlag einbringen" - akteur: "dpm" - inhalt: "DPM bringt Entscheidungsvorschlag ein" - - schritt_2: - name: "Verständnisfragen klären" - bedingung: "sofern vorhanden" - - schritt_3: - name: "Einwände prüfen" - regel: "Ohne schwerwiegenden, begründeten Einwand gilt Vorschlag als angenommen" - - bei_einwand: - verantwortung: "einwendende Rolle" - verpflichtung: "muss Entscheidungsvorlage überarbeiten und konstruktive Alternative einbringen" - - bei_mehreren_einwaenden: - prozess: "gemeinsame Erarbeitung des Alternativ-Vorschlags" - - iteratives_verfahren: - beschreibung: "Überarbeitete Entscheidungsvorlage unterliegt selbst wieder dem Konsent-Prinzip" - - eskalation: - trigger: "nach zwei Iterationen ohne Einigung (bei drittem Einwand)" - option: "DPM kann ans Mission Board eskalieren" - - beschlussfaehigkeit: - bedingung: "alle vier Rollen durch Mitglieder oder Vertretungen besetzt" - - entscheidungen_unter_auflagen: - erlaubt: true - beschreibung: "DSR kann Demands unter Auflagen freigeben" - status: "verbindlicher Teil des Beschlusses" - - erfuellung: - zeitpunkt: "vor/während der Umsetzung" - ueberwachung_durch: "ppm" - - bei_nicht_erfuellung: - massnahme: "Umsetzung stoppen" - naechster_schritt: "Vorlage an DSR zur Neuentscheidung" - - virtuelle_hybride_asynchrone: - virtuell_hybrid: - status: "gleichwertig zu Präsenzsitzungen" - - asynchron: - status: "in Entwicklung" - hinweis: "Werden bei Bedarf während Pilotphase entwickelt und getestet" - moegliche_mechanismen: - - "Kommentierungsfunktion" - - "Voting" - - entscheidungsvarianten_nach_demand_typ: - mb_demand: - beschreibung: "Mission Board-Demand (wird durch DSR vorbereitet)" - einwaende_moeglich_zu: - - "Klassifizierung" - - "Bewertung" - - "Priorisierung" - - "Empfehlung/Begründung" - - dsr_demand_mit_delegation: - beschreibung: "DSR-Demand mit Delegationsoption ans Mission Board" - einwaende_moeglich_zu: - - "Klassifizierung" - - "Bewertung" - - "Priorisierung" - - "Delegationsempfehlung/Begründung" - - dsr_demand: - beschreibung: "DSR-Demand (DSR entscheidet final)" - einwaende_moeglich_zu: - - "Klassifizierung" - - "Bewertung" - - "Priorisierung" - - "Empfehlung/Begründung: Freigabe oder Ablehnung" - -# ======================================== -# 6. RESSOURCENMOBILISIERUNG UND PROJEKTUMSETZUNG -# ======================================== - -ressourcenmobilisierung: - beschreibung: "Prozess nach Freigabe eines DSR-Demands" - - projektinitiierung: - schritt_1: - name: "Projekt-Aufnahme" - beschreibung: "Demand wird formal als Projekt ins Projekt-Portfolio aufgenommen" - verantwortlich: "ppm" - - schritt_2: - name: "Sponsoring" - regelfall: "SPM übernimmt Sponsor:innen-Rolle bei service-/produkt-/infrastrukturbezogenen DSR-Demands" - verantwortlich: "spm" - - projektleitung_und_ressourcen: - projektleitung_benennung: - verantwortlich: "spm" - prozess: "SPM benennt abgestimmte Projektleitung und meldet an PPM" - regelfall: "Owner des betroffenen Services/Produkts wird Projektleitung" - - scope_definition: - verantwortlich: ["spm", "projektleitung"] - prozess: "SPM definiert gemeinsam mit Projektleitung den Scope" - - ressourcenmobilisierung: - verantwortlich: "projektleitung" - prozess: "Projektleitung mobilisiert Ressourcen" - - bei_konflikten: - eskalation_ueber: "ppm_oder_spm" - eskalation_an: "dsr" - weitere_eskalation_moeglich_an: "mission_board" - - monitoring_und_steuerung: - projekt_monitoring: - verantwortlich: "ppm" - umfang: "alle Projekte im Portfolio" - - status_reporting: - von: "ppm" - an: "dsr" - frequenz: "regelmäßig" - gegenstand: "Projekte, die durch DSR beauftragt wurden" - - bei_konflikten: - inhaltliche_konflikte: - klaerung_in: "dsr" - eskalation_moeglich_an: "mission_board" - - projektabschluss: - inhaltliche_abnahme: - verantwortlich: "spm" - - formaler_abschluss: - verantwortlich: "ppm" - prozess: "Projekt formal im Portfolio schließen" - -# ======================================== -# 7. SCHNITTSTELLEN -# ======================================== - -schnittstellen: - - ausloeser: "DSR Freigabe (DSR-Demand)" - von: "dsr" - zu: "ppm" - zweck: "Projektaufnahme, Umsetzung starten" - artefakte: - - "Beschluss" - - "Auflagen" - verantwortlich: ["dpm", "ppm"] - - - ausloeser: "Service-Betroffenheit, Sponsoring & Owner-Einbindung" - zwischen: ["dsr", "spm"] - art: "bidirektional" - zweck: "Sponsoring, Owner-Einbindung" - artefakte: - - "Protokoll" - - "Owner-Liste" - verantwortlich: "spm" - - - ausloeser: "Delegation ans MB" - von: "dsr" - zu: "mission_board" - zweck: "Strategische Entscheidung herbeiführen" - artefakte: - - "MB Vorlage" - - "DSR Empfehlung" - verantwortlich: "dpm" - - - ausloeser: "Rückmeldungen an Stakeholder" - kontext: "Freigaben/Zurückstellungen mit Auflagen, Übergabe in Projekt-/Umsetzungssteuerung, Reporting" - von: ["dsr", "ppm", "spm"] - zu: "shm" - zweck: "Entscheidung/Begründung kommunizieren" - artefakte: - - "Beschluss" - verantwortlich: "shm" - - themen: - - "Wiedervorlagen" - - "Steckbrief-/User-Story-Bezug" - - - ausloeser: "Architektur-Grundsatzfrage" - von: "dsr" - zu: "it_architektur_board" - zweck: "Klärung technischer Leitplanken" - artefakte: - - "Kurzlage/Fragestellung" - verantwortlich: "dpm" - - - ausloeser: "Projekt Reporting" - von: "ppm" - zu: ["dsr", "mission_board"] - zweck: "Status, Risiken, Ressourcenlage kommunizieren" - artefakte: - - "Projekt-Portfolio Bericht" - verantwortlich: "ppm" - -# ======================================== -# 8. KONFLIKTBEHANDLUNG -# ======================================== - -konfliktbehandlung: - regelung: "Verantwortlichkeiten in Konfliktsituationen sind in RACI-Matrix geregelt" +meta: + typ: "geschaeftsordnung" + gremium_id: "dsr" + gremium_name: "Demand & Stakeholder-Runde" + aliases: ["DSR", "Demand-Runde", "Stakeholder-Runde"] + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + abstimmung: + sparring_mit: ["shm", "spm"] + abgestimmt_mit: ["DPM-Teammitglied"] + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + kontext_tags: + - "demand-management" + - "governance" + - "entscheidungsgremium" + - "demand-lifecycle" + +# ======================================== +# 1. ZWECK UND GELTUNGSBEREICH +# ======================================== + +zweck: + verankerung: "Steuerungs- und Entscheidungsgremium im DIGITOM" + + funktion: | + Brücke zwischen Bedarfserfassung (Stakeholder-Management) und + Projektinitiierung (Projekt-Portfolio-Management). + + regelungsumfang: + - "Arbeitsweise der DSR" + - "Entscheidungsverfahren" + - "Schnittstellen im Demand-Lifecycle" + + geltungsbereich: + inkludiert: + - typ: "DSR-Demands" + beschreibung: "Demands ohne automatische MB-Trigger gemäß Demand-Klassifizierung" + + - typ: "DSR-Demands mit Delegationsoption" + beschreibung: "Demands mit Option zur Delegation ans Mission Board" + + rolle_bei_mb_demands: "vorbereitendes und empfehlendes Gremium" + +# ======================================== +# 2. AUFGABEN UND KOMPETENZEN +# ======================================== + +aufgaben: + charakter: "hybrides Gremium mit zwei Funktionsbereichen" + + entscheidungsfunktion: + gueltig_fuer: "DSR-Demands" + + entscheidungsoptionen: + - option: "freigabe_zur_umsetzung" + beschreibung: "Freigabe zur Umsetzungsplanung und Übergabe an PPM" + naechster_schritt: "Projekt-Initiierung durch PPM" + + - option: "ablehnung" + beschreibung: "Ablehnung und Weitergabe ans SHM für Stakeholder-Kommunikation" + naechster_schritt: "SHM kommuniziert Ablehnung" + + - option: "delegation_mission_board" + trigger: ["strategische_relevanz", "kompetenzueberschreitung"] + beschreibung: "Delegation ans Mission Board" + naechster_schritt: "Mission Board entscheidet" + + - option: "vertagung_fehlende_grundlagen" + trigger: "fehlende_entscheidungsgrundlagen" + beschreibung: "Weitere Aufarbeitung durch DPM erforderlich" + verantwortlich: "dpm" + + - option: "vertagung_einwand" + trigger: "begruendeter_einwand" + beschreibung: "Weitere Aufarbeitung durch einwendende Rolle (Konsent-Prinzip)" + verantwortlich: "einwendende_rolle" + + informations_und_abstimmungsfunktion: + aktivitaeten: + - name: "Informationsaustausch" + gegenstand: + - "offene Demands" + - "laufende Projekte (durch DSR freigegeben)" + + - name: "Abstimmung" + themen: + - "Abhängigkeiten zwischen Demands/Projekten" + - "Ressourcen-Bedarfe für DSR-freigegebene Projekte" + +# ======================================== +# 3. ZUSAMMENSETZUNG +# ======================================== + +zusammensetzung: + stimmberechtigte_mitglieder: + anzahl: 4 + + rationale: | + Vollständiger Demand-Lifecycle abgebildet: Bedarfserfassung (SHM) → + Qualifizierung (DPM) → Service-Impact-Analyse (SPM) → Projekt-Integration (PPM) + + mitglieder: + - rolle_id: "dpm" + rolle_name: "Demand-Portfolio-Management" + funktion: "vorsitz" + stimmberechtigt: true + + - rolle_id: "shm" + rolle_name: "Stakeholder-Management" + funktion: "mitglied" + stimmberechtigt: true + + - rolle_id: "spm" + rolle_name: "Service-Portfolio-Management" + funktion: "mitglied" + stimmberechtigt: true + + - rolle_id: "ppm" + rolle_name: "Projekt-Portfolio-Management" + funktion: "mitglied" + stimmberechtigt: true + + vertretungsregelung: + flexibel: true + beschreibung: "Mitglieder benennen ihre Vertretungen flexibel" + vertretungs_kompetenzen: "Vertretungen sind stimmberechtigt und haben volle Kompetenzen der vertretenen Rolle" + + zusaetzliche_teilnehmende: + erlaubt: true + status: "beratend" + stimmberechtigt: false + + typische_teilnehmende: + - "Owner betroffener Services" + - "Owner betroffener Produkte" + - "Owner betroffener Infrastruktur-Komponenten" + - "Fachexperten (z.B. IT-Architektur)" + + einladung_durch: "dpm" + +# ======================================== +# 4. ARBEITSWEISE +# ======================================== + +arbeitsweise: + sitzungsrhythmus: + pilotphase: + frequenz: "woechentlich" + termin: "fester Termin" + dauer_minuten: 90 + + regelzeit: + hinweis: "wird nach Pilotphase definiert" + + sondersitzungen: + erfragen_durch: "jedes Mitglied" + einberufung_durch: "dpm" + + vorbereitung_und_dokumentation: + vorbereitung: + verantwortlich: "dpm" + unterlagen_vorlauf_stunden: 24 + beschreibung: "Unterlagen müssen 24h vor Sitzung verfügbar sein" + + protokollfuehrung: + verantwortlich: "dpm" + typ: "Entscheidungsprotokoll" + basis: "Demand-Portfolio-Übersicht" + + ablage: + ort: "Confluence" + zugriff: "DIGIT-weit" + + kommunikation: + timing: "unmittelbar nach Sitzung" + gegenstand: "Entscheidungen werden kommuniziert" + + agenda_struktur: + referenz: "dsr-standard-agenda.yaml" + hinweis: "Detaillierte Agenda-Struktur in separatem Dokument definiert" + +# ======================================== +# 5. ENTSCHEIDUNGSVERFAHREN +# ======================================== + +entscheidungsverfahren: + prinzip: "konsent_mit_alternativzwang" + + konsent_ablauf: + schritt_1: + name: "Vorschlag einbringen" + akteur: "dpm" + inhalt: "DPM bringt Entscheidungsvorschlag ein" + + schritt_2: + name: "Verständnisfragen klären" + bedingung: "sofern vorhanden" + + schritt_3: + name: "Einwände prüfen" + regel: "Ohne schwerwiegenden, begründeten Einwand gilt Vorschlag als angenommen" + + bei_einwand: + verantwortung: "einwendende Rolle" + verpflichtung: "muss Entscheidungsvorlage überarbeiten und konstruktive Alternative einbringen" + + bei_mehreren_einwaenden: + prozess: "gemeinsame Erarbeitung des Alternativ-Vorschlags" + + iteratives_verfahren: + beschreibung: "Überarbeitete Entscheidungsvorlage unterliegt selbst wieder dem Konsent-Prinzip" + + eskalation: + trigger: "nach zwei Iterationen ohne Einigung (bei drittem Einwand)" + option: "DPM kann ans Mission Board eskalieren" + + beschlussfaehigkeit: + bedingung: "alle vier Rollen durch Mitglieder oder Vertretungen besetzt" + + entscheidungen_unter_auflagen: + erlaubt: true + beschreibung: "DSR kann Demands unter Auflagen freigeben" + status: "verbindlicher Teil des Beschlusses" + + erfuellung: + zeitpunkt: "vor/während der Umsetzung" + ueberwachung_durch: "ppm" + + bei_nicht_erfuellung: + massnahme: "Umsetzung stoppen" + naechster_schritt: "Vorlage an DSR zur Neuentscheidung" + + virtuelle_hybride_asynchrone: + virtuell_hybrid: + status: "gleichwertig zu Präsenzsitzungen" + + asynchron: + status: "in Entwicklung" + hinweis: "Werden bei Bedarf während Pilotphase entwickelt und getestet" + moegliche_mechanismen: + - "Kommentierungsfunktion" + - "Voting" + + entscheidungsvarianten_nach_demand_typ: + mb_demand: + beschreibung: "Mission Board-Demand (wird durch DSR vorbereitet)" + einwaende_moeglich_zu: + - "Klassifizierung" + - "Bewertung" + - "Priorisierung" + - "Empfehlung/Begründung" + + dsr_demand_mit_delegation: + beschreibung: "DSR-Demand mit Delegationsoption ans Mission Board" + einwaende_moeglich_zu: + - "Klassifizierung" + - "Bewertung" + - "Priorisierung" + - "Delegationsempfehlung/Begründung" + + dsr_demand: + beschreibung: "DSR-Demand (DSR entscheidet final)" + einwaende_moeglich_zu: + - "Klassifizierung" + - "Bewertung" + - "Priorisierung" + - "Empfehlung/Begründung: Freigabe oder Ablehnung" + +# ======================================== +# 6. RESSOURCENMOBILISIERUNG UND PROJEKTUMSETZUNG +# ======================================== + +ressourcenmobilisierung: + beschreibung: "Prozess nach Freigabe eines DSR-Demands" + + projektinitiierung: + schritt_1: + name: "Projekt-Aufnahme" + beschreibung: "Demand wird formal als Projekt ins Projekt-Portfolio aufgenommen" + verantwortlich: "ppm" + + schritt_2: + name: "Sponsoring" + regelfall: "SPM übernimmt Sponsor:innen-Rolle bei service-/produkt-/infrastrukturbezogenen DSR-Demands" + verantwortlich: "spm" + + projektleitung_und_ressourcen: + projektleitung_benennung: + verantwortlich: "spm" + prozess: "SPM benennt abgestimmte Projektleitung und meldet an PPM" + regelfall: "Owner des betroffenen Services/Produkts wird Projektleitung" + + scope_definition: + verantwortlich: ["spm", "projektleitung"] + prozess: "SPM definiert gemeinsam mit Projektleitung den Scope" + + ressourcenmobilisierung: + verantwortlich: "projektleitung" + prozess: "Projektleitung mobilisiert Ressourcen" + + bei_konflikten: + eskalation_ueber: "ppm_oder_spm" + eskalation_an: "dsr" + weitere_eskalation_moeglich_an: "mission_board" + + monitoring_und_steuerung: + projekt_monitoring: + verantwortlich: "ppm" + umfang: "alle Projekte im Portfolio" + + status_reporting: + von: "ppm" + an: "dsr" + frequenz: "regelmäßig" + gegenstand: "Projekte, die durch DSR beauftragt wurden" + + bei_konflikten: + inhaltliche_konflikte: + klaerung_in: "dsr" + eskalation_moeglich_an: "mission_board" + + projektabschluss: + inhaltliche_abnahme: + verantwortlich: "spm" + + formaler_abschluss: + verantwortlich: "ppm" + prozess: "Projekt formal im Portfolio schließen" + +# ======================================== +# 7. SCHNITTSTELLEN +# ======================================== + +schnittstellen: + - ausloeser: "DSR Freigabe (DSR-Demand)" + von: "dsr" + zu: "ppm" + zweck: "Projektaufnahme, Umsetzung starten" + artefakte: + - "Beschluss" + - "Auflagen" + verantwortlich: ["dpm", "ppm"] + + - ausloeser: "Service-Betroffenheit, Sponsoring & Owner-Einbindung" + zwischen: ["dsr", "spm"] + art: "bidirektional" + zweck: "Sponsoring, Owner-Einbindung" + artefakte: + - "Protokoll" + - "Owner-Liste" + verantwortlich: "spm" + + - ausloeser: "Delegation ans MB" + von: "dsr" + zu: "mission_board" + zweck: "Strategische Entscheidung herbeiführen" + artefakte: + - "MB Vorlage" + - "DSR Empfehlung" + verantwortlich: "dpm" + + - ausloeser: "Rückmeldungen an Stakeholder" + kontext: "Freigaben/Zurückstellungen mit Auflagen, Übergabe in Projekt-/Umsetzungssteuerung, Reporting" + von: ["dsr", "ppm", "spm"] + zu: "shm" + zweck: "Entscheidung/Begründung kommunizieren" + artefakte: + - "Beschluss" + verantwortlich: "shm" + + themen: + - "Wiedervorlagen" + - "Steckbrief-/User-Story-Bezug" + + - ausloeser: "Architektur-Grundsatzfrage" + von: "dsr" + zu: "it_architektur_board" + zweck: "Klärung technischer Leitplanken" + artefakte: + - "Kurzlage/Fragestellung" + verantwortlich: "dpm" + + - ausloeser: "Projekt Reporting" + von: "ppm" + zu: ["dsr", "mission_board"] + zweck: "Status, Risiken, Ressourcenlage kommunizieren" + artefakte: + - "Projekt-Portfolio Bericht" + verantwortlich: "ppm" + +# ======================================== +# 8. KONFLIKTBEHANDLUNG +# ======================================== + +konfliktbehandlung: + regelung: "Verantwortlichkeiten in Konfliktsituationen sind in RACI-Matrix geregelt" referenz: "raci-matrix-demand-portfolio-management.yaml" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml index 4f2408c..020d527 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml @@ -1,460 +1,460 @@ -meta: - typ: "funktionsbeschreibung" - funktion_id: "dpm" - funktion_name: "Demand-Portfolio-Management" - aliases: ["DPM", "Demand-Portfolio-Funktion"] - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - kontext_tags: - - "demand-management" - - "funktion" - - "systemische-perspektive" - - "orchestrierung" - - "neutralitaet" - -# ======================================== -# ABKÜRZUNGSVERZEICHNIS -# ======================================== - -abkuerzungen: - dpm: "Demand-Portfolio-Management" - dsr: "Demand & Stakeholder-Runde" - mb: "Mission Board" - vb: "Vision Board" - shm: "Stakeholder-Management" - spm: "Service-Portfolio-Management" - ppm: "Projekt-Portfolio-Management" - al_p: "Abteilungsleitung Planung" - pl: "Projektleitung" - pzm: "Prozess-Management" - ita: "IT-Architektur-Board" - sh: "Stakeholder" - kpi: "Key Performance Indicator (Kennzahl)" - raci: "Responsible / Accountable / Consulted / Informed" - d2p: "Demand-to-Project (Prozess)" - -# ======================================== -# 1. ZWECK -# ======================================== - -zweck: - wozu_existiert_diese_funktion: - kurz: "Koordiniert den Fluss aller Demands im DIGIT vom vorqualifizierten Demand bis zur entscheidungsreifen Vorlage" - - ausfuehrlich: | - Das Demand-Portfolio-Management (DPM) übernimmt Demands aus dem Stakeholder-Management (SHM), - klassifiziert, analysiert, bewertet und priorisiert sie und bringt sie als strukturierte - Entscheidungsvorlagen in die zuständigen Gremien Demand & Stakeholder Runde (DSR) und - Mission Board (MB) ein. - - wertbeitrag: - - "Transparenz" - - "Vergleichbarkeit" - - "Entscheidungsfähigkeit" - - kritisches_merkmal: "Getrennt von der eigentlichen Freigabeentscheidung der Gremien" - - hauptziel: - beschreibung: "Ein kohärentes, strategiekonformes und entscheidungsfähiges Demand-Portfolio sicherstellen" - - erreicht_durch: - - id: "Z1" - aktivitaet: "Systematische Überführung" - beschreibung: "Vorqualifizierte Demands systematisch in Entscheidungsvorlagen überführen" - umfasst: - - "Klassifizierung" - - "Analyse" - - "Bewertung" - - "Priorisierung" - - - id: "Z2" - aktivitaet: "Informationsfluss orchestrieren" - beschreibung: "Informationsfluss zwischen SHM, DPM und Entscheidungsgremien orchestrieren" - richtungen: - - "Bottom-up" - - "Top-down" - - "Horizontal" - - - id: "Z3" - aktivitaet: "Trennung wahren" - beschreibung: "Trennung von fachlicher Bewertung (DPM) und Entscheidung (DSR/MB) wahren" - effekt: "Objektivität und Akzeptanz als neutrale Koordinationsinstanz stärken" - - - id: "Z4" - aktivitaet: "Portfolio-Erkenntnisse aufbereiten" - beschreibung: "Demand-Portfolio-Erkenntnisse regelmäßig aufbereiten (Reviews)" - effekt: "Bessere Koordination durch Mission Board und Abteilungsleitung Planung ermöglichen" - - - id: "Z5" - aktivitaet: "Zielbeitrag sichtbar machen" - beschreibung: "Zielbeitrag anhand klarer KPIs sichtbar machen" - -# ======================================== -# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG -# ======================================== - -funktionsverstaendnis: - charakterisierung: - typ: "Bewertungs- und Orchestrierungsfunktion" - - beschreibung: | - Die neutrale Instanz, die Demands strukturiert bewertet, priorisiert und als - Entscheidungsvorlagen in die zuständigen Gremien einbringt. Die Funktion hält - Methodik, Routing und Demand-Portfolio-Transparenz zusammen – getrennt von der - finalen Entscheidung und der operativen Umsetzung. - - grundprinzipien: - verantwortung_bleibt_wo_sie_hingehoert: - beschreibung: "Klare Trennung zwischen Vorbereitung und Entscheidung" - - entscheidungen: - wo: "Gremien (DSR, MB)" - was: "Freigabe, Ablehnung oder Delegation" - dpm_rolle: "Bereitet vor, präsentiert, führt Beschlüsse nach – entscheidet aber nicht anstelle der Gremien" - - linien_budget_verantwortung: - wo: "MB und Fachbereiche" - dpm_rolle: "Stellt Systematik und Entscheidungsreife sicher" - - partnerschaft_statt_kontrolle: - beschreibung: "DPM arbeitet auf Augenhöhe mit anderen Portfolio-Funktionen" - - partnerschaften: - - partner: "shm" - beziehung: "SHM speist vorqualifizierte Demands ein" - - - partner: "dpm" - beziehung: "DPM qualifiziert und bündelt" - - - partner: "spm" - beziehung: "SPM bewertet Service-Auswirkungen" - - - partner: "ppm" - beziehung: "PPM integriert in das Projektportfolio" - - institutionalisierung: "Diese Partnerschaft ist im DSR institutionalisiert (stimmberechtigte Kernrollen)" - - arbeitsweise: "Folgt definierten Informationsflüssen (Bottom-up, Top-down, Horizontal) und fördert schnelle, anschlussfähige Entscheidungen statt 'Kontrolle'" - - systematische_bewertung_transparenz: - verantwortung_dpm: - - "Klassifizierung" - - "Analyse" - - "Bewertung" - - "Priorisierung" - - "Erstellung Entscheidungsvorlagen" - - "Sauberes Entscheidungs-Routing (je nach Tragweite, Komplexität, Systemebene, Treiber)" - - transparenz: "DPM stellt Transparenz über ein zentrales Demand-Portfolio her und bereitet Reviews für MB/AL-Planung vor" - - nicht_teil_des_mandats: - - "Operative Projektentscheidungen" - - "Umsetzungsleistungen" - - abgrenzung_zu_angrenzenden_funktionen: - - funktion: "shm" - name: "Stakeholder-Management" - tut: "Erfasst und klärt den Bedarf mit Stakeholdern" - uebergabe: "Übergibt vorqualifiziert an DPM" - - - funktion: "dpm" - name: "Demand-Portfolio-Management" - tut: "Klassifiziert, analysiert, bewertet, priorisiert, routet" - uebergabe: "Bringt Vorlagen in DSR/MB ein" - - - funktion: "spm" - name: "Service-Portfolio-Management" - tut: "Prüft Service-Fit/-Impact und katalogseitige Konsequenzen" - - - funktion: "ppm" - name: "Projekt-Portfolio-Management" - tut: "Integriert freigegebene Demands in das Projektportfolio" - und: "Steuert Projektumsetzungen" - -# ======================================== -# 3. VERANTWORTUNGSBEREICHE -# ======================================== - -verantwortungsbereiche: - - # ---------------------------------- - # 3.1 DEMAND-PORTFOLIO-MANAGEMENT - # ---------------------------------- - - bereich_1_portfolio_management: - id: "VB1" - name: "Demand-Portfolio-Management" - - was: - - "Zentrales Demand-Portfolio führen und aktuell halten" - - "Trends und Muster analysieren" - - "Demand-Portfolio-Methodiken optimieren" - - "Entlang Vision-Board-Leitplanken bewerten und priorisieren" - - warum: - - "Strategiekonforme, ressourcenfähige Auswahl durch MB ermöglichen" - - "DPM liefert die strukturierte Grundlage, MB trifft die Allokationsentscheidungen" - - "Objektivität sichern durch Trennung von Bewertung (DPM) und Entscheidung (DSR/MB)" - - wie: - routinen: - - frequenz: "woechentlich" - was: "DSR" - - - frequenz: "quartalsweise" - was: "Demand-Portfolio-Review" - - reporting: - an: "mb" - format: "MB-Kurzpräsentation" - inhalte: - - "Demand-Portfolio-Entwicklung" - - "Muster" - - "Handlungsbedarfe" - - "Empfehlungen" - - # ---------------------------------- - # 3.2 KLASSIFIZIERUNG, ANALYSE, BEWERTUNG, PRIORISIERUNG - # ---------------------------------- - - bereich_2_qualifizierung: - id: "VB2" - name: "Demand-Klassifizierung, Analyse, Bewertung und Priorisierung" - - was: - - "Klassifizierung nach vordefinierten Dimensionen" - - "Unzureichend qualifizierte Demands zurückweisen" - - "Dubletten konsolidieren" - - "Fachexpert:innen einbeziehen" - - "Anwendung von Kategorien & Bewertungskriterien" - - "Nutzung Bedarfs-Steckbrief und Demand-Entscheidungsvorlage" - - warum: - - "Klaren Prozess und Verfahren gegenüber Stakeholder sicherstellen" - - "Entscheidungsfähigkeit herstellen und Vergleichbarkeit sichern" - - wie: - methodik: - beschreibung: "Standardisierte Klassifizierung/Bewertung/Priorisierung" - referenz: "DPM-Framework" - - interaktion: - - mit: "shm" - was: "Rückfragen/Nachforderungen" - - - mit: ["spm", "ppm", "ita"] - was: "Abstimmung bei Service-, Projekt- oder Technikfragen" - - dokumentation: - - "Laufende Statuspflege im Ticketsystem" - - "Statuspflege in weiteren genutzten Tools im Demand-Portfolio" - - "Portfolio-Abgleich" - - # ---------------------------------- - # 3.3 GREMIENARBEIT - # ---------------------------------- - - bereich_3_gremienarbeit: - id: "VB3" - name: "Gremienarbeit" - - was: - - "DSR vorbereiten, in der Sitzung präsentieren, Beschlüsse dokumentieren" - - "MB-Vorstellung MB-relevanter Demands" - - "Nachbearbeitung und Umsetzungsvorbereitung gemäß Beschlüssen" - - warum: - - "Klare, effiziente Entscheidungen im Konsent-Verfahren" - - "Eskalationsfähigkeit zum MB bei Uneinigkeit oder Kompetenzüberschreitung" - - wie: - rhythmus_rolle: - - frequenz: "woechentlich" - gremium: "dsr" - - - frequenz: "ad_hoc" - was: "Sondersitzungen auf Antrag" - - arbeitsweise: - - "Standard-Agenda" - - "Unterlagen vorab" - - "Confluence-Ablage" - - "Unmittelbare Ergebnis-Kommunikation" - - outputs: - - "Beschlussprotokolle" - - "Aktualisierte Demand-Portfolio-/Ticket-Einträge" - - "Übergabe an PPM bei Freigabe" - -# ======================================== -# 4. SCHNITTSTELLEN -# ======================================== - -schnittstellen: - beschreibung: "Input/Output/Typische Abstimmungswege" - - # ---------------------------------- - # 4.1 INPUTS - # ---------------------------------- - - inputs: - beschreibung: "Was das DPM empfängt" - - quellen: - - von: "vision_board" - inhalt: "Strategische Leitplanken und Top-down-Vorgaben, die den Priorisierungsrahmen für Demands setzen" - - - von: "mission_board" - inhalt: "Beschlüsse und Prioritäten für MB-relevante Demands; Rückfragen oder Arbeitsaufträge an DPM bei Vertagung/Delegation" - - - von: "shm" - inhalt: "Übergabe vorqualifizierter Demands inkl. Bedarfs-Steckbrief; Nachlieferungen bei Rückfragen; Statuswechsel 'an DPM übergeben' mit SHM-Einschätzung" - - - von: "spm" - inhalt: "Input zu Service-Fit und -Konsequenzen; Abstimmung, wenn direkte Service-Umsetzung möglich oder Service-Impact zu prüfen ist" - - - von: "ppm" - inhalt: "Informationen zu laufenden/geplanten Projekten zur Überschneidungsprüfung; Abgleich bei potenziellen Projekt-Kollisionen" - - - von: "ita" - inhalt: "Strategische/technische Grundsatz-Inputs zur Machbarkeit und Architekturrahmen" - - - von: "fachexpertinnen" - inhalt: "Punktuelle Expertise für Bewertung/Qualifizierung (fachlich/technisch)" - - # ---------------------------------- - # 4.2 OUTPUTS - # ---------------------------------- - - outputs: - beschreibung: "Was das DPM weitergibt" - - ziele: - - an: "dsr" - inhalt: "Standardisierte Entscheidungsvorlage je Demand (Klassifizierung, Optionen, Empfehlung, Auswirkungen, Risiken), Vorstellung in der Sitzung, Beschluss-/Aufgabenüberführung" - - - an: "mb" - inhalt: "Entscheidungsvorlage für MB-relevante Demands inkl. Priorisierungsempfehlung, strategischer Fit, Ressourcen-/Portfolio-Auswirkungen, Alternativen; Kurzbericht Entscheidung/Nachverfolgung" - - - an: "shm" - inhalt: "Rückmeldung zum Bewertungsergebnis (z.B. Nachlieferung benötigt, Konsolidierung mit ähnlichen Demands, Routing in DSR/MB, Ablehnungs-/Delegationsbegründung); aktualisierte Steckbrief-Anforderungen" - - - an: "spm" - inhalt: "Klärungsanfragen zu Service-Fit/-Impact, dokumentierte Ergebnisse für Entscheidungsvorlage; Hinweise auf Servicekatalog-Anpassungen" - - - an: "ppm" - inhalt: "Übergabe freigegebener Demands in die Projektpipeline inkl. Beschlussreferenz, Priorität, Abhängigkeiten, initialer Projektsteckbrief/Startkonditionen" - - - an: ["ita", "fachexpertinnen"] - inhalt: "Gezielte Architektur-/Fachabfragen zur Entscheidungsreife; zusammengefasste Einschätzungen für die Vorlage (Machbarkeit, Standards, Risiken)" - - - an: "al_p" - inhalt: "Quartalsweiser Demand-Portfolio-Report: KPI-Dashboard, Muster/Trends, Handlungs-/Priorisierungsempfehlungen" - - # ---------------------------------- - # 4.3 TYPISCHE ABSTIMMUNGSWEGE - # ---------------------------------- - - typische_abstimmungswege: - beschreibung: "Standardisierte Interaktionsformate" - - formate: - - format: "dsr_regulaer" - name: "DSR – Regulär" - frequenz: "woechentlich" - - inhalt: - - "Vorstellung der Entscheidungsvorlagen durch DPM" - - "Gemeinsame Bewertung/Klassifizierung" - - "Beschluss (Freigabe, Ablehnung, Zurückstellung, Delegation ans MB)" - - "Protokoll und Ticket-Update" - - - format: "sonder_dsr" - name: "Sonder-DSR" - frequenz: "ad_hoc" - - inhalt: - - "Kurzfristige Klärung dringlicher Themen oder Konflikte" - - "Einberufung auf Anfrage eines DSR-Mitglieds" - - "Entscheidung über Einberufung liegt beim DPM" - - "Eskalationsweg bei Bedarf" - - - format: "mission_board" - name: "Mission Board" - frequenz: "zweiwoechentlich" - - inhalt: - - "Finale Entscheidung zu MB-relevanten Demands" - - "Priorisierung/Ressourcen" - - "DPM liefert MB-Vorlage" - - "PPM/SHM übernehmen Folgekommunikation und Statusupdates" - - - format: "shm_dpm_klaerung" - name: "SHM ↔ DPM – Klärungsschleifen" - frequenz: "laufend" - - inhalt: - - "Nachforderungen bei unvollständigen Demands" - - "Persönliche Kurzabstimmungen/E-Mail" - - "SHM aktualisiert Steckbrief/Ticket" - - - format: "dpm_spm_service" - name: "DPM ↔ SPM – Service-Fit/Impact" - frequenz: "bei_bedarf" - - inhalt: - - "Abgleich Service-Bezug" - - "Direkte Umsetzung kleiner Demands mit SPM/Service Manager" - - "Ergebnissicherung für die Entscheidungsvorlage" - - - format: "dpm_ppm_projekt" - name: "DPM ↔ PPM – Projekt-Abgleich/Übergabe" - frequenz: "bei_bedarf" - - inhalt: - - "Prüfen von Überschneidungen mit laufenden/geplanten Projekten" - - "Übergabe freigegebener Demands in die Projektpipeline" - - "Status-Reporting zurück an DSR/MB" - - - format: "dpm_ita_grundsatz" - name: "DPM ↔ IT-Architektur-Board" - frequenz: "bei_grundsatzfragen" - - inhalt: - - "Technische Leitplanken/Machbarkeit klären" - - "Kurzlage/Fragestellung aus DSR/DPM" - - - format: "portfolio_review" - name: "Demand-Portfolio-Review" - frequenz: "quartalsweise" - - inhalt: - - "Muster-/Trendanalysen" - -# ======================================== -# REFERENZEN -# ======================================== - -referenzen: - verwandte_dokumente: - - titel: "Rollenbeschreibung DPM" - pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" - unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch" - - - titel: "Demand-Portfolio Governance" - pfad: "#01.2_governance/demand-portfolio-governance.yaml" - relevanz: "Übergeordneter Governance-Rahmen für DPM-Funktion" - - - titel: "RACI-Matrix DPM" - pfad: "#01.2_governance/raci-matrix-dpm.yaml" - relevanz: "Detaillierte Verantwortlichkeiten über Phasen hinweg" - - - titel: "Demand-Klassifizierung" - pfad: "#01.4_methodik/demand-klassifizierung.yaml" +meta: + typ: "funktionsbeschreibung" + funktion_id: "dpm" + funktion_name: "Demand-Portfolio-Management" + aliases: ["DPM", "Demand-Portfolio-Funktion"] + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + kontext_tags: + - "demand-management" + - "funktion" + - "systemische-perspektive" + - "orchestrierung" + - "neutralitaet" + +# ======================================== +# ABKÜRZUNGSVERZEICHNIS +# ======================================== + +abkuerzungen: + dpm: "Demand-Portfolio-Management" + dsr: "Demand & Stakeholder-Runde" + mb: "Mission Board" + vb: "Vision Board" + shm: "Stakeholder-Management" + spm: "Service-Portfolio-Management" + ppm: "Projekt-Portfolio-Management" + al_p: "Abteilungsleitung Planung" + pl: "Projektleitung" + pzm: "Prozess-Management" + ita: "IT-Architektur-Board" + sh: "Stakeholder" + kpi: "Key Performance Indicator (Kennzahl)" + raci: "Responsible / Accountable / Consulted / Informed" + d2p: "Demand-to-Project (Prozess)" + +# ======================================== +# 1. ZWECK +# ======================================== + +zweck: + wozu_existiert_diese_funktion: + kurz: "Koordiniert den Fluss aller Demands im DIGIT vom vorqualifizierten Demand bis zur entscheidungsreifen Vorlage" + + ausfuehrlich: | + Das Demand-Portfolio-Management (DPM) übernimmt Demands aus dem Stakeholder-Management (SHM), + klassifiziert, analysiert, bewertet und priorisiert sie und bringt sie als strukturierte + Entscheidungsvorlagen in die zuständigen Gremien Demand & Stakeholder Runde (DSR) und + Mission Board (MB) ein. + + wertbeitrag: + - "Transparenz" + - "Vergleichbarkeit" + - "Entscheidungsfähigkeit" + + kritisches_merkmal: "Getrennt von der eigentlichen Freigabeentscheidung der Gremien" + + hauptziel: + beschreibung: "Ein kohärentes, strategiekonformes und entscheidungsfähiges Demand-Portfolio sicherstellen" + + erreicht_durch: + - id: "Z1" + aktivitaet: "Systematische Überführung" + beschreibung: "Vorqualifizierte Demands systematisch in Entscheidungsvorlagen überführen" + umfasst: + - "Klassifizierung" + - "Analyse" + - "Bewertung" + - "Priorisierung" + + - id: "Z2" + aktivitaet: "Informationsfluss orchestrieren" + beschreibung: "Informationsfluss zwischen SHM, DPM und Entscheidungsgremien orchestrieren" + richtungen: + - "Bottom-up" + - "Top-down" + - "Horizontal" + + - id: "Z3" + aktivitaet: "Trennung wahren" + beschreibung: "Trennung von fachlicher Bewertung (DPM) und Entscheidung (DSR/MB) wahren" + effekt: "Objektivität und Akzeptanz als neutrale Koordinationsinstanz stärken" + + - id: "Z4" + aktivitaet: "Portfolio-Erkenntnisse aufbereiten" + beschreibung: "Demand-Portfolio-Erkenntnisse regelmäßig aufbereiten (Reviews)" + effekt: "Bessere Koordination durch Mission Board und Abteilungsleitung Planung ermöglichen" + + - id: "Z5" + aktivitaet: "Zielbeitrag sichtbar machen" + beschreibung: "Zielbeitrag anhand klarer KPIs sichtbar machen" + +# ======================================== +# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG +# ======================================== + +funktionsverstaendnis: + charakterisierung: + typ: "Bewertungs- und Orchestrierungsfunktion" + + beschreibung: | + Die neutrale Instanz, die Demands strukturiert bewertet, priorisiert und als + Entscheidungsvorlagen in die zuständigen Gremien einbringt. Die Funktion hält + Methodik, Routing und Demand-Portfolio-Transparenz zusammen – getrennt von der + finalen Entscheidung und der operativen Umsetzung. + + grundprinzipien: + verantwortung_bleibt_wo_sie_hingehoert: + beschreibung: "Klare Trennung zwischen Vorbereitung und Entscheidung" + + entscheidungen: + wo: "Gremien (DSR, MB)" + was: "Freigabe, Ablehnung oder Delegation" + dpm_rolle: "Bereitet vor, präsentiert, führt Beschlüsse nach – entscheidet aber nicht anstelle der Gremien" + + linien_budget_verantwortung: + wo: "MB und Fachbereiche" + dpm_rolle: "Stellt Systematik und Entscheidungsreife sicher" + + partnerschaft_statt_kontrolle: + beschreibung: "DPM arbeitet auf Augenhöhe mit anderen Portfolio-Funktionen" + + partnerschaften: + - partner: "shm" + beziehung: "SHM speist vorqualifizierte Demands ein" + + - partner: "dpm" + beziehung: "DPM qualifiziert und bündelt" + + - partner: "spm" + beziehung: "SPM bewertet Service-Auswirkungen" + + - partner: "ppm" + beziehung: "PPM integriert in das Projektportfolio" + + institutionalisierung: "Diese Partnerschaft ist im DSR institutionalisiert (stimmberechtigte Kernrollen)" + + arbeitsweise: "Folgt definierten Informationsflüssen (Bottom-up, Top-down, Horizontal) und fördert schnelle, anschlussfähige Entscheidungen statt 'Kontrolle'" + + systematische_bewertung_transparenz: + verantwortung_dpm: + - "Klassifizierung" + - "Analyse" + - "Bewertung" + - "Priorisierung" + - "Erstellung Entscheidungsvorlagen" + - "Sauberes Entscheidungs-Routing (je nach Tragweite, Komplexität, Systemebene, Treiber)" + + transparenz: "DPM stellt Transparenz über ein zentrales Demand-Portfolio her und bereitet Reviews für MB/AL-Planung vor" + + nicht_teil_des_mandats: + - "Operative Projektentscheidungen" + - "Umsetzungsleistungen" + + abgrenzung_zu_angrenzenden_funktionen: + - funktion: "shm" + name: "Stakeholder-Management" + tut: "Erfasst und klärt den Bedarf mit Stakeholdern" + uebergabe: "Übergibt vorqualifiziert an DPM" + + - funktion: "dpm" + name: "Demand-Portfolio-Management" + tut: "Klassifiziert, analysiert, bewertet, priorisiert, routet" + uebergabe: "Bringt Vorlagen in DSR/MB ein" + + - funktion: "spm" + name: "Service-Portfolio-Management" + tut: "Prüft Service-Fit/-Impact und katalogseitige Konsequenzen" + + - funktion: "ppm" + name: "Projekt-Portfolio-Management" + tut: "Integriert freigegebene Demands in das Projektportfolio" + und: "Steuert Projektumsetzungen" + +# ======================================== +# 3. VERANTWORTUNGSBEREICHE +# ======================================== + +verantwortungsbereiche: + + # ---------------------------------- + # 3.1 DEMAND-PORTFOLIO-MANAGEMENT + # ---------------------------------- + + bereich_1_portfolio_management: + id: "VB1" + name: "Demand-Portfolio-Management" + + was: + - "Zentrales Demand-Portfolio führen und aktuell halten" + - "Trends und Muster analysieren" + - "Demand-Portfolio-Methodiken optimieren" + - "Entlang Vision-Board-Leitplanken bewerten und priorisieren" + + warum: + - "Strategiekonforme, ressourcenfähige Auswahl durch MB ermöglichen" + - "DPM liefert die strukturierte Grundlage, MB trifft die Allokationsentscheidungen" + - "Objektivität sichern durch Trennung von Bewertung (DPM) und Entscheidung (DSR/MB)" + + wie: + routinen: + - frequenz: "woechentlich" + was: "DSR" + + - frequenz: "quartalsweise" + was: "Demand-Portfolio-Review" + + reporting: + an: "mb" + format: "MB-Kurzpräsentation" + inhalte: + - "Demand-Portfolio-Entwicklung" + - "Muster" + - "Handlungsbedarfe" + - "Empfehlungen" + + # ---------------------------------- + # 3.2 KLASSIFIZIERUNG, ANALYSE, BEWERTUNG, PRIORISIERUNG + # ---------------------------------- + + bereich_2_qualifizierung: + id: "VB2" + name: "Demand-Klassifizierung, Analyse, Bewertung und Priorisierung" + + was: + - "Klassifizierung nach vordefinierten Dimensionen" + - "Unzureichend qualifizierte Demands zurückweisen" + - "Dubletten konsolidieren" + - "Fachexpert:innen einbeziehen" + - "Anwendung von Kategorien & Bewertungskriterien" + - "Nutzung Bedarfs-Steckbrief und Demand-Entscheidungsvorlage" + + warum: + - "Klaren Prozess und Verfahren gegenüber Stakeholder sicherstellen" + - "Entscheidungsfähigkeit herstellen und Vergleichbarkeit sichern" + + wie: + methodik: + beschreibung: "Standardisierte Klassifizierung/Bewertung/Priorisierung" + referenz: "DPM-Framework" + + interaktion: + - mit: "shm" + was: "Rückfragen/Nachforderungen" + + - mit: ["spm", "ppm", "ita"] + was: "Abstimmung bei Service-, Projekt- oder Technikfragen" + + dokumentation: + - "Laufende Statuspflege im Ticketsystem" + - "Statuspflege in weiteren genutzten Tools im Demand-Portfolio" + - "Portfolio-Abgleich" + + # ---------------------------------- + # 3.3 GREMIENARBEIT + # ---------------------------------- + + bereich_3_gremienarbeit: + id: "VB3" + name: "Gremienarbeit" + + was: + - "DSR vorbereiten, in der Sitzung präsentieren, Beschlüsse dokumentieren" + - "MB-Vorstellung MB-relevanter Demands" + - "Nachbearbeitung und Umsetzungsvorbereitung gemäß Beschlüssen" + + warum: + - "Klare, effiziente Entscheidungen im Konsent-Verfahren" + - "Eskalationsfähigkeit zum MB bei Uneinigkeit oder Kompetenzüberschreitung" + + wie: + rhythmus_rolle: + - frequenz: "woechentlich" + gremium: "dsr" + + - frequenz: "ad_hoc" + was: "Sondersitzungen auf Antrag" + + arbeitsweise: + - "Standard-Agenda" + - "Unterlagen vorab" + - "Confluence-Ablage" + - "Unmittelbare Ergebnis-Kommunikation" + + outputs: + - "Beschlussprotokolle" + - "Aktualisierte Demand-Portfolio-/Ticket-Einträge" + - "Übergabe an PPM bei Freigabe" + +# ======================================== +# 4. SCHNITTSTELLEN +# ======================================== + +schnittstellen: + beschreibung: "Input/Output/Typische Abstimmungswege" + + # ---------------------------------- + # 4.1 INPUTS + # ---------------------------------- + + inputs: + beschreibung: "Was das DPM empfängt" + + quellen: + - von: "vision_board" + inhalt: "Strategische Leitplanken und Top-down-Vorgaben, die den Priorisierungsrahmen für Demands setzen" + + - von: "mission_board" + inhalt: "Beschlüsse und Prioritäten für MB-relevante Demands; Rückfragen oder Arbeitsaufträge an DPM bei Vertagung/Delegation" + + - von: "shm" + inhalt: "Übergabe vorqualifizierter Demands inkl. Bedarfs-Steckbrief; Nachlieferungen bei Rückfragen; Statuswechsel 'an DPM übergeben' mit SHM-Einschätzung" + + - von: "spm" + inhalt: "Input zu Service-Fit und -Konsequenzen; Abstimmung, wenn direkte Service-Umsetzung möglich oder Service-Impact zu prüfen ist" + + - von: "ppm" + inhalt: "Informationen zu laufenden/geplanten Projekten zur Überschneidungsprüfung; Abgleich bei potenziellen Projekt-Kollisionen" + + - von: "ita" + inhalt: "Strategische/technische Grundsatz-Inputs zur Machbarkeit und Architekturrahmen" + + - von: "fachexpertinnen" + inhalt: "Punktuelle Expertise für Bewertung/Qualifizierung (fachlich/technisch)" + + # ---------------------------------- + # 4.2 OUTPUTS + # ---------------------------------- + + outputs: + beschreibung: "Was das DPM weitergibt" + + ziele: + - an: "dsr" + inhalt: "Standardisierte Entscheidungsvorlage je Demand (Klassifizierung, Optionen, Empfehlung, Auswirkungen, Risiken), Vorstellung in der Sitzung, Beschluss-/Aufgabenüberführung" + + - an: "mb" + inhalt: "Entscheidungsvorlage für MB-relevante Demands inkl. Priorisierungsempfehlung, strategischer Fit, Ressourcen-/Portfolio-Auswirkungen, Alternativen; Kurzbericht Entscheidung/Nachverfolgung" + + - an: "shm" + inhalt: "Rückmeldung zum Bewertungsergebnis (z.B. Nachlieferung benötigt, Konsolidierung mit ähnlichen Demands, Routing in DSR/MB, Ablehnungs-/Delegationsbegründung); aktualisierte Steckbrief-Anforderungen" + + - an: "spm" + inhalt: "Klärungsanfragen zu Service-Fit/-Impact, dokumentierte Ergebnisse für Entscheidungsvorlage; Hinweise auf Servicekatalog-Anpassungen" + + - an: "ppm" + inhalt: "Übergabe freigegebener Demands in die Projektpipeline inkl. Beschlussreferenz, Priorität, Abhängigkeiten, initialer Projektsteckbrief/Startkonditionen" + + - an: ["ita", "fachexpertinnen"] + inhalt: "Gezielte Architektur-/Fachabfragen zur Entscheidungsreife; zusammengefasste Einschätzungen für die Vorlage (Machbarkeit, Standards, Risiken)" + + - an: "al_p" + inhalt: "Quartalsweiser Demand-Portfolio-Report: KPI-Dashboard, Muster/Trends, Handlungs-/Priorisierungsempfehlungen" + + # ---------------------------------- + # 4.3 TYPISCHE ABSTIMMUNGSWEGE + # ---------------------------------- + + typische_abstimmungswege: + beschreibung: "Standardisierte Interaktionsformate" + + formate: + - format: "dsr_regulaer" + name: "DSR – Regulär" + frequenz: "woechentlich" + + inhalt: + - "Vorstellung der Entscheidungsvorlagen durch DPM" + - "Gemeinsame Bewertung/Klassifizierung" + - "Beschluss (Freigabe, Ablehnung, Zurückstellung, Delegation ans MB)" + - "Protokoll und Ticket-Update" + + - format: "sonder_dsr" + name: "Sonder-DSR" + frequenz: "ad_hoc" + + inhalt: + - "Kurzfristige Klärung dringlicher Themen oder Konflikte" + - "Einberufung auf Anfrage eines DSR-Mitglieds" + - "Entscheidung über Einberufung liegt beim DPM" + - "Eskalationsweg bei Bedarf" + + - format: "mission_board" + name: "Mission Board" + frequenz: "zweiwoechentlich" + + inhalt: + - "Finale Entscheidung zu MB-relevanten Demands" + - "Priorisierung/Ressourcen" + - "DPM liefert MB-Vorlage" + - "PPM/SHM übernehmen Folgekommunikation und Statusupdates" + + - format: "shm_dpm_klaerung" + name: "SHM ↔ DPM – Klärungsschleifen" + frequenz: "laufend" + + inhalt: + - "Nachforderungen bei unvollständigen Demands" + - "Persönliche Kurzabstimmungen/E-Mail" + - "SHM aktualisiert Steckbrief/Ticket" + + - format: "dpm_spm_service" + name: "DPM ↔ SPM – Service-Fit/Impact" + frequenz: "bei_bedarf" + + inhalt: + - "Abgleich Service-Bezug" + - "Direkte Umsetzung kleiner Demands mit SPM/Service Manager" + - "Ergebnissicherung für die Entscheidungsvorlage" + + - format: "dpm_ppm_projekt" + name: "DPM ↔ PPM – Projekt-Abgleich/Übergabe" + frequenz: "bei_bedarf" + + inhalt: + - "Prüfen von Überschneidungen mit laufenden/geplanten Projekten" + - "Übergabe freigegebener Demands in die Projektpipeline" + - "Status-Reporting zurück an DSR/MB" + + - format: "dpm_ita_grundsatz" + name: "DPM ↔ IT-Architektur-Board" + frequenz: "bei_grundsatzfragen" + + inhalt: + - "Technische Leitplanken/Machbarkeit klären" + - "Kurzlage/Fragestellung aus DSR/DPM" + + - format: "portfolio_review" + name: "Demand-Portfolio-Review" + frequenz: "quartalsweise" + + inhalt: + - "Muster-/Trendanalysen" + +# ======================================== +# REFERENZEN +# ======================================== + +referenzen: + verwandte_dokumente: + - titel: "Rollenbeschreibung DPM" + pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml" + unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch" + + - titel: "Demand-Portfolio Governance" + pfad: "#01.2_governance/demand-portfolio-governance.yaml" + relevanz: "Übergeordneter Governance-Rahmen für DPM-Funktion" + + - titel: "RACI-Matrix DPM" + pfad: "#01.2_governance/raci-matrix-dpm.yaml" + relevanz: "Detaillierte Verantwortlichkeiten über Phasen hinweg" + + - titel: "Demand-Klassifizierung" + pfad: "#01.4_methodik/demand-klassifizierung.yaml" relevanz: "Methodischer Kern der DPM-Funktion" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_komplexität.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_komplexität.yaml index 24fc8db..403f6ed 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_komplexität.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_komplexität.yaml @@ -1,329 +1,329 @@ -meta: - typ: "bewertungsmatrix" - dimension: "komplexitaet" - titel: "Klassifizierungsmatrix Komplexität" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - referenzen: - teil_von: "#01.4_methodik/demand-klassifizierung.yaml" - verwendet_in: "#01.4_methodik/demand-bewertung.yaml" - - kontext_tags: - - "komplexitaet" - - "loesungsunsicherheit" - - "bewertungsmatrix" - -# ======================================== -# ZWECK -# ======================================== - -zweck: - beschreibung: | - Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands. - Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell - und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert - zu bewerten. - - grundverstaendnis: | - Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit, - sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch - einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen - Interessen involviert sind. - -# ======================================== -# BEWERTUNGSDIMENSIONEN -# ======================================== - -bewertungsdimensionen: - anzahl: 4 - beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung" - - # ---------------------------------- - # DIMENSION 1: STAKEHOLDER & KOORDINATION - # ---------------------------------- - - dimension_1_stakeholder_koordination: - id: "stakeholder_koordination" - name: "Stakeholder & Koordination" - leitfrage: "Wie viele Akteure müssen koordiniert werden?" - - kriterien: - - kriterium_id: "beteiligte_teams" - name: "Beteiligte Teams" - - auspraegungen: - moderat: "1-2 Teams" - komplex: "3-4 Teams" - hochkomplex: "5+ Teams" - - - kriterium_id: "stakeholder_gruppen" - name: "Stakeholder-Gruppen" - - auspraegungen: - moderat: "1-2 Gruppen" - komplex: "3-5 Gruppen" - hochkomplex: "6+ Gruppen" - - - kriterium_id: "entscheidungsebene" - name: "Entscheidungsebene" - - auspraegungen: - moderat: "Arbeitsebene" - komplex: "Abteilungsleitung" - hochkomplex: "Amtsleitung/Politik" - - # ---------------------------------- - # DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT - # ---------------------------------- - - dimension_2_loesungsraum_unsicherheit: - id: "loesungsraum_unsicherheit" - name: "Lösungsraum & Unsicherheit" - leitfrage: "Wie klar ist der Weg zur Lösung?" - - kriterien: - - kriterium_id: "loesungsklarheit" - name: "Lösungsklarheit" - - auspraegungen: - moderat: "Eindeutige Lösung" - komplex: "2-3 Optionen" - hochkomplex: "Unklar/Exploration nötig" - - - kriterium_id: "technologie_reife" - name: "Technologie-Reife" - - auspraegungen: - moderat: "Bewährt im DIGIT" - komplex: "Neu für DIGIT" - hochkomplex: "Innovativ/Experimentell" - - - kriterium_id: "anforderungsstabilitaet" - name: "Anforderungsstabilität" - - auspraegungen: - moderat: "Stabil & klar" - komplex: "Teilweise unklar" - hochkomplex: "Volatil/Undefiniert" - - # ---------------------------------- - # DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION - # ---------------------------------- - - dimension_3_abhaengigkeiten_integration: - id: "abhaengigkeiten_integration" - name: "Abhängigkeiten & Integration" - leitfrage: "Wie vernetzt ist der Demand?" - - kriterien: - - kriterium_id: "externe_partner" - name: "Externe Partner" - - auspraegungen: - moderat: "Keine" - komplex: "1-2 Partner" - hochkomplex: "3+ Partner" - - - kriterium_id: "system_schnittstellen" - name: "System-Schnittstellen" - - auspraegungen: - moderat: "1-2 Systeme" - komplex: "3-4 Systeme" - hochkomplex: "5+ Systeme" - - - kriterium_id: "zeitliche_abhaengigkeiten" - name: "Zeitliche Abhängigkeiten" - - auspraegungen: - moderat: "Flexibel planbar" - komplex: "Teilweise gebunden" - hochkomplex: "Kritische Verkettung" - - # ---------------------------------- - # DIMENSION 4: RISIKEN & UNWÄGBARKEITEN - # ---------------------------------- - - dimension_4_risiken_unwaegbarkeiten: - id: "risiken_unwaegbarkeiten" - name: "Risiken & Unwägbarkeiten" - leitfrage: "Wie beherrschbar sind die Risiken?" - - kriterien: - - kriterium_id: "budget_unsicherheit" - name: "Budget-Unsicherheit" - - auspraegungen: - moderat: "Verlässlich planbar" - komplex: "Bandbreiten-Schätzung" - hochkomplex: "Unkalkulierbar" - - - kriterium_id: "termin_risiko" - name: "Termin-Risiko" - - auspraegungen: - moderat: "Gering" - komplex: "Mittel" - hochkomplex: "Hoch/Unklar" - - - kriterium_id: "compliance_risiken" - name: "Compliance-Risiken" - - auspraegungen: - moderat: "Keine" - komplex: "Handhabbar" - hochkomplex: "Kritisch/Unklar" - -# ======================================== -# SIGNALE FÜR HOCHKOMPLEXITÄT -# ======================================== - -signale_hochkomplexitaet: - beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten" - - signale: - - id: "paradoxe_anforderungen" - signal: "Paradoxe Anforderungen" - beispiel: "\"Soll alles können, darf nichts kosten\"" - interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern" - - - id: "moving_targets" - signal: "Moving Targets" - beschreibung: "Anforderungen ändern sich während der Analyse" - interpretation: "Instabile Ausgangslage, hohe Unsicherheit" - - - id: "interessenskomplexitaet" - signal: "Interessenskomplexität" - beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen" - interpretation: "Verdeckte Agenden, schwierige Konsensfindung" - - - id: "regulatorische_grauzonen" - signal: "Regulatorische Grauzonen" - beschreibung: "Rechtslage unklar oder im Wandel" - interpretation: "Compliance-Risiko, Neuorientierung erforderlich" - - - id: "praezedenzfall" - signal: "Präzedenzfall" - beschreibung: "Erstmalige Herausforderung ohne Referenz" - interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig" - -# ======================================== -# ANWENDUNG DER MATRIX -# ======================================== - -anwendung: - bewertungsverfahren: - beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung" - - schritte: - - schritt: 1 - name: "Dimension-Scoring" - beschreibung: "Jede der vier Dimensionen separat bewerten" - output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)" - - - schritt: 2 - name: "Komplexitäts-Aggregation" - beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen" - logik: "siehe aggregationslogik unten" - - - schritt: 3 - name: "Kontextuelle Anpassung" - beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren" - - aggregationslogik: - titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\"" - - regeln: - - bedingung: "1 Dimension = \"Hochkomplex\"" - ergebnis: "Hochkomplex" - rationale: "Ein hochkomplexer Aspekt dominiert" - - - bedingung: "3 Dimensionen = \"Komplex\"" - ergebnis: "Hochkomplex" - rationale: "Kumulative Komplexität führt zu Hochkomplexität" - - - bedingung: "2 Dimensionen = \"Komplex\"" - ergebnis: "Komplex" - rationale: "Moderate kumulative Komplexität" - - - bedingung: "ansonsten" - ergebnis: "Moderat" - rationale: "Überschaubare Komplexität" - -# ======================================== -# KONSEQUENZEN DER BEWERTUNG -# ======================================== - -konsequenzen: - - komplexitaet: "moderat" - konsequenz: "Direkte Umsetzung" - typische_massnahmen: - - "Standardprozess" - - "Keine Sonderanalysen" - - - komplexitaet: "komplex" - konsequenz: "Strukturierte Analyse" - typische_massnahmen: - - "Vorprojekt empfohlen" - - "Experteneinbindung" - - "Risikomanagement" - - - komplexitaet: "hochkomplex" - konsequenz: "Sondierung zwingend" - typische_massnahmen: - - "Machbarkeitsstudie" - - "Pilot/PoC" - - "Steering Committee" - -# ======================================== -# UMGANG MIT KOMPLEXITÄT -# ======================================== - -umgang_mit_komplexitaet: - bei_hochkomplexitaet: - massnahmen: - - id: "M1" - name: "Komplexitätsreduktion prüfen" - frage: "Kann der Demand geteilt werden?" - ziel: "Reduzierung auf handhabbare Teilprobleme" - - - id: "M2" - name: "Sondierung priorisieren" - prinzip: "Keine vorschnellen Lösungsversprechen" - ziel: "Exploration vor Commitment" - - - id: "M3" - name: "Stakeholder-Zielausrichtung" - aktivitaet: "Frühzeitige Erwartungsklärung" - ziel: "Konvergenz der Interessen" - - - id: "M4" - name: "Iteratives Vorgehen" - prinzip: "Schritt-für-Schritt statt \"Big Bang\"" - ziel: "Schrittweise Komplexitätsreduktion" - - komplexitaetsfallen_vermeiden: - beschreibung: "Typische Denkfehler im Umgang mit Komplexität" - - fallen: - - falle: "Schein-Einfachheit" - beispiel: "\"Wir brauchen nur Tool X\"" - gegenmassnahme: "Immer nach dem \"Warum\" fragen" - - - falle: "Komplexitäts-Paralysis" - beschreibung: "Nicht alles Komplexe ist unlösbar" - gegenmassnahme: "Handlungsfähigkeit bewahren" - - - falle: "Oversimplification" - beschreibung: "Komplexität nicht wegdefinieren" - gegenmassnahme: "Realistische Einschätzung" - - - falle: "Analysis-Paralysis" - beschreibung: "Irgendwann muss entschieden werden" +meta: + typ: "bewertungsmatrix" + dimension: "komplexitaet" + titel: "Klassifizierungsmatrix Komplexität" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + referenzen: + teil_von: "#01.4_methodik/demand-klassifizierung.yaml" + verwendet_in: "#01.4_methodik/demand-bewertung.yaml" + + kontext_tags: + - "komplexitaet" + - "loesungsunsicherheit" + - "bewertungsmatrix" + +# ======================================== +# ZWECK +# ======================================== + +zweck: + beschreibung: | + Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands. + Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell + und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert + zu bewerten. + + grundverstaendnis: | + Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit, + sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch + einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen + Interessen involviert sind. + +# ======================================== +# BEWERTUNGSDIMENSIONEN +# ======================================== + +bewertungsdimensionen: + anzahl: 4 + beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung" + + # ---------------------------------- + # DIMENSION 1: STAKEHOLDER & KOORDINATION + # ---------------------------------- + + dimension_1_stakeholder_koordination: + id: "stakeholder_koordination" + name: "Stakeholder & Koordination" + leitfrage: "Wie viele Akteure müssen koordiniert werden?" + + kriterien: + - kriterium_id: "beteiligte_teams" + name: "Beteiligte Teams" + + auspraegungen: + moderat: "1-2 Teams" + komplex: "3-4 Teams" + hochkomplex: "5+ Teams" + + - kriterium_id: "stakeholder_gruppen" + name: "Stakeholder-Gruppen" + + auspraegungen: + moderat: "1-2 Gruppen" + komplex: "3-5 Gruppen" + hochkomplex: "6+ Gruppen" + + - kriterium_id: "entscheidungsebene" + name: "Entscheidungsebene" + + auspraegungen: + moderat: "Arbeitsebene" + komplex: "Abteilungsleitung" + hochkomplex: "Amtsleitung/Politik" + + # ---------------------------------- + # DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT + # ---------------------------------- + + dimension_2_loesungsraum_unsicherheit: + id: "loesungsraum_unsicherheit" + name: "Lösungsraum & Unsicherheit" + leitfrage: "Wie klar ist der Weg zur Lösung?" + + kriterien: + - kriterium_id: "loesungsklarheit" + name: "Lösungsklarheit" + + auspraegungen: + moderat: "Eindeutige Lösung" + komplex: "2-3 Optionen" + hochkomplex: "Unklar/Exploration nötig" + + - kriterium_id: "technologie_reife" + name: "Technologie-Reife" + + auspraegungen: + moderat: "Bewährt im DIGIT" + komplex: "Neu für DIGIT" + hochkomplex: "Innovativ/Experimentell" + + - kriterium_id: "anforderungsstabilitaet" + name: "Anforderungsstabilität" + + auspraegungen: + moderat: "Stabil & klar" + komplex: "Teilweise unklar" + hochkomplex: "Volatil/Undefiniert" + + # ---------------------------------- + # DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION + # ---------------------------------- + + dimension_3_abhaengigkeiten_integration: + id: "abhaengigkeiten_integration" + name: "Abhängigkeiten & Integration" + leitfrage: "Wie vernetzt ist der Demand?" + + kriterien: + - kriterium_id: "externe_partner" + name: "Externe Partner" + + auspraegungen: + moderat: "Keine" + komplex: "1-2 Partner" + hochkomplex: "3+ Partner" + + - kriterium_id: "system_schnittstellen" + name: "System-Schnittstellen" + + auspraegungen: + moderat: "1-2 Systeme" + komplex: "3-4 Systeme" + hochkomplex: "5+ Systeme" + + - kriterium_id: "zeitliche_abhaengigkeiten" + name: "Zeitliche Abhängigkeiten" + + auspraegungen: + moderat: "Flexibel planbar" + komplex: "Teilweise gebunden" + hochkomplex: "Kritische Verkettung" + + # ---------------------------------- + # DIMENSION 4: RISIKEN & UNWÄGBARKEITEN + # ---------------------------------- + + dimension_4_risiken_unwaegbarkeiten: + id: "risiken_unwaegbarkeiten" + name: "Risiken & Unwägbarkeiten" + leitfrage: "Wie beherrschbar sind die Risiken?" + + kriterien: + - kriterium_id: "budget_unsicherheit" + name: "Budget-Unsicherheit" + + auspraegungen: + moderat: "Verlässlich planbar" + komplex: "Bandbreiten-Schätzung" + hochkomplex: "Unkalkulierbar" + + - kriterium_id: "termin_risiko" + name: "Termin-Risiko" + + auspraegungen: + moderat: "Gering" + komplex: "Mittel" + hochkomplex: "Hoch/Unklar" + + - kriterium_id: "compliance_risiken" + name: "Compliance-Risiken" + + auspraegungen: + moderat: "Keine" + komplex: "Handhabbar" + hochkomplex: "Kritisch/Unklar" + +# ======================================== +# SIGNALE FÜR HOCHKOMPLEXITÄT +# ======================================== + +signale_hochkomplexitaet: + beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten" + + signale: + - id: "paradoxe_anforderungen" + signal: "Paradoxe Anforderungen" + beispiel: "\"Soll alles können, darf nichts kosten\"" + interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern" + + - id: "moving_targets" + signal: "Moving Targets" + beschreibung: "Anforderungen ändern sich während der Analyse" + interpretation: "Instabile Ausgangslage, hohe Unsicherheit" + + - id: "interessenskomplexitaet" + signal: "Interessenskomplexität" + beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen" + interpretation: "Verdeckte Agenden, schwierige Konsensfindung" + + - id: "regulatorische_grauzonen" + signal: "Regulatorische Grauzonen" + beschreibung: "Rechtslage unklar oder im Wandel" + interpretation: "Compliance-Risiko, Neuorientierung erforderlich" + + - id: "praezedenzfall" + signal: "Präzedenzfall" + beschreibung: "Erstmalige Herausforderung ohne Referenz" + interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig" + +# ======================================== +# ANWENDUNG DER MATRIX +# ======================================== + +anwendung: + bewertungsverfahren: + beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung" + + schritte: + - schritt: 1 + name: "Dimension-Scoring" + beschreibung: "Jede der vier Dimensionen separat bewerten" + output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)" + + - schritt: 2 + name: "Komplexitäts-Aggregation" + beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen" + logik: "siehe aggregationslogik unten" + + - schritt: 3 + name: "Kontextuelle Anpassung" + beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren" + + aggregationslogik: + titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\"" + + regeln: + - bedingung: "1 Dimension = \"Hochkomplex\"" + ergebnis: "Hochkomplex" + rationale: "Ein hochkomplexer Aspekt dominiert" + + - bedingung: "3 Dimensionen = \"Komplex\"" + ergebnis: "Hochkomplex" + rationale: "Kumulative Komplexität führt zu Hochkomplexität" + + - bedingung: "2 Dimensionen = \"Komplex\"" + ergebnis: "Komplex" + rationale: "Moderate kumulative Komplexität" + + - bedingung: "ansonsten" + ergebnis: "Moderat" + rationale: "Überschaubare Komplexität" + +# ======================================== +# KONSEQUENZEN DER BEWERTUNG +# ======================================== + +konsequenzen: + - komplexitaet: "moderat" + konsequenz: "Direkte Umsetzung" + typische_massnahmen: + - "Standardprozess" + - "Keine Sonderanalysen" + + - komplexitaet: "komplex" + konsequenz: "Strukturierte Analyse" + typische_massnahmen: + - "Vorprojekt empfohlen" + - "Experteneinbindung" + - "Risikomanagement" + + - komplexitaet: "hochkomplex" + konsequenz: "Sondierung zwingend" + typische_massnahmen: + - "Machbarkeitsstudie" + - "Pilot/PoC" + - "Steering Committee" + +# ======================================== +# UMGANG MIT KOMPLEXITÄT +# ======================================== + +umgang_mit_komplexitaet: + bei_hochkomplexitaet: + massnahmen: + - id: "M1" + name: "Komplexitätsreduktion prüfen" + frage: "Kann der Demand geteilt werden?" + ziel: "Reduzierung auf handhabbare Teilprobleme" + + - id: "M2" + name: "Sondierung priorisieren" + prinzip: "Keine vorschnellen Lösungsversprechen" + ziel: "Exploration vor Commitment" + + - id: "M3" + name: "Stakeholder-Zielausrichtung" + aktivitaet: "Frühzeitige Erwartungsklärung" + ziel: "Konvergenz der Interessen" + + - id: "M4" + name: "Iteratives Vorgehen" + prinzip: "Schritt-für-Schritt statt \"Big Bang\"" + ziel: "Schrittweise Komplexitätsreduktion" + + komplexitaetsfallen_vermeiden: + beschreibung: "Typische Denkfehler im Umgang mit Komplexität" + + fallen: + - falle: "Schein-Einfachheit" + beispiel: "\"Wir brauchen nur Tool X\"" + gegenmassnahme: "Immer nach dem \"Warum\" fragen" + + - falle: "Komplexitäts-Paralysis" + beschreibung: "Nicht alles Komplexe ist unlösbar" + gegenmassnahme: "Handlungsfähigkeit bewahren" + + - falle: "Oversimplification" + beschreibung: "Komplexität nicht wegdefinieren" + gegenmassnahme: "Realistische Einschätzung" + + - falle: "Analysis-Paralysis" + beschreibung: "Irgendwann muss entschieden werden" gegenmassnahme: "Entscheidungszeitpunkt definieren" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_tragweite.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_tragweite.yaml index 016abe2..a117452 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_tragweite.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_klassifizierungsmatrix_tragweite.yaml @@ -1,295 +1,295 @@ -meta: - typ: "bewertungsmatrix" - dimension: "tragweite" - titel: "Klassifizierungsmatrix Tragweite" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - - referenzen: - teil_von: "#01.4_methodik/demand-klassifizierung.yaml" - verwendet_in: "#01.4_methodik/demand-bewertung.yaml" - - kontext_tags: - - "tragweite" - - "veraenderungstiefe" - - "bewertungsmatrix" - -# ======================================== -# ZWECK -# ======================================== - -zweck: - beschreibung: | - Diese Bewertungsmatrix dient der detaillierten Einordnung von Demands in die - Dimension "Tragweite". Sie erweitert die Grunddefinitionen aus dem - Klassifizierungsmodell um konkrete Bewertungskriterien und unterstützt DPMs - bei der Einschätzung der Veränderungstiefe. - -# ======================================== -# BEWERTUNGSPERSPEKTIVEN -# ======================================== - -bewertungsperspektiven: - anzahl: 4 - beschreibung: "Vier komplementäre Perspektiven zur Bewertung der Tragweite" - prinzip: "Dominanz-Prinzip: Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite" - - # ---------------------------------- - # PERSPEKTIVE 1: NUTZER:INNEN - # ---------------------------------- - - perspektive_1_nutzerinnen: - id: "nutzerinnen" - name: "Nutzer:innen-Perspektive" - leitfrage: "Wie stark verändert sich die Arbeitsweise der Endanwender:innen?" - - kriterien: - - kriterium_id: "schulungsbedarf" - name: "Schulungsbedarf" - - auspraegungen: - optimierung: "Keine Schulungen nötig" - ausbau: "Punktuelle Schulungen" - neugestaltung: "Flächendeckende Schulungen" - - - kriterium_id: "verhaltensaenderung" - name: "Verhaltensänderung" - - auspraegungen: - optimierung: "Minimale Anpassung" - ausbau: "Neue Funktionen lernen" - neugestaltung: "Neue Arbeitsweisen" - - - kriterium_id: "nutzer_impact" - name: "Nutzer-Impact" - - auspraegungen: - optimierung: "< 20% merken Veränderung" - ausbau: "20-70% betroffen" - neugestaltung: "> 70% der Nutzer betroffen" - - - kriterium_id: "rueckfallmoeglichkeit" - name: "Rückfallmöglichkeit" - - auspraegungen: - optimierung: "Jederzeit möglich" - ausbau: "Mit Aufwand möglich" - neugestaltung: "Nicht mehr möglich" - - # ---------------------------------- - # PERSPEKTIVE 2: TECHNISCH - # ---------------------------------- - - perspektive_2_technisch: - id: "technisch" - name: "Technische Perspektive" - leitfrage: "Wie tiefgreifend sind die technischen Veränderungen?" - - kriterien: - - kriterium_id: "betroffenheit_anwendungen" - name: "Betroffenheit von Anwendungen" - - auspraegungen: - optimierung: "< 20% Anwendungen betroffen" - ausbau: "20-70% Anwendungen betroffen" - neugestaltung: "> 70% Anwendungen betroffen" - - - kriterium_id: "systemgrenzen" - name: "Systemgrenzen" - - auspraegungen: - optimierung: "Innerhalb eines Systems" - ausbau: "Systemübergreifend" - neugestaltung: "Systemlandschaft-Umbau" - - - kriterium_id: "technologie_stack" - name: "Technologie-Stack" - - auspraegungen: - optimierung: "Bestehende Technologien" - ausbau: "Ergänzung neuer Technologie" - neugestaltung: "Technologiewechsel" - - - kriterium_id: "datenmigration" - name: "Datenmigration" - - auspraegungen: - optimierung: "Keine erforderlich" - ausbau: "Teilmigration" - neugestaltung: "Vollmigration" - - # ---------------------------------- - # PERSPEKTIVE 3: ORGANISATORISCH - # ---------------------------------- - - perspektive_3_organisatorisch: - id: "organisatorisch" - name: "Organisatorische Perspektive" - leitfrage: "Wie stark verändern sich Prozesse und Strukturen?" - - kriterien: - - kriterium_id: "prozessaenderung" - name: "Prozessänderung" - - auspraegungen: - optimierung: "Optimierung im Detail" - ausbau: "Prozesserweiterung" - neugestaltung: "Prozess-Neudesign" - - - kriterium_id: "rollenveraenderung" - name: "Rollenveränderung" - - auspraegungen: - optimierung: "Keine" - ausbau: "Neue/veränderte Aufgaben" - neugestaltung: "Neue Rollen/Stellen" - - - kriterium_id: "aemter_uebergreifend" - name: "Ämter-übergreifend" - - auspraegungen: - optimierung: "Ein Amt" - ausbau: "2-3 Ämter" - neugestaltung: "Gesamtorganisation" - - - kriterium_id: "abteilungs_uebergreifend_digit" - name: "Abteilungs-übergreifend (DIGIT)" - - auspraegungen: - optimierung: "Eine Abteilung" - ausbau: "2-3 Abteilungen" - neugestaltung: "Gesamt-DIGIT" - - - kriterium_id: "governance_impact" - name: "Governance-Impact" - - auspraegungen: - optimierung: "Keine Änderung" - ausbau: "Anpassung nötig" - neugestaltung: "Neue Governance" - - # ---------------------------------- - # PERSPEKTIVE 4: FINANZIELL - # ---------------------------------- - - perspektive_4_finanziell: - id: "finanziell" - name: "Finanzielle Perspektive" - leitfrage: "Welche finanziellen Auswirkungen hat die Veränderung?" - - kriterien: - - kriterium_id: "investitionsvolumen_extern" - name: "Externes Investitionsvolumen" - - auspraegungen: - optimierung: "< 50.000 €" - ausbau: "50.000 - 200.000 €" - neugestaltung: "> 200.000 €" - - - kriterium_id: "folgekosten" - name: "Folgekosten" - - auspraegungen: - optimierung: "Marginal" - ausbau: "Moderat" - neugestaltung: "Erheblich" - -# ======================================== -# ANWENDUNG DER MATRIX -# ======================================== - -anwendung: - bewertungslogik: - schritte: - - schritt: 1 - name: "Perspektiven-Bewertung" - beschreibung: "Jede der vier Perspektiven wird separat bewertet" - output: "4 Einzelbewertungen (Optimierung/Ausbau/Neugestaltung)" - - - schritt: 2 - name: "Dominanz-Prinzip" - beschreibung: "Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite" - rationale: "Ein transformativer Aspekt reicht, um den gesamten Demand als transformativ einzustufen" - - - schritt: 3 - name: "Begründungspflicht" - beschreibung: "Bei Abweichungen zwischen Perspektiven ist eine explizite Begründung erforderlich" - ziel: "Nachvollziehbarkeit und Lerneffekte" - -# ======================================== -# GRENZFÄLLE UND INTERPRETATIONSHILFEN -# ======================================== - -grenzfaelle: - typische_indikatoren_neugestaltung: - beschreibung: "Signale für transformative/neugestaltende Demands" - - indikatoren: - - "Ablösung von Altsystemen" - - "Gesetzlich getriebene Paradigmenwechsel" - - "Einführung völlig neuer Geschäftsmodelle" - - "Fundamentale Änderung der Nutzer:innen-Interaktion" - - abgrenzung_optimierung_vs_ausbau: - optimierung_inkrementell: - beschreibung: "Verbesserung des Bestehenden ohne neue Konzepte" - beispiele: - - "UI-Verbesserungen" - - "Performance-Optimierung" - - "Bugfixes" - - ausbau_evolutionaer: - beschreibung: "Hinzufügen neuer Fähigkeiten zum bestehenden System" - beispiele: - - "Neue Module" - - "API-Erweiterungen" - - "Prozessdigitalisierung" - - umgang_mit_unsicherheit: - beschreibung: "Vorgehen bei unklarer Einordnung" - - massnahmen: - - schritt: 1 - name: "Workshop mit betroffenen Stakeholdern" - ziel: "Verschiedene Perspektiven integrieren" - - - schritt: 2 - name: "Pilot-Phase zur Validierung der Tragweite" - ziel: "Empirische Klärung" - - - schritt: 3 - name: "Vorsichtsprinzip" - regel: "Im Zweifel: Höhere Kategorie wählen" - rationale: "Unterschätzung vermeiden" - -# ======================================== -# DOKUMENTATIONSANFORDERUNG -# ======================================== - -dokumentationsstandard: - template: - struktur: | - TRAGWEITEN-ANALYSE - - Nutzer:innen: [Ausprägung] - Begründung: [Kurz und prägnant] - - Technisch: [Ausprägung] - Begründung: [Kurz und prägnant] - - Organisatorisch: [Ausprägung] - Begründung: [Kurz und prägnant] - - Finanziell: [Ausprägung] - Begründung: [Kurz und prägnant] - - GESAMTTRAGWEITE: [Kategorie] - - BEGRÜNDUNG: [Warum diese Einordnung, insb. bei Divergenz] - +meta: + typ: "bewertungsmatrix" + dimension: "tragweite" + titel: "Klassifizierungsmatrix Tragweite" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + + referenzen: + teil_von: "#01.4_methodik/demand-klassifizierung.yaml" + verwendet_in: "#01.4_methodik/demand-bewertung.yaml" + + kontext_tags: + - "tragweite" + - "veraenderungstiefe" + - "bewertungsmatrix" + +# ======================================== +# ZWECK +# ======================================== + +zweck: + beschreibung: | + Diese Bewertungsmatrix dient der detaillierten Einordnung von Demands in die + Dimension "Tragweite". Sie erweitert die Grunddefinitionen aus dem + Klassifizierungsmodell um konkrete Bewertungskriterien und unterstützt DPMs + bei der Einschätzung der Veränderungstiefe. + +# ======================================== +# BEWERTUNGSPERSPEKTIVEN +# ======================================== + +bewertungsperspektiven: + anzahl: 4 + beschreibung: "Vier komplementäre Perspektiven zur Bewertung der Tragweite" + prinzip: "Dominanz-Prinzip: Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite" + + # ---------------------------------- + # PERSPEKTIVE 1: NUTZER:INNEN + # ---------------------------------- + + perspektive_1_nutzerinnen: + id: "nutzerinnen" + name: "Nutzer:innen-Perspektive" + leitfrage: "Wie stark verändert sich die Arbeitsweise der Endanwender:innen?" + + kriterien: + - kriterium_id: "schulungsbedarf" + name: "Schulungsbedarf" + + auspraegungen: + optimierung: "Keine Schulungen nötig" + ausbau: "Punktuelle Schulungen" + neugestaltung: "Flächendeckende Schulungen" + + - kriterium_id: "verhaltensaenderung" + name: "Verhaltensänderung" + + auspraegungen: + optimierung: "Minimale Anpassung" + ausbau: "Neue Funktionen lernen" + neugestaltung: "Neue Arbeitsweisen" + + - kriterium_id: "nutzer_impact" + name: "Nutzer-Impact" + + auspraegungen: + optimierung: "< 20% merken Veränderung" + ausbau: "20-70% betroffen" + neugestaltung: "> 70% der Nutzer betroffen" + + - kriterium_id: "rueckfallmoeglichkeit" + name: "Rückfallmöglichkeit" + + auspraegungen: + optimierung: "Jederzeit möglich" + ausbau: "Mit Aufwand möglich" + neugestaltung: "Nicht mehr möglich" + + # ---------------------------------- + # PERSPEKTIVE 2: TECHNISCH + # ---------------------------------- + + perspektive_2_technisch: + id: "technisch" + name: "Technische Perspektive" + leitfrage: "Wie tiefgreifend sind die technischen Veränderungen?" + + kriterien: + - kriterium_id: "betroffenheit_anwendungen" + name: "Betroffenheit von Anwendungen" + + auspraegungen: + optimierung: "< 20% Anwendungen betroffen" + ausbau: "20-70% Anwendungen betroffen" + neugestaltung: "> 70% Anwendungen betroffen" + + - kriterium_id: "systemgrenzen" + name: "Systemgrenzen" + + auspraegungen: + optimierung: "Innerhalb eines Systems" + ausbau: "Systemübergreifend" + neugestaltung: "Systemlandschaft-Umbau" + + - kriterium_id: "technologie_stack" + name: "Technologie-Stack" + + auspraegungen: + optimierung: "Bestehende Technologien" + ausbau: "Ergänzung neuer Technologie" + neugestaltung: "Technologiewechsel" + + - kriterium_id: "datenmigration" + name: "Datenmigration" + + auspraegungen: + optimierung: "Keine erforderlich" + ausbau: "Teilmigration" + neugestaltung: "Vollmigration" + + # ---------------------------------- + # PERSPEKTIVE 3: ORGANISATORISCH + # ---------------------------------- + + perspektive_3_organisatorisch: + id: "organisatorisch" + name: "Organisatorische Perspektive" + leitfrage: "Wie stark verändern sich Prozesse und Strukturen?" + + kriterien: + - kriterium_id: "prozessaenderung" + name: "Prozessänderung" + + auspraegungen: + optimierung: "Optimierung im Detail" + ausbau: "Prozesserweiterung" + neugestaltung: "Prozess-Neudesign" + + - kriterium_id: "rollenveraenderung" + name: "Rollenveränderung" + + auspraegungen: + optimierung: "Keine" + ausbau: "Neue/veränderte Aufgaben" + neugestaltung: "Neue Rollen/Stellen" + + - kriterium_id: "aemter_uebergreifend" + name: "Ämter-übergreifend" + + auspraegungen: + optimierung: "Ein Amt" + ausbau: "2-3 Ämter" + neugestaltung: "Gesamtorganisation" + + - kriterium_id: "abteilungs_uebergreifend_digit" + name: "Abteilungs-übergreifend (DIGIT)" + + auspraegungen: + optimierung: "Eine Abteilung" + ausbau: "2-3 Abteilungen" + neugestaltung: "Gesamt-DIGIT" + + - kriterium_id: "governance_impact" + name: "Governance-Impact" + + auspraegungen: + optimierung: "Keine Änderung" + ausbau: "Anpassung nötig" + neugestaltung: "Neue Governance" + + # ---------------------------------- + # PERSPEKTIVE 4: FINANZIELL + # ---------------------------------- + + perspektive_4_finanziell: + id: "finanziell" + name: "Finanzielle Perspektive" + leitfrage: "Welche finanziellen Auswirkungen hat die Veränderung?" + + kriterien: + - kriterium_id: "investitionsvolumen_extern" + name: "Externes Investitionsvolumen" + + auspraegungen: + optimierung: "< 50.000 €" + ausbau: "50.000 - 200.000 €" + neugestaltung: "> 200.000 €" + + - kriterium_id: "folgekosten" + name: "Folgekosten" + + auspraegungen: + optimierung: "Marginal" + ausbau: "Moderat" + neugestaltung: "Erheblich" + +# ======================================== +# ANWENDUNG DER MATRIX +# ======================================== + +anwendung: + bewertungslogik: + schritte: + - schritt: 1 + name: "Perspektiven-Bewertung" + beschreibung: "Jede der vier Perspektiven wird separat bewertet" + output: "4 Einzelbewertungen (Optimierung/Ausbau/Neugestaltung)" + + - schritt: 2 + name: "Dominanz-Prinzip" + beschreibung: "Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite" + rationale: "Ein transformativer Aspekt reicht, um den gesamten Demand als transformativ einzustufen" + + - schritt: 3 + name: "Begründungspflicht" + beschreibung: "Bei Abweichungen zwischen Perspektiven ist eine explizite Begründung erforderlich" + ziel: "Nachvollziehbarkeit und Lerneffekte" + +# ======================================== +# GRENZFÄLLE UND INTERPRETATIONSHILFEN +# ======================================== + +grenzfaelle: + typische_indikatoren_neugestaltung: + beschreibung: "Signale für transformative/neugestaltende Demands" + + indikatoren: + - "Ablösung von Altsystemen" + - "Gesetzlich getriebene Paradigmenwechsel" + - "Einführung völlig neuer Geschäftsmodelle" + - "Fundamentale Änderung der Nutzer:innen-Interaktion" + + abgrenzung_optimierung_vs_ausbau: + optimierung_inkrementell: + beschreibung: "Verbesserung des Bestehenden ohne neue Konzepte" + beispiele: + - "UI-Verbesserungen" + - "Performance-Optimierung" + - "Bugfixes" + + ausbau_evolutionaer: + beschreibung: "Hinzufügen neuer Fähigkeiten zum bestehenden System" + beispiele: + - "Neue Module" + - "API-Erweiterungen" + - "Prozessdigitalisierung" + + umgang_mit_unsicherheit: + beschreibung: "Vorgehen bei unklarer Einordnung" + + massnahmen: + - schritt: 1 + name: "Workshop mit betroffenen Stakeholdern" + ziel: "Verschiedene Perspektiven integrieren" + + - schritt: 2 + name: "Pilot-Phase zur Validierung der Tragweite" + ziel: "Empirische Klärung" + + - schritt: 3 + name: "Vorsichtsprinzip" + regel: "Im Zweifel: Höhere Kategorie wählen" + rationale: "Unterschätzung vermeiden" + +# ======================================== +# DOKUMENTATIONSANFORDERUNG +# ======================================== + +dokumentationsstandard: + template: + struktur: | + TRAGWEITEN-ANALYSE + + Nutzer:innen: [Ausprägung] + Begründung: [Kurz und prägnant] + + Technisch: [Ausprägung] + Begründung: [Kurz und prägnant] + + Organisatorisch: [Ausprägung] + Begründung: [Kurz und prägnant] + + Finanziell: [Ausprägung] + Begründung: [Kurz und prägnant] + + GESAMTTRAGWEITE: [Kategorie] + + BEGRÜNDUNG: [Warum diese Einordnung, insb. bei Divergenz] + hinweis: "Bei divergierenden Perspektiven muss erklärt werden, warum eine Perspektive dominiert" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_raci.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_raci.yaml index 34010b1..f992f84 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_raci.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_raci.yaml @@ -1,668 +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" +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" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_rollenbeschreibung-dpm.yaml b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_rollenbeschreibung-dpm.yaml index 359d747..ffae10c 100644 --- a/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_rollenbeschreibung-dpm.yaml +++ b/#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_rollenbeschreibung-dpm.yaml @@ -1,493 +1,493 @@ -meta: - typ: "rollenbeschreibung" - rolle_id: "dpm" - rolle_name: "Demand-Portfolio-Manager:in" - aliases: ["DPM", "Portfolio-Manager", "Demand-Manager"] - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status: - ueberprueft_durch: "DPM-Teammitglied" - abgestimmt_zwischen: ["human", "DPM-Teammitglied"] - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - status: "abgenommen_in_gesamtkonzept" - hinweis: "anpassen auf Basis der weiteren Workstream-Ergebnisse" - - kontext_tags: - - "demand-management" - - "portfolio-steuerung" - - "qualifizierung" - - "bewertung" - - "priorisierung" - -# ======================================== -# 1. ROLLENZWECK -# ======================================== - -rollenzweck: - kurz: "Zentrale Instanz für Qualifizierung, Bewertung und Portfolio-Steuerung aller Demands im DIGIT" - - ausfuehrlich: | - Der:die Demand-Portfolio-Manager:in transformiert vorqualifizierte Demands in - Demand-Entscheidungsvorlagen und schafft die Grundlage für optimale - Ressourcensteuerung durch die verantwortlichen Gremien. - - verantwortung: - ab_wann: "nach erfolgter Bedarfsklärung durch Stakeholder-Management" - fuer: "alle Demands" - bis: "Aufbereitung für Entscheidungsgremien" - - entscheidungsgremien: - - gremium_id: "dsr" - gremium_name: "Demand & Stakeholder-Runde" - - gremium_id: "mission_board" - gremium_name: "Mission Board" - -# ======================================== -# 2. ORGANISATORISCHE EINORDNUNG -# ======================================== - -organisatorische_einordnung: - zuordnung: - abteilung: "Abteilung Planung" - abteilungskuerzel: "AL-P" - - auspraegungen: - beschreibung: "Spezialisierungen nach Themenfeld oder Kapazität möglich, aber nicht strukturell vorgegeben" - hinweis: | - Die frühere Unterscheidung in DPM Core-IT und DPM Non-Core-IT entfällt. - Alle Demands – unabhängig von ihrer Herkunft (Betrieb oder Innovation) – - durchlaufen denselben Prozess. Spezialisierungen können bei Bedarf - themenfeld- oder kapazitätsbezogen entstehen. - - berichtslinie: - berichtet_an: "Abteilungsleitung Planung" - berichtet_an_rolle_id: "al_p" - - arbeitsmodell: - typ: "Vollzeitfunktion" - vertretung: "gegenseitige Vertretungsregelung zwischen DPM-Mitarbeitenden" - -# ======================================== -# 3. KERNVERANTWORTLICHKEITEN -# ======================================== - -kernverantwortlichkeiten: - bereich_1_portfolio_management: - name: "Demand-Portfolio-Management" - - aufgaben: - - id: "PM-01" - titel: "Portfolio-Aufbau und -Pflege" - beschreibung: "Aufbau und Pflege eines transparenten Demand-Portfolios" - frequenz: "kontinuierlich" - output: "aktuelles_demand_portfolio" - - - id: "PM-02" - titel: "Strategische Portfolio-Analyse" - beschreibung: "Strategische Analyse des Demand-Portfolios und Identifizierung von Trends für das Mission Board" - frequenz: "quartalsweise" - output: "portfolio_trend_analyse" - empfaenger: "mission_board" - - - id: "PM-03" - titel: "Portfolio-Optimierung" - beschreibung: "Kontinuierliche Optimierung der Demand-Portfolio-Zusammensetzung" - frequenz: "kontinuierlich" - - - id: "PM-04" - titel: "Strategiekonformität sicherstellen" - beschreibung: "Bewertung und Priorisierung von Demands gemäß der strategischen Leitplanken des Vision Board" - referenz_zu: "vision_board" - frequenz: "pro_demand" - - bereich_2_demand_qualifizierung: - name: "Demand-Qualifizierung, Bewertung und Priorisierung" - - aufgaben: - - id: "QBP-01" - titel: "Demand-Übernahme" - beschreibung: "Übernahme vorqualifizierter Demands vom Stakeholder-Management" - von_rolle: "shm" - trigger: "demand_uebergabe_quality_gate_1" - - - id: "QBP-02" - titel: "Demand-Klassifizierung" - beschreibung: "Klassifizierung von Demands nach vordefinierten Dimensionen" - methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml" - output: "demand_kategorie" - - - id: "QBP-03" - titel: "Demand-Analyse" - beschreibung: "Analyse von Demands nach fachlichen und technischen Aspekten und Abhängigkeiten" - aspekte: - - "fachliche Anforderungen" - - "technische Machbarkeit" - - "Abhängigkeiten zu anderen Demands/Projekten" - output: "analyse_ergebnis" - - - id: "QBP-04" - titel: "Demand-Bewertung" - beschreibung: "Bewertung und Clusterung von Demands nach qualitativen Bewertungskategorien" - methode_referenz: "#01.4_methodik/demand-bewertung.yaml" - output: "bewertungsprofil" - - - id: "QBP-05" - titel: "Demand-Priorisierung" - beschreibung: "Priorisierung von Demands nach definiertem Standard und Ableitung von Handlungsempfehlungen" - methode_referenz: "#01.4_methodik/demand-priorisierung.yaml" - output: "priorisierungs_empfehlung" - - - id: "QBP-06" - titel: "Entscheidungsvorlagen erstellen" - beschreibung: "Erstellung von Demand-Entscheidungsvorlagen für Entscheidungsgremien" - output: "demand_entscheidungsvorlage" - empfaenger: ["dsr", "mission_board"] - - bereich_3_gremienarbeit: - name: "Gremienarbeit" - - aufgaben: - - id: "GR-01" - titel: "DSR-Vorbereitung" - beschreibung: "Vorbereitung und Präsentation/Diskussion in der Demand & Stakeholder-Runde (DSR) zur Entscheidung" - gremium: "dsr" - rolle_in_gremium: "vorsitz" - frequenz: "woechentlich" - aktivitaeten: - - "Agenda erstellen" - - "Materialien vorbereiten" - - "Präsentation vorbereiten" - - "Moderation durchführen" - - - id: "GR-02" - titel: "Portfolio-Überblick Mission Board" - beschreibung: "Demand-Portfolio Überblick im Mission Board" - gremium: "mission_board" - frequenz: "zweiwoechentlich" - output: "portfolio_status_update" - - - id: "GR-03" - titel: "Entscheidungsvorlagen präsentieren" - beschreibung: "Vorstellung der Demand-Entscheidungsvorlagen im Mission Board" - gremium: "mission_board" - frequenz: "bei_bedarf" - - - id: "GR-04" - titel: "Entscheidungsfähigkeit sicherstellen" - beschreibung: "Sicherstellung der Entscheidungsfähigkeit durch Bereitstellung der Demand-Entscheidungsvorlage" - kritikalitaet: "hoch" - qualitaetskriterium: "vollständige und präzise Entscheidungsgrundlagen" - - - id: "GR-05" - titel: "Gremienbeschlüsse umsetzen" - beschreibung: "Umsetzung und Nachbearbeitung auf Basis von Gremienbeschlüssen" - aktivitaeten: - - "Statusänderungen im Portfolio" - - "Kommunikation an Stakeholder (via SHM)" - - "Übergabe an PPM (bei Freigabe)" - - "Dokumentation" - -# ======================================== -# 4. SCHNITTSTELLEN UND ZUSAMMENARBEIT -# ======================================== - -schnittstellen: - primaer: - - rolle_id: "shm" - rolle_name: "Stakeholder-Management" - art: "sequenziell" - richtung: "von_shm_zu_dpm" - themen: - - "Übernahme vorqualifizierter Demands" - - "Rückfragen bei Unvollständigkeit" - frequenz: "kontinuierlich" - artefakte: - input: "bedarfs_steckbrief" - output: "rueckfragen_oder_uebernahmebestaetigung" - - - rolle_id: "ppm" - rolle_name: "Projekt-Portfolio-Management" - art: "sequenziell" - richtung: "von_dpm_zu_ppm" - themen: - - "Übergabe freigegebener Demands zur (Vor-)Projektumsetzung" - trigger: "demand_freigabe_durch_gremium" - artefakte: - input: "freigegebener_demand" - output: "projektaufnahme_bestaetigung" - - - rolle_id: "spm" - rolle_name: "Service-Portfolio-Management" - art: "koordinativ" - richtung: "bidirektional" - themen: - - "Abstimmung zu Service-Bezug" - - "Klärung: direkte Umsetzung vs. Projekt" - frequenz: "bei_bedarf_pro_demand" - kontext: "Besonders relevant bei Demands mit Service-Impact" - - sekundaer: - - rolle_id: "it_architektur" - rolle_name: "IT-Architektur" - art: "konsultativ" - themen: - - "Klärung strategischer Grundsatzfragen" - - "Klärung technischer Grundsatzfragen" - frequenz: "bei_bedarf" - trigger: "komplexe_technische_anforderungen" - - - bezeichnung: "Fachexpert:innen" - art: "konsultativ" - themen: - - "Einholung spezifischer Expertise" - frequenz: "bei_bedarf" - beispiele: - - "Datenschutzexpert:innen" - - "Sicherheitsexpert:innen" - - "Fachbereichsexpert:innen" - -# ======================================== -# 5. ENTSCHEIDUNGSBEFUGNISSE -# ======================================== - -entscheidungsbefugnisse: - eigenstaendige_entscheidungen: - beschreibung: "Entscheidungen, die der DPM ohne Gremienabstimmung treffen kann" - - liste: - - id: "ENT-01" - titel: "Demand-Rückweisung" - beschreibung: "Rückweisung unzureichend vorqualifizierter Demands an das Stakeholder-Management zur konkreten Nachbearbeitung" - bedingung: "unzureichende_qualitaet_oder_vollstaendigkeit" - rueckweisung_an: "shm" - - - id: "ENT-02" - titel: "Demand-Klassifizierung" - beschreibung: "Klassifizierung von Demands gemäß der vordefinierten Dimensionen" - bindend: true - kann_ueberstimmt_werden_von: ["dsr", "mission_board"] - methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml" - - - id: "ENT-03" - titel: "Demand-Konsolidierung" - beschreibung: "Konsolidierung ähnlicher oder zusammengehöriger Demands" - rationale: "Vermeidung von Redundanzen und Synergienutzung" - - - id: "ENT-04" - titel: "Expert:innen-Einbindung" - beschreibung: "Einbeziehung von Fachexpert:innen" - kontext: "Bei Bedarf für fundierte Analyse und Bewertung" - - empfehlungen_fuer_gremien: - beschreibung: "DPM bereitet Entscheidungen vor, finales Votum liegt bei Gremien" - - liste: - - id: "EMP-01" - titel: "Bewertungsprofile" - beschreibung: "Bewertungsprofile mit qualitativen Cluster-Fazits als Diskussionsgrundlage für Gremien" - methode_referenz: "#01.4_methodik/demand-bewertung.yaml" - output: "bewertungsprofil" - entscheidung_durch: ["dsr", "mission_board"] - - - id: "EMP-02" - titel: "Priorisierungs-Empfehlung" - beschreibung: "Priorisierung- und Handlungsempfehlung für Demands" - methode_referenz: "#01.4_methodik/demand-priorisierung.yaml" - output: "priorisierungs_empfehlung" - entscheidung_durch: ["dsr", "mission_board"] - - qualitaetssicherung: - beschreibung: "Recht und Pflicht zur Sicherstellung methodischer und prozessualer Qualität" - - liste: - - id: "QS-01" - titel: "Standards durchsetzen" - beschreibung: "Standards für Demand-Dokumentationen und -Bewertung durchzusetzen" - gueltig_fuer: "alle_prozessbeteiligten" - - - id: "QS-02" - titel: "Methodentreue einfordern" - beschreibung: "Methodentreue bei allen Prozessbeteiligten einzufordern" - gueltig_fuer: "alle_prozessbeteiligten" - - - id: "QS-03" - titel: "Transparenz sicherstellen" - beschreibung: "Transparenz durch vollständige Demand-Portfolio-Dokumentation sicherzustellen" - output: "vollstaendiges_demand_portfolio" - - - id: "QS-04" - titel: "Verbesserungen vorschlagen" - beschreibung: "Verbesserungen für Prozesse und Methoden basierend auf Erfahrungswerten vorzuschlagen" - empfaenger: ["al_p", "mission_board"] - frequenz: "kontinuierlich" - -# ======================================== -# 6. WERKZEUGE UND METHODEN -# ======================================== - -werkzeuge_und_methoden: - it_werkzeuge: - - id: "TOOL-01" - name: "Ticketsystem" - zweck: "Zentrale Dokumentation und Statusverfolgung" - verwendung: "alle_demands" - - - id: "TOOL-02" - name: "Demand-Portfolio-Datenbank" - zweck: "Transparente Übersicht aller Demands" - features: - - "Portfolio-Übersicht" - - "Status-Tracking" - - "Reporting-Funktionen" - - standardvorlagen: - - id: "TPL-01" - name: "Demand-Entscheidungsvorlage" - verwendung: "für_gremienpraesentation" - zielgruppe: ["dsr", "mission_board"] - - - id: "TPL-02" - name: "Bedarfs-Steckbrief" - verwendung: "input_von_shm" - status: "wird_geprueft_und_erweitert" - - methoden: - - id: "METH-01" - name: "Demand-Kategorien" - beschreibung: "Standardisierte Methodik zur Qualifizierung und Kategorisierung von Demands" - referenz: "#01.4_methodik/demand-klassifizierung.yaml" - - - id: "METH-02" - name: "Bewertungskriterien" - beschreibung: "Standardisierte Methodik zur Bewertung von Demands" - referenz: "#01.4_methodik/demand-bewertung.yaml" - - - id: "METH-03" - name: "Priorisierungsmethodik" - beschreibung: "Standardisierte Methodik zur Priorisierung von Demands" - referenz: "#01.4_methodik/demand-priorisierung.yaml" - -# ======================================== -# 7. ERFORDERLICHE KOMPETENZEN -# ======================================== - -erforderliche_kompetenzen: - fachlich: - - id: "FK-01" - kompetenz: "IT-Landschaft" - beschreibung: "Fundiertes Verständnis der IT-Landschaft und digitalen Services" - niveau: "fundiert" - - - id: "FK-02" - kompetenz: "Demand-Portfolio-Management" - beschreibung: "Expertise in Demand-Portfolio-Management und Business-Analyse" - niveau: "expertise" - - - id: "FK-03" - kompetenz: "Projektmanagement" - beschreibung: "Kenntnisse in Projektmanagement" - niveau: "kenntnisse" - - - id: "FK-04" - kompetenz: "Verwaltungsprozesse" - beschreibung: "Verwaltungsspezifisches Prozessverständnis" - niveau: "verstaendnis" - kontext: "Öffentliche Verwaltung, kommunale Strukturen" - - methodisch: - - id: "MK-01" - kompetenz: "Analytisches Denken" - beschreibung: "Analytisches und strategisches Denkvermögen" - anwendung: "Demand-Analyse, Portfolio-Trends identifizieren" - - - id: "MK-02" - kompetenz: "Strukturierte Arbeitsweise" - beschreibung: "Strukturierte Arbeitsweise und Komplexitätsmanagement" - anwendung: "Parallele Bearbeitung vieler Demands" - - - id: "MK-03" - kompetenz: "Präsentation und Moderation" - beschreibung: "Präsentations- und Moderationskompetenz" - anwendung: "Gremienarbeit, DSR-Vorsitz" - - - id: "MK-04" - kompetenz: "Konfliktlösung" - beschreibung: "Konfliktlösungsfähigkeit" - anwendung: "Dissens in DSR, konkurrierende Stakeholder-Interessen" - - sozial: - - id: "SK-01" - kompetenz: "Kommunikation" - beschreibung: "Exzellente Kommunikationsfähigkeit über alle Hierarchieebenen" - kritikalitaet: "hoch" - kontext: "Von Fachexpert:innen bis Amtsleitung" - - - id: "SK-02" - kompetenz: "Diplomatisches Geschick" - beschreibung: "Diplomatisches Geschick und Neutralität" - anwendung: "Vermittlung zwischen divergierenden Interessen" - kritikalitaet: "hoch" - - - id: "SK-03" - kompetenz: "Teamfähigkeit" - beschreibung: "Teamfähigkeit und Serviceorientierung" - kontext: "Zusammenarbeit mit SHM, SPM, PPM" - - - id: "SK-04" - kompetenz: "Durchsetzungsvermögen" - beschreibung: "Durchsetzungsvermögen bei gleichzeitiger Kompromissbereitschaft" - anwendung: "Methodentreue einfordern vs. pragmatische Lösungen finden" - -# ======================================== -# 8. ERFOLGSFAKTOREN -# ======================================== - -erfolgsfaktoren: - beschreibung: "Kritische Rahmenbedingungen für erfolgreiche Rollenausübung" - - faktoren: - - id: "EF-01" - titel: "Klare Prozessdefinition" - beschreibung: "Umfängliche Nutzung des Demand-to-Project-Prozesses" - abhaengigkeit: "Alle Beteiligten halten sich an definierten Prozess" - risiko_bei_fehlen: "Umgehung des DPM, inkonsistente Demand-Behandlung" - - - id: "EF-02" - titel: "Management-Unterstützung" - beschreibung: "Rückendeckung durch Amtsleitung und Gremien" - abhaengigkeit: "Amtsleitung stärkt DPM-Rolle aktiv" - risiko_bei_fehlen: "DPM-Entscheidungen werden nicht akzeptiert" - - - id: "EF-03" - titel: "Systemunterstützung" - beschreibung: "Funktionsfähige IT-Werkzeuge und Vorlagen" - abhaengigkeit: "Ticketsystem, Portfolio-Datenbank, Templates verfügbar" - risiko_bei_fehlen: "Manuelle Arbeit, Intransparenz, Ineffizienz" - - - id: "EF-04" - titel: "Akzeptanz" - beschreibung: "Anerkennung als neutrale Koordinationsinstanz" - abhaengigkeit: "Stakeholder vertrauen auf Objektivität des DPM" - risiko_bei_fehlen: "Politisierung von Entscheidungen, Umgehung" - -# ======================================== -# REFERENZEN -# ======================================== - -referenzen: - beschreibung: "Weiterführende Dokumente zur DPM-Rolle" - - dokumente: - - titel: "Demand-Portfolio Governance" - pfad: "#01.2_governance/demand-portfolio-governance.yaml" - relevanz: "Governance-Rahmen für DPM-Arbeit" - - - titel: "RACI-Matrix Demand-Portfolio-Management" - pfad: "#01.2_governance/raci-matrix-demand-portfolio-management.yaml" - relevanz: "Detaillierte Verantwortlichkeiten im Prozess" - - - titel: "Demand & Stakeholder-Runde (DSR) Geschäftsordnung" - pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" +meta: + typ: "rollenbeschreibung" + rolle_id: "dpm" + rolle_name: "Demand-Portfolio-Manager:in" + aliases: ["DPM", "Portfolio-Manager", "Demand-Manager"] + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status: + ueberprueft_durch: "DPM-Teammitglied" + abgestimmt_zwischen: ["human", "DPM-Teammitglied"] + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + status: "abgenommen_in_gesamtkonzept" + hinweis: "anpassen auf Basis der weiteren Workstream-Ergebnisse" + + kontext_tags: + - "demand-management" + - "portfolio-steuerung" + - "qualifizierung" + - "bewertung" + - "priorisierung" + +# ======================================== +# 1. ROLLENZWECK +# ======================================== + +rollenzweck: + kurz: "Zentrale Instanz für Qualifizierung, Bewertung und Portfolio-Steuerung aller Demands im DIGIT" + + ausfuehrlich: | + Der:die Demand-Portfolio-Manager:in transformiert vorqualifizierte Demands in + Demand-Entscheidungsvorlagen und schafft die Grundlage für optimale + Ressourcensteuerung durch die verantwortlichen Gremien. + + verantwortung: + ab_wann: "nach erfolgter Bedarfsklärung durch Stakeholder-Management" + fuer: "alle Demands" + bis: "Aufbereitung für Entscheidungsgremien" + + entscheidungsgremien: + - gremium_id: "dsr" + gremium_name: "Demand & Stakeholder-Runde" + - gremium_id: "mission_board" + gremium_name: "Mission Board" + +# ======================================== +# 2. ORGANISATORISCHE EINORDNUNG +# ======================================== + +organisatorische_einordnung: + zuordnung: + abteilung: "Abteilung Planung" + abteilungskuerzel: "AL-P" + + auspraegungen: + beschreibung: "Spezialisierungen nach Themenfeld oder Kapazität möglich, aber nicht strukturell vorgegeben" + hinweis: | + Die frühere Unterscheidung in DPM Core-IT und DPM Non-Core-IT entfällt. + Alle Demands – unabhängig von ihrer Herkunft (Betrieb oder Innovation) – + durchlaufen denselben Prozess. Spezialisierungen können bei Bedarf + themenfeld- oder kapazitätsbezogen entstehen. + + berichtslinie: + berichtet_an: "Abteilungsleitung Planung" + berichtet_an_rolle_id: "al_p" + + arbeitsmodell: + typ: "Vollzeitfunktion" + vertretung: "gegenseitige Vertretungsregelung zwischen DPM-Mitarbeitenden" + +# ======================================== +# 3. KERNVERANTWORTLICHKEITEN +# ======================================== + +kernverantwortlichkeiten: + bereich_1_portfolio_management: + name: "Demand-Portfolio-Management" + + aufgaben: + - id: "PM-01" + titel: "Portfolio-Aufbau und -Pflege" + beschreibung: "Aufbau und Pflege eines transparenten Demand-Portfolios" + frequenz: "kontinuierlich" + output: "aktuelles_demand_portfolio" + + - id: "PM-02" + titel: "Strategische Portfolio-Analyse" + beschreibung: "Strategische Analyse des Demand-Portfolios und Identifizierung von Trends für das Mission Board" + frequenz: "quartalsweise" + output: "portfolio_trend_analyse" + empfaenger: "mission_board" + + - id: "PM-03" + titel: "Portfolio-Optimierung" + beschreibung: "Kontinuierliche Optimierung der Demand-Portfolio-Zusammensetzung" + frequenz: "kontinuierlich" + + - id: "PM-04" + titel: "Strategiekonformität sicherstellen" + beschreibung: "Bewertung und Priorisierung von Demands gemäß der strategischen Leitplanken des Vision Board" + referenz_zu: "vision_board" + frequenz: "pro_demand" + + bereich_2_demand_qualifizierung: + name: "Demand-Qualifizierung, Bewertung und Priorisierung" + + aufgaben: + - id: "QBP-01" + titel: "Demand-Übernahme" + beschreibung: "Übernahme vorqualifizierter Demands vom Stakeholder-Management" + von_rolle: "shm" + trigger: "demand_uebergabe_quality_gate_1" + + - id: "QBP-02" + titel: "Demand-Klassifizierung" + beschreibung: "Klassifizierung von Demands nach vordefinierten Dimensionen" + methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml" + output: "demand_kategorie" + + - id: "QBP-03" + titel: "Demand-Analyse" + beschreibung: "Analyse von Demands nach fachlichen und technischen Aspekten und Abhängigkeiten" + aspekte: + - "fachliche Anforderungen" + - "technische Machbarkeit" + - "Abhängigkeiten zu anderen Demands/Projekten" + output: "analyse_ergebnis" + + - id: "QBP-04" + titel: "Demand-Bewertung" + beschreibung: "Bewertung und Clusterung von Demands nach qualitativen Bewertungskategorien" + methode_referenz: "#01.4_methodik/demand-bewertung.yaml" + output: "bewertungsprofil" + + - id: "QBP-05" + titel: "Demand-Priorisierung" + beschreibung: "Priorisierung von Demands nach definiertem Standard und Ableitung von Handlungsempfehlungen" + methode_referenz: "#01.4_methodik/demand-priorisierung.yaml" + output: "priorisierungs_empfehlung" + + - id: "QBP-06" + titel: "Entscheidungsvorlagen erstellen" + beschreibung: "Erstellung von Demand-Entscheidungsvorlagen für Entscheidungsgremien" + output: "demand_entscheidungsvorlage" + empfaenger: ["dsr", "mission_board"] + + bereich_3_gremienarbeit: + name: "Gremienarbeit" + + aufgaben: + - id: "GR-01" + titel: "DSR-Vorbereitung" + beschreibung: "Vorbereitung und Präsentation/Diskussion in der Demand & Stakeholder-Runde (DSR) zur Entscheidung" + gremium: "dsr" + rolle_in_gremium: "vorsitz" + frequenz: "woechentlich" + aktivitaeten: + - "Agenda erstellen" + - "Materialien vorbereiten" + - "Präsentation vorbereiten" + - "Moderation durchführen" + + - id: "GR-02" + titel: "Portfolio-Überblick Mission Board" + beschreibung: "Demand-Portfolio Überblick im Mission Board" + gremium: "mission_board" + frequenz: "zweiwoechentlich" + output: "portfolio_status_update" + + - id: "GR-03" + titel: "Entscheidungsvorlagen präsentieren" + beschreibung: "Vorstellung der Demand-Entscheidungsvorlagen im Mission Board" + gremium: "mission_board" + frequenz: "bei_bedarf" + + - id: "GR-04" + titel: "Entscheidungsfähigkeit sicherstellen" + beschreibung: "Sicherstellung der Entscheidungsfähigkeit durch Bereitstellung der Demand-Entscheidungsvorlage" + kritikalitaet: "hoch" + qualitaetskriterium: "vollständige und präzise Entscheidungsgrundlagen" + + - id: "GR-05" + titel: "Gremienbeschlüsse umsetzen" + beschreibung: "Umsetzung und Nachbearbeitung auf Basis von Gremienbeschlüssen" + aktivitaeten: + - "Statusänderungen im Portfolio" + - "Kommunikation an Stakeholder (via SHM)" + - "Übergabe an PPM (bei Freigabe)" + - "Dokumentation" + +# ======================================== +# 4. SCHNITTSTELLEN UND ZUSAMMENARBEIT +# ======================================== + +schnittstellen: + primaer: + - rolle_id: "shm" + rolle_name: "Stakeholder-Management" + art: "sequenziell" + richtung: "von_shm_zu_dpm" + themen: + - "Übernahme vorqualifizierter Demands" + - "Rückfragen bei Unvollständigkeit" + frequenz: "kontinuierlich" + artefakte: + input: "bedarfs_steckbrief" + output: "rueckfragen_oder_uebernahmebestaetigung" + + - rolle_id: "ppm" + rolle_name: "Projekt-Portfolio-Management" + art: "sequenziell" + richtung: "von_dpm_zu_ppm" + themen: + - "Übergabe freigegebener Demands zur (Vor-)Projektumsetzung" + trigger: "demand_freigabe_durch_gremium" + artefakte: + input: "freigegebener_demand" + output: "projektaufnahme_bestaetigung" + + - rolle_id: "spm" + rolle_name: "Service-Portfolio-Management" + art: "koordinativ" + richtung: "bidirektional" + themen: + - "Abstimmung zu Service-Bezug" + - "Klärung: direkte Umsetzung vs. Projekt" + frequenz: "bei_bedarf_pro_demand" + kontext: "Besonders relevant bei Demands mit Service-Impact" + + sekundaer: + - rolle_id: "it_architektur" + rolle_name: "IT-Architektur" + art: "konsultativ" + themen: + - "Klärung strategischer Grundsatzfragen" + - "Klärung technischer Grundsatzfragen" + frequenz: "bei_bedarf" + trigger: "komplexe_technische_anforderungen" + + - bezeichnung: "Fachexpert:innen" + art: "konsultativ" + themen: + - "Einholung spezifischer Expertise" + frequenz: "bei_bedarf" + beispiele: + - "Datenschutzexpert:innen" + - "Sicherheitsexpert:innen" + - "Fachbereichsexpert:innen" + +# ======================================== +# 5. ENTSCHEIDUNGSBEFUGNISSE +# ======================================== + +entscheidungsbefugnisse: + eigenstaendige_entscheidungen: + beschreibung: "Entscheidungen, die der DPM ohne Gremienabstimmung treffen kann" + + liste: + - id: "ENT-01" + titel: "Demand-Rückweisung" + beschreibung: "Rückweisung unzureichend vorqualifizierter Demands an das Stakeholder-Management zur konkreten Nachbearbeitung" + bedingung: "unzureichende_qualitaet_oder_vollstaendigkeit" + rueckweisung_an: "shm" + + - id: "ENT-02" + titel: "Demand-Klassifizierung" + beschreibung: "Klassifizierung von Demands gemäß der vordefinierten Dimensionen" + bindend: true + kann_ueberstimmt_werden_von: ["dsr", "mission_board"] + methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml" + + - id: "ENT-03" + titel: "Demand-Konsolidierung" + beschreibung: "Konsolidierung ähnlicher oder zusammengehöriger Demands" + rationale: "Vermeidung von Redundanzen und Synergienutzung" + + - id: "ENT-04" + titel: "Expert:innen-Einbindung" + beschreibung: "Einbeziehung von Fachexpert:innen" + kontext: "Bei Bedarf für fundierte Analyse und Bewertung" + + empfehlungen_fuer_gremien: + beschreibung: "DPM bereitet Entscheidungen vor, finales Votum liegt bei Gremien" + + liste: + - id: "EMP-01" + titel: "Bewertungsprofile" + beschreibung: "Bewertungsprofile mit qualitativen Cluster-Fazits als Diskussionsgrundlage für Gremien" + methode_referenz: "#01.4_methodik/demand-bewertung.yaml" + output: "bewertungsprofil" + entscheidung_durch: ["dsr", "mission_board"] + + - id: "EMP-02" + titel: "Priorisierungs-Empfehlung" + beschreibung: "Priorisierung- und Handlungsempfehlung für Demands" + methode_referenz: "#01.4_methodik/demand-priorisierung.yaml" + output: "priorisierungs_empfehlung" + entscheidung_durch: ["dsr", "mission_board"] + + qualitaetssicherung: + beschreibung: "Recht und Pflicht zur Sicherstellung methodischer und prozessualer Qualität" + + liste: + - id: "QS-01" + titel: "Standards durchsetzen" + beschreibung: "Standards für Demand-Dokumentationen und -Bewertung durchzusetzen" + gueltig_fuer: "alle_prozessbeteiligten" + + - id: "QS-02" + titel: "Methodentreue einfordern" + beschreibung: "Methodentreue bei allen Prozessbeteiligten einzufordern" + gueltig_fuer: "alle_prozessbeteiligten" + + - id: "QS-03" + titel: "Transparenz sicherstellen" + beschreibung: "Transparenz durch vollständige Demand-Portfolio-Dokumentation sicherzustellen" + output: "vollstaendiges_demand_portfolio" + + - id: "QS-04" + titel: "Verbesserungen vorschlagen" + beschreibung: "Verbesserungen für Prozesse und Methoden basierend auf Erfahrungswerten vorzuschlagen" + empfaenger: ["al_p", "mission_board"] + frequenz: "kontinuierlich" + +# ======================================== +# 6. WERKZEUGE UND METHODEN +# ======================================== + +werkzeuge_und_methoden: + it_werkzeuge: + - id: "TOOL-01" + name: "Ticketsystem" + zweck: "Zentrale Dokumentation und Statusverfolgung" + verwendung: "alle_demands" + + - id: "TOOL-02" + name: "Demand-Portfolio-Datenbank" + zweck: "Transparente Übersicht aller Demands" + features: + - "Portfolio-Übersicht" + - "Status-Tracking" + - "Reporting-Funktionen" + + standardvorlagen: + - id: "TPL-01" + name: "Demand-Entscheidungsvorlage" + verwendung: "für_gremienpraesentation" + zielgruppe: ["dsr", "mission_board"] + + - id: "TPL-02" + name: "Bedarfs-Steckbrief" + verwendung: "input_von_shm" + status: "wird_geprueft_und_erweitert" + + methoden: + - id: "METH-01" + name: "Demand-Kategorien" + beschreibung: "Standardisierte Methodik zur Qualifizierung und Kategorisierung von Demands" + referenz: "#01.4_methodik/demand-klassifizierung.yaml" + + - id: "METH-02" + name: "Bewertungskriterien" + beschreibung: "Standardisierte Methodik zur Bewertung von Demands" + referenz: "#01.4_methodik/demand-bewertung.yaml" + + - id: "METH-03" + name: "Priorisierungsmethodik" + beschreibung: "Standardisierte Methodik zur Priorisierung von Demands" + referenz: "#01.4_methodik/demand-priorisierung.yaml" + +# ======================================== +# 7. ERFORDERLICHE KOMPETENZEN +# ======================================== + +erforderliche_kompetenzen: + fachlich: + - id: "FK-01" + kompetenz: "IT-Landschaft" + beschreibung: "Fundiertes Verständnis der IT-Landschaft und digitalen Services" + niveau: "fundiert" + + - id: "FK-02" + kompetenz: "Demand-Portfolio-Management" + beschreibung: "Expertise in Demand-Portfolio-Management und Business-Analyse" + niveau: "expertise" + + - id: "FK-03" + kompetenz: "Projektmanagement" + beschreibung: "Kenntnisse in Projektmanagement" + niveau: "kenntnisse" + + - id: "FK-04" + kompetenz: "Verwaltungsprozesse" + beschreibung: "Verwaltungsspezifisches Prozessverständnis" + niveau: "verstaendnis" + kontext: "Öffentliche Verwaltung, kommunale Strukturen" + + methodisch: + - id: "MK-01" + kompetenz: "Analytisches Denken" + beschreibung: "Analytisches und strategisches Denkvermögen" + anwendung: "Demand-Analyse, Portfolio-Trends identifizieren" + + - id: "MK-02" + kompetenz: "Strukturierte Arbeitsweise" + beschreibung: "Strukturierte Arbeitsweise und Komplexitätsmanagement" + anwendung: "Parallele Bearbeitung vieler Demands" + + - id: "MK-03" + kompetenz: "Präsentation und Moderation" + beschreibung: "Präsentations- und Moderationskompetenz" + anwendung: "Gremienarbeit, DSR-Vorsitz" + + - id: "MK-04" + kompetenz: "Konfliktlösung" + beschreibung: "Konfliktlösungsfähigkeit" + anwendung: "Dissens in DSR, konkurrierende Stakeholder-Interessen" + + sozial: + - id: "SK-01" + kompetenz: "Kommunikation" + beschreibung: "Exzellente Kommunikationsfähigkeit über alle Hierarchieebenen" + kritikalitaet: "hoch" + kontext: "Von Fachexpert:innen bis Amtsleitung" + + - id: "SK-02" + kompetenz: "Diplomatisches Geschick" + beschreibung: "Diplomatisches Geschick und Neutralität" + anwendung: "Vermittlung zwischen divergierenden Interessen" + kritikalitaet: "hoch" + + - id: "SK-03" + kompetenz: "Teamfähigkeit" + beschreibung: "Teamfähigkeit und Serviceorientierung" + kontext: "Zusammenarbeit mit SHM, SPM, PPM" + + - id: "SK-04" + kompetenz: "Durchsetzungsvermögen" + beschreibung: "Durchsetzungsvermögen bei gleichzeitiger Kompromissbereitschaft" + anwendung: "Methodentreue einfordern vs. pragmatische Lösungen finden" + +# ======================================== +# 8. ERFOLGSFAKTOREN +# ======================================== + +erfolgsfaktoren: + beschreibung: "Kritische Rahmenbedingungen für erfolgreiche Rollenausübung" + + faktoren: + - id: "EF-01" + titel: "Klare Prozessdefinition" + beschreibung: "Umfängliche Nutzung des Demand-to-Project-Prozesses" + abhaengigkeit: "Alle Beteiligten halten sich an definierten Prozess" + risiko_bei_fehlen: "Umgehung des DPM, inkonsistente Demand-Behandlung" + + - id: "EF-02" + titel: "Management-Unterstützung" + beschreibung: "Rückendeckung durch Amtsleitung und Gremien" + abhaengigkeit: "Amtsleitung stärkt DPM-Rolle aktiv" + risiko_bei_fehlen: "DPM-Entscheidungen werden nicht akzeptiert" + + - id: "EF-03" + titel: "Systemunterstützung" + beschreibung: "Funktionsfähige IT-Werkzeuge und Vorlagen" + abhaengigkeit: "Ticketsystem, Portfolio-Datenbank, Templates verfügbar" + risiko_bei_fehlen: "Manuelle Arbeit, Intransparenz, Ineffizienz" + + - id: "EF-04" + titel: "Akzeptanz" + beschreibung: "Anerkennung als neutrale Koordinationsinstanz" + abhaengigkeit: "Stakeholder vertrauen auf Objektivität des DPM" + risiko_bei_fehlen: "Politisierung von Entscheidungen, Umgehung" + +# ======================================== +# REFERENZEN +# ======================================== + +referenzen: + beschreibung: "Weiterführende Dokumente zur DPM-Rolle" + + dokumente: + - titel: "Demand-Portfolio Governance" + pfad: "#01.2_governance/demand-portfolio-governance.yaml" + relevanz: "Governance-Rahmen für DPM-Arbeit" + + - titel: "RACI-Matrix Demand-Portfolio-Management" + pfad: "#01.2_governance/raci-matrix-demand-portfolio-management.yaml" + relevanz: "Detaillierte Verantwortlichkeiten im Prozess" + + - titel: "Demand & Stakeholder-Runde (DSR) Geschäftsordnung" + pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml" relevanz: "Arbeitsweise des wichtigsten Gremiums für DPM" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml index efaf500..6808d7e 100644 --- a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml +++ b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml @@ -1,123 +1,123 @@ -phase: - id: 1 - titel: "Initiierung und Erfassung" - ziel: "Identifikation von Bedarfen durch Stakeholder und Überführung in qualifizierte Bedarfssteckbriefe durch das Stakeholder-Management, inklusive Abgrenzung zum bestehenden Service-Katalog." - verantwortlich_rolle: "Stakeholder-Management (SHM)" - - schema_referenzen: - bedarfs_steckbrief: - pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml" - version: "1.1" - bedarfsbewertung: - pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" - beschreibung: "Routing-Logik und Entscheidungsbaum" - - schritte: - - schritt_id: "1.1" - titel: "Bedarfsidentifikation" - akteur: "Stakeholder (SH)" - beschreibung: "Ein Stakeholder erkennt einen fachlichen Bedarf, der nicht durch die bestehende Arbeitsumgebung abgedeckt ist." - input: "Fachlicher Auslöser (z.B. Gesetzesänderung, Prozessoptimierung)" - output: "Initialer Bedarfsgedanke" - raci_referenz: "1.1" - citation: [506] - - - schritt_id: "1.2" - titel: "Bedarfsmeldung" - akteur: "Stakeholder (SH)" - beschreibung: "Der Stakeholder meldet den Bedarf über definierte Kanäle (z.B. Service Desk Ticket, direkte Ansprache) an DIGIT." - input: "Initialer Bedarfsgedanke" - output: "Unqualifizierte Bedarfsmeldung (Ticket)" - system: "Ticketsystem" - raci_referenz: "1.2" - citation: [506] - - - schritt_id: "1.3" - titel: "Initiale Qualifizierung (Triage)" - akteur: "Stakeholder-Management (SHM)" - beschreibung: "Erste Sichtung der Meldung. Prüfung auf Vollständigkeit der Basisinformationen und Zuständigkeit." - input: "Unqualifizierte Bedarfsmeldung" - output: "Qualifizierungsstatus" - raci_referenz: "1.3" - citation: [506] - - - schritt_id: "1.4" - titel: "Service-Katalog-Prüfung" - akteur: "Stakeholder-Management (SHM)" - support_akteur: "Service-Portfolio-Management (SPM)" - beschreibung: "Abgleich des Bedarfs mit dem existierenden Service-Katalog. Entscheidung, ob es sich um einen Standard-Request handelt." - entscheidungspunkt: - frage: "Ist der Bedarf durch bestehenden Service-Katalog abdeckbar?" - option_ja: "Routing in Request Fulfilment Prozess (Out of Demand Scope)" - option_nein: "Weiter in Demand-Prozess (Schritt 1.5)" - routing_pfad_bei_ja: - id: "ROUTE-REQ" - name: "Request Fulfilment" - ziel: "Service Desk" - steckbrief_erforderlich: false - hinweis: "Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung" - raci_referenz: "1.4" - citation: [506] - - - schritt_id: "1.5" - titel: "Bedarfsklärungsgespräch" - akteur: "Stakeholder-Management (SHM)" - partner_akteur: "Stakeholder (SH)" - beschreibung: "Strukturiertes Interview zur Erhebung der funktionalen und nicht-funktionalen Anforderungen, des Nutzens und der Rahmenbedingungen." - input: "Qualifizierte Meldung" - output: "Protokollierte Anforderungen" - artefakte: "Bedarfs-Steckbrief (Draft)" - raci_referenz: "1.5" - citation: [506] - - - schritt_id: "1.6" - titel: "User Story Erstellung" - akteur: "Stakeholder-Management (SHM)" - beschreibung: "Übersetzung der Anforderungen in strukturierte User Stories (Wer möchte was warum?) zur Sicherstellung der fachlichen Perspektive." - input: "Protokollierte Anforderungen" - output: "Fertiger Bedarfs-Steckbrief" - artefakte: - - "Bedarfs-Steckbrief (Final)" - - "Leitfaden User Stories" - raci_referenz: "1.6" - citation: [506] - - - schritt_id: "1.7" - titel: "Bedarfs-Routing (Quality Gate 1)" - akteur: "Stakeholder-Management (SHM)" - beschreibung: | - Routing-Entscheidung basierend auf Bedarfsbewertung. - Je nach Ergebnis erfolgt Übergabe an unterschiedliche Empfänger. - input: "Bedarfs-Steckbrief (Final oder reduziert je nach Routing)" - system: "Ticketsystem / Demand-Portfolio-Datenbank" - raci_referenz: "1.7" - citation: [506] - - routing_optionen: - - routing_id: "ROUTE-DPM" - name: "Demand Portfolio Management" - empfaenger: "Demand-Portfolio-Management (DPM)" - bedingung: "Neuer Service oder grundlegende Neugestaltung erforderlich" - output: "Demand (Status: an_dpm_uebergeben)" - steckbrief_vollstaendig: true - trigger_next_phase: "Phase 2: Qualifizierung und Priorisierung" - quality_gate: true - - - routing_id: "ROUTE-SPM" - name: "Service Portfolio Management (Change)" - empfaenger: "Service-Portfolio-Management (SPM)" - bedingung: "Änderung an bestehendem Service" - output: "Change Request (Status: an_spm_uebergeben)" - steckbrief_vollstaendig: false - hinweis: "Reduzierter Steckbrief ausreichend" - - - routing_id: "ROUTE-SO" - name: "Service-Owner-Klärung" - empfaenger: "Service Owner (über Service-Portfolio / SPM)" - bedingung: "Routing unklar – bilaterale Klärung mit Service Owner" - output: "Klärungsfall (Status: in_so_klaerung)" - steckbrief_vollstaendig: false - hinweis: "Wenn Service Owner identifizierbar: direkte bilaterale Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR." - referenz: "GOV-SHM-029" - +phase: + id: 1 + titel: "Initiierung und Erfassung" + ziel: "Identifikation von Bedarfen durch Stakeholder und Überführung in qualifizierte Bedarfssteckbriefe durch das Stakeholder-Management, inklusive Abgrenzung zum bestehenden Service-Katalog." + verantwortlich_rolle: "Stakeholder-Management (SHM)" + + schema_referenzen: + bedarfs_steckbrief: + pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml" + version: "1.1" + bedarfsbewertung: + pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" + beschreibung: "Routing-Logik und Entscheidungsbaum" + + schritte: + - schritt_id: "1.1" + titel: "Bedarfsidentifikation" + akteur: "Stakeholder (SH)" + beschreibung: "Ein Stakeholder erkennt einen fachlichen Bedarf, der nicht durch die bestehende Arbeitsumgebung abgedeckt ist." + input: "Fachlicher Auslöser (z.B. Gesetzesänderung, Prozessoptimierung)" + output: "Initialer Bedarfsgedanke" + raci_referenz: "1.1" + citation: [506] + + - schritt_id: "1.2" + titel: "Bedarfsmeldung" + akteur: "Stakeholder (SH)" + beschreibung: "Der Stakeholder meldet den Bedarf über definierte Kanäle (z.B. Service Desk Ticket, direkte Ansprache) an DIGIT." + input: "Initialer Bedarfsgedanke" + output: "Unqualifizierte Bedarfsmeldung (Ticket)" + system: "Ticketsystem" + raci_referenz: "1.2" + citation: [506] + + - schritt_id: "1.3" + titel: "Initiale Qualifizierung (Triage)" + akteur: "Stakeholder-Management (SHM)" + beschreibung: "Erste Sichtung der Meldung. Prüfung auf Vollständigkeit der Basisinformationen und Zuständigkeit." + input: "Unqualifizierte Bedarfsmeldung" + output: "Qualifizierungsstatus" + raci_referenz: "1.3" + citation: [506] + + - schritt_id: "1.4" + titel: "Service-Katalog-Prüfung" + akteur: "Stakeholder-Management (SHM)" + support_akteur: "Service-Portfolio-Management (SPM)" + beschreibung: "Abgleich des Bedarfs mit dem existierenden Service-Katalog. Entscheidung, ob es sich um einen Standard-Request handelt." + entscheidungspunkt: + frage: "Ist der Bedarf durch bestehenden Service-Katalog abdeckbar?" + option_ja: "Routing in Request Fulfilment Prozess (Out of Demand Scope)" + option_nein: "Weiter in Demand-Prozess (Schritt 1.5)" + routing_pfad_bei_ja: + id: "ROUTE-REQ" + name: "Request Fulfilment" + ziel: "Service Desk" + steckbrief_erforderlich: false + hinweis: "Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung" + raci_referenz: "1.4" + citation: [506] + + - schritt_id: "1.5" + titel: "Bedarfsklärungsgespräch" + akteur: "Stakeholder-Management (SHM)" + partner_akteur: "Stakeholder (SH)" + beschreibung: "Strukturiertes Interview zur Erhebung der funktionalen und nicht-funktionalen Anforderungen, des Nutzens und der Rahmenbedingungen." + input: "Qualifizierte Meldung" + output: "Protokollierte Anforderungen" + artefakte: "Bedarfs-Steckbrief (Draft)" + raci_referenz: "1.5" + citation: [506] + + - schritt_id: "1.6" + titel: "User Story Erstellung" + akteur: "Stakeholder-Management (SHM)" + beschreibung: "Übersetzung der Anforderungen in strukturierte User Stories (Wer möchte was warum?) zur Sicherstellung der fachlichen Perspektive." + input: "Protokollierte Anforderungen" + output: "Fertiger Bedarfs-Steckbrief" + artefakte: + - "Bedarfs-Steckbrief (Final)" + - "Leitfaden User Stories" + raci_referenz: "1.6" + citation: [506] + + - schritt_id: "1.7" + titel: "Bedarfs-Routing (Quality Gate 1)" + akteur: "Stakeholder-Management (SHM)" + beschreibung: | + Routing-Entscheidung basierend auf Bedarfsbewertung. + Je nach Ergebnis erfolgt Übergabe an unterschiedliche Empfänger. + input: "Bedarfs-Steckbrief (Final oder reduziert je nach Routing)" + system: "Ticketsystem / Demand-Portfolio-Datenbank" + raci_referenz: "1.7" + citation: [506] + + routing_optionen: + - routing_id: "ROUTE-DPM" + name: "Demand Portfolio Management" + empfaenger: "Demand-Portfolio-Management (DPM)" + bedingung: "Neuer Service oder grundlegende Neugestaltung erforderlich" + output: "Demand (Status: an_dpm_uebergeben)" + steckbrief_vollstaendig: true + trigger_next_phase: "Phase 2: Qualifizierung und Priorisierung" + quality_gate: true + + - routing_id: "ROUTE-SPM" + name: "Service Portfolio Management (Change)" + empfaenger: "Service-Portfolio-Management (SPM)" + bedingung: "Änderung an bestehendem Service" + output: "Change Request (Status: an_spm_uebergeben)" + steckbrief_vollstaendig: false + hinweis: "Reduzierter Steckbrief ausreichend" + + - routing_id: "ROUTE-SO" + name: "Service-Owner-Klärung" + empfaenger: "Service Owner (über Service-Portfolio / SPM)" + bedingung: "Routing unklar – bilaterale Klärung mit Service Owner" + output: "Klärungsfall (Status: in_so_klaerung)" + steckbrief_vollstaendig: false + hinweis: "Wenn Service Owner identifizierbar: direkte bilaterale Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR." + referenz: "GOV-SHM-029" + validierungsprofile_referenz: "shm_schema_bedarfssteckbrief.yaml#validierungsprofile" \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-2.yaml b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-2.yaml index b738735..00fd83f 100644 --- a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-2.yaml +++ b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-2.yaml @@ -1,71 +1,71 @@ -phase: - id: 2 - titel: "Qualifizierung und Priorisierung" - ziel: "Systematische Analyse, Bewertung und Priorisierung des Demands zur Herstellung der Entscheidungsreife für das zuständige Gremium." - verantwortlich_rolle: "Demand-Portfolio-Management (DPM)" - - schritte: - - schritt_id: "2.1" - titel: "Vollständigkeitsprüfung (Quality Gate 2)" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Prüfung des übergebenen Bedarfs-Steckbriefs auf formale Vollständigkeit und inhaltliche Plausibilität." - input: "Bedarfs-Steckbrief (Final)" - entscheidungspunkt: - frage: "Ist der Steckbrief ausreichend qualifiziert?" - option_ja: "Weiter zur Klassifizierung (Schritt 2.2)" - option_nein: "Rückweisung an Stakeholder-Management zur Nachbesserung" - raci_referenz: "2.1" - citation: [376, 196] - - - schritt_id: "2.2" - titel: "Demand-Klassifizierung" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Einordnung des Demands in die vier Steuerungsdimensionen: Treiber, Tragweite, Systemebene, Komplexität." - input: "Bedarfs-Steckbrief" - output: "Klassifizierter Demand mit initialem Routing-Vorschlag" - artefakte: "Klassifizierungsmatrix" - raci_referenz: "2.2" - citation: [376, 1048] - - - schritt_id: "2.3" - titel: "Inhaltliche Analyse & Abhängigkeitsprüfung" - akteur: "Demand-Portfolio-Management (DPM)" - support_akteure: - - "IT-Architektur-Board (bei Architekturrelevanz)" - - "Projekt-Portfolio-Management (PPM) (für Portfolio-Check)" - - "Service-Portfolio-Management (SPM) (für Service-Impact)" - beschreibung: "Tiefenprüfung der Anforderungen, Identifikation technischer/fachlicher Abhängigkeiten zu anderen Demands/Projekten und Ersteinschätzung des Lösungsraums." - input: "Klassifizierter Demand" - output: "Analyseergebnisse & identifizierte Abhängigkeiten" - raci_referenz: "2.3" - citation: [376, 113] - - - schritt_id: "2.4" - titel: "Demand-Bewertung" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Qualitative Bewertung anhand der drei Cluster: Nutzen & Wirkung, Druck & Notwendigkeit, Machbarkeit & Aufwand." - input: "Analyseergebnisse" - output: "Bewertungs-Scores je Cluster" - raci_referenz: "2.4" - citation: [376, 1309] - - - schritt_id: "2.5" - titel: "Priorisierung" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Überführung der Bewertungsergebnisse in die Priorisierungs-Matrix (Wichtigkeit vs. Dringlichkeit) zur Ermittlung der Handlungsempfehlung." - input: "Bewertungs-Scores" - output: "Priorisierter Demand (Quadrant + Machbarkeits-Ampel)" - artefakte: "Priorisierungs-Matrix" - raci_referenz: "2.5" - citation: [376, 1593] - - - schritt_id: "2.6" - titel: "Erstellung Entscheidungsvorlage" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Zusammenführung aller Ergebnisse in eine standardisierte Vorlage für das Entscheidungsgremium inklusive finalem Routing-Vorschlag." - input: "Priorisierter Demand" - output: "Entscheidungsreife Vorlage" - artefakte: "Demand-Entscheidungsvorlage" - trigger_next_phase: "Phase 3: Entscheidung und Freigabe" - raci_referenz: "2.6" +phase: + id: 2 + titel: "Qualifizierung und Priorisierung" + ziel: "Systematische Analyse, Bewertung und Priorisierung des Demands zur Herstellung der Entscheidungsreife für das zuständige Gremium." + verantwortlich_rolle: "Demand-Portfolio-Management (DPM)" + + schritte: + - schritt_id: "2.1" + titel: "Vollständigkeitsprüfung (Quality Gate 2)" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Prüfung des übergebenen Bedarfs-Steckbriefs auf formale Vollständigkeit und inhaltliche Plausibilität." + input: "Bedarfs-Steckbrief (Final)" + entscheidungspunkt: + frage: "Ist der Steckbrief ausreichend qualifiziert?" + option_ja: "Weiter zur Klassifizierung (Schritt 2.2)" + option_nein: "Rückweisung an Stakeholder-Management zur Nachbesserung" + raci_referenz: "2.1" + citation: [376, 196] + + - schritt_id: "2.2" + titel: "Demand-Klassifizierung" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Einordnung des Demands in die vier Steuerungsdimensionen: Treiber, Tragweite, Systemebene, Komplexität." + input: "Bedarfs-Steckbrief" + output: "Klassifizierter Demand mit initialem Routing-Vorschlag" + artefakte: "Klassifizierungsmatrix" + raci_referenz: "2.2" + citation: [376, 1048] + + - schritt_id: "2.3" + titel: "Inhaltliche Analyse & Abhängigkeitsprüfung" + akteur: "Demand-Portfolio-Management (DPM)" + support_akteure: + - "IT-Architektur-Board (bei Architekturrelevanz)" + - "Projekt-Portfolio-Management (PPM) (für Portfolio-Check)" + - "Service-Portfolio-Management (SPM) (für Service-Impact)" + beschreibung: "Tiefenprüfung der Anforderungen, Identifikation technischer/fachlicher Abhängigkeiten zu anderen Demands/Projekten und Ersteinschätzung des Lösungsraums." + input: "Klassifizierter Demand" + output: "Analyseergebnisse & identifizierte Abhängigkeiten" + raci_referenz: "2.3" + citation: [376, 113] + + - schritt_id: "2.4" + titel: "Demand-Bewertung" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Qualitative Bewertung anhand der drei Cluster: Nutzen & Wirkung, Druck & Notwendigkeit, Machbarkeit & Aufwand." + input: "Analyseergebnisse" + output: "Bewertungs-Scores je Cluster" + raci_referenz: "2.4" + citation: [376, 1309] + + - schritt_id: "2.5" + titel: "Priorisierung" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Überführung der Bewertungsergebnisse in die Priorisierungs-Matrix (Wichtigkeit vs. Dringlichkeit) zur Ermittlung der Handlungsempfehlung." + input: "Bewertungs-Scores" + output: "Priorisierter Demand (Quadrant + Machbarkeits-Ampel)" + artefakte: "Priorisierungs-Matrix" + raci_referenz: "2.5" + citation: [376, 1593] + + - schritt_id: "2.6" + titel: "Erstellung Entscheidungsvorlage" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Zusammenführung aller Ergebnisse in eine standardisierte Vorlage für das Entscheidungsgremium inklusive finalem Routing-Vorschlag." + input: "Priorisierter Demand" + output: "Entscheidungsreife Vorlage" + artefakte: "Demand-Entscheidungsvorlage" + trigger_next_phase: "Phase 3: Entscheidung und Freigabe" + raci_referenz: "2.6" citation: [376, 1770] \ No newline at end of file diff --git a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-3.yaml b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-3.yaml index 8f98acd..c74d7fe 100644 --- a/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-3.yaml +++ b/#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-3.yaml @@ -1,74 +1,74 @@ -phase: - id: 3 - titel: "Entscheidung und Freigabe" - ziel: "Herbeiführung einer verbindlichen Entscheidung (Freigabe, Ablehnung, Delegation) durch das zuständige Gremium inklusive Definition notwendiger Rahmenbedingungen." - verantwortlich_rolle: "Demand-Portfolio-Management (DPM)" - - schritte: - - schritt_id: "3.1" - titel: "DSR-Vorbereitung (Async)" - bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Finale Qualitätssicherung der Vorlage und Versand der Unterlagen an DSR-Mitglieder (min. 24h vor Sitzung)." - input: "Entscheidungsreife Vorlage" - output: "Versendete Sitzungsunterlagen" - raci_referenz: "3.1" - citation: [378, 461] - - - schritt_id: "3.2" - titel: "DSR-Sitzung (Sync)" - bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption" - akteur: "Demand & Stakeholder Runde (DSR)" - moderator: "Demand-Portfolio-Management (DPM)" - beschreibung: "Präsentation des Demands und Entscheidungsfindung im Konsent-Verfahren." - entscheidungspunkt: - frage: "DSR-Entscheidungsergebnis?" - option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)" - option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)" - option_delegation: "Weiter zu Schritt 3.3 (MB-Vorbereitung)" - option_vertagung: "Zurück zu Phase 2 (Nachbesserung erforderlich)" - raci_referenz: "3.2, 3.3, 3.4" - citation: [378, 470] - - - schritt_id: "3.3" - titel: "MB-Vorbereitung (Async)" - bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR (aus 3.2)" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Aufbereitung der Entscheidungsvorlage für die strategische Perspektive des Mission Boards." - input: "Vorlage (ggf. mit Delegationsvotum der DSR)" - output: "MB-Sitzungsunterlagen" - raci_referenz: "3.5" - citation: [378] - - - schritt_id: "3.4" - titel: "MB-Sitzung (Sync)" - bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR" - akteur: "Mission Board (MB)" - support_akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Strategische Diskussion und finale Entscheidung über MB-relevante Demands." - entscheidungspunkt: - frage: "MB-Entscheidungsergebnis?" - option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)" - option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)" - option_vertagung: "Zurück zu Phase 2 (Nachbesserung) oder 3.3 (Wiedervorlage)" - raci_referenz: "3.6, 3.7" - citation: [378, 381] - - - schritt_id: "3.5" - titel: "Entscheidungs-Finalisierung" - bedingung: "Nur bei Freigabe (durch DSR oder MB)" - akteur: "Entscheidungsgremium (DSR/MB)" - beschreibung: "Festlegung verbindlicher Auflagen für die Umsetzung und Benennung eines fachlichen Sponsors." - output: "Vollständiger Gremienbeschluss mit Auflagen & Sponsor" - raci_referenz: "3.8, 3.9, 3.10" - citation: [381, 482] - - - schritt_id: "3.6" - titel: "Kommunikation & Routing (Quality Gate 3)" - akteur: "Demand-Portfolio-Management (DPM)" - beschreibung: "Formale Dokumentation des Beschlusses, Information an Stakeholder (via SHM) und Routing in die nächste Phase." - input: "Gremienbeschluss" - output: "Aktualisierter Demand-Status" - trigger_next_phase: "Phase 4: Projektinitiierung (bei Freigabe) ODER Archivierung (bei Ablehnung)" - raci_referenz: "3.11" +phase: + id: 3 + titel: "Entscheidung und Freigabe" + ziel: "Herbeiführung einer verbindlichen Entscheidung (Freigabe, Ablehnung, Delegation) durch das zuständige Gremium inklusive Definition notwendiger Rahmenbedingungen." + verantwortlich_rolle: "Demand-Portfolio-Management (DPM)" + + schritte: + - schritt_id: "3.1" + titel: "DSR-Vorbereitung (Async)" + bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Finale Qualitätssicherung der Vorlage und Versand der Unterlagen an DSR-Mitglieder (min. 24h vor Sitzung)." + input: "Entscheidungsreife Vorlage" + output: "Versendete Sitzungsunterlagen" + raci_referenz: "3.1" + citation: [378, 461] + + - schritt_id: "3.2" + titel: "DSR-Sitzung (Sync)" + bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption" + akteur: "Demand & Stakeholder Runde (DSR)" + moderator: "Demand-Portfolio-Management (DPM)" + beschreibung: "Präsentation des Demands und Entscheidungsfindung im Konsent-Verfahren." + entscheidungspunkt: + frage: "DSR-Entscheidungsergebnis?" + option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)" + option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)" + option_delegation: "Weiter zu Schritt 3.3 (MB-Vorbereitung)" + option_vertagung: "Zurück zu Phase 2 (Nachbesserung erforderlich)" + raci_referenz: "3.2, 3.3, 3.4" + citation: [378, 470] + + - schritt_id: "3.3" + titel: "MB-Vorbereitung (Async)" + bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR (aus 3.2)" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Aufbereitung der Entscheidungsvorlage für die strategische Perspektive des Mission Boards." + input: "Vorlage (ggf. mit Delegationsvotum der DSR)" + output: "MB-Sitzungsunterlagen" + raci_referenz: "3.5" + citation: [378] + + - schritt_id: "3.4" + titel: "MB-Sitzung (Sync)" + bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR" + akteur: "Mission Board (MB)" + support_akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Strategische Diskussion und finale Entscheidung über MB-relevante Demands." + entscheidungspunkt: + frage: "MB-Entscheidungsergebnis?" + option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)" + option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)" + option_vertagung: "Zurück zu Phase 2 (Nachbesserung) oder 3.3 (Wiedervorlage)" + raci_referenz: "3.6, 3.7" + citation: [378, 381] + + - schritt_id: "3.5" + titel: "Entscheidungs-Finalisierung" + bedingung: "Nur bei Freigabe (durch DSR oder MB)" + akteur: "Entscheidungsgremium (DSR/MB)" + beschreibung: "Festlegung verbindlicher Auflagen für die Umsetzung und Benennung eines fachlichen Sponsors." + output: "Vollständiger Gremienbeschluss mit Auflagen & Sponsor" + raci_referenz: "3.8, 3.9, 3.10" + citation: [381, 482] + + - schritt_id: "3.6" + titel: "Kommunikation & Routing (Quality Gate 3)" + akteur: "Demand-Portfolio-Management (DPM)" + beschreibung: "Formale Dokumentation des Beschlusses, Information an Stakeholder (via SHM) und Routing in die nächste Phase." + input: "Gremienbeschluss" + output: "Aktualisierter Demand-Status" + trigger_next_phase: "Phase 4: Projektinitiierung (bei Freigabe) ODER Archivierung (bei Ablehnung)" + raci_referenz: "3.11" citation: [381] \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_governance_framework.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_governance_framework.yaml index 485ff34..af50b1e 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_governance_framework.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_governance_framework.yaml @@ -1,1248 +1,1248 @@ -# ============================================================================= -# SPM GOVERNANCE-FRAMEWORK -# ============================================================================= -# Version: 1.1 -# Datum: 2026-01-31 -# Status: Entwurf -# Quelle: Konsolidierung aus GOV-001 bis GOV-PR-007, GOV-SR-001 bis GOV-SR-005, -# GOV-TR-010 bis GOV-TR-030, GOV-CE-001 bis GOV-CE-003, GOV-SOR-001 bis GOV-SOR-003 -# ============================================================================= - -meta: - typ: "governance_framework" - funktion: "Service Portfolio Management" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Service-Portfolio-Management" - - status: - inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" - status: "entwurf" - - kontext_tags: - - "governance" - - "service-portfolio-management" - - "entscheidungslogik" - - "eskalation" - - "service-lifecycle" - - zweck: | - Dieses Dokument konsolidiert die Governance-Entscheidungen, die während - der SPM-Konzeptentwicklung getroffen wurden, zu einem kohärenten Regelwerk. - - Es definiert: - - Governance-Prinzipien für SPM-Entscheidungen - - Entscheidungsdomänen und deren Regeln - - Eskalationslogik und -pfade - - Entscheidungsmatrix (wer entscheidet was) - - Schnittstellen-Governance zu anderen Funktionen - - abgrenzung: | - Dieses Framework regelt die SPM-Governance und die Schnittstellen zu - anderen Funktionen. Es ersetzt nicht: - - Die Rollenbeschreibungen (rolle_service-owner.yaml, rolle_service-portfolio-manager.yaml) - - Die Practice-Konzepte (SCM, SLM, Change Enablement, SSM) - - Die Lifecycle-Konzepte (Transition, Review) - - Die SOR-Geschäftsordnung (operative Gremienregelungen) - - Explizit NICHT im Scope dieser Version: - - Service-Betrieb-Governance (spätere Phase) - - Operations-Manager-Verantwortlichkeiten (spätere Phase) - - quellen: - - dokument: "spm_governance-entscheidungen-log.yaml" - beschreibung: "Vollständige Dokumentation aller Governance-Entscheidungen" - - dokument: "rolle_service-owner.yaml" - beschreibung: "SO-Entscheidungsbefugnisse" - - dokument: "rolle_service-portfolio-manager.yaml" - beschreibung: "SPM-Entscheidungsbefugnisse" - - dokument: "spm_sor_go.yaml" - beschreibung: "SOR-Geschäftsordnung" - - dokument: "spm_konzept_service-transition.yaml" - beschreibung: "Transition-Governance" - - dokument: "spm_konzept_service-review.yaml" - beschreibung: "Service-Review-Governance" - - dokument: "spm_konzept_service-portfolio-review.yaml" - beschreibung: "Portfolio-Review-Governance" - - dokument: "spm_practice_change-enablement.yaml" - beschreibung: "Change-Governance" - -# ============================================================================= -# GOVERNANCE-PRINZIPIEN -# ============================================================================= - -governance_prinzipien: - - beschreibung: | - Die folgenden Prinzipien leiten alle Governance-Entscheidungen im - SPM-Kontext. Sie wurden aus den konkreten Entscheidungen abstrahiert - und bilden das normative Fundament. - - prinzipien: - - # ------------------------------------------------------------------------- - - id: "GP-SPM-01" - name: "Subsidiarität in der Service-Verantwortung" - - beschreibung: | - Der Service Owner trägt die End-to-End-Verantwortung für seinen - Service. Entscheidungen werden auf der niedrigsten kompetenten - Ebene getroffen. SPM und SOR greifen nur ein, wo Portfolio-Perspektive - oder Gremien-Governance erforderlich ist. - - konsequenzen: - - "SO entscheidet autonom über Normal Changes" - - "SO führt Service-Reviews eigenständig durch" - - "SO ist Change Authority für seinen Service-Scope" - - "Eskalation an SOR nur bei definierten Triggern" - - governance_referenzen: - - "GOV-SR-002" - - "GOV-CE-003" - - "GOV-007" - - # ------------------------------------------------------------------------- - - id: "GP-SPM-02" - name: "Orientierung mit Urteilsvorbehalt" - - beschreibung: | - SPM verwendet Orientierungskriterien statt starrer Schwellenwerte. - Kriterien definieren typische Konstellationen, aber das finale - Urteil liegt bei der verantwortlichen Rolle. Bei Abweichung von - der Orientierung besteht Begründungspflicht. - - begruendung: | - Starre Schwellenwerte führen zu Schein-Objektivität und Gaming. - Die Datenbasis im MVP ist nicht robust genug für automatisierte - Entscheidungen. Professionelles Urteilsvermögen wird höher - bewertet als mechanische Regelanwendung. - - konsequenzen: - - "Keine automatischen Trigger für Eskalationen" - - "Begründungspflicht bei Abweichung (2-3 Sätze)" - - "Review-Entscheidungen basieren auf qualitativer Bewertung" - - "Portfolio-Aggregation nutzt Orientierungskriterien, keine Formeln" - - governance_referenzen: - - "GOV-SR-003" - - "GOV-PR-005" - - # ------------------------------------------------------------------------- - - id: "GP-SPM-03" - name: "Governance-Fokus auf Ausnahmen" - - beschreibung: | - Die SOR-Governance fokussiert auf Entscheidungen, die Governance - erfordern. Routine-Vorgänge (CONTINUE, Standard Changes, Minor - Katalogänderungen) binden keine Gremienzeit. Management by Exception - als Leitprinzip. - - konsequenzen: - - "CONTINUE-Reviews: Keine SOR-Behandlung, nur Dokumentation" - - "Standard Changes: Pre-authorized, keine Einzelgenehmigung" - - "Minor Katalogänderungen: SO-Autonomie" - - "SOR-Agenda nur für echte Entscheidungen" - - governance_referenzen: - - "GOV-SR-004" - - "GOV-008" - - # ------------------------------------------------------------------------- - - id: "GP-SPM-04" - name: "Transparenz ohne Kontrollbürokratie" - - beschreibung: | - SPM erhält Transparenz über Portfolio-relevante Vorgänge, ohne - dass dies zu Genehmigungsprozessen führt. Information dient der - Portfolio-Übersicht, nicht der Kontrolle des SO. - - konsequenzen: - - "SO informiert SPM über alle Service-Reviews (unabhängig vom Ergebnis)" - - "SO dokumentiert Standard Change-Modelle, SPM erhält Kopie" - - "SPM aggregiert für Portfolio-Sicht, interveniert nicht" - - "Katalog-Backlog bei SPM, ohne Blockade-Recht" - - governance_referenzen: - - "GOV-SR-002" - - "GOV-006" - - # ------------------------------------------------------------------------- - - id: "GP-SPM-05" - name: "Klare Verantwortungstrennung SPM/SHM" - - beschreibung: | - SPM und SHM haben klar getrennte Verantwortungsbereiche. - Es gibt keine Doppel-Zuständigkeiten, aber definierte - Schnittstellen für den Informationsaustausch. - - verantwortungstrennung: - spm_verantwortet: - - "Service-Qualität (technisch, funktional)" - - "SLA-Erfüllung und -Governance" - - "Service-Performance (Einzelservice-Perspektive)" - - "Katalog-Inhalte und -Struktur" - - shm_verantwortet: - - "Beziehungsqualität" - - "Bedarfserfüllung" - - "Strategische Passung" - - "Aggregierte Stakeholder-Sicht" - - gemeinsam: - - "Kundenforum (integriertes Format)" - - "Service-Steckbrief Kundenverständlichkeit (SHM consulted)" - - governance_referenzen: - - "GOV-012" - - "GOV-009" - - "GOV-SHM-024" - -# ============================================================================= -# ENTSCHEIDUNGSDOMÄNEN -# ============================================================================= - -entscheidungsdomaenen: - - beschreibung: | - Die Governance-Entscheidungen sind in fünf Domänen gruppiert. - Jede Domäne hat spezifische Regeln und Entscheidungslogiken. - - # --------------------------------------------------------------------------- - # DOMÄNE A: PORTFOLIO-GOVERNANCE - # --------------------------------------------------------------------------- - - portfolio_governance: - - name: "Portfolio-Governance" - beschreibung: | - Regeln für die Struktur, Pflege und Steuerung des Service-Portfolios. - - governance_referenzen: - - "GOV-001 bis GOV-012" - - "GOV-PR-001 bis GOV-PR-007" - - teilbereiche: - - # ----------------------------------------------------------------------- - service_kategorisierung: - - name: "Service-Kategorisierung" - - regel: | - Services werden in drei Kategorien eingeteilt (A/B/C), die - Betreuungsintensität und Governance-Aufwand differenzieren. - - entscheidungshoheit: - vorbereitung: "SPM" - entscheidung: "Mission Board" - - referenz: "GOV-001" - - # ----------------------------------------------------------------------- - katalog_governance: - - name: "Service-Katalog-Governance" - - dreistufiges_modell: - - - stufe: "Redaktionell" - beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"] - entscheidung: "SO autonom" - governance: "Keine" - - - stufe: "Minor" - beispiele: ["Neue SLA-Variante", "Leistungsanpassung"] - entscheidung: "SO mit SPM-Freigabe" - governance: "SPM validiert Portfolio-Konsistenz" - - - stufe: "Major" - beispiele: ["Neuer Service", "Service-Stilllegung", "Strukturänderung"] - entscheidung: "SOR" - governance: "Vollständige Gremienbehandlung" - - referenz: "GOV-008" - - # ----------------------------------------------------------------------- - portfolio_review: - - name: "Portfolio-Review-Governance" - - zweistufiges_modell: - - - ebene: "E2 (Quartalsweise)" - gremium: "SOR" - inhalt: "Portfolio-Status-Übersicht, Ampelverteilung, Muster" - output: "Bestätigter Portfolio-Status, Eskalationsempfehlungen" - - - ebene: "E1 (Jährlich)" - gremium: "Vision Board" - inhalt: "Jahres-Portfolio-Report, strategische Analyse" - output: "Strategische Empfehlungen, Ressourcen-Implikationen" - - datenbasis: | - Datenpunkte werden aus Service-Reviews abgeleitet, nicht separat - erhoben. Daten-Gaps werden explizit markiert. - - aggregationslogik: | - Orientierungskriterien (AK-01 bis AK-06) mit Urteilsvorbehalt. - Keine mathematische Formel. Bei Abweichung Begründungspflicht. - - referenzen: - - "GOV-PR-001 bis GOV-PR-007" - - # --------------------------------------------------------------------------- - # DOMÄNE B: LIFECYCLE-GOVERNANCE - # --------------------------------------------------------------------------- - - lifecycle_governance: - - name: "Service-Lifecycle-Governance" - beschreibung: | - Regeln für die Steuerung von Services durch ihren Lebenszyklus. - Fokus auf Transition und Review. Service-Betrieb ist in dieser - Framework-Version nicht im Scope. - - governance_referenzen: - - "GOV-TR-010 bis GOV-TR-030" - - "GOV-SR-001 bis GOV-SR-005" - - teilbereiche: - - # ----------------------------------------------------------------------- - service_transition: - - name: "Service-Transition-Governance" - - gate_modell: - - beschreibung: | - Dreistufiges Gate-Modell mit unterschiedlichen Governance-Verfahren. - Gate 1 und Gate 3 sind SOR-Entscheidungen, Gate 2 ist SO-Entscheidung. - - gates: - - - gate: "Gate 1 (Build or Configure Decision)" - aktivitaets_id: "tr_01" - zweck: "Entry-Gate der Transition-Phase" - entscheidung: "SOR-Gremiumsentscheidung" - governance: "SOR prüft Design-Vollständigkeit, Budget, Architektur" - hinweis: "Reguläres Gate für alle Transition-Eintritte (neue Services und Major Changes, die bei Transition einsteigen)" - referenz: "GOV-TR-011" - - - gate: "Gate 2 (Entry-Prüfung nach Build)" - aktivitaets_id: "tr_09" - zweck: "Validierung der Übergabefähigkeit nach Build" - entscheidung: "SO-Einzelentscheidung" - governance: "SO prüft Übergabe-Vollständigkeit, Abnahme-Status" - pilot_entscheidung: "SO entscheidet kriterienbasiert" - referenz: "GOV-TR-012" - - - gate: "Gate 3 (Go-Live-Freigabe)" - aktivitaets_id: "tr_12" - zweck: "Freigabe für produktiven Betrieb" - entscheidung: "SOR-Gremiumsentscheidung" - governance: "Vollständige Prüfung, Protokollierung" - referenz: "GOV-TR-016" - - els_governance: - - beschreibung: | - Early Life Support nach Go-Live mit SO-Ermessen für Dauer. - - dauer: "Orientierungswert 2-4 Wochen, SO-Ermessen" - exit_kriterien: "Keine kritischen offenen Störungen, Stabilität erreicht" - referenz: "GOV-TR-020" - - # ----------------------------------------------------------------------- - service_review: - - name: "Service-Review-Governance" - - review_modell: - - beschreibung: | - Quartalsweiser Selbst-Review durch SO mit differenzierter - SOR-Behandlung nach Handlungsempfehlung. - - frequenz: "Quartalsweise (regulär), Ad-hoc bei Triggern" - verantwortlich: "Service Owner (A/R)" - - dimensionen: - - "Nutzung & Nachfrage" - - "Qualität & Performance" - - "Wirtschaftlichkeit" - - "Strategische Passung" - - "Technische Gesundheit" - - handlungsempfehlungen: - - empfehlung: "CONTINUE" - beschreibung: "Stabiler Betrieb, kein Handlungsbedarf" - sor_behandlung: false - - - empfehlung: "IMPROVEMENT" - beschreibung: "Optimierung im Service-Rahmen" - sor_behandlung: "Nur wenn ressourcenrelevant" - - - empfehlung: "REDESIGN" - beschreibung: "Grundlegende Neugestaltung erforderlich" - sor_behandlung: true - output: "Demand an DPM" - - - empfehlung: "RETIRE" - beschreibung: "Service soll stillgelegt werden" - sor_behandlung: true - output: "Stilllegungsprojekt via DPM" - - referenzen: - - "GOV-SR-001 bis GOV-SR-005" - - # --------------------------------------------------------------------------- - # DOMÄNE C: CHANGE-GOVERNANCE - # --------------------------------------------------------------------------- - - change_governance: - - name: "Change-Governance" - beschreibung: | - Regeln für die Klassifizierung und Autorisierung von Service-Änderungen. - - governance_referenzen: - - "GOV-CE-001 bis GOV-CE-003" - - teilbereiche: - - # ----------------------------------------------------------------------- - change_klassifizierung: - - name: "Change-Typen und Autorisierung" - - typen: - - - typ: "Standard Change" - definition: "Wiederkehrend, risikoarm, dokumentiert" - change_authority: "Pre-authorized (via Change-Modell)" - governance: "Einmalige SO-Genehmigung des Modells" - - - typ: "Normal Change" - definition: "Einzelfall, überschaubares Risiko" - change_authority: "Service Owner" - governance: "SO-Einzelentscheidung" - - - typ: "Major Change" - definition: "Service-Identität betroffen, SOR-Autorisierung erforderlich" - change_authority: "SOR (einmalige Autorisierung)" - governance: "SOR autorisiert und legt Einstiegspunkt fest (Design/Transition). Danach regulärer Lifecycle." - - - typ: "Emergency Change" - definition: "Kritische Sicherheit/Verfügbarkeit" - change_authority: "Betrieb/Support (Sofortumsetzung)" - governance: "Nachträgliche Dokumentation (24h)" - referenz: "GOV-CE-001" - - # ----------------------------------------------------------------------- - cross_service_impact: - - name: "Cross-Service-Impact" - - regel: | - SO ist verantwortlich für Erkennung von Cross-Service-Impact. - Bei potenziellem Impact: SPM als "Zweite Augen" einbeziehen. - - schwellenwert: "SO-Ermessen ('Im Zweifel SPM einbeziehen')" - - referenz: "GOV-CE-003" - - # --------------------------------------------------------------------------- - # DOMÄNE D: GREMIEN-GOVERNANCE - # --------------------------------------------------------------------------- - - gremien_governance: - - name: "Gremien-Governance" - beschreibung: | - Regeln für die Arbeitsweise der SPM-relevanten Gremien. - - governance_referenzen: - - "GOV-SOR-001 bis GOV-SOR-003" - - teilbereiche: - - # ----------------------------------------------------------------------- - sor_governance: - - name: "Service Operations Runde (SOR)" - - charakterisierung: - ebene: "Koordinativ (unterhalb Mission Board)" - doppelfunktion: - - "Entscheidungsfunktion: Governance-Entscheidungen zu Services" - - "Koordinationsfunktion: Abstimmung Service/Betrieb/Support" - - vorsitz: - rolle: "SPM" - befugnisse: - - "Verfahrenshoheit (Agenda, Moderation)" - - "Stimmberechtigtes Mitglied" - - "Kein Stichentscheid bei inhaltlichen Fragen" - referenz: "GOV-SOR-002" - - entscheidungsmodus: "Konsent" - - dissens_verfahren: - beschreibung: | - Bei Dissens hat SPM Verfahrenshoheit zur Koordination, - aber keinen Stichentscheid. Eskalation an MB bei - unauflösbarem Dissens. - referenz: "GOV-SOR-003" - - entscheidungstypen: - - "Gate-1-Freigaben (Entry-Autorisierung für Transition)" - - "Gate-3-Freigaben (Go-Live-Freigabe)" - - "Major-Change-Autorisierungen (einmalig, inkl. Einstiegspunkt)" - - "Service-Review-Entscheidungen (IMPROVEMENT ressourcenrelevant, REDESIGN, RETIRE)" - - "Major Katalogänderungen" - - "Portfolio-Status-Bestätigung (E2)" - - "Implementierung von RUN/Change-Entscheidungen des Service Owners (ROUTE-SO)" - - verweis: "spm_sor_go.yaml für operative Details" - - # ----------------------------------------------------------------------- - mb_eskalation: - - name: "Eskalation an Mission Board" - - trigger: - - "Ressourcenkonflikt nicht in SOR lösbar" - - "Strategische Tragweite (SO/SPM-Einschätzung)" - - "Unauflösbarer Dissens in SOR" - - "Portfolio-Entscheidungen mit Budget-Implikation" - - verfahren: | - SPM bereitet Eskalationsvorlage vor, MB entscheidet. - SOR-Protokoll dokumentiert Eskalationsgrund. - - # --------------------------------------------------------------------------- - # DOMÄNE E: SCHNITTSTELLEN-GOVERNANCE - # --------------------------------------------------------------------------- - - schnittstellen_governance: - - name: "Schnittstellen-Governance" - beschreibung: | - Regeln für die Zusammenarbeit mit anderen DIGITOM-Funktionen. - - schnittstellen: - - # ----------------------------------------------------------------------- - spm_dpm: - - name: "Schnittstelle SPM ↔ DPM" - - richtungen: - - - richtung: "DPM → SPM" - trigger: "Freigegebener Demand mit Service-Bezug" - uebergabepunkt: "Nach DSR/MB-Freigabe" - artefakt: "Demand-Steckbrief" - empfaenger: "SO (für Service-Entwicklung)" - - - richtung: "SPM → DPM" - trigger: "REDESIGN oder RETIRE aus Service-Review" - uebergabepunkt: "Nach SOR-Freigabe" - artefakt: "Demand (Neugestaltung oder Stilllegung)" - absender: "SO via SOR" - - koordination: - gremium: "DSR" - spm_rolle: "Mitglied (bei Service-relevanten Routing-Fragen)" - - referenzen: - - "GOV-SR-004" - - "demand-lifecycle-blueprint" - - # ----------------------------------------------------------------------- - spm_shm: - - name: "Schnittstelle SPM ↔ SHM" - - richtungen: - - - richtung: "SHM → SPM" - trigger: "Change-Routing (ROUTE-SPM)" - artefakt: "Bedarfssteckbrief" - empfaenger: "SO" - - - richtung: "SPM → SHM" - trigger: "Service-Steckbrief Kundenverständlichkeit" - artefakt: "Service-Steckbrief zur Prüfung" - mvp_hinweis: "Optional, nicht blockierend" - - gemeinsame_formate: - - - format: "Kundenforum" - beschreibung: | - Integriertes Format für SLA-Abstimmung (SLM-Verantwortung) - und Beziehungspflege (SHM-Verantwortung). - governance: - durchfuehrung: "SM (R), SPM (R)" - accountable: "SHM-L" - so_rolle: "C (bei Service-spezifischen Themen)" - referenz: "GOV-012, GOV-SHM-015" - - reporting_abgrenzung: - spm_berichtet: - - "Service-Qualität" - - "SLA-Erfüllung" - - "Service-Performance" - shm_berichtet: - - "Beziehungsqualität" - - "Bedarfserfüllung" - - "Stakeholder-Zufriedenheit" - keine_dopplung: true - referenz: "GOV-SHM-024" - - # ----------------------------------------------------------------------- - spm_ppm: - - name: "Schnittstelle SPM ↔ PPM" - status: "placeholder" - - beschreibung: | - Die Schnittstelle zu Projekt-Portfolio-Management (PPM) ist - in der aktuellen Phase nicht vollständig konzipiert. - - bekannte_beruehrungspunkte: - - "Projekt→Service-Übergabe (Ende Projektphase)" - - "Koordination bei Projekten mit Service-Impact" - - "Ressourcenallokation bei REDESIGN-Demands" - - offene_punkte: - - id: "OPEN-SPM-005" - beschreibung: "Bei PPM-Konzeption zu klären" - - verweis: "schnittstelle_spm-ppm.yaml (ausstehend)" - -# ============================================================================= -# ESKALATIONSLOGIK -# ============================================================================= - -eskalationslogik: - - beschreibung: | - Definition der Eskalationspfade für verschiedene Situationen. - Eskalation bedeutet die Weiterleitung einer Entscheidung oder eines - Themas an eine höhere Instanz. - - prinzip: | - Eskalation ist kein Zeichen von Versagen, sondern ein definierter - Governance-Mechanismus. Die Eskalationspflicht liegt bei der Rolle, - die die Grenzen ihrer Entscheidungskompetenz erkennt. - - pfade: - - # ------------------------------------------------------------------------- - - id: "ESK-SPM-01" - name: "SO → SOR (Review-Eskalation)" - - trigger: - - "Service-Review mit Empfehlung REDESIGN" - - "Service-Review mit Empfehlung RETIRE" - - "Service-Review mit ressourcenrelevantem IMPROVEMENT" - - "Mindestens eine Review-Dimension 'Rot'" - - "SO ist unsicher über Handlungsempfehlung" - - verfahren: | - SO reicht Review-Vorlage bei SPM ein (3 Arbeitstage vor SOR). - SPM prüft Vollständigkeit, setzt auf SOR-Agenda. - SOR entscheidet gemäß Behandlungskategorien. - - output: - - "Freigabe der Maßnahmen" - - "Freigabe mit Auflagen" - - "Zurückweisung" - - "Eskalation an MB" - - # ------------------------------------------------------------------------- - - id: "ESK-SPM-02" - name: "SO → SOR (Transition Gate 3 - Go-Live)" - - trigger: - - "Service-Transition erreicht Gate 3 (Go-Live-Entscheidung)" - - "Regulärer Lifecycle-Gate-3-Antrag (neue Services und Major Changes)" - - verfahren: | - SO reicht Transition-Steckbrief bei SPM ein. - SPM prüft Vollständigkeit, setzt auf SOR-Agenda. - SOR entscheidet: Go-Live / Auflagen / Zurück an Transition / Ablehnung. - - output: - - "Go-Live-Freigabe" - - "Freigabe mit Auflagen" - - "Zurück an Transition" - - "Eskalation an MB" - - # ------------------------------------------------------------------------- - - id: "ESK-SPM-03" - name: "SO → SPM (Cross-Service-Impact)" - - trigger: - - "Normal Change mit potenziellem Cross-Service-Impact" - - "SO-Unsicherheit über Auswirkungen auf andere Services" - - verfahren: | - SO informiert SPM über geplanten Change. - SPM prüft aus Portfolio-Perspektive. - Bei bestätigtem Cross-Service-Impact: Abstimmung mit betroffenen SOs. - - output: - - "Bestätigung: Kein relevanter Impact" - - "Koordinierter Change mit betroffenen SOs" - - "Hochstufung zu Major Change (SOR-Behandlung)" - - # ------------------------------------------------------------------------- - - id: "ESK-SPM-04" - name: "SOR → MB (Strategische Eskalation)" - - trigger: - - "Ressourcenkonflikt nicht in SOR lösbar" - - "Strategische Tragweite übersteigt SOR-Mandat" - - "Unauflösbarer Dissens in SOR" - - "Budget-relevante Portfolio-Entscheidungen" - - verfahren: | - SPM bereitet Eskalationsvorlage vor. - SOR-Protokoll dokumentiert Eskalationsgrund. - MB entscheidet. - - output: - - "MB-Entscheidung" - - "Rückverweis an SOR mit Vorgaben" - - # ------------------------------------------------------------------------- - - id: "ESK-SPM-05" - name: "SPM → MB (Portfolio-Eskalation)" - - trigger: - - "Portfolio-Review identifiziert systemische Probleme" - - "IMPROVE-ESCALATE (Resource) aus Portfolio-Review" - - "Mehrere RETIRE-Empfehlungen mit gemeinsamer Ursache" - - verfahren: | - SPM dokumentiert im Quartals- oder Jahres-Report. - E2-Eskalation: Via SOR an MB. - E1-Eskalation: Direkt im Jahres-Report an VB. - - output: - - "Strategische Maßnahmen" - - "Ressourcen-Reallokation" - - "Portfolio-Bereinigung" - -# ============================================================================= -# ENTSCHEIDUNGSMATRIX -# ============================================================================= - -entscheidungsmatrix: - - beschreibung: | - Vollständige Zuordnung von Entscheidungsgegenständen zu Rollen und - Gremien. Die Matrix folgt dem Subsidiaritätsprinzip (GP-SPM-01). - - legende: - A: "Accountable – trägt die Entscheidungsverantwortung" - R: "Responsible – führt aus / bereitet vor" - C: "Consulted – wird vor Entscheidung konsultiert" - I: "Informed – wird über Entscheidung informiert" - "-": "Nicht beteiligt" - - rollen: - SO: "Service Owner" - SPM: "Service-Portfolio-Manager" - SOR: "Service Operations Runde" - DSR: "Demand & Stakeholder-Runde" - MB: "Mission Board" - VB: "Vision Board" - DPM: "Demand-Portfolio-Manager" - SHM: "Stakeholder-Manager" - - # --------------------------------------------------------------------------- - # LIFECYCLE-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - lifecycle_entscheidungen: - - name: "Lifecycle-Entscheidungen" - beschreibung: "Entscheidungen im Service-Lebenszyklus" - - entscheidungen: - - - id: "E-LC-01" - gegenstand: "Gate 1 (Entry-Autorisierung) Freigabe" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "I" - VB: "-" - DPM: "-" - SHM: "-" - hinweis: "SOR autorisiert Entry in Transition (neue Services und Major Changes)" - referenz: "GOV-TR-011" - - - id: "E-LC-02" - gegenstand: "Pilot-Entscheidung (ja/nein)" - SO: "A/R" - SPM: "I" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - hinweis: "Kriterienbasiert, SO-Ermessen" - - - id: "E-LC-03" - gegenstand: "Gate 3 (Go-Live) Freigabe" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "I" - VB: "-" - DPM: "-" - SHM: "-" - hinweis: "SOR gibt Go-Live für produktiven Betrieb frei (neue Services und Major Changes)" - referenz: "GOV-TR-016" - - - id: "E-LC-04" - gegenstand: "ELS-Exit-Entscheidung" - SO: "A/R" - SPM: "I" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-TR-020" - - - id: "E-LC-05" - gegenstand: "Service-Review durchführen" - SO: "A/R" - SPM: "I" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-SR-002" - - - id: "E-LC-06" - gegenstand: "Review-Eskalation an SOR" - SO: "R" - SPM: "R (Agenda)" - SOR: "A" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-SR-004" - - - id: "E-LC-07" - gegenstand: "REDESIGN/RETIRE-Freigabe" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "I" - VB: "-" - DPM: "I" - SHM: "-" - referenz: "GOV-SR-004" - - # --------------------------------------------------------------------------- - # KATALOG-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - katalog_entscheidungen: - - name: "Katalog-Entscheidungen" - beschreibung: "Entscheidungen zu Service-Katalog und -Definitionen" - - entscheidungen: - - - id: "E-KA-01" - gegenstand: "Service-Definition erstellen" - SO: "A/R" - SPM: "C" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-007" - - - id: "E-KA-02" - gegenstand: "Service-Definition validieren" - SO: "R" - SPM: "A" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-007" - - - id: "E-KA-03" - gegenstand: "Redaktionelle Katalogänderung" - SO: "A/R" - SPM: "-" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-008" - - - id: "E-KA-04" - gegenstand: "Minor Katalogänderung" - SO: "R" - SPM: "A" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-008" - - - id: "E-KA-05" - gegenstand: "Major Katalogänderung" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-008" - - - id: "E-KA-06" - gegenstand: "Service-Kategorisierung (A/B/C)" - SO: "C" - SPM: "R" - SOR: "-" - DSR: "-" - MB: "A" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-001" - - - id: "E-KA-07" - gegenstand: "Kundenverständlichkeit prüfen" - SO: "R" - SPM: "A" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "C" - hinweis: "Im MVP optional" - referenz: "GOV-009" - - # --------------------------------------------------------------------------- - # CHANGE-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - change_entscheidungen: - - name: "Change-Entscheidungen" - beschreibung: "Entscheidungen zu Service-Änderungen" - - entscheidungen: - - - id: "E-CH-01" - gegenstand: "Change-Klassifizierung" - SO: "A/R" - SPM: "-" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - - - id: "E-CH-02" - gegenstand: "Standard Change-Modell genehmigen" - SO: "A/R" - SPM: "I" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - - - id: "E-CH-03" - gegenstand: "Normal Change freigeben" - SO: "A/R" - SPM: "C (bei Cross-Service)" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-CE-003" - - - id: "E-CH-04" - gegenstand: "Major Change freigeben" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - hinweis: "EIN Entscheidungspunkt: SOR-Autorisierung (inkl. Festlegung Einstiegspunkt). Danach regulärer Lifecycle." - referenz: "GOV-TR-003" - - - id: "E-CH-05" - gegenstand: "Emergency Change (Sofortumsetzung)" - SO: "I" - SPM: "-" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - hinweis: "Betrieb/Support führt aus, SO wird informiert" - referenz: "GOV-CE-001" - - # --------------------------------------------------------------------------- - # SLA-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - sla_entscheidungen: - - name: "SLA-Entscheidungen" - beschreibung: "Entscheidungen zu Service Level Agreements" - - entscheidungen: - - - id: "E-SL-01" - gegenstand: "SLS (Service Level Specification) erstellen" - SO: "A/R" - SPM: "C" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - - - id: "E-SL-02" - gegenstand: "Standard-SLA anwenden" - SO: "A/R" - SPM: "-" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - - - id: "E-SL-03" - gegenstand: "Individuelles SLA genehmigen" - SO: "R" - SPM: "R (Vorsitz)" - SOR: "A" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "-" - - - id: "E-SL-04" - gegenstand: "SLA-Eskalation behandeln" - SO: "R" - SPM: "C" - SOR: "-" - DSR: "-" - MB: "-" - VB: "-" - DPM: "-" - SHM: "I (bei Kundenrelevanz)" - referenz: "GOV-002" - - # --------------------------------------------------------------------------- - # PORTFOLIO-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - portfolio_entscheidungen: - - name: "Portfolio-Entscheidungen" - beschreibung: "Entscheidungen auf Portfolio-Ebene" - - entscheidungen: - - - id: "E-PF-01" - gegenstand: "Portfolio-Status bestätigen (E2)" - SO: "I" - SPM: "R" - SOR: "A" - DSR: "-" - MB: "I" - VB: "-" - DPM: "I" - SHM: "-" - referenz: "GOV-PR-002" - - - id: "E-PF-02" - gegenstand: "Portfolio-Report erstellen (E1)" - SO: "C" - SPM: "A/R" - SOR: "-" - DSR: "-" - MB: "I" - VB: "I" - DPM: "I" - SHM: "-" - referenz: "GOV-PR-002" - - - id: "E-PF-03" - gegenstand: "IMPROVE-ESCALATE (Resource)" - SO: "-" - SPM: "R" - SOR: "R" - DSR: "-" - MB: "A" - VB: "-" - DPM: "-" - SHM: "-" - referenz: "GOV-PR-004" - - - id: "E-PF-04" - gegenstand: "RETIRE-RECOMMEND (Portfolio-Ebene)" - SO: "C" - SPM: "R" - SOR: "A" - DSR: "-" - MB: "I" - VB: "-" - DPM: "I" - SHM: "-" - referenz: "GOV-PR-004" - -# ============================================================================= -# QUERVERWEIS GOVERNANCE-LOG -# ============================================================================= - -querverweis_governance_log: - - beschreibung: | - Mapping zwischen den Governance-Entscheidungen im Log und den - Abschnitten in diesem Framework. - - dokument: "spm_governance-entscheidungen-log.yaml" - - mapping: - - portfolio_governance: - - "GOV-001: Service-Kategorisierung" - - "GOV-002: SLA-Eskalationsmechanismus" - - "GOV-003: Interner vs. externer Review" - - "GOV-005: SLA-Partner = Entscheidungsbefugte" - - "GOV-006: SPM ist Practice Owner für SCM" - - "GOV-007: SO erstellt Service-Definition, SPM validiert" - - "GOV-008: Dreistufige Katalog-Governance" - - "GOV-009: SHM-Einbindung für Kundenverständlichkeit" - - "GOV-010: Trennung Inhalt (SPM) vs. Betrieb (Technik)" - - "GOV-011: Service-Kategorien (A/B/C)" - - "GOV-012: Integriertes Kundenforum" - - lifecycle_governance: - - "GOV-TR-011: Gate 1 = SOR-Entscheidung (Entry-Autorisierung)" - - "GOV-TR-012: Gate 2 = SO-Einzelentscheidung (Entry-Prüfung nach Build)" - - "GOV-TR-016: Gate 3 = SOR-Entscheidung (Go-Live-Freigabe)" - - "GOV-TR-003: Major Change = einmalige SOR-Autorisierung (danach regulärer Lifecycle)" - - "GOV-TR-010 bis GOV-TR-030: Transition-Details" - - "GOV-SR-001: Quartalsweiser Service-Review" - - "GOV-SR-002: SO accountable für Review" - - "GOV-SR-003: Orientierungskriterien mit Urteilsvorbehalt" - - "GOV-SR-004: Differenzierte SOR-Behandlung" - - "GOV-SR-005: Improvement via Service-Definition" - - change_governance: - - "GOV-CE-001: Emergency Changes" - - "GOV-CE-002: Scope (Service-Changes, nicht Infrastruktur)" - - "GOV-CE-003: Cross-Service-Impact" - - portfolio_review_governance: - - "GOV-PR-001: Datenbasis aus Service-Reviews" - - "GOV-PR-002: E1/E2-Struktur" - - "GOV-PR-003: Zeitliche Synchronisation" - - "GOV-PR-004: Entscheidungstypen Portfolio-Ebene" - - "GOV-PR-005: Aggregationslogik" - - "GOV-PR-006: Mapping Service-Review → Portfolio-Review" - - "GOV-PR-007: SOR-Agenda-Struktur" - - gremien_governance: - - "GOV-SOR-001: Routing-Klärung bilateral über Service Owner (aktualisiert per GOV-SHM-029)" - - "GOV-SOR-002: SPM = SOR-Vorsitz" - - "GOV-SOR-003: Koordination bei Dissens, kein Stichentscheid" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.1" - datum: "2026-02-19" - autor: "DIGITOM-Projekt" - aenderung: | - Major-Change-Governance vereinfacht (Kundenvorschlag): - - Change-Klassifizierung: "Transition erforderlich" → "SOR-Autorisierung erforderlich" - - Change Authority: "Entry + Gate 3" → "einmalige Autorisierung" - - SOR-Entscheidungstypen: "Entry + Go-Live" → "einmalig, inkl. Einstiegspunkt" - - Entscheidungsmatrix E-CH-04: zwei Entscheidungspunkte → ein Entscheidungspunkt - - Querverweis GOV-TR-003: angepasst - - Gate 1 Hinweis: reguläres Gate für alle Transition-Eintritte - - ESK-SPM-02 Trigger: angepasst - Konsistent mit spm_practice_change-enablement.yaml v1.3 - - - version: "1.0" - datum: "2025-12-17" - autor: "DIGITOM-Projekt" - aenderung: | - Initiale Erstellung durch Konsolidierung der SPM-Governance-Entscheidungen. - - Konsolidierte Quellen: - - spm_governance-entscheidungen-log.yaml (30+ GOV-IDs) - - rolle_service-owner.yaml - - rolle_service-portfolio-manager.yaml - - spm_sor_go.yaml - - spm_konzept_service-transition.yaml - - spm_konzept_service-review.yaml - - spm_konzept_service-portfolio-review.yaml - - spm_practice_change-enablement.yaml - - Struktur: - - 5 Governance-Prinzipien (GP-SPM-01 bis GP-SPM-05) - - 5 Entscheidungsdomänen - - 5 Eskalationspfade (ESK-SPM-01 bis ESK-SPM-05) - - 25 Entscheidungsgegenstände in Matrix - - 3 Schnittstellen (DPM, SHM, PPM-Placeholder) - - Explizit nicht im Scope: - - Service-Betrieb-Governance (spätere Phase) +# ============================================================================= +# SPM GOVERNANCE-FRAMEWORK +# ============================================================================= +# Version: 1.1 +# Datum: 2026-01-31 +# Status: Entwurf +# Quelle: Konsolidierung aus GOV-001 bis GOV-PR-007, GOV-SR-001 bis GOV-SR-005, +# GOV-TR-010 bis GOV-TR-030, GOV-CE-001 bis GOV-CE-003, GOV-SOR-001 bis GOV-SOR-003 +# ============================================================================= + +meta: + typ: "governance_framework" + funktion: "Service Portfolio Management" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Service-Portfolio-Management" + + status: + inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" + status: "entwurf" + + kontext_tags: + - "governance" + - "service-portfolio-management" + - "entscheidungslogik" + - "eskalation" + - "service-lifecycle" + + zweck: | + Dieses Dokument konsolidiert die Governance-Entscheidungen, die während + der SPM-Konzeptentwicklung getroffen wurden, zu einem kohärenten Regelwerk. + + Es definiert: + - Governance-Prinzipien für SPM-Entscheidungen + - Entscheidungsdomänen und deren Regeln + - Eskalationslogik und -pfade + - Entscheidungsmatrix (wer entscheidet was) + - Schnittstellen-Governance zu anderen Funktionen + + abgrenzung: | + Dieses Framework regelt die SPM-Governance und die Schnittstellen zu + anderen Funktionen. Es ersetzt nicht: + - Die Rollenbeschreibungen (rolle_service-owner.yaml, rolle_service-portfolio-manager.yaml) + - Die Practice-Konzepte (SCM, SLM, Change Enablement, SSM) + - Die Lifecycle-Konzepte (Transition, Review) + - Die SOR-Geschäftsordnung (operative Gremienregelungen) + + Explizit NICHT im Scope dieser Version: + - Service-Betrieb-Governance (spätere Phase) + - Operations-Manager-Verantwortlichkeiten (spätere Phase) + + quellen: + - dokument: "spm_governance-entscheidungen-log.yaml" + beschreibung: "Vollständige Dokumentation aller Governance-Entscheidungen" + - dokument: "rolle_service-owner.yaml" + beschreibung: "SO-Entscheidungsbefugnisse" + - dokument: "rolle_service-portfolio-manager.yaml" + beschreibung: "SPM-Entscheidungsbefugnisse" + - dokument: "spm_sor_go.yaml" + beschreibung: "SOR-Geschäftsordnung" + - dokument: "spm_konzept_service-transition.yaml" + beschreibung: "Transition-Governance" + - dokument: "spm_konzept_service-review.yaml" + beschreibung: "Service-Review-Governance" + - dokument: "spm_konzept_service-portfolio-review.yaml" + beschreibung: "Portfolio-Review-Governance" + - dokument: "spm_practice_change-enablement.yaml" + beschreibung: "Change-Governance" + +# ============================================================================= +# GOVERNANCE-PRINZIPIEN +# ============================================================================= + +governance_prinzipien: + + beschreibung: | + Die folgenden Prinzipien leiten alle Governance-Entscheidungen im + SPM-Kontext. Sie wurden aus den konkreten Entscheidungen abstrahiert + und bilden das normative Fundament. + + prinzipien: + + # ------------------------------------------------------------------------- + - id: "GP-SPM-01" + name: "Subsidiarität in der Service-Verantwortung" + + beschreibung: | + Der Service Owner trägt die End-to-End-Verantwortung für seinen + Service. Entscheidungen werden auf der niedrigsten kompetenten + Ebene getroffen. SPM und SOR greifen nur ein, wo Portfolio-Perspektive + oder Gremien-Governance erforderlich ist. + + konsequenzen: + - "SO entscheidet autonom über Normal Changes" + - "SO führt Service-Reviews eigenständig durch" + - "SO ist Change Authority für seinen Service-Scope" + - "Eskalation an SOR nur bei definierten Triggern" + + governance_referenzen: + - "GOV-SR-002" + - "GOV-CE-003" + - "GOV-007" + + # ------------------------------------------------------------------------- + - id: "GP-SPM-02" + name: "Orientierung mit Urteilsvorbehalt" + + beschreibung: | + SPM verwendet Orientierungskriterien statt starrer Schwellenwerte. + Kriterien definieren typische Konstellationen, aber das finale + Urteil liegt bei der verantwortlichen Rolle. Bei Abweichung von + der Orientierung besteht Begründungspflicht. + + begruendung: | + Starre Schwellenwerte führen zu Schein-Objektivität und Gaming. + Die Datenbasis im MVP ist nicht robust genug für automatisierte + Entscheidungen. Professionelles Urteilsvermögen wird höher + bewertet als mechanische Regelanwendung. + + konsequenzen: + - "Keine automatischen Trigger für Eskalationen" + - "Begründungspflicht bei Abweichung (2-3 Sätze)" + - "Review-Entscheidungen basieren auf qualitativer Bewertung" + - "Portfolio-Aggregation nutzt Orientierungskriterien, keine Formeln" + + governance_referenzen: + - "GOV-SR-003" + - "GOV-PR-005" + + # ------------------------------------------------------------------------- + - id: "GP-SPM-03" + name: "Governance-Fokus auf Ausnahmen" + + beschreibung: | + Die SOR-Governance fokussiert auf Entscheidungen, die Governance + erfordern. Routine-Vorgänge (CONTINUE, Standard Changes, Minor + Katalogänderungen) binden keine Gremienzeit. Management by Exception + als Leitprinzip. + + konsequenzen: + - "CONTINUE-Reviews: Keine SOR-Behandlung, nur Dokumentation" + - "Standard Changes: Pre-authorized, keine Einzelgenehmigung" + - "Minor Katalogänderungen: SO-Autonomie" + - "SOR-Agenda nur für echte Entscheidungen" + + governance_referenzen: + - "GOV-SR-004" + - "GOV-008" + + # ------------------------------------------------------------------------- + - id: "GP-SPM-04" + name: "Transparenz ohne Kontrollbürokratie" + + beschreibung: | + SPM erhält Transparenz über Portfolio-relevante Vorgänge, ohne + dass dies zu Genehmigungsprozessen führt. Information dient der + Portfolio-Übersicht, nicht der Kontrolle des SO. + + konsequenzen: + - "SO informiert SPM über alle Service-Reviews (unabhängig vom Ergebnis)" + - "SO dokumentiert Standard Change-Modelle, SPM erhält Kopie" + - "SPM aggregiert für Portfolio-Sicht, interveniert nicht" + - "Katalog-Backlog bei SPM, ohne Blockade-Recht" + + governance_referenzen: + - "GOV-SR-002" + - "GOV-006" + + # ------------------------------------------------------------------------- + - id: "GP-SPM-05" + name: "Klare Verantwortungstrennung SPM/SHM" + + beschreibung: | + SPM und SHM haben klar getrennte Verantwortungsbereiche. + Es gibt keine Doppel-Zuständigkeiten, aber definierte + Schnittstellen für den Informationsaustausch. + + verantwortungstrennung: + spm_verantwortet: + - "Service-Qualität (technisch, funktional)" + - "SLA-Erfüllung und -Governance" + - "Service-Performance (Einzelservice-Perspektive)" + - "Katalog-Inhalte und -Struktur" + + shm_verantwortet: + - "Beziehungsqualität" + - "Bedarfserfüllung" + - "Strategische Passung" + - "Aggregierte Stakeholder-Sicht" + + gemeinsam: + - "Kundenforum (integriertes Format)" + - "Service-Steckbrief Kundenverständlichkeit (SHM consulted)" + + governance_referenzen: + - "GOV-012" + - "GOV-009" + - "GOV-SHM-024" + +# ============================================================================= +# ENTSCHEIDUNGSDOMÄNEN +# ============================================================================= + +entscheidungsdomaenen: + + beschreibung: | + Die Governance-Entscheidungen sind in fünf Domänen gruppiert. + Jede Domäne hat spezifische Regeln und Entscheidungslogiken. + + # --------------------------------------------------------------------------- + # DOMÄNE A: PORTFOLIO-GOVERNANCE + # --------------------------------------------------------------------------- + + portfolio_governance: + + name: "Portfolio-Governance" + beschreibung: | + Regeln für die Struktur, Pflege und Steuerung des Service-Portfolios. + + governance_referenzen: + - "GOV-001 bis GOV-012" + - "GOV-PR-001 bis GOV-PR-007" + + teilbereiche: + + # ----------------------------------------------------------------------- + service_kategorisierung: + + name: "Service-Kategorisierung" + + regel: | + Services werden in drei Kategorien eingeteilt (A/B/C), die + Betreuungsintensität und Governance-Aufwand differenzieren. + + entscheidungshoheit: + vorbereitung: "SPM" + entscheidung: "Mission Board" + + referenz: "GOV-001" + + # ----------------------------------------------------------------------- + katalog_governance: + + name: "Service-Katalog-Governance" + + dreistufiges_modell: + + - stufe: "Redaktionell" + beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"] + entscheidung: "SO autonom" + governance: "Keine" + + - stufe: "Minor" + beispiele: ["Neue SLA-Variante", "Leistungsanpassung"] + entscheidung: "SO mit SPM-Freigabe" + governance: "SPM validiert Portfolio-Konsistenz" + + - stufe: "Major" + beispiele: ["Neuer Service", "Service-Stilllegung", "Strukturänderung"] + entscheidung: "SOR" + governance: "Vollständige Gremienbehandlung" + + referenz: "GOV-008" + + # ----------------------------------------------------------------------- + portfolio_review: + + name: "Portfolio-Review-Governance" + + zweistufiges_modell: + + - ebene: "E2 (Quartalsweise)" + gremium: "SOR" + inhalt: "Portfolio-Status-Übersicht, Ampelverteilung, Muster" + output: "Bestätigter Portfolio-Status, Eskalationsempfehlungen" + + - ebene: "E1 (Jährlich)" + gremium: "Vision Board" + inhalt: "Jahres-Portfolio-Report, strategische Analyse" + output: "Strategische Empfehlungen, Ressourcen-Implikationen" + + datenbasis: | + Datenpunkte werden aus Service-Reviews abgeleitet, nicht separat + erhoben. Daten-Gaps werden explizit markiert. + + aggregationslogik: | + Orientierungskriterien (AK-01 bis AK-06) mit Urteilsvorbehalt. + Keine mathematische Formel. Bei Abweichung Begründungspflicht. + + referenzen: + - "GOV-PR-001 bis GOV-PR-007" + + # --------------------------------------------------------------------------- + # DOMÄNE B: LIFECYCLE-GOVERNANCE + # --------------------------------------------------------------------------- + + lifecycle_governance: + + name: "Service-Lifecycle-Governance" + beschreibung: | + Regeln für die Steuerung von Services durch ihren Lebenszyklus. + Fokus auf Transition und Review. Service-Betrieb ist in dieser + Framework-Version nicht im Scope. + + governance_referenzen: + - "GOV-TR-010 bis GOV-TR-030" + - "GOV-SR-001 bis GOV-SR-005" + + teilbereiche: + + # ----------------------------------------------------------------------- + service_transition: + + name: "Service-Transition-Governance" + + gate_modell: + + beschreibung: | + Dreistufiges Gate-Modell mit unterschiedlichen Governance-Verfahren. + Gate 1 und Gate 3 sind SOR-Entscheidungen, Gate 2 ist SO-Entscheidung. + + gates: + + - gate: "Gate 1 (Build or Configure Decision)" + aktivitaets_id: "tr_01" + zweck: "Entry-Gate der Transition-Phase" + entscheidung: "SOR-Gremiumsentscheidung" + governance: "SOR prüft Design-Vollständigkeit, Budget, Architektur" + hinweis: "Reguläres Gate für alle Transition-Eintritte (neue Services und Major Changes, die bei Transition einsteigen)" + referenz: "GOV-TR-011" + + - gate: "Gate 2 (Entry-Prüfung nach Build)" + aktivitaets_id: "tr_09" + zweck: "Validierung der Übergabefähigkeit nach Build" + entscheidung: "SO-Einzelentscheidung" + governance: "SO prüft Übergabe-Vollständigkeit, Abnahme-Status" + pilot_entscheidung: "SO entscheidet kriterienbasiert" + referenz: "GOV-TR-012" + + - gate: "Gate 3 (Go-Live-Freigabe)" + aktivitaets_id: "tr_12" + zweck: "Freigabe für produktiven Betrieb" + entscheidung: "SOR-Gremiumsentscheidung" + governance: "Vollständige Prüfung, Protokollierung" + referenz: "GOV-TR-016" + + els_governance: + + beschreibung: | + Early Life Support nach Go-Live mit SO-Ermessen für Dauer. + + dauer: "Orientierungswert 2-4 Wochen, SO-Ermessen" + exit_kriterien: "Keine kritischen offenen Störungen, Stabilität erreicht" + referenz: "GOV-TR-020" + + # ----------------------------------------------------------------------- + service_review: + + name: "Service-Review-Governance" + + review_modell: + + beschreibung: | + Quartalsweiser Selbst-Review durch SO mit differenzierter + SOR-Behandlung nach Handlungsempfehlung. + + frequenz: "Quartalsweise (regulär), Ad-hoc bei Triggern" + verantwortlich: "Service Owner (A/R)" + + dimensionen: + - "Nutzung & Nachfrage" + - "Qualität & Performance" + - "Wirtschaftlichkeit" + - "Strategische Passung" + - "Technische Gesundheit" + + handlungsempfehlungen: + - empfehlung: "CONTINUE" + beschreibung: "Stabiler Betrieb, kein Handlungsbedarf" + sor_behandlung: false + + - empfehlung: "IMPROVEMENT" + beschreibung: "Optimierung im Service-Rahmen" + sor_behandlung: "Nur wenn ressourcenrelevant" + + - empfehlung: "REDESIGN" + beschreibung: "Grundlegende Neugestaltung erforderlich" + sor_behandlung: true + output: "Demand an DPM" + + - empfehlung: "RETIRE" + beschreibung: "Service soll stillgelegt werden" + sor_behandlung: true + output: "Stilllegungsprojekt via DPM" + + referenzen: + - "GOV-SR-001 bis GOV-SR-005" + + # --------------------------------------------------------------------------- + # DOMÄNE C: CHANGE-GOVERNANCE + # --------------------------------------------------------------------------- + + change_governance: + + name: "Change-Governance" + beschreibung: | + Regeln für die Klassifizierung und Autorisierung von Service-Änderungen. + + governance_referenzen: + - "GOV-CE-001 bis GOV-CE-003" + + teilbereiche: + + # ----------------------------------------------------------------------- + change_klassifizierung: + + name: "Change-Typen und Autorisierung" + + typen: + + - typ: "Standard Change" + definition: "Wiederkehrend, risikoarm, dokumentiert" + change_authority: "Pre-authorized (via Change-Modell)" + governance: "Einmalige SO-Genehmigung des Modells" + + - typ: "Normal Change" + definition: "Einzelfall, überschaubares Risiko" + change_authority: "Service Owner" + governance: "SO-Einzelentscheidung" + + - typ: "Major Change" + definition: "Service-Identität betroffen, SOR-Autorisierung erforderlich" + change_authority: "SOR (einmalige Autorisierung)" + governance: "SOR autorisiert und legt Einstiegspunkt fest (Design/Transition). Danach regulärer Lifecycle." + + - typ: "Emergency Change" + definition: "Kritische Sicherheit/Verfügbarkeit" + change_authority: "Betrieb/Support (Sofortumsetzung)" + governance: "Nachträgliche Dokumentation (24h)" + referenz: "GOV-CE-001" + + # ----------------------------------------------------------------------- + cross_service_impact: + + name: "Cross-Service-Impact" + + regel: | + SO ist verantwortlich für Erkennung von Cross-Service-Impact. + Bei potenziellem Impact: SPM als "Zweite Augen" einbeziehen. + + schwellenwert: "SO-Ermessen ('Im Zweifel SPM einbeziehen')" + + referenz: "GOV-CE-003" + + # --------------------------------------------------------------------------- + # DOMÄNE D: GREMIEN-GOVERNANCE + # --------------------------------------------------------------------------- + + gremien_governance: + + name: "Gremien-Governance" + beschreibung: | + Regeln für die Arbeitsweise der SPM-relevanten Gremien. + + governance_referenzen: + - "GOV-SOR-001 bis GOV-SOR-003" + + teilbereiche: + + # ----------------------------------------------------------------------- + sor_governance: + + name: "Service Operations Runde (SOR)" + + charakterisierung: + ebene: "Koordinativ (unterhalb Mission Board)" + doppelfunktion: + - "Entscheidungsfunktion: Governance-Entscheidungen zu Services" + - "Koordinationsfunktion: Abstimmung Service/Betrieb/Support" + + vorsitz: + rolle: "SPM" + befugnisse: + - "Verfahrenshoheit (Agenda, Moderation)" + - "Stimmberechtigtes Mitglied" + - "Kein Stichentscheid bei inhaltlichen Fragen" + referenz: "GOV-SOR-002" + + entscheidungsmodus: "Konsent" + + dissens_verfahren: + beschreibung: | + Bei Dissens hat SPM Verfahrenshoheit zur Koordination, + aber keinen Stichentscheid. Eskalation an MB bei + unauflösbarem Dissens. + referenz: "GOV-SOR-003" + + entscheidungstypen: + - "Gate-1-Freigaben (Entry-Autorisierung für Transition)" + - "Gate-3-Freigaben (Go-Live-Freigabe)" + - "Major-Change-Autorisierungen (einmalig, inkl. Einstiegspunkt)" + - "Service-Review-Entscheidungen (IMPROVEMENT ressourcenrelevant, REDESIGN, RETIRE)" + - "Major Katalogänderungen" + - "Portfolio-Status-Bestätigung (E2)" + - "Implementierung von RUN/Change-Entscheidungen des Service Owners (ROUTE-SO)" + + verweis: "spm_sor_go.yaml für operative Details" + + # ----------------------------------------------------------------------- + mb_eskalation: + + name: "Eskalation an Mission Board" + + trigger: + - "Ressourcenkonflikt nicht in SOR lösbar" + - "Strategische Tragweite (SO/SPM-Einschätzung)" + - "Unauflösbarer Dissens in SOR" + - "Portfolio-Entscheidungen mit Budget-Implikation" + + verfahren: | + SPM bereitet Eskalationsvorlage vor, MB entscheidet. + SOR-Protokoll dokumentiert Eskalationsgrund. + + # --------------------------------------------------------------------------- + # DOMÄNE E: SCHNITTSTELLEN-GOVERNANCE + # --------------------------------------------------------------------------- + + schnittstellen_governance: + + name: "Schnittstellen-Governance" + beschreibung: | + Regeln für die Zusammenarbeit mit anderen DIGITOM-Funktionen. + + schnittstellen: + + # ----------------------------------------------------------------------- + spm_dpm: + + name: "Schnittstelle SPM ↔ DPM" + + richtungen: + + - richtung: "DPM → SPM" + trigger: "Freigegebener Demand mit Service-Bezug" + uebergabepunkt: "Nach DSR/MB-Freigabe" + artefakt: "Demand-Steckbrief" + empfaenger: "SO (für Service-Entwicklung)" + + - richtung: "SPM → DPM" + trigger: "REDESIGN oder RETIRE aus Service-Review" + uebergabepunkt: "Nach SOR-Freigabe" + artefakt: "Demand (Neugestaltung oder Stilllegung)" + absender: "SO via SOR" + + koordination: + gremium: "DSR" + spm_rolle: "Mitglied (bei Service-relevanten Routing-Fragen)" + + referenzen: + - "GOV-SR-004" + - "demand-lifecycle-blueprint" + + # ----------------------------------------------------------------------- + spm_shm: + + name: "Schnittstelle SPM ↔ SHM" + + richtungen: + + - richtung: "SHM → SPM" + trigger: "Change-Routing (ROUTE-SPM)" + artefakt: "Bedarfssteckbrief" + empfaenger: "SO" + + - richtung: "SPM → SHM" + trigger: "Service-Steckbrief Kundenverständlichkeit" + artefakt: "Service-Steckbrief zur Prüfung" + mvp_hinweis: "Optional, nicht blockierend" + + gemeinsame_formate: + + - format: "Kundenforum" + beschreibung: | + Integriertes Format für SLA-Abstimmung (SLM-Verantwortung) + und Beziehungspflege (SHM-Verantwortung). + governance: + durchfuehrung: "SM (R), SPM (R)" + accountable: "SHM-L" + so_rolle: "C (bei Service-spezifischen Themen)" + referenz: "GOV-012, GOV-SHM-015" + + reporting_abgrenzung: + spm_berichtet: + - "Service-Qualität" + - "SLA-Erfüllung" + - "Service-Performance" + shm_berichtet: + - "Beziehungsqualität" + - "Bedarfserfüllung" + - "Stakeholder-Zufriedenheit" + keine_dopplung: true + referenz: "GOV-SHM-024" + + # ----------------------------------------------------------------------- + spm_ppm: + + name: "Schnittstelle SPM ↔ PPM" + status: "placeholder" + + beschreibung: | + Die Schnittstelle zu Projekt-Portfolio-Management (PPM) ist + in der aktuellen Phase nicht vollständig konzipiert. + + bekannte_beruehrungspunkte: + - "Projekt→Service-Übergabe (Ende Projektphase)" + - "Koordination bei Projekten mit Service-Impact" + - "Ressourcenallokation bei REDESIGN-Demands" + + offene_punkte: + - id: "OPEN-SPM-005" + beschreibung: "Bei PPM-Konzeption zu klären" + + verweis: "schnittstelle_spm-ppm.yaml (ausstehend)" + +# ============================================================================= +# ESKALATIONSLOGIK +# ============================================================================= + +eskalationslogik: + + beschreibung: | + Definition der Eskalationspfade für verschiedene Situationen. + Eskalation bedeutet die Weiterleitung einer Entscheidung oder eines + Themas an eine höhere Instanz. + + prinzip: | + Eskalation ist kein Zeichen von Versagen, sondern ein definierter + Governance-Mechanismus. Die Eskalationspflicht liegt bei der Rolle, + die die Grenzen ihrer Entscheidungskompetenz erkennt. + + pfade: + + # ------------------------------------------------------------------------- + - id: "ESK-SPM-01" + name: "SO → SOR (Review-Eskalation)" + + trigger: + - "Service-Review mit Empfehlung REDESIGN" + - "Service-Review mit Empfehlung RETIRE" + - "Service-Review mit ressourcenrelevantem IMPROVEMENT" + - "Mindestens eine Review-Dimension 'Rot'" + - "SO ist unsicher über Handlungsempfehlung" + + verfahren: | + SO reicht Review-Vorlage bei SPM ein (3 Arbeitstage vor SOR). + SPM prüft Vollständigkeit, setzt auf SOR-Agenda. + SOR entscheidet gemäß Behandlungskategorien. + + output: + - "Freigabe der Maßnahmen" + - "Freigabe mit Auflagen" + - "Zurückweisung" + - "Eskalation an MB" + + # ------------------------------------------------------------------------- + - id: "ESK-SPM-02" + name: "SO → SOR (Transition Gate 3 - Go-Live)" + + trigger: + - "Service-Transition erreicht Gate 3 (Go-Live-Entscheidung)" + - "Regulärer Lifecycle-Gate-3-Antrag (neue Services und Major Changes)" + + verfahren: | + SO reicht Transition-Steckbrief bei SPM ein. + SPM prüft Vollständigkeit, setzt auf SOR-Agenda. + SOR entscheidet: Go-Live / Auflagen / Zurück an Transition / Ablehnung. + + output: + - "Go-Live-Freigabe" + - "Freigabe mit Auflagen" + - "Zurück an Transition" + - "Eskalation an MB" + + # ------------------------------------------------------------------------- + - id: "ESK-SPM-03" + name: "SO → SPM (Cross-Service-Impact)" + + trigger: + - "Normal Change mit potenziellem Cross-Service-Impact" + - "SO-Unsicherheit über Auswirkungen auf andere Services" + + verfahren: | + SO informiert SPM über geplanten Change. + SPM prüft aus Portfolio-Perspektive. + Bei bestätigtem Cross-Service-Impact: Abstimmung mit betroffenen SOs. + + output: + - "Bestätigung: Kein relevanter Impact" + - "Koordinierter Change mit betroffenen SOs" + - "Hochstufung zu Major Change (SOR-Behandlung)" + + # ------------------------------------------------------------------------- + - id: "ESK-SPM-04" + name: "SOR → MB (Strategische Eskalation)" + + trigger: + - "Ressourcenkonflikt nicht in SOR lösbar" + - "Strategische Tragweite übersteigt SOR-Mandat" + - "Unauflösbarer Dissens in SOR" + - "Budget-relevante Portfolio-Entscheidungen" + + verfahren: | + SPM bereitet Eskalationsvorlage vor. + SOR-Protokoll dokumentiert Eskalationsgrund. + MB entscheidet. + + output: + - "MB-Entscheidung" + - "Rückverweis an SOR mit Vorgaben" + + # ------------------------------------------------------------------------- + - id: "ESK-SPM-05" + name: "SPM → MB (Portfolio-Eskalation)" + + trigger: + - "Portfolio-Review identifiziert systemische Probleme" + - "IMPROVE-ESCALATE (Resource) aus Portfolio-Review" + - "Mehrere RETIRE-Empfehlungen mit gemeinsamer Ursache" + + verfahren: | + SPM dokumentiert im Quartals- oder Jahres-Report. + E2-Eskalation: Via SOR an MB. + E1-Eskalation: Direkt im Jahres-Report an VB. + + output: + - "Strategische Maßnahmen" + - "Ressourcen-Reallokation" + - "Portfolio-Bereinigung" + +# ============================================================================= +# ENTSCHEIDUNGSMATRIX +# ============================================================================= + +entscheidungsmatrix: + + beschreibung: | + Vollständige Zuordnung von Entscheidungsgegenständen zu Rollen und + Gremien. Die Matrix folgt dem Subsidiaritätsprinzip (GP-SPM-01). + + legende: + A: "Accountable – trägt die Entscheidungsverantwortung" + R: "Responsible – führt aus / bereitet vor" + C: "Consulted – wird vor Entscheidung konsultiert" + I: "Informed – wird über Entscheidung informiert" + "-": "Nicht beteiligt" + + rollen: + SO: "Service Owner" + SPM: "Service-Portfolio-Manager" + SOR: "Service Operations Runde" + DSR: "Demand & Stakeholder-Runde" + MB: "Mission Board" + VB: "Vision Board" + DPM: "Demand-Portfolio-Manager" + SHM: "Stakeholder-Manager" + + # --------------------------------------------------------------------------- + # LIFECYCLE-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + lifecycle_entscheidungen: + + name: "Lifecycle-Entscheidungen" + beschreibung: "Entscheidungen im Service-Lebenszyklus" + + entscheidungen: + + - id: "E-LC-01" + gegenstand: "Gate 1 (Entry-Autorisierung) Freigabe" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "I" + VB: "-" + DPM: "-" + SHM: "-" + hinweis: "SOR autorisiert Entry in Transition (neue Services und Major Changes)" + referenz: "GOV-TR-011" + + - id: "E-LC-02" + gegenstand: "Pilot-Entscheidung (ja/nein)" + SO: "A/R" + SPM: "I" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + hinweis: "Kriterienbasiert, SO-Ermessen" + + - id: "E-LC-03" + gegenstand: "Gate 3 (Go-Live) Freigabe" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "I" + VB: "-" + DPM: "-" + SHM: "-" + hinweis: "SOR gibt Go-Live für produktiven Betrieb frei (neue Services und Major Changes)" + referenz: "GOV-TR-016" + + - id: "E-LC-04" + gegenstand: "ELS-Exit-Entscheidung" + SO: "A/R" + SPM: "I" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-TR-020" + + - id: "E-LC-05" + gegenstand: "Service-Review durchführen" + SO: "A/R" + SPM: "I" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-SR-002" + + - id: "E-LC-06" + gegenstand: "Review-Eskalation an SOR" + SO: "R" + SPM: "R (Agenda)" + SOR: "A" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-SR-004" + + - id: "E-LC-07" + gegenstand: "REDESIGN/RETIRE-Freigabe" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "I" + VB: "-" + DPM: "I" + SHM: "-" + referenz: "GOV-SR-004" + + # --------------------------------------------------------------------------- + # KATALOG-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + katalog_entscheidungen: + + name: "Katalog-Entscheidungen" + beschreibung: "Entscheidungen zu Service-Katalog und -Definitionen" + + entscheidungen: + + - id: "E-KA-01" + gegenstand: "Service-Definition erstellen" + SO: "A/R" + SPM: "C" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-007" + + - id: "E-KA-02" + gegenstand: "Service-Definition validieren" + SO: "R" + SPM: "A" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-007" + + - id: "E-KA-03" + gegenstand: "Redaktionelle Katalogänderung" + SO: "A/R" + SPM: "-" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-008" + + - id: "E-KA-04" + gegenstand: "Minor Katalogänderung" + SO: "R" + SPM: "A" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-008" + + - id: "E-KA-05" + gegenstand: "Major Katalogänderung" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-008" + + - id: "E-KA-06" + gegenstand: "Service-Kategorisierung (A/B/C)" + SO: "C" + SPM: "R" + SOR: "-" + DSR: "-" + MB: "A" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-001" + + - id: "E-KA-07" + gegenstand: "Kundenverständlichkeit prüfen" + SO: "R" + SPM: "A" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "C" + hinweis: "Im MVP optional" + referenz: "GOV-009" + + # --------------------------------------------------------------------------- + # CHANGE-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + change_entscheidungen: + + name: "Change-Entscheidungen" + beschreibung: "Entscheidungen zu Service-Änderungen" + + entscheidungen: + + - id: "E-CH-01" + gegenstand: "Change-Klassifizierung" + SO: "A/R" + SPM: "-" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + + - id: "E-CH-02" + gegenstand: "Standard Change-Modell genehmigen" + SO: "A/R" + SPM: "I" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + + - id: "E-CH-03" + gegenstand: "Normal Change freigeben" + SO: "A/R" + SPM: "C (bei Cross-Service)" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-CE-003" + + - id: "E-CH-04" + gegenstand: "Major Change freigeben" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + hinweis: "EIN Entscheidungspunkt: SOR-Autorisierung (inkl. Festlegung Einstiegspunkt). Danach regulärer Lifecycle." + referenz: "GOV-TR-003" + + - id: "E-CH-05" + gegenstand: "Emergency Change (Sofortumsetzung)" + SO: "I" + SPM: "-" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + hinweis: "Betrieb/Support führt aus, SO wird informiert" + referenz: "GOV-CE-001" + + # --------------------------------------------------------------------------- + # SLA-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + sla_entscheidungen: + + name: "SLA-Entscheidungen" + beschreibung: "Entscheidungen zu Service Level Agreements" + + entscheidungen: + + - id: "E-SL-01" + gegenstand: "SLS (Service Level Specification) erstellen" + SO: "A/R" + SPM: "C" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + + - id: "E-SL-02" + gegenstand: "Standard-SLA anwenden" + SO: "A/R" + SPM: "-" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + + - id: "E-SL-03" + gegenstand: "Individuelles SLA genehmigen" + SO: "R" + SPM: "R (Vorsitz)" + SOR: "A" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "-" + + - id: "E-SL-04" + gegenstand: "SLA-Eskalation behandeln" + SO: "R" + SPM: "C" + SOR: "-" + DSR: "-" + MB: "-" + VB: "-" + DPM: "-" + SHM: "I (bei Kundenrelevanz)" + referenz: "GOV-002" + + # --------------------------------------------------------------------------- + # PORTFOLIO-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + portfolio_entscheidungen: + + name: "Portfolio-Entscheidungen" + beschreibung: "Entscheidungen auf Portfolio-Ebene" + + entscheidungen: + + - id: "E-PF-01" + gegenstand: "Portfolio-Status bestätigen (E2)" + SO: "I" + SPM: "R" + SOR: "A" + DSR: "-" + MB: "I" + VB: "-" + DPM: "I" + SHM: "-" + referenz: "GOV-PR-002" + + - id: "E-PF-02" + gegenstand: "Portfolio-Report erstellen (E1)" + SO: "C" + SPM: "A/R" + SOR: "-" + DSR: "-" + MB: "I" + VB: "I" + DPM: "I" + SHM: "-" + referenz: "GOV-PR-002" + + - id: "E-PF-03" + gegenstand: "IMPROVE-ESCALATE (Resource)" + SO: "-" + SPM: "R" + SOR: "R" + DSR: "-" + MB: "A" + VB: "-" + DPM: "-" + SHM: "-" + referenz: "GOV-PR-004" + + - id: "E-PF-04" + gegenstand: "RETIRE-RECOMMEND (Portfolio-Ebene)" + SO: "C" + SPM: "R" + SOR: "A" + DSR: "-" + MB: "I" + VB: "-" + DPM: "I" + SHM: "-" + referenz: "GOV-PR-004" + +# ============================================================================= +# QUERVERWEIS GOVERNANCE-LOG +# ============================================================================= + +querverweis_governance_log: + + beschreibung: | + Mapping zwischen den Governance-Entscheidungen im Log und den + Abschnitten in diesem Framework. + + dokument: "spm_governance-entscheidungen-log.yaml" + + mapping: + + portfolio_governance: + - "GOV-001: Service-Kategorisierung" + - "GOV-002: SLA-Eskalationsmechanismus" + - "GOV-003: Interner vs. externer Review" + - "GOV-005: SLA-Partner = Entscheidungsbefugte" + - "GOV-006: SPM ist Practice Owner für SCM" + - "GOV-007: SO erstellt Service-Definition, SPM validiert" + - "GOV-008: Dreistufige Katalog-Governance" + - "GOV-009: SHM-Einbindung für Kundenverständlichkeit" + - "GOV-010: Trennung Inhalt (SPM) vs. Betrieb (Technik)" + - "GOV-011: Service-Kategorien (A/B/C)" + - "GOV-012: Integriertes Kundenforum" + + lifecycle_governance: + - "GOV-TR-011: Gate 1 = SOR-Entscheidung (Entry-Autorisierung)" + - "GOV-TR-012: Gate 2 = SO-Einzelentscheidung (Entry-Prüfung nach Build)" + - "GOV-TR-016: Gate 3 = SOR-Entscheidung (Go-Live-Freigabe)" + - "GOV-TR-003: Major Change = einmalige SOR-Autorisierung (danach regulärer Lifecycle)" + - "GOV-TR-010 bis GOV-TR-030: Transition-Details" + - "GOV-SR-001: Quartalsweiser Service-Review" + - "GOV-SR-002: SO accountable für Review" + - "GOV-SR-003: Orientierungskriterien mit Urteilsvorbehalt" + - "GOV-SR-004: Differenzierte SOR-Behandlung" + - "GOV-SR-005: Improvement via Service-Definition" + + change_governance: + - "GOV-CE-001: Emergency Changes" + - "GOV-CE-002: Scope (Service-Changes, nicht Infrastruktur)" + - "GOV-CE-003: Cross-Service-Impact" + + portfolio_review_governance: + - "GOV-PR-001: Datenbasis aus Service-Reviews" + - "GOV-PR-002: E1/E2-Struktur" + - "GOV-PR-003: Zeitliche Synchronisation" + - "GOV-PR-004: Entscheidungstypen Portfolio-Ebene" + - "GOV-PR-005: Aggregationslogik" + - "GOV-PR-006: Mapping Service-Review → Portfolio-Review" + - "GOV-PR-007: SOR-Agenda-Struktur" + + gremien_governance: + - "GOV-SOR-001: Routing-Klärung bilateral über Service Owner (aktualisiert per GOV-SHM-029)" + - "GOV-SOR-002: SPM = SOR-Vorsitz" + - "GOV-SOR-003: Koordination bei Dissens, kein Stichentscheid" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.1" + datum: "2026-02-19" + autor: "DIGITOM-Projekt" + aenderung: | + Major-Change-Governance vereinfacht (Kundenvorschlag): + - Change-Klassifizierung: "Transition erforderlich" → "SOR-Autorisierung erforderlich" + - Change Authority: "Entry + Gate 3" → "einmalige Autorisierung" + - SOR-Entscheidungstypen: "Entry + Go-Live" → "einmalig, inkl. Einstiegspunkt" + - Entscheidungsmatrix E-CH-04: zwei Entscheidungspunkte → ein Entscheidungspunkt + - Querverweis GOV-TR-003: angepasst + - Gate 1 Hinweis: reguläres Gate für alle Transition-Eintritte + - ESK-SPM-02 Trigger: angepasst + Konsistent mit spm_practice_change-enablement.yaml v1.3 + + - version: "1.0" + datum: "2025-12-17" + autor: "DIGITOM-Projekt" + aenderung: | + Initiale Erstellung durch Konsolidierung der SPM-Governance-Entscheidungen. + + Konsolidierte Quellen: + - spm_governance-entscheidungen-log.yaml (30+ GOV-IDs) + - rolle_service-owner.yaml + - rolle_service-portfolio-manager.yaml + - spm_sor_go.yaml + - spm_konzept_service-transition.yaml + - spm_konzept_service-review.yaml + - spm_konzept_service-portfolio-review.yaml + - spm_practice_change-enablement.yaml + + Struktur: + - 5 Governance-Prinzipien (GP-SPM-01 bis GP-SPM-05) + - 5 Entscheidungsdomänen + - 5 Eskalationspfade (ESK-SPM-01 bis ESK-SPM-05) + - 25 Entscheidungsgegenstände in Matrix + - 3 Schnittstellen (DPM, SHM, PPM-Placeholder) + + Explizit nicht im Scope: + - Service-Betrieb-Governance (spätere Phase) - Operations-Manager-Verantwortlichkeiten (spätere Phase) \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_konzept_service-portfolio-review.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_konzept_service-portfolio-review.yaml index 57d873d..cb6c9b7 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_konzept_service-portfolio-review.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_konzept_service-portfolio-review.yaml @@ -1,1591 +1,1591 @@ -# ============================================================================= -# SERVICE-PORTFOLIO REVIEW KONZEPT -# ============================================================================= - -metadata: - id: "G-PR" - name: "Service-Portfolio Review Konzept" - version: "1.0" - status: "draft" - erstellt: "2025-12-17" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "methodik" - - beschreibung: > - Definiert den strategischen Review-Zyklus für das gesamte Service-Portfolio. - Der Portfolio-Review aggregiert die Ergebnisse der Einzel-Service-Reviews - und ermöglicht eine übergreifende Steuerungsperspektive. Er folgt einem - zweistufigen Modell (E1/E2) konsistent mit der DIGITOM-Architektur. - - abgrenzung: - service_review: > - Das Konzept "Service-Review" (K-SR) fokussiert auf den einzelnen Service - aus operativer Perspektive. Der Service Owner bewertet seinen Service - quartalsweise anhand von 4 Dimensionen. - portfolio_review: > - Dieses Konzept fokussiert auf das Gesamtportfolio aus taktisch- - strategischer Perspektive. SPM aggregiert die Service-Review-Ergebnisse - und identifiziert übergreifende Muster. - - referenzen: - service_review_konzept: "02a_lifecycle-konzepte/konzept_service-review.yaml" - service_review_blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-review.yaml" - sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" - dpm_portfolio_review: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml" - shm_koordination: "#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml" - ssm_governance: "03_practices/spm_practice_service-support-management/ssm_governance.yaml" - - governance_entscheidungen: - - "GOV-PR-001 bis GOV-PR-007 (in diesem Dokument definiert)" - -# ============================================================================= -# 1. ZWECK UND FUNKTION -# ============================================================================= - -zweck_und_funktion: - - primaerer_zweck: | - Sicherstellung der Portfolio-Gesundheit durch regelmäßige Aggregation - und Bewertung der Service-Performance auf Portfolio-Ebene. Der Review - dient der Früherkennung von Risiken, der Identifikation von - Optimierungspotenzialen und der strategischen Rückkopplung. - - # --------------------------------------------------------------------------- - # FUNKTIONEN - # --------------------------------------------------------------------------- - - funktionen: - - - id: "F-01" - name: "Qualitätssicherung" - beschreibung: "Aggregierte Bewertung der Portfolio-Performance" - ebene: "E2" - konkretisierung: | - Zusammenführung der Service-Review-Ergebnisse zu einer - Portfolio-Gesamtsicht. Identifikation von Services mit - Handlungsbedarf und deren Anteil am Gesamtportfolio. - - - id: "F-02" - name: "Risiko-Früherkennung" - beschreibung: "Identifikation von Risiko-Clustern und Kapazitätsengpässen" - ebene: "E2" - konkretisierung: | - Erkennung von Mustern, die auf systemische Probleme hindeuten: - - Mehrere Services mit gleichartigen Problemen - - Ressourcenengpässe über Service-Grenzen hinweg - - Technologie-Cluster mit EOL-Risiko - - - id: "F-03" - name: "Strategische Rückkopplung" - beschreibung: "Input für übergeordnete Portfolio-Entscheidungen" - ebene: "E1" - konkretisierung: | - Jährliche Bewertung der Portfolio-Entwicklung und Ableitung - strategischer Empfehlungen für das Vision Board. - - # --------------------------------------------------------------------------- - # EXPLIZITE NICHT-FUNKTIONEN - # --------------------------------------------------------------------------- - - explizite_nicht_funktionen: - - - funktion: "Operative Einzelservice-Entscheidungen" - verweis: "Service-Review (K-SR), Aktivität sr_03" - begruendung: | - Entscheidungen zu CONTINUE, IMPROVEMENT, REDESIGN oder RETIRE - für einen einzelnen Service werden im Service-Review getroffen, - nicht im Portfolio-Review. - - - funktion: "Demand-Priorisierung" - verweis: "DPM-Portfolio-Review" - begruendung: | - Die Priorisierung von Demands erfolgt im DPM-Prozess. Der - SPM-Portfolio-Review liefert Input (Service-Impact), trifft - aber keine Demand-Entscheidungen. - - - funktion: "Strategiedefinition" - verweis: "Vision Board" - begruendung: | - Der Portfolio-Review liefert strategische Erkenntnisse als - Input für das Vision Board, definiert aber nicht selbst - die IT-Strategie. - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Der Portfolio-Review ist kein Ersatz für den operativen Service-Review - (sr_02/sr_03), sondern dessen Aggregation. Er erzeugt keine neuen - Service-Entscheidungen, sondern bewertet die Portfolio-Gesundheit - und eskaliert bei Bedarf. Die Zweistufigkeit (E1/E2) spiegelt die - etablierte DIGITOM-Governance-Architektur. - -# ============================================================================= -# 2. DATENBASIS -# ============================================================================= - -datenbasis: - - governance_referenz: "GOV-PR-001" - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Der Portfolio-Review arbeitet mit der verfügbaren Datenbasis und - akzeptiert Lücken explizit. Die Datenpunkte werden aus den Service- - Reviews abgeleitet, nicht separat erhoben. Dies vermeidet Doppelarbeit - und nutzt den bereits definierten Service-Review-Output. - - # --------------------------------------------------------------------------- - # DATENPUNKTE - # --------------------------------------------------------------------------- - - datenpunkte: - - beschreibung: | - Diese Datenpunkte werden je Service für den Portfolio-Review benötigt. - Sie werden aus dem Service-Review und der Service-Definition abgeleitet. - - punkte: - - - id: "DP-01" - name: "Service-Status" - typ: "Kategorie" - auspraegungen: - - "aktiv" - - "in_transition" - - "planned_eol" - - "retired" - quelle: "Service-Katalog" - mapping: "Direkte Übernahme aus Service-Katalog" - pflicht: true - - - id: "DP-02" - name: "Letzter Service-Review" - typ: "Datum" - quelle: "Service-Definition" - mapping: "Datum des letzten abgeschlossenen Service-Reviews" - pflicht: true - hinweis: "Falls kein Review stattgefunden hat: 'nie'" - - - id: "DP-03" - name: "Nutzungsintensität" - typ: "Kategorie" - auspraegungen: - - "hoch" - - "mittel" - - "niedrig" - - "unbekannt" - quelle: "Service-Review (SO-Einschätzung)" - mapping: "Übernahme aus Service-Review" - pflicht: true - - - id: "DP-04" - name: "Aktuelle Problemlage" - typ: "Ampel" - auspraegungen: - gruen: - label: "Stabil" - ableitung: "Alle Dimensionen Grün oder max. 1x Gelb im Service-Review" - gelb: - label: "Beobachten" - ableitung: "Mind. 2x Gelb oder 1x Rot ohne Handlungsbedarf im Service-Review" - rot: - label: "Handlungsbedarf" - ableitung: "Mind. 1x Rot mit Handlungsbedarf (IMPROVEMENT/REDESIGN/RETIRE)" - quelle: "Abgeleitet aus Service-Review-Dimensionen (SR-D1 bis SR-D4)" - mapping: | - Die Problemlage-Ampel aggregiert die 4 Service-Review-Dimensionen - zu einem Gesamtwert. Die Ableitung folgt der Aggregationslogik - im Service-Review-Konzept. - pflicht: true - - - id: "DP-05" - name: "Geplante Maßnahmen" - typ: "Strukturiert" - felder: - - name: "massnahmen_vorhanden" - typ: "boolean" - - name: "kurzbeschreibung" - typ: "string" - max_laenge: 200 - quelle: "Service-Steckbrief → Abschnitt 'Laufende Verbesserungen'" - mapping: "ja/nein + Kurztext der wichtigsten Maßnahme" - pflicht: true - - # --------------------------------------------------------------------------- - # QUALITATIVE ERGÄNZUNG - # --------------------------------------------------------------------------- - - qualitative_ergaenzung: - - beschreibung: | - Neben den strukturierten Datenpunkten kann der Service Owner eine - qualitative Einschätzung zur Gesamtsituation des Service geben. - Diese wird im Portfolio-Review bei Bedarf herangezogen. - - format: "Freitext (max. 500 Zeichen)" - inhalt: "Wesentliche Entwicklungen, Risiken, Chancen" - quelle: "Service-Definition → service_review" - pflicht: false - - # --------------------------------------------------------------------------- - # UMGANG MIT DATENLÜCKEN - # --------------------------------------------------------------------------- - - umgang_mit_datenluecken: - - prinzip: | - Fehlende Daten werden als "unbekannt" markiert, nicht geschätzt. - Services mit mehr als 2 unbekannten Datenpunkten werden im - Review explizit als "Daten-Gap" ausgewiesen. - - schwellenwert_portfolio: | - Bei systematischen Daten-Gaps (>30% der Services) wird dies - als eigener Review-Befund dokumentiert und führt zu - IMPROVE-ESCALATE mit Fokus auf Datenbasis-Verbesserung. - - eskalation: | - Wenn ein Service über 2 Quartale keinen Review hatte (DP-02), - wird dies im Portfolio-Review als Governance-Problem markiert - und an den betreffenden Service Owner bzw. SOR eskaliert. - -# ============================================================================= -# 3. GOVERNANCE-EINBETTUNG -# ============================================================================= - -governance_einbettung: - - governance_referenz: "GOV-PR-002" - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Der Service-Portfolio-Review ist kein eigenständiges Gremienformat, - sondern eine periodische Funktion, die in bestehenden Governance- - Strukturen ausgeübt wird. Die Zweistufigkeit (E1/E2) spiegelt die - etablierte DIGITOM-Architektur. - - # --------------------------------------------------------------------------- - # E2: QUARTALS-PORTFOLIO-REVIEW - # --------------------------------------------------------------------------- - - e2_portfolio_review: - - name: "SPM Quartals-Portfolio-Review" - - entscheidungstyp_referenz: "E2" - - format: "Erweiterter Agenda-Block in SOR" - - frequenz: "Quartalsweise" - - zeitpunkt: "T+10 bis T+12 nach Quartalsende" - - dauer: "45-60 Minuten (innerhalb regulärer SOR-Sitzung)" - - governance_anker: "SOR" - - # ------------------------------------------------------------------------- - teilnehmer: - - pflicht: - - rolle: "SPM" - funktion: "Leitung des Portfolio-Blocks, Präsentation" - - rolle: "SOR-Teilnehmer" - funktion: "Entscheidung, Diskussion" - - optional: - - rolle: "Service Owner" - funktion: "Bei Bedarf für Einzelthemen" - bedingung: "Wenn Service in SOR behandelt wird" - - # ------------------------------------------------------------------------- - input: - - - quelle: "Service Owner" - artefakt: "Aktualisierte Service-Steckbriefe" - inhalt: "Datenpunkte DP-01 bis DP-05 je Service" - deadline: "T+7" - - - quelle: "SSM / Support" - artefakt: "Support-KPIs (aggregiert)" - inhalt: "Incident-Trends, Problem-Cluster" - status: "Falls verfügbar" - - - quelle: "SHM" - artefakt: "VoC-Erkenntnisse" - inhalt: "Stakeholder-Feedback zu Services (Cluster D2)" - status: "Falls E2 vor Portfolio-Review abgeschlossen" - - # ------------------------------------------------------------------------- - output: - - - artefakt: "Portfolio-Status-Übersicht" - ziel: "Dokumentation, SOR-Protokoll" - inhalt: "Aggregierte Portfolio-Sicht, Ampel-Verteilung" - - - artefakt: "Identifizierte Handlungsbedarfe" - ziel: "SOR-Entscheidungen oder Eskalation" - inhalt: "Muster, Cluster-Probleme, Ressourcenkonflikte" - - - artefakt: "SPM-Input für DPM-Review" - ziel: "DPM-Portfolio-Review" - inhalt: "Service-Impact, Kapazitäts-Einschätzung" - - # ------------------------------------------------------------------------- - entscheidungsreichweite: - - direkt_in_sor: - - "Bestätigung Portfolio-Status (MAINTAIN)" - - "Priorisierung von übergreifenden Verbesserungsmaßnahmen" - - "Eskalationsempfehlung an MB formulieren" - - eskalation_an_mb: - - "Portfolio-strukturelle Entscheidungen (bei RETIRE-RECOMMEND für mehrere Services)" - - "Ressourcenkonflikte, die MB-Priorisierung erfordern" - - "Strategische Themen mit Budget-Implikation" - - # --------------------------------------------------------------------------- - # E1: JAHRES-PORTFOLIO-REPORT - # --------------------------------------------------------------------------- - - e1_portfolio_review: - - name: "SPM Jahres-Portfolio-Report" - - entscheidungstyp_referenz: "E1" - - format: "Bericht + Präsentation" - - frequenz: "Jährlich" - - zeitpunkt: "Q4, vor Vision-Board-Strategieplanung" - - governance_anker: "Vision Board (Input)" - - verantwortlich: "SPM" - - # ------------------------------------------------------------------------- - inhalt: - - - abschnitt: "Portfolio-Entwicklung" - beschreibung: "Jahres-Entwicklung des Service-Portfolios" - elemente: - - "Anzahl Services (Zu-/Abgänge)" - - "Ampel-Entwicklung über 4 Quartale" - - "Abgeschlossene Improvements und Retirements" - - - abschnitt: "Strategische Erkenntnisse" - beschreibung: "Muster und Trends mit strategischer Relevanz" - elemente: - - "Technologie-Trends (EOL, Modernisierungsbedarf)" - - "Kapazitäts-Entwicklung" - - "Stakeholder-Zufriedenheit (VoC-Aggregation)" - - - abschnitt: "Risiken und Chancen" - beschreibung: "Mittelfristige Portfolio-Risiken und -Chancen" - elemente: - - "Identifizierte Risiko-Cluster" - - "Konsolidierungspotenziale" - - "Strategische Lücken" - - - abschnitt: "Empfehlungen" - beschreibung: "Empfehlungen für Portfolio-Ausrichtung" - elemente: - - "Priorisierte Handlungsfelder" - - "Ressourcenbedarf-Prognose" - - "Alignment mit IT-Strategie" - - # ------------------------------------------------------------------------- - entscheidungsreichweite: | - Keine direkte Entscheidung. Der E1-Report liefert Input für - strategische Entscheidungen im Vision Board. Empfehlungen - werden dort diskutiert und ggf. in strategische Maßnahmen - überführt. - - # ------------------------------------------------------------------------- - zusaetzlich_pulse_update: - frequenz: "Halbjährlich" - zeitpunkt: "Q2" - umfang: "Kurzform (max. 2 Seiten)" - inhalt: "Wesentliche Entwicklungen seit Jahresbericht, Trendaktualisierung" - - # --------------------------------------------------------------------------- - # INTEGRATION IN DPM-REVIEW - # --------------------------------------------------------------------------- - - integration_dpm_review: - - beschreibung: | - SPM ist regulärer Teilnehmer im DPM-Portfolio-Review und liefert - dort die Service-Perspektive. Der SPM-Input basiert auf den - Erkenntnissen des E2-Portfolio-Reviews. - - spm_beitrag_im_dpm_review: - - - beitrag: "Service-Impact neuer Demands" - beschreibung: "Bewertung, wie geplante Demands das Portfolio beeinflussen" - - - beitrag: "Betriebsbereitschaft für geplante Übergaben" - beschreibung: "Einschätzung der Transition-Kapazität" - - - beitrag: "Portfolio-Kapazitäts-Einschätzung" - beschreibung: "Verfügbare Ressourcen für neue Services" - - sequenzierung: | - SPM E2 (SOR) findet vor dem DPM-Portfolio-Review statt, - damit konsolidierte SPM-Erkenntnisse verfügbar sind. - -# ============================================================================= -# 4. ZEITLICHE SYNCHRONISATION -# ============================================================================= - -zeitliche_synchronisation: - - governance_referenz: "GOV-PR-003" - - # --------------------------------------------------------------------------- - # VALIDIERUNGSHINWEIS - # --------------------------------------------------------------------------- - - validierungshinweis: - status: "Modellannahme" - beschreibung: | - Die folgenden Zeitfenster sind Modellannahmen basierend auf der - bestehenden DIGITOM-Architektur. Sie müssen in der Praxis durch - DIGIT validiert und ggf. angepasst werden. - validierung_durch: "DIGIT" - validierung_methode: "Pilotierung über 2 Quartale" - - # --------------------------------------------------------------------------- - # QUARTALS-ZYKLUS - # --------------------------------------------------------------------------- - - quartals_zyklus: - - beschreibung: | - Der Quartals-Zyklus definiert die zeitliche Abfolge der Review- - Aktivitäten nach Quartalsende. T+n bezeichnet den n-ten Arbeitstag - nach dem letzten Tag des Quartals. - - phasen: - - - phase: 1 - name: "Service-Reviews durchführen" - zeitfenster: "T+1 bis T+7" - verantwortlich: "Alle Service Owner" - aktivitaeten: - - "SO führt quartalsweisen Selbst-Review durch" - - "Bewertung der 4 Dimensionen (SR-D1 bis SR-D4)" - - "Ableitung der Handlungsempfehlung" - - "Aktualisierung des Service-Steckbriefs" - output: "Aktualisierte Service-Steckbriefe" - deadline: "T+7 (Ende erste Woche)" - - - phase: 2 - name: "SPM-Aggregation und Vorbereitung" - zeitfenster: "T+8 bis T+10" - verantwortlich: "SPM" - aktivitaeten: - - "Sammlung aller Service-Steckbriefe" - - "Extraktion der Datenpunkte (DP-01 bis DP-05)" - - "Erstellung der Portfolio-Status-Übersicht" - - "Identifikation von Mustern und Auffälligkeiten" - - "Vorbereitung der SOR-Vorlage" - output: "Portfolio-Status-Übersicht, SOR-Vorlage" - - - phase: 3 - name: "SOR mit Portfolio-Block (E2)" - zeitfenster: "T+10 bis T+12" - verantwortlich: "SOR" - aktivitaeten: - - "Präsentation Portfolio-Status durch SPM" - - "Behandlung von Service-Reviews mit SOR-Bedarf" - - "Portfolio-Entscheidungen (MAINTAIN/IMPROVE-ESCALATE/RETIRE-RECOMMEND)" - - "Bestätigung des Portfolio-Status" - output: "SOR-Protokoll, bestätigter Portfolio-Status" - - - phase: 4 - name: "DPM-Portfolio-Review" - zeitfenster: "T+12 bis T+14" - verantwortlich: "AL Planung" - aktivitaeten: - - "SPM bringt Portfolio-Erkenntnisse ein" - - "Demand-Portfolio-Review gemäß DPM-Framework" - input: "SPM-Erkenntnisse aus E2" - - # --------------------------------------------------------------------------- - # SYNCHRONISATION MIT ANDEREN FORMATEN - # --------------------------------------------------------------------------- - - synchronisation_andere_formate: - - shm_e2: - format: "SHM Quartals-Review" - zeitfenster: "T+1 bis T+7 (parallel zu Service-Reviews)" - beziehung: | - SHM E2 liefert VoC-Erkenntnisse (Cluster D2: Service-Qualität), - die in Service-Reviews einfließen können. Wenn SHM E2 vor dem - jeweiligen Service-Review abgeschlossen ist, kann der SO die - VoC-Signale in seine Bewertung einbeziehen. - - ssm_quartals_review: - format: "SSM Quartals-Review" - zeitfenster: "Idealerweise T+1 bis T+5" - beziehung: | - Der SSM-Quartals-Review liefert Support-Perspektive (Incident- - Trends, Problem-Cluster), die in die Service-Review-Dimension - SR-D2 (Betriebsstabilität) einfließt. Empfehlung: SSM-Review - vor den meisten Service-Reviews abschließen. - - # --------------------------------------------------------------------------- - # JAHRES-ZYKLUS - # --------------------------------------------------------------------------- - - jahres_zyklus: - - beschreibung: | - Der Jahres-Zyklus definiert die E1-Aktivitäten und deren - Einbettung in die DIGIT-Strategieplanung. - - aktivitaeten: - - - zeitpunkt: "Q2 (ca. KW 26-28)" - name: "Halbjahres-Pulse-Update" - verantwortlich: "SPM" - output: "Kurzform Portfolio-Update für Vision Board" - - - zeitpunkt: "Q4 (ca. KW 45-48)" - name: "Jahres-Portfolio-Report erstellen" - verantwortlich: "SPM" - output: "SPM Jahres-Portfolio-Report" - - - zeitpunkt: "Q4 (vor Vision-Board-Strategiesitzung)" - name: "E1-Input für Vision Board" - verantwortlich: "SPM" - output: "Präsentation strategischer Erkenntnisse und Empfehlungen" - -# ============================================================================= -# 5. ENTSCHEIDUNGSTYPEN -# ============================================================================= - -entscheidungstypen: - - governance_referenz: "GOV-PR-004" - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Der Portfolio-Review trifft selbst nur eine Entscheidung: MAINTAIN. - Alle anderen Ergebnisse sind Empfehlungen oder Eskalationen, die - in anderen Governance-Strukturen entschieden werden. Dies vermeidet - Doppelstrukturen und respektiert die bestehende Entscheidungsarchitektur. - - # --------------------------------------------------------------------------- - # MAINTAIN - # --------------------------------------------------------------------------- - - typen: - - - id: "PR-MAINTAIN" - name: "MAINTAIN" - - beschreibung: | - Das Portfolio befindet sich in einem akzeptablen Zustand. - Die aggregierten Service-Reviews zeigen keine systematischen - Probleme. Keine Portfolio-Ebenen-Aktion erforderlich. - - entscheidungstraeger: "SOR (im Rahmen des E2-Reviews)" - - kriterien: - - "Keine oder nur einzelne Services mit roter Ampel (DP-04)" - - "Keine systematischen Daten-Gaps (< 30% der Services)" - - "Keine offenen IMPROVE-ESCALATE oder RETIRE-RECOMMEND aus Vorquartal" - - "Keine erkennbaren Muster, die übergreifende Aktion erfordern" - - output: - - artefakt: "Portfolio-Status-Bestätigung" - ort: "SOR-Protokoll" - - folgeprozess: null - - naechster_review: "Nächstes Quartal (E2)" - - # ------------------------------------------------------------------------- - # IMPROVE-ESCALATE - # ------------------------------------------------------------------------- - - - id: "PR-IMPROVE-ESCALATE" - name: "IMPROVE-ESCALATE" - - beschreibung: | - Handlungsbedarf auf Portfolio-Ebene erkannt. Dies kann sein: - - Mehrere Services mit gleichartigen Problemen (Muster) - - Ressourcenengpässe, die mehrere Services betreffen - - Strukturelle Verbesserungspotenziale - - Der Review identifiziert und dokumentiert, entscheidet aber nicht - über die Maßnahme selbst. - - entscheidungstraeger: "SOR (Identifikation), Weiterleitung an zuständige Stelle" - - # ----------------------------------------------------------------------- - varianten: - - - id: "PR-IMPROVE-ESCALATE-OPERATIONAL" - name: "Operative Eskalation" - - beschreibung: | - Handlungsbedarf, der durch koordinierte Aktion der betroffenen - Service Owner adressiert werden kann. - - beispiele: - - "Gemeinsame Dokumentationslücken in mehreren Services" - - "Wiederkehrende Schulungsbedarfe" - - "Prozess-Inkonsistenzen zwischen Services" - - weiterleitung: "Betroffene Service Owner (koordiniert durch SPM)" - - folgeprozess: "Service Improvement (sr_04) in betroffenen Services" - - - id: "PR-IMPROVE-ESCALATE-STRUCTURAL" - name: "Strukturelle Eskalation" - - beschreibung: | - Handlungsbedarf, der Demand-Charakter hat (Budget, Projektaufwand, - übergreifende Architektur-Entscheidung). - - beispiele: - - "Mehrere Services benötigen Technologie-Migration" - - "Gemeinsame Infrastruktur-Komponente muss erneuert werden" - - "Konsolidierungspotenzial bei überlappenden Services" - - weiterleitung: "DPM zur Demand-Erfassung" - - folgeprozess: "Demand-Lifecycle" - - - id: "PR-IMPROVE-ESCALATE-RESOURCE" - name: "Ressourcen-Eskalation" - - beschreibung: | - Kapazitätsengpässe, die MB-Entscheidung erfordern, weil sie - Priorisierung zwischen konkurrierenden Bedarfen erfordern. - - beispiele: - - "Mehrere ressourcenrelevante Improvements konkurrieren" - - "Betriebskapazität reicht nicht für Portfolio-Umfang" - - "Skill-Engpass bei kritischer Technologie" - - weiterleitung: "Mission Board" - - folgeprozess: "MB-Entscheidung zur Ressourcenallokation" - - # ----------------------------------------------------------------------- - kriterien: - - "Mehrere Services mit gelber oder roter Ampel (Muster erkennbar)" - - "Wiederkehrende Themen aus Service-Reviews (> 3 Services betroffen)" - - "Kapazitäts-Gap zwischen Anforderungen und Verfügbarkeit" - - "Systematische Daten-Gaps (> 30% der Services)" - - output: - - artefakt: "Eskalations-Empfehlung" - inhalt: - - "Identifiziertes Muster/Problem" - - "Betroffene Services" - - "Empfohlene Maßnahme oder Demand-Skizze" - - "Adressat der Eskalation" - - "Begründung" - - # ------------------------------------------------------------------------- - # RETIRE-RECOMMEND - # ------------------------------------------------------------------------- - - - id: "PR-RETIRE-RECOMMEND" - name: "RETIRE-RECOMMEND" - - beschreibung: | - Empfehlung zur Stilllegung eines oder mehrerer Services. - Der Portfolio-Review aggregiert Signale aus Service-Reviews - (RETIRE-Empfehlungen) und formuliert eine konsolidierte - Empfehlung an das MB. - - Die Entscheidung zur Stilllegung liegt beim MB wegen - Ressourcen- und Kundenimplikationen. - - entscheidungstraeger: "SOR (Empfehlung), MB (Entscheidung)" - - kriterien: - - "Service-Review-Ergebnis: RETIRE (sr_06) für einen oder mehrere Services" - - "Niedrige Nutzungsintensität (DP-03) über mehrere Quartale" - - "Hoher Betriebsaufwand bei geringem dokumentiertem Nutzen" - - "Technische Überalterung ohne wirtschaftlichen Migrationsweg" - - "Funktionalität wird durch anderen Service abgedeckt (Dopplung)" - - output: - - artefakt: "Stilllegungs-Empfehlung" - inhalt: - - "Betroffene Services" - - "Begründung je Service" - - "Grobe Impact-Einschätzung (Nutzer, Abhängigkeiten)" - - "Vorgeschlagener Zeitrahmen" - - "Ggf. Migrationshinweise" - - folgeprozess: "MB-Entscheidung → ggf. Retirement-Projekt via DPM" - - # --------------------------------------------------------------------------- - # EXPLIZIT NICHT-ENTSCHEIDUNGSTYPEN - # --------------------------------------------------------------------------- - - explizit_nicht_entscheidungstypen: - - beschreibung: | - Die folgenden Entscheidungstypen aus klassischen Portfolio-Management- - Frameworks werden bewusst NICHT als Portfolio-Review-Entscheidungen - modelliert, da sie entweder Demand-Charakter haben oder auf anderer - Ebene entschieden werden. - - typen: - - - id: "EXPAND" - name: "Portfolio erweitern" - begruendung: | - Neue Services entstehen durch den Demand-Lifecycle, nicht durch - Portfolio-Review-Entscheidung. Der Review kann Lücken identifizieren - (als IMPROVE-ESCALATE-STRUCTURAL), aber die Entscheidung zur - Erweiterung ist ein Demand. - alternativer_pfad: "Demand → DPM → DSR/MB → Projekt → Service-Entwicklung" - - - id: "TRANSFORM" - name: "Portfolio transformieren" - begruendung: | - Grundlegende Neuausrichtung hat strategischen Charakter und - Demand-Implikationen. Gehört in den Vision-Board-Strategieprozess, - nicht in den operativen Portfolio-Review. Der E1-Report kann - Transformationsbedarf als Erkenntnis dokumentieren. - alternativer_pfad: "E1-Report → Vision Board → Strategische Initiative" - - - id: "CONSOLIDATE" - name: "Services konsolidieren" - begruendung: | - Konsolidierung (Zusammenführung von Services) ist ein Projekt - mit Demand-Charakter. Der Review kann Konsolidierungspotenzial - identifizieren (als IMPROVE-ESCALATE-STRUCTURAL), aber die - Umsetzung läuft über DPM. - alternativer_pfad: "IMPROVE-ESCALATE-STRUCTURAL → DPM → Konsolidierungsprojekt" - -# ============================================================================= -# 6. AGGREGATIONSLOGIK -# ============================================================================= - -aggregationslogik: - - governance_referenz: "GOV-PR-005" - - # --------------------------------------------------------------------------- - # GRUNDSATZ - # --------------------------------------------------------------------------- - - grundsatz: | - Der SPM bewertet das Portfolio-Gesamtbild anhand der aggregierten - Service-Daten. Es gibt keine mathematische Formel, aber - Orientierungskriterien für die Ableitung des Portfolio-Status. - Die Logik ist konsistent mit dem Service-Review-Konzept, das - ebenfalls Orientierungskriterien mit Urteilsvorbehalt nutzt. - - # --------------------------------------------------------------------------- - # ORIENTIERUNGSKRITERIEN - # --------------------------------------------------------------------------- - - orientierungskriterien: - - - id: "AK-01" - konstellation: "Alle Services Grün oder Gelb, keine offenen Handlungsbedarfe" - typische_empfehlung: "MAINTAIN" - erklaerung: | - Das Portfolio ist stabil. Einzelne Gelb-Bewertungen sind normal - und werden im Service-Review adressiert. - - - id: "AK-02" - konstellation: "Einzelne Services mit IMPROVEMENT (SO-geführt)" - typische_empfehlung: "MAINTAIN" - erklaerung: | - SO-geführte Improvements sind Routine und erfordern keine - Portfolio-Aktion. Die Services werden operativ betreut. - - - id: "AK-03" - konstellation: "Mehrere Services mit gleichartigem Problem-Muster" - typische_empfehlung: "IMPROVE-ESCALATE" - erklaerung: | - Ein Muster (z.B. 3+ Services mit Performance-Problemen wegen - gemeinsamer Infrastruktur) deutet auf systemisches Problem hin, - das übergreifend adressiert werden muss. - variante: "OPERATIONAL wenn koordinierte SO-Aktion reicht, STRUCTURAL wenn Demand nötig" - - - id: "AK-04" - konstellation: "Ressourcenkonflikte zwischen mehreren Improvement-Vorhaben" - typische_empfehlung: "IMPROVE-ESCALATE-RESOURCE" - erklaerung: | - Wenn mehrere ressourcenrelevante Improvements um dieselben - Ressourcen konkurrieren, muss MB priorisieren. - - - id: "AK-05" - konstellation: "Services mit RETIRE-Empfehlung aus Service-Review" - typische_empfehlung: "RETIRE-RECOMMEND" - erklaerung: | - RETIRE-Empfehlungen aus Service-Reviews werden auf Portfolio-Ebene - aggregiert und als konsolidierte Empfehlung an MB weitergeleitet. - - - id: "AK-06" - konstellation: "Systematische Daten-Gaps (> 30% der Services)" - typische_empfehlung: "IMPROVE-ESCALATE-OPERATIONAL" - erklaerung: | - Fehlende Daten sind ein Governance-Problem, das adressiert werden - muss. Fokus auf Verbesserung der Review-Durchführung. - - # --------------------------------------------------------------------------- - # URTEILSVORBEHALT - # --------------------------------------------------------------------------- - - urteilsvorbehalt: | - Diese Orientierungskriterien ersetzen nicht das Urteil des SPM. - Bei Abweichung von der typischen Konstellation ist eine kurze - Begründung im Review-Protokoll erforderlich. Der SPM berücksichtigt - den Gesamtkontext, der in den Kriterien nicht vollständig abbildbar ist. - - # --------------------------------------------------------------------------- - # BEGRUENDUNGSPFLICHT - # --------------------------------------------------------------------------- - - begruendungspflicht: - - wann: "Bei Abweichung von typischer Konstellation" - - form: "Kurze schriftliche Begründung im Portfolio-Review-Protokoll (2-3 Sätze)" - - beispiele: - - - situation: "Mehrere Services Rot, aber Empfehlung MAINTAIN" - begruendung_beispiel: | - "Obwohl 4 Services rot bewertet sind, empfehle ich MAINTAIN, weil - alle 4 bereits laufende Improvement-Maßnahmen haben, die im - nächsten Quartal wirksam werden sollen. Kein zusätzlicher - Portfolio-Handlungsbedarf." - - - situation: "Alle Services Grün, aber Empfehlung IMPROVE-ESCALATE" - begruendung_beispiel: | - "Trotz stabiler Ampel-Bewertungen empfehle ich IMPROVE-ESCALATE, - weil die Datenbasis in 8 von 20 Services 'unbekannt' enthält. - Wir brauchen eine konzertierte Aktion zur Review-Qualität." - -# ============================================================================= -# 7. ENTSCHEIDUNGSTYPEN-MAPPING -# ============================================================================= - -entscheidungstypen_mapping: - - governance_referenz: "GOV-PR-006" - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Service-Review-Entscheidungen beziehen sich auf einen einzelnen Service. - Portfolio-Review-Entscheidungen beziehen sich auf das Gesamtportfolio - oder Cluster von Services. Die Begriffe sind bewusst unterschiedlich, - um die Ebenen zu trennen. - - # --------------------------------------------------------------------------- - # MAPPING-TABELLE - # --------------------------------------------------------------------------- - - mapping: - - - service_review_entscheidung: "CONTINUE" - portfolio_aggregation: "Beitrag zu MAINTAIN" - erklaerung: | - Einzelne CONTINUE-Ergebnisse aggregieren zu MAINTAIN auf - Portfolio-Ebene, wenn keine Muster erkennbar sind. - - - service_review_entscheidung: "IMPROVEMENT (SO-geführt)" - portfolio_aggregation: "Beitrag zu MAINTAIN" - erklaerung: | - SO-geführte Improvements sind Routine und erfordern keine - Portfolio-Aktion. Der Service wird operativ betreut. - - - service_review_entscheidung: "IMPROVEMENT (ressourcenrelevant)" - portfolio_aggregation: "Einzelfall: SOR-Entscheidung. Mehrfach: Ggf. IMPROVE-ESCALATE-RESOURCE" - erklaerung: | - Ein einzelnes ressourcenrelevantes Improvement wird in der SOR - als Service-Review-Entscheidung behandelt. Wenn mehrere solche - Improvements Kapazitätskonflikte erzeugen, wird dies auf - Portfolio-Ebene als Ressourcen-Eskalation behandelt. - - - service_review_entscheidung: "REDESIGN" - portfolio_aggregation: "Einzelfall: DPM via SOR. Muster: IMPROVE-ESCALATE-STRUCTURAL" - erklaerung: | - Ein einzelnes REDESIGN ist eine Service-Entscheidung, die nach - SOR-Freigabe an DPM übergeht. Mehrere REDESIGN-Fälle mit - gemeinsamer Ursache sind ein Portfolio-Muster. - - - service_review_entscheidung: "RETIRE" - portfolio_aggregation: "RETIRE-RECOMMEND" - erklaerung: | - RETIRE-Empfehlungen aus Service-Reviews werden auf Portfolio-Ebene - aggregiert und als konsolidierte Empfehlung an MB weitergeleitet. - - # --------------------------------------------------------------------------- - # BEGRIFFLICHE ABGRENZUNG - # --------------------------------------------------------------------------- - - begriffliche_abgrenzung: - - - begriffspaar: "CONTINUE vs. MAINTAIN" - service_ebene: "CONTINUE = Einzelservice-Status ('dieser Service läuft weiter')" - portfolio_ebene: "MAINTAIN = Portfolio-Status ('das Portfolio ist stabil')" - - - begriffspaar: "IMPROVEMENT vs. IMPROVE-ESCALATE" - service_ebene: "IMPROVEMENT = Maßnahme für einen Service" - portfolio_ebene: "IMPROVE-ESCALATE = Handlungsbedarf auf Portfolio-Ebene (Muster, Ressourcen)" - - - begriffspaar: "RETIRE vs. RETIRE-RECOMMEND" - service_ebene: "RETIRE = SOR-Entscheidung für Einzelservice (führt zu DPM)" - portfolio_ebene: "RETIRE-RECOMMEND = Portfolio-Empfehlung an MB (ggf. mehrere Services)" - -# ============================================================================= -# 8. SOR-AGENDA-STRUKTUR -# ============================================================================= - -sor_agenda_struktur: - - governance_referenz: "GOV-PR-007" - - # --------------------------------------------------------------------------- - # DESIGN-PRINZIP - # --------------------------------------------------------------------------- - - design_prinzip: | - Der Portfolio-Review-Block (E2) und die Service-Review-Behandlungen - finden in derselben SOR-Sitzung statt, aber in definierter Reihenfolge. - Die Portfolio-Perspektive rahmt die Einzelentscheidungen. - - # --------------------------------------------------------------------------- - # EMPFOHLENE AGENDA-SEQUENZ - # --------------------------------------------------------------------------- - - empfohlene_agenda_sequenz: - - - block: 1 - name: "Portfolio-Status-Überblick" - dauer: "15 Minuten" - verantwortlich: "SPM" - inhalt: - - "Präsentation der aggregierten Portfolio-Sicht" - - "Ampel-Verteilung und Trends" - - "Identifizierte Muster und Auffälligkeiten" - - "Vorschau auf anstehende Einzelentscheidungen" - output: "Kontext für Einzelentscheidungen" - - - block: 2 - name: "Service-Review-Entscheidungen" - dauer: "Variable (abhängig von Anzahl)" - verantwortlich: "Betroffene Service Owner" - inhalt: - - "Behandlung einzelner Services mit SOR-Bedarf" - - "IMPROVEMENT (ressourcenrelevant)" - - "REDESIGN" - - "RETIRE" - output: "SOR-Beschlüsse je Service" - verweis: "Behandlungskategorien gemäß K-SR" - - - block: 3 - name: "Portfolio-Entscheidungen" - dauer: "15-20 Minuten" - verantwortlich: "SPM" - inhalt: - - "Übergreifende Muster aus Block 1 und 2" - - "IMPROVE-ESCALATE-Empfehlungen" - - "RETIRE-RECOMMEND (bei mehreren Services)" - - "Ressourcen-Eskalationen an MB" - output: "Portfolio-Entscheidungen, Eskalationsempfehlungen" - - - block: 4 - name: "Portfolio-Status-Bestätigung" - dauer: "5 Minuten" - verantwortlich: "SOR (Gremium)" - inhalt: - - "Formale Bestätigung des Portfolio-Status" - - "MAINTAIN oder Eskalation" - output: "Bestätigter Portfolio-Status im Protokoll" - - # --------------------------------------------------------------------------- - # BEI ÜBERLAPPUNG - # --------------------------------------------------------------------------- - - bei_ueberlappung: - - beschreibung: | - Wenn Service-Review-Entscheidungen (Block 2) ein Muster ergeben, - das im Portfolio-Block (Block 3) adressiert werden sollte, - verschiebt SPM die Einzelentscheidungen in Block 3 und behandelt - sie als Portfolio-Thema. - - beispiel: | - 3 Services haben RETIRE-Empfehlung wegen gemeinsamer Technologie-EOL. - → Nicht 3 Einzelentscheidungen in Block 2, sondern eine - Portfolio-Entscheidung "RETIRE-RECOMMEND für Technologie-X-Cluster" - in Block 3. - - entscheidungskriterium: | - SPM entscheidet bei der Agenda-Vorbereitung, ob Einzelthemen - als Cluster behandelt werden. Kriterium: Gemeinsame Ursache - oder gemeinsamer Lösungsansatz. - -# ============================================================================= -# 9. OUTPUT-ARTEFAKTE -# ============================================================================= - -output_artefakte: - - entwicklungshinweis: - status: "Arbeitsmaterialien erforderlich" - beschreibung: | - Für die praktische Umsetzung müssen Arbeitsmaterialien (Templates, - Checklisten) entwickelt werden. Die folgenden Strukturen definieren - den inhaltlichen Rahmen. - zu_entwickeln: - - "Template: SPM Quartals-Portfolio-Status" - - "Template: SPM Jahres-Portfolio-Report" - - "Checkliste: Portfolio-Review-Vorbereitung" - - "Vorlage: SOR-Protokoll-Abschnitt Portfolio-Review" - - # --------------------------------------------------------------------------- - # E2: PORTFOLIO-STATUS-ÜBERSICHT - # --------------------------------------------------------------------------- - - e2_portfolio_status_uebersicht: - - name: "SPM Quartals-Portfolio-Status" - - umfang: "1-2 Seiten" - - frequenz: "Quartalsweise" - - verantwortlich: "SPM" - - struktur: - - - abschnitt: "1. Portfolio-Übersicht" - inhalt: - - element: "Anzahl Services nach Status" - detail: "aktiv, in_transition, planned_eol, retired" - - element: "Ampel-Verteilung" - detail: "Anzahl/Prozent grün, gelb, rot" - - element: "Trend gegenüber Vorquartal" - detail: "Verbesserung, stabil, Verschlechterung" - - element: "Services mit Handlungsbedarf" - detail: "Liste der rot bewerteten Services" - - - abschnitt: "2. Auffälligkeiten und Muster" - inhalt: - - element: "Identifizierte Cluster-Probleme" - detail: "Mehrere Services mit gleichartigem Problem" - - element: "Ressourcenengpässe" - detail: "Kapazitätskonflikte, Skill-Gaps" - - element: "Daten-Gaps" - detail: "Services ohne Review, unvollständige Daten" - - - abschnitt: "3. Portfolio-Empfehlung" - inhalt: - - element: "Portfolio-Status" - detail: "MAINTAIN / IMPROVE-ESCALATE / RETIRE-RECOMMEND" - - element: "Begründung" - detail: "Kurze Erläuterung der Empfehlung" - - element: "Ggf. Eskalationen" - detail: "An MB weiterzuleitende Themen" - - - abschnitt: "4. Input für DPM-Review" - inhalt: - - element: "Service-Impact geplanter Demands" - detail: "Bewertung aus Portfolio-Perspektive" - - element: "Kapazitäts-Einschätzung" - detail: "Verfügbarkeit für neue Services/Projekte" - - element: "Transition-Pipeline" - detail: "Services in Transition, geplante Go-Lives" - - # --------------------------------------------------------------------------- - # E1: JAHRES-PORTFOLIO-REPORT - # --------------------------------------------------------------------------- - - e1_jahresbericht: - - name: "SPM Jahres-Portfolio-Report" - - umfang: "3-5 Seiten + Anhang" - - frequenz: "Jährlich (Q4)" - - verantwortlich: "SPM" - - struktur: - - - abschnitt: "Executive Summary" - umfang: "0.5 Seiten" - inhalt: - - "Zentrale Erkenntnisse des Jahres" - - "Top-3-Empfehlungen" - - - abschnitt: "Portfolio-Entwicklung im Jahresverlauf" - umfang: "1 Seite" - inhalt: - - "Anzahl Services (Zu-/Abgänge)" - - "Ampel-Entwicklung über 4 Quartale (Grafik)" - - "Abgeschlossene Improvements" - - "Durchgeführte Retirements" - - - abschnitt: "Strategische Erkenntnisse" - umfang: "1 Seite" - inhalt: - - "Technologie-Trends (EOL, Modernisierungsbedarf)" - - "Kapazitäts-Entwicklung und -Prognose" - - "Stakeholder-Zufriedenheit (VoC-Aggregation, falls verfügbar)" - - "Governance-Wirksamkeit (Review-Durchführungsquote)" - - - abschnitt: "Risiken und Chancen" - umfang: "0.5 Seiten" - inhalt: - - "Identifizierte Risiko-Cluster" - - "Konsolidierungspotenziale" - - "Strategische Lücken" - - - abschnitt: "Empfehlungen für Strategie" - umfang: "0.5-1 Seite" - inhalt: - - "Priorisierte Handlungsfelder" - - "Ressourcenbedarf-Prognose" - - "Empfehlungen für IT-Strategie / Vision Board" - - - anhang: "Detail-Daten je Service" - umfang: "Variable" - inhalt: - - "Tabelle aller Services mit Jahres-Bewertung" - - "Maßnahmen-Übersicht" - - detail_struktur_status: "Post-MVP zu detaillieren" - -# ============================================================================= -# 10. ABGRENZUNGEN -# ============================================================================= - -abgrenzungen: - - # --------------------------------------------------------------------------- - # SSM QUARTALS-REVIEW - # --------------------------------------------------------------------------- - - ssm_quartals_review: - - dokument: "ssm_governance.yaml" - - ssm_fokus: "Support-Performance (Incident, Request, Problem)" - ssm_perspektive: "Operativ-taktisch" - ssm_teilnehmer: "Support-Organisation + Service Owner" - ssm_output: "Support-Verbesserungen, Prozess-Anpassungen" - - spm_fokus: "Portfolio-Gesundheit (Service-Performance aggregiert)" - spm_perspektive: "Taktisch-strategisch" - spm_teilnehmer: "SOR-Teilnehmer + SPM" - spm_output: "Portfolio-Status, Eskalationen" - - beziehung: | - Der SSM-Quartals-Review liefert Support-Perspektive, die in - Service-Reviews (Dimension SR-D2: Betriebsstabilität) einfließt. - Der SPM-Portfolio-Review nutzt die aggregierten Service-Review- - Ergebnisse. Keine direkte Abhängigkeit, aber inhaltliche Verknüpfung - über die Service-Ebene. - - sequenz_empfehlung: | - SSM-Quartals-Review idealerweise vor Service-Reviews abschließen, - damit Support-Erkenntnisse in die Service-Bewertung (SR-D2) - einfließen können. - - # --------------------------------------------------------------------------- - # DPM-PORTFOLIO-REVIEW - # --------------------------------------------------------------------------- - - dpm_portfolio_review: - - dokument: "dpm_demand-portfolio-review.yaml" - - dpm_fokus: "Demand-Dynamik, Priorisierung, Workflow-Optimierung" - dpm_perspektive: "Demand-Steuerung" - - spm_fokus: "Service-Portfolio-Gesundheit" - spm_perspektive: "Service-Steuerung" - - beziehung: | - SPM ist Teilnehmer im DPM-Portfolio-Review und liefert die - Service-Perspektive. Die Reviews sind komplementär, nicht - konkurrierend. Der SPM E2 findet vor dem DPM-Review statt, - damit Erkenntnisse einfließen können. - - informationsfluss: - von_spm_zu_dpm: - - "Service-Impact neuer Demands" - - "Betriebsbereitschaft für Übergaben" - - "Portfolio-Kapazitäts-Einschätzung" - von_dpm_zu_spm: - - "Geplante Service-Neueinführungen" - - "Demand-Trends mit Service-Relevanz" - -# ============================================================================= -# 11. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - # --------------------------------------------------------------------------- - # INPUT-SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - input: - - - quelle: "Service Owner" - was: "Service-Review-Ergebnisse" - artefakt: "Aktualisierte Service-Steckbriefe" - frequenz: "Quartalsweise" - deadline: "T+7 nach Quartalsende" - pflicht: true - - - quelle: "SSM / Support" - was: "Support-KPIs (aggregiert)" - artefakt: "Support-Auswertung" - frequenz: "Quartalsweise" - hinweis: "Falls SSM-Quartals-Review vor Service-Reviews abgeschlossen" - pflicht: false - - - quelle: "SHM" - was: "VoC-Erkenntnisse" - artefakt: "Cluster D2 (Service-Qualität)" - frequenz: "Quartalsweise" - hinweis: "Aus SHM E2-Review" - pflicht: false - - - quelle: "Service-Katalog" - was: "Service-Status-Übersicht" - artefakt: "Service-Liste mit Status" - frequenz: "Laufend aktuell" - pflicht: true - - # --------------------------------------------------------------------------- - # OUTPUT-SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - output: - - - ziel: "SOR" - was: "Portfolio-Review-Vorlage" - artefakt: "Portfolio-Status-Übersicht" - frequenz: "Quartalsweise" - bedingung: "Jedes Quartal" - - - ziel: "DPM-Portfolio-Review" - was: "SPM-Input" - artefakt: "Portfolio-Erkenntnisse, Kapazitäts-Einschätzung" - frequenz: "Quartalsweise" - bedingung: "Jedes Quartal" - - - ziel: "Mission Board" - was: "Eskalationen" - artefakt: "Eskalations-Empfehlung" - frequenz: "Anlassbezogen" - bedingung: "Bei IMPROVE-ESCALATE-RESOURCE oder RETIRE-RECOMMEND" - - - ziel: "Vision Board" - was: "Strategischer Input" - artefakt: "SPM Jahres-Portfolio-Report" - frequenz: "Jährlich (Q4)" - bedingung: "E1-Zyklus" - - - ziel: "Service Owner (bei Mustern)" - was: "Koordinierte Aktion" - artefakt: "Maßnahmen-Empfehlung" - frequenz: "Anlassbezogen" - bedingung: "Bei IMPROVE-ESCALATE-OPERATIONAL" - -# ============================================================================= -# 12. ROLLEN UND VERANTWORTLICHKEITEN -# ============================================================================= - -rollen: - - service_portfolio_manager: - kurzbezeichnung: "SPM" - verantwortung: - - "Sammlung und Aggregation der Service-Review-Ergebnisse" - - "Erstellung der Portfolio-Status-Übersicht (E2)" - - "Vorbereitung und Präsentation des Portfolio-Blocks in SOR" - - "Identifikation von Mustern und Auffälligkeiten" - - "Formulierung der Portfolio-Empfehlung" - - "Erstellung des Jahres-Portfolio-Reports (E1)" - - "Koordination bei IMPROVE-ESCALATE-OPERATIONAL" - - "Lieferung des SPM-Inputs für DPM-Review" - raci: "A/R für Portfolio-Review-Durchführung" - - sor: - kurzbezeichnung: "SOR" - typ: "Gremium" - verantwortung: - - "Behandlung des Portfolio-Review-Blocks" - - "Entscheidung bei Service-Reviews mit SOR-Bedarf" - - "Bestätigung des Portfolio-Status" - - "Eskalationsentscheidungen an MB" - raci: "A für Portfolio-Governance-Entscheidungen" - - service_owner: - kurzbezeichnung: "SO" - verantwortung: - - "Durchführung des quartalsweisen Service-Reviews" - - "Aktualisierung des Service-Steckbriefs" - - "Lieferung der Datenpunkte an SPM (via Steckbrief)" - - "Umsetzung von IMPROVE-ESCALATE-OPERATIONAL-Maßnahmen" - raci: "R für Service-Review-Input" - - mission_board: - kurzbezeichnung: "MB" - typ: "Gremium" - verantwortung: - - "Entscheidung bei RETIRE-RECOMMEND" - - "Entscheidung bei Ressourcen-Eskalationen" - - "Strategische Portfolio-Entscheidungen" - raci: "A für eskalierte Portfolio-Entscheidungen" - - vision_board: - kurzbezeichnung: "VB" - typ: "Gremium" - verantwortung: - - "Entgegennahme des E1-Jahresberichts" - - "Strategische Richtungsentscheidungen basierend auf Portfolio-Erkenntnissen" - raci: "A für strategische Ausrichtung" - -# ============================================================================= -# 13. OFFENE PUNKTE UND POST-MVP -# ============================================================================= - -offene_punkte: - - # --------------------------------------------------------------------------- - # IM MVP NICHT ADRESSIERT - # --------------------------------------------------------------------------- - - im_mvp_nicht_adressiert: - - - punkt: "Quantitative Portfolio-KPIs" - beschreibung: | - Das MVP arbeitet primär qualitativ (Ampel-Aggregation). - Quantitative Portfolio-KPIs (z.B. Portfolio-TCO, durchschnittliche - Service-Alter, Technologie-Diversität) können später ergänzt werden. - status: "Post-MVP-Erweiterung" - - - punkt: "Tool-gestützte Aggregation" - beschreibung: | - Im MVP erfolgt die Aggregation manuell durch SPM. Bei wachsendem - Portfolio kann Tool-Unterstützung (Dashboard, automatische - Datenextraktion aus Steckbriefen) sinnvoll werden. - status: "Post-MVP-Erweiterung" - - - punkt: "Benchmark-Definition" - beschreibung: | - Zielwerte für Portfolio-Gesundheit (z.B. "max. 10% rot") sind - im MVP nicht definiert. Erst nach Baseline-Erhebung über 2-3 - Quartale sinnvoll. - status: "Nach Pilotphase zu definieren" - - # --------------------------------------------------------------------------- - # VALIDIERUNGSBEDARF - # --------------------------------------------------------------------------- - - validierungsbedarf: - - - punkt: "Zeitliche Synchronisation" - beschreibung: | - Die definierten Zeitfenster (T+1 bis T+14) sind Modellannahmen. - Die Praktikabilität muss in der Praxis validiert werden. - methode: "Pilotierung über 2 Quartale" - verantwortlich: "DIGIT" - - - punkt: "SOR-Agenda-Struktur" - beschreibung: | - Die 4-Block-Struktur für SOR-Sitzungen muss mit der tatsächlichen - SOR-Praxis abgestimmt werden. - methode: "Abstimmung mit SOR-Leitung" - - - punkt: "Aggregationslogik" - beschreibung: | - Die Orientierungskriterien (AK-01 bis AK-06) müssen sich in der - Praxis als handhabbar erweisen. - methode: "Review nach erstem Jahres-Zyklus" - - # --------------------------------------------------------------------------- - # ARBEITSMATERIALIEN - # --------------------------------------------------------------------------- - - arbeitsmaterialien_zu_entwickeln: - - status: "Ausstehend" - - materialien: - - - id: "AM-01" - name: "Template: SPM Quartals-Portfolio-Status" - format: "Word/Markdown" - prioritaet: "Hoch" - beschreibung: "Vorlage für E2-Output gemäß Abschnitt 9" - - - id: "AM-02" - name: "Template: SPM Jahres-Portfolio-Report" - format: "Word/Markdown" - prioritaet: "Mittel" - beschreibung: "Vorlage für E1-Output gemäß Abschnitt 9" - - - id: "AM-03" - name: "Checkliste: Portfolio-Review-Vorbereitung" - format: "Checklist" - prioritaet: "Hoch" - beschreibung: "SPM-Checkliste für T+8 bis T+10" - - - id: "AM-04" - name: "Vorlage: SOR-Protokoll-Abschnitt Portfolio-Review" - format: "Word/Markdown" - prioritaet: "Mittel" - beschreibung: "Standard-Abschnitt für SOR-Protokoll" - - - id: "AM-05" - name: "Dashboard-Konzept: Portfolio-Übersicht" - format: "Konzept/Excel" - prioritaet: "Niedrig" - beschreibung: "Optional: Visualisierung der Portfolio-Daten" - -# ============================================================================= -# 14. GOVERNANCE-ENTSCHEIDUNGEN (ZUSAMMENFASSUNG) -# ============================================================================= - -governance_entscheidungen_log: - - - id: "GOV-PR-001" - datum: "2025-12-17" - frage: "Welche Datenbasis nutzt der Portfolio-Review?" - entscheidung: | - Datenpunkte (DP-01 bis DP-05) werden aus Service-Reviews abgeleitet, - nicht separat erhoben. Minimale quantitative Basis ergänzt durch - qualitative Einschätzung. Daten-Gaps werden explizit markiert. - begruendung: | - Vermeidet Doppelerhebung, nutzt bestehenden Service-Review-Output. - Konsistent mit der verfügbaren Datenbasis im MVP. - confidence: "80%" - status: "final" - - - id: "GOV-PR-002" - datum: "2025-12-17" - frage: "Wie ist der Portfolio-Review governance-seitig eingebettet?" - entscheidung: | - Zweistufiges Modell: E2 quartalsweise in SOR (Portfolio-Block), - E1 jährlich als Report für Vision Board. Kein eigenständiges - Gremienformat. Integration als Input in DPM-Review. - begruendung: | - Vermeidet Format-Inflation, nutzt bestehende Strukturen. - Konsistent mit E1/E2-Architektur in SHM und DPM. - confidence: "85%" - status: "final" - - - id: "GOV-PR-003" - datum: "2025-12-17" - frage: "Wie ist die zeitliche Synchronisation der Reviews?" - entscheidung: | - Definierte Zeitfenster: Service-Reviews (T+1 bis T+7), - SPM-Aggregation (T+8 bis T+10), SOR mit Portfolio-Block (T+10 bis T+12), - DPM-Review (T+12 bis T+14). - begruendung: | - Ermöglicht sequentielle Aggregation mit Puffer. Konsistent mit - DPM-Review-Zeitplanung. - confidence: "75%" - hinweis: "Modellannahme – Validierung durch DIGIT erforderlich" - status: "final" - - - id: "GOV-PR-004" - datum: "2025-12-17" - frage: "Welche Entscheidungstypen gibt es auf Portfolio-Ebene?" - entscheidung: | - Drei Typen: MAINTAIN (Bestätigung), IMPROVE-ESCALATE (mit Varianten: - Operational, Structural, Resource), RETIRE-RECOMMEND. EXPAND, - TRANSFORM, CONSOLIDATE sind keine Portfolio-Review-Entscheidungen. - begruendung: | - Klare Abgrenzung zu Demand-Lifecycle. Portfolio-Review identifiziert - und eskaliert, aber generiert keine neuen Demands direkt. - confidence: "85%" - status: "final" - - - id: "GOV-PR-005" - datum: "2025-12-17" - frage: "Wie werden Service-Review-Ergebnisse aggregiert?" - entscheidung: | - Orientierungskriterien (AK-01 bis AK-06) mit Urteilsvorbehalt. - Keine mathematische Formel. Bei Abweichung Begründungspflicht. - begruendung: | - Konsistent mit Service-Review-Konzept. Vermeidet Schein-Objektivität, - erhält Flexibilität für Kontextberücksichtigung. - confidence: "75%" - status: "final" - - - id: "GOV-PR-006" - datum: "2025-12-17" - frage: "Wie verhalten sich Service-Review- und Portfolio-Review-Entscheidungen?" - entscheidung: | - Explizites Mapping: CONTINUE → MAINTAIN, IMPROVEMENT → ggf. IMPROVE-ESCALATE, - RETIRE → RETIRE-RECOMMEND. Begriffe bewusst unterschiedlich für Ebenen-Trennung. - begruendung: | - Vermeidet Begriffsverwirrung, macht Aggregationslogik explizit. - confidence: "90%" - status: "final" - - - id: "GOV-PR-007" - datum: "2025-12-17" - frage: "Wie ist die SOR-Agenda für Reviews strukturiert?" - entscheidung: | - 4-Block-Struktur: (1) Portfolio-Überblick, (2) Service-Review-Entscheidungen, - (3) Portfolio-Entscheidungen, (4) Status-Bestätigung. Bei Überlappung - werden Einzelthemen als Cluster behandelt. - begruendung: | - Portfolio-Perspektive rahmt Einzelentscheidungen. Vermeidet - redundante Behandlung bei Mustern. - confidence: "80%" - status: "final" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "0.1" - datum: "2025-12-15" - aenderung: "Placeholder erstellt mit Gliederungsskelett" - autor: "DIGITOM-Projekt" - - - version: "1.0" - datum: "2025-12-17" - aenderung: | - Vollständige Ausarbeitung basierend auf: - - Klärungsfragen KF1-KF4 (Zweck, Datenbasis, Governance, Entscheidungstypen) - - Modellierungsreife-Prüfung (7 Punkte) - - Synchronisation mit Service-Review-Konzept (K-SR) +# ============================================================================= +# SERVICE-PORTFOLIO REVIEW KONZEPT +# ============================================================================= + +metadata: + id: "G-PR" + name: "Service-Portfolio Review Konzept" + version: "1.0" + status: "draft" + erstellt: "2025-12-17" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "methodik" + + beschreibung: > + Definiert den strategischen Review-Zyklus für das gesamte Service-Portfolio. + Der Portfolio-Review aggregiert die Ergebnisse der Einzel-Service-Reviews + und ermöglicht eine übergreifende Steuerungsperspektive. Er folgt einem + zweistufigen Modell (E1/E2) konsistent mit der DIGITOM-Architektur. + + abgrenzung: + service_review: > + Das Konzept "Service-Review" (K-SR) fokussiert auf den einzelnen Service + aus operativer Perspektive. Der Service Owner bewertet seinen Service + quartalsweise anhand von 4 Dimensionen. + portfolio_review: > + Dieses Konzept fokussiert auf das Gesamtportfolio aus taktisch- + strategischer Perspektive. SPM aggregiert die Service-Review-Ergebnisse + und identifiziert übergreifende Muster. + + referenzen: + service_review_konzept: "02a_lifecycle-konzepte/konzept_service-review.yaml" + service_review_blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-review.yaml" + sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" + dpm_portfolio_review: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio-review.yaml" + shm_koordination: "#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml" + ssm_governance: "03_practices/spm_practice_service-support-management/ssm_governance.yaml" + + governance_entscheidungen: + - "GOV-PR-001 bis GOV-PR-007 (in diesem Dokument definiert)" + +# ============================================================================= +# 1. ZWECK UND FUNKTION +# ============================================================================= + +zweck_und_funktion: + + primaerer_zweck: | + Sicherstellung der Portfolio-Gesundheit durch regelmäßige Aggregation + und Bewertung der Service-Performance auf Portfolio-Ebene. Der Review + dient der Früherkennung von Risiken, der Identifikation von + Optimierungspotenzialen und der strategischen Rückkopplung. + + # --------------------------------------------------------------------------- + # FUNKTIONEN + # --------------------------------------------------------------------------- + + funktionen: + + - id: "F-01" + name: "Qualitätssicherung" + beschreibung: "Aggregierte Bewertung der Portfolio-Performance" + ebene: "E2" + konkretisierung: | + Zusammenführung der Service-Review-Ergebnisse zu einer + Portfolio-Gesamtsicht. Identifikation von Services mit + Handlungsbedarf und deren Anteil am Gesamtportfolio. + + - id: "F-02" + name: "Risiko-Früherkennung" + beschreibung: "Identifikation von Risiko-Clustern und Kapazitätsengpässen" + ebene: "E2" + konkretisierung: | + Erkennung von Mustern, die auf systemische Probleme hindeuten: + - Mehrere Services mit gleichartigen Problemen + - Ressourcenengpässe über Service-Grenzen hinweg + - Technologie-Cluster mit EOL-Risiko + + - id: "F-03" + name: "Strategische Rückkopplung" + beschreibung: "Input für übergeordnete Portfolio-Entscheidungen" + ebene: "E1" + konkretisierung: | + Jährliche Bewertung der Portfolio-Entwicklung und Ableitung + strategischer Empfehlungen für das Vision Board. + + # --------------------------------------------------------------------------- + # EXPLIZITE NICHT-FUNKTIONEN + # --------------------------------------------------------------------------- + + explizite_nicht_funktionen: + + - funktion: "Operative Einzelservice-Entscheidungen" + verweis: "Service-Review (K-SR), Aktivität sr_03" + begruendung: | + Entscheidungen zu CONTINUE, IMPROVEMENT, REDESIGN oder RETIRE + für einen einzelnen Service werden im Service-Review getroffen, + nicht im Portfolio-Review. + + - funktion: "Demand-Priorisierung" + verweis: "DPM-Portfolio-Review" + begruendung: | + Die Priorisierung von Demands erfolgt im DPM-Prozess. Der + SPM-Portfolio-Review liefert Input (Service-Impact), trifft + aber keine Demand-Entscheidungen. + + - funktion: "Strategiedefinition" + verweis: "Vision Board" + begruendung: | + Der Portfolio-Review liefert strategische Erkenntnisse als + Input für das Vision Board, definiert aber nicht selbst + die IT-Strategie. + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Der Portfolio-Review ist kein Ersatz für den operativen Service-Review + (sr_02/sr_03), sondern dessen Aggregation. Er erzeugt keine neuen + Service-Entscheidungen, sondern bewertet die Portfolio-Gesundheit + und eskaliert bei Bedarf. Die Zweistufigkeit (E1/E2) spiegelt die + etablierte DIGITOM-Governance-Architektur. + +# ============================================================================= +# 2. DATENBASIS +# ============================================================================= + +datenbasis: + + governance_referenz: "GOV-PR-001" + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Der Portfolio-Review arbeitet mit der verfügbaren Datenbasis und + akzeptiert Lücken explizit. Die Datenpunkte werden aus den Service- + Reviews abgeleitet, nicht separat erhoben. Dies vermeidet Doppelarbeit + und nutzt den bereits definierten Service-Review-Output. + + # --------------------------------------------------------------------------- + # DATENPUNKTE + # --------------------------------------------------------------------------- + + datenpunkte: + + beschreibung: | + Diese Datenpunkte werden je Service für den Portfolio-Review benötigt. + Sie werden aus dem Service-Review und der Service-Definition abgeleitet. + + punkte: + + - id: "DP-01" + name: "Service-Status" + typ: "Kategorie" + auspraegungen: + - "aktiv" + - "in_transition" + - "planned_eol" + - "retired" + quelle: "Service-Katalog" + mapping: "Direkte Übernahme aus Service-Katalog" + pflicht: true + + - id: "DP-02" + name: "Letzter Service-Review" + typ: "Datum" + quelle: "Service-Definition" + mapping: "Datum des letzten abgeschlossenen Service-Reviews" + pflicht: true + hinweis: "Falls kein Review stattgefunden hat: 'nie'" + + - id: "DP-03" + name: "Nutzungsintensität" + typ: "Kategorie" + auspraegungen: + - "hoch" + - "mittel" + - "niedrig" + - "unbekannt" + quelle: "Service-Review (SO-Einschätzung)" + mapping: "Übernahme aus Service-Review" + pflicht: true + + - id: "DP-04" + name: "Aktuelle Problemlage" + typ: "Ampel" + auspraegungen: + gruen: + label: "Stabil" + ableitung: "Alle Dimensionen Grün oder max. 1x Gelb im Service-Review" + gelb: + label: "Beobachten" + ableitung: "Mind. 2x Gelb oder 1x Rot ohne Handlungsbedarf im Service-Review" + rot: + label: "Handlungsbedarf" + ableitung: "Mind. 1x Rot mit Handlungsbedarf (IMPROVEMENT/REDESIGN/RETIRE)" + quelle: "Abgeleitet aus Service-Review-Dimensionen (SR-D1 bis SR-D4)" + mapping: | + Die Problemlage-Ampel aggregiert die 4 Service-Review-Dimensionen + zu einem Gesamtwert. Die Ableitung folgt der Aggregationslogik + im Service-Review-Konzept. + pflicht: true + + - id: "DP-05" + name: "Geplante Maßnahmen" + typ: "Strukturiert" + felder: + - name: "massnahmen_vorhanden" + typ: "boolean" + - name: "kurzbeschreibung" + typ: "string" + max_laenge: 200 + quelle: "Service-Steckbrief → Abschnitt 'Laufende Verbesserungen'" + mapping: "ja/nein + Kurztext der wichtigsten Maßnahme" + pflicht: true + + # --------------------------------------------------------------------------- + # QUALITATIVE ERGÄNZUNG + # --------------------------------------------------------------------------- + + qualitative_ergaenzung: + + beschreibung: | + Neben den strukturierten Datenpunkten kann der Service Owner eine + qualitative Einschätzung zur Gesamtsituation des Service geben. + Diese wird im Portfolio-Review bei Bedarf herangezogen. + + format: "Freitext (max. 500 Zeichen)" + inhalt: "Wesentliche Entwicklungen, Risiken, Chancen" + quelle: "Service-Definition → service_review" + pflicht: false + + # --------------------------------------------------------------------------- + # UMGANG MIT DATENLÜCKEN + # --------------------------------------------------------------------------- + + umgang_mit_datenluecken: + + prinzip: | + Fehlende Daten werden als "unbekannt" markiert, nicht geschätzt. + Services mit mehr als 2 unbekannten Datenpunkten werden im + Review explizit als "Daten-Gap" ausgewiesen. + + schwellenwert_portfolio: | + Bei systematischen Daten-Gaps (>30% der Services) wird dies + als eigener Review-Befund dokumentiert und führt zu + IMPROVE-ESCALATE mit Fokus auf Datenbasis-Verbesserung. + + eskalation: | + Wenn ein Service über 2 Quartale keinen Review hatte (DP-02), + wird dies im Portfolio-Review als Governance-Problem markiert + und an den betreffenden Service Owner bzw. SOR eskaliert. + +# ============================================================================= +# 3. GOVERNANCE-EINBETTUNG +# ============================================================================= + +governance_einbettung: + + governance_referenz: "GOV-PR-002" + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Der Service-Portfolio-Review ist kein eigenständiges Gremienformat, + sondern eine periodische Funktion, die in bestehenden Governance- + Strukturen ausgeübt wird. Die Zweistufigkeit (E1/E2) spiegelt die + etablierte DIGITOM-Architektur. + + # --------------------------------------------------------------------------- + # E2: QUARTALS-PORTFOLIO-REVIEW + # --------------------------------------------------------------------------- + + e2_portfolio_review: + + name: "SPM Quartals-Portfolio-Review" + + entscheidungstyp_referenz: "E2" + + format: "Erweiterter Agenda-Block in SOR" + + frequenz: "Quartalsweise" + + zeitpunkt: "T+10 bis T+12 nach Quartalsende" + + dauer: "45-60 Minuten (innerhalb regulärer SOR-Sitzung)" + + governance_anker: "SOR" + + # ------------------------------------------------------------------------- + teilnehmer: + + pflicht: + - rolle: "SPM" + funktion: "Leitung des Portfolio-Blocks, Präsentation" + - rolle: "SOR-Teilnehmer" + funktion: "Entscheidung, Diskussion" + + optional: + - rolle: "Service Owner" + funktion: "Bei Bedarf für Einzelthemen" + bedingung: "Wenn Service in SOR behandelt wird" + + # ------------------------------------------------------------------------- + input: + + - quelle: "Service Owner" + artefakt: "Aktualisierte Service-Steckbriefe" + inhalt: "Datenpunkte DP-01 bis DP-05 je Service" + deadline: "T+7" + + - quelle: "SSM / Support" + artefakt: "Support-KPIs (aggregiert)" + inhalt: "Incident-Trends, Problem-Cluster" + status: "Falls verfügbar" + + - quelle: "SHM" + artefakt: "VoC-Erkenntnisse" + inhalt: "Stakeholder-Feedback zu Services (Cluster D2)" + status: "Falls E2 vor Portfolio-Review abgeschlossen" + + # ------------------------------------------------------------------------- + output: + + - artefakt: "Portfolio-Status-Übersicht" + ziel: "Dokumentation, SOR-Protokoll" + inhalt: "Aggregierte Portfolio-Sicht, Ampel-Verteilung" + + - artefakt: "Identifizierte Handlungsbedarfe" + ziel: "SOR-Entscheidungen oder Eskalation" + inhalt: "Muster, Cluster-Probleme, Ressourcenkonflikte" + + - artefakt: "SPM-Input für DPM-Review" + ziel: "DPM-Portfolio-Review" + inhalt: "Service-Impact, Kapazitäts-Einschätzung" + + # ------------------------------------------------------------------------- + entscheidungsreichweite: + + direkt_in_sor: + - "Bestätigung Portfolio-Status (MAINTAIN)" + - "Priorisierung von übergreifenden Verbesserungsmaßnahmen" + - "Eskalationsempfehlung an MB formulieren" + + eskalation_an_mb: + - "Portfolio-strukturelle Entscheidungen (bei RETIRE-RECOMMEND für mehrere Services)" + - "Ressourcenkonflikte, die MB-Priorisierung erfordern" + - "Strategische Themen mit Budget-Implikation" + + # --------------------------------------------------------------------------- + # E1: JAHRES-PORTFOLIO-REPORT + # --------------------------------------------------------------------------- + + e1_portfolio_review: + + name: "SPM Jahres-Portfolio-Report" + + entscheidungstyp_referenz: "E1" + + format: "Bericht + Präsentation" + + frequenz: "Jährlich" + + zeitpunkt: "Q4, vor Vision-Board-Strategieplanung" + + governance_anker: "Vision Board (Input)" + + verantwortlich: "SPM" + + # ------------------------------------------------------------------------- + inhalt: + + - abschnitt: "Portfolio-Entwicklung" + beschreibung: "Jahres-Entwicklung des Service-Portfolios" + elemente: + - "Anzahl Services (Zu-/Abgänge)" + - "Ampel-Entwicklung über 4 Quartale" + - "Abgeschlossene Improvements und Retirements" + + - abschnitt: "Strategische Erkenntnisse" + beschreibung: "Muster und Trends mit strategischer Relevanz" + elemente: + - "Technologie-Trends (EOL, Modernisierungsbedarf)" + - "Kapazitäts-Entwicklung" + - "Stakeholder-Zufriedenheit (VoC-Aggregation)" + + - abschnitt: "Risiken und Chancen" + beschreibung: "Mittelfristige Portfolio-Risiken und -Chancen" + elemente: + - "Identifizierte Risiko-Cluster" + - "Konsolidierungspotenziale" + - "Strategische Lücken" + + - abschnitt: "Empfehlungen" + beschreibung: "Empfehlungen für Portfolio-Ausrichtung" + elemente: + - "Priorisierte Handlungsfelder" + - "Ressourcenbedarf-Prognose" + - "Alignment mit IT-Strategie" + + # ------------------------------------------------------------------------- + entscheidungsreichweite: | + Keine direkte Entscheidung. Der E1-Report liefert Input für + strategische Entscheidungen im Vision Board. Empfehlungen + werden dort diskutiert und ggf. in strategische Maßnahmen + überführt. + + # ------------------------------------------------------------------------- + zusaetzlich_pulse_update: + frequenz: "Halbjährlich" + zeitpunkt: "Q2" + umfang: "Kurzform (max. 2 Seiten)" + inhalt: "Wesentliche Entwicklungen seit Jahresbericht, Trendaktualisierung" + + # --------------------------------------------------------------------------- + # INTEGRATION IN DPM-REVIEW + # --------------------------------------------------------------------------- + + integration_dpm_review: + + beschreibung: | + SPM ist regulärer Teilnehmer im DPM-Portfolio-Review und liefert + dort die Service-Perspektive. Der SPM-Input basiert auf den + Erkenntnissen des E2-Portfolio-Reviews. + + spm_beitrag_im_dpm_review: + + - beitrag: "Service-Impact neuer Demands" + beschreibung: "Bewertung, wie geplante Demands das Portfolio beeinflussen" + + - beitrag: "Betriebsbereitschaft für geplante Übergaben" + beschreibung: "Einschätzung der Transition-Kapazität" + + - beitrag: "Portfolio-Kapazitäts-Einschätzung" + beschreibung: "Verfügbare Ressourcen für neue Services" + + sequenzierung: | + SPM E2 (SOR) findet vor dem DPM-Portfolio-Review statt, + damit konsolidierte SPM-Erkenntnisse verfügbar sind. + +# ============================================================================= +# 4. ZEITLICHE SYNCHRONISATION +# ============================================================================= + +zeitliche_synchronisation: + + governance_referenz: "GOV-PR-003" + + # --------------------------------------------------------------------------- + # VALIDIERUNGSHINWEIS + # --------------------------------------------------------------------------- + + validierungshinweis: + status: "Modellannahme" + beschreibung: | + Die folgenden Zeitfenster sind Modellannahmen basierend auf der + bestehenden DIGITOM-Architektur. Sie müssen in der Praxis durch + DIGIT validiert und ggf. angepasst werden. + validierung_durch: "DIGIT" + validierung_methode: "Pilotierung über 2 Quartale" + + # --------------------------------------------------------------------------- + # QUARTALS-ZYKLUS + # --------------------------------------------------------------------------- + + quartals_zyklus: + + beschreibung: | + Der Quartals-Zyklus definiert die zeitliche Abfolge der Review- + Aktivitäten nach Quartalsende. T+n bezeichnet den n-ten Arbeitstag + nach dem letzten Tag des Quartals. + + phasen: + + - phase: 1 + name: "Service-Reviews durchführen" + zeitfenster: "T+1 bis T+7" + verantwortlich: "Alle Service Owner" + aktivitaeten: + - "SO führt quartalsweisen Selbst-Review durch" + - "Bewertung der 4 Dimensionen (SR-D1 bis SR-D4)" + - "Ableitung der Handlungsempfehlung" + - "Aktualisierung des Service-Steckbriefs" + output: "Aktualisierte Service-Steckbriefe" + deadline: "T+7 (Ende erste Woche)" + + - phase: 2 + name: "SPM-Aggregation und Vorbereitung" + zeitfenster: "T+8 bis T+10" + verantwortlich: "SPM" + aktivitaeten: + - "Sammlung aller Service-Steckbriefe" + - "Extraktion der Datenpunkte (DP-01 bis DP-05)" + - "Erstellung der Portfolio-Status-Übersicht" + - "Identifikation von Mustern und Auffälligkeiten" + - "Vorbereitung der SOR-Vorlage" + output: "Portfolio-Status-Übersicht, SOR-Vorlage" + + - phase: 3 + name: "SOR mit Portfolio-Block (E2)" + zeitfenster: "T+10 bis T+12" + verantwortlich: "SOR" + aktivitaeten: + - "Präsentation Portfolio-Status durch SPM" + - "Behandlung von Service-Reviews mit SOR-Bedarf" + - "Portfolio-Entscheidungen (MAINTAIN/IMPROVE-ESCALATE/RETIRE-RECOMMEND)" + - "Bestätigung des Portfolio-Status" + output: "SOR-Protokoll, bestätigter Portfolio-Status" + + - phase: 4 + name: "DPM-Portfolio-Review" + zeitfenster: "T+12 bis T+14" + verantwortlich: "AL Planung" + aktivitaeten: + - "SPM bringt Portfolio-Erkenntnisse ein" + - "Demand-Portfolio-Review gemäß DPM-Framework" + input: "SPM-Erkenntnisse aus E2" + + # --------------------------------------------------------------------------- + # SYNCHRONISATION MIT ANDEREN FORMATEN + # --------------------------------------------------------------------------- + + synchronisation_andere_formate: + + shm_e2: + format: "SHM Quartals-Review" + zeitfenster: "T+1 bis T+7 (parallel zu Service-Reviews)" + beziehung: | + SHM E2 liefert VoC-Erkenntnisse (Cluster D2: Service-Qualität), + die in Service-Reviews einfließen können. Wenn SHM E2 vor dem + jeweiligen Service-Review abgeschlossen ist, kann der SO die + VoC-Signale in seine Bewertung einbeziehen. + + ssm_quartals_review: + format: "SSM Quartals-Review" + zeitfenster: "Idealerweise T+1 bis T+5" + beziehung: | + Der SSM-Quartals-Review liefert Support-Perspektive (Incident- + Trends, Problem-Cluster), die in die Service-Review-Dimension + SR-D2 (Betriebsstabilität) einfließt. Empfehlung: SSM-Review + vor den meisten Service-Reviews abschließen. + + # --------------------------------------------------------------------------- + # JAHRES-ZYKLUS + # --------------------------------------------------------------------------- + + jahres_zyklus: + + beschreibung: | + Der Jahres-Zyklus definiert die E1-Aktivitäten und deren + Einbettung in die DIGIT-Strategieplanung. + + aktivitaeten: + + - zeitpunkt: "Q2 (ca. KW 26-28)" + name: "Halbjahres-Pulse-Update" + verantwortlich: "SPM" + output: "Kurzform Portfolio-Update für Vision Board" + + - zeitpunkt: "Q4 (ca. KW 45-48)" + name: "Jahres-Portfolio-Report erstellen" + verantwortlich: "SPM" + output: "SPM Jahres-Portfolio-Report" + + - zeitpunkt: "Q4 (vor Vision-Board-Strategiesitzung)" + name: "E1-Input für Vision Board" + verantwortlich: "SPM" + output: "Präsentation strategischer Erkenntnisse und Empfehlungen" + +# ============================================================================= +# 5. ENTSCHEIDUNGSTYPEN +# ============================================================================= + +entscheidungstypen: + + governance_referenz: "GOV-PR-004" + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Der Portfolio-Review trifft selbst nur eine Entscheidung: MAINTAIN. + Alle anderen Ergebnisse sind Empfehlungen oder Eskalationen, die + in anderen Governance-Strukturen entschieden werden. Dies vermeidet + Doppelstrukturen und respektiert die bestehende Entscheidungsarchitektur. + + # --------------------------------------------------------------------------- + # MAINTAIN + # --------------------------------------------------------------------------- + + typen: + + - id: "PR-MAINTAIN" + name: "MAINTAIN" + + beschreibung: | + Das Portfolio befindet sich in einem akzeptablen Zustand. + Die aggregierten Service-Reviews zeigen keine systematischen + Probleme. Keine Portfolio-Ebenen-Aktion erforderlich. + + entscheidungstraeger: "SOR (im Rahmen des E2-Reviews)" + + kriterien: + - "Keine oder nur einzelne Services mit roter Ampel (DP-04)" + - "Keine systematischen Daten-Gaps (< 30% der Services)" + - "Keine offenen IMPROVE-ESCALATE oder RETIRE-RECOMMEND aus Vorquartal" + - "Keine erkennbaren Muster, die übergreifende Aktion erfordern" + + output: + - artefakt: "Portfolio-Status-Bestätigung" + ort: "SOR-Protokoll" + + folgeprozess: null + + naechster_review: "Nächstes Quartal (E2)" + + # ------------------------------------------------------------------------- + # IMPROVE-ESCALATE + # ------------------------------------------------------------------------- + + - id: "PR-IMPROVE-ESCALATE" + name: "IMPROVE-ESCALATE" + + beschreibung: | + Handlungsbedarf auf Portfolio-Ebene erkannt. Dies kann sein: + - Mehrere Services mit gleichartigen Problemen (Muster) + - Ressourcenengpässe, die mehrere Services betreffen + - Strukturelle Verbesserungspotenziale + + Der Review identifiziert und dokumentiert, entscheidet aber nicht + über die Maßnahme selbst. + + entscheidungstraeger: "SOR (Identifikation), Weiterleitung an zuständige Stelle" + + # ----------------------------------------------------------------------- + varianten: + + - id: "PR-IMPROVE-ESCALATE-OPERATIONAL" + name: "Operative Eskalation" + + beschreibung: | + Handlungsbedarf, der durch koordinierte Aktion der betroffenen + Service Owner adressiert werden kann. + + beispiele: + - "Gemeinsame Dokumentationslücken in mehreren Services" + - "Wiederkehrende Schulungsbedarfe" + - "Prozess-Inkonsistenzen zwischen Services" + + weiterleitung: "Betroffene Service Owner (koordiniert durch SPM)" + + folgeprozess: "Service Improvement (sr_04) in betroffenen Services" + + - id: "PR-IMPROVE-ESCALATE-STRUCTURAL" + name: "Strukturelle Eskalation" + + beschreibung: | + Handlungsbedarf, der Demand-Charakter hat (Budget, Projektaufwand, + übergreifende Architektur-Entscheidung). + + beispiele: + - "Mehrere Services benötigen Technologie-Migration" + - "Gemeinsame Infrastruktur-Komponente muss erneuert werden" + - "Konsolidierungspotenzial bei überlappenden Services" + + weiterleitung: "DPM zur Demand-Erfassung" + + folgeprozess: "Demand-Lifecycle" + + - id: "PR-IMPROVE-ESCALATE-RESOURCE" + name: "Ressourcen-Eskalation" + + beschreibung: | + Kapazitätsengpässe, die MB-Entscheidung erfordern, weil sie + Priorisierung zwischen konkurrierenden Bedarfen erfordern. + + beispiele: + - "Mehrere ressourcenrelevante Improvements konkurrieren" + - "Betriebskapazität reicht nicht für Portfolio-Umfang" + - "Skill-Engpass bei kritischer Technologie" + + weiterleitung: "Mission Board" + + folgeprozess: "MB-Entscheidung zur Ressourcenallokation" + + # ----------------------------------------------------------------------- + kriterien: + - "Mehrere Services mit gelber oder roter Ampel (Muster erkennbar)" + - "Wiederkehrende Themen aus Service-Reviews (> 3 Services betroffen)" + - "Kapazitäts-Gap zwischen Anforderungen und Verfügbarkeit" + - "Systematische Daten-Gaps (> 30% der Services)" + + output: + - artefakt: "Eskalations-Empfehlung" + inhalt: + - "Identifiziertes Muster/Problem" + - "Betroffene Services" + - "Empfohlene Maßnahme oder Demand-Skizze" + - "Adressat der Eskalation" + - "Begründung" + + # ------------------------------------------------------------------------- + # RETIRE-RECOMMEND + # ------------------------------------------------------------------------- + + - id: "PR-RETIRE-RECOMMEND" + name: "RETIRE-RECOMMEND" + + beschreibung: | + Empfehlung zur Stilllegung eines oder mehrerer Services. + Der Portfolio-Review aggregiert Signale aus Service-Reviews + (RETIRE-Empfehlungen) und formuliert eine konsolidierte + Empfehlung an das MB. + + Die Entscheidung zur Stilllegung liegt beim MB wegen + Ressourcen- und Kundenimplikationen. + + entscheidungstraeger: "SOR (Empfehlung), MB (Entscheidung)" + + kriterien: + - "Service-Review-Ergebnis: RETIRE (sr_06) für einen oder mehrere Services" + - "Niedrige Nutzungsintensität (DP-03) über mehrere Quartale" + - "Hoher Betriebsaufwand bei geringem dokumentiertem Nutzen" + - "Technische Überalterung ohne wirtschaftlichen Migrationsweg" + - "Funktionalität wird durch anderen Service abgedeckt (Dopplung)" + + output: + - artefakt: "Stilllegungs-Empfehlung" + inhalt: + - "Betroffene Services" + - "Begründung je Service" + - "Grobe Impact-Einschätzung (Nutzer, Abhängigkeiten)" + - "Vorgeschlagener Zeitrahmen" + - "Ggf. Migrationshinweise" + + folgeprozess: "MB-Entscheidung → ggf. Retirement-Projekt via DPM" + + # --------------------------------------------------------------------------- + # EXPLIZIT NICHT-ENTSCHEIDUNGSTYPEN + # --------------------------------------------------------------------------- + + explizit_nicht_entscheidungstypen: + + beschreibung: | + Die folgenden Entscheidungstypen aus klassischen Portfolio-Management- + Frameworks werden bewusst NICHT als Portfolio-Review-Entscheidungen + modelliert, da sie entweder Demand-Charakter haben oder auf anderer + Ebene entschieden werden. + + typen: + + - id: "EXPAND" + name: "Portfolio erweitern" + begruendung: | + Neue Services entstehen durch den Demand-Lifecycle, nicht durch + Portfolio-Review-Entscheidung. Der Review kann Lücken identifizieren + (als IMPROVE-ESCALATE-STRUCTURAL), aber die Entscheidung zur + Erweiterung ist ein Demand. + alternativer_pfad: "Demand → DPM → DSR/MB → Projekt → Service-Entwicklung" + + - id: "TRANSFORM" + name: "Portfolio transformieren" + begruendung: | + Grundlegende Neuausrichtung hat strategischen Charakter und + Demand-Implikationen. Gehört in den Vision-Board-Strategieprozess, + nicht in den operativen Portfolio-Review. Der E1-Report kann + Transformationsbedarf als Erkenntnis dokumentieren. + alternativer_pfad: "E1-Report → Vision Board → Strategische Initiative" + + - id: "CONSOLIDATE" + name: "Services konsolidieren" + begruendung: | + Konsolidierung (Zusammenführung von Services) ist ein Projekt + mit Demand-Charakter. Der Review kann Konsolidierungspotenzial + identifizieren (als IMPROVE-ESCALATE-STRUCTURAL), aber die + Umsetzung läuft über DPM. + alternativer_pfad: "IMPROVE-ESCALATE-STRUCTURAL → DPM → Konsolidierungsprojekt" + +# ============================================================================= +# 6. AGGREGATIONSLOGIK +# ============================================================================= + +aggregationslogik: + + governance_referenz: "GOV-PR-005" + + # --------------------------------------------------------------------------- + # GRUNDSATZ + # --------------------------------------------------------------------------- + + grundsatz: | + Der SPM bewertet das Portfolio-Gesamtbild anhand der aggregierten + Service-Daten. Es gibt keine mathematische Formel, aber + Orientierungskriterien für die Ableitung des Portfolio-Status. + Die Logik ist konsistent mit dem Service-Review-Konzept, das + ebenfalls Orientierungskriterien mit Urteilsvorbehalt nutzt. + + # --------------------------------------------------------------------------- + # ORIENTIERUNGSKRITERIEN + # --------------------------------------------------------------------------- + + orientierungskriterien: + + - id: "AK-01" + konstellation: "Alle Services Grün oder Gelb, keine offenen Handlungsbedarfe" + typische_empfehlung: "MAINTAIN" + erklaerung: | + Das Portfolio ist stabil. Einzelne Gelb-Bewertungen sind normal + und werden im Service-Review adressiert. + + - id: "AK-02" + konstellation: "Einzelne Services mit IMPROVEMENT (SO-geführt)" + typische_empfehlung: "MAINTAIN" + erklaerung: | + SO-geführte Improvements sind Routine und erfordern keine + Portfolio-Aktion. Die Services werden operativ betreut. + + - id: "AK-03" + konstellation: "Mehrere Services mit gleichartigem Problem-Muster" + typische_empfehlung: "IMPROVE-ESCALATE" + erklaerung: | + Ein Muster (z.B. 3+ Services mit Performance-Problemen wegen + gemeinsamer Infrastruktur) deutet auf systemisches Problem hin, + das übergreifend adressiert werden muss. + variante: "OPERATIONAL wenn koordinierte SO-Aktion reicht, STRUCTURAL wenn Demand nötig" + + - id: "AK-04" + konstellation: "Ressourcenkonflikte zwischen mehreren Improvement-Vorhaben" + typische_empfehlung: "IMPROVE-ESCALATE-RESOURCE" + erklaerung: | + Wenn mehrere ressourcenrelevante Improvements um dieselben + Ressourcen konkurrieren, muss MB priorisieren. + + - id: "AK-05" + konstellation: "Services mit RETIRE-Empfehlung aus Service-Review" + typische_empfehlung: "RETIRE-RECOMMEND" + erklaerung: | + RETIRE-Empfehlungen aus Service-Reviews werden auf Portfolio-Ebene + aggregiert und als konsolidierte Empfehlung an MB weitergeleitet. + + - id: "AK-06" + konstellation: "Systematische Daten-Gaps (> 30% der Services)" + typische_empfehlung: "IMPROVE-ESCALATE-OPERATIONAL" + erklaerung: | + Fehlende Daten sind ein Governance-Problem, das adressiert werden + muss. Fokus auf Verbesserung der Review-Durchführung. + + # --------------------------------------------------------------------------- + # URTEILSVORBEHALT + # --------------------------------------------------------------------------- + + urteilsvorbehalt: | + Diese Orientierungskriterien ersetzen nicht das Urteil des SPM. + Bei Abweichung von der typischen Konstellation ist eine kurze + Begründung im Review-Protokoll erforderlich. Der SPM berücksichtigt + den Gesamtkontext, der in den Kriterien nicht vollständig abbildbar ist. + + # --------------------------------------------------------------------------- + # BEGRUENDUNGSPFLICHT + # --------------------------------------------------------------------------- + + begruendungspflicht: + + wann: "Bei Abweichung von typischer Konstellation" + + form: "Kurze schriftliche Begründung im Portfolio-Review-Protokoll (2-3 Sätze)" + + beispiele: + + - situation: "Mehrere Services Rot, aber Empfehlung MAINTAIN" + begruendung_beispiel: | + "Obwohl 4 Services rot bewertet sind, empfehle ich MAINTAIN, weil + alle 4 bereits laufende Improvement-Maßnahmen haben, die im + nächsten Quartal wirksam werden sollen. Kein zusätzlicher + Portfolio-Handlungsbedarf." + + - situation: "Alle Services Grün, aber Empfehlung IMPROVE-ESCALATE" + begruendung_beispiel: | + "Trotz stabiler Ampel-Bewertungen empfehle ich IMPROVE-ESCALATE, + weil die Datenbasis in 8 von 20 Services 'unbekannt' enthält. + Wir brauchen eine konzertierte Aktion zur Review-Qualität." + +# ============================================================================= +# 7. ENTSCHEIDUNGSTYPEN-MAPPING +# ============================================================================= + +entscheidungstypen_mapping: + + governance_referenz: "GOV-PR-006" + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Service-Review-Entscheidungen beziehen sich auf einen einzelnen Service. + Portfolio-Review-Entscheidungen beziehen sich auf das Gesamtportfolio + oder Cluster von Services. Die Begriffe sind bewusst unterschiedlich, + um die Ebenen zu trennen. + + # --------------------------------------------------------------------------- + # MAPPING-TABELLE + # --------------------------------------------------------------------------- + + mapping: + + - service_review_entscheidung: "CONTINUE" + portfolio_aggregation: "Beitrag zu MAINTAIN" + erklaerung: | + Einzelne CONTINUE-Ergebnisse aggregieren zu MAINTAIN auf + Portfolio-Ebene, wenn keine Muster erkennbar sind. + + - service_review_entscheidung: "IMPROVEMENT (SO-geführt)" + portfolio_aggregation: "Beitrag zu MAINTAIN" + erklaerung: | + SO-geführte Improvements sind Routine und erfordern keine + Portfolio-Aktion. Der Service wird operativ betreut. + + - service_review_entscheidung: "IMPROVEMENT (ressourcenrelevant)" + portfolio_aggregation: "Einzelfall: SOR-Entscheidung. Mehrfach: Ggf. IMPROVE-ESCALATE-RESOURCE" + erklaerung: | + Ein einzelnes ressourcenrelevantes Improvement wird in der SOR + als Service-Review-Entscheidung behandelt. Wenn mehrere solche + Improvements Kapazitätskonflikte erzeugen, wird dies auf + Portfolio-Ebene als Ressourcen-Eskalation behandelt. + + - service_review_entscheidung: "REDESIGN" + portfolio_aggregation: "Einzelfall: DPM via SOR. Muster: IMPROVE-ESCALATE-STRUCTURAL" + erklaerung: | + Ein einzelnes REDESIGN ist eine Service-Entscheidung, die nach + SOR-Freigabe an DPM übergeht. Mehrere REDESIGN-Fälle mit + gemeinsamer Ursache sind ein Portfolio-Muster. + + - service_review_entscheidung: "RETIRE" + portfolio_aggregation: "RETIRE-RECOMMEND" + erklaerung: | + RETIRE-Empfehlungen aus Service-Reviews werden auf Portfolio-Ebene + aggregiert und als konsolidierte Empfehlung an MB weitergeleitet. + + # --------------------------------------------------------------------------- + # BEGRIFFLICHE ABGRENZUNG + # --------------------------------------------------------------------------- + + begriffliche_abgrenzung: + + - begriffspaar: "CONTINUE vs. MAINTAIN" + service_ebene: "CONTINUE = Einzelservice-Status ('dieser Service läuft weiter')" + portfolio_ebene: "MAINTAIN = Portfolio-Status ('das Portfolio ist stabil')" + + - begriffspaar: "IMPROVEMENT vs. IMPROVE-ESCALATE" + service_ebene: "IMPROVEMENT = Maßnahme für einen Service" + portfolio_ebene: "IMPROVE-ESCALATE = Handlungsbedarf auf Portfolio-Ebene (Muster, Ressourcen)" + + - begriffspaar: "RETIRE vs. RETIRE-RECOMMEND" + service_ebene: "RETIRE = SOR-Entscheidung für Einzelservice (führt zu DPM)" + portfolio_ebene: "RETIRE-RECOMMEND = Portfolio-Empfehlung an MB (ggf. mehrere Services)" + +# ============================================================================= +# 8. SOR-AGENDA-STRUKTUR +# ============================================================================= + +sor_agenda_struktur: + + governance_referenz: "GOV-PR-007" + + # --------------------------------------------------------------------------- + # DESIGN-PRINZIP + # --------------------------------------------------------------------------- + + design_prinzip: | + Der Portfolio-Review-Block (E2) und die Service-Review-Behandlungen + finden in derselben SOR-Sitzung statt, aber in definierter Reihenfolge. + Die Portfolio-Perspektive rahmt die Einzelentscheidungen. + + # --------------------------------------------------------------------------- + # EMPFOHLENE AGENDA-SEQUENZ + # --------------------------------------------------------------------------- + + empfohlene_agenda_sequenz: + + - block: 1 + name: "Portfolio-Status-Überblick" + dauer: "15 Minuten" + verantwortlich: "SPM" + inhalt: + - "Präsentation der aggregierten Portfolio-Sicht" + - "Ampel-Verteilung und Trends" + - "Identifizierte Muster und Auffälligkeiten" + - "Vorschau auf anstehende Einzelentscheidungen" + output: "Kontext für Einzelentscheidungen" + + - block: 2 + name: "Service-Review-Entscheidungen" + dauer: "Variable (abhängig von Anzahl)" + verantwortlich: "Betroffene Service Owner" + inhalt: + - "Behandlung einzelner Services mit SOR-Bedarf" + - "IMPROVEMENT (ressourcenrelevant)" + - "REDESIGN" + - "RETIRE" + output: "SOR-Beschlüsse je Service" + verweis: "Behandlungskategorien gemäß K-SR" + + - block: 3 + name: "Portfolio-Entscheidungen" + dauer: "15-20 Minuten" + verantwortlich: "SPM" + inhalt: + - "Übergreifende Muster aus Block 1 und 2" + - "IMPROVE-ESCALATE-Empfehlungen" + - "RETIRE-RECOMMEND (bei mehreren Services)" + - "Ressourcen-Eskalationen an MB" + output: "Portfolio-Entscheidungen, Eskalationsempfehlungen" + + - block: 4 + name: "Portfolio-Status-Bestätigung" + dauer: "5 Minuten" + verantwortlich: "SOR (Gremium)" + inhalt: + - "Formale Bestätigung des Portfolio-Status" + - "MAINTAIN oder Eskalation" + output: "Bestätigter Portfolio-Status im Protokoll" + + # --------------------------------------------------------------------------- + # BEI ÜBERLAPPUNG + # --------------------------------------------------------------------------- + + bei_ueberlappung: + + beschreibung: | + Wenn Service-Review-Entscheidungen (Block 2) ein Muster ergeben, + das im Portfolio-Block (Block 3) adressiert werden sollte, + verschiebt SPM die Einzelentscheidungen in Block 3 und behandelt + sie als Portfolio-Thema. + + beispiel: | + 3 Services haben RETIRE-Empfehlung wegen gemeinsamer Technologie-EOL. + → Nicht 3 Einzelentscheidungen in Block 2, sondern eine + Portfolio-Entscheidung "RETIRE-RECOMMEND für Technologie-X-Cluster" + in Block 3. + + entscheidungskriterium: | + SPM entscheidet bei der Agenda-Vorbereitung, ob Einzelthemen + als Cluster behandelt werden. Kriterium: Gemeinsame Ursache + oder gemeinsamer Lösungsansatz. + +# ============================================================================= +# 9. OUTPUT-ARTEFAKTE +# ============================================================================= + +output_artefakte: + + entwicklungshinweis: + status: "Arbeitsmaterialien erforderlich" + beschreibung: | + Für die praktische Umsetzung müssen Arbeitsmaterialien (Templates, + Checklisten) entwickelt werden. Die folgenden Strukturen definieren + den inhaltlichen Rahmen. + zu_entwickeln: + - "Template: SPM Quartals-Portfolio-Status" + - "Template: SPM Jahres-Portfolio-Report" + - "Checkliste: Portfolio-Review-Vorbereitung" + - "Vorlage: SOR-Protokoll-Abschnitt Portfolio-Review" + + # --------------------------------------------------------------------------- + # E2: PORTFOLIO-STATUS-ÜBERSICHT + # --------------------------------------------------------------------------- + + e2_portfolio_status_uebersicht: + + name: "SPM Quartals-Portfolio-Status" + + umfang: "1-2 Seiten" + + frequenz: "Quartalsweise" + + verantwortlich: "SPM" + + struktur: + + - abschnitt: "1. Portfolio-Übersicht" + inhalt: + - element: "Anzahl Services nach Status" + detail: "aktiv, in_transition, planned_eol, retired" + - element: "Ampel-Verteilung" + detail: "Anzahl/Prozent grün, gelb, rot" + - element: "Trend gegenüber Vorquartal" + detail: "Verbesserung, stabil, Verschlechterung" + - element: "Services mit Handlungsbedarf" + detail: "Liste der rot bewerteten Services" + + - abschnitt: "2. Auffälligkeiten und Muster" + inhalt: + - element: "Identifizierte Cluster-Probleme" + detail: "Mehrere Services mit gleichartigem Problem" + - element: "Ressourcenengpässe" + detail: "Kapazitätskonflikte, Skill-Gaps" + - element: "Daten-Gaps" + detail: "Services ohne Review, unvollständige Daten" + + - abschnitt: "3. Portfolio-Empfehlung" + inhalt: + - element: "Portfolio-Status" + detail: "MAINTAIN / IMPROVE-ESCALATE / RETIRE-RECOMMEND" + - element: "Begründung" + detail: "Kurze Erläuterung der Empfehlung" + - element: "Ggf. Eskalationen" + detail: "An MB weiterzuleitende Themen" + + - abschnitt: "4. Input für DPM-Review" + inhalt: + - element: "Service-Impact geplanter Demands" + detail: "Bewertung aus Portfolio-Perspektive" + - element: "Kapazitäts-Einschätzung" + detail: "Verfügbarkeit für neue Services/Projekte" + - element: "Transition-Pipeline" + detail: "Services in Transition, geplante Go-Lives" + + # --------------------------------------------------------------------------- + # E1: JAHRES-PORTFOLIO-REPORT + # --------------------------------------------------------------------------- + + e1_jahresbericht: + + name: "SPM Jahres-Portfolio-Report" + + umfang: "3-5 Seiten + Anhang" + + frequenz: "Jährlich (Q4)" + + verantwortlich: "SPM" + + struktur: + + - abschnitt: "Executive Summary" + umfang: "0.5 Seiten" + inhalt: + - "Zentrale Erkenntnisse des Jahres" + - "Top-3-Empfehlungen" + + - abschnitt: "Portfolio-Entwicklung im Jahresverlauf" + umfang: "1 Seite" + inhalt: + - "Anzahl Services (Zu-/Abgänge)" + - "Ampel-Entwicklung über 4 Quartale (Grafik)" + - "Abgeschlossene Improvements" + - "Durchgeführte Retirements" + + - abschnitt: "Strategische Erkenntnisse" + umfang: "1 Seite" + inhalt: + - "Technologie-Trends (EOL, Modernisierungsbedarf)" + - "Kapazitäts-Entwicklung und -Prognose" + - "Stakeholder-Zufriedenheit (VoC-Aggregation, falls verfügbar)" + - "Governance-Wirksamkeit (Review-Durchführungsquote)" + + - abschnitt: "Risiken und Chancen" + umfang: "0.5 Seiten" + inhalt: + - "Identifizierte Risiko-Cluster" + - "Konsolidierungspotenziale" + - "Strategische Lücken" + + - abschnitt: "Empfehlungen für Strategie" + umfang: "0.5-1 Seite" + inhalt: + - "Priorisierte Handlungsfelder" + - "Ressourcenbedarf-Prognose" + - "Empfehlungen für IT-Strategie / Vision Board" + + - anhang: "Detail-Daten je Service" + umfang: "Variable" + inhalt: + - "Tabelle aller Services mit Jahres-Bewertung" + - "Maßnahmen-Übersicht" + + detail_struktur_status: "Post-MVP zu detaillieren" + +# ============================================================================= +# 10. ABGRENZUNGEN +# ============================================================================= + +abgrenzungen: + + # --------------------------------------------------------------------------- + # SSM QUARTALS-REVIEW + # --------------------------------------------------------------------------- + + ssm_quartals_review: + + dokument: "ssm_governance.yaml" + + ssm_fokus: "Support-Performance (Incident, Request, Problem)" + ssm_perspektive: "Operativ-taktisch" + ssm_teilnehmer: "Support-Organisation + Service Owner" + ssm_output: "Support-Verbesserungen, Prozess-Anpassungen" + + spm_fokus: "Portfolio-Gesundheit (Service-Performance aggregiert)" + spm_perspektive: "Taktisch-strategisch" + spm_teilnehmer: "SOR-Teilnehmer + SPM" + spm_output: "Portfolio-Status, Eskalationen" + + beziehung: | + Der SSM-Quartals-Review liefert Support-Perspektive, die in + Service-Reviews (Dimension SR-D2: Betriebsstabilität) einfließt. + Der SPM-Portfolio-Review nutzt die aggregierten Service-Review- + Ergebnisse. Keine direkte Abhängigkeit, aber inhaltliche Verknüpfung + über die Service-Ebene. + + sequenz_empfehlung: | + SSM-Quartals-Review idealerweise vor Service-Reviews abschließen, + damit Support-Erkenntnisse in die Service-Bewertung (SR-D2) + einfließen können. + + # --------------------------------------------------------------------------- + # DPM-PORTFOLIO-REVIEW + # --------------------------------------------------------------------------- + + dpm_portfolio_review: + + dokument: "dpm_demand-portfolio-review.yaml" + + dpm_fokus: "Demand-Dynamik, Priorisierung, Workflow-Optimierung" + dpm_perspektive: "Demand-Steuerung" + + spm_fokus: "Service-Portfolio-Gesundheit" + spm_perspektive: "Service-Steuerung" + + beziehung: | + SPM ist Teilnehmer im DPM-Portfolio-Review und liefert die + Service-Perspektive. Die Reviews sind komplementär, nicht + konkurrierend. Der SPM E2 findet vor dem DPM-Review statt, + damit Erkenntnisse einfließen können. + + informationsfluss: + von_spm_zu_dpm: + - "Service-Impact neuer Demands" + - "Betriebsbereitschaft für Übergaben" + - "Portfolio-Kapazitäts-Einschätzung" + von_dpm_zu_spm: + - "Geplante Service-Neueinführungen" + - "Demand-Trends mit Service-Relevanz" + +# ============================================================================= +# 11. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + # --------------------------------------------------------------------------- + # INPUT-SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + input: + + - quelle: "Service Owner" + was: "Service-Review-Ergebnisse" + artefakt: "Aktualisierte Service-Steckbriefe" + frequenz: "Quartalsweise" + deadline: "T+7 nach Quartalsende" + pflicht: true + + - quelle: "SSM / Support" + was: "Support-KPIs (aggregiert)" + artefakt: "Support-Auswertung" + frequenz: "Quartalsweise" + hinweis: "Falls SSM-Quartals-Review vor Service-Reviews abgeschlossen" + pflicht: false + + - quelle: "SHM" + was: "VoC-Erkenntnisse" + artefakt: "Cluster D2 (Service-Qualität)" + frequenz: "Quartalsweise" + hinweis: "Aus SHM E2-Review" + pflicht: false + + - quelle: "Service-Katalog" + was: "Service-Status-Übersicht" + artefakt: "Service-Liste mit Status" + frequenz: "Laufend aktuell" + pflicht: true + + # --------------------------------------------------------------------------- + # OUTPUT-SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + output: + + - ziel: "SOR" + was: "Portfolio-Review-Vorlage" + artefakt: "Portfolio-Status-Übersicht" + frequenz: "Quartalsweise" + bedingung: "Jedes Quartal" + + - ziel: "DPM-Portfolio-Review" + was: "SPM-Input" + artefakt: "Portfolio-Erkenntnisse, Kapazitäts-Einschätzung" + frequenz: "Quartalsweise" + bedingung: "Jedes Quartal" + + - ziel: "Mission Board" + was: "Eskalationen" + artefakt: "Eskalations-Empfehlung" + frequenz: "Anlassbezogen" + bedingung: "Bei IMPROVE-ESCALATE-RESOURCE oder RETIRE-RECOMMEND" + + - ziel: "Vision Board" + was: "Strategischer Input" + artefakt: "SPM Jahres-Portfolio-Report" + frequenz: "Jährlich (Q4)" + bedingung: "E1-Zyklus" + + - ziel: "Service Owner (bei Mustern)" + was: "Koordinierte Aktion" + artefakt: "Maßnahmen-Empfehlung" + frequenz: "Anlassbezogen" + bedingung: "Bei IMPROVE-ESCALATE-OPERATIONAL" + +# ============================================================================= +# 12. ROLLEN UND VERANTWORTLICHKEITEN +# ============================================================================= + +rollen: + + service_portfolio_manager: + kurzbezeichnung: "SPM" + verantwortung: + - "Sammlung und Aggregation der Service-Review-Ergebnisse" + - "Erstellung der Portfolio-Status-Übersicht (E2)" + - "Vorbereitung und Präsentation des Portfolio-Blocks in SOR" + - "Identifikation von Mustern und Auffälligkeiten" + - "Formulierung der Portfolio-Empfehlung" + - "Erstellung des Jahres-Portfolio-Reports (E1)" + - "Koordination bei IMPROVE-ESCALATE-OPERATIONAL" + - "Lieferung des SPM-Inputs für DPM-Review" + raci: "A/R für Portfolio-Review-Durchführung" + + sor: + kurzbezeichnung: "SOR" + typ: "Gremium" + verantwortung: + - "Behandlung des Portfolio-Review-Blocks" + - "Entscheidung bei Service-Reviews mit SOR-Bedarf" + - "Bestätigung des Portfolio-Status" + - "Eskalationsentscheidungen an MB" + raci: "A für Portfolio-Governance-Entscheidungen" + + service_owner: + kurzbezeichnung: "SO" + verantwortung: + - "Durchführung des quartalsweisen Service-Reviews" + - "Aktualisierung des Service-Steckbriefs" + - "Lieferung der Datenpunkte an SPM (via Steckbrief)" + - "Umsetzung von IMPROVE-ESCALATE-OPERATIONAL-Maßnahmen" + raci: "R für Service-Review-Input" + + mission_board: + kurzbezeichnung: "MB" + typ: "Gremium" + verantwortung: + - "Entscheidung bei RETIRE-RECOMMEND" + - "Entscheidung bei Ressourcen-Eskalationen" + - "Strategische Portfolio-Entscheidungen" + raci: "A für eskalierte Portfolio-Entscheidungen" + + vision_board: + kurzbezeichnung: "VB" + typ: "Gremium" + verantwortung: + - "Entgegennahme des E1-Jahresberichts" + - "Strategische Richtungsentscheidungen basierend auf Portfolio-Erkenntnissen" + raci: "A für strategische Ausrichtung" + +# ============================================================================= +# 13. OFFENE PUNKTE UND POST-MVP +# ============================================================================= + +offene_punkte: + + # --------------------------------------------------------------------------- + # IM MVP NICHT ADRESSIERT + # --------------------------------------------------------------------------- + + im_mvp_nicht_adressiert: + + - punkt: "Quantitative Portfolio-KPIs" + beschreibung: | + Das MVP arbeitet primär qualitativ (Ampel-Aggregation). + Quantitative Portfolio-KPIs (z.B. Portfolio-TCO, durchschnittliche + Service-Alter, Technologie-Diversität) können später ergänzt werden. + status: "Post-MVP-Erweiterung" + + - punkt: "Tool-gestützte Aggregation" + beschreibung: | + Im MVP erfolgt die Aggregation manuell durch SPM. Bei wachsendem + Portfolio kann Tool-Unterstützung (Dashboard, automatische + Datenextraktion aus Steckbriefen) sinnvoll werden. + status: "Post-MVP-Erweiterung" + + - punkt: "Benchmark-Definition" + beschreibung: | + Zielwerte für Portfolio-Gesundheit (z.B. "max. 10% rot") sind + im MVP nicht definiert. Erst nach Baseline-Erhebung über 2-3 + Quartale sinnvoll. + status: "Nach Pilotphase zu definieren" + + # --------------------------------------------------------------------------- + # VALIDIERUNGSBEDARF + # --------------------------------------------------------------------------- + + validierungsbedarf: + + - punkt: "Zeitliche Synchronisation" + beschreibung: | + Die definierten Zeitfenster (T+1 bis T+14) sind Modellannahmen. + Die Praktikabilität muss in der Praxis validiert werden. + methode: "Pilotierung über 2 Quartale" + verantwortlich: "DIGIT" + + - punkt: "SOR-Agenda-Struktur" + beschreibung: | + Die 4-Block-Struktur für SOR-Sitzungen muss mit der tatsächlichen + SOR-Praxis abgestimmt werden. + methode: "Abstimmung mit SOR-Leitung" + + - punkt: "Aggregationslogik" + beschreibung: | + Die Orientierungskriterien (AK-01 bis AK-06) müssen sich in der + Praxis als handhabbar erweisen. + methode: "Review nach erstem Jahres-Zyklus" + + # --------------------------------------------------------------------------- + # ARBEITSMATERIALIEN + # --------------------------------------------------------------------------- + + arbeitsmaterialien_zu_entwickeln: + + status: "Ausstehend" + + materialien: + + - id: "AM-01" + name: "Template: SPM Quartals-Portfolio-Status" + format: "Word/Markdown" + prioritaet: "Hoch" + beschreibung: "Vorlage für E2-Output gemäß Abschnitt 9" + + - id: "AM-02" + name: "Template: SPM Jahres-Portfolio-Report" + format: "Word/Markdown" + prioritaet: "Mittel" + beschreibung: "Vorlage für E1-Output gemäß Abschnitt 9" + + - id: "AM-03" + name: "Checkliste: Portfolio-Review-Vorbereitung" + format: "Checklist" + prioritaet: "Hoch" + beschreibung: "SPM-Checkliste für T+8 bis T+10" + + - id: "AM-04" + name: "Vorlage: SOR-Protokoll-Abschnitt Portfolio-Review" + format: "Word/Markdown" + prioritaet: "Mittel" + beschreibung: "Standard-Abschnitt für SOR-Protokoll" + + - id: "AM-05" + name: "Dashboard-Konzept: Portfolio-Übersicht" + format: "Konzept/Excel" + prioritaet: "Niedrig" + beschreibung: "Optional: Visualisierung der Portfolio-Daten" + +# ============================================================================= +# 14. GOVERNANCE-ENTSCHEIDUNGEN (ZUSAMMENFASSUNG) +# ============================================================================= + +governance_entscheidungen_log: + + - id: "GOV-PR-001" + datum: "2025-12-17" + frage: "Welche Datenbasis nutzt der Portfolio-Review?" + entscheidung: | + Datenpunkte (DP-01 bis DP-05) werden aus Service-Reviews abgeleitet, + nicht separat erhoben. Minimale quantitative Basis ergänzt durch + qualitative Einschätzung. Daten-Gaps werden explizit markiert. + begruendung: | + Vermeidet Doppelerhebung, nutzt bestehenden Service-Review-Output. + Konsistent mit der verfügbaren Datenbasis im MVP. + confidence: "80%" + status: "final" + + - id: "GOV-PR-002" + datum: "2025-12-17" + frage: "Wie ist der Portfolio-Review governance-seitig eingebettet?" + entscheidung: | + Zweistufiges Modell: E2 quartalsweise in SOR (Portfolio-Block), + E1 jährlich als Report für Vision Board. Kein eigenständiges + Gremienformat. Integration als Input in DPM-Review. + begruendung: | + Vermeidet Format-Inflation, nutzt bestehende Strukturen. + Konsistent mit E1/E2-Architektur in SHM und DPM. + confidence: "85%" + status: "final" + + - id: "GOV-PR-003" + datum: "2025-12-17" + frage: "Wie ist die zeitliche Synchronisation der Reviews?" + entscheidung: | + Definierte Zeitfenster: Service-Reviews (T+1 bis T+7), + SPM-Aggregation (T+8 bis T+10), SOR mit Portfolio-Block (T+10 bis T+12), + DPM-Review (T+12 bis T+14). + begruendung: | + Ermöglicht sequentielle Aggregation mit Puffer. Konsistent mit + DPM-Review-Zeitplanung. + confidence: "75%" + hinweis: "Modellannahme – Validierung durch DIGIT erforderlich" + status: "final" + + - id: "GOV-PR-004" + datum: "2025-12-17" + frage: "Welche Entscheidungstypen gibt es auf Portfolio-Ebene?" + entscheidung: | + Drei Typen: MAINTAIN (Bestätigung), IMPROVE-ESCALATE (mit Varianten: + Operational, Structural, Resource), RETIRE-RECOMMEND. EXPAND, + TRANSFORM, CONSOLIDATE sind keine Portfolio-Review-Entscheidungen. + begruendung: | + Klare Abgrenzung zu Demand-Lifecycle. Portfolio-Review identifiziert + und eskaliert, aber generiert keine neuen Demands direkt. + confidence: "85%" + status: "final" + + - id: "GOV-PR-005" + datum: "2025-12-17" + frage: "Wie werden Service-Review-Ergebnisse aggregiert?" + entscheidung: | + Orientierungskriterien (AK-01 bis AK-06) mit Urteilsvorbehalt. + Keine mathematische Formel. Bei Abweichung Begründungspflicht. + begruendung: | + Konsistent mit Service-Review-Konzept. Vermeidet Schein-Objektivität, + erhält Flexibilität für Kontextberücksichtigung. + confidence: "75%" + status: "final" + + - id: "GOV-PR-006" + datum: "2025-12-17" + frage: "Wie verhalten sich Service-Review- und Portfolio-Review-Entscheidungen?" + entscheidung: | + Explizites Mapping: CONTINUE → MAINTAIN, IMPROVEMENT → ggf. IMPROVE-ESCALATE, + RETIRE → RETIRE-RECOMMEND. Begriffe bewusst unterschiedlich für Ebenen-Trennung. + begruendung: | + Vermeidet Begriffsverwirrung, macht Aggregationslogik explizit. + confidence: "90%" + status: "final" + + - id: "GOV-PR-007" + datum: "2025-12-17" + frage: "Wie ist die SOR-Agenda für Reviews strukturiert?" + entscheidung: | + 4-Block-Struktur: (1) Portfolio-Überblick, (2) Service-Review-Entscheidungen, + (3) Portfolio-Entscheidungen, (4) Status-Bestätigung. Bei Überlappung + werden Einzelthemen als Cluster behandelt. + begruendung: | + Portfolio-Perspektive rahmt Einzelentscheidungen. Vermeidet + redundante Behandlung bei Mustern. + confidence: "80%" + status: "final" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "0.1" + datum: "2025-12-15" + aenderung: "Placeholder erstellt mit Gliederungsskelett" + autor: "DIGITOM-Projekt" + + - version: "1.0" + datum: "2025-12-17" + aenderung: | + Vollständige Ausarbeitung basierend auf: + - Klärungsfragen KF1-KF4 (Zweck, Datenbasis, Governance, Entscheidungstypen) + - Modellierungsreife-Prüfung (7 Punkte) + - Synchronisation mit Service-Review-Konzept (K-SR) autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml index f2c23a1..0f12c24 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml @@ -1,1158 +1,1158 @@ -# ============================================================================= -# SERVICE OPERATIONS RUNDE (SOR) – GESCHÄFTSORDNUNG -# ============================================================================= -# -# Geschäftsordnung der Service Operations Runde (SOR). -# Definiert Zweck, Zusammensetzung, Arbeitsweise und Entscheidungsverfahren. -# -# Status: Draft (zur Validierung mit DIGIT) -# ============================================================================= - -metadata: - id: "G-SOR" - typ: "geschaeftsordnung" - gremium_id: "sor" - gremium_name: "Service Operations Runde" - aliases: ["SOR", "Service-Runde"] - version: "1.4" - status: "draft" - erstellt: "2025-12-17" - aktualisiert: "2026-01-31" - gueltig_ab: "[Datum nach Freigabe]" - geltungsbereich: "DIGITOM / Service-Portfolio-Management" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "geschaeftsordnung" - - abstimmung: - sparring_mit: ["dpm", "shm"] - abgestimmt_mit: [] - inhaltlich_abgenommen_durch: [] - status: "in_abstimmung" - - kontext_tags: - - "service-portfolio-management" - - "governance" - - "entscheidungsgremium" - - "service-lifecycle" - - referenzen: - taxonomie: "00_meta/digitom_taxonomie.yaml → gremium" - dsr_go: "01_demand-portfolio-management/dpm_dsr-go.yaml" - spm_rollen: "02_service-lifecycle-blueprint/spm_rollen.yaml" - service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" - service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml" - -# ============================================================================= -# 1. ZWECK UND GELTUNGSBEREICH -# ============================================================================= - -zweck: - - kurzform: "Service-Portfolio-Governance und operative Koordination" - - beschreibung: | - Die Service Operations Runde (SOR) ist das zentrale Gremium für - Service-Portfolio-Angelegenheiten unterhalb des Mission Boards. - - Sie vereint zwei Funktionen: - (1) Entscheidungsfunktion: Governance-Entscheidungen zu Services - (2) Koordinationsfunktion: Abstimmung zwischen Service-Ownership, - Betrieb und Support - - Die Bezeichnung "Operations" bezieht sich auf den Fokus auf aktive - Services im Betrieb sowie die operative Koordination – nicht auf - die Ebene in der Governance-Hierarchie. - - funktion: | - Brücke zwischen Service-Entwicklung/-Transition und Service-Betrieb. - Steuerung des Service-Portfolios durch definierte Entscheidungstypen. - Koordination der operativen Zusammenarbeit im Service-Lifecycle. - - verankerung: "Koordinatives Gremium im DIGITOM (gleiche Ebene wie DSR)" - - governance_ebene: "koordinativ" - - regelungsumfang: - - "Arbeitsweise der SOR" - - "Entscheidungsverfahren" - - "Entscheidungstypen im Service-Lifecycle" - - "Koordination Service/Betrieb/Support" - - "Schnittstellen zu anderen Gremien und Funktionen" - -# ============================================================================= -# 2. MANDAT UND ABGRENZUNG -# ============================================================================= - -mandat: - - umfasst: - - entscheidungen: - - gegenstand: "Service-Aktivierungen (Go-Live-Freigabe)" - referenz: "Gate 3 der Service Transition (tr_11)" - governance_referenz: "GOV-TR-002" - - - gegenstand: "Service-Review-Entscheidungen" - beschreibung: "Behandlung von IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE" - referenz: "spm_konzept_service-review.yaml" - governance_referenz: "GOV-SR-004" - - - gegenstand: "Major-Change-Freigaben an Services" - beschreibung: "Wesentliche Änderungen an bestehenden Services" - referenz: "GOV-TR-003" - - koordination: - - gegenstand: "Status-Abstimmung Betrieb und Support" - beschreibung: "Regelmäßiger Austausch zu Betriebsstatus, Support-Situation, Kapazitäten" - - - gegenstand: "Klärungsbedarfe aus anderen Funktionen" - beschreibung: "Themen, die von SHM, DPM oder anderen eingebracht werden" - beispiele: - - "Unklare Servicezuständigkeiten" - - "Abstimmungsbedarf bei Service-Änderungen" - - "Eskalationen aus dem Stakeholder-Kontext" - - - gegenstand: "Operative Abstimmung im Service-Lifecycle" - beschreibung: "Koordination zwischen SO, Betrieb und Support bei Übergängen" - - umfasst_nicht: - - - gegenstand: "Demand-Entscheidungen" - zustaendig: "DPM (direkt)" - abgrenzung: "Demands gehen direkt an DPM, SOR bestätigt Changes" - - - gegenstand: "Routing-Empfehlungen (Service vs. Demand)" - zustaendig: "Service Owner (Empfehlung) → SOR/DSR (formelle Bestätigung)" - abgrenzung: "SO gibt Routing-Empfehlung ab bilateral mit SPM. SOR bestätigt formal RUN/Change-Empfehlungen. Demands gehen direkt an DPM (kein DSR-Weg). Weiterbearbeitung erfolgt 'als ob' bereits entschieden." - governance_referenz: "GOV-SHM-029 (aktualisiert GOV-SOR-001)" - - - gegenstand: "Ressourcenallokation über Abteilungsgrenzen" - zustaendig: "Mission Board" - abgrenzung: "SOR eskaliert bei Ressourcenkonflikten" - - - gegenstand: "Strategische Portfolio-Ausrichtung" - zustaendig: "Mission Board / Vision Board" - abgrenzung: "SOR setzt strategische Vorgaben um, definiert sie nicht" - - - gegenstand: "Operative Betriebskoordination im Tagesgeschäft" - zustaendig: "Operations Manager" - abgrenzung: "SOR ist Governance-Gremium, nicht operatives Jour-Fixe" - - - gegenstand: "Irreversible Service-Ablehnung" - zustaendig: "Mission Board" - abgrenzung: "Siehe offene_punkte → MVP-Scope" - - abgrenzung_zu_anderen_gremien: - - dsr: - beschreibung: "Demands gehen direkt an DPM. DSR nur Portfolio-Governance. SOR bestätigt Changes." - schnittstelle: "Bei REDESIGN/RETIRE übergibt SOR an DPM (neuer Demand)" - routing_regel: | - Routing-Klärung erfolgt bilateral mit dem Service Owner (ROUTE-SO). - SO gibt Routing-Empfehlung ab (nicht endgültige Entscheidung). - SO wird von SPM unterstützt. SOR bestätigt formal RUN/Change-Empfehlungen, - Demands gehen direkt an DPM. Kein DSR-Routing mehr. - "als ob" bereits entschieden, während auf formelle Gremienbestätigung - im nächsten Takt gewartet wird. - - mission_board: - beschreibung: "MB ist Eskalationsinstanz für SOR" - eskalation_bei: - - "Ressourcenkonflikte über SOR-Mandat hinaus" - - "Strategische Tragweite" - - "Anhaltender Dissens nach Einwand-Verfahren" - - "Irreversible Service-Ablehnung (Post-MVP)" - - ops_manager: - beschreibung: "Ops Manager koordiniert Tagesbetrieb, SOR entscheidet Governance" - abgrenzung: | - Operations Manager ist ständiges SOR-Mitglied und bringt die - Betriebsperspektive ein. Die operative Koordination im Tagesgeschäft - liegt beim Ops Manager, nicht bei der SOR. - -# ============================================================================= -# 3. AUFGABEN UND KOMPETENZEN -# ============================================================================= - -aufgaben: - - charakter: "Hybrides Gremium mit zwei Funktionsbereichen" - - # --------------------------------------------------------------------------- - # 3.1 ENTSCHEIDUNGSFUNKTION - # --------------------------------------------------------------------------- - - entscheidungsfunktion: - - beschreibung: | - Die SOR trifft Governance-Entscheidungen zu Services innerhalb - ihres Mandats. Entscheidungen folgen dem Konsent-Prinzip. - - entscheidungstypen: - - - typ: "go_live_freigabe" - name: "Go-Live-Freigabe (Gate 3)" - beschreibung: "Formale Freigabe zur Aktivierung eines neuen oder wesentlich geänderten Services" - lifecycle_aktivitaet: "tr_11" - - entscheidungsoptionen: - - option: "go_live" - beschreibung: "Service wird aktiviert, Aufnahme ins Portfolio" - naechster_schritt: "Katalog-Aktivierung, ELS-Start" - - - option: "go_live_mit_auflagen" - beschreibung: "Aktivierung unter Bedingungen" - naechster_schritt: "Go-Live erfolgt, Auflagen werden im ELS überwacht" - - - option: "zurueck_an_transition" - beschreibung: "Wesentliche Mängel, weitere Nacharbeit erforderlich" - naechster_schritt: "SO behebt Mängel, erneutes Gate 2" - - voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" - governance_referenz: "GOV-TR-002, GOV-TR-005" - konzept_referenz: "spm_konzept_service-transition.yaml" - - - typ: "service_review" - name: "Service-Review-Entscheidung" - beschreibung: "Behandlung von Review-Ergebnissen, die SOR-Governance erfordern" - - behandlungskategorien: - - - kategorie: "Kenntnisnahme" - sor_behandlung: false - gilt_fuer: - - "CONTINUE" - - "IMPROVEMENT (SO-geführt, ressourcenneutral)" - verfahren: "SO dokumentiert im Steckbrief, informiert SPM" - - - kategorie: "Operative Entscheidung" - sor_behandlung: true - agenda_block: "Entscheidungen" - gilt_fuer: - - "IMPROVEMENT (ressourcenrelevant)" - entscheidungsoptionen: - - "Freigabe der Improvement-Maßnahmen" - - "Freigabe mit Auflagen" - - "Zurückweisung (mit Begründung)" - - "Eskalation an MB (bei Ressourcenkonflikt)" - - - kategorie: "Lifecycle-Weichenstellung" - sor_behandlung: true - agenda_block: "Entscheidungen" - gilt_fuer: - - "REDESIGN" - - "RETIRE" - - beschreibung: | - Die SOR prüft, ob ein Service-Review-Ergebnis mit strategischer - Tragweite (REDESIGN, RETIRE) reif für die Übergabe an den - Demand-Prozess ist. Die SOR trifft keine inhaltlich-strategische - Entscheidung ("Soll der Service stillgelegt werden?"), sondern - eine Verfahrensentscheidung ("Ist das Thema ausreichend geprüft - für den nächsten Schritt?"). - - Die eigentliche strategische Entscheidung erfolgt im Demand-Lifecycle - (DSR) oder bei übergreifender Tragweite im Mission Board. - - entscheidungsoptionen: - - option: "freigabe_uebergabe" - beschreibung: "Review-Ergebnis ist ausreichend fundiert" - naechster_schritt: "Übergabe an DPM als Demand" - - - option: "zurueck_an_so" - beschreibung: "Weitere Prüfung oder Substantiierung erforderlich" - naechster_schritt: "SO überarbeitet Review-Ergebnis" - - - option: "eskalation_mb" - beschreibung: "Tragweite übersteigt SOR-Mandat" - trigger: - - "Abteilungsübergreifende Ressourcenimplikationen" - - "Politische Sensibilität" - - "Grundsatzfrage zur Portfolio-Strategie" - naechster_schritt: "Mission Board entscheidet über Verfahren" - - output_bei_freigabe: - redesign: "Demand an DPM (Klassifizierung: Neugestaltung)" - retire: "Demand an DPM (Stilllegungsprojekt)" - - abgrenzung: | - Die SOR entscheidet NICHT über das "Ob" (strategische Frage), - sondern über das "Ob reif" (Verfahrensfrage). - - voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" - governance_referenz: "GOV-SR-004" - konzept_referenz: "spm_konzept_service-review.yaml" - - - typ: "major_change" - name: "Major-Change-Autorisierung und -Freigabe" - beschreibung: "Autorisierung und Freigabe wesentlicher Änderungen an bestehenden Services" - - major_kriterien: - - "Änderung der Service-Definition (Scope, Zielgruppe, Kernfunktionalität)" - - "Änderung der SLA/SLO-Vereinbarungen" - - "Signifikante Architektur-Änderung" - - zwei_entscheidungspunkte: - beschreibung: | - Major Changes erfordern zwei SOR-Entscheidungen: - 1. Entry-Autorisierung: Freigabe für den Eintritt in die Transition - 2. Go-Live-Freigabe (Gate 3): Freigabe für den produktiven Betrieb - - Dies unterscheidet Major Changes von Normal Changes, bei denen - der SO allein entscheidet. - - entry_autorisierung: - zweck: "Prüfung ob Major Change in Transition gehen darf" - entscheidungsoptionen: - - "Freigabe für Transition" - - "Freigabe mit Auflagen" - - "Ablehnung" - - go_live_freigabe: - zweck: "Freigabe nach Abschluss der Transition-Aktivitäten" - entspricht: "Gate 3 (tr_11)" - entscheidungsoptionen: - - "Go-Live" - - "Go-Live mit Auflagen" - - "Zurück an Transition" - - "Ablehnung" - - voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" - governance_referenz: "GOV-TR-003" - konzept_referenz: "spm_practice_change-enablement.yaml" - - abgrenzung: | - Minor Changes laufen über Change Enablement (Standard/Normal Change) - und erfordern keine SOR-Behandlung. Der wesentliche Unterschied: - Normal Change = SO-Einzelentscheidung - Major Change = SOR-Autorisierung (Entry) + SOR-Freigabe (Gate 3) - - # --------------------------------------------------------------------------- - # 3.2 KOORDINATIONSFUNKTION - # --------------------------------------------------------------------------- - - koordinationsfunktion: - - beschreibung: | - Die SOR dient als Forum für die operative Abstimmung zwischen - Service-Ownership, Betrieb und Support. Koordinationsthemen haben - keinen Entscheidungscharakter, sondern dienen dem Informationsaustausch - und der Klärung. - - aktivitaeten: - - - name: "Status-Austausch" - beschreibung: "Regelmäßiger Austausch zu Betrieb und Support" - themen: - - "Betriebsstatus kritischer Services" - - "Support-Auslastung und Trends" - - "Kapazitätssituation" - - "Anstehende Wartungsfenster" - - - name: "Klärungsbedarfe" - beschreibung: "Behandlung von Themen, die Klärung erfordern" - einbringung_durch: - - "Ständige Mitglieder (SPM, Ops Mgr, Sup Mgr, SHM)" - - "Service Owner (über SPM)" - - "Andere Funktionen (über SPM)" - beispiele: - - "Unklare Servicezuständigkeiten" - - "Abstimmungsbedarf bei Service-Übergängen" - - "Eskalationen aus Stakeholder-Interaktionen (via SHM)" - - - name: "Lifecycle-Koordination" - beschreibung: "Abstimmung bei Übergängen im Service-Lifecycle" - themen: - - "Vorbereitung auf anstehende Go-Lives" - - "ELS-Status und Exit-Planung" - - "Übergabe von Services zwischen Verantwortlichen" - -# ============================================================================= -# 4. ZUSAMMENSETZUNG -# ============================================================================= - -zusammensetzung: - - # --------------------------------------------------------------------------- - # 4.1 STÄNDIGE MITGLIEDER - # --------------------------------------------------------------------------- - - staendige_mitglieder: - anzahl: 5 - - rationale: | - Der Kern deckt die zentralen Perspektiven des Service-Lifecycle ab: - - Portfolio-Steuerung (SPM) - - Betrieb Infrastruktur (AL Basis & Cloud) - - Betrieb Anwendungen (AL Applikationen) - - Support (Sup Mgr) - - Stakeholder/Kunde (SHM) - - Die beiden Betriebsperspektiven sind gleichwertig vertreten, da Services - sowohl infrastruktur- als auch anwendungsseitige Aspekte haben. Dies - respektiert die bestehende Organisationsstruktur bei DIGIT ohne neue - Hierarchieebene zu schaffen. - - Service Owner sind service-spezifisch und daher variable Mitglieder. - - design_prinzipien_abgleich: | - Die Zusammensetzung folgt den DIGITOM-Designprinzipien: - - Participatory Design: Beide Abteilungen gleichberechtigt eingebunden - - Provisorische Strukturen: Review nach 6 Monaten vorgesehen - - Explizites System: Klare Regelung statt informeller Absprache - - Keine neue Hierarchie: Bestehende AL-Rollen, keine Koordinationsebene - - mitglieder: - - - rolle_id: "spm" - rolle_name: "Service-Portfolio-Manager" - funktion: "vorsitz" - stimmberechtigt: true - begruendung: "Portfolio-Perspektive, Koordination, Verfahrenshoheit" - verantwortlichkeiten: - - "Einberufung und Leitung der Sitzungen" - - "Tagesordnung erstellen" - - "Protokollführung (oder Delegation)" - - "Moderation bei Dissens" - - "Entscheidung über Vertagung oder Eskalation" - - - rolle_id: "al_basis_cloud" - rolle_name: "Abteilungsleitung Basis & Cloud" - funktion: "mitglied" - stimmberechtigt: true - begruendung: "Betriebsperspektive Infrastruktur, Ressourcen-Realität, Betriebsreife-Bewertung für Infrastruktur-Services" - themengruppen: - - "Netzwerk" - - "Cloud" - - "Deployment" - - "Infrastruktur-Betrieb" - - - rolle_id: "al_applikationen" - rolle_name: "Abteilungsleitung Applikationen" - funktion: "mitglied" - stimmberechtigt: true - begruendung: "Betriebsperspektive Anwendungen, Ressourcen-Realität, Betriebsreife-Bewertung für Anwendungs-Services" - themengruppen: - - "SAP" - - "Ennaio" - - "Fachverfahren" - - "Anwendungs-Betrieb" - - - rolle_id: "sup_mgr" - rolle_name: "Support Manager" - funktion: "mitglied" - stimmberechtigt: true - begruendung: "Support-Perspektive, Kundennähe, Support-Readiness-Bewertung" - - - rolle_id: "shm" - rolle_name: "Stakeholder-Management" - funktion: "mitglied" - stimmberechtigt: true - begruendung: "Stakeholder-Perspektive, Kundenanwalt, Einbringung von Klärungsbedarfen" - rolle_in_sor: | - SHM vertritt die Stakeholder-Perspektive (analog zur Rolle in der DSR). - Zusätzlich kann SHM Klärungsbedarfe einbringen, die aus der - Stakeholder-Interaktion entstehen. - - # --------------------------------------------------------------------------- - # 4.2 SERVICE OWNER BEI SERVICE-SPEZIFISCHEN ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - service_owner_beteiligung: - - grundregel: | - Bei service-spezifischen Entscheidungen (Go-Live, Review, Major Change) - ist die Anwesenheit des betroffenen Service Owners Pflicht. - Der SO ist dann stimmberechtigt. - - pflicht_bei: - - "Go-Live-Freigabe (Gate 2)" - - "Service-Review-Entscheidung (operativ oder strategisch)" - - "Major-Change-Freigabe" - - nicht_erforderlich_bei: - - "Portfolio-übergreifende Entscheidungen" - - "Generische Prozess-Entscheidungen" - - "Koordinationsthemen ohne Entscheidungscharakter" - - status: "stimmberechtigt" - - einladung_durch: "spm" - - konsequenz_bei_abwesenheit: | - Kann der relevante SO nicht teilnehmen, wird die Entscheidung vertagt. - In dringenden Fällen kann der SO eine Vertretung mit - Entscheidungsbefugnis benennen. - - # --------------------------------------------------------------------------- - # 4.3 BERATENDE TEILNAHME - # --------------------------------------------------------------------------- - - beratende_teilnahme: - erlaubt: true - status: "beratend" - stimmberechtigt: false - - typische_teilnehmende: - - rolle: "IT-Architektur" - bei: "Architektur-relevanten Entscheidungen, Major Changes mit Architektur-Impact" - - - rolle: "Projektleiter" - bei: "Go-Live-Entscheidungen zu Projekten in Transition" - - - rolle: "DPM" - bei: "REDESIGN/RETIRE-Entscheidungen (Übergabe-Abstimmung)" - - - rolle: "Fachexperten" - bei: "Spezifische technische oder fachliche Fragestellungen" - - einladung_durch: "spm" - - vorlaufzeit: "Einladung mit Tagesordnung (mind. 24h vor Sitzung)" - - # --------------------------------------------------------------------------- - # 4.4 VERTRETUNGSREGELUNG - # --------------------------------------------------------------------------- - - vertretungsregelung: - - prinzip: "flexibel" - - beschreibung: | - Ständige Mitglieder benennen ihre Vertretung flexibel für einzelne - Sitzungen. Die Vertretung muss vor der Sitzung benannt werden. - - vertretungs_kompetenzen: | - Vertretungen sind vollständig stimmberechtigt und haben die vollen - Kompetenzen der vertretenen Rolle für die Dauer der Vertretung. - - anforderungen_an_vertretung: - - "Fachliche Eignung (kennt die Domäne der vertretenen Rolle)" - - "Entscheidungsbefugnis (kann für die Organisationseinheit sprechen)" - - "Vorbereitung (hat Unterlagen gesichtet)" - - benennung: "Information an SPM vor Sitzungsbeginn" - -# ============================================================================= -# 5. ARBEITSWEISE -# ============================================================================= - -arbeitsweise: - - # --------------------------------------------------------------------------- - # 5.1 SITZUNGSRHYTHMUS - # --------------------------------------------------------------------------- - - sitzungsrhythmus: - - pilotphase: - frequenz: "woechentlich" - termin: "fester Termin (zu definieren)" - dauer_minuten: 60 - - begruendung: | - Die wöchentliche Frequenz ermöglicht schnelles Lernen und - Etablierung von Routinen. Nach der Pilotphase wird die - Frequenz basierend auf dem tatsächlichen Bedarf angepasst. - - dauer_pilotphase: "3 Monate, dann Evaluation" - - regelzeit: - hinweis: "Wird nach Pilotphase basierend auf Erfahrung definiert" - erwartung: "Wahrscheinlich 2-wöchentlich" - - sondersitzungen: - einberufung_durch: "jedes ständige Mitglied" - - begruendung: | - Bei dringenden Entscheidungen (z.B. kritischer Service-Stopp, - dringende Go-Live-Verzögerung) kann kurzfristig einberufen werden. - - einberufungsfrist: "24 Stunden, bei Notfall kürzer" - - anfrage_an: "spm" - - # --------------------------------------------------------------------------- - # 5.2 VORBEREITUNG UND DOKUMENTATION - # --------------------------------------------------------------------------- - - vorbereitung: - verantwortlich: "spm" - - unterlagen_vorlauf_stunden: 24 - - beschreibung: | - Tagesordnung und Entscheidungsvorlagen müssen 24 Stunden vor - Sitzungsbeginn verfügbar sein. - - tagesordnung_inhalte: - - "Entscheidungsvorlagen (Go-Live, Review, Major Change)" - - "Koordinationsthemen" - - "Eingebrachte Klärungsbedarfe" - - "Informationspunkte" - - entscheidungsvorlagen: - einreichungsfrist: "3 Arbeitstage vor Sitzung" - einreichung_an: "spm" - - vollstaendigkeitspruefung: - verantwortlich: "spm" - bei_unvollstaendigkeit: "Rückfrage an Einreichenden, ggf. Verschiebung" - - referenz: "GOV-TR-014 (Vorbereitungs-Governance)" - - protokollfuehrung: - verantwortlich: "spm" - typ: "Entscheidungsprotokoll" - - pflichtinhalte: - - "Datum und Teilnehmende" - - "Entscheidungen mit Ergebnis" - - "Auflagen (falls vergeben)" - - "Dissens (falls aufgetreten, mit Begründung)" - - "Offene Punkte und Verantwortlichkeiten" - - bei_entscheidungen: - go_live: "Kurz bei Freigabe, vollständig bei Auflagen oder Zurückweisung" - review: "Vollständig bei REDESIGN/RETIRE, kurz bei IMPROVEMENT" - - ablage: - ort: "Confluence" - zugriff: "DIGIT-weit" - - kommunikation: - timing: "Innerhalb von 24 Stunden nach Sitzung" - gegenstand: "Entscheidungen werden an Betroffene kommuniziert" - - # --------------------------------------------------------------------------- - # 5.3 AGENDA-STRUKTUR - # --------------------------------------------------------------------------- - - agenda_struktur: - - beschreibung: | - Die Agenda unterscheidet zwischen Entscheidungsblock und - Koordinationsblock, analog zur DSR-Struktur. - - bloecke: - - - block: "Operative Entscheidungen" - dauer_anteil: "30%" - inhalte: - - "Go-Live-Freigaben" - - "Major-Change-Freigaben" - - "IMPROVEMENT-Freigaben (ressourcenrelevant)" - hinweis: "Nur Themen mit vollständiger Vorlage" - - - block: "Lifecycle-Weichenstellungen" - dauer_anteil: "20%" - inhalte: - - "REDESIGN-Prüfungen" - - "RETIRE-Prüfungen" - hinweis: | - Verfahrensentscheidungen zur Reife-Prüfung, keine - inhaltlich-strategischen Entscheidungen (siehe Abschnitt 3.1)" - - - block: "Koordination" - dauer_anteil: "30%" - inhalte: - - "Status Betrieb/Support" - - "Eingebrachte Klärungsbedarfe" - - "Lifecycle-Koordination" - - - block: "Informationen" - dauer_anteil: "20%" - inhalte: - - "Anstehende Themen (Vorschau)" - - "Rückmeldungen aus MB" - - "Sonstiges" - -# ============================================================================= -# 6. ENTSCHEIDUNGSVERFAHREN -# ============================================================================= - -entscheidungsverfahren: - - # --------------------------------------------------------------------------- - # 6.1 GRUNDPRINZIP - # --------------------------------------------------------------------------- - - grundprinzip: "konsent" - - beschreibung: | - Eine Entscheidung gilt als getroffen, wenn kein schwerwiegender, - begründeter Einwand vorliegt. Enthaltungen blockieren nicht. - - Ein Einwand ist begründet, wenn er einen konkreten Schaden für - Portfolio, Betrieb, Support oder Stakeholder benennt, der durch - die vorgeschlagene Entscheidung entstehen würde. - - # --------------------------------------------------------------------------- - # 6.2 BESCHLUSSFÄHIGKEIT - # --------------------------------------------------------------------------- - - beschlussfaehigkeit: - - regel: "Mindestens 4 von 5 ständigen Mitgliedern anwesend" - - zusatz: "SPM oder dessen Vertretung muss anwesend sein" - - bei_service_spezifischen_entscheidungen: | - Zusätzlich muss der relevante Service Owner anwesend sein. - Bei Abwesenheit des SO wird die Entscheidung vertagt. - - bei_nicht_erfuellung: "Keine Beschlussfassung, Vertagung" - - # --------------------------------------------------------------------------- - # 6.3 EINWAND-VERFAHREN - # --------------------------------------------------------------------------- - - einwand_verfahren: - - beschreibung: | - Das Einwand-Verfahren stellt sicher, dass Bedenken gehört werden, - ohne dass einzelne Mitglieder blockieren können. - - ablauf: - - schritt: 1 - aktion: "Einwendende Rolle benennt konkreten Einwand" - anforderung: "Einwand muss konkreten Schaden benennen" - - - schritt: 2 - aktion: "Einwendende Rolle bringt Alternative ein" - anforderung: "Konstruktiver Gegenvorschlag erforderlich" - - - schritt: 3 - aktion: "SOR versucht Konsensfindung" - moderation: "SPM" - - - schritt: 4 - aktion: "Bei anhaltendem Dissens: SPM entscheidet über weiteres Vorgehen" - optionen: - - "Vertagung mit Arbeitsauftrag" - - "Eskalation ans Mission Board" - - kein_stichentscheid: | - SPM hat keinen Stichentscheid, aber die Verfahrenshoheit. - SPM moderiert die Konsensfindung und entscheidet über - Vertagung oder Eskalation – nicht über den Inhalt. - - # --------------------------------------------------------------------------- - # 6.4 SO-SONDERREGEL - # --------------------------------------------------------------------------- - - so_sonderregel: - - beschreibung: | - Wenn der Service Owner bei einer Entscheidung zu seinem Service - überstimmt wird (d.h. sein Einwand wird nicht akzeptiert), wird - dies explizit protokolliert. - - verfahren: - - "SO-Einwand und Begründung werden protokolliert" - - "Entscheidung der SOR wird protokolliert" - - "SO kann Eskalation ans Mission Board beantragen" - - eskalationsrecht: - berechtigt: "Service Owner" - frist: "5 Arbeitstage nach SOR-Beschluss" - verfahren: "Antrag an SPM, SPM leitet an MB weiter" - - begruendung: | - Der SO trägt die Verantwortung für seinen Service. Wenn das Gremium - gegen seinen Einwand entscheidet, muss dies transparent sein und - der SO muss die Möglichkeit haben, die Entscheidung prüfen zu lassen. - - # --------------------------------------------------------------------------- - # 6.5 ESKALATION - # --------------------------------------------------------------------------- - - eskalation: - - an: "Mission Board" - - trigger: - - "Anhaltender Dissens nach Einwand-Verfahren" - - "SO-Eskalationsantrag nach Überstimmung" - - "Ressourcenkonflikt über SOR-Mandat hinaus" - - "Strategische Tragweite (SOR-Einschätzung)" - - verfahren: - verantwortlich: "spm" - schritte: - - "SPM bereitet Eskalationsvorlage vor" - - "Vorlage enthält: Sachverhalt, Positionen, Empfehlung" - - "MB behandelt in nächster Sitzung (oder Sondersitzung bei Dringlichkeit)" - - aufschiebende_wirkung: | - Eskalation hat aufschiebende Wirkung – die strittige Entscheidung - wird nicht vollzogen, bis MB entschieden hat. - -# ============================================================================= -# 7. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - # --------------------------------------------------------------------------- - # 7.1 EINGANGSSCHNITTSTELLEN - # --------------------------------------------------------------------------- - - eingang: - - - von: "Service Owner" - gegenstand: "Gate-2-Anträge, Review-Vorlagen, Major-Change-Anträge" - verfahren: "Einreichung an SPM, SPM prüft Vollständigkeit" - vorlaufzeit: "3 Arbeitstage vor Sitzung" - - - von: "SHM" - gegenstand: "Klärungsbedarfe aus Stakeholder-Interaktion" - verfahren: "Einbringung durch SHM als ständiges Mitglied" - beispiele: - - "Unklare Servicezuständigkeit bei Stakeholder-Anfrage" - - "Eskalation aus Stakeholder-Feedback" - - - von: "Service Entwicklung / Projekt" - gegenstand: "Services zur Transition" - verfahren: "Formale Übergabe an SO, SO beantragt Gate 2" - referenz: "spm_konzept_service-transition.yaml" - - - von: "Operations / Support" - gegenstand: "Betriebsstatus, Support-Situation, Kapazitätsthemen" - verfahren: "Einbringung durch Ops Mgr / Sup Mgr als ständige Mitglieder" - - # --------------------------------------------------------------------------- - # 7.2 AUSGANGSSCHNITTSTELLEN - # --------------------------------------------------------------------------- - - ausgang: - - - an: "DPM" - gegenstand: "REDESIGN/RETIRE-Entscheidungen" - verfahren: "Übergabe als neuer Demand" - output: - redesign: "Demand (Klassifizierung: Neugestaltung)" - retire: "Demand (Stilllegungsprojekt)" - - - an: "Service Owner" - gegenstand: "Go-Live-Freigabe, Review-Entscheidung, Auflagen" - verfahren: "Kommunikation durch SPM nach Sitzung" - - - an: "Mission Board" - gegenstand: "Eskalationen, Information über kritische Entscheidungen" - verfahren: "SPM bereitet Vorlage vor" - - - an: "Service-Katalog" - gegenstand: "Aktivierung neuer Services" - verfahren: "Nach Go-Live-Freigabe: Katalog-Eintrag wird aktiviert" - referenz: "GOV-TR-021 (Aktivierungskonzept)" - - # --------------------------------------------------------------------------- - # 7.3 INFORMATIONSSCHNITTSTELLEN - # --------------------------------------------------------------------------- - - information: - - - an: "Mission Board" - gegenstand: "Portfolio-Bericht" - rhythmus: "Im Rahmen des regelmäßigen SPM-Berichts ans MB" - inhalte: - - "Aktivierte Services (seit letztem Bericht)" - - "Review-Ergebnisse (Aggregat)" - - "Kritische Themen" - - - an: "DPM" - gegenstand: "Service-Portfolio-Status" - verfahren: "SPM ist DSR-Mitglied und informiert bei Bedarf" - -# ============================================================================= -# 8. GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance_entscheidungen: - - beschreibung: | - Folgende Governance-Entscheidungen wurden im Rahmen der Konzeption - der SOR-Geschäftsordnung getroffen. - - entscheidungen: - - - id: "GOV-SOR-001" - datum: "2025-12-17" - aktualisiert: "2026-03-04" - aktualisiert_durch: "GOV-SHM-029 (ROUTE-DSR → ROUTE-SO); konzeptuelle Verfeinerung: Empfehlung vs. Entscheidung" - frage: "Wie erfolgt die Routing-Klärung bei Unsicherheit (Service vs. Demand)?" - - entscheidung: | - Ursprüngliche Entscheidung (2025-12-17): - Demand-Routing erfolgt direkt an DPM. DSR nur Portfolio-Governance. - - Aktualisiert durch GOV-SHM-029 (2026-03-04 - Workshop-Entscheidung): - Routing-Klärung bei Unsicherheit erfolgt bilateral über den zuständigen - Service Owner. Service Owner gibt Routing-Empfehlung ab. SPM unterstützt - bei der Service-Identifikation. SOR ist zuständig für die FORMELLE BESTÄTIGUNG - von RUN/Change-Routing-Empfehlungen des Service Owners (ROUTE-SO). - Weiterbearbeitung erfolgt "als ob" bereits entschieden, während auf formelle - Bestätigung im nächsten Takt gewartet wird. - - Neue Logik: - - SO gibt Empfehlung ab: RUN/Change → SOR bestätigt formal im nächsten Takt - - SO gibt Empfehlung ab: Demand → DPM nimmt direkt entgegen (kein DSR-Weg) - - SO unsicher? → Bilaterale Klärung mit SPM - - Prozess läuft "als ob" entschieden während auf formelle Gremienbestätigung gewartet wird - - auswirkung_auf: - - dokument: "shm_governance-framework.yaml" - aktion: "ROUTE-DSR → ROUTE-DPM ändern (Demand direkt an DPM); GOV-SOR-001 Referenz aktualisieren" - - dokument: "shm_bedarfsbewertung.yaml" - aktion: "Routing-Pfade: ROUTE-SO statt ROUTE-DSR" - - dokument: "rolle_service-portfolio-manager.yaml" - aktion: "Routing-Klärung (ROUTE-SO oder DPM-Rückkopplung); Governance-Referenz zu GOV-SHM-029" - - status: "aktualisiert" - patch_erforderlich: true - - - id: "GOV-SOR-002" - datum: "2025-12-17" - frage: "Wer sind die ständigen Mitglieder der SOR?" - - entscheidung: | - Ursprüngliche Entscheidung (2025-12-17): - Vier ständige stimmberechtigte Mitglieder mit Operations Manager. - - Aktualisiert durch GOV-SOR-005 (2026-01-31): - Fünf ständige stimmberechtigte Mitglieder: - 1. Service-Portfolio-Manager (SPM) – Vorsitz - 2. Abteilungsleitung Basis & Cloud - 3. Abteilungsleitung Applikationen - 4. Support Manager - 5. Stakeholder-Management (SHM) - - Service Owner ist variables stimmberechtigtes Mitglied bei - service-spezifischen Entscheidungen (Pflicht-Teilnahme). - - begruendung: | - Die fünf Perspektiven (Portfolio, Betrieb Infrastruktur, Betrieb - Anwendungen, Support, Stakeholder) decken den Service-Lifecycle ab. - Beide Betriebsabteilungen sind gleichwertig vertreten. - - status: "aktualisiert" - aktualisiert_durch: "GOV-SOR-005" - - - id: "GOV-SOR-005" - datum: "2026-01-31" - frage: "Wie wird die Betriebsperspektive in der SOR vertreten?" - - entscheidung: | - Beide Abteilungsleitungen (Basis & Cloud, Applikationen) sind - ständige stimmberechtigte Mitglieder der SOR. - - Begründung: - - Respektiert die reale Organisationsstruktur bei DIGIT - - Beide Betriebsperspektiven (Infrastruktur/Anwendungen) sind - für Service-Entscheidungen relevant - - Keine neue Koordinationsebene erforderlich - - Konsistent mit DIGITOM-Designprinzipien: - * Participatory Design (beide Abteilungen eingebunden) - * Provisorische Strukturen (Review vorgesehen) - * Explizites System (klare Regelung statt informelle Absprache) - * Keine neue Hierarchieverschachtelung - - auswirkung_auf: - - dokument: "spm_sor_go.yaml" - aktion: "Zusammensetzung auf 5 ständige Mitglieder erweitert" - - dokument: "spm_rollen.yaml" - aktion: "AL-Rollen mit SOR-Mitgliedschaft ergänzen" - - review: - termin: "2026-07-31" - kriterien: - - "Funktioniert die Doppelbesetzung in der Praxis?" - - "Gibt es Stimmenkonflikte zwischen den Abteilungen?" - - "Wäre eine Konsolidierung sinnvoll?" - - status: "final (provisorisch)" - - - id: "GOV-SOR-003" - datum: "2025-12-17" - frage: "Welche Rolle hat SPM bei Dissens?" - - entscheidung: | - SPM hat Koordinationsverantwortung (analog DPM in der DSR): - - Moderiert Konsensfindung - - Entscheidet über Vertagung oder Eskalation - - Hat KEINEN Stichentscheid über den Inhalt - - status: "final" - - - id: "GOV-SOR-004" - datum: "2025-12-17" - frage: "Wie wird mit irreversibler Service-Ablehnung umgegangen?" - - entscheidung: | - MVP-Scope: Irreversible Service-Ablehnung wird nicht modelliert. - Die Option "Zurück an Transition" deckt den Regelfall ab. - - Wenn eine Situation auftritt, die eine irreversible Ablehnung - erfordert, wird diese ans Mission Board eskaliert. - - begruendung: | - Irreversible Ablehnungen sind voraussichtlich sehr selten. - Die Eskalation ans MB ist für diese Fälle angemessen. - - status: "final (MVP)" - post_mvp: "Evaluation, ob explizite Regelung erforderlich" - -# ============================================================================= -# 9. OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - beschreibung: | - Die folgenden Punkte wurden identifiziert, aber für den MVP bewusst - nicht detailliert. Sie können bei Bedarf ergänzt werden. - - punkte: - - - id: "OPEN-SOR-001" - thema: "Irreversible Service-Ablehnung" - beschreibung: | - Die Entscheidungsoption "Service wird nicht aktiviert, Projekt - wird formal beendet" ist im MVP nicht modelliert. Bei Bedarf - wird ans MB eskaliert. - spaetere_klaerung: "Post-MVP, wenn operative Erfahrung vorliegt" - prioritaet: "niedrig" - - - id: "OPEN-SOR-002" - thema: "Delegationsmöglichkeiten SOR → SO" - beschreibung: | - Kann die SOR wiederkehrende Entscheidungstypen an den SO - delegieren (z.B. Go-Live für Standard-Services)? - spaetere_klaerung: "Evaluation nach 6 Monaten SOR-Betrieb" - prioritaet: "mittel" - - - id: "OPEN-SOR-003" - thema: "Eilentscheidungen außerhalb SOR-Turnus" - beschreibung: | - Können bestimmte Entscheidungen im Umlaufverfahren getroffen - werden, ohne SOR-Sitzung? - spaetere_klaerung: "Bei operativer Erfahrung" - prioritaet: "niedrig" - - - id: "OPEN-SOR-004" - thema: "Verhältnis SOR ↔ IT-Architektur-Board" - beschreibung: | - Beide Gremien sind koordinativ. Abgrenzung bei - Architektur-relevanten Service-Entscheidungen? - spaetere_klaerung: "Bei Definition IT-Architektur-Board" - prioritaet: "mittel" - - # --------------------------------------------------------------------------- - # PATCH-ANFORDERUNGEN - # --------------------------------------------------------------------------- - - patch_anforderungen: - - beschreibung: | - Folgende Patches an bestehenden Dokumenten sind erforderlich, - um Konsistenz herzustellen. - - patches: - - - id: "PATCH-SOR-001" - dokument: "shm_governance-framework.yaml" - abschnitt: "routing_entscheidung.routing_pfade" - aenderung: "ROUTE-SOR → ROUTE-DSR" - begruendung: "GOV-SOR-001: Routing-Klärung zur DSR" - status: "ausstehend" - - - id: "PATCH-SOR-002" - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "routing_pfade" - aenderung: "ROUTE-SOR entfernen oder zu ROUTE-DSR ändern" - begruendung: "GOV-SOR-001: Routing-Klärung zur DSR" - status: "ausstehend" - -# ============================================================================= -# 10. ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.5" - datum: "2026-03-04" - aenderung: | - Aktualisierung Routing-Klärung: ROUTE-DSR → ROUTE-SO (GOV-SHM-029) - Workshop-Entscheidung führte zur Neukonzeption des Routing-Prozesses: - - GOV-SOR-001 aktualisiert: Routing-Klärung erfolgt bilateral mit Service Owner (nicht DSR) - - Neue Logik: SO entscheidet RUN/Change (→ SOR) oder Demand (→ DPM/DSR) - - SPM unterstützt SO bei Service-Identifikation - - SOR ist Implementierungs-Empfänger von RUN/Change-Entscheidungen - - Abschnitte umfasst/umfasst_nicht, abgrenzung_zu_anderen_gremien aktualisiert - autor: "DIGITOM-Projekt" - governance_referenz: "GOV-SHM-029" - - - version: "1.4" - datum: "2026-01-31" - aenderung: | - Erweiterung der ständigen Mitglieder von 4 auf 5: - - Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen - - Beide Betriebsperspektiven (Infrastruktur/Anwendungen) gleichwertig vertreten - - Beschlussfähigkeit angepasst (4 von 5 statt 3 von 4) - - Neue Governance-Entscheidung GOV-SOR-005 - - Review-Termin für Juli 2026 vorgesehen - autor: "DIGITOM-Projekt" - governance_referenz: "GOV-SOR-005" - begruendung: | - Abgleich mit DIGITOM-Designprinzipien ergab, dass beide - Betriebsperspektiven gleichwertig vertreten sein sollten. - Die Lösung respektiert die bestehende Organisationsstruktur - ohne neue Hierarchieebene zu schaffen. - - - version: "1.3" - datum: "2026-01-31" - aenderung: | - Korrektur Major-Change-Governance: - - Major-Change-Abschnitt präzisiert: Zwei Entscheidungspunkte (Entry-Autorisierung + Gate 3) - - Entscheidungsoptionen für beide Punkte separat dokumentiert - - Abgrenzung zu Normal Change explizit gemacht - - Konzept-Referenz auf spm_practice_change-enablement.yaml ergänzt - autor: "DIGITOM-Projekt" - kontext: "Konsistenz mit Change-Enablement-Konzept v1.2" - - - version: "1.2" - datum: "2026-01-30" - aenderung: | - Präzisierung der Entscheidungskategorien bei Service-Reviews: - - Kategorie "Strategische Entscheidung" umbenannt zu "Lifecycle-Weichenstellung" - - Explizite Abgrenzung ergänzt: SOR trifft Verfahrensentscheidungen - ("Ob reif"), nicht inhaltlich-strategische Entscheidungen ("Ob") - - Agenda-Struktur angepasst: Trennung in "Operative Entscheidungen" - und "Lifecycle-Weichenstellungen" - autor: "DIGITOM-Projekt" - begruendung: | - Die bisherige Bezeichnung "Strategische Entscheidung" war missverständlich, - da strategische Portfolio-Ausrichtung explizit nicht im SOR-Mandat liegt - (siehe Abschnitt 2 "umfasst_nicht"). Die neue Bezeichnung macht klar, - dass die SOR bei REDESIGN/RETIRE die Reife prüft und an DPM übergibt, - aber nicht selbst strategisch entscheidet. - - - version: "1.1" - datum: "2026-01-30" - aenderung: "Anpassung an Service-Lifecycle 3.0: Gate-Referenzen aktualisiert (Go-Live-Freigabe ist Gate 3 / tr_11, nicht Gate 2)" - autor: "DIGITOM-Projekt" - referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" - - - version: "1.0" - datum: "2025-12-17" - aenderung: "Initiale Erstellung basierend auf Konzeptionsarbeit" - autor: "DIGITOM-Projekt" - quelle: "Chat-Session SPM Service Operations Runde" - - enthaltene_entscheidungen: - - "GOV-SOR-001 (Routing zur DSR)" - - "GOV-SOR-002 (Zusammensetzung)" - - "GOV-SOR-003 (SPM-Koordinationsrolle)" +# ============================================================================= +# SERVICE OPERATIONS RUNDE (SOR) – GESCHÄFTSORDNUNG +# ============================================================================= +# +# Geschäftsordnung der Service Operations Runde (SOR). +# Definiert Zweck, Zusammensetzung, Arbeitsweise und Entscheidungsverfahren. +# +# Status: Draft (zur Validierung mit DIGIT) +# ============================================================================= + +metadata: + id: "G-SOR" + typ: "geschaeftsordnung" + gremium_id: "sor" + gremium_name: "Service Operations Runde" + aliases: ["SOR", "Service-Runde"] + version: "1.4" + status: "draft" + erstellt: "2025-12-17" + aktualisiert: "2026-01-31" + gueltig_ab: "[Datum nach Freigabe]" + geltungsbereich: "DIGITOM / Service-Portfolio-Management" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "geschaeftsordnung" + + abstimmung: + sparring_mit: ["dpm", "shm"] + abgestimmt_mit: [] + inhaltlich_abgenommen_durch: [] + status: "in_abstimmung" + + kontext_tags: + - "service-portfolio-management" + - "governance" + - "entscheidungsgremium" + - "service-lifecycle" + + referenzen: + taxonomie: "00_meta/digitom_taxonomie.yaml → gremium" + dsr_go: "01_demand-portfolio-management/dpm_dsr-go.yaml" + spm_rollen: "02_service-lifecycle-blueprint/spm_rollen.yaml" + service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" + service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml" + +# ============================================================================= +# 1. ZWECK UND GELTUNGSBEREICH +# ============================================================================= + +zweck: + + kurzform: "Service-Portfolio-Governance und operative Koordination" + + beschreibung: | + Die Service Operations Runde (SOR) ist das zentrale Gremium für + Service-Portfolio-Angelegenheiten unterhalb des Mission Boards. + + Sie vereint zwei Funktionen: + (1) Entscheidungsfunktion: Governance-Entscheidungen zu Services + (2) Koordinationsfunktion: Abstimmung zwischen Service-Ownership, + Betrieb und Support + + Die Bezeichnung "Operations" bezieht sich auf den Fokus auf aktive + Services im Betrieb sowie die operative Koordination – nicht auf + die Ebene in der Governance-Hierarchie. + + funktion: | + Brücke zwischen Service-Entwicklung/-Transition und Service-Betrieb. + Steuerung des Service-Portfolios durch definierte Entscheidungstypen. + Koordination der operativen Zusammenarbeit im Service-Lifecycle. + + verankerung: "Koordinatives Gremium im DIGITOM (gleiche Ebene wie DSR)" + + governance_ebene: "koordinativ" + + regelungsumfang: + - "Arbeitsweise der SOR" + - "Entscheidungsverfahren" + - "Entscheidungstypen im Service-Lifecycle" + - "Koordination Service/Betrieb/Support" + - "Schnittstellen zu anderen Gremien und Funktionen" + +# ============================================================================= +# 2. MANDAT UND ABGRENZUNG +# ============================================================================= + +mandat: + + umfasst: + + entscheidungen: + - gegenstand: "Service-Aktivierungen (Go-Live-Freigabe)" + referenz: "Gate 3 der Service Transition (tr_11)" + governance_referenz: "GOV-TR-002" + + - gegenstand: "Service-Review-Entscheidungen" + beschreibung: "Behandlung von IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE" + referenz: "spm_konzept_service-review.yaml" + governance_referenz: "GOV-SR-004" + + - gegenstand: "Major-Change-Freigaben an Services" + beschreibung: "Wesentliche Änderungen an bestehenden Services" + referenz: "GOV-TR-003" + + koordination: + - gegenstand: "Status-Abstimmung Betrieb und Support" + beschreibung: "Regelmäßiger Austausch zu Betriebsstatus, Support-Situation, Kapazitäten" + + - gegenstand: "Klärungsbedarfe aus anderen Funktionen" + beschreibung: "Themen, die von SHM, DPM oder anderen eingebracht werden" + beispiele: + - "Unklare Servicezuständigkeiten" + - "Abstimmungsbedarf bei Service-Änderungen" + - "Eskalationen aus dem Stakeholder-Kontext" + + - gegenstand: "Operative Abstimmung im Service-Lifecycle" + beschreibung: "Koordination zwischen SO, Betrieb und Support bei Übergängen" + + umfasst_nicht: + + - gegenstand: "Demand-Entscheidungen" + zustaendig: "DPM (direkt)" + abgrenzung: "Demands gehen direkt an DPM, SOR bestätigt Changes" + + - gegenstand: "Routing-Empfehlungen (Service vs. Demand)" + zustaendig: "Service Owner (Empfehlung) → SOR/DSR (formelle Bestätigung)" + abgrenzung: "SO gibt Routing-Empfehlung ab bilateral mit SPM. SOR bestätigt formal RUN/Change-Empfehlungen. Demands gehen direkt an DPM (kein DSR-Weg). Weiterbearbeitung erfolgt 'als ob' bereits entschieden." + governance_referenz: "GOV-SHM-029 (aktualisiert GOV-SOR-001)" + + - gegenstand: "Ressourcenallokation über Abteilungsgrenzen" + zustaendig: "Mission Board" + abgrenzung: "SOR eskaliert bei Ressourcenkonflikten" + + - gegenstand: "Strategische Portfolio-Ausrichtung" + zustaendig: "Mission Board / Vision Board" + abgrenzung: "SOR setzt strategische Vorgaben um, definiert sie nicht" + + - gegenstand: "Operative Betriebskoordination im Tagesgeschäft" + zustaendig: "Operations Manager" + abgrenzung: "SOR ist Governance-Gremium, nicht operatives Jour-Fixe" + + - gegenstand: "Irreversible Service-Ablehnung" + zustaendig: "Mission Board" + abgrenzung: "Siehe offene_punkte → MVP-Scope" + + abgrenzung_zu_anderen_gremien: + + dsr: + beschreibung: "Demands gehen direkt an DPM. DSR nur Portfolio-Governance. SOR bestätigt Changes." + schnittstelle: "Bei REDESIGN/RETIRE übergibt SOR an DPM (neuer Demand)" + routing_regel: | + Routing-Klärung erfolgt bilateral mit dem Service Owner (ROUTE-SO). + SO gibt Routing-Empfehlung ab (nicht endgültige Entscheidung). + SO wird von SPM unterstützt. SOR bestätigt formal RUN/Change-Empfehlungen, + Demands gehen direkt an DPM. Kein DSR-Routing mehr. + "als ob" bereits entschieden, während auf formelle Gremienbestätigung + im nächsten Takt gewartet wird. + + mission_board: + beschreibung: "MB ist Eskalationsinstanz für SOR" + eskalation_bei: + - "Ressourcenkonflikte über SOR-Mandat hinaus" + - "Strategische Tragweite" + - "Anhaltender Dissens nach Einwand-Verfahren" + - "Irreversible Service-Ablehnung (Post-MVP)" + + ops_manager: + beschreibung: "Ops Manager koordiniert Tagesbetrieb, SOR entscheidet Governance" + abgrenzung: | + Operations Manager ist ständiges SOR-Mitglied und bringt die + Betriebsperspektive ein. Die operative Koordination im Tagesgeschäft + liegt beim Ops Manager, nicht bei der SOR. + +# ============================================================================= +# 3. AUFGABEN UND KOMPETENZEN +# ============================================================================= + +aufgaben: + + charakter: "Hybrides Gremium mit zwei Funktionsbereichen" + + # --------------------------------------------------------------------------- + # 3.1 ENTSCHEIDUNGSFUNKTION + # --------------------------------------------------------------------------- + + entscheidungsfunktion: + + beschreibung: | + Die SOR trifft Governance-Entscheidungen zu Services innerhalb + ihres Mandats. Entscheidungen folgen dem Konsent-Prinzip. + + entscheidungstypen: + + - typ: "go_live_freigabe" + name: "Go-Live-Freigabe (Gate 3)" + beschreibung: "Formale Freigabe zur Aktivierung eines neuen oder wesentlich geänderten Services" + lifecycle_aktivitaet: "tr_12" + + entscheidungsoptionen: + - option: "go_live" + beschreibung: "Service wird aktiviert, Aufnahme ins Portfolio" + naechster_schritt: "Katalog-Aktivierung, ELS-Start" + + - option: "go_live_mit_auflagen" + beschreibung: "Aktivierung unter Bedingungen" + naechster_schritt: "Go-Live erfolgt, Auflagen werden im ELS überwacht" + + - option: "zurueck_an_transition" + beschreibung: "Wesentliche Mängel, weitere Nacharbeit erforderlich" + naechster_schritt: "SO behebt Mängel, erneutes Gate 2" + + voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" + governance_referenz: "GOV-TR-002, GOV-TR-005" + konzept_referenz: "spm_konzept_service-transition.yaml" + + - typ: "service_review" + name: "Service-Review-Entscheidung" + beschreibung: "Behandlung von Review-Ergebnissen, die SOR-Governance erfordern" + + behandlungskategorien: + + - kategorie: "Kenntnisnahme" + sor_behandlung: false + gilt_fuer: + - "CONTINUE" + - "IMPROVEMENT (SO-geführt, ressourcenneutral)" + verfahren: "SO dokumentiert im Steckbrief, informiert SPM" + + - kategorie: "Operative Entscheidung" + sor_behandlung: true + agenda_block: "Entscheidungen" + gilt_fuer: + - "IMPROVEMENT (ressourcenrelevant)" + entscheidungsoptionen: + - "Freigabe der Improvement-Maßnahmen" + - "Freigabe mit Auflagen" + - "Zurückweisung (mit Begründung)" + - "Eskalation an MB (bei Ressourcenkonflikt)" + + - kategorie: "Lifecycle-Weichenstellung" + sor_behandlung: true + agenda_block: "Entscheidungen" + gilt_fuer: + - "REDESIGN" + - "RETIRE" + + beschreibung: | + Die SOR prüft, ob ein Service-Review-Ergebnis mit strategischer + Tragweite (REDESIGN, RETIRE) reif für die Übergabe an den + Demand-Prozess ist. Die SOR trifft keine inhaltlich-strategische + Entscheidung ("Soll der Service stillgelegt werden?"), sondern + eine Verfahrensentscheidung ("Ist das Thema ausreichend geprüft + für den nächsten Schritt?"). + + Die eigentliche strategische Entscheidung erfolgt im Demand-Lifecycle + (DSR) oder bei übergreifender Tragweite im Mission Board. + + entscheidungsoptionen: + - option: "freigabe_uebergabe" + beschreibung: "Review-Ergebnis ist ausreichend fundiert" + naechster_schritt: "Übergabe an DPM als Demand" + + - option: "zurueck_an_so" + beschreibung: "Weitere Prüfung oder Substantiierung erforderlich" + naechster_schritt: "SO überarbeitet Review-Ergebnis" + + - option: "eskalation_mb" + beschreibung: "Tragweite übersteigt SOR-Mandat" + trigger: + - "Abteilungsübergreifende Ressourcenimplikationen" + - "Politische Sensibilität" + - "Grundsatzfrage zur Portfolio-Strategie" + naechster_schritt: "Mission Board entscheidet über Verfahren" + + output_bei_freigabe: + redesign: "Demand an DPM (Klassifizierung: Neugestaltung)" + retire: "Demand an DPM (Stilllegungsprojekt)" + + abgrenzung: | + Die SOR entscheidet NICHT über das "Ob" (strategische Frage), + sondern über das "Ob reif" (Verfahrensfrage). + + voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" + governance_referenz: "GOV-SR-004" + konzept_referenz: "spm_konzept_service-review.yaml" + + - typ: "major_change" + name: "Major-Change-Autorisierung und -Freigabe" + beschreibung: "Autorisierung und Freigabe wesentlicher Änderungen an bestehenden Services" + + major_kriterien: + - "Änderung der Service-Definition (Scope, Zielgruppe, Kernfunktionalität)" + - "Änderung der SLA/SLO-Vereinbarungen" + - "Signifikante Architektur-Änderung" + + zwei_entscheidungspunkte: + beschreibung: | + Major Changes erfordern zwei SOR-Entscheidungen: + 1. Entry-Autorisierung: Freigabe für den Eintritt in die Transition + 2. Go-Live-Freigabe (Gate 3): Freigabe für den produktiven Betrieb + + Dies unterscheidet Major Changes von Normal Changes, bei denen + der SO allein entscheidet. + + entry_autorisierung: + zweck: "Prüfung ob Major Change in Transition gehen darf" + entscheidungsoptionen: + - "Freigabe für Transition" + - "Freigabe mit Auflagen" + - "Ablehnung" + + go_live_freigabe: + zweck: "Freigabe nach Abschluss der Transition-Aktivitäten" + entspricht: "Gate 3 (tr_12)" + entscheidungsoptionen: + - "Go-Live" + - "Go-Live mit Auflagen" + - "Zurück an Transition" + - "Ablehnung" + + voraussetzung: "SO des betroffenen Service ist anwesend und stimmberechtigt" + governance_referenz: "GOV-TR-003" + konzept_referenz: "spm_practice_change-enablement.yaml" + + abgrenzung: | + Minor Changes laufen über Change Enablement (Standard/Normal Change) + und erfordern keine SOR-Behandlung. Der wesentliche Unterschied: + Normal Change = SO-Einzelentscheidung + Major Change = SOR-Autorisierung (Entry) + SOR-Freigabe (Gate 3) + + # --------------------------------------------------------------------------- + # 3.2 KOORDINATIONSFUNKTION + # --------------------------------------------------------------------------- + + koordinationsfunktion: + + beschreibung: | + Die SOR dient als Forum für die operative Abstimmung zwischen + Service-Ownership, Betrieb und Support. Koordinationsthemen haben + keinen Entscheidungscharakter, sondern dienen dem Informationsaustausch + und der Klärung. + + aktivitaeten: + + - name: "Status-Austausch" + beschreibung: "Regelmäßiger Austausch zu Betrieb und Support" + themen: + - "Betriebsstatus kritischer Services" + - "Support-Auslastung und Trends" + - "Kapazitätssituation" + - "Anstehende Wartungsfenster" + + - name: "Klärungsbedarfe" + beschreibung: "Behandlung von Themen, die Klärung erfordern" + einbringung_durch: + - "Ständige Mitglieder (SPM, Ops Mgr, Sup Mgr, SHM)" + - "Service Owner (über SPM)" + - "Andere Funktionen (über SPM)" + beispiele: + - "Unklare Servicezuständigkeiten" + - "Abstimmungsbedarf bei Service-Übergängen" + - "Eskalationen aus Stakeholder-Interaktionen (via SHM)" + + - name: "Lifecycle-Koordination" + beschreibung: "Abstimmung bei Übergängen im Service-Lifecycle" + themen: + - "Vorbereitung auf anstehende Go-Lives" + - "ELS-Status und Exit-Planung" + - "Übergabe von Services zwischen Verantwortlichen" + +# ============================================================================= +# 4. ZUSAMMENSETZUNG +# ============================================================================= + +zusammensetzung: + + # --------------------------------------------------------------------------- + # 4.1 STÄNDIGE MITGLIEDER + # --------------------------------------------------------------------------- + + staendige_mitglieder: + anzahl: 5 + + rationale: | + Der Kern deckt die zentralen Perspektiven des Service-Lifecycle ab: + - Portfolio-Steuerung (SPM) + - Betrieb Infrastruktur (AL Basis & Cloud) + - Betrieb Anwendungen (AL Applikationen) + - Support (Sup Mgr) + - Stakeholder/Kunde (SHM) + + Die beiden Betriebsperspektiven sind gleichwertig vertreten, da Services + sowohl infrastruktur- als auch anwendungsseitige Aspekte haben. Dies + respektiert die bestehende Organisationsstruktur bei DIGIT ohne neue + Hierarchieebene zu schaffen. + + Service Owner sind service-spezifisch und daher variable Mitglieder. + + design_prinzipien_abgleich: | + Die Zusammensetzung folgt den DIGITOM-Designprinzipien: + - Participatory Design: Beide Abteilungen gleichberechtigt eingebunden + - Provisorische Strukturen: Review nach 6 Monaten vorgesehen + - Explizites System: Klare Regelung statt informeller Absprache + - Keine neue Hierarchie: Bestehende AL-Rollen, keine Koordinationsebene + + mitglieder: + + - rolle_id: "spm" + rolle_name: "Service-Portfolio-Manager" + funktion: "vorsitz" + stimmberechtigt: true + begruendung: "Portfolio-Perspektive, Koordination, Verfahrenshoheit" + verantwortlichkeiten: + - "Einberufung und Leitung der Sitzungen" + - "Tagesordnung erstellen" + - "Protokollführung (oder Delegation)" + - "Moderation bei Dissens" + - "Entscheidung über Vertagung oder Eskalation" + + - rolle_id: "al_basis_cloud" + rolle_name: "Abteilungsleitung Basis & Cloud" + funktion: "mitglied" + stimmberechtigt: true + begruendung: "Betriebsperspektive Infrastruktur, Ressourcen-Realität, Betriebsreife-Bewertung für Infrastruktur-Services" + themengruppen: + - "Netzwerk" + - "Cloud" + - "Deployment" + - "Infrastruktur-Betrieb" + + - rolle_id: "al_applikationen" + rolle_name: "Abteilungsleitung Applikationen" + funktion: "mitglied" + stimmberechtigt: true + begruendung: "Betriebsperspektive Anwendungen, Ressourcen-Realität, Betriebsreife-Bewertung für Anwendungs-Services" + themengruppen: + - "SAP" + - "Ennaio" + - "Fachverfahren" + - "Anwendungs-Betrieb" + + - rolle_id: "sup_mgr" + rolle_name: "Support Manager" + funktion: "mitglied" + stimmberechtigt: true + begruendung: "Support-Perspektive, Kundennähe, Support-Readiness-Bewertung" + + - rolle_id: "shm" + rolle_name: "Stakeholder-Management" + funktion: "mitglied" + stimmberechtigt: true + begruendung: "Stakeholder-Perspektive, Kundenanwalt, Einbringung von Klärungsbedarfen" + rolle_in_sor: | + SHM vertritt die Stakeholder-Perspektive (analog zur Rolle in der DSR). + Zusätzlich kann SHM Klärungsbedarfe einbringen, die aus der + Stakeholder-Interaktion entstehen. + + # --------------------------------------------------------------------------- + # 4.2 SERVICE OWNER BEI SERVICE-SPEZIFISCHEN ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + service_owner_beteiligung: + + grundregel: | + Bei service-spezifischen Entscheidungen (Go-Live, Review, Major Change) + ist die Anwesenheit des betroffenen Service Owners Pflicht. + Der SO ist dann stimmberechtigt. + + pflicht_bei: + - "Go-Live-Freigabe (Gate 2)" + - "Service-Review-Entscheidung (operativ oder strategisch)" + - "Major-Change-Freigabe" + + nicht_erforderlich_bei: + - "Portfolio-übergreifende Entscheidungen" + - "Generische Prozess-Entscheidungen" + - "Koordinationsthemen ohne Entscheidungscharakter" + + status: "stimmberechtigt" + + einladung_durch: "spm" + + konsequenz_bei_abwesenheit: | + Kann der relevante SO nicht teilnehmen, wird die Entscheidung vertagt. + In dringenden Fällen kann der SO eine Vertretung mit + Entscheidungsbefugnis benennen. + + # --------------------------------------------------------------------------- + # 4.3 BERATENDE TEILNAHME + # --------------------------------------------------------------------------- + + beratende_teilnahme: + erlaubt: true + status: "beratend" + stimmberechtigt: false + + typische_teilnehmende: + - rolle: "IT-Architektur" + bei: "Architektur-relevanten Entscheidungen, Major Changes mit Architektur-Impact" + + - rolle: "Projektleiter" + bei: "Go-Live-Entscheidungen zu Projekten in Transition" + + - rolle: "DPM" + bei: "REDESIGN/RETIRE-Entscheidungen (Übergabe-Abstimmung)" + + - rolle: "Fachexperten" + bei: "Spezifische technische oder fachliche Fragestellungen" + + einladung_durch: "spm" + + vorlaufzeit: "Einladung mit Tagesordnung (mind. 24h vor Sitzung)" + + # --------------------------------------------------------------------------- + # 4.4 VERTRETUNGSREGELUNG + # --------------------------------------------------------------------------- + + vertretungsregelung: + + prinzip: "flexibel" + + beschreibung: | + Ständige Mitglieder benennen ihre Vertretung flexibel für einzelne + Sitzungen. Die Vertretung muss vor der Sitzung benannt werden. + + vertretungs_kompetenzen: | + Vertretungen sind vollständig stimmberechtigt und haben die vollen + Kompetenzen der vertretenen Rolle für die Dauer der Vertretung. + + anforderungen_an_vertretung: + - "Fachliche Eignung (kennt die Domäne der vertretenen Rolle)" + - "Entscheidungsbefugnis (kann für die Organisationseinheit sprechen)" + - "Vorbereitung (hat Unterlagen gesichtet)" + + benennung: "Information an SPM vor Sitzungsbeginn" + +# ============================================================================= +# 5. ARBEITSWEISE +# ============================================================================= + +arbeitsweise: + + # --------------------------------------------------------------------------- + # 5.1 SITZUNGSRHYTHMUS + # --------------------------------------------------------------------------- + + sitzungsrhythmus: + + pilotphase: + frequenz: "woechentlich" + termin: "fester Termin (zu definieren)" + dauer_minuten: 60 + + begruendung: | + Die wöchentliche Frequenz ermöglicht schnelles Lernen und + Etablierung von Routinen. Nach der Pilotphase wird die + Frequenz basierend auf dem tatsächlichen Bedarf angepasst. + + dauer_pilotphase: "3 Monate, dann Evaluation" + + regelzeit: + hinweis: "Wird nach Pilotphase basierend auf Erfahrung definiert" + erwartung: "Wahrscheinlich 2-wöchentlich" + + sondersitzungen: + einberufung_durch: "jedes ständige Mitglied" + + begruendung: | + Bei dringenden Entscheidungen (z.B. kritischer Service-Stopp, + dringende Go-Live-Verzögerung) kann kurzfristig einberufen werden. + + einberufungsfrist: "24 Stunden, bei Notfall kürzer" + + anfrage_an: "spm" + + # --------------------------------------------------------------------------- + # 5.2 VORBEREITUNG UND DOKUMENTATION + # --------------------------------------------------------------------------- + + vorbereitung: + verantwortlich: "spm" + + unterlagen_vorlauf_stunden: 24 + + beschreibung: | + Tagesordnung und Entscheidungsvorlagen müssen 24 Stunden vor + Sitzungsbeginn verfügbar sein. + + tagesordnung_inhalte: + - "Entscheidungsvorlagen (Go-Live, Review, Major Change)" + - "Koordinationsthemen" + - "Eingebrachte Klärungsbedarfe" + - "Informationspunkte" + + entscheidungsvorlagen: + einreichungsfrist: "3 Arbeitstage vor Sitzung" + einreichung_an: "spm" + + vollstaendigkeitspruefung: + verantwortlich: "spm" + bei_unvollstaendigkeit: "Rückfrage an Einreichenden, ggf. Verschiebung" + + referenz: "GOV-TR-014 (Vorbereitungs-Governance)" + + protokollfuehrung: + verantwortlich: "spm" + typ: "Entscheidungsprotokoll" + + pflichtinhalte: + - "Datum und Teilnehmende" + - "Entscheidungen mit Ergebnis" + - "Auflagen (falls vergeben)" + - "Dissens (falls aufgetreten, mit Begründung)" + - "Offene Punkte und Verantwortlichkeiten" + + bei_entscheidungen: + go_live: "Kurz bei Freigabe, vollständig bei Auflagen oder Zurückweisung" + review: "Vollständig bei REDESIGN/RETIRE, kurz bei IMPROVEMENT" + + ablage: + ort: "Confluence" + zugriff: "DIGIT-weit" + + kommunikation: + timing: "Innerhalb von 24 Stunden nach Sitzung" + gegenstand: "Entscheidungen werden an Betroffene kommuniziert" + + # --------------------------------------------------------------------------- + # 5.3 AGENDA-STRUKTUR + # --------------------------------------------------------------------------- + + agenda_struktur: + + beschreibung: | + Die Agenda unterscheidet zwischen Entscheidungsblock und + Koordinationsblock, analog zur DSR-Struktur. + + bloecke: + + - block: "Operative Entscheidungen" + dauer_anteil: "30%" + inhalte: + - "Go-Live-Freigaben" + - "Major-Change-Freigaben" + - "IMPROVEMENT-Freigaben (ressourcenrelevant)" + hinweis: "Nur Themen mit vollständiger Vorlage" + + - block: "Lifecycle-Weichenstellungen" + dauer_anteil: "20%" + inhalte: + - "REDESIGN-Prüfungen" + - "RETIRE-Prüfungen" + hinweis: | + Verfahrensentscheidungen zur Reife-Prüfung, keine + inhaltlich-strategischen Entscheidungen (siehe Abschnitt 3.1)" + + - block: "Koordination" + dauer_anteil: "30%" + inhalte: + - "Status Betrieb/Support" + - "Eingebrachte Klärungsbedarfe" + - "Lifecycle-Koordination" + + - block: "Informationen" + dauer_anteil: "20%" + inhalte: + - "Anstehende Themen (Vorschau)" + - "Rückmeldungen aus MB" + - "Sonstiges" + +# ============================================================================= +# 6. ENTSCHEIDUNGSVERFAHREN +# ============================================================================= + +entscheidungsverfahren: + + # --------------------------------------------------------------------------- + # 6.1 GRUNDPRINZIP + # --------------------------------------------------------------------------- + + grundprinzip: "konsent" + + beschreibung: | + Eine Entscheidung gilt als getroffen, wenn kein schwerwiegender, + begründeter Einwand vorliegt. Enthaltungen blockieren nicht. + + Ein Einwand ist begründet, wenn er einen konkreten Schaden für + Portfolio, Betrieb, Support oder Stakeholder benennt, der durch + die vorgeschlagene Entscheidung entstehen würde. + + # --------------------------------------------------------------------------- + # 6.2 BESCHLUSSFÄHIGKEIT + # --------------------------------------------------------------------------- + + beschlussfaehigkeit: + + regel: "Mindestens 4 von 5 ständigen Mitgliedern anwesend" + + zusatz: "SPM oder dessen Vertretung muss anwesend sein" + + bei_service_spezifischen_entscheidungen: | + Zusätzlich muss der relevante Service Owner anwesend sein. + Bei Abwesenheit des SO wird die Entscheidung vertagt. + + bei_nicht_erfuellung: "Keine Beschlussfassung, Vertagung" + + # --------------------------------------------------------------------------- + # 6.3 EINWAND-VERFAHREN + # --------------------------------------------------------------------------- + + einwand_verfahren: + + beschreibung: | + Das Einwand-Verfahren stellt sicher, dass Bedenken gehört werden, + ohne dass einzelne Mitglieder blockieren können. + + ablauf: + - schritt: 1 + aktion: "Einwendende Rolle benennt konkreten Einwand" + anforderung: "Einwand muss konkreten Schaden benennen" + + - schritt: 2 + aktion: "Einwendende Rolle bringt Alternative ein" + anforderung: "Konstruktiver Gegenvorschlag erforderlich" + + - schritt: 3 + aktion: "SOR versucht Konsensfindung" + moderation: "SPM" + + - schritt: 4 + aktion: "Bei anhaltendem Dissens: SPM entscheidet über weiteres Vorgehen" + optionen: + - "Vertagung mit Arbeitsauftrag" + - "Eskalation ans Mission Board" + + kein_stichentscheid: | + SPM hat keinen Stichentscheid, aber die Verfahrenshoheit. + SPM moderiert die Konsensfindung und entscheidet über + Vertagung oder Eskalation – nicht über den Inhalt. + + # --------------------------------------------------------------------------- + # 6.4 SO-SONDERREGEL + # --------------------------------------------------------------------------- + + so_sonderregel: + + beschreibung: | + Wenn der Service Owner bei einer Entscheidung zu seinem Service + überstimmt wird (d.h. sein Einwand wird nicht akzeptiert), wird + dies explizit protokolliert. + + verfahren: + - "SO-Einwand und Begründung werden protokolliert" + - "Entscheidung der SOR wird protokolliert" + - "SO kann Eskalation ans Mission Board beantragen" + + eskalationsrecht: + berechtigt: "Service Owner" + frist: "5 Arbeitstage nach SOR-Beschluss" + verfahren: "Antrag an SPM, SPM leitet an MB weiter" + + begruendung: | + Der SO trägt die Verantwortung für seinen Service. Wenn das Gremium + gegen seinen Einwand entscheidet, muss dies transparent sein und + der SO muss die Möglichkeit haben, die Entscheidung prüfen zu lassen. + + # --------------------------------------------------------------------------- + # 6.5 ESKALATION + # --------------------------------------------------------------------------- + + eskalation: + + an: "Mission Board" + + trigger: + - "Anhaltender Dissens nach Einwand-Verfahren" + - "SO-Eskalationsantrag nach Überstimmung" + - "Ressourcenkonflikt über SOR-Mandat hinaus" + - "Strategische Tragweite (SOR-Einschätzung)" + + verfahren: + verantwortlich: "spm" + schritte: + - "SPM bereitet Eskalationsvorlage vor" + - "Vorlage enthält: Sachverhalt, Positionen, Empfehlung" + - "MB behandelt in nächster Sitzung (oder Sondersitzung bei Dringlichkeit)" + + aufschiebende_wirkung: | + Eskalation hat aufschiebende Wirkung – die strittige Entscheidung + wird nicht vollzogen, bis MB entschieden hat. + +# ============================================================================= +# 7. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + # --------------------------------------------------------------------------- + # 7.1 EINGANGSSCHNITTSTELLEN + # --------------------------------------------------------------------------- + + eingang: + + - von: "Service Owner" + gegenstand: "Gate-2-Anträge, Review-Vorlagen, Major-Change-Anträge" + verfahren: "Einreichung an SPM, SPM prüft Vollständigkeit" + vorlaufzeit: "3 Arbeitstage vor Sitzung" + + - von: "SHM" + gegenstand: "Klärungsbedarfe aus Stakeholder-Interaktion" + verfahren: "Einbringung durch SHM als ständiges Mitglied" + beispiele: + - "Unklare Servicezuständigkeit bei Stakeholder-Anfrage" + - "Eskalation aus Stakeholder-Feedback" + + - von: "Service Entwicklung / Projekt" + gegenstand: "Services zur Transition" + verfahren: "Formale Übergabe an SO, SO beantragt Gate 2" + referenz: "spm_konzept_service-transition.yaml" + + - von: "Operations / Support" + gegenstand: "Betriebsstatus, Support-Situation, Kapazitätsthemen" + verfahren: "Einbringung durch Ops Mgr / Sup Mgr als ständige Mitglieder" + + # --------------------------------------------------------------------------- + # 7.2 AUSGANGSSCHNITTSTELLEN + # --------------------------------------------------------------------------- + + ausgang: + + - an: "DPM" + gegenstand: "REDESIGN/RETIRE-Entscheidungen" + verfahren: "Übergabe als neuer Demand" + output: + redesign: "Demand (Klassifizierung: Neugestaltung)" + retire: "Demand (Stilllegungsprojekt)" + + - an: "Service Owner" + gegenstand: "Go-Live-Freigabe, Review-Entscheidung, Auflagen" + verfahren: "Kommunikation durch SPM nach Sitzung" + + - an: "Mission Board" + gegenstand: "Eskalationen, Information über kritische Entscheidungen" + verfahren: "SPM bereitet Vorlage vor" + + - an: "Service-Katalog" + gegenstand: "Aktivierung neuer Services" + verfahren: "Nach Go-Live-Freigabe: Katalog-Eintrag wird aktiviert" + referenz: "GOV-TR-021 (Aktivierungskonzept)" + + # --------------------------------------------------------------------------- + # 7.3 INFORMATIONSSCHNITTSTELLEN + # --------------------------------------------------------------------------- + + information: + + - an: "Mission Board" + gegenstand: "Portfolio-Bericht" + rhythmus: "Im Rahmen des regelmäßigen SPM-Berichts ans MB" + inhalte: + - "Aktivierte Services (seit letztem Bericht)" + - "Review-Ergebnisse (Aggregat)" + - "Kritische Themen" + + - an: "DPM" + gegenstand: "Service-Portfolio-Status" + verfahren: "SPM ist DSR-Mitglied und informiert bei Bedarf" + +# ============================================================================= +# 8. GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance_entscheidungen: + + beschreibung: | + Folgende Governance-Entscheidungen wurden im Rahmen der Konzeption + der SOR-Geschäftsordnung getroffen. + + entscheidungen: + + - id: "GOV-SOR-001" + datum: "2025-12-17" + aktualisiert: "2026-03-04" + aktualisiert_durch: "GOV-SHM-029 (ROUTE-DSR → ROUTE-SO); konzeptuelle Verfeinerung: Empfehlung vs. Entscheidung" + frage: "Wie erfolgt die Routing-Klärung bei Unsicherheit (Service vs. Demand)?" + + entscheidung: | + Ursprüngliche Entscheidung (2025-12-17): + Demand-Routing erfolgt direkt an DPM. DSR nur Portfolio-Governance. + + Aktualisiert durch GOV-SHM-029 (2026-03-04 - Workshop-Entscheidung): + Routing-Klärung bei Unsicherheit erfolgt bilateral über den zuständigen + Service Owner. Service Owner gibt Routing-Empfehlung ab. SPM unterstützt + bei der Service-Identifikation. SOR ist zuständig für die FORMELLE BESTÄTIGUNG + von RUN/Change-Routing-Empfehlungen des Service Owners (ROUTE-SO). + Weiterbearbeitung erfolgt "als ob" bereits entschieden, während auf formelle + Bestätigung im nächsten Takt gewartet wird. + + Neue Logik: + - SO gibt Empfehlung ab: RUN/Change → SOR bestätigt formal im nächsten Takt + - SO gibt Empfehlung ab: Demand → DPM nimmt direkt entgegen (kein DSR-Weg) + - SO unsicher? → Bilaterale Klärung mit SPM + - Prozess läuft "als ob" entschieden während auf formelle Gremienbestätigung gewartet wird + + auswirkung_auf: + - dokument: "shm_governance-framework.yaml" + aktion: "ROUTE-DSR → ROUTE-DPM ändern (Demand direkt an DPM); GOV-SOR-001 Referenz aktualisieren" + - dokument: "shm_bedarfsbewertung.yaml" + aktion: "Routing-Pfade: ROUTE-SO statt ROUTE-DSR" + - dokument: "rolle_service-portfolio-manager.yaml" + aktion: "Routing-Klärung (ROUTE-SO oder DPM-Rückkopplung); Governance-Referenz zu GOV-SHM-029" + + status: "aktualisiert" + patch_erforderlich: true + + - id: "GOV-SOR-002" + datum: "2025-12-17" + frage: "Wer sind die ständigen Mitglieder der SOR?" + + entscheidung: | + Ursprüngliche Entscheidung (2025-12-17): + Vier ständige stimmberechtigte Mitglieder mit Operations Manager. + + Aktualisiert durch GOV-SOR-005 (2026-01-31): + Fünf ständige stimmberechtigte Mitglieder: + 1. Service-Portfolio-Manager (SPM) – Vorsitz + 2. Abteilungsleitung Basis & Cloud + 3. Abteilungsleitung Applikationen + 4. Support Manager + 5. Stakeholder-Management (SHM) + + Service Owner ist variables stimmberechtigtes Mitglied bei + service-spezifischen Entscheidungen (Pflicht-Teilnahme). + + begruendung: | + Die fünf Perspektiven (Portfolio, Betrieb Infrastruktur, Betrieb + Anwendungen, Support, Stakeholder) decken den Service-Lifecycle ab. + Beide Betriebsabteilungen sind gleichwertig vertreten. + + status: "aktualisiert" + aktualisiert_durch: "GOV-SOR-005" + + - id: "GOV-SOR-005" + datum: "2026-01-31" + frage: "Wie wird die Betriebsperspektive in der SOR vertreten?" + + entscheidung: | + Beide Abteilungsleitungen (Basis & Cloud, Applikationen) sind + ständige stimmberechtigte Mitglieder der SOR. + + Begründung: + - Respektiert die reale Organisationsstruktur bei DIGIT + - Beide Betriebsperspektiven (Infrastruktur/Anwendungen) sind + für Service-Entscheidungen relevant + - Keine neue Koordinationsebene erforderlich + - Konsistent mit DIGITOM-Designprinzipien: + * Participatory Design (beide Abteilungen eingebunden) + * Provisorische Strukturen (Review vorgesehen) + * Explizites System (klare Regelung statt informelle Absprache) + * Keine neue Hierarchieverschachtelung + + auswirkung_auf: + - dokument: "spm_sor_go.yaml" + aktion: "Zusammensetzung auf 5 ständige Mitglieder erweitert" + - dokument: "spm_rollen.yaml" + aktion: "AL-Rollen mit SOR-Mitgliedschaft ergänzen" + + review: + termin: "2026-07-31" + kriterien: + - "Funktioniert die Doppelbesetzung in der Praxis?" + - "Gibt es Stimmenkonflikte zwischen den Abteilungen?" + - "Wäre eine Konsolidierung sinnvoll?" + + status: "final (provisorisch)" + + - id: "GOV-SOR-003" + datum: "2025-12-17" + frage: "Welche Rolle hat SPM bei Dissens?" + + entscheidung: | + SPM hat Koordinationsverantwortung (analog DPM in der DSR): + - Moderiert Konsensfindung + - Entscheidet über Vertagung oder Eskalation + - Hat KEINEN Stichentscheid über den Inhalt + + status: "final" + + - id: "GOV-SOR-004" + datum: "2025-12-17" + frage: "Wie wird mit irreversibler Service-Ablehnung umgegangen?" + + entscheidung: | + MVP-Scope: Irreversible Service-Ablehnung wird nicht modelliert. + Die Option "Zurück an Transition" deckt den Regelfall ab. + + Wenn eine Situation auftritt, die eine irreversible Ablehnung + erfordert, wird diese ans Mission Board eskaliert. + + begruendung: | + Irreversible Ablehnungen sind voraussichtlich sehr selten. + Die Eskalation ans MB ist für diese Fälle angemessen. + + status: "final (MVP)" + post_mvp: "Evaluation, ob explizite Regelung erforderlich" + +# ============================================================================= +# 9. OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + beschreibung: | + Die folgenden Punkte wurden identifiziert, aber für den MVP bewusst + nicht detailliert. Sie können bei Bedarf ergänzt werden. + + punkte: + + - id: "OPEN-SOR-001" + thema: "Irreversible Service-Ablehnung" + beschreibung: | + Die Entscheidungsoption "Service wird nicht aktiviert, Projekt + wird formal beendet" ist im MVP nicht modelliert. Bei Bedarf + wird ans MB eskaliert. + spaetere_klaerung: "Post-MVP, wenn operative Erfahrung vorliegt" + prioritaet: "niedrig" + + - id: "OPEN-SOR-002" + thema: "Delegationsmöglichkeiten SOR → SO" + beschreibung: | + Kann die SOR wiederkehrende Entscheidungstypen an den SO + delegieren (z.B. Go-Live für Standard-Services)? + spaetere_klaerung: "Evaluation nach 6 Monaten SOR-Betrieb" + prioritaet: "mittel" + + - id: "OPEN-SOR-003" + thema: "Eilentscheidungen außerhalb SOR-Turnus" + beschreibung: | + Können bestimmte Entscheidungen im Umlaufverfahren getroffen + werden, ohne SOR-Sitzung? + spaetere_klaerung: "Bei operativer Erfahrung" + prioritaet: "niedrig" + + - id: "OPEN-SOR-004" + thema: "Verhältnis SOR ↔ IT-Architektur-Board" + beschreibung: | + Beide Gremien sind koordinativ. Abgrenzung bei + Architektur-relevanten Service-Entscheidungen? + spaetere_klaerung: "Bei Definition IT-Architektur-Board" + prioritaet: "mittel" + + # --------------------------------------------------------------------------- + # PATCH-ANFORDERUNGEN + # --------------------------------------------------------------------------- + + patch_anforderungen: + + beschreibung: | + Folgende Patches an bestehenden Dokumenten sind erforderlich, + um Konsistenz herzustellen. + + patches: + + - id: "PATCH-SOR-001" + dokument: "shm_governance-framework.yaml" + abschnitt: "routing_entscheidung.routing_pfade" + aenderung: "ROUTE-SOR → ROUTE-DSR" + begruendung: "GOV-SOR-001: Routing-Klärung zur DSR" + status: "ausstehend" + + - id: "PATCH-SOR-002" + dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "routing_pfade" + aenderung: "ROUTE-SOR entfernen oder zu ROUTE-DSR ändern" + begruendung: "GOV-SOR-001: Routing-Klärung zur DSR" + status: "ausstehend" + +# ============================================================================= +# 10. ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.5" + datum: "2026-03-04" + aenderung: | + Aktualisierung Routing-Klärung: ROUTE-DSR → ROUTE-SO (GOV-SHM-029) + Workshop-Entscheidung führte zur Neukonzeption des Routing-Prozesses: + - GOV-SOR-001 aktualisiert: Routing-Klärung erfolgt bilateral mit Service Owner (nicht DSR) + - Neue Logik: SO entscheidet RUN/Change (→ SOR) oder Demand (→ DPM/DSR) + - SPM unterstützt SO bei Service-Identifikation + - SOR ist Implementierungs-Empfänger von RUN/Change-Entscheidungen + - Abschnitte umfasst/umfasst_nicht, abgrenzung_zu_anderen_gremien aktualisiert + autor: "DIGITOM-Projekt" + governance_referenz: "GOV-SHM-029" + + - version: "1.4" + datum: "2026-01-31" + aenderung: | + Erweiterung der ständigen Mitglieder von 4 auf 5: + - Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen + - Beide Betriebsperspektiven (Infrastruktur/Anwendungen) gleichwertig vertreten + - Beschlussfähigkeit angepasst (4 von 5 statt 3 von 4) + - Neue Governance-Entscheidung GOV-SOR-005 + - Review-Termin für Juli 2026 vorgesehen + autor: "DIGITOM-Projekt" + governance_referenz: "GOV-SOR-005" + begruendung: | + Abgleich mit DIGITOM-Designprinzipien ergab, dass beide + Betriebsperspektiven gleichwertig vertreten sein sollten. + Die Lösung respektiert die bestehende Organisationsstruktur + ohne neue Hierarchieebene zu schaffen. + + - version: "1.3" + datum: "2026-01-31" + aenderung: | + Korrektur Major-Change-Governance: + - Major-Change-Abschnitt präzisiert: Zwei Entscheidungspunkte (Entry-Autorisierung + Gate 3) + - Entscheidungsoptionen für beide Punkte separat dokumentiert + - Abgrenzung zu Normal Change explizit gemacht + - Konzept-Referenz auf spm_practice_change-enablement.yaml ergänzt + autor: "DIGITOM-Projekt" + kontext: "Konsistenz mit Change-Enablement-Konzept v1.2" + + - version: "1.2" + datum: "2026-01-30" + aenderung: | + Präzisierung der Entscheidungskategorien bei Service-Reviews: + - Kategorie "Strategische Entscheidung" umbenannt zu "Lifecycle-Weichenstellung" + - Explizite Abgrenzung ergänzt: SOR trifft Verfahrensentscheidungen + ("Ob reif"), nicht inhaltlich-strategische Entscheidungen ("Ob") + - Agenda-Struktur angepasst: Trennung in "Operative Entscheidungen" + und "Lifecycle-Weichenstellungen" + autor: "DIGITOM-Projekt" + begruendung: | + Die bisherige Bezeichnung "Strategische Entscheidung" war missverständlich, + da strategische Portfolio-Ausrichtung explizit nicht im SOR-Mandat liegt + (siehe Abschnitt 2 "umfasst_nicht"). Die neue Bezeichnung macht klar, + dass die SOR bei REDESIGN/RETIRE die Reife prüft und an DPM übergibt, + aber nicht selbst strategisch entscheidet. + + - version: "1.1" + datum: "2026-01-30" + aenderung: "Anpassung an Service-Lifecycle 3.0: Gate-Referenzen aktualisiert (Go-Live-Freigabe ist Gate 3 / tr_11, nicht Gate 2)" + autor: "DIGITOM-Projekt" + referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" + + - version: "1.0" + datum: "2025-12-17" + aenderung: "Initiale Erstellung basierend auf Konzeptionsarbeit" + autor: "DIGITOM-Projekt" + quelle: "Chat-Session SPM Service Operations Runde" + + enthaltene_entscheidungen: + - "GOV-SOR-001 (Routing zur DSR)" + - "GOV-SOR-002 (Zusammensetzung)" + - "GOV-SOR-003 (SPM-Koordinationsrolle)" - "GOV-SOR-004 (Irreversible Ablehnung → MB)" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml index 59b641d..5715f1d 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml @@ -1,184 +1,193 @@ -metadata: - name: "Design" - yasm_referenz: "LP2: Design new or changed services" - version: "3.0" - status: "draft" - erstellt: "2026-01-22" - aktualisiert: "2026-02-18" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - beschreibung: > - Strategische und architektonische Gestaltung neuer oder wesentlich - geänderter Services. Umfasst Service-Definition, Architektur-Design - und Implementation Blueprint. - - Diese Phase entspricht YASM LP2 (Design new or changed services) und - fokussiert auf die Planung und das Design, NICHT auf die Implementierung. - - aenderungen: - - version: "3.0" - datum: "2026-02-18" - beschreibung: > - Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase - verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1 - ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design. - - - version: "2.1" - datum: "2026-01-30" - beschreibung: > - Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft" - (g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR - Beginn der Transition geprüft werden, um Ressourcenverschwendung zu - vermeiden. Alle Prüfdimensionen nun explizit dokumentiert. - - - version: "2.0" - datum: "2026-01-30" - beschreibung: > - Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_ - umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen. - - - version: "1.0" - datum: "2026-01-22" - beschreibung: "Initiale Erstellung nach YASM LP2" - - schnittstellen: - eingang: - - quelle: "Demand Lifecycle Phase 4" - artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)" - beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert" - ausgang: - - ziel: "Transition" - artefakt: "Service Design Document + Implementation Blueprint" - beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase" - - hinweis: > - Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung). - Nach YASM LP2 werden hier alle strategischen und architektonischen - Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt - als erste Aktivität der Transition-Phase (tr_01). - -# ============================================================================= -# AKTIVITÄTEN -# ============================================================================= - -aktivitaeten: - - # --------------------------------------------------------------------------- - - id: ds_01 - name: "Definieren der erforderlichen Service-Eigenschaften" - typ: aktivitaet - yasm_referenz: "LP2: Service Definition (Utility & Warranty)" - ehemals: "sd_01" - - beschreibung: > - Grundlegende Definition des neuen oder geänderten Services aus - fachlicher Perspektive. - - umfasst: - - "Definition von Zweck, Nutzen, Zielgruppen" - - "Definition der Utility & Warranty des Services" - - "Ableitung der SLA-/SLO-Anforderungen" - - "Ermittlung unterstützender Services und Abhängigkeiten" - - "Identifikation fachlicher und technischer Anforderungen" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: projektleitung - raci: R - - rolle: betriebsteam - raci: C - - rolle: architektur - raci: C - - rolle: spm - raci: C - - # --------------------------------------------------------------------------- - - id: ds_02 - name: "Designen der erforderlichen Service- und Service-Management-Komponenten" - typ: aktivitaet - yasm_referenz: "LP2: Service Architecture Design" - ehemals: "sd_02" - - beschreibung: > - Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell. - - umfasst: - - "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)" - - "Design der Betriebs- und Supportprozesse" - - "Sicherheits-, Compliance- und Datenschutzanforderungen" - - "Monitoring & Reporting-Anforderungen" - - "Tool-/Konfigurationsanforderungen" - - "Rollenmodell (Support, Betrieb, Governance)" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: architektur - raci: R - - rolle: projektteam - raci: R - - rolle: spm - raci: I - - hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)" - - # --------------------------------------------------------------------------- - - id: ds_03 - name: "Beschreiben des Vorgehens zur Implementierung" - typ: aktivitaet - yasm_referenz: "LP2: Implementation Blueprint" - ehemals: "sd_03" - - beschreibung: > - Planen, WIE der Service organisatorisch eingeführt wird - (nicht technisch deployt wird). - - umfasst: - - "Plan für organisatorische Integration" - - "Definition aller Rollenübergaben" - - "Anpassung von Richtlinien, Prozessen, Toolkonfiguration" - - "Definition benötigter Trainings / Kommunikation" - - "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: projektleitung - raci: R - - rolle: betriebsteam - raci: C - - rolle: service_support_team - raci: C - - rolle: spm - raci: I - - # --------------------------------------------------------------------------- - - id: ds_04 - name: "Vorbereiten der Service-Implementierung" - typ: aktivitaet - yasm_referenz: "LP2: Organizational Integration Planning" - ehemals: "sd_04" - - beschreibung: > - Finalisieren aller organisatorischen Voraussetzungen für die - spätere Übergabe in den Betrieb. - - umfasst: - - "Abstimmung mit Betrieb & Support" - - "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind" - - "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht" - - "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: projektleitung - raci: R - - rolle: betriebsteam - raci: C - - rolle: service_support_team - raci: C - - rolle: spm - raci: I - +metadata: + name: "Design" + yasm_referenz: "LP2: Design new or changed services" + version: "3.0" + status: "draft" + erstellt: "2026-01-22" + aktualisiert: "2026-02-18" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + beschreibung: > + Strategische und architektonische Gestaltung neuer oder wesentlich + geänderter Services. Umfasst Service-Definition, Architektur-Design + und Implementation Blueprint. + + Diese Phase entspricht YASM LP2 (Design new or changed services) und + fokussiert auf die Planung und das Design, NICHT auf die Implementierung. + + aenderungen: + - version: "3.0" + datum: "2026-02-18" + beschreibung: > + Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase + verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1 + ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design. + + - version: "2.1" + datum: "2026-01-30" + beschreibung: > + Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft" + (g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR + Beginn der Transition geprüft werden, um Ressourcenverschwendung zu + vermeiden. Alle Prüfdimensionen nun explizit dokumentiert. + + - version: "2.0" + datum: "2026-01-30" + beschreibung: > + Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_ + umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen. + + - version: "1.0" + datum: "2026-01-22" + beschreibung: "Initiale Erstellung nach YASM LP2" + + schnittstellen: + eingang: + - quelle: "Demand Lifecycle Phase 4" + artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)" + beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert" + ausgang: + - ziel: "Transition" + artefakt: "Service Design Document + Implementation Blueprint" + beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase" + + hinweis: > + Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung). + Nach YASM LP2 werden hier alle strategischen und architektonischen + Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt + als erste Aktivität der Transition-Phase (tr_01). + +# ============================================================================= +# AKTIVITÄTEN +# ============================================================================= + +aktivitaeten: + + # --------------------------------------------------------------------------- + - id: ds_01 + name: "Definieren der erforderlichen Service-Eigenschaften" + typ: aktivitaet + yasm_referenz: "LP2: Service Definition (Utility & Warranty)" + ehemals: "sd_01" + + beschreibung: > + Grundlegende Definition des neuen oder geänderten Services aus + fachlicher Perspektive. Diese Aktivität bildet den Startpunkt für + die Erstellung der Service-Definition als zentrales Artefakt. + + umfasst: + - "Definition von Zweck, Nutzen, Zielgruppen" + - "Definition der Utility & Warranty des Services" + - "Ableitung der SLA-/SLO-Anforderungen" + - "Ermittlung unterstützender Services und Abhängigkeiten" + - "Identifikation fachlicher und technischer Anforderungen" + + hinweis_rollen: > + In der Design-Phase agiert die Rolle service_owner als designierter + Service Owner, da der Service noch nicht im Betrieb existiert und die + formale Übernahme der SO-Rolle erst bei Gate 1 (tr_01) erfolgt + (vgl. GOV-TR-004, GOV-TR-006). Die Empfehlung ist eine frühzeitige + Benennung bei/kurz nach Projektfreigabe; der harte Constraint liegt + bei Gate 1. Dieser Hinweis gilt für alle Aktivitäten ds_01 bis ds_04. + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: projektleitung + raci: R + - rolle: betriebsteam + raci: C + - rolle: architektur + raci: C + - rolle: spm + raci: C + + # --------------------------------------------------------------------------- + - id: ds_02 + name: "Designen der erforderlichen Service- und Service-Management-Komponenten" + typ: aktivitaet + yasm_referenz: "LP2: Service Architecture Design" + ehemals: "sd_02" + + beschreibung: > + Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell. + + umfasst: + - "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)" + - "Design der Betriebs- und Supportprozesse" + - "Sicherheits-, Compliance- und Datenschutzanforderungen" + - "Monitoring & Reporting-Anforderungen" + - "Tool-/Konfigurationsanforderungen" + - "Rollenmodell (Support, Betrieb, Governance)" + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: architektur + raci: R + - rolle: projektteam + raci: R + - rolle: spm + raci: I + + hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)" + + # --------------------------------------------------------------------------- + - id: ds_03 + name: "Beschreiben des Vorgehens zur Implementierung" + typ: aktivitaet + yasm_referenz: "LP2: Implementation Blueprint" + ehemals: "sd_03" + + beschreibung: > + Planen, WIE der Service organisatorisch eingeführt wird + (nicht technisch deployt wird). + + umfasst: + - "Plan für organisatorische Integration" + - "Definition aller Rollenübergaben" + - "Anpassung von Richtlinien, Prozessen, Toolkonfiguration" + - "Definition benötigter Trainings / Kommunikation" + - "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)" + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: projektleitung + raci: R + - rolle: betriebsteam + raci: C + - rolle: service_support_team + raci: C + - rolle: spm + raci: I + + # --------------------------------------------------------------------------- + - id: ds_04 + name: "Vorbereiten der Service-Implementierung" + typ: aktivitaet + yasm_referenz: "LP2: Organizational Integration Planning" + ehemals: "sd_04" + + beschreibung: > + Finalisieren aller organisatorischen Voraussetzungen für die + spätere Übergabe in den Betrieb. + + umfasst: + - "Abstimmung mit Betrieb & Support" + - "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind" + - "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht" + - "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist" + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: projektleitung + raci: R + - rolle: betriebsteam + raci: C + - rolle: service_support_team + raci: C + - rolle: spm + raci: I + diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_review.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_review.yaml index 8986363..97aba63 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_review.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_review.yaml @@ -1,268 +1,268 @@ -metadata: - name: "Review" - yasm_referenz: "LP5: Improve the services" - version: "2.0" - status: "draft" - erstellt: "2025-11-26" - aktualisiert: "2026-01-30" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - beschreibung: > - Periodische und anlassbezogene Bewertung der Service-Performance. - Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung - von Verbesserungsmaßnahmen bis hin zur Stilllegung. - - aenderungen: - - version: "2.0" - datum: "2026-01-30" - beschreibung: > - Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review" - zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt. - - - version: "1.1" - datum: "2025-12-17" - beschreibung: | - - Referenz auf spm_konzept_service-review.yaml hinzugefügt - - Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001) - - Output-Präzisierung für Handlungsempfehlungen ergänzt - - - version: "1.0" - datum: "2025-11-26" - beschreibung: "Initiale Erstellung" - - referenzen: - konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" - governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005" - - schnittstellen: - eingang: - - quelle: "Operation" - artefakt: "Service-Qualitätsbericht, Monitoring-Daten" - - quelle: "Support" - artefakt: "Support-KPIs, Problem Records, Incident-Trends" - ausgang: - - ziel: "Operation" - artefakt: "Freigegebene Verbesserungsmaßnahmen" - bedingung: "Bei Service Improvement" - - ziel: "Demand-Lifecycle (DPM)" - artefakt: "Demand für strukturelle Änderung" - bedingung: "Bei Service Redesign / Erweiterung" - - ziel: "Demand-Lifecycle (DPM)" - artefakt: "Retirement-Plan, Decommissioning-Auftrag" - bedingung: "Bei Service außer Betrieb nehmen" - -# ============================================================================= -# AKTIVITÄTEN -# ============================================================================= - -aktivitaeten: - - # --------------------------------------------------------------------------- - - id: rv_01 - name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs" - typ: aktivitaet - ehemals: "sr_01" - - beschreibung: > - Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs, - um mittelfristige Verbesserungen anzustoßen. - - umfasst: - - "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)" - - "Identifikation wiederkehrender Tickets und systemischer Ursachen" - - "Abgleich mit Problem Records" - - "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)" - - mitarbeit: - - rolle: service_owner - raci: A - kontext: "Priorisiert und bestätigt Maßnahmen" - - rolle: problem_manager - raci: R - kontext: "Führt taktische Analyse durch" - - # --------------------------------------------------------------------------- - - id: rv_02 - name: "Service Performance & Improvement Review" - typ: aktivitaet - ehemals: "sr_02" - - beschreibung: > - Operativer Review des Servicezustands basierend auf Qualitätsberichten, - Supportdaten und Problem-Analysen. - - konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema" - governance_referenz: "GOV-SR-001" - - methodik: - beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung" - dimensionen: - - "SR-D1: Leistungserbringung" - - "SR-D2: Betriebsstabilität" - - "SR-D3: Nutzerzufriedenheit" - - "SR-D4: Zukunftsfähigkeit" - bewertungsskala: "Grün / Gelb / Rot" - - umfasst: - - "Abgleich der Service-Leistung gegen Ziele und SLAs" - - "Bewertung des Gesamterfüllungsgrades der Serviceerbringung" - - "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe" - - "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)" - - "Vorbereitung für SOR-Review" - - "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist" - - output_praezisierung: - handlungsempfehlung: - optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"] - dokumentation: "Service-Definition -> service_review" - - mitarbeit: - - rolle: service_owner - raci: A/R - kontext: "Führt Review durch" - - rolle: spm - raci: I - - # --------------------------------------------------------------------------- - - id: rv_03 - name: "SOR: Periodischer Service Review" - typ: aktivitaet - ehemals: "sr_03" - - beschreibung: > - Die SOR bewertet regelmäßig die Serviceleistung und trifft operative - Entscheidungen. - - umfasst: - - "Sichtung des Service Performance & Improvement Reviews" - - "Bewertung der Stabilität & Betriebsreife" - - "Priorisierung operativer Verbesserungen" - - "Freigabe kleinerer Verbesserungsmaßnahmen" - - "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist" - - "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen" - - mitarbeit: - - rolle: sor - raci: A - kontext: "Trifft Entscheidungen" - - rolle: service_owner - raci: R - kontext: "Berichtet & präsentiert" - - entscheidungspfade: - - id: ep_weiter - name: "Weiter wie bisher" - bedingung: "Service stabil, keine Maßnahmen erforderlich" - ziel_aktivitaet: null - ziel_phase: "Operation" - - - id: ep_improvement - name: "Verbesserung nötig (klein)" - bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung" - ziel_aktivitaet: "rv_04" - ziel_phase: null - - - id: ep_redesign - name: "Strukturelle Überarbeitung nötig" - bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht" - ziel_aktivitaet: "rv_05" - ziel_phase: null - - - id: ep_retirement - name: "Service End-of-Life" - bedingung: "Service soll stillgelegt werden" - ziel_aktivitaet: "rv_06" - ziel_phase: null - - # --------------------------------------------------------------------------- - - id: rv_04 - name: "Service Improvement" - typ: aktivitaet - ehemals: "sr_04" - - beschreibung: > - Entscheidung aus der SOR: Planung und Steuerung von kleineren - Verbesserungsmaßnahmen innerhalb des Service. - - umfasst: - - "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen" - - "Aufwandsschätzung und Priorisierung" - - "Festlegen der Zielmetriken für Verbesserung" - - "Zuweisung der Verantwortlichkeiten" - - "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden" - - mitarbeit: - - rolle: service_owner - raci: A/R - kontext: "Führt Improvements, steuert Maßnahmen" - - rolle: spm - raci: C - kontext: "Für portfolio-relevante Anpassungen" - - rolle: problem_manager - raci: C - kontext: "Für Problem-bezogene Maßnahmen" - - ausgang: - ziel_phase: "Operation" - beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb" - - # --------------------------------------------------------------------------- - - id: rv_05 - name: "Service Redesign / Erweiterung" - typ: aktivitaet - ehemals: "sr_05" - - beschreibung: > - Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service - auf Basis von SOR- oder Review-Entscheidungen. - - umfasst: - - "Überarbeitung der Service-Definitionen" - - "Anpassung von Komponenten, Prozessen oder Rollen" - - "Identifikation von Anforderungen für Entwicklungsprozess" - - "Übergabe an Demand-Lifecycle-Prozess" - - mitarbeit: - - rolle: service_owner - raci: A - kontext: "Verantwortet Redesign" - - rolle: spm - raci: C - kontext: "Prüft Portfolio-Anpassungen" - - ausgang: - ziel_phase: "Demand-Lifecycle (DPM)" - artefakt: "Neuer Demand" - beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle" - - # --------------------------------------------------------------------------- - - id: rv_06 - name: "Service außer Betrieb nehmen" - typ: aktivitaet - ehemals: "sr_06" - - beschreibung: > - Strukturierte Entscheidung und kontrollierte Abschaltung eines Services. - - umfasst: - - "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)" - - "Bewertung durch SOR" - - "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)" - - "Koordination mit Portfolio (SPM)" - - "Übergabe an Projekt-/Transitionsthemen falls notwendig" - - mitarbeit: - - rolle: sor - raci: A - kontext: "Entscheidet" - - rolle: service_owner - raci: R - kontext: "Führt Retire-Plan aus" - - rolle: spm - raci: C - kontext: "Aktualisiert Portfolio" - - ausgang: - ziel_phase: "Demand-Lifecycle (DPM)" - artefakt: "Retirement-Plan / Decommissioning-Auftrag" - beschreibung: "Stilllegung wird als Demand/Projekt koordiniert" +metadata: + name: "Review" + yasm_referenz: "LP5: Improve the services" + version: "2.0" + status: "draft" + erstellt: "2025-11-26" + aktualisiert: "2026-01-30" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + beschreibung: > + Periodische und anlassbezogene Bewertung der Service-Performance. + Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung + von Verbesserungsmaßnahmen bis hin zur Stilllegung. + + aenderungen: + - version: "2.0" + datum: "2026-01-30" + beschreibung: > + Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review" + zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt. + + - version: "1.1" + datum: "2025-12-17" + beschreibung: | + - Referenz auf spm_konzept_service-review.yaml hinzugefügt + - Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001) + - Output-Präzisierung für Handlungsempfehlungen ergänzt + + - version: "1.0" + datum: "2025-11-26" + beschreibung: "Initiale Erstellung" + + referenzen: + konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" + governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005" + + schnittstellen: + eingang: + - quelle: "Operation" + artefakt: "Service-Qualitätsbericht, Monitoring-Daten" + - quelle: "Support" + artefakt: "Support-KPIs, Problem Records, Incident-Trends" + ausgang: + - ziel: "Operation" + artefakt: "Freigegebene Verbesserungsmaßnahmen" + bedingung: "Bei Service Improvement" + - ziel: "Demand-Lifecycle (DPM)" + artefakt: "Demand für strukturelle Änderung" + bedingung: "Bei Service Redesign / Erweiterung" + - ziel: "Demand-Lifecycle (DPM)" + artefakt: "Retirement-Plan, Decommissioning-Auftrag" + bedingung: "Bei Service außer Betrieb nehmen" + +# ============================================================================= +# AKTIVITÄTEN +# ============================================================================= + +aktivitaeten: + + # --------------------------------------------------------------------------- + - id: rv_01 + name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs" + typ: aktivitaet + ehemals: "sr_01" + + beschreibung: > + Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs, + um mittelfristige Verbesserungen anzustoßen. + + umfasst: + - "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)" + - "Identifikation wiederkehrender Tickets und systemischer Ursachen" + - "Abgleich mit Problem Records" + - "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)" + + mitarbeit: + - rolle: service_owner + raci: A + kontext: "Priorisiert und bestätigt Maßnahmen" + - rolle: problem_manager + raci: R + kontext: "Führt taktische Analyse durch" + + # --------------------------------------------------------------------------- + - id: rv_02 + name: "Service Performance & Improvement Review" + typ: aktivitaet + ehemals: "sr_02" + + beschreibung: > + Operativer Review des Servicezustands basierend auf Qualitätsberichten, + Supportdaten und Problem-Analysen. + + konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema" + governance_referenz: "GOV-SR-001" + + methodik: + beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung" + dimensionen: + - "SR-D1: Leistungserbringung" + - "SR-D2: Betriebsstabilität" + - "SR-D3: Nutzerzufriedenheit" + - "SR-D4: Zukunftsfähigkeit" + bewertungsskala: "Grün / Gelb / Rot" + + umfasst: + - "Abgleich der Service-Leistung gegen Ziele und SLAs" + - "Bewertung des Gesamterfüllungsgrades der Serviceerbringung" + - "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe" + - "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)" + - "Vorbereitung für SOR-Review" + - "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist" + + output_praezisierung: + handlungsempfehlung: + optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"] + dokumentation: "Service-Definition -> service_review" + + mitarbeit: + - rolle: service_owner + raci: A/R + kontext: "Führt Review durch" + - rolle: spm + raci: I + + # --------------------------------------------------------------------------- + - id: rv_03 + name: "SOR: Periodischer Service Review" + typ: aktivitaet + ehemals: "sr_03" + + beschreibung: > + Die SOR bewertet regelmäßig die Serviceleistung und trifft operative + Entscheidungen. + + umfasst: + - "Sichtung des Service Performance & Improvement Reviews" + - "Bewertung der Stabilität & Betriebsreife" + - "Priorisierung operativer Verbesserungen" + - "Freigabe kleinerer Verbesserungsmaßnahmen" + - "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist" + - "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen" + + mitarbeit: + - rolle: sor + raci: A + kontext: "Trifft Entscheidungen" + - rolle: service_owner + raci: R + kontext: "Berichtet & präsentiert" + + entscheidungspfade: + - id: ep_weiter + name: "Weiter wie bisher" + bedingung: "Service stabil, keine Maßnahmen erforderlich" + ziel_aktivitaet: null + ziel_phase: "Operation" + + - id: ep_improvement + name: "Verbesserung nötig (klein)" + bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung" + ziel_aktivitaet: "rv_04" + ziel_phase: null + + - id: ep_redesign + name: "Strukturelle Überarbeitung nötig" + bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht" + ziel_aktivitaet: "rv_05" + ziel_phase: null + + - id: ep_retirement + name: "Service End-of-Life" + bedingung: "Service soll stillgelegt werden" + ziel_aktivitaet: "rv_06" + ziel_phase: null + + # --------------------------------------------------------------------------- + - id: rv_04 + name: "Service Improvement" + typ: aktivitaet + ehemals: "sr_04" + + beschreibung: > + Entscheidung aus der SOR: Planung und Steuerung von kleineren + Verbesserungsmaßnahmen innerhalb des Service. + + umfasst: + - "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen" + - "Aufwandsschätzung und Priorisierung" + - "Festlegen der Zielmetriken für Verbesserung" + - "Zuweisung der Verantwortlichkeiten" + - "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden" + + mitarbeit: + - rolle: service_owner + raci: A/R + kontext: "Führt Improvements, steuert Maßnahmen" + - rolle: spm + raci: C + kontext: "Für portfolio-relevante Anpassungen" + - rolle: problem_manager + raci: C + kontext: "Für Problem-bezogene Maßnahmen" + + ausgang: + ziel_phase: "Operation" + beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb" + + # --------------------------------------------------------------------------- + - id: rv_05 + name: "Service Redesign / Erweiterung" + typ: aktivitaet + ehemals: "sr_05" + + beschreibung: > + Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service + auf Basis von SOR- oder Review-Entscheidungen. + + umfasst: + - "Überarbeitung der Service-Definitionen" + - "Anpassung von Komponenten, Prozessen oder Rollen" + - "Identifikation von Anforderungen für Entwicklungsprozess" + - "Übergabe an Demand-Lifecycle-Prozess" + + mitarbeit: + - rolle: service_owner + raci: A + kontext: "Verantwortet Redesign" + - rolle: spm + raci: C + kontext: "Prüft Portfolio-Anpassungen" + + ausgang: + ziel_phase: "Demand-Lifecycle (DPM)" + artefakt: "Neuer Demand" + beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle" + + # --------------------------------------------------------------------------- + - id: rv_06 + name: "Service außer Betrieb nehmen" + typ: aktivitaet + ehemals: "sr_06" + + beschreibung: > + Strukturierte Entscheidung und kontrollierte Abschaltung eines Services. + + umfasst: + - "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)" + - "Bewertung durch SOR" + - "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)" + - "Koordination mit Portfolio (SPM)" + - "Übergabe an Projekt-/Transitionsthemen falls notwendig" + + mitarbeit: + - rolle: sor + raci: A + kontext: "Entscheidet" + - rolle: service_owner + raci: R + kontext: "Führt Retire-Plan aus" + - rolle: spm + raci: C + kontext: "Aktualisiert Portfolio" + + ausgang: + ziel_phase: "Demand-Lifecycle (DPM)" + artefakt: "Retirement-Plan / Decommissioning-Auftrag" + beschreibung: "Stilllegung wird als Demand/Projekt koordiniert" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml index 928dcf8..01356f1 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml @@ -1,578 +1,578 @@ -metadata: - name: "Transition" - yasm_referenz: "LP3: Build new or changed services" - version: "2.0" - status: "draft" - erstellt: "2026-01-30" - aktualisiert: "2026-02-18" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - beschreibung: > - Technische Realisierung und Überführung des Services in den produktiven - Betrieb. Umfasst Entry-Gate (Gate 1), Build/Konfiguration, Test, - Deployment und Go-Live-Freigabe. - - Diese Phase konsolidiert die ehemaligen Phasen "Service Entwicklung" und - "Service Transition" und entspricht YASM LP3 (Build new or changed services). - - aenderungen: - - version: "2.0" - datum: "2026-02-18" - beschreibung: > - Gate 1 aus Design-Phase hierher verschoben als tr_01 (Entry-Gate der - Transition). Alle Aktivitäts-IDs um +1 verschoben: ehemals tr_01-tr_11 - wird zu tr_02-tr_12. Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist - nun tr_12 (ehemals tr_11). Die Transition-Phase enthält nun alle 3 Gates. - - - version: "1.0" - datum: "2026-01-30" - beschreibung: > - Konsolidierung auf 5-Phasen-Modell: Zusammenführung von - "Service Entwicklung" (se_01-se_07) und "Service Transition" (st_01-st_04) - zu einer Phase "Transition" (tr_01-tr_11). Gate 2 (Entry-Prüfung) und - Gate 3 (Go-Live-Freigabe) integriert. ELS verschoben nach Operation. - - schnittstellen: - eingang: - - quelle: "Design" - artefakt: "Service Design Document + Implementation Blueprint" - trigger: "Abschluss der Design-Phase (ds_04)" - ausgang: - - ziel: "Operation" - artefakt: "Aktivierter Service" - trigger: "SOR-Freigabe an Gate 3 (tr_12)" - - ziel: "Support" - artefakt: "Aktivierter Service mit Support-Dokumentation" - trigger: "SOR-Freigabe an Gate 3 (tr_12)" - - hinweis: > - Die Transition-Phase enthält drei Gates: Gate 1 (tr_01) als Entry-Gate, - Gate 2 (tr_09) prüft die Übergabefähigkeit nach dem Build, Gate 3 (tr_12) - gibt den Go-Live frei. Early Life Support (ELS) wurde in die Operation-Phase - verschoben. - -# ============================================================================= -# GATE 1: ENTRY-GATE (TRANSITION ENTRY) -# ============================================================================= - -aktivitaeten: - - # --------------------------------------------------------------------------- - - id: tr_01 - name: "Gate 1: Entwicklung oder Konfiguration?" - typ: gate - gate_nummer: 1 - yasm_referenz: "LP3 Entry Gate" - ehemals: "ds_05" - - beschreibung: > - Entscheidung, ob die Service-Komponenten entwickelt oder nur - konfiguriert werden müssen. Dies ist Gate 1 im Service-Lifecycle: - das Entry-Gate der Transition-Phase. - - WICHTIG: Diese Entscheidung erfordert SOR-Approval, da sie Budget- - und Ressourcenimplikationen hat. - - umfasst: - - "Aufwandsschätzung (Build vs. Configure)" - - "Bewertung technischer Risiken" - - "Budget-Abgleich" - - "ggf. Lieferanten-Einbindung (Beschaffung)" - - "SOR-Vorlage für Gate-Freigabe" - - entscheidungspfade: - - id: entwicklung - name: "Entwicklung" - beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich" - folgeaktivitaet: tr_02 - governance: "SOR-Approval erforderlich" - - - id: konfiguration - name: "Konfiguration" - beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst" - folgeaktivitaet: tr_05 - governance: "SOR-Approval erforderlich" - hinweis: "Überspringt Entwicklungsaktivitäten (tr_02-tr_04), startet direkt bei Konfiguration" - - mitarbeit: - - rolle: sor - raci: A - kontext: "Freigabe-Entscheidung für Eintritt in Transition" - - rolle: service_owner - raci: R - kontext: "Antragsteller und fachliche Empfehlung" - - rolle: projektleitung - raci: R - kontext: "Aufwandsschätzung und Ressourcenplanung" - - rolle: architektur - raci: R - kontext: "Technische Bewertung" - - rolle: spm - raci: C - kontext: "Portfolio-Perspektive" - - rolle: lieferant - raci: I - kontext: "Information für Beschaffungsplanung" - - pruef_dimensionen: - - id: g1_dim_01 - name: "Design-Vollständigkeit" - beschreibung: "Ist das Service Design Document vollständig und schlüssig?" - showstopper: true - - - id: g1_dim_02 - name: "Budget-Verfügbarkeit" - beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?" - showstopper: true - - - id: g1_dim_03 - name: "Projektressourcen" - beschreibung: "Können Ressourcen (intern/extern) für die Transition mobilisiert werden?" - showstopper: true - - - id: g1_dim_04 - name: "Betriebs- und Support-Bereitschaft" - beschreibung: > - Haben Betrieb und Support grundsätzlich die Kapazität und Bereitschaft, - diesen Service nach Abschluss der Transition zu übernehmen? - - WICHTIG: Dies ist eine prinzipielle Prüfung VOR Beginn der Transition. - Ohne grundsätzliches Commitment darf die Transition nicht starten, - da sonst Ressourcen für einen Service aufgewendet werden, der nicht - betrieben werden kann. - - Die operative Bestätigung (konkreter Termin, Personal eingeplant) - erfolgt an Gate 3. - showstopper: true - werte: - - "bestaetigt" - - "unter_vorbehalt" - - "nicht_gegeben" - hinweis: "Bei 'nicht_gegeben' ist Gate 1 nicht passierbar." - - - id: g1_dim_05 - name: "Risikobewertung" - beschreibung: "Sind Risiken identifiziert und bewertet?" - showstopper: false - - governance_hinweis: > - Die SOR-Freigabe an Gate 1 stellt sicher, dass: - 1. Das Design vollständig und schlüssig ist - 2. Budget für die gewählte Implementierungsstrategie verfügbar ist - 3. Ressourcen (intern/extern) für Transition mobilisiert werden können - 4. Betrieb und Support grundsätzlich zur Übernahme bereit sind - 5. Risiken identifiziert und bewertet sind - -# ============================================================================= -# AKTIVITÄTEN – BUILD (ehemals Service Entwicklung) -# ============================================================================= - - # --------------------------------------------------------------------------- - - id: tr_02 - name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten" - typ: aktivitaet - yasm_referenz: "LP3.1: Coordinate build and acquisition activities" - ehemals: "se_01 / tr_01" - - beschreibung: > - Steuern der Entwicklungsaktivitäten im Projekt. - - umfasst: - - "Abstimmung mit Lieferanten" - - "Ressourcenplanung" - - "Termin- und Budgetnachführung" - - "Sicherstellung von Change-Kontrollen" - - "Definition von Build- und Konfigurationspaketen" - - mitarbeit: - - rolle: projektleitung - raci: A - - rolle: architektur - raci: C - - rolle: service_owner - raci: I - - rolle: lieferant - raci: C/I - - # --------------------------------------------------------------------------- - - id: tr_03 - name: "Entwickeln von Anwendungen und Systemen" - typ: aktivitaet - yasm_referenz: "LP3.2: Develop applications and systems" - ehemals: "se_02 / tr_02" - - beschreibung: > - Realisierung der technischen Service-Komponenten. - - umfasst: - - "Softwareentwicklung" - - "Customizing" - - "Schnittstellenentwicklung" - - "Infrastrukturaufbau" - - "Versionierung & Dokumentation" - - "Testdaten & Migrationspfade vorbereiten" - - mitarbeit: - - rolle: projektteam - raci: R - kontext: "Interne Entwicklung" - - rolle: lieferant - raci: R - kontext: "Externe Entwicklung" - - rolle: projektleitung - raci: A - - rolle: service_owner - raci: C - - rolle: architektur - raci: C - - # --------------------------------------------------------------------------- - - id: tr_04 - name: "Entgegennehmen der Service-Komponenten" - typ: aktivitaet - yasm_referenz: "LP3.3: Accept service components" - ehemals: "se_03 / tr_03" - - beschreibung: > - Qualitätssicherung beim Übergang vom Entwicklungs- zur Testphase. - - umfasst: - - "Eingangskontrolle" - - "Prüfung von Vollständigkeit / Qualität" - - "Sicherstellung der Dokumentationen" - - "Übergabe an Testmanagement" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: projektleitung - raci: R - - rolle: testmanagement - raci: R - - rolle: lieferant - raci: C - - # --------------------------------------------------------------------------- - - id: tr_05 - name: "Konfiguration der Service-Komponenten" - typ: aktivitaet - yasm_referenz: "LP3.4: Configure service components" - ehemals: "se_04 / tr_04" - - beschreibung: > - Einrichtung der Konfigurationsparameter, Settings, Rollen, Zugänge. - - umfasst: - - "Setup von Parametern, Policies, Templates" - - "Toolkonfiguration (ITSM-Systeme, Monitoring)" - - "Anpassung bestehender Komponenten" - - "Verknüpfung mit Service-Katalog / Portfolio" - - mitarbeit: - - rolle: projektteam - raci: R - - rolle: service_owner - raci: A - - rolle: betriebsteam - raci: C - - rolle: service_support_team - raci: C - - hinweis: > - Diese Aktivität wird bei Gate-1-Entscheidung "Konfiguration" - als Einstiegspunkt verwendet (überspringt tr_02-tr_04). - - # --------------------------------------------------------------------------- - - id: tr_06 - name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation" - typ: aktivitaet - yasm_referenz: "LP3.5: Document the services" - ehemals: "se_05 / tr_05" - - beschreibung: > - Alle Betriebsunterlagen werden erstellt oder aktualisiert. - - umfasst: - - "Service Operation Manual" - - "Supportanleitungen" - - "Monitoring-Spezifikationen" - - "Eskalationswege" - - "Standard Changes" - - "Konfigurations-/Betriebsrichtlinien" - - mitarbeit: - - rolle: service_owner - raci: A - - rolle: projektteam - raci: R - - rolle: betriebsteam - raci: C - - rolle: service_support_team - raci: C - - # --------------------------------------------------------------------------- - - id: tr_07 - name: "Testen der Service-Komponenten" - typ: aktivitaet - yasm_referenz: "LP3.6: Test the services" - ehemals: "se_06 / tr_06" - - beschreibung: > - Verifizierung, dass alle Servicekomponenten funktionsfähig und - bereit für den Betrieb sind. - - umfasst: - - "Funktionstests" - - "Integrationstests" - - "Abnahmetests" - - "Nachweis der Betriebsreife" - - "Testprotokolle & Freigaben" - - mitarbeit: - - rolle: testmanagement - raci: R - - rolle: projektleitung - raci: A - - rolle: service_owner - raci: C - - rolle: lieferant - raci: C/I - - # --------------------------------------------------------------------------- - - id: tr_08 - name: "Formale Übergabe (Build abgeschlossen)" - typ: aktivitaet - yasm_referenz: "LP3.7: Prepare for service activation" - ehemals: "se_07 / tr_07" - - beschreibung: > - Der Build ist abgeschlossen. Alle Artefakte werden für die - Entry-Prüfung (Gate 2) bereitgestellt. - - umfasst: - - "Bereitstellung aller Betriebsunterlagen" - - "Bereitstellung der Testprotokolle" - - "Dokumentierter Übergabe-Termin" - - "Vorbereitung Gate-2-Antrag" - - mitarbeit: - - rolle: projektleitung - raci: A - - rolle: service_owner - raci: R - kontext: "Fachliche Freigabe" - - rolle: spm - raci: I - kontext: "Für Portfolio-Aktualisierung" - - rolle: betriebsteam - raci: C - kontext: "Übernahmebereitschaft prüfen" - - rolle: service_support_team - raci: C - kontext: "Support-Bereitschaft prüfen" - -# ============================================================================= -# GATE 2: ENTRY-PRÜFUNG -# ============================================================================= - - # --------------------------------------------------------------------------- - - id: tr_09 - name: "Gate 2: Entry-Prüfung nach Build" - typ: gate - gate_nummer: 2 - ehemals: "tr_08" - - beschreibung: > - Validierung der Übergabefähigkeit nach Abschluss des Builds. - Der Service Owner prüft, ob alle Voraussetzungen für die - Deploy-Aktivitäten erfüllt sind. - - Dies ist eine SO-Einzelentscheidung (keine Gremienentscheidung). - - umfasst: - - "Prüfung der Übergabe-Vollständigkeit (alle Artefakte vorhanden)" - - "Prüfung des Abnahme-Status (Auftraggeber-Abnahme liegt vor)" - - "Ressourcen-Outlook (Betrieb und Support prinzipiell vorbereitet)" - - "Pilot-Entscheidung (falls erforderlich)" - - "Dokumentation im Transition-Steckbrief" - - entscheidungspfade: - - id: freigabe - name: "Freigabe" - beschreibung: "Weiter zu Deploy-Aktivitäten" - folgeaktivitaet: tr_10 - - - id: freigabe_mit_auflagen - name: "Freigabe mit Auflagen" - beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden" - folgeaktivitaet: tr_10 - - - id: zurueck - name: "Zurück an Build" - beschreibung: "Nachbesserung erforderlich" - folgeaktivitaet: tr_02 - hinweis: "Je nach Mängelart kann auch bei tr_05-tr_07 eingestiegen werden" - - - id: ablehnung - name: "Ablehnung" - beschreibung: "Endgültige Ablehnung des Service-Vorhabens" - folgeaktivitaet: null - hinweis: "Erfordert SOR-Eskalation" - - mitarbeit: - - rolle: service_owner - raci: A - kontext: "Gate-Keeper" - - rolle: projektleitung - raci: R - kontext: "Liefert Übergabe-Nachweis" - - rolle: betriebsteam - raci: C - kontext: "Bestätigt Übernahmebereitschaft" - - rolle: service_support_team - raci: C - kontext: "Bestätigt Support-Bereitschaft" - - rolle: spm - raci: I - kontext: "Bei Eskalation: Beratung" - - governance_hinweis: > - Gate 2 ist eine operative Entscheidung des Service Owners. - Bei Unklarheit kann der SO das SPM zur Beratung hinzuziehen. - Ablehnung erfordert SOR-Eskalation. - -# ============================================================================= -# AKTIVITÄTEN – DEPLOY (ehemals Service Transition) -# ============================================================================= - - # --------------------------------------------------------------------------- - - id: tr_10 - name: "Ausrollen der Service-Komponenten" - typ: aktivitaet - ehemals: "st_02 / tr_09" - - beschreibung: > - Technische Bereitstellung/Deployment des Services in die produktive Umgebung. - - umfasst: - - "Deployment von Anwendungen, Systemen, Komponenten" - - "Konfiguration produktiver Systeme" - - "Migration von Daten" - - "Aktivierung von Monitoring" - - "Sicherstellen von Zugängen, Rollen, Berechtigungen" - - "Schnittstellen-Integration" - - "Technische Abnahmetests" - - mitarbeit: - - rolle: betriebsteam - raci: R - - rolle: service_owner - raci: A - - rolle: spm - raci: C - - rolle: lieferant - raci: C/I - - # --------------------------------------------------------------------------- - - id: tr_11 - name: "Vorbereiten der Service-Aktivierung" - typ: aktivitaet - ehemals: "st_03 / tr_10" - - beschreibung: > - Prüfung der Betriebsbereitschaft und Vorbereitung des Go-Live-Antrags - für Gate 3. - - umfasst: - - "Review der Betriebsdokumentation" - - "Prüfung der Überwachungsregeln" - - "Prüfung der Rollen- und Eskalationswege" - - "Sicherstellen von Zugriffen & Toolanbindung" - - "Vorbereitung der Go-Live-Kommunikation" - - "Validierung der Service-Funktionalität mit Supportteams" - - "Vorbereitung Gate-3-Antrag (SOR-Vorlage)" - - mitarbeit: - - rolle: betriebsteam - raci: R - - rolle: service_owner - raci: A - kontext: "Fachliche Freigabe" - - rolle: spm - raci: C - -# ============================================================================= -# GATE 3: GO-LIVE-FREIGABE -# ============================================================================= - - # --------------------------------------------------------------------------- - - id: tr_12 - name: "Gate 3: Go-Live-Freigabe" - typ: gate - gate_nummer: 3 - ehemals: "st_01 / tr_11" - - beschreibung: > - Portfolio-Freigabe und formale Aktivierung des Services. - Die SOR prüft die Betriebsreife aus Portfolio-Perspektive und - beschließt die Aufnahme ins Service-Portfolio. - - Dies ist das Exit-Gate aus der Transition-Phase. - - umfasst: - - "Prüfung der Portfolio-Konsistenz (strategische Ausrichtung)" - - "Prüfung der Betriebsreife (SO-Bestätigung)" - - "Prüfung der Support-Bereitschaft" - - "Prüfung der SLA/SLO-Vereinbarung" - - "Prüfung der Auflagen-Erfüllung aus Gate 2" - - "Bewertung der Geschäftskritikalität" - - "Beschluss: Go-Live / Go-Live mit Auflagen / Zurück / Ablehnung" - - "Formale Aufnahme ins Service-Portfolio" - - entscheidungspfade: - - id: go_live - name: "Go-Live" - beschreibung: "Service wird aktiviert, Übergang zu Operation" - folgeaktivitaet: op_01 - folge_phase: "Operation" - - - id: go_live_mit_auflagen - name: "Go-Live mit Auflagen" - beschreibung: "Service wird aktiviert, definierte Punkte müssen nachgearbeitet werden" - folgeaktivitaet: op_01 - folge_phase: "Operation" - - - id: zurueck - name: "Zurück an Transition" - beschreibung: "Nachbesserung erforderlich" - folgeaktivitaet: tr_10 - hinweis: "Je nach Mängelart kann auch bei tr_09 eingestiegen werden" - - - id: ablehnung - name: "Ablehnung" - beschreibung: "Endgültige Ablehnung des Service-Vorhabens" - folgeaktivitaet: null - - mitarbeit: - - rolle: sor - raci: A - kontext: "Endgültiger Beschluss (Konsent-Verfahren)" - - rolle: service_owner - raci: R - kontext: "Antragsteller" - - rolle: spm - raci: C - kontext: "Portfolio-Perspektive" - - rolle: projektleitung - raci: C - - rolle: operations_manager - raci: C - - rolle: support_manager - raci: C - - governance_hinweis: > - Gate 3 ist eine SOR-Entscheidung nach dem Konsent-Prinzip. - Die SOR-Freigabe bewirkt gleichzeitig: - 1. Aufnahme ins Service-Portfolio - 2. Aktivierung des Katalog-Eintrags - 3. Formale Bestätigung des Service Owners +metadata: + name: "Transition" + yasm_referenz: "LP3: Build new or changed services" + version: "2.0" + status: "draft" + erstellt: "2026-01-30" + aktualisiert: "2026-02-18" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + beschreibung: > + Technische Realisierung und Überführung des Services in den produktiven + Betrieb. Umfasst Entry-Gate (Gate 1), Build/Konfiguration, Test, + Deployment und Go-Live-Freigabe. + + Diese Phase konsolidiert die ehemaligen Phasen "Service Entwicklung" und + "Service Transition" und entspricht YASM LP3 (Build new or changed services). + + aenderungen: + - version: "2.0" + datum: "2026-02-18" + beschreibung: > + Gate 1 aus Design-Phase hierher verschoben als tr_01 (Entry-Gate der + Transition). Alle Aktivitäts-IDs um +1 verschoben: ehemals tr_01-tr_11 + wird zu tr_02-tr_12. Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist + nun tr_12 (ehemals tr_11). Die Transition-Phase enthält nun alle 3 Gates. + + - version: "1.0" + datum: "2026-01-30" + beschreibung: > + Konsolidierung auf 5-Phasen-Modell: Zusammenführung von + "Service Entwicklung" (se_01-se_07) und "Service Transition" (st_01-st_04) + zu einer Phase "Transition" (tr_01-tr_11). Gate 2 (Entry-Prüfung) und + Gate 3 (Go-Live-Freigabe) integriert. ELS verschoben nach Operation. + + schnittstellen: + eingang: + - quelle: "Design" + artefakt: "Service Design Document + Implementation Blueprint" + trigger: "Abschluss der Design-Phase (ds_04)" + ausgang: + - ziel: "Operation" + artefakt: "Aktivierter Service" + trigger: "SOR-Freigabe an Gate 3 (tr_12)" + - ziel: "Support" + artefakt: "Aktivierter Service mit Support-Dokumentation" + trigger: "SOR-Freigabe an Gate 3 (tr_12)" + + hinweis: > + Die Transition-Phase enthält drei Gates: Gate 1 (tr_01) als Entry-Gate, + Gate 2 (tr_09) prüft die Übergabefähigkeit nach dem Build, Gate 3 (tr_12) + gibt den Go-Live frei. Early Life Support (ELS) wurde in die Operation-Phase + verschoben. + +# ============================================================================= +# GATE 1: ENTRY-GATE (TRANSITION ENTRY) +# ============================================================================= + +aktivitaeten: + + # --------------------------------------------------------------------------- + - id: tr_01 + name: "Gate 1: Entwicklung oder Konfiguration?" + typ: gate + gate_nummer: 1 + yasm_referenz: "LP3 Entry Gate" + ehemals: "ds_05" + + beschreibung: > + Entscheidung, ob die Service-Komponenten entwickelt oder nur + konfiguriert werden müssen. Dies ist Gate 1 im Service-Lifecycle: + das Entry-Gate der Transition-Phase. + + WICHTIG: Diese Entscheidung erfordert SOR-Approval, da sie Budget- + und Ressourcenimplikationen hat. + + umfasst: + - "Aufwandsschätzung (Build vs. Configure)" + - "Bewertung technischer Risiken" + - "Budget-Abgleich" + - "ggf. Lieferanten-Einbindung (Beschaffung)" + - "SOR-Vorlage für Gate-Freigabe" + + entscheidungspfade: + - id: entwicklung + name: "Entwicklung" + beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich" + folgeaktivitaet: tr_02 + governance: "SOR-Approval erforderlich" + + - id: konfiguration + name: "Konfiguration" + beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst" + folgeaktivitaet: tr_05 + governance: "SOR-Approval erforderlich" + hinweis: "Überspringt Entwicklungsaktivitäten (tr_02-tr_04), startet direkt bei Konfiguration" + + mitarbeit: + - rolle: sor + raci: A + kontext: "Freigabe-Entscheidung für Eintritt in Transition" + - rolle: service_owner + raci: R + kontext: "Antragsteller und fachliche Empfehlung" + - rolle: projektleitung + raci: R + kontext: "Aufwandsschätzung und Ressourcenplanung" + - rolle: architektur + raci: R + kontext: "Technische Bewertung" + - rolle: spm + raci: C + kontext: "Portfolio-Perspektive" + - rolle: lieferant + raci: I + kontext: "Information für Beschaffungsplanung" + + pruef_dimensionen: + - id: g1_dim_01 + name: "Design-Vollständigkeit" + beschreibung: "Ist das Service Design Document vollständig und schlüssig?" + showstopper: true + + - id: g1_dim_02 + name: "Budget-Verfügbarkeit" + beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?" + showstopper: true + + - id: g1_dim_03 + name: "Projektressourcen" + beschreibung: "Können Ressourcen (intern/extern) für die Transition mobilisiert werden?" + showstopper: true + + - id: g1_dim_04 + name: "Betriebs- und Support-Bereitschaft" + beschreibung: > + Haben Betrieb und Support grundsätzlich die Kapazität und Bereitschaft, + diesen Service nach Abschluss der Transition zu übernehmen? + + WICHTIG: Dies ist eine prinzipielle Prüfung VOR Beginn der Transition. + Ohne grundsätzliches Commitment darf die Transition nicht starten, + da sonst Ressourcen für einen Service aufgewendet werden, der nicht + betrieben werden kann. + + Die operative Bestätigung (konkreter Termin, Personal eingeplant) + erfolgt an Gate 3. + showstopper: true + werte: + - "bestaetigt" + - "unter_vorbehalt" + - "nicht_gegeben" + hinweis: "Bei 'nicht_gegeben' ist Gate 1 nicht passierbar." + + - id: g1_dim_05 + name: "Risikobewertung" + beschreibung: "Sind Risiken identifiziert und bewertet?" + showstopper: false + + governance_hinweis: > + Die SOR-Freigabe an Gate 1 stellt sicher, dass: + 1. Das Design vollständig und schlüssig ist + 2. Budget für die gewählte Implementierungsstrategie verfügbar ist + 3. Ressourcen (intern/extern) für Transition mobilisiert werden können + 4. Betrieb und Support grundsätzlich zur Übernahme bereit sind + 5. Risiken identifiziert und bewertet sind + +# ============================================================================= +# AKTIVITÄTEN – BUILD (ehemals Service Entwicklung) +# ============================================================================= + + # --------------------------------------------------------------------------- + - id: tr_02 + name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten" + typ: aktivitaet + yasm_referenz: "LP3.1: Coordinate build and acquisition activities" + ehemals: "se_01 / tr_01" + + beschreibung: > + Steuern der Entwicklungsaktivitäten im Projekt. + + umfasst: + - "Abstimmung mit Lieferanten" + - "Ressourcenplanung" + - "Termin- und Budgetnachführung" + - "Sicherstellung von Change-Kontrollen" + - "Definition von Build- und Konfigurationspaketen" + + mitarbeit: + - rolle: projektleitung + raci: A + - rolle: architektur + raci: C + - rolle: service_owner + raci: I + - rolle: lieferant + raci: C/I + + # --------------------------------------------------------------------------- + - id: tr_03 + name: "Entwickeln von Anwendungen und Systemen" + typ: aktivitaet + yasm_referenz: "LP3.2: Develop applications and systems" + ehemals: "se_02 / tr_02" + + beschreibung: > + Realisierung der technischen Service-Komponenten. + + umfasst: + - "Softwareentwicklung" + - "Customizing" + - "Schnittstellenentwicklung" + - "Infrastrukturaufbau" + - "Versionierung & Dokumentation" + - "Testdaten & Migrationspfade vorbereiten" + + mitarbeit: + - rolle: projektteam + raci: R + kontext: "Interne Entwicklung" + - rolle: lieferant + raci: R + kontext: "Externe Entwicklung" + - rolle: projektleitung + raci: A + - rolle: service_owner + raci: C + - rolle: architektur + raci: C + + # --------------------------------------------------------------------------- + - id: tr_04 + name: "Entgegennehmen der Service-Komponenten" + typ: aktivitaet + yasm_referenz: "LP3.3: Accept service components" + ehemals: "se_03 / tr_03" + + beschreibung: > + Qualitätssicherung beim Übergang vom Entwicklungs- zur Testphase. + + umfasst: + - "Eingangskontrolle" + - "Prüfung von Vollständigkeit / Qualität" + - "Sicherstellung der Dokumentationen" + - "Übergabe an Testmanagement" + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: projektleitung + raci: R + - rolle: testmanagement + raci: R + - rolle: lieferant + raci: C + + # --------------------------------------------------------------------------- + - id: tr_05 + name: "Konfiguration der Service-Komponenten" + typ: aktivitaet + yasm_referenz: "LP3.4: Configure service components" + ehemals: "se_04 / tr_04" + + beschreibung: > + Einrichtung der Konfigurationsparameter, Settings, Rollen, Zugänge. + + umfasst: + - "Setup von Parametern, Policies, Templates" + - "Toolkonfiguration (ITSM-Systeme, Monitoring)" + - "Anpassung bestehender Komponenten" + - "Verknüpfung mit Service-Katalog / Portfolio" + + mitarbeit: + - rolle: projektteam + raci: R + - rolle: service_owner + raci: A + - rolle: betriebsteam + raci: C + - rolle: service_support_team + raci: C + + hinweis: > + Diese Aktivität wird bei Gate-1-Entscheidung "Konfiguration" + als Einstiegspunkt verwendet (überspringt tr_02-tr_04). + + # --------------------------------------------------------------------------- + - id: tr_06 + name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation" + typ: aktivitaet + yasm_referenz: "LP3.5: Document the services" + ehemals: "se_05 / tr_05" + + beschreibung: > + Alle Betriebsunterlagen werden erstellt oder aktualisiert. + + umfasst: + - "Service Operation Manual" + - "Supportanleitungen" + - "Monitoring-Spezifikationen" + - "Eskalationswege" + - "Standard Changes" + - "Konfigurations-/Betriebsrichtlinien" + + mitarbeit: + - rolle: service_owner + raci: A + - rolle: projektteam + raci: R + - rolle: betriebsteam + raci: C + - rolle: service_support_team + raci: C + + # --------------------------------------------------------------------------- + - id: tr_07 + name: "Testen der Service-Komponenten" + typ: aktivitaet + yasm_referenz: "LP3.6: Test the services" + ehemals: "se_06 / tr_06" + + beschreibung: > + Verifizierung, dass alle Servicekomponenten funktionsfähig und + bereit für den Betrieb sind. + + umfasst: + - "Funktionstests" + - "Integrationstests" + - "Abnahmetests" + - "Nachweis der Betriebsreife" + - "Testprotokolle & Freigaben" + + mitarbeit: + - rolle: testmanagement + raci: R + - rolle: projektleitung + raci: A + - rolle: service_owner + raci: C + - rolle: lieferant + raci: C/I + + # --------------------------------------------------------------------------- + - id: tr_08 + name: "Formale Übergabe (Build abgeschlossen)" + typ: aktivitaet + yasm_referenz: "LP3.7: Prepare for service activation" + ehemals: "se_07 / tr_07" + + beschreibung: > + Der Build ist abgeschlossen. Alle Artefakte werden für die + Entry-Prüfung (Gate 2) bereitgestellt. + + umfasst: + - "Bereitstellung aller Betriebsunterlagen" + - "Bereitstellung der Testprotokolle" + - "Dokumentierter Übergabe-Termin" + - "Vorbereitung Gate-2-Antrag" + + mitarbeit: + - rolle: projektleitung + raci: A + - rolle: service_owner + raci: R + kontext: "Fachliche Freigabe" + - rolle: spm + raci: I + kontext: "Für Portfolio-Aktualisierung" + - rolle: betriebsteam + raci: C + kontext: "Übernahmebereitschaft prüfen" + - rolle: service_support_team + raci: C + kontext: "Support-Bereitschaft prüfen" + +# ============================================================================= +# GATE 2: ENTRY-PRÜFUNG +# ============================================================================= + + # --------------------------------------------------------------------------- + - id: tr_09 + name: "Gate 2: Entry-Prüfung nach Build" + typ: gate + gate_nummer: 2 + ehemals: "tr_08" + + beschreibung: > + Validierung der Übergabefähigkeit nach Abschluss des Builds. + Der Service Owner prüft, ob alle Voraussetzungen für die + Deploy-Aktivitäten erfüllt sind. + + Dies ist eine SO-Einzelentscheidung (keine Gremienentscheidung). + + umfasst: + - "Prüfung der Übergabe-Vollständigkeit (alle Artefakte vorhanden)" + - "Prüfung des Abnahme-Status (Auftraggeber-Abnahme liegt vor)" + - "Ressourcen-Outlook (Betrieb und Support prinzipiell vorbereitet)" + - "Pilot-Entscheidung (falls erforderlich)" + - "Dokumentation im Transition-Steckbrief" + + entscheidungspfade: + - id: freigabe + name: "Freigabe" + beschreibung: "Weiter zu Deploy-Aktivitäten" + folgeaktivitaet: tr_10 + + - id: freigabe_mit_auflagen + name: "Freigabe mit Auflagen" + beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden" + folgeaktivitaet: tr_10 + + - id: zurueck + name: "Zurück an Build" + beschreibung: "Nachbesserung erforderlich" + folgeaktivitaet: tr_02 + hinweis: "Je nach Mängelart kann auch bei tr_05-tr_07 eingestiegen werden" + + - id: ablehnung + name: "Ablehnung" + beschreibung: "Endgültige Ablehnung des Service-Vorhabens" + folgeaktivitaet: null + hinweis: "Erfordert SOR-Eskalation" + + mitarbeit: + - rolle: service_owner + raci: A + kontext: "Gate-Keeper" + - rolle: projektleitung + raci: R + kontext: "Liefert Übergabe-Nachweis" + - rolle: betriebsteam + raci: C + kontext: "Bestätigt Übernahmebereitschaft" + - rolle: service_support_team + raci: C + kontext: "Bestätigt Support-Bereitschaft" + - rolle: spm + raci: I + kontext: "Bei Eskalation: Beratung" + + governance_hinweis: > + Gate 2 ist eine operative Entscheidung des Service Owners. + Bei Unklarheit kann der SO das SPM zur Beratung hinzuziehen. + Ablehnung erfordert SOR-Eskalation. + +# ============================================================================= +# AKTIVITÄTEN – DEPLOY (ehemals Service Transition) +# ============================================================================= + + # --------------------------------------------------------------------------- + - id: tr_10 + name: "Ausrollen der Service-Komponenten" + typ: aktivitaet + ehemals: "st_02 / tr_09" + + beschreibung: > + Technische Bereitstellung/Deployment des Services in die produktive Umgebung. + + umfasst: + - "Deployment von Anwendungen, Systemen, Komponenten" + - "Konfiguration produktiver Systeme" + - "Migration von Daten" + - "Aktivierung von Monitoring" + - "Sicherstellen von Zugängen, Rollen, Berechtigungen" + - "Schnittstellen-Integration" + - "Technische Abnahmetests" + + mitarbeit: + - rolle: betriebsteam + raci: R + - rolle: service_owner + raci: A + - rolle: spm + raci: C + - rolle: lieferant + raci: C/I + + # --------------------------------------------------------------------------- + - id: tr_11 + name: "Vorbereiten der Service-Aktivierung" + typ: aktivitaet + ehemals: "st_03 / tr_10" + + beschreibung: > + Prüfung der Betriebsbereitschaft und Vorbereitung des Go-Live-Antrags + für Gate 3. + + umfasst: + - "Review der Betriebsdokumentation" + - "Prüfung der Überwachungsregeln" + - "Prüfung der Rollen- und Eskalationswege" + - "Sicherstellen von Zugriffen & Toolanbindung" + - "Vorbereitung der Go-Live-Kommunikation" + - "Validierung der Service-Funktionalität mit Supportteams" + - "Vorbereitung Gate-3-Antrag (SOR-Vorlage)" + + mitarbeit: + - rolle: betriebsteam + raci: R + - rolle: service_owner + raci: A + kontext: "Fachliche Freigabe" + - rolle: spm + raci: C + +# ============================================================================= +# GATE 3: GO-LIVE-FREIGABE +# ============================================================================= + + # --------------------------------------------------------------------------- + - id: tr_12 + name: "Gate 3: Go-Live-Freigabe" + typ: gate + gate_nummer: 3 + ehemals: "st_01 / tr_11" + + beschreibung: > + Portfolio-Freigabe und formale Aktivierung des Services. + Die SOR prüft die Betriebsreife aus Portfolio-Perspektive und + beschließt die Aufnahme ins Service-Portfolio. + + Dies ist das Exit-Gate aus der Transition-Phase. + + umfasst: + - "Prüfung der Portfolio-Konsistenz (strategische Ausrichtung)" + - "Prüfung der Betriebsreife (SO-Bestätigung)" + - "Prüfung der Support-Bereitschaft" + - "Prüfung der SLA/SLO-Vereinbarung" + - "Prüfung der Auflagen-Erfüllung aus Gate 2" + - "Bewertung der Geschäftskritikalität" + - "Beschluss: Go-Live / Go-Live mit Auflagen / Zurück / Ablehnung" + - "Formale Aufnahme ins Service-Portfolio" + + entscheidungspfade: + - id: go_live + name: "Go-Live" + beschreibung: "Service wird aktiviert, Übergang zu Operation" + folgeaktivitaet: op_01 + folge_phase: "Operation" + + - id: go_live_mit_auflagen + name: "Go-Live mit Auflagen" + beschreibung: "Service wird aktiviert, definierte Punkte müssen nachgearbeitet werden" + folgeaktivitaet: op_01 + folge_phase: "Operation" + + - id: zurueck + name: "Zurück an Transition" + beschreibung: "Nachbesserung erforderlich" + folgeaktivitaet: tr_10 + hinweis: "Je nach Mängelart kann auch bei tr_09 eingestiegen werden" + + - id: ablehnung + name: "Ablehnung" + beschreibung: "Endgültige Ablehnung des Service-Vorhabens" + folgeaktivitaet: null + + mitarbeit: + - rolle: sor + raci: A + kontext: "Endgültiger Beschluss (Konsent-Verfahren)" + - rolle: service_owner + raci: R + kontext: "Antragsteller" + - rolle: spm + raci: C + kontext: "Portfolio-Perspektive" + - rolle: projektleitung + raci: C + - rolle: operations_manager + raci: C + - rolle: support_manager + raci: C + + governance_hinweis: > + Gate 3 ist eine SOR-Entscheidung nach dem Konsent-Prinzip. + Die SOR-Freigabe bewirkt gleichzeitig: + 1. Aufnahme ins Service-Portfolio + 2. Aktivierung des Katalog-Eintrags + 3. Formale Bestätigung des Service Owners diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml index 5d9855f..1e6c7b5 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml @@ -1,407 +1,407 @@ -metadata: - name: "Rollendefinitionen Service-Lifecycle" - version: "1.1" - status: "draft" - erstellt: "2025-11-26" - aktualisiert: "2026-01-31" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - beschreibung: > - Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden. - Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen. - - aenderungshistorie: - - version: "1.1" - datum: "2026-01-31" - aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen" - governance_referenz: "GOV-SOR-005" - begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten" - -# ============================================================================= -# RACI-Legende (für Referenz in Prozess-YAMLs) -# ============================================================================= -raci_legende: - R: "Responsible – führt die Aktivität operativ aus" - A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)" - C: "Consulted – wird vor Entscheidung/Durchführung einbezogen" - I: "Informed – wird über Ergebnis informiert" - -# ============================================================================= -# ROLLENKATEGORIEN -# ============================================================================= - -rollen: - - # --------------------------------------------------------------------------- - # GOVERNANCE & STRATEGISCHE STEUERUNG - # --------------------------------------------------------------------------- - governance: - - - id: spm - name: "Service-Portfolio-Manager" - kurzbezeichnung: "SPM" - typ: "Einzelrolle" - beschreibung: > - Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme, - Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung, - Priorisierung und Wirtschaftlichkeit. - verantwortlichkeiten: - - "Strategische Portfolio-Steuerung" - - "Entscheidungen zu Service-Aufnahme und -Stilllegung" - - "Sicherstellung der Wirtschaftlichkeit" - - "Portfolio-Konsistenz und Standards" - - "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)" - - "Identifikation portfolio-uebergreifender Muster aus Reviews" - - "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)" - - "Vollstaendigkeitspruefung der SOR-Vorlagen" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - "Service Review" - - - id: sor - name: "Service Operations Runde" - kurzbezeichnung: "SOR" - typ: "Gremium" - beschreibung: > - Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche - Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken - und organisatorische Abstimmung. - verantwortlichkeiten: - - "Freigabe von Service-Aktivierungen" - - "Bewertung der Betriebsreife" - - "Entscheidung über wesentliche Anpassungen" - - "Risikobewertung und organisatorische Abstimmung" - lifecycle_relevanz: - - "Service Transition" - - "Service Review" - - - id: service_owner - name: "Service Owner" - kurzbezeichnung: "SO" - typ: "Einzelrolle" - beschreibung: > - Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert - Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer - Service-Inhalt und -Wert. - verantwortlichkeiten: - - "End-to-End-Verantwortung fuer den Service" - - "Definition von Anforderungen und Qualitaetszielen" - - "Steuerung der Weiterentwicklung" - - "Fachliche Freigaben und Priorisierungen" - - "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002" - - "Improvement-Tracking in der Service-Definition (GOV-SR-005)" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - "Service Betrieb" - - "Service Support" - - "Service Review" - - # --------------------------------------------------------------------------- - # MANAGEMENT-ROLLEN (Operative Führung) - # --------------------------------------------------------------------------- - management: - - - id: al_basis_cloud - name: "Abteilungsleitung Basis & Cloud" - kurzbezeichnung: "AL B&C" - typ: "Einzelrolle" - beschreibung: > - Verantwortet den stabilen, sicheren und effizienten Betrieb der - Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert - die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung - von SLAs und Policies sicher. Ständiges Mitglied der SOR. - verantwortlichkeiten: - - "Gesamtverantwortung für Infrastruktur-Betrieb" - - "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)" - - "SLA- und Policy-Einhaltung im Infrastrukturbereich" - - "Ressourcenplanung und -priorisierung" - - "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR" - themengruppen: - - "Netzwerk" - - "Cloud" - - "Deployment" - - "Infrastruktur-Betrieb" - lifecycle_relevanz: - - "Service Transition" - - "Service Betrieb" - gremien: - - gremium: "SOR" - funktion: "ständiges Mitglied" - stimmberechtigt: true - governance_referenz: "GOV-SOR-005" - - - id: al_applikationen - name: "Abteilungsleitung Applikationen" - kurzbezeichnung: "AL App" - typ: "Einzelrolle" - beschreibung: > - Verantwortet den stabilen, sicheren und effizienten Betrieb der - Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen). - Koordiniert die Betriebsteams im Anwendungsbereich und stellt die - Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR. - verantwortlichkeiten: - - "Gesamtverantwortung für Anwendungs-Betrieb" - - "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)" - - "SLA- und Policy-Einhaltung im Anwendungsbereich" - - "Ressourcenplanung und -priorisierung" - - "Betriebsreife-Bewertung für Anwendungs-Services in der SOR" - themengruppen: - - "SAP" - - "Ennaio" - - "Fachverfahren" - - "Anwendungs-Betrieb" - lifecycle_relevanz: - - "Service Transition" - - "Service Betrieb" - gremien: - - gremium: "SOR" - funktion: "ständiges Mitglied" - stimmberechtigt: true - governance_referenz: "GOV-SOR-005" - - - id: support_manager - name: "Support Manager" - kurzbezeichnung: "Sup Mgr" - typ: "Einzelrolle" - beschreibung: > - Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level). - Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes - Incident/Request-Handling. - verantwortlichkeiten: - - "Organisation des Service-Supports" - - "Qualitätssicherung im Support" - - "Prozess- und Leitlinienentwicklung" - - "Wissensmanagement" - lifecycle_relevanz: - - "Service Transition" - - "Service Support" - - - id: problem_manager - name: "Problem Manager" - kurzbezeichnung: "Prob Mgr" - typ: "Einzelrolle" - beschreibung: > - Identifiziert wiederkehrende oder strukturelle Störungen, führt - Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für - dauerhafte Fehlerbehebung und Workarounds. - verantwortlichkeiten: - - "Identifikation struktureller Störungen" - - "Durchführung von Root-Cause-Analysen" - - "Steuerung von Problemlösungen" - - "Bereitstellung von Workarounds" - lifecycle_relevanz: - - "Service Support" - - "Service Review" - - - id: projektleitung - name: "Projektleitung" - kurzbezeichnung: "PL" - typ: "Einzelrolle" - beschreibung: > - Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen, - Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und - qualitätsgesicherte Lieferung der Projektartefakte. - verantwortlichkeiten: - - "Planung und Steuerung von Entwicklungsprojekten" - - "Ressourcen- und Lieferantenkoordination" - - "Termin- und Qualitätssicherung" - - "Lieferung der Projektartefakte" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - # --------------------------------------------------------------------------- - # TEAMS (Kollektive Rollen) - # --------------------------------------------------------------------------- - teams: - - - id: betriebsteam - name: "Betriebsteam" - kurzbezeichnung: "Betrieb" - typ: "Team" - beschreibung: > - Führt alle laufenden Betriebsaktivitäten für den Service aus - von - anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung. - Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und - tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität - des Betriebs. - verantwortlichkeiten: - - "Durchführung laufender Betriebsaufgaben" - - "Monitoring und Überwachung" - - "Ausführung von Standard-Changes" - - "Deployment und Rollout von Komponenten" - - "Betreuung technischer Infrastruktur" - - "Tiefgehende Diagnosen und Fehleranalyse" - - "Systempflege und -wartung" - - "Sicherstellung von Stabilität und Verfügbarkeit" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - "Service Betrieb" - - - id: service_support_team - name: "Service-Support Team" - kurzbezeichnung: "Support" - typ: "Team" - beschreibung: > - Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle - Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen - Anwendern, Betrieb und Problemmanagement. - verantwortlichkeiten: - - "Bearbeitung von Nutzeranfragen" - - "Incident-Bearbeitung (1st/2nd Level)" - - "Schnelle Wiederherstellung" - - "Schnittstelle zu Betrieb und Problemmanagement" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Support" - - - id: projektteam - name: "Projektteam" - kurzbezeichnung: "Projekt" - typ: "Team" - beschreibung: > - Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und - Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe - und Betriebsbefähigung. - verantwortlichkeiten: - - "Entwicklung und Konfiguration" - - "Testdurchführung" - - "Dokumentation" - - "Unterstützung bei Übergabe und Betriebsbefähigung" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - # --------------------------------------------------------------------------- - # INDIVIDUELLE OPERATIVE ROLLEN - # --------------------------------------------------------------------------- - operative_rollen: - - - id: queue_koordinator - name: "Queue Koordinator" - kurzbezeichnung: "Queue Koord" - typ: "Einzelrolle" - beschreibung: > - Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen - und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und - effizienten Ticketfluss sicher. - verantwortlichkeiten: - - "Überwachung des Ticketaufkommens" - - "Ticketverteilung und Routing" - - "Priorisierung und SLA-Überwachung" - - "Sicherstellung des Ticketflusses" - lifecycle_relevanz: - - "Service Support" - - - id: first_level_agent - name: "1st Level Agent" - kurzbezeichnung: "L1" - typ: "Einzelrolle" - beschreibung: > - Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst - Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den - 2nd Level bei Bedarf. - verantwortlichkeiten: - - "Entgegennahme von Incidents und Requests" - - "Lösung von Standardfällen" - - "Saubere Dokumentation" - - "Fachgerechte Eskalation" - lifecycle_relevanz: - - "Service Support" - - - id: second_level_agent - name: "2nd Level Agent" - kurzbezeichnung: "L2" - typ: "Einzelrolle" - beschreibung: > - Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere - Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb, - Herstellern und Problemmanagement. - verantwortlichkeiten: - - "Bearbeitung komplexer Störungen" - - "Tiefere Analysen und Diagnosen" - - "Lösungsbereitstellung" - - "Kooperation mit Betrieb und Herstellern" - lifecycle_relevanz: - - "Service Support" - - - id: testmanagement - name: "Testmanagement" - kurzbezeichnung: "Test Mgmt" - typ: "Einzelrolle" - beschreibung: > - Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression) - während Service-Entwicklung und Transition. Sichert die Qualität und - Betriebsreife neuer Service-Komponenten. - verantwortlichkeiten: - - "Testplanung und -organisation" - - "Verantwortung für Testdurchführung" - - "Qualitätssicherung neuer Komponenten" - - "Nachweis der Betriebsreife" - lifecycle_relevanz: - - "Service Entwicklung" - - - id: architektur - name: "Architektur" - kurzbezeichnung: "Arch" - typ: "Einzelrolle" - beschreibung: > - Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen; - bewertet Designvarianten und Risiken. Sichert technische Konsistenz und - Zukunftsfähigkeit des Service. - verantwortlichkeiten: - - "Definition technischer Standards" - - "Entwicklung von Zielarchitekturen" - - "Bewertung von Designvarianten und Risiken" - - "Sicherstellung technischer Konsistenz" - lifecycle_relevanz: - - "Service Entwicklung" - - # --------------------------------------------------------------------------- - # EXTERNE ROLLEN - # --------------------------------------------------------------------------- - externe: - - - id: lieferant - name: "Lieferant / Hersteller / Entwickler" - kurzbezeichnung: "Lieferant" - typ: "Externe Rolle" - beschreibung: > - Stellt externe System-, Software- oder Infrastrukturkomponenten bereit - oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse - und Komponentensupport eingebunden. - verantwortlichkeiten: - - "Bereitstellung externer Komponenten" - - "Entwicklung spezifischer Anpassungen" - - "Unterstützung bei Fehleranalyse" - - "Komponentensupport" - lifecycle_relevanz: - - "Service Entwicklung" - - "Service Transition" - - "Service Support" - -# ============================================================================= -# ROLLEN-MAPPING (für schnelle Referenz) -# ============================================================================= -rollen_index: - # Kurzreferenz: id -> name - spm: "Service-Portfolio-Manager" - sor: "Service Operations Runde" - service_owner: "Service Owner" - al_basis_cloud: "Abteilungsleitung Basis & Cloud" - al_applikationen: "Abteilungsleitung Applikationen" - support_manager: "Support Manager" - problem_manager: "Problem Manager" - projektleitung: "Projektleitung" - betriebsteam: "Betriebsteam" - service_support_team: "Service-Support Team" - projektteam: "Projektteam" - queue_koordinator: "Queue Koordinator" - first_level_agent: "1st Level Agent" - second_level_agent: "2nd Level Agent" - testmanagement: "Testmanagement" - architektur: "Architektur" +metadata: + name: "Rollendefinitionen Service-Lifecycle" + version: "1.1" + status: "draft" + erstellt: "2025-11-26" + aktualisiert: "2026-01-31" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + beschreibung: > + Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden. + Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen. + + aenderungshistorie: + - version: "1.1" + datum: "2026-01-31" + aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen" + governance_referenz: "GOV-SOR-005" + begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten" + +# ============================================================================= +# RACI-Legende (für Referenz in Prozess-YAMLs) +# ============================================================================= +raci_legende: + R: "Responsible – führt die Aktivität operativ aus" + A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)" + C: "Consulted – wird vor Entscheidung/Durchführung einbezogen" + I: "Informed – wird über Ergebnis informiert" + +# ============================================================================= +# ROLLENKATEGORIEN +# ============================================================================= + +rollen: + + # --------------------------------------------------------------------------- + # GOVERNANCE & STRATEGISCHE STEUERUNG + # --------------------------------------------------------------------------- + governance: + + - id: spm + name: "Service-Portfolio-Manager" + kurzbezeichnung: "SPM" + typ: "Einzelrolle" + beschreibung: > + Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme, + Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung, + Priorisierung und Wirtschaftlichkeit. + verantwortlichkeiten: + - "Strategische Portfolio-Steuerung" + - "Entscheidungen zu Service-Aufnahme und -Stilllegung" + - "Sicherstellung der Wirtschaftlichkeit" + - "Portfolio-Konsistenz und Standards" + - "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)" + - "Identifikation portfolio-uebergreifender Muster aus Reviews" + - "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)" + - "Vollstaendigkeitspruefung der SOR-Vorlagen" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + - "Service Review" + + - id: sor + name: "Service Operations Runde" + kurzbezeichnung: "SOR" + typ: "Gremium" + beschreibung: > + Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche + Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken + und organisatorische Abstimmung. + verantwortlichkeiten: + - "Freigabe von Service-Aktivierungen" + - "Bewertung der Betriebsreife" + - "Entscheidung über wesentliche Anpassungen" + - "Risikobewertung und organisatorische Abstimmung" + lifecycle_relevanz: + - "Service Transition" + - "Service Review" + + - id: service_owner + name: "Service Owner" + kurzbezeichnung: "SO" + typ: "Einzelrolle" + beschreibung: > + Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert + Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer + Service-Inhalt und -Wert. + verantwortlichkeiten: + - "End-to-End-Verantwortung fuer den Service" + - "Definition von Anforderungen und Qualitaetszielen" + - "Steuerung der Weiterentwicklung" + - "Fachliche Freigaben und Priorisierungen" + - "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002" + - "Improvement-Tracking in der Service-Definition (GOV-SR-005)" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + - "Service Betrieb" + - "Service Support" + - "Service Review" + + # --------------------------------------------------------------------------- + # MANAGEMENT-ROLLEN (Operative Führung) + # --------------------------------------------------------------------------- + management: + + - id: al_basis_cloud + name: "Abteilungsleitung Basis & Cloud" + kurzbezeichnung: "AL B&C" + typ: "Einzelrolle" + beschreibung: > + Verantwortet den stabilen, sicheren und effizienten Betrieb der + Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert + die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung + von SLAs und Policies sicher. Ständiges Mitglied der SOR. + verantwortlichkeiten: + - "Gesamtverantwortung für Infrastruktur-Betrieb" + - "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)" + - "SLA- und Policy-Einhaltung im Infrastrukturbereich" + - "Ressourcenplanung und -priorisierung" + - "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR" + themengruppen: + - "Netzwerk" + - "Cloud" + - "Deployment" + - "Infrastruktur-Betrieb" + lifecycle_relevanz: + - "Service Transition" + - "Service Betrieb" + gremien: + - gremium: "SOR" + funktion: "ständiges Mitglied" + stimmberechtigt: true + governance_referenz: "GOV-SOR-005" + + - id: al_applikationen + name: "Abteilungsleitung Applikationen" + kurzbezeichnung: "AL App" + typ: "Einzelrolle" + beschreibung: > + Verantwortet den stabilen, sicheren und effizienten Betrieb der + Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen). + Koordiniert die Betriebsteams im Anwendungsbereich und stellt die + Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR. + verantwortlichkeiten: + - "Gesamtverantwortung für Anwendungs-Betrieb" + - "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)" + - "SLA- und Policy-Einhaltung im Anwendungsbereich" + - "Ressourcenplanung und -priorisierung" + - "Betriebsreife-Bewertung für Anwendungs-Services in der SOR" + themengruppen: + - "SAP" + - "Ennaio" + - "Fachverfahren" + - "Anwendungs-Betrieb" + lifecycle_relevanz: + - "Service Transition" + - "Service Betrieb" + gremien: + - gremium: "SOR" + funktion: "ständiges Mitglied" + stimmberechtigt: true + governance_referenz: "GOV-SOR-005" + + - id: support_manager + name: "Support Manager" + kurzbezeichnung: "Sup Mgr" + typ: "Einzelrolle" + beschreibung: > + Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level). + Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes + Incident/Request-Handling. + verantwortlichkeiten: + - "Organisation des Service-Supports" + - "Qualitätssicherung im Support" + - "Prozess- und Leitlinienentwicklung" + - "Wissensmanagement" + lifecycle_relevanz: + - "Service Transition" + - "Service Support" + + - id: problem_manager + name: "Problem Manager" + kurzbezeichnung: "Prob Mgr" + typ: "Einzelrolle" + beschreibung: > + Identifiziert wiederkehrende oder strukturelle Störungen, führt + Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für + dauerhafte Fehlerbehebung und Workarounds. + verantwortlichkeiten: + - "Identifikation struktureller Störungen" + - "Durchführung von Root-Cause-Analysen" + - "Steuerung von Problemlösungen" + - "Bereitstellung von Workarounds" + lifecycle_relevanz: + - "Service Support" + - "Service Review" + + - id: projektleitung + name: "Projektleitung" + kurzbezeichnung: "PL" + typ: "Einzelrolle" + beschreibung: > + Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen, + Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und + qualitätsgesicherte Lieferung der Projektartefakte. + verantwortlichkeiten: + - "Planung und Steuerung von Entwicklungsprojekten" + - "Ressourcen- und Lieferantenkoordination" + - "Termin- und Qualitätssicherung" + - "Lieferung der Projektartefakte" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + + # --------------------------------------------------------------------------- + # TEAMS (Kollektive Rollen) + # --------------------------------------------------------------------------- + teams: + + - id: betriebsteam + name: "Betriebsteam" + kurzbezeichnung: "Betrieb" + typ: "Team" + beschreibung: > + Führt alle laufenden Betriebsaktivitäten für den Service aus - von + anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung. + Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und + tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität + des Betriebs. + verantwortlichkeiten: + - "Durchführung laufender Betriebsaufgaben" + - "Monitoring und Überwachung" + - "Ausführung von Standard-Changes" + - "Deployment und Rollout von Komponenten" + - "Betreuung technischer Infrastruktur" + - "Tiefgehende Diagnosen und Fehleranalyse" + - "Systempflege und -wartung" + - "Sicherstellung von Stabilität und Verfügbarkeit" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + - "Service Betrieb" + + - id: service_support_team + name: "Service-Support Team" + kurzbezeichnung: "Support" + typ: "Team" + beschreibung: > + Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle + Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen + Anwendern, Betrieb und Problemmanagement. + verantwortlichkeiten: + - "Bearbeitung von Nutzeranfragen" + - "Incident-Bearbeitung (1st/2nd Level)" + - "Schnelle Wiederherstellung" + - "Schnittstelle zu Betrieb und Problemmanagement" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Support" + + - id: projektteam + name: "Projektteam" + kurzbezeichnung: "Projekt" + typ: "Team" + beschreibung: > + Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und + Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe + und Betriebsbefähigung. + verantwortlichkeiten: + - "Entwicklung und Konfiguration" + - "Testdurchführung" + - "Dokumentation" + - "Unterstützung bei Übergabe und Betriebsbefähigung" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + + # --------------------------------------------------------------------------- + # INDIVIDUELLE OPERATIVE ROLLEN + # --------------------------------------------------------------------------- + operative_rollen: + + - id: queue_koordinator + name: "Queue Koordinator" + kurzbezeichnung: "Queue Koord" + typ: "Einzelrolle" + beschreibung: > + Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen + und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und + effizienten Ticketfluss sicher. + verantwortlichkeiten: + - "Überwachung des Ticketaufkommens" + - "Ticketverteilung und Routing" + - "Priorisierung und SLA-Überwachung" + - "Sicherstellung des Ticketflusses" + lifecycle_relevanz: + - "Service Support" + + - id: first_level_agent + name: "1st Level Agent" + kurzbezeichnung: "L1" + typ: "Einzelrolle" + beschreibung: > + Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst + Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den + 2nd Level bei Bedarf. + verantwortlichkeiten: + - "Entgegennahme von Incidents und Requests" + - "Lösung von Standardfällen" + - "Saubere Dokumentation" + - "Fachgerechte Eskalation" + lifecycle_relevanz: + - "Service Support" + + - id: second_level_agent + name: "2nd Level Agent" + kurzbezeichnung: "L2" + typ: "Einzelrolle" + beschreibung: > + Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere + Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb, + Herstellern und Problemmanagement. + verantwortlichkeiten: + - "Bearbeitung komplexer Störungen" + - "Tiefere Analysen und Diagnosen" + - "Lösungsbereitstellung" + - "Kooperation mit Betrieb und Herstellern" + lifecycle_relevanz: + - "Service Support" + + - id: testmanagement + name: "Testmanagement" + kurzbezeichnung: "Test Mgmt" + typ: "Einzelrolle" + beschreibung: > + Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression) + während Service-Entwicklung und Transition. Sichert die Qualität und + Betriebsreife neuer Service-Komponenten. + verantwortlichkeiten: + - "Testplanung und -organisation" + - "Verantwortung für Testdurchführung" + - "Qualitätssicherung neuer Komponenten" + - "Nachweis der Betriebsreife" + lifecycle_relevanz: + - "Service Entwicklung" + + - id: architektur + name: "Architektur" + kurzbezeichnung: "Arch" + typ: "Einzelrolle" + beschreibung: > + Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen; + bewertet Designvarianten und Risiken. Sichert technische Konsistenz und + Zukunftsfähigkeit des Service. + verantwortlichkeiten: + - "Definition technischer Standards" + - "Entwicklung von Zielarchitekturen" + - "Bewertung von Designvarianten und Risiken" + - "Sicherstellung technischer Konsistenz" + lifecycle_relevanz: + - "Service Entwicklung" + + # --------------------------------------------------------------------------- + # EXTERNE ROLLEN + # --------------------------------------------------------------------------- + externe: + + - id: lieferant + name: "Lieferant / Hersteller / Entwickler" + kurzbezeichnung: "Lieferant" + typ: "Externe Rolle" + beschreibung: > + Stellt externe System-, Software- oder Infrastrukturkomponenten bereit + oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse + und Komponentensupport eingebunden. + verantwortlichkeiten: + - "Bereitstellung externer Komponenten" + - "Entwicklung spezifischer Anpassungen" + - "Unterstützung bei Fehleranalyse" + - "Komponentensupport" + lifecycle_relevanz: + - "Service Entwicklung" + - "Service Transition" + - "Service Support" + +# ============================================================================= +# ROLLEN-MAPPING (für schnelle Referenz) +# ============================================================================= +rollen_index: + # Kurzreferenz: id -> name + spm: "Service-Portfolio-Manager" + sor: "Service Operations Runde" + service_owner: "Service Owner" + al_basis_cloud: "Abteilungsleitung Basis & Cloud" + al_applikationen: "Abteilungsleitung Applikationen" + support_manager: "Support Manager" + problem_manager: "Problem Manager" + projektleitung: "Projektleitung" + betriebsteam: "Betriebsteam" + service_support_team: "Service-Support Team" + projektteam: "Projektteam" + queue_koordinator: "Queue Koordinator" + first_level_agent: "1st Level Agent" + second_level_agent: "2nd Level Agent" + testmanagement: "Testmanagement" + architektur: "Architektur" lieferant: "Lieferant / Hersteller / Entwickler" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-betrieb-light.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-betrieb-light.yaml index 54dc164..653c5fa 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-betrieb-light.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-betrieb-light.yaml @@ -1,104 +1,104 @@ -# ============================================================================= -# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT) -# ============================================================================= - -metadata: - id: "K-BL" - name: "Service-Betrieb Light-Weight Konzept" - version: "0.1" - status: "placeholder" - erstellt: "2025-12-15" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "konzept" - - beschreibung: > - Minimales Strukturkonzept für den Service-Betrieb. Definiert - Betriebsrollen und grundlegende Verantwortungsabgrenzungen, - um Anschlussfähigkeit an die operative Organisation herzustellen. - - scope_hinweis: > - BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine - vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase. - - referenzen: - blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml" - rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml" - -# ============================================================================= -# BEGRÜNDUNG -# ============================================================================= - -begruendung: - workshop_befund: > - Ohne minimale Strukturelemente für den Service-Betrieb fehlt die - Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft - muss sich im Modell wiederfinden, sonst keine Legitimation. - - systemtheoretisch: > - Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur, - die von der Organisation als "Management-Theater" abgekoppelt wird. - -# ============================================================================= -# GLIEDERUNG (zu entwickeln) -# ============================================================================= - -gliederung: - - - abschnitt: "Scope und Abgrenzung" - status: "ausstehend" - inhalte: - - "Was dieses Konzept ist (Strukturanker)" - - "Was dieses Konzept nicht ist (kein Betriebshandbuch)" - - "Verweis auf Blueprint für Aktivitäten" - - - abschnitt: "Betriebsrollen (Minimum)" - status: "ausstehend" - inhalte: - - "Operations Manager" - - "Betriebsteam" - - "Technical Lead (optional)" - referenz: "spm_rollen.yaml → management, operativ" - - - abschnitt: "Verantwortungsabgrenzung" - status: "ausstehend" - inhalte: - - "Service Owner vs. Operations Manager" - - "Betrieb vs. Support (Incident-Handling)" - - "Proaktiv vs. Reaktiv" - - - abschnitt: "Schnittstelle zu Support" - status: "ausstehend" - inhalte: - - "Eskalationswege bei Incidents" - - "Problem-Identifikation" - - "Wissenstransfer" - - - abschnitt: "Monitoring-Verantwortung" - status: "ausstehend" - inhalte: - - "Wer definiert Schwellwerte?" - - "Wer reagiert auf Alerts?" - - "Wer erstellt Qualitätsberichte?" - -# ============================================================================= -# EXPLIZITE NICHT-INHALTE -# ============================================================================= - -nicht_inhalte: - themen: - - "Detaillierte Betriebsprozesse" - - "Monitoring-Tool-Auswahl" - - "Kapazitätsplanung" - - "Change-Management im Betrieb" - hinweis: "Diese Themen werden in Phase X vertieft." - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-15" - aenderung: "Placeholder erstellt mit Gliederungsskelett" - autor: "DIGITOM-Projekt" +# ============================================================================= +# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT) +# ============================================================================= + +metadata: + id: "K-BL" + name: "Service-Betrieb Light-Weight Konzept" + version: "0.1" + status: "placeholder" + erstellt: "2025-12-15" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "konzept" + + beschreibung: > + Minimales Strukturkonzept für den Service-Betrieb. Definiert + Betriebsrollen und grundlegende Verantwortungsabgrenzungen, + um Anschlussfähigkeit an die operative Organisation herzustellen. + + scope_hinweis: > + BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine + vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase. + + referenzen: + blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml" + rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml" + +# ============================================================================= +# BEGRÜNDUNG +# ============================================================================= + +begruendung: + workshop_befund: > + Ohne minimale Strukturelemente für den Service-Betrieb fehlt die + Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft + muss sich im Modell wiederfinden, sonst keine Legitimation. + + systemtheoretisch: > + Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur, + die von der Organisation als "Management-Theater" abgekoppelt wird. + +# ============================================================================= +# GLIEDERUNG (zu entwickeln) +# ============================================================================= + +gliederung: + + - abschnitt: "Scope und Abgrenzung" + status: "ausstehend" + inhalte: + - "Was dieses Konzept ist (Strukturanker)" + - "Was dieses Konzept nicht ist (kein Betriebshandbuch)" + - "Verweis auf Blueprint für Aktivitäten" + + - abschnitt: "Betriebsrollen (Minimum)" + status: "ausstehend" + inhalte: + - "Operations Manager" + - "Betriebsteam" + - "Technical Lead (optional)" + referenz: "spm_rollen.yaml → management, operativ" + + - abschnitt: "Verantwortungsabgrenzung" + status: "ausstehend" + inhalte: + - "Service Owner vs. Operations Manager" + - "Betrieb vs. Support (Incident-Handling)" + - "Proaktiv vs. Reaktiv" + + - abschnitt: "Schnittstelle zu Support" + status: "ausstehend" + inhalte: + - "Eskalationswege bei Incidents" + - "Problem-Identifikation" + - "Wissenstransfer" + + - abschnitt: "Monitoring-Verantwortung" + status: "ausstehend" + inhalte: + - "Wer definiert Schwellwerte?" + - "Wer reagiert auf Alerts?" + - "Wer erstellt Qualitätsberichte?" + +# ============================================================================= +# EXPLIZITE NICHT-INHALTE +# ============================================================================= + +nicht_inhalte: + themen: + - "Detaillierte Betriebsprozesse" + - "Monitoring-Tool-Auswahl" + - "Kapazitätsplanung" + - "Change-Management im Betrieb" + hinweis: "Diese Themen werden in Phase X vertieft." + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-12-15" + aenderung: "Placeholder erstellt mit Gliederungsskelett" + autor: "DIGITOM-Projekt" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml index ddf16ef..e26832c 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml @@ -1,1080 +1,1080 @@ -# ============================================================================= -# KONZEPT: SERVICE-REVIEW (EINZELSERVICE) -# ============================================================================= - -metadata: - id: "K-SR" - name: "Konzept Service-Review" - version: "1.1" - status: "draft" - erstellt: "2025-12-17" - geaendert: "2026-01-31" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "konzept" - - beschreibung: > - Definiert die Governance-Logik, Bewertungsmethodik und Entscheidungsverfahren - für den periodischen Review eines einzelnen Services. Ergänzt den prozessualen - Rahmen aus dem Service-Lifecycle-Blueprint um konzeptionelle Klarheit. - - abgrenzung: - service_lifecycle_blueprint: > - Das Dokument "service-lifecycle_service-review.yaml" beschreibt den - prozessualen Rahmen (Aktivitäten sr_01 bis sr_06, RACI-Zuordnung). - Dieses Konzept definiert die dahinterliegende Governance-Logik. - - portfolio_review: > - Das "Service-Portfolio-Review" (G-PR) betrachtet das Gesamtportfolio - aus strategischer Perspektive. Dieses Konzept fokussiert auf den - einzelnen Service aus operativer Perspektive. - - referenzen: - blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-review.yaml" - portfolio_review: "01_governance/spm_portfolio-review-konzept.yaml" - sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" - service_definition: "06_Informationsmodell/spm_schema_service-definition.yaml" - shm_koordination: "#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml" - - governance_entscheidungen: - - "GOV-SR-001 bis GOV-SR-005 (in diesem Dokument definiert)" - -# ============================================================================= -# 1. ZWECK UND SCOPE -# ============================================================================= - -zweck_und_scope: - - zweck: | - Der Service-Review dient der systematischen Bewertung eines Services - im laufenden Betrieb. Er stellt sicher, dass: - - - Der Service seinen definierten Zweck erfüllt - - Probleme frühzeitig erkannt und adressiert werden - - Verbesserungspotenziale identifiziert werden - - Entscheidungen zu Improvement, Redesign oder Stilllegung fundiert getroffen werden - - scope: - in_scope: - - "Alle Services im Status 'Aktiv' im Service-Portfolio" - - "Services im Early Life Support (ELS) mit eingeschränktem Fokus" - - out_of_scope: - - "Services in Entwicklung oder Transition (andere Governance)" - - "Portfolio-übergreifende Betrachtung (→ Portfolio-Review)" - - "Externe SLA-Reviews mit Kunden (→ SLM-Practice)" - - ergebnis_des_reviews: - beschreibung: "Der Review mündet in eine Handlungsempfehlung" - optionen: - - id: "CONTINUE" - name: "Weiterbetrieb" - beschreibung: "Service stabil, keine Maßnahmen erforderlich" - - - id: "IMPROVEMENT" - name: "Verbesserung" - beschreibung: "Optimierungsbedarf identifiziert, im Rahmen des Service lösbar" - - - id: "REDESIGN" - name: "Neugestaltung" - beschreibung: "Strukturelle Änderung erforderlich, Übergabe an DPM" - - - id: "RETIRE" - name: "Stilllegung" - beschreibung: "Service soll außer Betrieb genommen werden" - -# ============================================================================= -# 2. BEWERTUNGSSCHEMA -# ============================================================================= - -bewertungsschema: - - governance_referenz: "GOV-SR-001" - - grundprinzip: | - Der Service Owner bewertet den Service anhand von vier Dimensionen - mit einer qualitativen Ampelbewertung. Die Bewertung ist urteilsbasiert, - nicht metrisch-automatisiert. Sie dient als strukturierte Entscheidungs- - grundlage für den SO selbst und ggf. für die SOR. - - methodik: "Qualitative Dimensionsbewertung mit Ampellogik" - - # --------------------------------------------------------------------------- - # BEWERTUNGSSKALA - # --------------------------------------------------------------------------- - - bewertungsskala: - - gruen: - label: "Stabil" - code: "G" - bedeutung: "Dimension erfüllt Erwartungen, kein Handlungsbedarf" - typische_indikatoren: - - "Ziele werden erreicht" - - "Keine wiederkehrenden Probleme" - - "Positives oder neutrales Feedback" - - gelb: - label: "Beobachten" - code: "Y" - bedeutung: "Auffälligkeiten erkennbar, Monitoring erforderlich" - typische_indikatoren: - - "Einzelne Abweichungen von Zielen" - - "Vereinzelte Beschwerden oder Probleme" - - "Trend-Verschlechterung erkennbar" - - rot: - label: "Handlungsbedarf" - code: "R" - bedeutung: "Systematische Probleme, Maßnahmen erforderlich" - typische_indikatoren: - - "Ziele werden wiederholt verfehlt" - - "Wiederkehrende oder eskalierende Probleme" - - "Deutliche Kritik von Nutzern oder Stakeholdern" - - # --------------------------------------------------------------------------- - # BEWERTUNGSDIMENSIONEN - # --------------------------------------------------------------------------- - - dimensionen: - - - id: "SR-D1" - name: "Leistungserbringung" - leitfrage: "Liefert der Service den erwarteten Nutzen?" - - beschreibung: | - Bewertet, ob der Service seinen definierten Zweck erfüllt und - die vereinbarten Leistungsziele erreicht. - - indikatoren: - - "Zielerreichung (falls SLOs/SLAs definiert)" - - "Verfügbarkeit und Performance im Nutzungskontext" - - "Funktionsumfang entspricht dokumentiertem Scope" - - "Nutzen wird von Stakeholdern wahrgenommen" - - datenquellen: - - "Monitoring-Daten (falls vorhanden)" - - "SLA-Berichte (falls vorhanden)" - - "Stakeholder-Feedback via SHM" - - - id: "SR-D2" - name: "Betriebsstabilität" - leitfrage: "Läuft der Service störungsarm und beherrschbar?" - - beschreibung: | - Bewertet die operative Stabilität und den Betriebsaufwand - aus Sicht des Betriebsteams. - - indikatoren: - - "Incident-Häufigkeit und -Schwere" - - "Wiederkehrende Probleme (Problem Records)" - - "Betriebsaufwand im Verhältnis zum Erwarteten" - - "Stabilität der technischen Komponenten" - - datenquellen: - - "Incident-Statistik aus ITSM-Tool" - - "Problem-Records" - - "Einschätzung des Betriebsteams" - - - id: "SR-D3" - name: "Nutzerzufriedenheit" - leitfrage: "Wie bewerten die Nutzer den Service?" - - beschreibung: | - Bewertet die Wahrnehmung des Services durch die Nutzer und - Stakeholder, unabhängig von technischen Metriken. - - indikatoren: - - "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)" - - "Beschwerden und Eskalationen" - - "VoC-Signale via SHM (falls vorhanden)" - - "Informelle Rückmeldungen" - - datenquellen: - - "Service-Desk-Feedback" - - "SHM-Erkenntnisse (VoC-Cluster D2)" - - "Direkte Nutzer-Rückmeldungen" - - - id: "SR-D4" - name: "Zukunftsfähigkeit" - leitfrage: "Ist der Service mittelfristig tragfähig?" - - beschreibung: | - Bewertet die mittelfristige Perspektive des Services hinsichtlich - Technologie, Strategie und Ressourcen. - - indikatoren: - - "Technische Schulden und Modernisierungsbedarf" - - "Abhängigkeiten und externe Risiken (Lieferanten, Technologie-EOL)" - - "Strategische Passung (Alignment mit DIGIT-Strategie)" - - "Ressourcenverfügbarkeit für Weiterentwicklung" - - datenquellen: - - "Technische Einschätzung des Betriebsteams" - - "IT-Architektur-Bewertung (falls vorhanden)" - - "Strategische Vorgaben" - - # --------------------------------------------------------------------------- - # AGGREGATIONSLOGIK - # --------------------------------------------------------------------------- - - aggregationslogik: - - grundsatz: | - Es gibt keine mathematische Aggregation zu einem Score. Der SO - betrachtet das Gesamtbild und leitet eine begründete Handlungs- - empfehlung ab. - - orientierung: - - konstellation: "Alle Dimensionen Grün" - typische_empfehlung: "CONTINUE" - - - konstellation: "Max. eine Dimension Gelb, Rest Grün" - typische_empfehlung: "CONTINUE mit Monitoring" - - - konstellation: "Eine oder mehrere Dimensionen Gelb" - typische_empfehlung: "CONTINUE oder IMPROVEMENT prüfen" - - - konstellation: "Eine Dimension Rot" - typische_empfehlung: "IMPROVEMENT" - - - konstellation: "Mehrere Dimensionen Rot" - typische_empfehlung: "IMPROVEMENT oder REDESIGN prüfen" - - - konstellation: "D4 (Zukunftsfähigkeit) Rot + strategische Gründe" - typische_empfehlung: "REDESIGN oder RETIRE prüfen" - - hinweis: | - Diese Orientierung ersetzt nicht das Urteil des SO. Abweichungen - sind möglich und erfordern eine kurze Begründung. - -# ============================================================================= -# 3. REVIEW-RHYTHMUS -# ============================================================================= - -review_rhythmus: - - governance_referenz: "GOV-SR-002" - - grundprinzip: | - Der Service-Review folgt einem Hybridmodell: Der SO führt eigenständig - einen quartalsweisen Selbst-Review durch. Die SOR wird nur bei - Auffälligkeiten oder Handlungsbedarf einbezogen. Der SPM erhält - regelmäßig alle Review-Berichte für die Portfolio-Perspektive. - - # --------------------------------------------------------------------------- - # REGELZYKLUS - # --------------------------------------------------------------------------- - - regelzyklus: - - frequenz: "Quartalsweise" - verantwortlich: "Service Owner" - - synchronisation: | - Der Service-Review sollte vor dem quartalsweisen DPM-Portfolio-Review - abgeschlossen sein, damit aggregierte Erkenntnisse einfließen können. - - Empfohlener Zeitpunkt: Erste zwei Wochen nach Quartalsende. - - ablauf: - - - schritt: 1 - was: "SO führt Bewertung durch" - beschreibung: "Bewertung der 4 Dimensionen anhand verfügbarer Daten und Einschätzungen" - dauer: "30-60 Minuten" - output: "Dimensionsbewertung (Ampel + Kurztext)" - - - schritt: 2 - was: "SO leitet Handlungsempfehlung ab" - beschreibung: "Gesamteinschätzung und Empfehlung (CONTINUE/IMPROVEMENT/REDESIGN/RETIRE)" - output: "Handlungsempfehlung mit Begründung" - - - schritt: 3 - was: "SO aktualisiert Service-Definition" - beschreibung: "Dokumentation des Review-Ergebnisses in der Service-Definition (Abschnitt 'service_review')" - output: "Aktualisierte Service-Definition mit Review-Status" - - - schritt: 4 - was: "SO informiert SPM" - beschreibung: "Review-Bericht wird an SPM übermittelt" - output: "SPM hat aktuellen Review-Status aller Services" - - - schritt: 5 - was: "SO prüft SOR-Einbeziehung" - beschreibung: "Entscheidung, ob SOR-Behandlung erforderlich ist" - output: "Ggf. Review-Vorlage für SOR" - - # --------------------------------------------------------------------------- - # SPM-INFORMATIONSPFLICHT - # --------------------------------------------------------------------------- - - spm_informationspflicht: - - grundsatz: | - Der SPM erhält regelmäßig alle Service-Review-Berichte, unabhängig - vom Ergebnis. Dies ermöglicht die Portfolio-Perspektive und die - Vorbereitung des Portfolio-Reviews. - - was: "Review-Ergebnis je Service (Dimensionsbewertung + Empfehlung)" - wann: "Nach Abschluss des Quartals-Reviews" - wie: "Aktualisierte Service-Definition oder konsolidierte Übersicht" - - spm_nutzung: - - "Aggregation für Portfolio-Review" - - "Identifikation portfolio-übergreifender Muster" - - "Früherkennung von Ressourcenkonflikten bei Improvement-Vorhaben" - - # --------------------------------------------------------------------------- - # SOR-EINBEZIEHUNG - # --------------------------------------------------------------------------- - - sor_einbeziehung: - - grundsatz: | - Die SOR wird nur einbezogen, wenn der Review zu Handlungsbedarf führt, - der über die SO-Kompetenz hinausgeht oder Governance-Entscheidungen erfordert. - - trigger: - - "Mindestens eine Dimension 'Rot'" - - "Handlungsempfehlung: IMPROVEMENT mit Ressourcenbedarf" - - "Handlungsempfehlung: REDESIGN oder RETIRE" - - "SO ist unsicher über angemessene Reaktion" - - verfahren: "SO reicht Review-Vorlage für nächste SOR-Sitzung ein" - - keine_sor_behandlung_bei: - - "Alle Dimensionen Grün oder Gelb UND Empfehlung CONTINUE" - - "IMPROVEMENT ohne zusätzlichen Ressourcenbedarf (SO-geführt)" - - # --------------------------------------------------------------------------- - # ANLASSBEZOGENER REVIEW - # --------------------------------------------------------------------------- - - anlassbezogener_review: - - grundsatz: | - Außerhalb des Regelzyklus kann ein Ad-hoc-Review erforderlich sein, - wenn kritische Ereignisse eintreten. - - trigger: - - "Major Incident mit service-weiten Auswirkungen" - - "Wiederholte SLA-Verletzung (3+ in Folge)" - - "Stakeholder-Eskalation an SOR oder Mission Board" - - "Sicherheitsvorfall mit Service-Bezug" - - verfahren: | - SO führt Ad-hoc-Review durch (kann verkürzt sein, Fokus auf - betroffene Dimension). Bei Handlungsbedarf → SOR-Behandlung. - - dokumentation: "In der Service-Definition als 'Ad-hoc-Review' markieren" - -# ============================================================================= -# 4. ENTSCHEIDUNGSPFADE UND ESKALATIONSKRITERIEN -# ============================================================================= - -entscheidungspfade: - - governance_referenz: "GOV-SR-003" - - grundprinzip: | - Die Kriterien für jeden Entscheidungspfad sind Orientierungshilfen, - keine Automatismen. Der SO trifft die Entscheidung unter Berücksichtigung - des Gesamtkontexts. Bei Abweichung von der typischen Konstellation ist - eine kurze Begründung im Review-Dokument erforderlich. - - # --------------------------------------------------------------------------- - # CONTINUE - # --------------------------------------------------------------------------- - - pfad_continue: - - id: "CONTINUE" - name: "Weiterbetrieb" - - orientierung: | - Typische Konstellation: - - Alle Dimensionen Grün oder max. eine Dimension Gelb - - Keine wiederkehrenden oder eskalierenden Probleme - - Nutzerzufriedenheit stabil oder positiv - - Keine strategischen Bedenken - - sor_behandlung: "Nein (Selbst-Review ausreichend)" - - output: - - "Service-Definition-Update mit Review-Status" - - "Information an SPM" - - naechster_review: "Nächstes Quartal (Regelzyklus)" - - # --------------------------------------------------------------------------- - # IMPROVEMENT - # --------------------------------------------------------------------------- - - pfad_improvement: - - id: "IMPROVEMENT" - name: "Verbesserung" - - orientierung: | - Typische Konstellation: - - Eine oder mehrere Dimensionen Rot oder mehrfach Gelb - - Identifizierte Ursachen sind im Rahmen des Service lösbar - - Keine grundsätzliche Änderung des Service-Scopes erforderlich - - Verbesserung ist mit vorhandenen oder planbaren Ressourcen umsetzbar - - beispiele: - - "Wiederkehrende Incidents mit bekannter, behebbarer Ursache" - - "Performance-Probleme, die durch Optimierung lösbar sind" - - "Dokumentationslücken im Betrieb" - - "Schulungsbedarf bei Nutzern oder Support" - - "Monitoring-Erweiterung erforderlich" - - varianten: - - so_gefuehrt: - beschreibung: "Improvement liegt in SO-Kompetenz und -Ressourcen" - sor_behandlung: "Nein" - beispiel: "Dokumentation aktualisieren, Workaround etablieren" - - ressourcenrelevant: - beschreibung: "Improvement erfordert zusätzliche Ressourcen oder Abstimmung" - sor_behandlung: "Ja (SOR unter 'Operative Entscheidungen')" - beispiel: "Technische Optimierung mit Entwicklungsaufwand" - - output: - - "Maßnahmendefinition in der Service-Definition" - - "Ggf. SOR-Beschluss" - - naechster_review: "Nächstes Quartal (mit Wirksamkeitsprüfung)" - - # --------------------------------------------------------------------------- - # REDESIGN - # --------------------------------------------------------------------------- - - pfad_redesign: - - id: "REDESIGN" - name: "Neugestaltung" - - orientierung: | - Typische Konstellation: - - Mehrere Dimensionen Rot, ggf. über mehrere Quartale - - Ursachen liegen in der Service-Architektur, im Scope oder im Grundkonzept - - Bisherige Improvement-Maßnahmen waren nicht wirksam - - Änderung erfordert Projektcharakter (Ressourcen, Zeit, Governance) - - beispiele: - - "Technologie-Ablösung erforderlich (EOL, nicht mehr wartbar)" - - "Zielgruppe oder Funktionsumfang muss fundamental neu definiert werden" - - "Service passt nicht mehr zur strategischen Ausrichtung" - - "Integration mit anderen Services erfordert Neuarchitektur" - - sor_behandlung: "Ja (SOR unter 'Strategische Entscheidungen')" - - output: - - "SOR-Beschluss: Übergabe an DPM" - - "Demand für Neugestaltung wird erfasst" - - "Service bleibt in Betrieb bis Ablösung" - - naechster_review: "Weiterhin quartalsweise bis Ablösung" - - # --------------------------------------------------------------------------- - # RETIRE - # --------------------------------------------------------------------------- - - pfad_retire: - - id: "RETIRE" - name: "Stilllegung" - - orientierung: | - Typische Konstellation: - - Service wird kaum noch genutzt (Nutzungszahlen minimal) - - Betriebsaufwand steht in keinem Verhältnis zum Nutzen - - Funktionalität wird durch anderen Service abgedeckt - - Strategische Entscheidung zur Ablösung liegt vor - - Technologie ist nicht mehr supportfähig und Redesign unverhältnismäßig - - beispiele: - - "Legacy-System mit < 10 aktiven Nutzern" - - "Dopplung mit anderem Service nach Migration" - - "Lieferant kündigt Support, keine Alternative" - - sor_behandlung: "Ja (SOR unter 'Strategische Entscheidungen')" - - output: - - "SOR-Beschluss: Stilllegung" - - "Demand für Stilllegungsprojekt an DPM" - - "Kommunikationsplan für Nutzer" - - naechster_review: "Entfällt nach Stilllegung" - - # --------------------------------------------------------------------------- - # BEGRÜNDUNGSPFLICHT - # --------------------------------------------------------------------------- - - begruendungspflicht: - - wann: "Bei Abweichung von typischer Konstellation" - - form: "Kurze schriftliche Begründung im Review-Dokument (2-3 Sätze)" - - beispiele: - - situation: "Dimension Rot, aber Empfehlung CONTINUE" - begruendung: | - "Obwohl Dimension Betriebsstabilität Rot ist, empfehle ich CONTINUE, - weil die Ursache ein bekannter Lieferanten-Bug ist, der im nächsten - Release behoben wird (ETA: Q1). Kein Handlungsbedarf unsererseits." - - - situation: "Alle Dimensionen Grün, aber Empfehlung REDESIGN" - begruendung: | - "Trotz stabiler Bewertung empfehle ich REDESIGN, weil die zugrunde - liegende Technologie (Framework X) zum Jahresende EOL geht und - eine Migration ohnehin erforderlich ist." - -# ============================================================================= -# 5. SOR-GOVERNANCE FÜR SERVICE-REVIEW -# ============================================================================= - -sor_governance: - - governance_referenz: "GOV-SR-004" - - grundprinzip: | - Die SOR-Behandlung von Service-Reviews erfolgt differenziert nach - Handlungsempfehlung. Routine-Reviews (CONTINUE) binden keine Sitzungszeit. - Die SOR fokussiert auf Entscheidungen, die Governance erfordern. - - # --------------------------------------------------------------------------- - # BEHANDLUNGSKATEGORIEN - # --------------------------------------------------------------------------- - - behandlungskategorien: - - - kategorie: "Kenntnisnahme (kein SOR-Agenda-Punkt)" - - gilt_fuer: - - "CONTINUE" - - "IMPROVEMENT (SO-geführt, ressourcenneutral)" - - verfahren: | - SO dokumentiert in der Service-Definition, informiert SPM. - Keine SOR-Vorlage erforderlich. - - protokoll: "Nicht erforderlich" - - hinweis: | - SPM kann bei Auffälligkeiten im Portfolio (z.B. mehrere Services - mit gleicher Problemdimension) einen Service-Review auf die - SOR-Agenda setzen. - - - kategorie: "Operative Entscheidung" - - gilt_fuer: - - "IMPROVEMENT (ressourcenrelevant)" - - verfahren: | - SO reicht Review-Vorlage ein (Frist: 3 Arbeitstage vor Sitzung). - SOR behandelt unter Agenda-Block "Operative Entscheidungen". - - entscheidungsmodus: "Konsent (analog Gate-Entscheidungen)" - - entscheidungsoptionen: - - "Freigabe der Improvement-Maßnahmen" - - "Freigabe mit Auflagen" - - "Zurückweisung (mit Begründung)" - - "Eskalation an MB (bei Ressourcenkonflikt)" - - protokoll: "Kurze Dokumentation: Beschluss, ggf. Auflagen, Verantwortlicher" - - - kategorie: "Strategische Entscheidung" - - gilt_fuer: - - "REDESIGN" - - "RETIRE" - - verfahren: | - SO reicht Review-Vorlage ein (Frist: 3 Arbeitstage vor Sitzung). - SOR behandelt unter Agenda-Block "Strategische Entscheidungen". - - entscheidungsmodus: "Konsent" - - entscheidungsoptionen: - - "Freigabe: Übergabe an DPM" - - "Zurück an SO: Weitere Prüfung erforderlich" - - "Eskalation an MB: Strategische Tragweite" - - output_bei_freigabe: - redesign: "Demand an DPM (Klassifizierung: Neugestaltung)" - retire: "Demand an DPM (Stilllegungsprojekt)" - - protokoll: "Vollständige Dokumentation inkl. Begründung und nächste Schritte" - - # --------------------------------------------------------------------------- - # VORLAGE-ANFORDERUNGEN - # --------------------------------------------------------------------------- - - vorlage_anforderungen: - - name: "Service-Review-Vorlage für SOR" - - pflichtinhalte: - - feld: "Service-Bezeichnung und Version" - - feld: "Review-Zeitraum" - - feld: "Bewertung je Dimension (Ampel + Kurztext)" - - feld: "Handlungsempfehlung" - - feld: "Begründung der Empfehlung" - - feld: "Bei IMPROVEMENT: Maßnahmenvorschlag mit Ressourcenschätzung" - - feld: "Bei REDESIGN/RETIRE: Konsequenzen, Alternativen, Stakeholder-Impact" - - einreichungsfrist: "3 Arbeitstage vor SOR-Sitzung" - - einreichung_an: "SPM (koordiniert SOR-Agenda)" - - vollstaendigkeitspruefung: - verantwortlich: "SPM" - bei_unvollstaendigkeit: "Rückfrage an SO, ggf. Verschiebung auf nächste Sitzung" - - # --------------------------------------------------------------------------- - # INTEGRATION IN SOR-GESCHÄFTSORDNUNG - # --------------------------------------------------------------------------- - - integration_sor_go: - - hinweis: | - Die folgenden Elemente sind in die SOR-Geschäftsordnung zu integrieren, - sobald diese aus dem Placeholder-Status entwickelt wird. - - zu_integrierende_elemente: - - "Service-Review als Entscheidungstyp (neben Gate-Entscheidungen, Routing)" - - "Behandlungskategorien (Kenntnisnahme, Operativ, Strategisch)" - - "Vorlage-Anforderungen und Einreichungsfrist" - - "Entscheidungsmodus für Review-Entscheidungen" - -# ============================================================================= -# 6. IMPROVEMENT-STEUERUNG -# ============================================================================= - -improvement_steuerung: - - governance_referenz: "GOV-SR-005" - - grundprinzip: | - Im MVP wird Service Improvement über die Service-Definition gesteuert. - Der SO dokumentiert Maßnahmen und prüft deren Wirksamkeit im nächsten - Quartals-Review. Es gibt keine separate CI-Infrastruktur. - - # --------------------------------------------------------------------------- - # MVP-LÖSUNG - # --------------------------------------------------------------------------- - - mvp_loesung: - - massnahmen_dokumentation: - - ort: "Service-Definition → Abschnitt 'laufende_verbesserungen'" - - pflichtfelder: - - id: "massnahmen_id" - name: "ID" - beschreibung: "Eindeutige Kennung (z.B. IMP-[Service]-001)" - - - id: "beschreibung" - name: "Beschreibung" - beschreibung: "Kurzbeschreibung der Maßnahme (1-2 Sätze)" - - - id: "ziel" - name: "Ziel" - beschreibung: "Erwartetes Ergebnis / betroffene Dimension" - - - id: "verantwortlich" - name: "Verantwortlich" - beschreibung: "Wer setzt um? (Person oder Rolle)" - - - id: "termin" - name: "Zieltermin" - beschreibung: "Geplanter Abschluss" - - - id: "status" - name: "Status" - beschreibung: "Offen | In Arbeit | Abgeschlossen | Abgebrochen" - - optionale_felder: - - id: "aufwand" - name: "Aufwandsschätzung" - beschreibung: "PT oder Kostenschätzung (falls relevant)" - - - id: "abhaengigkeiten" - name: "Abhängigkeiten" - beschreibung: "Andere Maßnahmen, Services, Projekte" - - wirksamkeitspruefung: - - wann: "Im nächsten Quartals-Review" - - wie: | - SO bewertet: Hat sich die betroffene Dimension verbessert? - Ist das erwartete Ergebnis eingetreten? - - dokumentation: "Kurzkommentar in der Service-Definition bei der Maßnahme" - - bewertung: - - ergebnis: "Wirksam" - aktion: "Maßnahme wird als abgeschlossen markiert" - - - ergebnis: "Teilweise wirksam" - aktion: "Maßnahme bleibt offen oder wird erweitert" - - - ergebnis: "Nicht wirksam" - aktion: "Analyse der Ursache, neue Maßnahme oder Pfad-Wechsel (z.B. → REDESIGN)" - - - ergebnis: "Abgebrochen" - aktion: "Begründung dokumentieren" - - abschlusslogik: - - regelfall: | - Abgeschlossene Maßnahmen bleiben in der Service-Definition sichtbar (Historie), - werden aber nicht mehr aktiv getrackt. - - archivierung: | - Nach 4 Quartalen können abgeschlossene Maßnahmen in einen - Archiv-Abschnitt verschoben werden (optional). - - # --------------------------------------------------------------------------- - # POST-MVP-ERWEITERUNG - # --------------------------------------------------------------------------- - - post_mvp_erweiterung: - - status: "Placeholder für zukünftige Entwicklung" - - beschreibung: | - Nach MVP-Stabilisierung kann eine dedizierte Continual Improvement - Practice entwickelt werden, die übergreifendes Maßnahmen-Tracking, - Lessons Learned und ein zentrales Improvement-Register umfasst. - - moegliche_elemente: - - "Zentrales Improvement-Register (CIR) mit Service-Verknüpfung" - - "Standardisierter Improvement-Workflow" - - "Aggregierte Auswertung über alle Services" - - "Integration mit Problem Management" - - migration: - von: "Service-Definition-basiertes Tracking" - nach: "Zentrales CIR mit bidirektionaler Verlinkung" - - voraussetzung: | - Entscheidung über Tooling und Verantwortlichkeit für CI-Practice - erforderlich. Derzeit kein dedizierter CI-Practice-Owner definiert. - - # --------------------------------------------------------------------------- - # ABGRENZUNG ZU SR_04 - # --------------------------------------------------------------------------- - - abgrenzung_sr_04: - - klarstellung: | - Die Aktivität sr_04 ("Service Improvement") im Workshop-Blueprint - beschreibt den Entscheidungspfad und die initiale Maßnahmenplanung. - Die laufende Steuerung und Wirksamkeitsprüfung erfolgt über diesen - Mechanismus (Steckbrief-Tracking + Folge-Review). - - sr_04_umfasst: - - "Entscheidung für Improvement-Pfad" - - "Initiale Definition der Maßnahmen" - - "Abstimmung mit SOR (falls ressourcenrelevant)" - - dieses_konzept_ergaenzt: - - "Strukturierte Dokumentation der Maßnahmen in der Service-Definition" - - "Wirksamkeitsprüfung im Folge-Review" - - "Abschlusslogik" - -# ============================================================================= -# 7. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - # --------------------------------------------------------------------------- - # INPUT-SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - input: - - - quelle: "Service Betrieb" - was: "Betriebsdaten, Monitoring-Informationen" - artefakt: "Service-Qualitätsbericht (informell)" - frequenz: "Quartalsweise oder laufend" - hinweis: | - Der 'Service-Qualitätsbericht' ist kein formalisiertes Artefakt im MVP. - Der SO nutzt verfügbare Daten und Einschätzungen des Betriebsteams. - - - quelle: "Service Support" - was: "Support-Statistik, Problem Records" - artefakt: "Incident-/Problem-Auswertung" - frequenz: "Quartalsweise" - - - quelle: "SHM (Stakeholder Management)" - was: "Stakeholder-Feedback, VoC-Signale" - artefakt: "VoC-Erkenntnisse (Cluster D2: Service-Qualität)" - frequenz: "Quartalsweise (E2-Review)" - referenz: "shm_voice-of-customer.yaml" - - - quelle: "SLM (Service Level Management)" - was: "SLA-Erfüllungsgrad" - artefakt: "SLA-Bericht (falls vorhanden)" - frequenz: "Abhängig von Service-Kategorie" - - # --------------------------------------------------------------------------- - # OUTPUT-SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - output: - - - ziel: "SPM (Service-Portfolio-Manager)" - was: "Review-Ergebnis aller Services" - artefakt: "Aktualisierte Service-Definitionen" - frequenz: "Quartalsweise" - zweck: "Portfolio-Übersicht, Aggregation für Portfolio-Review" - - - ziel: "SOR (bei Handlungsbedarf)" - was: "Review-Vorlage" - artefakt: "Service-Review-Vorlage" - frequenz: "Anlassbezogen" - bedingung: "Bei IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE" - - - ziel: "DPM (Demand Portfolio Management)" - was: "Demand für Neugestaltung oder Stilllegung" - artefakt: "Demand mit Klassifizierung" - frequenz: "Anlassbezogen" - bedingung: "Bei REDESIGN oder RETIRE (nach SOR-Freigabe)" - - - ziel: "Service Betrieb" - was: "Freigegebene Improvement-Maßnahmen" - artefakt: "Maßnahmenliste in der Service-Definition" - frequenz: "Nach Review" - bedingung: "Bei IMPROVEMENT" - - # --------------------------------------------------------------------------- - # SYNCHRONISATION MIT ANDEREN REVIEWS - # --------------------------------------------------------------------------- - - synchronisation: - - dpm_portfolio_review: - beschreibung: | - Der Service-Review liefert aggregierten Input für den quartalsweisen - DPM-Portfolio-Review. SPM bringt konsolidierte Service-Erkenntnisse ein. - - sequenz: | - Service-Reviews (erste zwei Wochen nach Quartalsende) - → SPM-Aggregation - → DPM-Portfolio-Review (ca. T+10 bis T+14) - - shm_e2_review: - beschreibung: | - SHM liefert VoC-Erkenntnisse aus E2 (Quartals-Review) als Input - für die Dimension "Nutzerzufriedenheit". - - sequenz: | - SHM E2-Review - → VoC-Erkenntnisse verfügbar - → Service-Review nutzt D2-Cluster - - portfolio_review_spm: - beschreibung: | - Das Service-Portfolio-Review (strategisch) nutzt aggregierte - Ergebnisse der Einzel-Service-Reviews. - - referenz: "spm_portfolio-review-konzept.yaml" - -# ============================================================================= -# 8. ROLLEN UND VERANTWORTLICHKEITEN -# ============================================================================= - -rollen: - - service_owner: - kurzbezeichnung: "SO" - verantwortung: - - "Durchführung des quartalsweisen Selbst-Reviews" - - "Bewertung der 4 Dimensionen" - - "Ableitung der Handlungsempfehlung" - - "Dokumentation in der Service-Definition" - - "Information an SPM" - - "Einreichung der SOR-Vorlage (bei Bedarf)" - - "Umsetzung von Improvement-Maßnahmen" - raci: "A/R für Review-Durchführung" - - service_portfolio_manager: - kurzbezeichnung: "SPM" - verantwortung: - - "Erhalt und Sichtung aller Review-Berichte" - - "Aggregation für Portfolio-Perspektive" - - "Koordination der SOR-Agenda (Review-Vorlagen)" - - "Vollständigkeitsprüfung der SOR-Vorlagen" - - "Identifikation portfolio-übergreifender Muster" - raci: "C bei Review, A für Portfolio-Aggregation" - - sor: - kurzbezeichnung: "SOR" - typ: "Gremium" - verantwortung: - - "Entscheidung bei IMPROVEMENT (ressourcenrelevant)" - - "Entscheidung bei REDESIGN und RETIRE" - - "Freigabe der Übergabe an DPM" - raci: "A für Governance-Entscheidungen" - - betriebsteam: - verantwortung: - - "Lieferung von Betriebsdaten und Einschätzungen" - - "Umsetzung technischer Improvement-Maßnahmen" - raci: "C/I bei Review, R bei Umsetzung" - - problem_manager: - verantwortung: - - "Input zu wiederkehrenden Problemen" - - "Root-Cause-Analyse bei Bedarf" - raci: "C bei Review (für D2)" - -# ============================================================================= -# 9. OFFENE PUNKTE UND POST-MVP -# ============================================================================= - -offene_punkte: - - im_mvp_nicht_adressiert: - - - punkt: "Externer SLA-Review mit Kunden" - beschreibung: | - GOV-003 definiert eine Zwei-Stufen-Logik (interner Review → externer - SLA-Review). Der externe Review ist nicht Teil dieses Konzepts. - status: "Zu modellieren in SLM-Practice" - referenz: "spm_practice_service-level-management.yaml" - - - punkt: "Service-Qualitätsbericht als formales Artefakt" - beschreibung: | - Der Input 'Service-Qualitätsbericht' ist nicht standardisiert. - Im MVP nutzt der SO verfügbare Daten informell. - status: "Optional für Post-MVP" - - - punkt: "Quantitative KPI-Integration" - beschreibung: | - Das Bewertungsschema ist qualitativ. Wenn Monitoring-Daten - verfügbar werden, können sie als Indikatoren einfließen. - status: "Erweiterbar bei Bedarf" - - - punkt: "Continual Improvement Practice" - beschreibung: | - Eine übergreifende CI-Practice mit zentralem Improvement-Register - existiert nicht. Das MVP nutzt Steckbrief-Tracking. - status: "Konzept-Placeholder für Post-MVP" - - validierungsbedarf: - - - punkt: "Bewertungsdimensionen" - beschreibung: "Die 4 Dimensionen sollten mit SOs validiert werden" - methode: "Workshop oder Pilotierung" - - - punkt: "Review-Aufwand" - beschreibung: "Der geschätzte Aufwand (30-60 Min.) muss verifiziert werden" - methode: "Pilotierung mit 2-3 Services" - - - punkt: "SPM-Informationspflicht" - beschreibung: "Praktikabilität des regelmäßigen Reportings prüfen" - methode: "Pilotierung" - -# ============================================================================= -# 10. GOVERNANCE-ENTSCHEIDUNGEN (ZUSAMMENFASSUNG) -# ============================================================================= - -governance_entscheidungen_log: - - - id: "GOV-SR-001" - datum: "2025-12-17" - frage: "Wie bewertet der SO den Service-Zustand?" - entscheidung: | - 4-Dimensionen-Modell (Leistungserbringung, Betriebsstabilität, - Nutzerzufriedenheit, Zukunftsfähigkeit) mit qualitativer - Ampelbewertung (Grün/Gelb/Rot). Keine mathematische Aggregation. - begruendung: | - Strukturelle Analogie zu SHM (VoC-Cluster), qualitative Bewertung - passt zur verfügbaren Datenbasis und Verwaltungskultur. - confidence: "80%" - status: "final" - - - id: "GOV-SR-002" - datum: "2025-12-17" - frage: "In welchem Rhythmus findet der Review statt?" - entscheidung: | - Quartalsweiser SO-Selbst-Review. SPM erhält regelmäßig alle - Review-Berichte. SOR-Einbeziehung nur bei Auffälligkeiten - (Rot-Dimension oder IMPROVEMENT/REDESIGN/RETIRE). - begruendung: | - Skaliert mit Portfolio-Größe, erhält SO-Eigenverantwortung, - SPM hat Portfolio-Übersicht, SOR fokussiert auf Ausnahmen. - confidence: "85%" - status: "final" - - - id: "GOV-SR-003" - datum: "2025-12-17" - frage: "Gibt es objektive Schwellenwerte für Eskalation?" - entscheidung: | - Orientierungskriterien mit Urteilsvorbehalt. Keine Automatismen. - SO begründet bei Abweichung von typischer Konstellation. - begruendung: | - Konsistent mit SHM-Logik, vermeidet Schein-Objektivität, - erhält Flexibilität für Service-spezifische Kontexte. - confidence: "75%" - status: "final" - - - id: "GOV-SR-004" - datum: "2025-12-17" - frage: "Wie läuft die SOR-Behandlung von Reviews?" - entscheidung: | - Differenziert nach Empfehlung: CONTINUE und SO-geführtes - IMPROVEMENT ohne SOR-Behandlung. Ressourcenrelevantes IMPROVEMENT - als operative Entscheidung. REDESIGN/RETIRE als strategische - Entscheidung. - begruendung: | - Fokussiert SOR-Zeit auf Governance-Entscheidungen, - Subsidiaritätsprinzip für SO-Kompetenz. - confidence: "80%" - status: "final" - - - id: "GOV-SR-005" - datum: "2025-12-17" - frage: "Wie wird die Wirksamkeit von Improvements nachgehalten?" - entscheidung: | - MVP: Steckbrief-Tracking. Maßnahmen werden im Service-Steckbrief - dokumentiert, Wirksamkeitsprüfung im Folge-Review. Keine - separate CI-Infrastruktur. - begruendung: | - Minimal Viable, kein neues Tooling erforderlich, erweiterbar - bei späterer CI-Practice-Etablierung. - confidence: "70%" - status: "final" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.1" - datum: "2026-01-31" - aenderung: | - - Alle Referenzen von 'Service-Steckbrief' auf 'Service-Definition' geändert - - Begründung: Review- und Improvement-Informationen sind interne Steuerungsdaten - und gehören in die Service-Definition (Single Source of Truth), nicht in den - kundenorientierten Service-Steckbrief - - Betroffene Stellen: regelzyklus, spm_informationspflicht, entscheidungspfade, - sor_governance, improvement_steuerung, schnittstellen, rollen - autor: "DIGITOM-Projekt" - referenz: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht" - - - version: "1.0" - datum: "2025-12-17" - aenderung: "Initiale Erstellung basierend auf Klärungsbereichen KB1-KB5" +# ============================================================================= +# KONZEPT: SERVICE-REVIEW (EINZELSERVICE) +# ============================================================================= + +metadata: + id: "K-SR" + name: "Konzept Service-Review" + version: "1.1" + status: "draft" + erstellt: "2025-12-17" + geaendert: "2026-01-31" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "konzept" + + beschreibung: > + Definiert die Governance-Logik, Bewertungsmethodik und Entscheidungsverfahren + für den periodischen Review eines einzelnen Services. Ergänzt den prozessualen + Rahmen aus dem Service-Lifecycle-Blueprint um konzeptionelle Klarheit. + + abgrenzung: + service_lifecycle_blueprint: > + Das Dokument "service-lifecycle_service-review.yaml" beschreibt den + prozessualen Rahmen (Aktivitäten sr_01 bis sr_06, RACI-Zuordnung). + Dieses Konzept definiert die dahinterliegende Governance-Logik. + + portfolio_review: > + Das "Service-Portfolio-Review" (G-PR) betrachtet das Gesamtportfolio + aus strategischer Perspektive. Dieses Konzept fokussiert auf den + einzelnen Service aus operativer Perspektive. + + referenzen: + blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-review.yaml" + portfolio_review: "01_governance/spm_portfolio-review-konzept.yaml" + sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" + service_definition: "06_Informationsmodell/spm_schema_service-definition.yaml" + shm_koordination: "#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml" + + governance_entscheidungen: + - "GOV-SR-001 bis GOV-SR-005 (in diesem Dokument definiert)" + +# ============================================================================= +# 1. ZWECK UND SCOPE +# ============================================================================= + +zweck_und_scope: + + zweck: | + Der Service-Review dient der systematischen Bewertung eines Services + im laufenden Betrieb. Er stellt sicher, dass: + + - Der Service seinen definierten Zweck erfüllt + - Probleme frühzeitig erkannt und adressiert werden + - Verbesserungspotenziale identifiziert werden + - Entscheidungen zu Improvement, Redesign oder Stilllegung fundiert getroffen werden + + scope: + in_scope: + - "Alle Services im Status 'Aktiv' im Service-Portfolio" + - "Services im Early Life Support (ELS) mit eingeschränktem Fokus" + + out_of_scope: + - "Services in Entwicklung oder Transition (andere Governance)" + - "Portfolio-übergreifende Betrachtung (→ Portfolio-Review)" + - "Externe SLA-Reviews mit Kunden (→ SLM-Practice)" + + ergebnis_des_reviews: + beschreibung: "Der Review mündet in eine Handlungsempfehlung" + optionen: + - id: "CONTINUE" + name: "Weiterbetrieb" + beschreibung: "Service stabil, keine Maßnahmen erforderlich" + + - id: "IMPROVEMENT" + name: "Verbesserung" + beschreibung: "Optimierungsbedarf identifiziert, im Rahmen des Service lösbar" + + - id: "REDESIGN" + name: "Neugestaltung" + beschreibung: "Strukturelle Änderung erforderlich, Übergabe an DPM" + + - id: "RETIRE" + name: "Stilllegung" + beschreibung: "Service soll außer Betrieb genommen werden" + +# ============================================================================= +# 2. BEWERTUNGSSCHEMA +# ============================================================================= + +bewertungsschema: + + governance_referenz: "GOV-SR-001" + + grundprinzip: | + Der Service Owner bewertet den Service anhand von vier Dimensionen + mit einer qualitativen Ampelbewertung. Die Bewertung ist urteilsbasiert, + nicht metrisch-automatisiert. Sie dient als strukturierte Entscheidungs- + grundlage für den SO selbst und ggf. für die SOR. + + methodik: "Qualitative Dimensionsbewertung mit Ampellogik" + + # --------------------------------------------------------------------------- + # BEWERTUNGSSKALA + # --------------------------------------------------------------------------- + + bewertungsskala: + + gruen: + label: "Stabil" + code: "G" + bedeutung: "Dimension erfüllt Erwartungen, kein Handlungsbedarf" + typische_indikatoren: + - "Ziele werden erreicht" + - "Keine wiederkehrenden Probleme" + - "Positives oder neutrales Feedback" + + gelb: + label: "Beobachten" + code: "Y" + bedeutung: "Auffälligkeiten erkennbar, Monitoring erforderlich" + typische_indikatoren: + - "Einzelne Abweichungen von Zielen" + - "Vereinzelte Beschwerden oder Probleme" + - "Trend-Verschlechterung erkennbar" + + rot: + label: "Handlungsbedarf" + code: "R" + bedeutung: "Systematische Probleme, Maßnahmen erforderlich" + typische_indikatoren: + - "Ziele werden wiederholt verfehlt" + - "Wiederkehrende oder eskalierende Probleme" + - "Deutliche Kritik von Nutzern oder Stakeholdern" + + # --------------------------------------------------------------------------- + # BEWERTUNGSDIMENSIONEN + # --------------------------------------------------------------------------- + + dimensionen: + + - id: "SR-D1" + name: "Leistungserbringung" + leitfrage: "Liefert der Service den erwarteten Nutzen?" + + beschreibung: | + Bewertet, ob der Service seinen definierten Zweck erfüllt und + die vereinbarten Leistungsziele erreicht. + + indikatoren: + - "Zielerreichung (falls SLOs/SLAs definiert)" + - "Verfügbarkeit und Performance im Nutzungskontext" + - "Funktionsumfang entspricht dokumentiertem Scope" + - "Nutzen wird von Stakeholdern wahrgenommen" + + datenquellen: + - "Monitoring-Daten (falls vorhanden)" + - "SLA-Berichte (falls vorhanden)" + - "Stakeholder-Feedback via SHM" + + - id: "SR-D2" + name: "Betriebsstabilität" + leitfrage: "Läuft der Service störungsarm und beherrschbar?" + + beschreibung: | + Bewertet die operative Stabilität und den Betriebsaufwand + aus Sicht des Betriebsteams. + + indikatoren: + - "Incident-Häufigkeit und -Schwere" + - "Wiederkehrende Probleme (Problem Records)" + - "Betriebsaufwand im Verhältnis zum Erwarteten" + - "Stabilität der technischen Komponenten" + + datenquellen: + - "Incident-Statistik aus ITSM-Tool" + - "Problem-Records" + - "Einschätzung des Betriebsteams" + + - id: "SR-D3" + name: "Nutzerzufriedenheit" + leitfrage: "Wie bewerten die Nutzer den Service?" + + beschreibung: | + Bewertet die Wahrnehmung des Services durch die Nutzer und + Stakeholder, unabhängig von technischen Metriken. + + indikatoren: + - "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)" + - "Beschwerden und Eskalationen" + - "VoC-Signale via SHM (falls vorhanden)" + - "Informelle Rückmeldungen" + + datenquellen: + - "Service-Desk-Feedback" + - "SHM-Erkenntnisse (VoC-Cluster D2)" + - "Direkte Nutzer-Rückmeldungen" + + - id: "SR-D4" + name: "Zukunftsfähigkeit" + leitfrage: "Ist der Service mittelfristig tragfähig?" + + beschreibung: | + Bewertet die mittelfristige Perspektive des Services hinsichtlich + Technologie, Strategie und Ressourcen. + + indikatoren: + - "Technische Schulden und Modernisierungsbedarf" + - "Abhängigkeiten und externe Risiken (Lieferanten, Technologie-EOL)" + - "Strategische Passung (Alignment mit DIGIT-Strategie)" + - "Ressourcenverfügbarkeit für Weiterentwicklung" + + datenquellen: + - "Technische Einschätzung des Betriebsteams" + - "IT-Architektur-Bewertung (falls vorhanden)" + - "Strategische Vorgaben" + + # --------------------------------------------------------------------------- + # AGGREGATIONSLOGIK + # --------------------------------------------------------------------------- + + aggregationslogik: + + grundsatz: | + Es gibt keine mathematische Aggregation zu einem Score. Der SO + betrachtet das Gesamtbild und leitet eine begründete Handlungs- + empfehlung ab. + + orientierung: + - konstellation: "Alle Dimensionen Grün" + typische_empfehlung: "CONTINUE" + + - konstellation: "Max. eine Dimension Gelb, Rest Grün" + typische_empfehlung: "CONTINUE mit Monitoring" + + - konstellation: "Eine oder mehrere Dimensionen Gelb" + typische_empfehlung: "CONTINUE oder IMPROVEMENT prüfen" + + - konstellation: "Eine Dimension Rot" + typische_empfehlung: "IMPROVEMENT" + + - konstellation: "Mehrere Dimensionen Rot" + typische_empfehlung: "IMPROVEMENT oder REDESIGN prüfen" + + - konstellation: "D4 (Zukunftsfähigkeit) Rot + strategische Gründe" + typische_empfehlung: "REDESIGN oder RETIRE prüfen" + + hinweis: | + Diese Orientierung ersetzt nicht das Urteil des SO. Abweichungen + sind möglich und erfordern eine kurze Begründung. + +# ============================================================================= +# 3. REVIEW-RHYTHMUS +# ============================================================================= + +review_rhythmus: + + governance_referenz: "GOV-SR-002" + + grundprinzip: | + Der Service-Review folgt einem Hybridmodell: Der SO führt eigenständig + einen quartalsweisen Selbst-Review durch. Die SOR wird nur bei + Auffälligkeiten oder Handlungsbedarf einbezogen. Der SPM erhält + regelmäßig alle Review-Berichte für die Portfolio-Perspektive. + + # --------------------------------------------------------------------------- + # REGELZYKLUS + # --------------------------------------------------------------------------- + + regelzyklus: + + frequenz: "Quartalsweise" + verantwortlich: "Service Owner" + + synchronisation: | + Der Service-Review sollte vor dem quartalsweisen DPM-Portfolio-Review + abgeschlossen sein, damit aggregierte Erkenntnisse einfließen können. + + Empfohlener Zeitpunkt: Erste zwei Wochen nach Quartalsende. + + ablauf: + + - schritt: 1 + was: "SO führt Bewertung durch" + beschreibung: "Bewertung der 4 Dimensionen anhand verfügbarer Daten und Einschätzungen" + dauer: "30-60 Minuten" + output: "Dimensionsbewertung (Ampel + Kurztext)" + + - schritt: 2 + was: "SO leitet Handlungsempfehlung ab" + beschreibung: "Gesamteinschätzung und Empfehlung (CONTINUE/IMPROVEMENT/REDESIGN/RETIRE)" + output: "Handlungsempfehlung mit Begründung" + + - schritt: 3 + was: "SO aktualisiert Service-Definition" + beschreibung: "Dokumentation des Review-Ergebnisses in der Service-Definition (Abschnitt 'service_review')" + output: "Aktualisierte Service-Definition mit Review-Status" + + - schritt: 4 + was: "SO informiert SPM" + beschreibung: "Review-Bericht wird an SPM übermittelt" + output: "SPM hat aktuellen Review-Status aller Services" + + - schritt: 5 + was: "SO prüft SOR-Einbeziehung" + beschreibung: "Entscheidung, ob SOR-Behandlung erforderlich ist" + output: "Ggf. Review-Vorlage für SOR" + + # --------------------------------------------------------------------------- + # SPM-INFORMATIONSPFLICHT + # --------------------------------------------------------------------------- + + spm_informationspflicht: + + grundsatz: | + Der SPM erhält regelmäßig alle Service-Review-Berichte, unabhängig + vom Ergebnis. Dies ermöglicht die Portfolio-Perspektive und die + Vorbereitung des Portfolio-Reviews. + + was: "Review-Ergebnis je Service (Dimensionsbewertung + Empfehlung)" + wann: "Nach Abschluss des Quartals-Reviews" + wie: "Aktualisierte Service-Definition oder konsolidierte Übersicht" + + spm_nutzung: + - "Aggregation für Portfolio-Review" + - "Identifikation portfolio-übergreifender Muster" + - "Früherkennung von Ressourcenkonflikten bei Improvement-Vorhaben" + + # --------------------------------------------------------------------------- + # SOR-EINBEZIEHUNG + # --------------------------------------------------------------------------- + + sor_einbeziehung: + + grundsatz: | + Die SOR wird nur einbezogen, wenn der Review zu Handlungsbedarf führt, + der über die SO-Kompetenz hinausgeht oder Governance-Entscheidungen erfordert. + + trigger: + - "Mindestens eine Dimension 'Rot'" + - "Handlungsempfehlung: IMPROVEMENT mit Ressourcenbedarf" + - "Handlungsempfehlung: REDESIGN oder RETIRE" + - "SO ist unsicher über angemessene Reaktion" + + verfahren: "SO reicht Review-Vorlage für nächste SOR-Sitzung ein" + + keine_sor_behandlung_bei: + - "Alle Dimensionen Grün oder Gelb UND Empfehlung CONTINUE" + - "IMPROVEMENT ohne zusätzlichen Ressourcenbedarf (SO-geführt)" + + # --------------------------------------------------------------------------- + # ANLASSBEZOGENER REVIEW + # --------------------------------------------------------------------------- + + anlassbezogener_review: + + grundsatz: | + Außerhalb des Regelzyklus kann ein Ad-hoc-Review erforderlich sein, + wenn kritische Ereignisse eintreten. + + trigger: + - "Major Incident mit service-weiten Auswirkungen" + - "Wiederholte SLA-Verletzung (3+ in Folge)" + - "Stakeholder-Eskalation an SOR oder Mission Board" + - "Sicherheitsvorfall mit Service-Bezug" + + verfahren: | + SO führt Ad-hoc-Review durch (kann verkürzt sein, Fokus auf + betroffene Dimension). Bei Handlungsbedarf → SOR-Behandlung. + + dokumentation: "In der Service-Definition als 'Ad-hoc-Review' markieren" + +# ============================================================================= +# 4. ENTSCHEIDUNGSPFADE UND ESKALATIONSKRITERIEN +# ============================================================================= + +entscheidungspfade: + + governance_referenz: "GOV-SR-003" + + grundprinzip: | + Die Kriterien für jeden Entscheidungspfad sind Orientierungshilfen, + keine Automatismen. Der SO trifft die Entscheidung unter Berücksichtigung + des Gesamtkontexts. Bei Abweichung von der typischen Konstellation ist + eine kurze Begründung im Review-Dokument erforderlich. + + # --------------------------------------------------------------------------- + # CONTINUE + # --------------------------------------------------------------------------- + + pfad_continue: + + id: "CONTINUE" + name: "Weiterbetrieb" + + orientierung: | + Typische Konstellation: + - Alle Dimensionen Grün oder max. eine Dimension Gelb + - Keine wiederkehrenden oder eskalierenden Probleme + - Nutzerzufriedenheit stabil oder positiv + - Keine strategischen Bedenken + + sor_behandlung: "Nein (Selbst-Review ausreichend)" + + output: + - "Service-Definition-Update mit Review-Status" + - "Information an SPM" + + naechster_review: "Nächstes Quartal (Regelzyklus)" + + # --------------------------------------------------------------------------- + # IMPROVEMENT + # --------------------------------------------------------------------------- + + pfad_improvement: + + id: "IMPROVEMENT" + name: "Verbesserung" + + orientierung: | + Typische Konstellation: + - Eine oder mehrere Dimensionen Rot oder mehrfach Gelb + - Identifizierte Ursachen sind im Rahmen des Service lösbar + - Keine grundsätzliche Änderung des Service-Scopes erforderlich + - Verbesserung ist mit vorhandenen oder planbaren Ressourcen umsetzbar + + beispiele: + - "Wiederkehrende Incidents mit bekannter, behebbarer Ursache" + - "Performance-Probleme, die durch Optimierung lösbar sind" + - "Dokumentationslücken im Betrieb" + - "Schulungsbedarf bei Nutzern oder Support" + - "Monitoring-Erweiterung erforderlich" + + varianten: + + so_gefuehrt: + beschreibung: "Improvement liegt in SO-Kompetenz und -Ressourcen" + sor_behandlung: "Nein" + beispiel: "Dokumentation aktualisieren, Workaround etablieren" + + ressourcenrelevant: + beschreibung: "Improvement erfordert zusätzliche Ressourcen oder Abstimmung" + sor_behandlung: "Ja (SOR unter 'Operative Entscheidungen')" + beispiel: "Technische Optimierung mit Entwicklungsaufwand" + + output: + - "Maßnahmendefinition in der Service-Definition" + - "Ggf. SOR-Beschluss" + + naechster_review: "Nächstes Quartal (mit Wirksamkeitsprüfung)" + + # --------------------------------------------------------------------------- + # REDESIGN + # --------------------------------------------------------------------------- + + pfad_redesign: + + id: "REDESIGN" + name: "Neugestaltung" + + orientierung: | + Typische Konstellation: + - Mehrere Dimensionen Rot, ggf. über mehrere Quartale + - Ursachen liegen in der Service-Architektur, im Scope oder im Grundkonzept + - Bisherige Improvement-Maßnahmen waren nicht wirksam + - Änderung erfordert Projektcharakter (Ressourcen, Zeit, Governance) + + beispiele: + - "Technologie-Ablösung erforderlich (EOL, nicht mehr wartbar)" + - "Zielgruppe oder Funktionsumfang muss fundamental neu definiert werden" + - "Service passt nicht mehr zur strategischen Ausrichtung" + - "Integration mit anderen Services erfordert Neuarchitektur" + + sor_behandlung: "Ja (SOR unter 'Strategische Entscheidungen')" + + output: + - "SOR-Beschluss: Übergabe an DPM" + - "Demand für Neugestaltung wird erfasst" + - "Service bleibt in Betrieb bis Ablösung" + + naechster_review: "Weiterhin quartalsweise bis Ablösung" + + # --------------------------------------------------------------------------- + # RETIRE + # --------------------------------------------------------------------------- + + pfad_retire: + + id: "RETIRE" + name: "Stilllegung" + + orientierung: | + Typische Konstellation: + - Service wird kaum noch genutzt (Nutzungszahlen minimal) + - Betriebsaufwand steht in keinem Verhältnis zum Nutzen + - Funktionalität wird durch anderen Service abgedeckt + - Strategische Entscheidung zur Ablösung liegt vor + - Technologie ist nicht mehr supportfähig und Redesign unverhältnismäßig + + beispiele: + - "Legacy-System mit < 10 aktiven Nutzern" + - "Dopplung mit anderem Service nach Migration" + - "Lieferant kündigt Support, keine Alternative" + + sor_behandlung: "Ja (SOR unter 'Strategische Entscheidungen')" + + output: + - "SOR-Beschluss: Stilllegung" + - "Demand für Stilllegungsprojekt an DPM" + - "Kommunikationsplan für Nutzer" + + naechster_review: "Entfällt nach Stilllegung" + + # --------------------------------------------------------------------------- + # BEGRÜNDUNGSPFLICHT + # --------------------------------------------------------------------------- + + begruendungspflicht: + + wann: "Bei Abweichung von typischer Konstellation" + + form: "Kurze schriftliche Begründung im Review-Dokument (2-3 Sätze)" + + beispiele: + - situation: "Dimension Rot, aber Empfehlung CONTINUE" + begruendung: | + "Obwohl Dimension Betriebsstabilität Rot ist, empfehle ich CONTINUE, + weil die Ursache ein bekannter Lieferanten-Bug ist, der im nächsten + Release behoben wird (ETA: Q1). Kein Handlungsbedarf unsererseits." + + - situation: "Alle Dimensionen Grün, aber Empfehlung REDESIGN" + begruendung: | + "Trotz stabiler Bewertung empfehle ich REDESIGN, weil die zugrunde + liegende Technologie (Framework X) zum Jahresende EOL geht und + eine Migration ohnehin erforderlich ist." + +# ============================================================================= +# 5. SOR-GOVERNANCE FÜR SERVICE-REVIEW +# ============================================================================= + +sor_governance: + + governance_referenz: "GOV-SR-004" + + grundprinzip: | + Die SOR-Behandlung von Service-Reviews erfolgt differenziert nach + Handlungsempfehlung. Routine-Reviews (CONTINUE) binden keine Sitzungszeit. + Die SOR fokussiert auf Entscheidungen, die Governance erfordern. + + # --------------------------------------------------------------------------- + # BEHANDLUNGSKATEGORIEN + # --------------------------------------------------------------------------- + + behandlungskategorien: + + - kategorie: "Kenntnisnahme (kein SOR-Agenda-Punkt)" + + gilt_fuer: + - "CONTINUE" + - "IMPROVEMENT (SO-geführt, ressourcenneutral)" + + verfahren: | + SO dokumentiert in der Service-Definition, informiert SPM. + Keine SOR-Vorlage erforderlich. + + protokoll: "Nicht erforderlich" + + hinweis: | + SPM kann bei Auffälligkeiten im Portfolio (z.B. mehrere Services + mit gleicher Problemdimension) einen Service-Review auf die + SOR-Agenda setzen. + + - kategorie: "Operative Entscheidung" + + gilt_fuer: + - "IMPROVEMENT (ressourcenrelevant)" + + verfahren: | + SO reicht Review-Vorlage ein (Frist: 3 Arbeitstage vor Sitzung). + SOR behandelt unter Agenda-Block "Operative Entscheidungen". + + entscheidungsmodus: "Konsent (analog Gate-Entscheidungen)" + + entscheidungsoptionen: + - "Freigabe der Improvement-Maßnahmen" + - "Freigabe mit Auflagen" + - "Zurückweisung (mit Begründung)" + - "Eskalation an MB (bei Ressourcenkonflikt)" + + protokoll: "Kurze Dokumentation: Beschluss, ggf. Auflagen, Verantwortlicher" + + - kategorie: "Strategische Entscheidung" + + gilt_fuer: + - "REDESIGN" + - "RETIRE" + + verfahren: | + SO reicht Review-Vorlage ein (Frist: 3 Arbeitstage vor Sitzung). + SOR behandelt unter Agenda-Block "Strategische Entscheidungen". + + entscheidungsmodus: "Konsent" + + entscheidungsoptionen: + - "Freigabe: Übergabe an DPM" + - "Zurück an SO: Weitere Prüfung erforderlich" + - "Eskalation an MB: Strategische Tragweite" + + output_bei_freigabe: + redesign: "Demand an DPM (Klassifizierung: Neugestaltung)" + retire: "Demand an DPM (Stilllegungsprojekt)" + + protokoll: "Vollständige Dokumentation inkl. Begründung und nächste Schritte" + + # --------------------------------------------------------------------------- + # VORLAGE-ANFORDERUNGEN + # --------------------------------------------------------------------------- + + vorlage_anforderungen: + + name: "Service-Review-Vorlage für SOR" + + pflichtinhalte: + - feld: "Service-Bezeichnung und Version" + - feld: "Review-Zeitraum" + - feld: "Bewertung je Dimension (Ampel + Kurztext)" + - feld: "Handlungsempfehlung" + - feld: "Begründung der Empfehlung" + - feld: "Bei IMPROVEMENT: Maßnahmenvorschlag mit Ressourcenschätzung" + - feld: "Bei REDESIGN/RETIRE: Konsequenzen, Alternativen, Stakeholder-Impact" + + einreichungsfrist: "3 Arbeitstage vor SOR-Sitzung" + + einreichung_an: "SPM (koordiniert SOR-Agenda)" + + vollstaendigkeitspruefung: + verantwortlich: "SPM" + bei_unvollstaendigkeit: "Rückfrage an SO, ggf. Verschiebung auf nächste Sitzung" + + # --------------------------------------------------------------------------- + # INTEGRATION IN SOR-GESCHÄFTSORDNUNG + # --------------------------------------------------------------------------- + + integration_sor_go: + + hinweis: | + Die folgenden Elemente sind in die SOR-Geschäftsordnung zu integrieren, + sobald diese aus dem Placeholder-Status entwickelt wird. + + zu_integrierende_elemente: + - "Service-Review als Entscheidungstyp (neben Gate-Entscheidungen, Routing)" + - "Behandlungskategorien (Kenntnisnahme, Operativ, Strategisch)" + - "Vorlage-Anforderungen und Einreichungsfrist" + - "Entscheidungsmodus für Review-Entscheidungen" + +# ============================================================================= +# 6. IMPROVEMENT-STEUERUNG +# ============================================================================= + +improvement_steuerung: + + governance_referenz: "GOV-SR-005" + + grundprinzip: | + Im MVP wird Service Improvement über die Service-Definition gesteuert. + Der SO dokumentiert Maßnahmen und prüft deren Wirksamkeit im nächsten + Quartals-Review. Es gibt keine separate CI-Infrastruktur. + + # --------------------------------------------------------------------------- + # MVP-LÖSUNG + # --------------------------------------------------------------------------- + + mvp_loesung: + + massnahmen_dokumentation: + + ort: "Service-Definition → Abschnitt 'laufende_verbesserungen'" + + pflichtfelder: + - id: "massnahmen_id" + name: "ID" + beschreibung: "Eindeutige Kennung (z.B. IMP-[Service]-001)" + + - id: "beschreibung" + name: "Beschreibung" + beschreibung: "Kurzbeschreibung der Maßnahme (1-2 Sätze)" + + - id: "ziel" + name: "Ziel" + beschreibung: "Erwartetes Ergebnis / betroffene Dimension" + + - id: "verantwortlich" + name: "Verantwortlich" + beschreibung: "Wer setzt um? (Person oder Rolle)" + + - id: "termin" + name: "Zieltermin" + beschreibung: "Geplanter Abschluss" + + - id: "status" + name: "Status" + beschreibung: "Offen | In Arbeit | Abgeschlossen | Abgebrochen" + + optionale_felder: + - id: "aufwand" + name: "Aufwandsschätzung" + beschreibung: "PT oder Kostenschätzung (falls relevant)" + + - id: "abhaengigkeiten" + name: "Abhängigkeiten" + beschreibung: "Andere Maßnahmen, Services, Projekte" + + wirksamkeitspruefung: + + wann: "Im nächsten Quartals-Review" + + wie: | + SO bewertet: Hat sich die betroffene Dimension verbessert? + Ist das erwartete Ergebnis eingetreten? + + dokumentation: "Kurzkommentar in der Service-Definition bei der Maßnahme" + + bewertung: + - ergebnis: "Wirksam" + aktion: "Maßnahme wird als abgeschlossen markiert" + + - ergebnis: "Teilweise wirksam" + aktion: "Maßnahme bleibt offen oder wird erweitert" + + - ergebnis: "Nicht wirksam" + aktion: "Analyse der Ursache, neue Maßnahme oder Pfad-Wechsel (z.B. → REDESIGN)" + + - ergebnis: "Abgebrochen" + aktion: "Begründung dokumentieren" + + abschlusslogik: + + regelfall: | + Abgeschlossene Maßnahmen bleiben in der Service-Definition sichtbar (Historie), + werden aber nicht mehr aktiv getrackt. + + archivierung: | + Nach 4 Quartalen können abgeschlossene Maßnahmen in einen + Archiv-Abschnitt verschoben werden (optional). + + # --------------------------------------------------------------------------- + # POST-MVP-ERWEITERUNG + # --------------------------------------------------------------------------- + + post_mvp_erweiterung: + + status: "Placeholder für zukünftige Entwicklung" + + beschreibung: | + Nach MVP-Stabilisierung kann eine dedizierte Continual Improvement + Practice entwickelt werden, die übergreifendes Maßnahmen-Tracking, + Lessons Learned und ein zentrales Improvement-Register umfasst. + + moegliche_elemente: + - "Zentrales Improvement-Register (CIR) mit Service-Verknüpfung" + - "Standardisierter Improvement-Workflow" + - "Aggregierte Auswertung über alle Services" + - "Integration mit Problem Management" + + migration: + von: "Service-Definition-basiertes Tracking" + nach: "Zentrales CIR mit bidirektionaler Verlinkung" + + voraussetzung: | + Entscheidung über Tooling und Verantwortlichkeit für CI-Practice + erforderlich. Derzeit kein dedizierter CI-Practice-Owner definiert. + + # --------------------------------------------------------------------------- + # ABGRENZUNG ZU SR_04 + # --------------------------------------------------------------------------- + + abgrenzung_sr_04: + + klarstellung: | + Die Aktivität sr_04 ("Service Improvement") im Workshop-Blueprint + beschreibt den Entscheidungspfad und die initiale Maßnahmenplanung. + Die laufende Steuerung und Wirksamkeitsprüfung erfolgt über diesen + Mechanismus (Steckbrief-Tracking + Folge-Review). + + sr_04_umfasst: + - "Entscheidung für Improvement-Pfad" + - "Initiale Definition der Maßnahmen" + - "Abstimmung mit SOR (falls ressourcenrelevant)" + + dieses_konzept_ergaenzt: + - "Strukturierte Dokumentation der Maßnahmen in der Service-Definition" + - "Wirksamkeitsprüfung im Folge-Review" + - "Abschlusslogik" + +# ============================================================================= +# 7. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + # --------------------------------------------------------------------------- + # INPUT-SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + input: + + - quelle: "Service Betrieb" + was: "Betriebsdaten, Monitoring-Informationen" + artefakt: "Service-Qualitätsbericht (informell)" + frequenz: "Quartalsweise oder laufend" + hinweis: | + Der 'Service-Qualitätsbericht' ist kein formalisiertes Artefakt im MVP. + Der SO nutzt verfügbare Daten und Einschätzungen des Betriebsteams. + + - quelle: "Service Support" + was: "Support-Statistik, Problem Records" + artefakt: "Incident-/Problem-Auswertung" + frequenz: "Quartalsweise" + + - quelle: "SHM (Stakeholder Management)" + was: "Stakeholder-Feedback, VoC-Signale" + artefakt: "VoC-Erkenntnisse (Cluster D2: Service-Qualität)" + frequenz: "Quartalsweise (E2-Review)" + referenz: "shm_voice-of-customer.yaml" + + - quelle: "SLM (Service Level Management)" + was: "SLA-Erfüllungsgrad" + artefakt: "SLA-Bericht (falls vorhanden)" + frequenz: "Abhängig von Service-Kategorie" + + # --------------------------------------------------------------------------- + # OUTPUT-SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + output: + + - ziel: "SPM (Service-Portfolio-Manager)" + was: "Review-Ergebnis aller Services" + artefakt: "Aktualisierte Service-Definitionen" + frequenz: "Quartalsweise" + zweck: "Portfolio-Übersicht, Aggregation für Portfolio-Review" + + - ziel: "SOR (bei Handlungsbedarf)" + was: "Review-Vorlage" + artefakt: "Service-Review-Vorlage" + frequenz: "Anlassbezogen" + bedingung: "Bei IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE" + + - ziel: "DPM (Demand Portfolio Management)" + was: "Demand für Neugestaltung oder Stilllegung" + artefakt: "Demand mit Klassifizierung" + frequenz: "Anlassbezogen" + bedingung: "Bei REDESIGN oder RETIRE (nach SOR-Freigabe)" + + - ziel: "Service Betrieb" + was: "Freigegebene Improvement-Maßnahmen" + artefakt: "Maßnahmenliste in der Service-Definition" + frequenz: "Nach Review" + bedingung: "Bei IMPROVEMENT" + + # --------------------------------------------------------------------------- + # SYNCHRONISATION MIT ANDEREN REVIEWS + # --------------------------------------------------------------------------- + + synchronisation: + + dpm_portfolio_review: + beschreibung: | + Der Service-Review liefert aggregierten Input für den quartalsweisen + DPM-Portfolio-Review. SPM bringt konsolidierte Service-Erkenntnisse ein. + + sequenz: | + Service-Reviews (erste zwei Wochen nach Quartalsende) + → SPM-Aggregation + → DPM-Portfolio-Review (ca. T+10 bis T+14) + + shm_e2_review: + beschreibung: | + SHM liefert VoC-Erkenntnisse aus E2 (Quartals-Review) als Input + für die Dimension "Nutzerzufriedenheit". + + sequenz: | + SHM E2-Review + → VoC-Erkenntnisse verfügbar + → Service-Review nutzt D2-Cluster + + portfolio_review_spm: + beschreibung: | + Das Service-Portfolio-Review (strategisch) nutzt aggregierte + Ergebnisse der Einzel-Service-Reviews. + + referenz: "spm_portfolio-review-konzept.yaml" + +# ============================================================================= +# 8. ROLLEN UND VERANTWORTLICHKEITEN +# ============================================================================= + +rollen: + + service_owner: + kurzbezeichnung: "SO" + verantwortung: + - "Durchführung des quartalsweisen Selbst-Reviews" + - "Bewertung der 4 Dimensionen" + - "Ableitung der Handlungsempfehlung" + - "Dokumentation in der Service-Definition" + - "Information an SPM" + - "Einreichung der SOR-Vorlage (bei Bedarf)" + - "Umsetzung von Improvement-Maßnahmen" + raci: "A/R für Review-Durchführung" + + service_portfolio_manager: + kurzbezeichnung: "SPM" + verantwortung: + - "Erhalt und Sichtung aller Review-Berichte" + - "Aggregation für Portfolio-Perspektive" + - "Koordination der SOR-Agenda (Review-Vorlagen)" + - "Vollständigkeitsprüfung der SOR-Vorlagen" + - "Identifikation portfolio-übergreifender Muster" + raci: "C bei Review, A für Portfolio-Aggregation" + + sor: + kurzbezeichnung: "SOR" + typ: "Gremium" + verantwortung: + - "Entscheidung bei IMPROVEMENT (ressourcenrelevant)" + - "Entscheidung bei REDESIGN und RETIRE" + - "Freigabe der Übergabe an DPM" + raci: "A für Governance-Entscheidungen" + + betriebsteam: + verantwortung: + - "Lieferung von Betriebsdaten und Einschätzungen" + - "Umsetzung technischer Improvement-Maßnahmen" + raci: "C/I bei Review, R bei Umsetzung" + + problem_manager: + verantwortung: + - "Input zu wiederkehrenden Problemen" + - "Root-Cause-Analyse bei Bedarf" + raci: "C bei Review (für D2)" + +# ============================================================================= +# 9. OFFENE PUNKTE UND POST-MVP +# ============================================================================= + +offene_punkte: + + im_mvp_nicht_adressiert: + + - punkt: "Externer SLA-Review mit Kunden" + beschreibung: | + GOV-003 definiert eine Zwei-Stufen-Logik (interner Review → externer + SLA-Review). Der externe Review ist nicht Teil dieses Konzepts. + status: "Zu modellieren in SLM-Practice" + referenz: "spm_practice_service-level-management.yaml" + + - punkt: "Service-Qualitätsbericht als formales Artefakt" + beschreibung: | + Der Input 'Service-Qualitätsbericht' ist nicht standardisiert. + Im MVP nutzt der SO verfügbare Daten informell. + status: "Optional für Post-MVP" + + - punkt: "Quantitative KPI-Integration" + beschreibung: | + Das Bewertungsschema ist qualitativ. Wenn Monitoring-Daten + verfügbar werden, können sie als Indikatoren einfließen. + status: "Erweiterbar bei Bedarf" + + - punkt: "Continual Improvement Practice" + beschreibung: | + Eine übergreifende CI-Practice mit zentralem Improvement-Register + existiert nicht. Das MVP nutzt Steckbrief-Tracking. + status: "Konzept-Placeholder für Post-MVP" + + validierungsbedarf: + + - punkt: "Bewertungsdimensionen" + beschreibung: "Die 4 Dimensionen sollten mit SOs validiert werden" + methode: "Workshop oder Pilotierung" + + - punkt: "Review-Aufwand" + beschreibung: "Der geschätzte Aufwand (30-60 Min.) muss verifiziert werden" + methode: "Pilotierung mit 2-3 Services" + + - punkt: "SPM-Informationspflicht" + beschreibung: "Praktikabilität des regelmäßigen Reportings prüfen" + methode: "Pilotierung" + +# ============================================================================= +# 10. GOVERNANCE-ENTSCHEIDUNGEN (ZUSAMMENFASSUNG) +# ============================================================================= + +governance_entscheidungen_log: + + - id: "GOV-SR-001" + datum: "2025-12-17" + frage: "Wie bewertet der SO den Service-Zustand?" + entscheidung: | + 4-Dimensionen-Modell (Leistungserbringung, Betriebsstabilität, + Nutzerzufriedenheit, Zukunftsfähigkeit) mit qualitativer + Ampelbewertung (Grün/Gelb/Rot). Keine mathematische Aggregation. + begruendung: | + Strukturelle Analogie zu SHM (VoC-Cluster), qualitative Bewertung + passt zur verfügbaren Datenbasis und Verwaltungskultur. + confidence: "80%" + status: "final" + + - id: "GOV-SR-002" + datum: "2025-12-17" + frage: "In welchem Rhythmus findet der Review statt?" + entscheidung: | + Quartalsweiser SO-Selbst-Review. SPM erhält regelmäßig alle + Review-Berichte. SOR-Einbeziehung nur bei Auffälligkeiten + (Rot-Dimension oder IMPROVEMENT/REDESIGN/RETIRE). + begruendung: | + Skaliert mit Portfolio-Größe, erhält SO-Eigenverantwortung, + SPM hat Portfolio-Übersicht, SOR fokussiert auf Ausnahmen. + confidence: "85%" + status: "final" + + - id: "GOV-SR-003" + datum: "2025-12-17" + frage: "Gibt es objektive Schwellenwerte für Eskalation?" + entscheidung: | + Orientierungskriterien mit Urteilsvorbehalt. Keine Automatismen. + SO begründet bei Abweichung von typischer Konstellation. + begruendung: | + Konsistent mit SHM-Logik, vermeidet Schein-Objektivität, + erhält Flexibilität für Service-spezifische Kontexte. + confidence: "75%" + status: "final" + + - id: "GOV-SR-004" + datum: "2025-12-17" + frage: "Wie läuft die SOR-Behandlung von Reviews?" + entscheidung: | + Differenziert nach Empfehlung: CONTINUE und SO-geführtes + IMPROVEMENT ohne SOR-Behandlung. Ressourcenrelevantes IMPROVEMENT + als operative Entscheidung. REDESIGN/RETIRE als strategische + Entscheidung. + begruendung: | + Fokussiert SOR-Zeit auf Governance-Entscheidungen, + Subsidiaritätsprinzip für SO-Kompetenz. + confidence: "80%" + status: "final" + + - id: "GOV-SR-005" + datum: "2025-12-17" + frage: "Wie wird die Wirksamkeit von Improvements nachgehalten?" + entscheidung: | + MVP: Steckbrief-Tracking. Maßnahmen werden im Service-Steckbrief + dokumentiert, Wirksamkeitsprüfung im Folge-Review. Keine + separate CI-Infrastruktur. + begruendung: | + Minimal Viable, kein neues Tooling erforderlich, erweiterbar + bei späterer CI-Practice-Etablierung. + confidence: "70%" + status: "final" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.1" + datum: "2026-01-31" + aenderung: | + - Alle Referenzen von 'Service-Steckbrief' auf 'Service-Definition' geändert + - Begründung: Review- und Improvement-Informationen sind interne Steuerungsdaten + und gehören in die Service-Definition (Single Source of Truth), nicht in den + kundenorientierten Service-Steckbrief + - Betroffene Stellen: regelzyklus, spm_informationspflicht, entscheidungspfade, + sor_governance, improvement_steuerung, schnittstellen, rollen + autor: "DIGITOM-Projekt" + referenz: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht" + + - version: "1.0" + datum: "2025-12-17" + aenderung: "Initiale Erstellung basierend auf Klärungsbereichen KB1-KB5" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-transition.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-transition.yaml index 9496c3f..6dbbc0d 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-transition.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-transition.yaml @@ -1,1085 +1,1085 @@ -# ============================================================================= -# RAHMENKONZEPT: SERVICE TRANSITION (K-TR) -# ============================================================================= -# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/ -# Dateiname: spm_konzept_service-transition.yaml -# ============================================================================= - -metadata: - id: "K-TR" - name: "Rahmenkonzept Service Transition" - version: "3.0" - status: "draft" - erstellt: "2025-12-15" - aktualisiert: "2026-02-18" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "konzept" - - beschreibung: | - Rahmenkonzept für die Transition-Phase im DIGITOM Service Lifecycle. - Definiert Governance-Logik, Quality Gates, Entscheidungsprinzipien und das - Early Life Support Konzept für die Überführung von Services in den Betrieb. - - aenderungen: - - version: "3.0" - datum: "2026-02-18" - beschreibung: | - Gate 1 in Transition-Phase verschoben (neue ID: tr_01, ehemals ds_05). - Alle Transition-Aktivitäts-IDs um +1 verschoben (tr_02-tr_12). - Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist nun tr_12 (ehemals tr_11). - Gate 1 ist nun im Scope der Transition, nicht mehr out_of_scope. - Aktivitäts-Referenzen und Schnittstellen aktualisiert. - autor: "DIGITOM-Projekt" - - - version: "2.0" - datum: "2026-01-30" - beschreibung: | - Anpassung an 5-Phasen-Modell (Version 3.0 des Service-Lifecycle-Blueprint): - - Phasennamen englisch (Design, Transition, Operation, Support, Review) - - 3-Gate-Modell: Gate 1 (ds_05), Gate 2 (tr_08), Gate 3 (tr_11) - - ELS verschoben nach Operation (op_01) - - Alle Aktivitäts-ID-Referenzen aktualisiert - - Schnittstellen-Referenzen aktualisiert - autor: "DIGITOM-Projekt" - - - version: "1.0" - datum: "2025-12-17" - beschreibung: | - Vollständige Konsolidierung aus AP-01 bis AP-07. - Enthält: Gate-Modell, ELS-Konzept, Rollback-Szenarien, Artefakte, - Begriffserklärungen, Governance-Referenzen, MVP-Annahmen. - autor: "DIGITOM-Projekt" - -# ============================================================================= -# 1. EINORDNUNG UND ABGRENZUNG -# ============================================================================= - -einordnung: - - position_im_lifecycle: - vorgaenger: "Design" - nachfolger: "Operation / Support" - - beschreibung: | - Die Transition-Phase bildet die Brücke zwischen der Design-Phase - und dem laufenden Betrieb. Sie umfasst Build/Konfiguration, Test, - Deployment und Go-Live-Freigabe. Nach Go-Live beginnt die Operation-Phase - mit Early Life Support (ELS). - - abgrenzung_blueprint_konzept: - - blueprint: - dokument: "service-lifecycle_transition.yaml" - inhalt: "Aktivitäten (tr_01–tr_12), RACI-Zuordnungen, Schnittstellen" - charakter: "Operativer Ablauf – das WAS und WER" - - konzept: - dokument: "spm_konzept_service-transition.yaml (dieses Dokument)" - inhalt: "Governance, Prinzipien, Entscheidungslogik, Quality Gates" - charakter: "Steuerungslogik – das WARUM und WIE entscheiden" - - referenzen: - blueprint_design: "02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml" - blueprint_transition: "02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml" - blueprint_operation: "02_spm_service-lifecycle-blueprint/service-lifecycle_operation.yaml" - schema_transition_steckbrief: "06_Informationsmodell/spm_schema_transition-steckbrief.yaml" - sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" - rolle_service_owner: "04_rollen/rolle_service-owner.yaml" - -# ============================================================================= -# 2. ZWECK UND SCOPE -# ============================================================================= - -zweck_und_scope: - - zweck: | - Die Transition-Phase gewährleistet, dass neu entwickelte oder wesentlich - geänderte Services kontrolliert in den produktiven Betrieb überführt werden. - Sie schützt das Service-Portfolio vor unreifen Services und stellt die - Betriebsfähigkeit sicher. - - scope: - in_scope: - - "Neue Services aus der Design-Phase" - - "Wesentliche Änderungen an bestehenden Services" - - "Entry-Entscheidung (Gate 1: Build or Configure)" - - "Build/Konfiguration, Test, Deployment" - - "Freigabeentscheidungen (Gate 1, Gate 2 und Gate 3)" - - out_of_scope: - - "Service-Design (Design-Phase)" - - "Minor Changes (werden über Change Enablement gesteuert)" - - "Early Life Support (Operation-Phase, op_01)" - - "Operative Betriebsführung (Operation-Phase)" - - "Incident-/Request-Bearbeitung (Support-Phase)" - - erfolgskriterien: - - "Service ist nach Transition stabil betreibbar" - - "Betriebsteam und Support sind handlungsfähig" - - "Dokumentation ist vollständig und aktuell" - - "SLA/SLO sind vereinbart und messbar" - -# ============================================================================= -# 3. LEITPRINZIPIEN -# ============================================================================= - -leitprinzipien: - - # --------------------------------------------------------------------------- - # P1: INFORMED JUDGMENT - # --------------------------------------------------------------------------- - informed_judgment: - governance_referenz: "GOV-TR-013" - - beschreibung: | - Gate-Entscheidungen folgen dem Prinzip der informierten Gesamtbewertung. - Der Gate-Keeper trifft eine Entscheidung auf Basis definierter - Prüfdimensionen. Die Dimensionen geben die Richtung vor, ohne jeden - Einzelfall vorab zu regeln. - - begruendung: | - Für den MVP ist ein prinzipienbasierter Ansatz angemessen. Detaillierte - Checklisten erzeugen Governance-Overhead ohne nachgewiesenen Mehrwert. - Die operative Erfahrung wird zeigen, wo Präzisierung nötig ist. - - # --------------------------------------------------------------------------- - # P2: SERVICE OWNER ACCOUNTABILITY - # --------------------------------------------------------------------------- - so_accountability: - - beschreibung: | - Der Service Owner bleibt während der gesamten Transition accountable - für den Service-Erfolg. Diese Verantwortung beginnt bei Gate 1 (Transition Entry) - und endet erst mit dem erfolgreichen ELS-Exit (Operation). - - implikationen: - - "SO ist Gate-Keeper bei Gate 2 (Entry-Prüfung)" - - "SO trägt Verantwortung für Mängelbeseitigung bei Zurückweisung" - - "SO entscheidet über ELS-Exit (mit Informationspflicht)" - - "SO kann Service-Stopp während ELS initiieren" - - # --------------------------------------------------------------------------- - # P3: QUALITATIVE BEWERTUNG - # --------------------------------------------------------------------------- - qualitative_bewertung: - governance_referenz: "GOV-TR-014" - - beschreibung: | - Prüfdimensionen werden qualitativ bewertet. Der Nachweis erfolgt durch - Zusicherung des Verantwortlichen, nicht durch mechanische Checklisten. - - validierungstiefe: | - "Hinreichende Plausibilität" – Der Gate-Keeper muss überzeugt sein, - dass die Kriterien erfüllt sind. Er muss nicht jeden Einzelnachweis - selbst prüfen. - - # --------------------------------------------------------------------------- - # P4: ROLLBACK ALS QUALITÄTSINSTRUMENT - # --------------------------------------------------------------------------- - rollback_als_qualitaetsinstrument: - governance_referenz: "GOV-TR-028" - - beschreibung: | - Rollback und Abbruch sind legitime Qualitätssicherungsinstrumente, - keine Schuldzuweisungen. Ein frühzeitiger Abbruch eines nicht - funktionierenden Service-Vorhabens ist besser als ein dysfunktionaler - Service im Portfolio. - -# ============================================================================= -# 4. QUALITY GATES -# ============================================================================= - -quality_gates: - - # --------------------------------------------------------------------------- - # 4.0 GATE-MODELL ÜBERSICHT - # --------------------------------------------------------------------------- - modell: - governance_referenz: "GOV-TR-010" - - anzahl_gates: 3 - - struktur: | - Design → Transition: [Gate 1] → Build → [Gate 2] → Deploy - → [Gate 3] → Operation (ELS) → Normalbetrieb - - gate_definition: | - Ein Gate ist ein formaler Entscheidungspunkt im Lifecycle, der kombiniert: - - Prüfkriterien (Was muss erfüllt sein?) - - Gate-Keeper (Wer entscheidet?) - - Entscheidungsoptionen (Welche Ergebnisse sind möglich?) - - Dokumentation (Wie wird die Entscheidung festgehalten?) - - gate_uebersicht: - - gate: "Gate 1" - id: "tr_01" - position: "Anfang Transition (Entry-Gate)" - gate_keeper: "SOR" - zweck: "Build or Configure Decision" - - - gate: "Gate 2" - id: "tr_09" - position: "Mitte Transition (nach Build)" - gate_keeper: "SO" - zweck: "Entry-Prüfung nach Build" - - - gate: "Gate 3" - id: "tr_12" - position: "Ende Transition" - gate_keeper: "SOR" - zweck: "Go-Live-Freigabe" - - entscheidungsoptionen_standard: - - option: "freigabe" - beschreibung: "Weiter zum nächsten Schritt" - - option: "freigabe_mit_auflagen" - beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden" - - option: "zurueck" - beschreibung: "Zurück an vorherige Phase zur Nachbesserung" - - option: "ablehnung" - beschreibung: "Endgültige Ablehnung des Service-Vorhabens" - - # --------------------------------------------------------------------------- - # 4.1 GATE 1: BUILD OR CONFIGURE DECISION (tr_01) - # --------------------------------------------------------------------------- - gate_1_build_or_configure: - governance_referenz: "GOV-TR-011" - - aktivitaets_id: "tr_01" - gate_keeper: "SOR (Service Owner Runde)" - phase: "Transition" - - zweck: | - Entscheidung, ob die Service-Komponenten entwickelt oder nur - konfiguriert werden müssen. Prüfung der Design-Vollständigkeit - und Budget-/Ressourcenfreigabe für die Transition-Phase. - - trigger: "Abschluss der Design-Aktivitäten (ds_01-ds_04)" - - pruef_dimensionen: - - - id: "G1-DIM-01" - name: "Design-Vollständigkeit" - beschreibung: "Ist das Service Design Document vollständig?" - showstopper: true - nachweisform: "SO-Zusicherung" - - - id: "G1-DIM-02" - name: "Architektur-Freigabe" - beschreibung: "Liegt eine Architektur-Bewertung vor?" - showstopper: true - nachweisform: "Architektur-Stellungnahme" - - - id: "G1-DIM-03" - name: "Budget-Verfügbarkeit" - beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?" - showstopper: true - nachweisform: "Budget-Bestätigung" - - entscheidungspfade: - - id: "entwicklung" - name: "Entwicklung" - beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich" - folgeaktivitaet: "tr_02" - - - id: "konfiguration" - name: "Konfiguration" - beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst" - folgeaktivitaet: "tr_05" - hinweis: "Überspringt Build-Aktivitäten (tr_02-tr_04)" - - governance_verfahren: - verfahren: "SOR-Konsent-Verfahren" - dokumentation: "SOR-Protokoll, Transition-Steckbrief (Abschnitt: gate_1)" - - # --------------------------------------------------------------------------- - # 4.2 GATE 2: ENTRY-PRÜFUNG NACH BUILD (tr_09) - # --------------------------------------------------------------------------- - gate_2_entry_pruefung: - governance_referenz: "GOV-TR-012" - - aktivitaets_id: "tr_09" - gate_keeper: "Service Owner (SO)" - phase: "Transition" - - zweck: | - Validierung der Übergabefähigkeit nach Abschluss des Builds. - Sicherstellung, dass grundlegende Voraussetzungen für die - Deploy-Aktivitäten erfüllt sind. - - trigger: "Formale Übergabe nach Build (tr_08)" - - voraussetzung: "Positives Gate 1 (tr_01)" - - pruef_dimensionen: - - - id: "G2-DIM-01" - name: "Übergabe-Vollständigkeit" - beschreibung: "Sind alle erwarteten Artefakte aus dem Build vorhanden?" - showstopper: true - nachweisform: "SO-Zusicherung basierend auf Übergabeprotokoll" - - - id: "G2-DIM-02" - name: "Abnahme-Status" - beschreibung: "Liegt eine Abnahme durch den Auftraggeber vor?" - showstopper: true - nachweisform: "Referenz auf Abnahmeprotokoll oder Bestätigung" - - - id: "G2-DIM-03" - name: "Ressourcen-Outlook" - beschreibung: "Sind Betrieb und Support prinzipiell vorbereitet?" - showstopper: false - nachweisform: "SO-Einschätzung, ggf. Rücksprache mit Ops/Support Manager" - - entscheidungsoptionen: - - "freigabe" - - "freigabe_mit_auflagen" - - "zurueck_an_build" - - "ablehnung" - - governance_verfahren: - governance_referenz: "GOV-TR-015" - - verfahren: "SO-Einzelentscheidung" - - beschreibung: | - Gate 2 ist eine operative Entscheidung des Service Owners. - Keine Gremienentscheidung erforderlich. - - dokumentation: "Transition-Steckbrief (Abschnitt: gate_2)" - - bei_unklarheit: - eskalation: "SO kann SPM zur Beratung hinzuziehen" - keine_pflicht: "Eskalation ist Option, keine Voraussetzung" - - pilot_entscheidung: - governance_referenz: "GOV-TR-012" - - in_gate_2: true - - beschreibung: | - Bei Gate 2 entscheidet der SO, ob ein Pilot erforderlich ist. - Die Entscheidung basiert auf Risikobewertung und Service-Komplexität. - - trigger_kriterien: - - "Hohe technische Komplexität" - - "Große Nutzerbasis" - - "Kritische Geschäftsprozesse betroffen" - - "Neuartige Technologie oder Integration" - - pilot_scope_festlegung: | - Falls Pilot erforderlich: SO definiert Pilotgruppe, Dauer und - Erfolgskriterien. Dokumentation im Transition-Steckbrief. - - output_bei_freigabe: - - "Transition-Steckbrief aktualisiert mit Gate-2-Dokumentation" - - "Pilot-Entscheidung dokumentiert" - - "Ggf. Auflagen dokumentiert" - - # --------------------------------------------------------------------------- - # 4.3 PILOT-PHASE (OPTIONAL) - # --------------------------------------------------------------------------- - pilot_phase: - governance_referenz: "GOV-TR-012" - - status: "Optional – Entscheidung bei Gate 2" - - zweck: | - Validierung des Services unter realen Bedingungen mit begrenzter - Nutzergruppe vor dem vollständigen Go-Live. - - kein_eigenstaendiges_gate: | - Der Pilot ist keine separate Gate-Entscheidung, sondern ein - optionaler Schritt zwischen Gate 2 und Gate 3. Die Pilot-Ergebnisse - fließen in die Gate-3-Prüfung ein. - - durchfuehrung: - verantwortlich: "SO" - unterstuetzung: "Betriebsteam, Support-Team" - - aktivitaeten: - - "Pilotgruppe informieren und onboarden" - - "Service für Pilotgruppe aktivieren" - - "Feedback sammeln und auswerten" - - "Technische Stabilität monitoren" - - "Ergebnisse dokumentieren" - - pilot_ergebnis: - dokumentation: "Transition-Steckbrief (Abschnitt: pilot)" - - moegliche_ergebnisse: - - ergebnis: "erfolgreich" - folge: "Weiter zu Gate 3" - - ergebnis: "erfolgreich_mit_anpassungen" - folge: "Anpassungen durchführen, dann Gate 3" - - ergebnis: "gescheitert" - folge: "Zurück an Build oder Design" - - # --------------------------------------------------------------------------- - # 4.4 GATE 3: GO-LIVE-FREIGABE (tr_12) - # --------------------------------------------------------------------------- - gate_3_go_live_freigabe: - governance_referenz: "GOV-TR-016" - - aktivitaets_id: "tr_12" - gate_keeper: "SOR (Service Owner Runde)" - phase: "Transition" - - zweck: | - Portfolio-Freigabe und formale Aktivierung des Services. - Prüfung der Betriebsreife aus Portfolio-Perspektive. - - trigger: "Antrag des SO nach Abschluss der Deploy-Aktivitäten (tr_10, tr_11)" - - voraussetzung: "Positives Gate 2 (tr_09), ggf. erfolgreiches Pilot" - - pruef_dimensionen: - - - id: "G3-DIM-01" - name: "Portfolio-Konsistenz" - beschreibung: "Passt der Service ins Portfolio? Strategische Ausrichtung?" - showstopper: true - nachweisform: "SPM-Stellungnahme" - - - id: "G3-DIM-02" - name: "Betriebsreife" - beschreibung: "Bestätigt SO die Readiness für den Produktivbetrieb?" - showstopper: true - nachweisform: "SO-Bestätigung im Transition-Steckbrief" - - - id: "G3-DIM-03" - name: "Support-Bereitschaft" - beschreibung: "Ist das Support-Team vorbereitet und handlungsfähig?" - showstopper: true - nachweisform: "Support Manager Bestätigung" - - - id: "G3-DIM-04" - name: "SLA/SLO-Vereinbarung" - beschreibung: "Liegen abgestimmte Service Levels vor?" - showstopper: false - nachweisform: "Verweis auf SLM-Artefakte" - - - id: "G3-DIM-05" - name: "Auflagen-Erfüllung" - beschreibung: "Sind alle Auflagen aus Gate 1 und Gate 2 erfüllt?" - showstopper: true - bedingung: "Nur wenn Auflagen existieren" - nachweisform: "SO-Bestätigung mit Nachweisreferenzen" - - entscheidungsoptionen: - - "go_live" - - "go_live_mit_auflagen" - - "zurueck_an_transition" - - "ablehnung" - - governance_verfahren: - governance_referenz: "GOV-TR-016" - - verfahren: "Konsent-Verfahren" - - beschreibung: | - Die SOR entscheidet nach dem Konsent-Prinzip: Ein Beschluss gilt als - angenommen, wenn kein anwesendes stimmberechtigtes Mitglied einen - schwerwiegenden, begründeten Einwand erhebt. - - bei_einwand: - folge: "Vertagung" - verantwortung: "SO muss Vorlage überarbeiten" - frist: "Nächste reguläre SOR-Sitzung" - - bei_erneutem_einwand: - folge: "SOR kann eskalieren oder ablehnen" - eskalationsziel: "Mission Board" - eskalation_ist: "Option, keine Pflicht" - - dokumentation: "SOR-Protokoll (referenziert im Transition-Steckbrief)" - - vorbereitungs_governance: - governance_referenz: "GOV-TR-017" - - vorlage_dokument: "Transition-Steckbrief" - - verantwortlich: "SO erstellt und reicht ein" - - einreichungsfrist: "3 Arbeitstage vor SOR-Sitzung" - - bei_verspaetung: "Verschiebung auf nächste SOR-Sitzung" - - vollstaendigkeitspruefung: - verantwortlich: "SPM" - zeitpunkt: "Bei Einreichung" - bei_unvollstaendigkeit: "Rückfrage an SO, ggf. Verschiebung" - - output_bei_freigabe: - - "SOR-Protokoll mit Go-Live-Beschluss" - - "Aufnahme ins Service-Portfolio" - - "Aktivierung des Katalog-Eintrags" - - "Formale SO-Bestätigung durch SOR" - - "Transition-Steckbrief (Abschnitt: gate_3) aktualisiert" - - "Übergang zu Operation-Phase (op_01: Early Life Support)" - -# ============================================================================= -# 5. ELS-KONZEPT (EARLY LIFE SUPPORT) -# ============================================================================= - -els_konzept: - - hinweis_phasen_zuordnung: | - WICHTIG: Early Life Support (ELS) ist seit Version 3.0 des Service-Lifecycle- - Blueprint der Operation-Phase zugeordnet (op_01), nicht mehr der Transition-Phase. - Der Service ist nach Gate 3 produktiv im Betrieb, ELS ist Betrieb mit erhöhter - Aufmerksamkeit. - - # --------------------------------------------------------------------------- - # 5.1 DEFINITION UND ZWECK - # --------------------------------------------------------------------------- - definition: - - aktivitaets_id: "op_01" - phase: "Operation" - - beschreibung: | - Early Life Support (ELS) ist die Phase erhöhter Aufmerksamkeit - unmittelbar nach dem Go-Live. Der Service ist produktiv, wird aber - intensiver beobachtet und betreut als im Normalbetrieb. - - zweck: - - "Frühzeitige Erkennung von Problemen im Produktivbetrieb" - - "Schnelle Reaktion auf unerwartete Situationen" - - "Geordneter Wissenstransfer vom Projekt zum Betrieb" - - "Validierung der Betriebsfähigkeit unter realen Bedingungen" - - # --------------------------------------------------------------------------- - # 5.2 DAUER-PARAMETER - # --------------------------------------------------------------------------- - dauer_parameter: - governance_referenz: "GOV-TR-018" - - modell: "Hybrid-Korridor" - - beschreibung: | - Zeitlicher Rahmen mit zustandsbasierter Exit-Entscheidung. - Innerhalb des Korridors entscheidet der SO basierend auf - den Exit-Kriterien. - - parameter: - - - name: "Mindestdauer" - wert: "2 Wochen" - verbindlichkeit: "verbindlich" - begruendung: "Minimale Beobachtungszeit für belastbare Aussage" - - - name: "Regeldauer" - wert: "4 Wochen" - verbindlichkeit: "Orientierung" - begruendung: "Erfahrungswert für typische Stabilisierung" - - - name: "Maximaldauer" - wert: "8 Wochen" - verbindlichkeit: "Eskalations-Trigger" - begruendung: "Überschreitung signalisiert Problem" - - mvp_annahme: | - Die konkreten Zeitwerte (2/4/8 Wochen) sind MVP-Annahmen und - müssen in der operativen Erprobung validiert werden. - - # --------------------------------------------------------------------------- - # 5.3 VERANTWORTLICHKEITEN - # --------------------------------------------------------------------------- - verantwortlichkeiten: - - service_owner: - rolle: "Accountable" - aufgaben: - - "Gesamtverantwortung für ELS-Erfolg" - - "Entscheidung über ELS-Exit" - - "Eskalation bei kritischen Störungen" - - "Dokumentation im Transition-Steckbrief" - - betriebsteam: - rolle: "Responsible (operativ)" - aufgaben: - - "Monitoring und Beobachtung" - - "Erste Anlaufstelle bei Störungen" - - "Technische Stabilisierung" - - support_team: - rolle: "Responsible (Nutzer-Support)" - aufgaben: - - "Bearbeitung von Incidents und Requests" - - "Feedback-Sammlung von Nutzern" - - "Eskalation bei Häufungen" - - projekt_verfuegbarkeit: - governance_referenz: "GOV-TR-019" - - modell: "Gestaffelte Übergabe" - - phasen: - - phase: "Woche 1-2" - verfuegbarkeit: "Verpflichtend" - reaktionszeit: "4 Stunden" - beschreibung: "Projekt-Team steht für Rückfragen bereit" - - - phase: "Ab Woche 3" - verfuegbarkeit: "Auf Abruf" - reaktionszeit: "2 Arbeitstage" - beschreibung: "Projekt-Team kann bei Bedarf hinzugezogen werden" - - projekt_exit: "Frühestens nach Mindestdauer (2 Wochen)" - - nachbetreuung: "Auf Abruf für 4 Wochen nach Projekt-Exit" - - # --------------------------------------------------------------------------- - # 5.4 EXIT-KRITERIEN - # --------------------------------------------------------------------------- - exit_kriterien: - governance_referenz: "GOV-TR-020" - - entscheidungslogik: | - SO prüft alle drei Kriterien. Alle müssen erfüllt sein. - Bei Grenzfällen dokumentiert SO seine Einschätzung in der - Exit-Begründung im Transition-Steckbrief. - - kriterien: - - - id: "EXIT-01" - name: "Stabilität" - beschreibung: "Keine kritischen Störungen in den letzten 2 Wochen" - praezisierung: | - "Kritisch" = Service für wesentliche Nutzergruppe nicht/kaum - nutzbar UND kein praktikabler Workaround existiert. - - - id: "EXIT-02" - name: "Support-Normalisierung" - beschreibung: "Ticket-Aufkommen auf erwartetem Normalniveau" - praezisierung: | - Keine quantitative Schwelle, sondern qualitative Einschätzung - durch SO in Abstimmung mit Support Manager. - - - id: "EXIT-03" - name: "Mängelfreiheit" - beschreibung: "Keine offenen fundamentalen Mängel" - praezisierung: | - "Fundamental" = Mängel, die Kernfunktionalität oder Sicherheit - betreffen. Bekannte Minor-Issues sind kein Exit-Blocker. - - mindestdauer_beachten: | - Auch wenn alle Exit-Kriterien erfüllt sind, kann ELS nicht vor - Ablauf der Mindestdauer (2 Wochen) beendet werden. - - # --------------------------------------------------------------------------- - # 5.5 ELS-EXIT-VERFAHREN - # --------------------------------------------------------------------------- - els_exit_verfahren: - - entscheider: "Service Owner" - - verfahren: "SO-Einzelentscheidung mit Informationspflicht" - - ablauf: - - schritt: 1 - aktivitaet: "SO prüft Exit-Kriterien" - - schritt: 2 - aktivitaet: "SO dokumentiert Exit-Begründung im Transition-Steckbrief" - - schritt: 3 - aktivitaet: "SO informiert SPM über ELS-Ende" - - schritt: 4 - aktivitaet: "SO schließt Transition-Steckbrief ab" - - schritt: 5 - aktivitaet: "Transition-Steckbrief wird Anhang im Service-Steckbrief" - - dokumentation: "Transition-Steckbrief (Abschnitt: els)" - - # --------------------------------------------------------------------------- - # 5.6 ESKALATION BEI ÜBERSCHREITUNG - # --------------------------------------------------------------------------- - eskalation: - governance_referenz: "GOV-TR-021" - - trigger: "Überschreitung der Maximaldauer (8 Wochen)" - - automatisch: true - - adressat: "SOR" - - vorbereitung: - verantwortlich: "SO" - inhalt: "Sachstandsbericht mit Ursachenanalyse und Empfehlung" - - sor_optionen: - - option: "Verlängerung" - beschreibung: "Maximale Verlängerung: 4 Wochen" - bedingung: "Nur einmal möglich" - - - option: "Rückführung in Transition" - beschreibung: "Service wird deaktiviert, Nachbesserung erforderlich" - - - option: "Zwangs-Exit mit Risiko-Akzeptanz" - beschreibung: "ELS wird beendet, bekannte Risiken werden akzeptiert" - dokumentation: "Risiko-Akzeptanz im SOR-Protokoll" - - - option: "Service-Stilllegung" - beschreibung: "Extremfall: Service wird nicht fortgeführt" - -# ============================================================================= -# 6. ROLLBACK- UND ABBRUCH-SZENARIEN -# ============================================================================= - -rollback_und_abbruch: - - # --------------------------------------------------------------------------- - # 6.0 BEGRIFFLICHE GRUNDLAGE - # --------------------------------------------------------------------------- - begriffe: - governance_referenz: "GOV-TR-028" - - rollback: - definition: | - Rückkehr zu einem früheren Zustand. Der Service wird temporär - deaktiviert oder zurückgenommen, mit der Absicht einer späteren - Wiederaufnahme nach Mängelbeseitigung. - charakter: "Reversibel, technisch-operativ" - - abbruch: - definition: | - Endgültige Beendigung des Service-Vorhabens. Der Service wird - nicht ins Portfolio aufgenommen. - charakter: "Irreversibel, strategisch" - - # --------------------------------------------------------------------------- - # 6.1 SZENARIO 1: GATE-3-ZURÜCKWEISUNG - # --------------------------------------------------------------------------- - szenario_gate_3_zurueckweisung: - governance_referenz: "GOV-TR-029" - - id: "RB-G3-01" - name: "Zurück an Transition" - phase: "Gate 3 (tr_12)" - charakter: "Rollback (reversibel)" - - beschreibung: | - SOR entscheidet bei Gate 3 auf "Zurück an Transition". - Service ist nicht Go-Live-bereit, aber grundsätzlich tragfähig. - - governance: - entscheider: "SOR" - folge_verantwortung: "SO" - - ablauf: - - schritt: 1 - aktivitaet: "SOR dokumentiert Zurückweisung mit Begründung" - - schritt: 2 - aktivitaet: "SO analysiert Mängel und plant Nachbesserung" - - schritt: 3 - aktivitaet: "SO führt Nachbesserung durch (ab tr_10 oder früher)" - - schritt: 4 - aktivitaet: "SO beantragt erneut Gate 3" - - frist: - standard: "8 Wochen" - beschreibung: "SO hat 8 Wochen für Nachbesserung" - bei_ueberschreitung: "Automatische SOR-Eskalation" - - service_status: "in_transition (unverändert)" - - dokumentation: "Transition-Steckbrief (Abschnitt: gate_3) mit Zurückweisungsgrund" - - # --------------------------------------------------------------------------- - # 6.2 SZENARIO 2: ELS-ROLLBACK (SERVICE-STOPP) - # --------------------------------------------------------------------------- - szenario_els_rollback: - governance_referenz: "GOV-TR-029" - - id: "RB-ELS-01" - name: "Service-Stopp während ELS" - phase: "ELS (op_01)" - charakter: "Rollback (reversibel)" - - beschreibung: | - Während ELS treten fundamentale Probleme auf, die einen - kontrollierten Service-Stopp erfordern. - - trigger: - - "Kritische Störung, die nicht zeitnah behebbar ist" - - "Sicherheitsrelevante Mängel" - - "Fundamentale Funktionsmängel" - - governance: - initiale_entscheidung: "SO" - folge_entscheidung: "SOR (in nächster Sitzung)" - - so_kompetenz: | - SO kann Service-Stopp eigenständig initiieren, wenn unmittelbares - Handeln erforderlich ist. Dies ist eine Notfallkompetenz. - - informationspflicht: "SO informiert SPM und SOR unverzüglich" - - ablauf: - - schritt: 1 - aktivitaet: "SO entscheidet Service-Stopp" - - schritt: 2 - aktivitaet: "Betriebsteam deaktiviert Service" - - schritt: 3 - aktivitaet: "SO informiert SPM und SOR" - - schritt: 4 - aktivitaet: "SO bereitet Sachstandsbericht für SOR vor" - - schritt: 5 - aktivitaet: "SOR entscheidet über weiteres Vorgehen" - - sor_optionen: - - "Nachbesserung und erneuter Go-Live-Versuch" - - "Rückführung in Transition (Build)" - - "Service-Ablehnung (Termination)" - - service_status: "suspended" - - dokumentation: "Transition-Steckbrief (Abschnitt: abbruch)" - - # --------------------------------------------------------------------------- - # 6.3 SZENARIO 3: SERVICE-ABLEHNUNG (TERMINATION) - # --------------------------------------------------------------------------- - szenario_termination: - governance_referenz: "GOV-TR-030" - - id: "TRM-01" - name: "Service-Ablehnung / Termination" - phase: "Gate 3 oder nach ELS-Stopp" - charakter: "Abbruch (irreversibel)" - - beschreibung: | - SOR entscheidet, das Service-Vorhaben endgültig zu beenden. - Der Service wird nicht ins Portfolio aufgenommen. - - trigger: - - "Fundamentale, nicht behebbare Mängel" - - "Strategische Neuausrichtung" - - "Wiederholte Zurückweisungen ohne erkennbaren Fortschritt" - - "Ressourcen-Entscheidung (Kosten-Nutzen)" - - governance: - entscheider: "SOR" - verfahren: "Konsent-Verfahren" - - mvp_hinweis: | - Für den MVP wird keine formale Iterationsgrenze für Zurückweisungen - definiert. SOR entscheidet situativ. Bei Praxisproblemen kann ein - formales Modell entwickelt werden. - - ablauf: - - schritt: 1 - aktivitaet: "SOR beschließt Termination" - - schritt: 2 - aktivitaet: "SO dokumentiert Abbruch im Transition-Steckbrief" - - schritt: 3 - aktivitaet: "Ressourcen-Freigabe / Projekt-Abschluss" - - schritt: 4 - aktivitaet: "Lessons Learned (optional)" - - service_status: "rejected" - - dokumentation: "Transition-Steckbrief (Abschnitt: abbruch) + SOR-Protokoll" - - # --------------------------------------------------------------------------- - # 6.4 SZENARIEN-ÜBERSICHT - # --------------------------------------------------------------------------- - szenarien_matrix: - - - id: "RB-G3-01" - name: "Zurück an Transition" - phase: "Gate 3 (tr_12)" - charakter: "Rollback" - entscheider: "SOR" - folgezustand: "in_transition" - - - id: "RB-ELS-01" - name: "Service-Stopp während ELS" - phase: "ELS (op_01)" - charakter: "Rollback" - entscheider: "SO (initial), SOR (final)" - folgezustand: "suspended" - - - id: "TRM-01" - name: "Service-Ablehnung" - phase: "Gate 3 / nach ELS-Stopp" - charakter: "Abbruch" - entscheider: "SOR" - folgezustand: "rejected" - -# ============================================================================= -# 7. ARTEFAKTE -# ============================================================================= - -artefakte: - - # --------------------------------------------------------------------------- - # 7.1 TRANSITION-STECKBRIEF (ZENTRALES ARTEFAKT) - # --------------------------------------------------------------------------- - transition_steckbrief: - governance_referenz: "GOV-TR-025" - - definition: | - Der Transition-Steckbrief ist das zentrale Prozessdokument der - Transition-Phase und ELS. Er dokumentiert den gesamten Verlauf - von Gate 1 bis zum ELS-Exit. - - charakter: "Temporäres Prozessdokument (nicht Service-Stammdatum)" - - schema_verweis: "06_Informationsmodell/spm_schema_transition-steckbrief.yaml" - - lifecycle: - anlage: "Bei Gate-1-Vorbereitung durch SO" - fortschreibung: "Kontinuierlich während Transition und ELS" - abschluss: "Nach ELS-Exit oder bei Abbruch" - archivierung: "Als Anhang in Service-Steckbrief überführt" - - struktur_uebersicht: - - "Header: Service-Referenz, Transition-Typ, Status, Zeitraum" - - "Gate 1: Entscheidung, Prüfdimensionen, Build/Configure-Entscheidung" - - "Gate 2: Entscheidung, Prüfdimensionen, Pilot-Entscheidung, Auflagen" - - "Pilot: Status, Scope, Ergebnis (nur wenn Pilot erforderlich)" - - "Gate 3: Entscheidung, Prüfdimensionen, SOR-Referenz" - - "ELS: Zeitraum, kritische Störungen, Exit-Begründung" - - "Abschluss-Checkliste: Boolean-Prüfung Vollständigkeit" - - "Abbruch: Dokumentation bei negativem Ausgang" - - "Meta: Erstellungs- und Änderungsinformationen" - -# ============================================================================= -# 8. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - eingang: - - von_design: - beschreibung: "Übergang nach Abschluss der Design-Phase" - trigger: "Abschluss Design-Phase (ds_04) → Gate 1 (tr_01) als Entry-Gate" - artefakte: - - "Service Design Document" - - "Implementation Blueprint" - - "Architektur-Dokumentation" - - "Budget-Freigabe" - verantwortlich: "SO / Projektleitung" - - ausgang: - - zu_operation: - beschreibung: "Aktivierter Service nach Gate-3-Freigabe" - trigger: "Gate 3 (tr_12) – SOR-Freigabe" - erste_aktivitaet: "op_01 (Early Life Support)" - artefakte: - - "Aktivierter Service" - - "Service-Steckbrief (mit Transition-Steckbrief als Anhang)" - - "Aktivierter Katalog-Eintrag" - - "SLA/SLO" - verantwortlich: "SO" - - zu_support: - beschreibung: "Support-Bereitschaft parallel zu Operation" - trigger: "Gate 3 (tr_12) – SOR-Freigabe" - artefakte: - - "Support-Dokumentation" - - "KB-Artikel (falls erforderlich)" - verantwortlich: "Support Manager" - - parallel: - - mit_slm: - beschreibung: "SLA/SLO-Abstimmung während Transition" - zeitpunkt: "Vor Gate 3" - artefakt: "SLA/SLO-Entwurf" - - mit_scm: - beschreibung: "Katalog-Eintrag-Vorbereitung" - zeitpunkt: "Vor Gate 3" - artefakt: "Katalog-Eintrag-Entwurf" - -# ============================================================================= -# 9. AKTIVITÄTS-REFERENZEN -# ============================================================================= - -aktivitaets_referenzen: - - hinweis: | - Referenz auf die Aktivitäts-IDs im Service-Lifecycle-Blueprint Version 3.0. - Die IDs wurden am 30.01.2026 von den alten Präfixen auf die neuen umgestellt. - - design_phase: - - id: ds_01 - name: "Definieren der erforderlichen Service-Eigenschaften" - - id: ds_02 - name: "Designen der erforderlichen Service- und Service-Management-Komponenten" - - id: ds_03 - name: "Beschreiben des Vorgehens zur Implementierung" - - id: ds_04 - name: "Vorbereiten der Service-Implementierung" - - transition_phase: - - id: tr_01 - name: "Gate 1: Entwicklung oder Konfiguration?" - typ: gate - - id: tr_02 - name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten" - - id: tr_03 - name: "Entwickeln von Anwendungen und Systemen" - - id: tr_04 - name: "Entgegennehmen der Service-Komponenten" - - id: tr_05 - name: "Konfiguration der Service-Komponenten" - - id: tr_06 - name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation" - - id: tr_07 - name: "Testen der Service-Komponenten" - - id: tr_08 - name: "Formale Übergabe (Build abgeschlossen)" - - id: tr_09 - name: "Gate 2: Entry-Prüfung nach Build" - typ: gate - - id: tr_10 - name: "Ausrollen der Service-Komponenten" - - id: tr_11 - name: "Vorbereiten der Service-Aktivierung" - - id: tr_12 - name: "Gate 3: Go-Live-Freigabe" - typ: gate - - operation_phase: - - id: op_01 - name: "Early Life Support (ELS)" - - id: op_02 - name: "Bereitstellen von Leitlinien für den Service-Betrieb" - # ... weitere Aktivitäten siehe Blueprint - -# ============================================================================= -# 10. ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "3.0" - datum: "2026-02-18" - aenderung: | - Gate 1 in Transition-Phase verschoben (neue ID: tr_01, ehemals ds_05). - Alle Transition-Aktivitäts-IDs um +1 verschoben (tr_02-tr_12). - Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist nun tr_12 (ehemals tr_11). - autor: "DIGITOM-Projekt" - - - version: "2.0" - datum: "2026-01-30" - aenderung: | - Anpassung an 5-Phasen-Modell (Version 3.0 des Service-Lifecycle-Blueprint): - - 3-Gate-Modell: Gate 1 (ds_05), Gate 2 (tr_08), Gate 3 (tr_11) - - ELS verschoben nach Operation (op_01) - - Alle Aktivitäts-ID-Referenzen aktualisiert - - Governance-Referenznummern beibehalten für Kontinuität - autor: "DIGITOM-Projekt" - - - version: "1.0" - datum: "2025-12-17" - aenderung: | - Vollständige Konsolidierung aus AP-01 bis AP-07. - Enthält: Gate-Modell, ELS-Konzept, Rollback-Szenarien, Artefakte, - Begriffserklärungen, Governance-Referenzen, MVP-Annahmen. - autor: "DIGITOM-Projekt" +# ============================================================================= +# RAHMENKONZEPT: SERVICE TRANSITION (K-TR) +# ============================================================================= +# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/ +# Dateiname: spm_konzept_service-transition.yaml +# ============================================================================= + +metadata: + id: "K-TR" + name: "Rahmenkonzept Service Transition" + version: "3.0" + status: "draft" + erstellt: "2025-12-15" + aktualisiert: "2026-02-18" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "konzept" + + beschreibung: | + Rahmenkonzept für die Transition-Phase im DIGITOM Service Lifecycle. + Definiert Governance-Logik, Quality Gates, Entscheidungsprinzipien und das + Early Life Support Konzept für die Überführung von Services in den Betrieb. + + aenderungen: + - version: "3.0" + datum: "2026-02-18" + beschreibung: | + Gate 1 in Transition-Phase verschoben (neue ID: tr_01, ehemals ds_05). + Alle Transition-Aktivitäts-IDs um +1 verschoben (tr_02-tr_12). + Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist nun tr_12 (ehemals tr_11). + Gate 1 ist nun im Scope der Transition, nicht mehr out_of_scope. + Aktivitäts-Referenzen und Schnittstellen aktualisiert. + autor: "DIGITOM-Projekt" + + - version: "2.0" + datum: "2026-01-30" + beschreibung: | + Anpassung an 5-Phasen-Modell (Version 3.0 des Service-Lifecycle-Blueprint): + - Phasennamen englisch (Design, Transition, Operation, Support, Review) + - 3-Gate-Modell: Gate 1 (ds_05), Gate 2 (tr_08), Gate 3 (tr_11) + - ELS verschoben nach Operation (op_01) + - Alle Aktivitäts-ID-Referenzen aktualisiert + - Schnittstellen-Referenzen aktualisiert + autor: "DIGITOM-Projekt" + + - version: "1.0" + datum: "2025-12-17" + beschreibung: | + Vollständige Konsolidierung aus AP-01 bis AP-07. + Enthält: Gate-Modell, ELS-Konzept, Rollback-Szenarien, Artefakte, + Begriffserklärungen, Governance-Referenzen, MVP-Annahmen. + autor: "DIGITOM-Projekt" + +# ============================================================================= +# 1. EINORDNUNG UND ABGRENZUNG +# ============================================================================= + +einordnung: + + position_im_lifecycle: + vorgaenger: "Design" + nachfolger: "Operation / Support" + + beschreibung: | + Die Transition-Phase bildet die Brücke zwischen der Design-Phase + und dem laufenden Betrieb. Sie umfasst Build/Konfiguration, Test, + Deployment und Go-Live-Freigabe. Nach Go-Live beginnt die Operation-Phase + mit Early Life Support (ELS). + + abgrenzung_blueprint_konzept: + + blueprint: + dokument: "service-lifecycle_transition.yaml" + inhalt: "Aktivitäten (tr_01–tr_12), RACI-Zuordnungen, Schnittstellen" + charakter: "Operativer Ablauf – das WAS und WER" + + konzept: + dokument: "spm_konzept_service-transition.yaml (dieses Dokument)" + inhalt: "Governance, Prinzipien, Entscheidungslogik, Quality Gates" + charakter: "Steuerungslogik – das WARUM und WIE entscheiden" + + referenzen: + blueprint_design: "02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml" + blueprint_transition: "02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml" + blueprint_operation: "02_spm_service-lifecycle-blueprint/service-lifecycle_operation.yaml" + schema_transition_steckbrief: "06_Informationsmodell/spm_schema_transition-steckbrief.yaml" + sor_geschaeftsordnung: "01_governance/spm_sor-geschaeftsordnung.yaml" + rolle_service_owner: "04_rollen/rolle_service-owner.yaml" + +# ============================================================================= +# 2. ZWECK UND SCOPE +# ============================================================================= + +zweck_und_scope: + + zweck: | + Die Transition-Phase gewährleistet, dass neu entwickelte oder wesentlich + geänderte Services kontrolliert in den produktiven Betrieb überführt werden. + Sie schützt das Service-Portfolio vor unreifen Services und stellt die + Betriebsfähigkeit sicher. + + scope: + in_scope: + - "Neue Services aus der Design-Phase" + - "Wesentliche Änderungen an bestehenden Services" + - "Entry-Entscheidung (Gate 1: Build or Configure)" + - "Build/Konfiguration, Test, Deployment" + - "Freigabeentscheidungen (Gate 1, Gate 2 und Gate 3)" + + out_of_scope: + - "Service-Design (Design-Phase)" + - "Minor Changes (werden über Change Enablement gesteuert)" + - "Early Life Support (Operation-Phase, op_01)" + - "Operative Betriebsführung (Operation-Phase)" + - "Incident-/Request-Bearbeitung (Support-Phase)" + + erfolgskriterien: + - "Service ist nach Transition stabil betreibbar" + - "Betriebsteam und Support sind handlungsfähig" + - "Dokumentation ist vollständig und aktuell" + - "SLA/SLO sind vereinbart und messbar" + +# ============================================================================= +# 3. LEITPRINZIPIEN +# ============================================================================= + +leitprinzipien: + + # --------------------------------------------------------------------------- + # P1: INFORMED JUDGMENT + # --------------------------------------------------------------------------- + informed_judgment: + governance_referenz: "GOV-TR-013" + + beschreibung: | + Gate-Entscheidungen folgen dem Prinzip der informierten Gesamtbewertung. + Der Gate-Keeper trifft eine Entscheidung auf Basis definierter + Prüfdimensionen. Die Dimensionen geben die Richtung vor, ohne jeden + Einzelfall vorab zu regeln. + + begruendung: | + Für den MVP ist ein prinzipienbasierter Ansatz angemessen. Detaillierte + Checklisten erzeugen Governance-Overhead ohne nachgewiesenen Mehrwert. + Die operative Erfahrung wird zeigen, wo Präzisierung nötig ist. + + # --------------------------------------------------------------------------- + # P2: SERVICE OWNER ACCOUNTABILITY + # --------------------------------------------------------------------------- + so_accountability: + + beschreibung: | + Der Service Owner bleibt während der gesamten Transition accountable + für den Service-Erfolg. Diese Verantwortung beginnt bei Gate 1 (Transition Entry) + und endet erst mit dem erfolgreichen ELS-Exit (Operation). + + implikationen: + - "SO ist Gate-Keeper bei Gate 2 (Entry-Prüfung)" + - "SO trägt Verantwortung für Mängelbeseitigung bei Zurückweisung" + - "SO entscheidet über ELS-Exit (mit Informationspflicht)" + - "SO kann Service-Stopp während ELS initiieren" + + # --------------------------------------------------------------------------- + # P3: QUALITATIVE BEWERTUNG + # --------------------------------------------------------------------------- + qualitative_bewertung: + governance_referenz: "GOV-TR-014" + + beschreibung: | + Prüfdimensionen werden qualitativ bewertet. Der Nachweis erfolgt durch + Zusicherung des Verantwortlichen, nicht durch mechanische Checklisten. + + validierungstiefe: | + "Hinreichende Plausibilität" – Der Gate-Keeper muss überzeugt sein, + dass die Kriterien erfüllt sind. Er muss nicht jeden Einzelnachweis + selbst prüfen. + + # --------------------------------------------------------------------------- + # P4: ROLLBACK ALS QUALITÄTSINSTRUMENT + # --------------------------------------------------------------------------- + rollback_als_qualitaetsinstrument: + governance_referenz: "GOV-TR-028" + + beschreibung: | + Rollback und Abbruch sind legitime Qualitätssicherungsinstrumente, + keine Schuldzuweisungen. Ein frühzeitiger Abbruch eines nicht + funktionierenden Service-Vorhabens ist besser als ein dysfunktionaler + Service im Portfolio. + +# ============================================================================= +# 4. QUALITY GATES +# ============================================================================= + +quality_gates: + + # --------------------------------------------------------------------------- + # 4.0 GATE-MODELL ÜBERSICHT + # --------------------------------------------------------------------------- + modell: + governance_referenz: "GOV-TR-010" + + anzahl_gates: 3 + + struktur: | + Design → Transition: [Gate 1] → Build → [Gate 2] → Deploy + → [Gate 3] → Operation (ELS) → Normalbetrieb + + gate_definition: | + Ein Gate ist ein formaler Entscheidungspunkt im Lifecycle, der kombiniert: + - Prüfkriterien (Was muss erfüllt sein?) + - Gate-Keeper (Wer entscheidet?) + - Entscheidungsoptionen (Welche Ergebnisse sind möglich?) + - Dokumentation (Wie wird die Entscheidung festgehalten?) + + gate_uebersicht: + - gate: "Gate 1" + id: "tr_01" + position: "Anfang Transition (Entry-Gate)" + gate_keeper: "SOR" + zweck: "Build or Configure Decision" + + - gate: "Gate 2" + id: "tr_09" + position: "Mitte Transition (nach Build)" + gate_keeper: "SO" + zweck: "Entry-Prüfung nach Build" + + - gate: "Gate 3" + id: "tr_12" + position: "Ende Transition" + gate_keeper: "SOR" + zweck: "Go-Live-Freigabe" + + entscheidungsoptionen_standard: + - option: "freigabe" + beschreibung: "Weiter zum nächsten Schritt" + - option: "freigabe_mit_auflagen" + beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden" + - option: "zurueck" + beschreibung: "Zurück an vorherige Phase zur Nachbesserung" + - option: "ablehnung" + beschreibung: "Endgültige Ablehnung des Service-Vorhabens" + + # --------------------------------------------------------------------------- + # 4.1 GATE 1: BUILD OR CONFIGURE DECISION (tr_01) + # --------------------------------------------------------------------------- + gate_1_build_or_configure: + governance_referenz: "GOV-TR-011" + + aktivitaets_id: "tr_01" + gate_keeper: "SOR (Service Owner Runde)" + phase: "Transition" + + zweck: | + Entscheidung, ob die Service-Komponenten entwickelt oder nur + konfiguriert werden müssen. Prüfung der Design-Vollständigkeit + und Budget-/Ressourcenfreigabe für die Transition-Phase. + + trigger: "Abschluss der Design-Aktivitäten (ds_01-ds_04)" + + pruef_dimensionen: + + - id: "G1-DIM-01" + name: "Design-Vollständigkeit" + beschreibung: "Ist das Service Design Document vollständig?" + showstopper: true + nachweisform: "SO-Zusicherung" + + - id: "G1-DIM-02" + name: "Architektur-Freigabe" + beschreibung: "Liegt eine Architektur-Bewertung vor?" + showstopper: true + nachweisform: "Architektur-Stellungnahme" + + - id: "G1-DIM-03" + name: "Budget-Verfügbarkeit" + beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?" + showstopper: true + nachweisform: "Budget-Bestätigung" + + entscheidungspfade: + - id: "entwicklung" + name: "Entwicklung" + beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich" + folgeaktivitaet: "tr_02" + + - id: "konfiguration" + name: "Konfiguration" + beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst" + folgeaktivitaet: "tr_05" + hinweis: "Überspringt Build-Aktivitäten (tr_02-tr_04)" + + governance_verfahren: + verfahren: "SOR-Konsent-Verfahren" + dokumentation: "SOR-Protokoll, Transition-Steckbrief (Abschnitt: gate_1)" + + # --------------------------------------------------------------------------- + # 4.2 GATE 2: ENTRY-PRÜFUNG NACH BUILD (tr_09) + # --------------------------------------------------------------------------- + gate_2_entry_pruefung: + governance_referenz: "GOV-TR-012" + + aktivitaets_id: "tr_09" + gate_keeper: "Service Owner (SO)" + phase: "Transition" + + zweck: | + Validierung der Übergabefähigkeit nach Abschluss des Builds. + Sicherstellung, dass grundlegende Voraussetzungen für die + Deploy-Aktivitäten erfüllt sind. + + trigger: "Formale Übergabe nach Build (tr_08)" + + voraussetzung: "Positives Gate 1 (tr_01)" + + pruef_dimensionen: + + - id: "G2-DIM-01" + name: "Übergabe-Vollständigkeit" + beschreibung: "Sind alle erwarteten Artefakte aus dem Build vorhanden?" + showstopper: true + nachweisform: "SO-Zusicherung basierend auf Übergabeprotokoll" + + - id: "G2-DIM-02" + name: "Abnahme-Status" + beschreibung: "Liegt eine Abnahme durch den Auftraggeber vor?" + showstopper: true + nachweisform: "Referenz auf Abnahmeprotokoll oder Bestätigung" + + - id: "G2-DIM-03" + name: "Ressourcen-Outlook" + beschreibung: "Sind Betrieb und Support prinzipiell vorbereitet?" + showstopper: false + nachweisform: "SO-Einschätzung, ggf. Rücksprache mit Ops/Support Manager" + + entscheidungsoptionen: + - "freigabe" + - "freigabe_mit_auflagen" + - "zurueck_an_build" + - "ablehnung" + + governance_verfahren: + governance_referenz: "GOV-TR-015" + + verfahren: "SO-Einzelentscheidung" + + beschreibung: | + Gate 2 ist eine operative Entscheidung des Service Owners. + Keine Gremienentscheidung erforderlich. + + dokumentation: "Transition-Steckbrief (Abschnitt: gate_2)" + + bei_unklarheit: + eskalation: "SO kann SPM zur Beratung hinzuziehen" + keine_pflicht: "Eskalation ist Option, keine Voraussetzung" + + pilot_entscheidung: + governance_referenz: "GOV-TR-012" + + in_gate_2: true + + beschreibung: | + Bei Gate 2 entscheidet der SO, ob ein Pilot erforderlich ist. + Die Entscheidung basiert auf Risikobewertung und Service-Komplexität. + + trigger_kriterien: + - "Hohe technische Komplexität" + - "Große Nutzerbasis" + - "Kritische Geschäftsprozesse betroffen" + - "Neuartige Technologie oder Integration" + + pilot_scope_festlegung: | + Falls Pilot erforderlich: SO definiert Pilotgruppe, Dauer und + Erfolgskriterien. Dokumentation im Transition-Steckbrief. + + output_bei_freigabe: + - "Transition-Steckbrief aktualisiert mit Gate-2-Dokumentation" + - "Pilot-Entscheidung dokumentiert" + - "Ggf. Auflagen dokumentiert" + + # --------------------------------------------------------------------------- + # 4.3 PILOT-PHASE (OPTIONAL) + # --------------------------------------------------------------------------- + pilot_phase: + governance_referenz: "GOV-TR-012" + + status: "Optional – Entscheidung bei Gate 2" + + zweck: | + Validierung des Services unter realen Bedingungen mit begrenzter + Nutzergruppe vor dem vollständigen Go-Live. + + kein_eigenstaendiges_gate: | + Der Pilot ist keine separate Gate-Entscheidung, sondern ein + optionaler Schritt zwischen Gate 2 und Gate 3. Die Pilot-Ergebnisse + fließen in die Gate-3-Prüfung ein. + + durchfuehrung: + verantwortlich: "SO" + unterstuetzung: "Betriebsteam, Support-Team" + + aktivitaeten: + - "Pilotgruppe informieren und onboarden" + - "Service für Pilotgruppe aktivieren" + - "Feedback sammeln und auswerten" + - "Technische Stabilität monitoren" + - "Ergebnisse dokumentieren" + + pilot_ergebnis: + dokumentation: "Transition-Steckbrief (Abschnitt: pilot)" + + moegliche_ergebnisse: + - ergebnis: "erfolgreich" + folge: "Weiter zu Gate 3" + - ergebnis: "erfolgreich_mit_anpassungen" + folge: "Anpassungen durchführen, dann Gate 3" + - ergebnis: "gescheitert" + folge: "Zurück an Build oder Design" + + # --------------------------------------------------------------------------- + # 4.4 GATE 3: GO-LIVE-FREIGABE (tr_12) + # --------------------------------------------------------------------------- + gate_3_go_live_freigabe: + governance_referenz: "GOV-TR-016" + + aktivitaets_id: "tr_12" + gate_keeper: "SOR (Service Owner Runde)" + phase: "Transition" + + zweck: | + Portfolio-Freigabe und formale Aktivierung des Services. + Prüfung der Betriebsreife aus Portfolio-Perspektive. + + trigger: "Antrag des SO nach Abschluss der Deploy-Aktivitäten (tr_10, tr_11)" + + voraussetzung: "Positives Gate 2 (tr_09), ggf. erfolgreiches Pilot" + + pruef_dimensionen: + + - id: "G3-DIM-01" + name: "Portfolio-Konsistenz" + beschreibung: "Passt der Service ins Portfolio? Strategische Ausrichtung?" + showstopper: true + nachweisform: "SPM-Stellungnahme" + + - id: "G3-DIM-02" + name: "Betriebsreife" + beschreibung: "Bestätigt SO die Readiness für den Produktivbetrieb?" + showstopper: true + nachweisform: "SO-Bestätigung im Transition-Steckbrief" + + - id: "G3-DIM-03" + name: "Support-Bereitschaft" + beschreibung: "Ist das Support-Team vorbereitet und handlungsfähig?" + showstopper: true + nachweisform: "Support Manager Bestätigung" + + - id: "G3-DIM-04" + name: "SLA/SLO-Vereinbarung" + beschreibung: "Liegen abgestimmte Service Levels vor?" + showstopper: false + nachweisform: "Verweis auf SLM-Artefakte" + + - id: "G3-DIM-05" + name: "Auflagen-Erfüllung" + beschreibung: "Sind alle Auflagen aus Gate 1 und Gate 2 erfüllt?" + showstopper: true + bedingung: "Nur wenn Auflagen existieren" + nachweisform: "SO-Bestätigung mit Nachweisreferenzen" + + entscheidungsoptionen: + - "go_live" + - "go_live_mit_auflagen" + - "zurueck_an_transition" + - "ablehnung" + + governance_verfahren: + governance_referenz: "GOV-TR-016" + + verfahren: "Konsent-Verfahren" + + beschreibung: | + Die SOR entscheidet nach dem Konsent-Prinzip: Ein Beschluss gilt als + angenommen, wenn kein anwesendes stimmberechtigtes Mitglied einen + schwerwiegenden, begründeten Einwand erhebt. + + bei_einwand: + folge: "Vertagung" + verantwortung: "SO muss Vorlage überarbeiten" + frist: "Nächste reguläre SOR-Sitzung" + + bei_erneutem_einwand: + folge: "SOR kann eskalieren oder ablehnen" + eskalationsziel: "Mission Board" + eskalation_ist: "Option, keine Pflicht" + + dokumentation: "SOR-Protokoll (referenziert im Transition-Steckbrief)" + + vorbereitungs_governance: + governance_referenz: "GOV-TR-017" + + vorlage_dokument: "Transition-Steckbrief" + + verantwortlich: "SO erstellt und reicht ein" + + einreichungsfrist: "3 Arbeitstage vor SOR-Sitzung" + + bei_verspaetung: "Verschiebung auf nächste SOR-Sitzung" + + vollstaendigkeitspruefung: + verantwortlich: "SPM" + zeitpunkt: "Bei Einreichung" + bei_unvollstaendigkeit: "Rückfrage an SO, ggf. Verschiebung" + + output_bei_freigabe: + - "SOR-Protokoll mit Go-Live-Beschluss" + - "Aufnahme ins Service-Portfolio" + - "Aktivierung des Katalog-Eintrags" + - "Formale SO-Bestätigung durch SOR" + - "Transition-Steckbrief (Abschnitt: gate_3) aktualisiert" + - "Übergang zu Operation-Phase (op_01: Early Life Support)" + +# ============================================================================= +# 5. ELS-KONZEPT (EARLY LIFE SUPPORT) +# ============================================================================= + +els_konzept: + + hinweis_phasen_zuordnung: | + WICHTIG: Early Life Support (ELS) ist seit Version 3.0 des Service-Lifecycle- + Blueprint der Operation-Phase zugeordnet (op_01), nicht mehr der Transition-Phase. + Der Service ist nach Gate 3 produktiv im Betrieb, ELS ist Betrieb mit erhöhter + Aufmerksamkeit. + + # --------------------------------------------------------------------------- + # 5.1 DEFINITION UND ZWECK + # --------------------------------------------------------------------------- + definition: + + aktivitaets_id: "op_01" + phase: "Operation" + + beschreibung: | + Early Life Support (ELS) ist die Phase erhöhter Aufmerksamkeit + unmittelbar nach dem Go-Live. Der Service ist produktiv, wird aber + intensiver beobachtet und betreut als im Normalbetrieb. + + zweck: + - "Frühzeitige Erkennung von Problemen im Produktivbetrieb" + - "Schnelle Reaktion auf unerwartete Situationen" + - "Geordneter Wissenstransfer vom Projekt zum Betrieb" + - "Validierung der Betriebsfähigkeit unter realen Bedingungen" + + # --------------------------------------------------------------------------- + # 5.2 DAUER-PARAMETER + # --------------------------------------------------------------------------- + dauer_parameter: + governance_referenz: "GOV-TR-018" + + modell: "Hybrid-Korridor" + + beschreibung: | + Zeitlicher Rahmen mit zustandsbasierter Exit-Entscheidung. + Innerhalb des Korridors entscheidet der SO basierend auf + den Exit-Kriterien. + + parameter: + + - name: "Mindestdauer" + wert: "2 Wochen" + verbindlichkeit: "verbindlich" + begruendung: "Minimale Beobachtungszeit für belastbare Aussage" + + - name: "Regeldauer" + wert: "4 Wochen" + verbindlichkeit: "Orientierung" + begruendung: "Erfahrungswert für typische Stabilisierung" + + - name: "Maximaldauer" + wert: "8 Wochen" + verbindlichkeit: "Eskalations-Trigger" + begruendung: "Überschreitung signalisiert Problem" + + mvp_annahme: | + Die konkreten Zeitwerte (2/4/8 Wochen) sind MVP-Annahmen und + müssen in der operativen Erprobung validiert werden. + + # --------------------------------------------------------------------------- + # 5.3 VERANTWORTLICHKEITEN + # --------------------------------------------------------------------------- + verantwortlichkeiten: + + service_owner: + rolle: "Accountable" + aufgaben: + - "Gesamtverantwortung für ELS-Erfolg" + - "Entscheidung über ELS-Exit" + - "Eskalation bei kritischen Störungen" + - "Dokumentation im Transition-Steckbrief" + + betriebsteam: + rolle: "Responsible (operativ)" + aufgaben: + - "Monitoring und Beobachtung" + - "Erste Anlaufstelle bei Störungen" + - "Technische Stabilisierung" + + support_team: + rolle: "Responsible (Nutzer-Support)" + aufgaben: + - "Bearbeitung von Incidents und Requests" + - "Feedback-Sammlung von Nutzern" + - "Eskalation bei Häufungen" + + projekt_verfuegbarkeit: + governance_referenz: "GOV-TR-019" + + modell: "Gestaffelte Übergabe" + + phasen: + - phase: "Woche 1-2" + verfuegbarkeit: "Verpflichtend" + reaktionszeit: "4 Stunden" + beschreibung: "Projekt-Team steht für Rückfragen bereit" + + - phase: "Ab Woche 3" + verfuegbarkeit: "Auf Abruf" + reaktionszeit: "2 Arbeitstage" + beschreibung: "Projekt-Team kann bei Bedarf hinzugezogen werden" + + projekt_exit: "Frühestens nach Mindestdauer (2 Wochen)" + + nachbetreuung: "Auf Abruf für 4 Wochen nach Projekt-Exit" + + # --------------------------------------------------------------------------- + # 5.4 EXIT-KRITERIEN + # --------------------------------------------------------------------------- + exit_kriterien: + governance_referenz: "GOV-TR-020" + + entscheidungslogik: | + SO prüft alle drei Kriterien. Alle müssen erfüllt sein. + Bei Grenzfällen dokumentiert SO seine Einschätzung in der + Exit-Begründung im Transition-Steckbrief. + + kriterien: + + - id: "EXIT-01" + name: "Stabilität" + beschreibung: "Keine kritischen Störungen in den letzten 2 Wochen" + praezisierung: | + "Kritisch" = Service für wesentliche Nutzergruppe nicht/kaum + nutzbar UND kein praktikabler Workaround existiert. + + - id: "EXIT-02" + name: "Support-Normalisierung" + beschreibung: "Ticket-Aufkommen auf erwartetem Normalniveau" + praezisierung: | + Keine quantitative Schwelle, sondern qualitative Einschätzung + durch SO in Abstimmung mit Support Manager. + + - id: "EXIT-03" + name: "Mängelfreiheit" + beschreibung: "Keine offenen fundamentalen Mängel" + praezisierung: | + "Fundamental" = Mängel, die Kernfunktionalität oder Sicherheit + betreffen. Bekannte Minor-Issues sind kein Exit-Blocker. + + mindestdauer_beachten: | + Auch wenn alle Exit-Kriterien erfüllt sind, kann ELS nicht vor + Ablauf der Mindestdauer (2 Wochen) beendet werden. + + # --------------------------------------------------------------------------- + # 5.5 ELS-EXIT-VERFAHREN + # --------------------------------------------------------------------------- + els_exit_verfahren: + + entscheider: "Service Owner" + + verfahren: "SO-Einzelentscheidung mit Informationspflicht" + + ablauf: + - schritt: 1 + aktivitaet: "SO prüft Exit-Kriterien" + - schritt: 2 + aktivitaet: "SO dokumentiert Exit-Begründung im Transition-Steckbrief" + - schritt: 3 + aktivitaet: "SO informiert SPM über ELS-Ende" + - schritt: 4 + aktivitaet: "SO schließt Transition-Steckbrief ab" + - schritt: 5 + aktivitaet: "Transition-Steckbrief wird Anhang im Service-Steckbrief" + + dokumentation: "Transition-Steckbrief (Abschnitt: els)" + + # --------------------------------------------------------------------------- + # 5.6 ESKALATION BEI ÜBERSCHREITUNG + # --------------------------------------------------------------------------- + eskalation: + governance_referenz: "GOV-TR-021" + + trigger: "Überschreitung der Maximaldauer (8 Wochen)" + + automatisch: true + + adressat: "SOR" + + vorbereitung: + verantwortlich: "SO" + inhalt: "Sachstandsbericht mit Ursachenanalyse und Empfehlung" + + sor_optionen: + - option: "Verlängerung" + beschreibung: "Maximale Verlängerung: 4 Wochen" + bedingung: "Nur einmal möglich" + + - option: "Rückführung in Transition" + beschreibung: "Service wird deaktiviert, Nachbesserung erforderlich" + + - option: "Zwangs-Exit mit Risiko-Akzeptanz" + beschreibung: "ELS wird beendet, bekannte Risiken werden akzeptiert" + dokumentation: "Risiko-Akzeptanz im SOR-Protokoll" + + - option: "Service-Stilllegung" + beschreibung: "Extremfall: Service wird nicht fortgeführt" + +# ============================================================================= +# 6. ROLLBACK- UND ABBRUCH-SZENARIEN +# ============================================================================= + +rollback_und_abbruch: + + # --------------------------------------------------------------------------- + # 6.0 BEGRIFFLICHE GRUNDLAGE + # --------------------------------------------------------------------------- + begriffe: + governance_referenz: "GOV-TR-028" + + rollback: + definition: | + Rückkehr zu einem früheren Zustand. Der Service wird temporär + deaktiviert oder zurückgenommen, mit der Absicht einer späteren + Wiederaufnahme nach Mängelbeseitigung. + charakter: "Reversibel, technisch-operativ" + + abbruch: + definition: | + Endgültige Beendigung des Service-Vorhabens. Der Service wird + nicht ins Portfolio aufgenommen. + charakter: "Irreversibel, strategisch" + + # --------------------------------------------------------------------------- + # 6.1 SZENARIO 1: GATE-3-ZURÜCKWEISUNG + # --------------------------------------------------------------------------- + szenario_gate_3_zurueckweisung: + governance_referenz: "GOV-TR-029" + + id: "RB-G3-01" + name: "Zurück an Transition" + phase: "Gate 3 (tr_12)" + charakter: "Rollback (reversibel)" + + beschreibung: | + SOR entscheidet bei Gate 3 auf "Zurück an Transition". + Service ist nicht Go-Live-bereit, aber grundsätzlich tragfähig. + + governance: + entscheider: "SOR" + folge_verantwortung: "SO" + + ablauf: + - schritt: 1 + aktivitaet: "SOR dokumentiert Zurückweisung mit Begründung" + - schritt: 2 + aktivitaet: "SO analysiert Mängel und plant Nachbesserung" + - schritt: 3 + aktivitaet: "SO führt Nachbesserung durch (ab tr_10 oder früher)" + - schritt: 4 + aktivitaet: "SO beantragt erneut Gate 3" + + frist: + standard: "8 Wochen" + beschreibung: "SO hat 8 Wochen für Nachbesserung" + bei_ueberschreitung: "Automatische SOR-Eskalation" + + service_status: "in_transition (unverändert)" + + dokumentation: "Transition-Steckbrief (Abschnitt: gate_3) mit Zurückweisungsgrund" + + # --------------------------------------------------------------------------- + # 6.2 SZENARIO 2: ELS-ROLLBACK (SERVICE-STOPP) + # --------------------------------------------------------------------------- + szenario_els_rollback: + governance_referenz: "GOV-TR-029" + + id: "RB-ELS-01" + name: "Service-Stopp während ELS" + phase: "ELS (op_01)" + charakter: "Rollback (reversibel)" + + beschreibung: | + Während ELS treten fundamentale Probleme auf, die einen + kontrollierten Service-Stopp erfordern. + + trigger: + - "Kritische Störung, die nicht zeitnah behebbar ist" + - "Sicherheitsrelevante Mängel" + - "Fundamentale Funktionsmängel" + + governance: + initiale_entscheidung: "SO" + folge_entscheidung: "SOR (in nächster Sitzung)" + + so_kompetenz: | + SO kann Service-Stopp eigenständig initiieren, wenn unmittelbares + Handeln erforderlich ist. Dies ist eine Notfallkompetenz. + + informationspflicht: "SO informiert SPM und SOR unverzüglich" + + ablauf: + - schritt: 1 + aktivitaet: "SO entscheidet Service-Stopp" + - schritt: 2 + aktivitaet: "Betriebsteam deaktiviert Service" + - schritt: 3 + aktivitaet: "SO informiert SPM und SOR" + - schritt: 4 + aktivitaet: "SO bereitet Sachstandsbericht für SOR vor" + - schritt: 5 + aktivitaet: "SOR entscheidet über weiteres Vorgehen" + + sor_optionen: + - "Nachbesserung und erneuter Go-Live-Versuch" + - "Rückführung in Transition (Build)" + - "Service-Ablehnung (Termination)" + + service_status: "suspended" + + dokumentation: "Transition-Steckbrief (Abschnitt: abbruch)" + + # --------------------------------------------------------------------------- + # 6.3 SZENARIO 3: SERVICE-ABLEHNUNG (TERMINATION) + # --------------------------------------------------------------------------- + szenario_termination: + governance_referenz: "GOV-TR-030" + + id: "TRM-01" + name: "Service-Ablehnung / Termination" + phase: "Gate 3 oder nach ELS-Stopp" + charakter: "Abbruch (irreversibel)" + + beschreibung: | + SOR entscheidet, das Service-Vorhaben endgültig zu beenden. + Der Service wird nicht ins Portfolio aufgenommen. + + trigger: + - "Fundamentale, nicht behebbare Mängel" + - "Strategische Neuausrichtung" + - "Wiederholte Zurückweisungen ohne erkennbaren Fortschritt" + - "Ressourcen-Entscheidung (Kosten-Nutzen)" + + governance: + entscheider: "SOR" + verfahren: "Konsent-Verfahren" + + mvp_hinweis: | + Für den MVP wird keine formale Iterationsgrenze für Zurückweisungen + definiert. SOR entscheidet situativ. Bei Praxisproblemen kann ein + formales Modell entwickelt werden. + + ablauf: + - schritt: 1 + aktivitaet: "SOR beschließt Termination" + - schritt: 2 + aktivitaet: "SO dokumentiert Abbruch im Transition-Steckbrief" + - schritt: 3 + aktivitaet: "Ressourcen-Freigabe / Projekt-Abschluss" + - schritt: 4 + aktivitaet: "Lessons Learned (optional)" + + service_status: "rejected" + + dokumentation: "Transition-Steckbrief (Abschnitt: abbruch) + SOR-Protokoll" + + # --------------------------------------------------------------------------- + # 6.4 SZENARIEN-ÜBERSICHT + # --------------------------------------------------------------------------- + szenarien_matrix: + + - id: "RB-G3-01" + name: "Zurück an Transition" + phase: "Gate 3 (tr_12)" + charakter: "Rollback" + entscheider: "SOR" + folgezustand: "in_transition" + + - id: "RB-ELS-01" + name: "Service-Stopp während ELS" + phase: "ELS (op_01)" + charakter: "Rollback" + entscheider: "SO (initial), SOR (final)" + folgezustand: "suspended" + + - id: "TRM-01" + name: "Service-Ablehnung" + phase: "Gate 3 / nach ELS-Stopp" + charakter: "Abbruch" + entscheider: "SOR" + folgezustand: "rejected" + +# ============================================================================= +# 7. ARTEFAKTE +# ============================================================================= + +artefakte: + + # --------------------------------------------------------------------------- + # 7.1 TRANSITION-STECKBRIEF (ZENTRALES ARTEFAKT) + # --------------------------------------------------------------------------- + transition_steckbrief: + governance_referenz: "GOV-TR-025" + + definition: | + Der Transition-Steckbrief ist das zentrale Prozessdokument der + Transition-Phase und ELS. Er dokumentiert den gesamten Verlauf + von Gate 1 bis zum ELS-Exit. + + charakter: "Temporäres Prozessdokument (nicht Service-Stammdatum)" + + schema_verweis: "06_Informationsmodell/spm_schema_transition-steckbrief.yaml" + + lifecycle: + anlage: "Bei Gate-1-Vorbereitung durch SO" + fortschreibung: "Kontinuierlich während Transition und ELS" + abschluss: "Nach ELS-Exit oder bei Abbruch" + archivierung: "Als Anhang in Service-Steckbrief überführt" + + struktur_uebersicht: + - "Header: Service-Referenz, Transition-Typ, Status, Zeitraum" + - "Gate 1: Entscheidung, Prüfdimensionen, Build/Configure-Entscheidung" + - "Gate 2: Entscheidung, Prüfdimensionen, Pilot-Entscheidung, Auflagen" + - "Pilot: Status, Scope, Ergebnis (nur wenn Pilot erforderlich)" + - "Gate 3: Entscheidung, Prüfdimensionen, SOR-Referenz" + - "ELS: Zeitraum, kritische Störungen, Exit-Begründung" + - "Abschluss-Checkliste: Boolean-Prüfung Vollständigkeit" + - "Abbruch: Dokumentation bei negativem Ausgang" + - "Meta: Erstellungs- und Änderungsinformationen" + +# ============================================================================= +# 8. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + eingang: + + von_design: + beschreibung: "Übergang nach Abschluss der Design-Phase" + trigger: "Abschluss Design-Phase (ds_04) → Gate 1 (tr_01) als Entry-Gate" + artefakte: + - "Service Design Document" + - "Implementation Blueprint" + - "Architektur-Dokumentation" + - "Budget-Freigabe" + verantwortlich: "SO / Projektleitung" + + ausgang: + + zu_operation: + beschreibung: "Aktivierter Service nach Gate-3-Freigabe" + trigger: "Gate 3 (tr_12) – SOR-Freigabe" + erste_aktivitaet: "op_01 (Early Life Support)" + artefakte: + - "Aktivierter Service" + - "Service-Steckbrief (mit Transition-Steckbrief als Anhang)" + - "Aktivierter Katalog-Eintrag" + - "SLA/SLO" + verantwortlich: "SO" + + zu_support: + beschreibung: "Support-Bereitschaft parallel zu Operation" + trigger: "Gate 3 (tr_12) – SOR-Freigabe" + artefakte: + - "Support-Dokumentation" + - "KB-Artikel (falls erforderlich)" + verantwortlich: "Support Manager" + + parallel: + + mit_slm: + beschreibung: "SLA/SLO-Abstimmung während Transition" + zeitpunkt: "Vor Gate 3" + artefakt: "SLA/SLO-Entwurf" + + mit_scm: + beschreibung: "Katalog-Eintrag-Vorbereitung" + zeitpunkt: "Vor Gate 3" + artefakt: "Katalog-Eintrag-Entwurf" + +# ============================================================================= +# 9. AKTIVITÄTS-REFERENZEN +# ============================================================================= + +aktivitaets_referenzen: + + hinweis: | + Referenz auf die Aktivitäts-IDs im Service-Lifecycle-Blueprint Version 3.0. + Die IDs wurden am 30.01.2026 von den alten Präfixen auf die neuen umgestellt. + + design_phase: + - id: ds_01 + name: "Definieren der erforderlichen Service-Eigenschaften" + - id: ds_02 + name: "Designen der erforderlichen Service- und Service-Management-Komponenten" + - id: ds_03 + name: "Beschreiben des Vorgehens zur Implementierung" + - id: ds_04 + name: "Vorbereiten der Service-Implementierung" + + transition_phase: + - id: tr_01 + name: "Gate 1: Entwicklung oder Konfiguration?" + typ: gate + - id: tr_02 + name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten" + - id: tr_03 + name: "Entwickeln von Anwendungen und Systemen" + - id: tr_04 + name: "Entgegennehmen der Service-Komponenten" + - id: tr_05 + name: "Konfiguration der Service-Komponenten" + - id: tr_06 + name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation" + - id: tr_07 + name: "Testen der Service-Komponenten" + - id: tr_08 + name: "Formale Übergabe (Build abgeschlossen)" + - id: tr_09 + name: "Gate 2: Entry-Prüfung nach Build" + typ: gate + - id: tr_10 + name: "Ausrollen der Service-Komponenten" + - id: tr_11 + name: "Vorbereiten der Service-Aktivierung" + - id: tr_12 + name: "Gate 3: Go-Live-Freigabe" + typ: gate + + operation_phase: + - id: op_01 + name: "Early Life Support (ELS)" + - id: op_02 + name: "Bereitstellen von Leitlinien für den Service-Betrieb" + # ... weitere Aktivitäten siehe Blueprint + +# ============================================================================= +# 10. ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "3.0" + datum: "2026-02-18" + aenderung: | + Gate 1 in Transition-Phase verschoben (neue ID: tr_01, ehemals ds_05). + Alle Transition-Aktivitäts-IDs um +1 verschoben (tr_02-tr_12). + Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist nun tr_12 (ehemals tr_11). + autor: "DIGITOM-Projekt" + + - version: "2.0" + datum: "2026-01-30" + aenderung: | + Anpassung an 5-Phasen-Modell (Version 3.0 des Service-Lifecycle-Blueprint): + - 3-Gate-Modell: Gate 1 (ds_05), Gate 2 (tr_08), Gate 3 (tr_11) + - ELS verschoben nach Operation (op_01) + - Alle Aktivitäts-ID-Referenzen aktualisiert + - Governance-Referenznummern beibehalten für Kontinuität + autor: "DIGITOM-Projekt" + + - version: "1.0" + datum: "2025-12-17" + aenderung: | + Vollständige Konsolidierung aus AP-01 bis AP-07. + Enthält: Gate-Modell, ELS-Konzept, Rollback-Szenarien, Artefakte, + Begriffserklärungen, Governance-Referenzen, MVP-Annahmen. + autor: "DIGITOM-Projekt" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_change-enablement.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_change-enablement.yaml index e2cecac..ca75caa 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_change-enablement.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_change-enablement.yaml @@ -1,844 +1,844 @@ -# ============================================================================= -# KONZEPT: CHANGE ENABLEMENT (P-03) -# ============================================================================= -# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/03_practices/ -# Dateiname: spm_practice_change-enablement.yaml -# ============================================================================= - -metadata: - id: "P-03" - name: "Change Enablement" - version: "1.3" - status: "draft" - erstellt: "2025-12-17" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "practice-konzept" - itil4_referenz: "Change Enablement Practice" - - beschreibung: | - Rahmenkonzept für die kontrollierte Durchführung von Service-Änderungen. - Definiert Change-Typen, Klassifizierungslogik, Autorisierungsverfahren - und Schnittstellen zu angrenzenden Prozessen. - - Ziel: Erfolgreiche Changes ermöglichen bei angemessener Risikokontrolle. - Prinzip: So wenig Governance wie nötig, so viel wie erforderlich. - - referenzen: - service_transition: "02a_lifecycle-konzepte/konzept_service-transition.yaml" - problem_management: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml" - shm_bedarfsbewertung: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" - dpm_klassifizierung: "#01_demand-portfolio-management/#01.1_documentation/dpm_demand-klassifizierung.yaml" - governance_log: "spm_governance-entscheidungen-log.yaml" - -# ============================================================================= -# 1. EINORDNUNG UND SCOPE -# ============================================================================= - -einordnung: - - zweck: | - Change Enablement stellt sicher, dass Service-Änderungen kontrolliert, - risikobewusst und effizient durchgeführt werden. Die Practice balanciert - zwischen Agilität (schnelle Umsetzung) und Stabilität (Schutz des Betriebs). - - itil4_definition: | - "The purpose of the change enablement practice is to maximize the number - of successful service and product changes by ensuring that risks have been - properly assessed, authorizing changes to proceed, and managing the - change schedule." - - scope: - - in_scope: - - "Änderungen an bestehenden Services" - - "Service-Erweiterungen und -Optimierungen" - - "Technische Updates mit Service-Bezug" - - "Konfigurationsänderungen an Service-Komponenten" - - "Changes aus Problem Management (permanente Lösungen)" - - out_of_scope: - - typ: "Neue Services" - routing: "Service Transition (vollständiger Lifecycle)" - referenz: "konzept_service-transition.yaml" - - - typ: "Demands (neue Services / grundlegende Neugestaltung)" - routing: "Demand Portfolio Management" - referenz: "dpm_funktionsbeschreibung.yaml" - - - typ: "Service Requests" - routing: "Request Management (Katalog-basiert)" - referenz: "sub-practice_request-management.yaml" - - - typ: "Infrastruktur ohne Service-Bezug" - routing: "Produkt-Ebene (nicht in aktueller Phase)" - hinweis: "Siehe Abgrenzung Produkt" - - abgrenzung_produkt: - governance_referenz: "GOV-CE-002" - - vermerk: | - Infrastruktur-Änderungen ohne direkten Service-Bezug (z.B. Netzwerk- - Wartung, Basis-Infrastruktur) sind der Produkt-Ebene zuzuordnen. - - Da die Produkt-Konzeption in der aktuellen Projektphase nicht im Fokus - steht (Priorisierung Kunden-/Service-Sicht), wird dieser Bereich - bewusst ausgeklammert. - - Merke: Bei späterer Produkt-Konzeption ist Change Enablement für - Produkte/Infrastruktur zu ergänzen. - - praktische_regel: | - Frage: "Hat diese Änderung Auswirkungen auf einen Service im Katalog?" - - Ja → Change Enablement (dieses Konzept) - - Nein → Operativer Betrieb oder Produkt-Management - -# ============================================================================= -# 2. CHANGE-TYPEN -# ============================================================================= - -change_typen: - - uebersicht: - beschreibung: | - DIGITOM unterscheidet vier Change-Typen, die sich in Risiko, - Autorisierungsverfahren und Dokumentationsaufwand unterscheiden. - - typen: - - "Standard Change (pre-authorized)" - - "Normal Change (SO-Entscheidung)" - - "Major Change (SOR-autorisierungspflichtig)" - - "Emergency Change (Sofortumsetzung)" - - # --------------------------------------------------------------------------- - # STANDARD CHANGE - # --------------------------------------------------------------------------- - standard_change: - - definition: | - Ein Standard Change ist ein wiederkehrender, risikoarmer Change, - der vollständig dokumentiert ist und ohne zusätzliche Genehmigung - durchgeführt werden kann. - - merkmale: - - "Wiederkehrend und vorhersehbar" - - "Risiko bekannt und gering" - - "Ablauf standardisiert und dokumentiert" - - "Ergebnis vorhersehbar" - - voraussetzungen: - - "Change-Modell existiert und ist dokumentiert" - - "Change-Modell wurde einmalig durch SO genehmigt" - - "Rollback-Verfahren ist definiert" - - change_modell: - - beschreibung: | - Ein Change-Modell dokumentiert das Verfahren für einen Standard Change. - Es wird einmalig erstellt und genehmigt. Danach ist der Change - pre-authorized – jede Ausführung benötigt keine weitere Genehmigung. - - verantwortung_erstellung: "Service Owner" - verantwortung_genehmigung: "Service Owner" - - inhalt: - - name: "Change-Bezeichnung" - beschreibung: "Eindeutiger Name für den Standard Change" - - name: "Anwendungsbereich" - beschreibung: "Wann/wo wird dieser Change angewendet?" - - name: "Auslöser" - beschreibung: "Was triggert diesen Change?" - - name: "Durchführungsschritte" - beschreibung: "Schritt-für-Schritt-Anleitung" - - name: "Beteiligte Rollen" - beschreibung: "Wer führt durch, wer wird informiert?" - - name: "Risikobewertung" - beschreibung: "Bekannte Risiken und Mitigationen" - - name: "Rollback-Verfahren" - beschreibung: "Wie wird rückgängig gemacht?" - - name: "Erwartete Dauer" - beschreibung: "Typischer Zeitaufwand" - - transparenz: | - SO dokumentiert Change-Modelle für seinen Service. - SPM erhält Kopie zur Kenntnis (nicht zur Genehmigung). - Dies dient der Portfolio-Transparenz, nicht der Kontrolle. - - autorisierung: | - Keine weitere Genehmigung bei Ausführung erforderlich. - Die Genehmigung erfolgte einmalig bei Freigabe des Change-Modells. - - beispiele: - - "Passwort-Reset nach definiertem Verfahren" - - "Software-Update auf freigegebene Version" - - "Benutzer-Berechtigung gemäß Berechtigungskonzept" - - "Regelmäßige Wartungsarbeiten nach Wartungsplan" - - # --------------------------------------------------------------------------- - # NORMAL CHANGE - # --------------------------------------------------------------------------- - normal_change: - - definition: | - Ein Normal Change ist eine Service-Änderung, die weder als Standard - Change pre-authorized ist, noch die Kriterien für einen Major Change - erfüllt. Er erfordert eine Einzelfallentscheidung durch den Service Owner. - - merkmale: - - "Nicht wiederkehrend oder nicht standardisierbar" - - "Risiko überschaubar, aber nicht trivial" - - "Service-Identität bleibt erhalten" - - "Keine Transition-Gates erforderlich" - - change_authority: "Service Owner" - - verfahren: - - schritte: - - schritt: 1 - name: "Change Request" - beschreibung: "Anforderung wird dokumentiert (Ticket, E-Mail, etc.)" - verantwortlich: "Anfordernde Rolle" - - - schritt: 2 - name: "Klassifizierung" - beschreibung: "SO prüft: Standard? Normal? Major?" - verantwortlich: "Service Owner" - - - schritt: 3 - name: "Bewertung" - beschreibung: "SO bewertet Risiko, Aufwand, Auswirkungen" - verantwortlich: "Service Owner" - - - schritt: 4 - name: "Entscheidung" - beschreibung: "SO entscheidet: Freigabe / Ablehnung / Rückfragen" - verantwortlich: "Service Owner" - - - schritt: 5 - name: "Umsetzung" - beschreibung: "Change wird implementiert" - verantwortlich: "Betriebsteam / Projektteam" - - - schritt: 6 - name: "Abschluss" - beschreibung: "SO bestätigt erfolgreiche Umsetzung" - verantwortlich: "Service Owner" - - cross_service: - governance_referenz: "GOV-CE-003" - - erkennung: | - Der Service Owner ist verantwortlich für die Erkennung von - Cross-Service-Impact. Er kennt seinen Service und dessen - Abhängigkeiten am besten. - - eskalation: | - Bei Normal Changes mit potenziellem Cross-Service-Impact - bezieht der SO den SPM als "Zweite Augen" ein. - - SPM prüft aus Portfolio-Perspektive: - - Gibt es Auswirkungen auf andere Services? - - Sind andere Service Owner zu informieren/einzubeziehen? - - Ist eine SOR-Befassung erforderlich? - - schwellenwert: | - SO-Ermessen: "Im Zweifel SPM einbeziehen." - - Keine formalen Schwellenwerte im MVP. Die operative Erfahrung - wird zeigen, ob Präzisierung nötig ist. - - verfahren_bei_cross_service: - - "SO identifiziert potenziellen Cross-Service-Impact" - - "SO informiert SPM (formlos, z.B. kurze E-Mail/Teams)" - - "SPM gibt Einschätzung: 'Go' oder 'Abstimmung mit SO X nötig'" - - "Bei Bedarf: Bilaterale Abstimmung zwischen betroffenen SOs" - - "Bei Dissens oder Unklarheit: Eskalation an SOR" - - # --------------------------------------------------------------------------- - # MAJOR CHANGE - # --------------------------------------------------------------------------- - major_change: - - definition: | - Ein Major Change ist eine signifikante Service-Änderung, die die - Service-Identität berührt und daher eine SOR-Autorisierung erfordert. - Nach der Autorisierung durchläuft der Major Change den regulären - Service-Lifecycle (Design/Transition) je nach Einstiegspunkt. - - governance_referenz: "GOV-TR-003" - - merkmale: - - "Verändert wesentliche Service-Eigenschaften" - - "Höheres Risiko für Betrieb und Stakeholder" - - "Erfordert initiale Governance-Entscheidung durch SOR (Autorisierung)" - - "Durchläuft nach Autorisierung regulären Lifecycle (Design/Transition) je nach Einstiegspunkt" - - kriterien: - beschreibung: | - Ein Change gilt als Major, wenn mindestens eines der folgenden - Kriterien erfüllt ist. Die Bewertung erfolgt durch den SO nach - dem Prinzip "Informed Judgment". - - liste: - - id: "MAJ-01" - kriterium: "Änderung der Service-Definition" - beschreibung: "Der Scope, die Zielgruppe oder die Kernfunktionalität des Service ändert sich." - beispiele: - - "Service wird auf neue Nutzergruppe ausgeweitet" - - "Kernfunktion wird hinzugefügt oder entfernt" - - "Service-Scope wird signifikant erweitert/eingeschränkt" - - - id: "MAJ-02" - kriterium: "Änderung der SLA/SLO-Vereinbarungen" - beschreibung: "Die vereinbarten Service Levels ändern sich." - beispiele: - - "Verfügbarkeitsziel wird angepasst" - - "Support-Zeiten werden geändert" - - "Performance-Ziele werden neu definiert" - - - id: "MAJ-03" - kriterium: "Signifikante Architektur-Änderung" - beschreibung: "Die technische Grundstruktur des Service ändert sich wesentlich." - beispiele: - - "Wechsel der Basis-Plattform" - - "Neue kritische Abhängigkeit zu anderem System" - - "Grundlegende Änderung des Technologie-Stacks" - bei_unsicherheit: | - Bei Unsicherheit, ob eine Architektur-Änderung "signifikant" ist: - Architektur-Rolle konsultieren. - - - id: "MAJ-04" - kriterium: "DPM-Komplexität 'komplex' oder 'hochkomplex'" - beschreibung: | - Der Change resultiert aus einem Demand, der im DPM als - komplex oder hochkomplex klassifiziert wurde. - referenz: "dpm_demand-klassifizierung.yaml" - hinweis: | - Dieses Kriterium greift, wenn ein Demand durch DPM bearbeitet - wurde und als Umsetzungsauftrag an SPM übergeht. - - verfahren: | - Major Changes erfordern EINE SOR-Autorisierung. Danach durchlaufen - sie den regulären Service-Lifecycle. Der Ablauf ist: - - 1. SO klassifiziert Change als Major - 2. SO stellt Major Change der SOR vor (Autorisierung) - 3. SOR entscheidet: Autorisierung / Autorisierung mit Auflagen / Ablehnung - - Als Teil der Autorisierung legt SOR den Einstiegspunkt fest - (Design oder Transition), je nach Reifegrad der Änderung - 4. Bei Autorisierung: Major Change durchläuft regulären Lifecycle - ab dem festgelegten Einstiegspunkt - 5. Alle weiteren Gates (Gate 1, Gate 2, Gate 3) sind reguläre - Lifecycle-Gates – keine gesonderte Major-Change-Entscheidung - - Wichtig: Die SOR hat bei einem Major Change genau EINE Entscheidung: - die initiale Autorisierung (oder Ablehnung). Danach ist der Major Change - eine Änderung an einem bestehenden Service und durchläuft als solcher - die vorgesehenen Lifecycle-Stufen und -Gates. - Dies unterscheidet ihn vom Normal Change, bei dem der SO allein entscheidet. - - Details siehe konzept_service-transition.yaml - - referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml" - - # --------------------------------------------------------------------------- - # EMERGENCY CHANGE - # --------------------------------------------------------------------------- - emergency_change: - governance_referenz: "GOV-CE-001" - - definition: | - Ein Emergency Change ist eine Änderung, die aufgrund kritischer - Sicherheits- oder Verfügbarkeitsprobleme sofort umgesetzt werden muss. - Das normale Genehmigungsverfahren wird zugunsten der Geschwindigkeit - verkürzt. - - merkmale: - - "Kritische Dringlichkeit (Sicherheit oder Verfügbarkeit)" - - "Sofortumsetzung erforderlich" - - "Dokumentation erfolgt nachträglich" - - "SO wird informiert, nicht um Genehmigung gefragt" - - ausloeser: - - "Kritische Sicherheitslücke (z.B. aktiv ausgenutzte Schwachstelle)" - - "Service-Ausfall mit hohem Business-Impact" - - "Datenverlust-Risiko" - - "Compliance-Verstoß mit sofortigem Handlungsbedarf" - - verfahren: - - autorisierung: | - Sofortumsetzung durch Betrieb/Support ohne vorherige Genehmigung. - Die Entscheidung zur Sofortumsetzung trifft die handelnde Rolle - (z.B. Operations Manager, Support Manager, L2-Agent). - - so_rolle: | - Der Service Owner wird informiert, nicht um Genehmigung gefragt. - Information erfolgt parallel zur oder unmittelbar nach der Umsetzung. - - dokumentation: | - Nachträgliche Dokumentation innerhalb von 24 Stunden: - - Was wurde geändert? - - Warum war Sofortumsetzung erforderlich? - - Wer hat entschieden/umgesetzt? - - Welche Auswirkungen hatte der Change? - - nachbereitung: | - Nach Abschluss des Emergency Change: - - SO prüft: Ist Nacharbeit erforderlich? - - Bei Bedarf: Normal Change für "saubere" Lösung - - Bei wiederkehrendem Muster: Problem Record erstellen - - abgrenzung: | - Nicht jeder dringende Change ist ein Emergency Change. - - Emergency = "Muss JETZT passieren, sonst kritischer Schaden" - Dringend = "Sollte schnell passieren" → Beschleunigter Normal Change - -# ============================================================================= -# 3. KLASSIFIZIERUNGSVERFAHREN -# ============================================================================= - -klassifizierung: - - verantwortung: "Service Owner" - - prinzip: | - Die Klassifizierung erfolgt nach dem Prinzip "Informed Judgment". - Der SO trifft eine fachliche Einschätzung basierend auf seinem - Service-Wissen. Es gibt keine mechanischen Schwellenwerte. - - entscheidungslogik: - - beschreibung: | - Der SO durchläuft folgende Prüffragen, um den Change-Typ zu bestimmen. - - prueffragen: - - reihenfolge: 1 - frage: "Ist das ein dokumentierter, pre-authorized Standard Change?" - wenn_ja: "→ Standard Change" - wenn_nein: "→ Weiter zu Frage 2" - - - reihenfolge: 2 - frage: "Erfordert die Situation Sofortumsetzung (Sicherheit/Verfügbarkeit)?" - wenn_ja: "→ Emergency Change" - wenn_nein: "→ Weiter zu Frage 3" - - - reihenfolge: 3 - frage: "Erfüllt der Change ein Major-Kriterium (MAJ-01 bis MAJ-04)?" - wenn_ja: "→ Major Change" - wenn_nein: "→ Normal Change" - - flussdiagramm: | - Change Request - │ - ▼ - ┌─────────────────────────────┐ - │ Standard Change-Modell │──► Ja ──► STANDARD - │ vorhanden? │ - └─────────────────────────────┘ - │ Nein - ▼ - ┌─────────────────────────────┐ - │ Kritische Dringlichkeit? │──► Ja ──► EMERGENCY - │ (Sicherheit/Verfügbarkeit) │ - └─────────────────────────────┘ - │ Nein - ▼ - ┌─────────────────────────────┐ - │ Major-Kriterium erfüllt? │──► Ja ──► MAJOR - │ (MAJ-01 bis MAJ-04) │ - └─────────────────────────────┘ - │ Nein - ▼ - NORMAL - - hochstufung: - beschreibung: | - Der SO kann einen Change jederzeit hochstufen, wenn sich während - der Bearbeitung herausstellt, dass die initiale Klassifizierung - nicht angemessen war. - - regel: | - - Normal → Major: SO stellt Change der SOR zur Autorisierung vor - - Standard → Normal: SO übernimmt Einzelfallentscheidung - - Jede Stufe → Emergency: Bei kritischem Sicherheits-/Verfügbarkeitsproblem - - dokumentation: | - Hochstufung wird im Change Request dokumentiert mit Begründung. - - dokumentation: - beschreibung: | - Die Klassifizierung wird im Change Request / Ticket dokumentiert. - - mindestangaben: - - "Change-Typ (Standard/Normal/Major/Emergency)" - - "Bei Normal/Major: Kurzbegründung" - - "Bei Major: Referenz auf erfülltes Kriterium (MAJ-01 bis MAJ-04)" - -# ============================================================================= -# 4. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - # --------------------------------------------------------------------------- - # SCHNITTSTELLE: SHM-ROUTING - # --------------------------------------------------------------------------- - shm_routing: - - beschreibung: | - SHM führt eine Ersteinschätzung durch (Request / Change / Demand). - Diese Ersteinschätzung ist eine Orientierung, nicht verbindlich. - Die verbindliche Klassifizierung erfolgt durch den SO. - - zwei_stufen_modell: - stufe_1: - name: "SHM-Ersteinschätzung" - verantwortlich: "Stakeholder-Manager" - ergebnis: "Routing zu Service Desk / SO / DPM" - charakter: "Orientierung" - - stufe_2: - name: "SO-Klassifizierung" - verantwortlich: "Service Owner" - ergebnis: "Standard / Normal / Major / Emergency" - charakter: "Verbindlich" - - korrektur: | - Wenn SO feststellt, dass SHM-Routing nicht passt: - - Change ist eigentlich Demand → SO gibt zurück an SHM/DPM - - Demand ist eigentlich Change → SO übernimmt und klassifiziert - - referenz: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLE: SERVICE TRANSITION - # --------------------------------------------------------------------------- - service_transition: - - beschreibung: | - Nach SOR-Autorisierung durchläuft ein Major Change den regulären - Service-Lifecycle ab dem von der SOR festgelegten Einstiegspunkt - (Design oder Transition). Die Lifecycle-Gates sind dabei reguläre - Gates – keine gesonderte Major-Change-Governance. - - trigger: "SOR autorisiert Major Change und legt Einstiegspunkt fest" - - uebergabe: - verantwortlich: "Service Owner" - aktion: "SO führt Major Change ab festgelegtem Einstiegspunkt im regulären Lifecycle durch" - artefakt: "Change Request wird zum Transition-/Design-Steckbrief erweitert" - - rueckweg: | - Die regulären Lifecycle-Gates (Gate 1, 2, 3) gelten unverändert. - Bei Rückweisung an einem Gate: reguläres Gate-Verfahren. - - referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLE: PROBLEM MANAGEMENT - # --------------------------------------------------------------------------- - problem_management: - - beschreibung: | - Problem Management identifiziert strukturelle Ursachen für Incidents. - Permanente Lösungen werden über Change Enablement umgesetzt. - - ablauf: - - schritt: 1 - beschreibung: "Problem Manager identifiziert permanente Lösung" - verantwortlich: "Problem Manager / Service Owner" - - - schritt: 2 - beschreibung: "Change Request wird erstellt" - verantwortlich: "Problem Manager" - inhalt: - - "Verweis auf Problem Record" - - "Beschreibung der Ursache" - - "Vorgeschlagene Lösung" - - - schritt: 3 - beschreibung: "SO klassifiziert den Change" - verantwortlich: "Service Owner" - - - schritt: 4 - beschreibung: "Change wird gemäß Typ bearbeitet" - verantwortlich: "Je nach Change-Typ" - - - schritt: 5 - beschreibung: "Problem Record wird nach erfolgreicher Umsetzung geschlossen" - verantwortlich: "Problem Manager" - - referenz: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLE: DPM (ABGRENZUNG CHANGE VS. DEMAND) - # --------------------------------------------------------------------------- - dpm_abgrenzung: - - beschreibung: | - Die Abgrenzung zwischen Change und Demand basiert auf der Frage: - "Bleibt der Service im Kern derselbe?" - - kriterium: "Service-Identität" - - proxy_fragen: - beschreibung: | - Da "Service-Identität" abstrakt ist, helfen folgende Proxy-Fragen: - - fragen: - - "Braucht es einen neuen Katalog-Eintrag?" - - "Ist ein neuer Service Owner erforderlich?" - - "Muss eine neue Service-Definition erstellt werden?" - - entscheidungsregel: | - - Mindestens eine Proxy-Frage mit "Ja" → Demand (→ DPM) - - Alle Proxy-Fragen mit "Nein" → Change (ggf. Major) - - grauzone: | - Bei Unsicherheit: - - SO bespricht mit SPM - - Im Zweifel: Als Major Change starten, bei Gate 1 kann SOR - entscheiden, ob Rückgabe an DPM erforderlich - -# ============================================================================= -# 5. GOVERNANCE -# ============================================================================= - -governance: - - # --------------------------------------------------------------------------- - # CHANGE AUTHORITY MATRIX - # --------------------------------------------------------------------------- - change_authority_matrix: - - beschreibung: | - Die Change Authority ist die Rolle/Instanz, die einen Change autorisiert. - Sie variiert je nach Change-Typ und Risiko. - - matrix: - - change_typ: "Standard" - authority: "Pre-authorized (via Change-Modell)" - genehmigung_durch: "Entfällt (einmalig bei Modell-Freigabe)" - - - change_typ: "Normal" - authority: "Service Owner" - genehmigung_durch: "SO-Einzelentscheidung" - - - change_typ: "Normal (Cross-Service)" - authority: "Service Owner + SPM" - genehmigung_durch: "SO-Entscheidung nach SPM-Konsultation" - - - change_typ: "Major" - authority: "SOR" - genehmigung_durch: "SOR-Autorisierung (einmalig, inkl. Festlegung Einstiegspunkt)" - hinweis: "EIN Entscheidungspunkt: initiale Autorisierung. Danach regulärer Lifecycle mit regulären Gates." - - - change_typ: "Emergency" - authority: "Betrieb/Support" - genehmigung_durch: "Sofortumsetzung, nachträgliche Dokumentation" - - # --------------------------------------------------------------------------- - # WARTUNGSFENSTER KRITISCHE SERVICES - # --------------------------------------------------------------------------- - wartungsfenster_kritische_services: - - governance_referenz: "GOV-CE-004" - - beschreibung: | - Für Services mit Kritikalitätsstufe 'geschaeftskritisch' (gemäß - Service-Definition) gelten besondere Anforderungen an die Change-Planung. - - referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet" - - anforderungen: - - id: "WF-01" - beschreibung: "Wartungsarbeiten bevorzugt außerhalb der Kernarbeitszeiten" - hinweis: "Kernarbeitszeiten gemäß Service-Definition (verfuegbarkeit.servicezeit)" - - - id: "WF-02" - beschreibung: "Vorabkommunikation an betroffene Nutzergruppen (mind. 48h)" - ausnahme: "Emergency Changes sind hiervon ausgenommen" - - - id: "WF-03" - beschreibung: "Rollback-Plan muss vor Durchführung dokumentiert sein" - hinweis: "Gilt auch für Normal Changes an kritischen Services" - - - id: "WF-04" - beschreibung: "Bei Major Changes: Abstimmung mit Service Owner und ggf. Kundenvertretung" - hinweis: "Erhöhte Sorgfaltspflicht bei geschäftskritischen Services" - - impact_auf_klassifizierung: | - Die Geschäftskritikalität eines Services beeinflusst nicht die - Change-Typ-Klassifizierung (Standard/Normal/Major/Emergency), - sondern die Umsetzungsmodalitäten (Zeitfenster, Kommunikation, Rollback). - - # --------------------------------------------------------------------------- - # ESKALATION - # --------------------------------------------------------------------------- - eskalation: - - bei_unsicherheit: - beschreibung: | - Wenn der SO bei der Klassifizierung oder Bewertung unsicher ist, - kann er formlos Rücksprache mit SPM halten. - verfahren: "Formlos (Gespräch, E-Mail, Teams)" - ergebnis: "SPM gibt Einschätzung, SO entscheidet" - - bei_cross_service: - beschreibung: | - Bei Changes mit Cross-Service-Impact wird SPM einbezogen. - verfahren: "SO informiert SPM, SPM gibt Einschätzung" - bei_dissens: "Eskalation an SOR" - - bei_so_dpm_unklarheit: - beschreibung: | - Wenn unklar ist, ob etwas ein Change oder Demand ist. - verfahren: "SO bespricht mit SPM und/oder DPM (ROUTE-SO)" - bei_dissens: "Klärung bilateral mit Service Owner (GOV-SHM-029) oder Eskalation an DSR" - - # --------------------------------------------------------------------------- - # TRANSPARENZ - # --------------------------------------------------------------------------- - transparenz: - - change_modelle: - regel: "SPM erhält Kopie aller Change-Modelle zur Kenntnis" - zweck: "Portfolio-Transparenz, nicht Genehmigung" - frequenz: "Bei Erstellung/Änderung eines Change-Modells" - - major_changes: - regel: "Alle Major Changes werden in SOR behandelt" - dokumentation: "SOR-Protokoll" - - reporting: - mvp_status: "Kein formales Change-Reporting im MVP" - hinweis: "Kann bei Bedarf später ergänzt werden" - -# ============================================================================= -# 6. ABSCHLUSS -# ============================================================================= - -abschluss: - - kriterium: | - Ein Change gilt als abgeschlossen, wenn der Service Owner die - erfolgreiche Umsetzung bestätigt hat. - - bestaetigung: - verantwortlich: "Service Owner" - form: "Dokumentiert im Change Request / Ticket" - inhalt: - - "Change wurde wie geplant umgesetzt" - - "Service funktioniert wie erwartet" - - "Keine unerwarteten Auswirkungen" - - bei_problemen: | - Wenn nach Umsetzung Probleme auftreten: - - Rollback prüfen (wenn möglich und sinnvoll) - - Incident erstellen (wenn Service-Störung) - - Ggf. weiteren Change initiieren (Korrektur) - - post_implementation_review: - mvp_status: "Nicht formalisiert" - beschreibung: | - Im MVP gibt es keinen formalen Post-Implementation-Review-Prozess. - Der SO bestätigt den Abschluss und beobachtet den Service. - - Bei wiederkehrenden Problemen nach Changes kann ein formaler - PIR-Prozess später ergänzt werden. - -# ============================================================================= -# 8. OFFENE PUNKTE / WEITERENTWICKLUNG -# ============================================================================= - -offene_punkte: - - - id: "OPEN-CE-001" - thema: "Change Schedule" - beschreibung: | - ITIL4 sieht einen Change Schedule zur Koordination vor. - Im MVP nicht implementiert. - prioritaet: "niedrig" - trigger_fuer_ergaenzung: "Wenn Koordinationsprobleme auftreten" - - - id: "OPEN-CE-002" - thema: "Post-Implementation Review" - beschreibung: | - Formaler PIR-Prozess ist im MVP nicht vorgesehen. - prioritaet: "niedrig" - trigger_fuer_ergaenzung: "Wenn wiederkehrende Probleme nach Changes auftreten" - - - id: "OPEN-CE-003" - thema: "Produkt/Infrastruktur-Changes" - beschreibung: | - Changes ohne Service-Bezug sind ausgeklammert (GOV-CE-002). - prioritaet: "mittel" - trigger_fuer_ergaenzung: "Bei Produkt-Konzeption in späterer Phase" - - - id: "OPEN-CE-004" - thema: "Formale Cross-Service-Schwellenwerte" - beschreibung: | - Aktuell SO-Ermessen. Ggf. später Präzisierung basierend auf Erfahrung. - prioritaet: "niedrig" - trigger_fuer_ergaenzung: "Wenn operative Probleme auftreten" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.3" - datum: "2026-02-19" - aenderung: | - Major-Change-Governance vereinfacht (Kundenvorschlag): - - SOR hat bei Major Changes genau EINE Entscheidung (initiale Autorisierung) - - Bisheriges Zwei-Entscheidungspunkte-Modell (Entry + Gate 3) aufgelöst - - Nach SOR-Autorisierung: Major Change durchläuft regulären Lifecycle - (Design/Transition) je nach Einstiegspunkt - - SOR legt als Teil der Autorisierung den Einstiegspunkt fest - - Alle Lifecycle-Gates (Gate 1, 2, 3) sind reguläre Gates - - Change Authority Matrix, Verfahren, Schnittstelle Transition angepasst - autor: "DIGITOM-Projekt" - kontext: "Vereinfachung auf Basis Kunden-Annotation: Major Change kann diverse Wege nehmen" - - - version: "1.2" - datum: "2026-01-31" - aenderung: | - Korrektur Major-Change-Routing: - - Verfahren präzisiert: SOR-Autorisierung vor Entry in Transition erforderlich - - Change Authority Matrix ergänzt: Zwei Entscheidungspunkte (Entry + Gate 3) - - Klarstellung: Major Change unterscheidet sich vom Normal Change durch - die obligatorische SOR-Autorisierung, nicht nur durch die Gate-3-Freigabe - autor: "DIGITOM-Projekt" - kontext: "Konzeptionelle Korrektur auf Basis Review" - - - version: "1.1" - datum: "2026-01-28" - aenderung: | - Ergänzung Wartungsfenster kritische Services: - - Neuer Abschnitt 'wartungsfenster_kritische_services' (GOV-CE-004) - - Anforderungen WF-01 bis WF-04 für geschäftskritische Services - - Referenz auf Service-Kritikalität aus spm_schema_service-definition.yaml - autor: "DIGITOM-Projekt" - kontext: "Integration Geschäftskritikalität in Change-Planung" - - - version: "1.0" - datum: "2025-12-17" - aenderung: | - Initiale Erstellung des Change Enablement Konzepts. - - Inhalt: - - Change-Typen (Standard, Normal, Major, Emergency) - - Klassifizierungsverfahren - - Change Authority Matrix - - Schnittstellen (SHM, Transition, Problem Management, DPM) - - Governance-Entscheidungen GOV-CE-001 bis GOV-CE-003 - - Konsolidiert aus: - - GOV-TR-003 (Major-Kriterien) - - Klärungen CE-01 bis CE-03 +# ============================================================================= +# KONZEPT: CHANGE ENABLEMENT (P-03) +# ============================================================================= +# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/03_practices/ +# Dateiname: spm_practice_change-enablement.yaml +# ============================================================================= + +metadata: + id: "P-03" + name: "Change Enablement" + version: "1.3" + status: "draft" + erstellt: "2025-12-17" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "practice-konzept" + itil4_referenz: "Change Enablement Practice" + + beschreibung: | + Rahmenkonzept für die kontrollierte Durchführung von Service-Änderungen. + Definiert Change-Typen, Klassifizierungslogik, Autorisierungsverfahren + und Schnittstellen zu angrenzenden Prozessen. + + Ziel: Erfolgreiche Changes ermöglichen bei angemessener Risikokontrolle. + Prinzip: So wenig Governance wie nötig, so viel wie erforderlich. + + referenzen: + service_transition: "02a_lifecycle-konzepte/konzept_service-transition.yaml" + problem_management: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml" + shm_bedarfsbewertung: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" + dpm_klassifizierung: "#01_demand-portfolio-management/#01.1_documentation/dpm_demand-klassifizierung.yaml" + governance_log: "spm_governance-entscheidungen-log.yaml" + +# ============================================================================= +# 1. EINORDNUNG UND SCOPE +# ============================================================================= + +einordnung: + + zweck: | + Change Enablement stellt sicher, dass Service-Änderungen kontrolliert, + risikobewusst und effizient durchgeführt werden. Die Practice balanciert + zwischen Agilität (schnelle Umsetzung) und Stabilität (Schutz des Betriebs). + + itil4_definition: | + "The purpose of the change enablement practice is to maximize the number + of successful service and product changes by ensuring that risks have been + properly assessed, authorizing changes to proceed, and managing the + change schedule." + + scope: + + in_scope: + - "Änderungen an bestehenden Services" + - "Service-Erweiterungen und -Optimierungen" + - "Technische Updates mit Service-Bezug" + - "Konfigurationsänderungen an Service-Komponenten" + - "Changes aus Problem Management (permanente Lösungen)" + + out_of_scope: + - typ: "Neue Services" + routing: "Service Transition (vollständiger Lifecycle)" + referenz: "konzept_service-transition.yaml" + + - typ: "Demands (neue Services / grundlegende Neugestaltung)" + routing: "Demand Portfolio Management" + referenz: "dpm_funktionsbeschreibung.yaml" + + - typ: "Service Requests" + routing: "Request Management (Katalog-basiert)" + referenz: "sub-practice_request-management.yaml" + + - typ: "Infrastruktur ohne Service-Bezug" + routing: "Produkt-Ebene (nicht in aktueller Phase)" + hinweis: "Siehe Abgrenzung Produkt" + + abgrenzung_produkt: + governance_referenz: "GOV-CE-002" + + vermerk: | + Infrastruktur-Änderungen ohne direkten Service-Bezug (z.B. Netzwerk- + Wartung, Basis-Infrastruktur) sind der Produkt-Ebene zuzuordnen. + + Da die Produkt-Konzeption in der aktuellen Projektphase nicht im Fokus + steht (Priorisierung Kunden-/Service-Sicht), wird dieser Bereich + bewusst ausgeklammert. + + Merke: Bei späterer Produkt-Konzeption ist Change Enablement für + Produkte/Infrastruktur zu ergänzen. + + praktische_regel: | + Frage: "Hat diese Änderung Auswirkungen auf einen Service im Katalog?" + - Ja → Change Enablement (dieses Konzept) + - Nein → Operativer Betrieb oder Produkt-Management + +# ============================================================================= +# 2. CHANGE-TYPEN +# ============================================================================= + +change_typen: + + uebersicht: + beschreibung: | + DIGITOM unterscheidet vier Change-Typen, die sich in Risiko, + Autorisierungsverfahren und Dokumentationsaufwand unterscheiden. + + typen: + - "Standard Change (pre-authorized)" + - "Normal Change (SO-Entscheidung)" + - "Major Change (SOR-autorisierungspflichtig)" + - "Emergency Change (Sofortumsetzung)" + + # --------------------------------------------------------------------------- + # STANDARD CHANGE + # --------------------------------------------------------------------------- + standard_change: + + definition: | + Ein Standard Change ist ein wiederkehrender, risikoarmer Change, + der vollständig dokumentiert ist und ohne zusätzliche Genehmigung + durchgeführt werden kann. + + merkmale: + - "Wiederkehrend und vorhersehbar" + - "Risiko bekannt und gering" + - "Ablauf standardisiert und dokumentiert" + - "Ergebnis vorhersehbar" + + voraussetzungen: + - "Change-Modell existiert und ist dokumentiert" + - "Change-Modell wurde einmalig durch SO genehmigt" + - "Rollback-Verfahren ist definiert" + + change_modell: + + beschreibung: | + Ein Change-Modell dokumentiert das Verfahren für einen Standard Change. + Es wird einmalig erstellt und genehmigt. Danach ist der Change + pre-authorized – jede Ausführung benötigt keine weitere Genehmigung. + + verantwortung_erstellung: "Service Owner" + verantwortung_genehmigung: "Service Owner" + + inhalt: + - name: "Change-Bezeichnung" + beschreibung: "Eindeutiger Name für den Standard Change" + - name: "Anwendungsbereich" + beschreibung: "Wann/wo wird dieser Change angewendet?" + - name: "Auslöser" + beschreibung: "Was triggert diesen Change?" + - name: "Durchführungsschritte" + beschreibung: "Schritt-für-Schritt-Anleitung" + - name: "Beteiligte Rollen" + beschreibung: "Wer führt durch, wer wird informiert?" + - name: "Risikobewertung" + beschreibung: "Bekannte Risiken und Mitigationen" + - name: "Rollback-Verfahren" + beschreibung: "Wie wird rückgängig gemacht?" + - name: "Erwartete Dauer" + beschreibung: "Typischer Zeitaufwand" + + transparenz: | + SO dokumentiert Change-Modelle für seinen Service. + SPM erhält Kopie zur Kenntnis (nicht zur Genehmigung). + Dies dient der Portfolio-Transparenz, nicht der Kontrolle. + + autorisierung: | + Keine weitere Genehmigung bei Ausführung erforderlich. + Die Genehmigung erfolgte einmalig bei Freigabe des Change-Modells. + + beispiele: + - "Passwort-Reset nach definiertem Verfahren" + - "Software-Update auf freigegebene Version" + - "Benutzer-Berechtigung gemäß Berechtigungskonzept" + - "Regelmäßige Wartungsarbeiten nach Wartungsplan" + + # --------------------------------------------------------------------------- + # NORMAL CHANGE + # --------------------------------------------------------------------------- + normal_change: + + definition: | + Ein Normal Change ist eine Service-Änderung, die weder als Standard + Change pre-authorized ist, noch die Kriterien für einen Major Change + erfüllt. Er erfordert eine Einzelfallentscheidung durch den Service Owner. + + merkmale: + - "Nicht wiederkehrend oder nicht standardisierbar" + - "Risiko überschaubar, aber nicht trivial" + - "Service-Identität bleibt erhalten" + - "Keine Transition-Gates erforderlich" + + change_authority: "Service Owner" + + verfahren: + + schritte: + - schritt: 1 + name: "Change Request" + beschreibung: "Anforderung wird dokumentiert (Ticket, E-Mail, etc.)" + verantwortlich: "Anfordernde Rolle" + + - schritt: 2 + name: "Klassifizierung" + beschreibung: "SO prüft: Standard? Normal? Major?" + verantwortlich: "Service Owner" + + - schritt: 3 + name: "Bewertung" + beschreibung: "SO bewertet Risiko, Aufwand, Auswirkungen" + verantwortlich: "Service Owner" + + - schritt: 4 + name: "Entscheidung" + beschreibung: "SO entscheidet: Freigabe / Ablehnung / Rückfragen" + verantwortlich: "Service Owner" + + - schritt: 5 + name: "Umsetzung" + beschreibung: "Change wird implementiert" + verantwortlich: "Betriebsteam / Projektteam" + + - schritt: 6 + name: "Abschluss" + beschreibung: "SO bestätigt erfolgreiche Umsetzung" + verantwortlich: "Service Owner" + + cross_service: + governance_referenz: "GOV-CE-003" + + erkennung: | + Der Service Owner ist verantwortlich für die Erkennung von + Cross-Service-Impact. Er kennt seinen Service und dessen + Abhängigkeiten am besten. + + eskalation: | + Bei Normal Changes mit potenziellem Cross-Service-Impact + bezieht der SO den SPM als "Zweite Augen" ein. + + SPM prüft aus Portfolio-Perspektive: + - Gibt es Auswirkungen auf andere Services? + - Sind andere Service Owner zu informieren/einzubeziehen? + - Ist eine SOR-Befassung erforderlich? + + schwellenwert: | + SO-Ermessen: "Im Zweifel SPM einbeziehen." + + Keine formalen Schwellenwerte im MVP. Die operative Erfahrung + wird zeigen, ob Präzisierung nötig ist. + + verfahren_bei_cross_service: + - "SO identifiziert potenziellen Cross-Service-Impact" + - "SO informiert SPM (formlos, z.B. kurze E-Mail/Teams)" + - "SPM gibt Einschätzung: 'Go' oder 'Abstimmung mit SO X nötig'" + - "Bei Bedarf: Bilaterale Abstimmung zwischen betroffenen SOs" + - "Bei Dissens oder Unklarheit: Eskalation an SOR" + + # --------------------------------------------------------------------------- + # MAJOR CHANGE + # --------------------------------------------------------------------------- + major_change: + + definition: | + Ein Major Change ist eine signifikante Service-Änderung, die die + Service-Identität berührt und daher eine SOR-Autorisierung erfordert. + Nach der Autorisierung durchläuft der Major Change den regulären + Service-Lifecycle (Design/Transition) je nach Einstiegspunkt. + + governance_referenz: "GOV-TR-003" + + merkmale: + - "Verändert wesentliche Service-Eigenschaften" + - "Höheres Risiko für Betrieb und Stakeholder" + - "Erfordert initiale Governance-Entscheidung durch SOR (Autorisierung)" + - "Durchläuft nach Autorisierung regulären Lifecycle (Design/Transition) je nach Einstiegspunkt" + + kriterien: + beschreibung: | + Ein Change gilt als Major, wenn mindestens eines der folgenden + Kriterien erfüllt ist. Die Bewertung erfolgt durch den SO nach + dem Prinzip "Informed Judgment". + + liste: + - id: "MAJ-01" + kriterium: "Änderung der Service-Definition" + beschreibung: "Der Scope, die Zielgruppe oder die Kernfunktionalität des Service ändert sich." + beispiele: + - "Service wird auf neue Nutzergruppe ausgeweitet" + - "Kernfunktion wird hinzugefügt oder entfernt" + - "Service-Scope wird signifikant erweitert/eingeschränkt" + + - id: "MAJ-02" + kriterium: "Änderung der SLA/SLO-Vereinbarungen" + beschreibung: "Die vereinbarten Service Levels ändern sich." + beispiele: + - "Verfügbarkeitsziel wird angepasst" + - "Support-Zeiten werden geändert" + - "Performance-Ziele werden neu definiert" + + - id: "MAJ-03" + kriterium: "Signifikante Architektur-Änderung" + beschreibung: "Die technische Grundstruktur des Service ändert sich wesentlich." + beispiele: + - "Wechsel der Basis-Plattform" + - "Neue kritische Abhängigkeit zu anderem System" + - "Grundlegende Änderung des Technologie-Stacks" + bei_unsicherheit: | + Bei Unsicherheit, ob eine Architektur-Änderung "signifikant" ist: + Architektur-Rolle konsultieren. + + - id: "MAJ-04" + kriterium: "DPM-Komplexität 'komplex' oder 'hochkomplex'" + beschreibung: | + Der Change resultiert aus einem Demand, der im DPM als + komplex oder hochkomplex klassifiziert wurde. + referenz: "dpm_demand-klassifizierung.yaml" + hinweis: | + Dieses Kriterium greift, wenn ein Demand durch DPM bearbeitet + wurde und als Umsetzungsauftrag an SPM übergeht. + + verfahren: | + Major Changes erfordern EINE SOR-Autorisierung. Danach durchlaufen + sie den regulären Service-Lifecycle. Der Ablauf ist: + + 1. SO klassifiziert Change als Major + 2. SO stellt Major Change der SOR vor (Autorisierung) + 3. SOR entscheidet: Autorisierung / Autorisierung mit Auflagen / Ablehnung + - Als Teil der Autorisierung legt SOR den Einstiegspunkt fest + (Design oder Transition), je nach Reifegrad der Änderung + 4. Bei Autorisierung: Major Change durchläuft regulären Lifecycle + ab dem festgelegten Einstiegspunkt + 5. Alle weiteren Gates (Gate 1, Gate 2, Gate 3) sind reguläre + Lifecycle-Gates – keine gesonderte Major-Change-Entscheidung + + Wichtig: Die SOR hat bei einem Major Change genau EINE Entscheidung: + die initiale Autorisierung (oder Ablehnung). Danach ist der Major Change + eine Änderung an einem bestehenden Service und durchläuft als solcher + die vorgesehenen Lifecycle-Stufen und -Gates. + Dies unterscheidet ihn vom Normal Change, bei dem der SO allein entscheidet. + + Details siehe konzept_service-transition.yaml + + referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml" + + # --------------------------------------------------------------------------- + # EMERGENCY CHANGE + # --------------------------------------------------------------------------- + emergency_change: + governance_referenz: "GOV-CE-001" + + definition: | + Ein Emergency Change ist eine Änderung, die aufgrund kritischer + Sicherheits- oder Verfügbarkeitsprobleme sofort umgesetzt werden muss. + Das normale Genehmigungsverfahren wird zugunsten der Geschwindigkeit + verkürzt. + + merkmale: + - "Kritische Dringlichkeit (Sicherheit oder Verfügbarkeit)" + - "Sofortumsetzung erforderlich" + - "Dokumentation erfolgt nachträglich" + - "SO wird informiert, nicht um Genehmigung gefragt" + + ausloeser: + - "Kritische Sicherheitslücke (z.B. aktiv ausgenutzte Schwachstelle)" + - "Service-Ausfall mit hohem Business-Impact" + - "Datenverlust-Risiko" + - "Compliance-Verstoß mit sofortigem Handlungsbedarf" + + verfahren: + + autorisierung: | + Sofortumsetzung durch Betrieb/Support ohne vorherige Genehmigung. + Die Entscheidung zur Sofortumsetzung trifft die handelnde Rolle + (z.B. Operations Manager, Support Manager, L2-Agent). + + so_rolle: | + Der Service Owner wird informiert, nicht um Genehmigung gefragt. + Information erfolgt parallel zur oder unmittelbar nach der Umsetzung. + + dokumentation: | + Nachträgliche Dokumentation innerhalb von 24 Stunden: + - Was wurde geändert? + - Warum war Sofortumsetzung erforderlich? + - Wer hat entschieden/umgesetzt? + - Welche Auswirkungen hatte der Change? + + nachbereitung: | + Nach Abschluss des Emergency Change: + - SO prüft: Ist Nacharbeit erforderlich? + - Bei Bedarf: Normal Change für "saubere" Lösung + - Bei wiederkehrendem Muster: Problem Record erstellen + + abgrenzung: | + Nicht jeder dringende Change ist ein Emergency Change. + + Emergency = "Muss JETZT passieren, sonst kritischer Schaden" + Dringend = "Sollte schnell passieren" → Beschleunigter Normal Change + +# ============================================================================= +# 3. KLASSIFIZIERUNGSVERFAHREN +# ============================================================================= + +klassifizierung: + + verantwortung: "Service Owner" + + prinzip: | + Die Klassifizierung erfolgt nach dem Prinzip "Informed Judgment". + Der SO trifft eine fachliche Einschätzung basierend auf seinem + Service-Wissen. Es gibt keine mechanischen Schwellenwerte. + + entscheidungslogik: + + beschreibung: | + Der SO durchläuft folgende Prüffragen, um den Change-Typ zu bestimmen. + + prueffragen: + - reihenfolge: 1 + frage: "Ist das ein dokumentierter, pre-authorized Standard Change?" + wenn_ja: "→ Standard Change" + wenn_nein: "→ Weiter zu Frage 2" + + - reihenfolge: 2 + frage: "Erfordert die Situation Sofortumsetzung (Sicherheit/Verfügbarkeit)?" + wenn_ja: "→ Emergency Change" + wenn_nein: "→ Weiter zu Frage 3" + + - reihenfolge: 3 + frage: "Erfüllt der Change ein Major-Kriterium (MAJ-01 bis MAJ-04)?" + wenn_ja: "→ Major Change" + wenn_nein: "→ Normal Change" + + flussdiagramm: | + Change Request + │ + ▼ + ┌─────────────────────────────┐ + │ Standard Change-Modell │──► Ja ──► STANDARD + │ vorhanden? │ + └─────────────────────────────┘ + │ Nein + ▼ + ┌─────────────────────────────┐ + │ Kritische Dringlichkeit? │──► Ja ──► EMERGENCY + │ (Sicherheit/Verfügbarkeit) │ + └─────────────────────────────┘ + │ Nein + ▼ + ┌─────────────────────────────┐ + │ Major-Kriterium erfüllt? │──► Ja ──► MAJOR + │ (MAJ-01 bis MAJ-04) │ + └─────────────────────────────┘ + │ Nein + ▼ + NORMAL + + hochstufung: + beschreibung: | + Der SO kann einen Change jederzeit hochstufen, wenn sich während + der Bearbeitung herausstellt, dass die initiale Klassifizierung + nicht angemessen war. + + regel: | + - Normal → Major: SO stellt Change der SOR zur Autorisierung vor + - Standard → Normal: SO übernimmt Einzelfallentscheidung + - Jede Stufe → Emergency: Bei kritischem Sicherheits-/Verfügbarkeitsproblem + + dokumentation: | + Hochstufung wird im Change Request dokumentiert mit Begründung. + + dokumentation: + beschreibung: | + Die Klassifizierung wird im Change Request / Ticket dokumentiert. + + mindestangaben: + - "Change-Typ (Standard/Normal/Major/Emergency)" + - "Bei Normal/Major: Kurzbegründung" + - "Bei Major: Referenz auf erfülltes Kriterium (MAJ-01 bis MAJ-04)" + +# ============================================================================= +# 4. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + # --------------------------------------------------------------------------- + # SCHNITTSTELLE: SHM-ROUTING + # --------------------------------------------------------------------------- + shm_routing: + + beschreibung: | + SHM führt eine Ersteinschätzung durch (Request / Change / Demand). + Diese Ersteinschätzung ist eine Orientierung, nicht verbindlich. + Die verbindliche Klassifizierung erfolgt durch den SO. + + zwei_stufen_modell: + stufe_1: + name: "SHM-Ersteinschätzung" + verantwortlich: "Stakeholder-Manager" + ergebnis: "Routing zu Service Desk / SO / DPM" + charakter: "Orientierung" + + stufe_2: + name: "SO-Klassifizierung" + verantwortlich: "Service Owner" + ergebnis: "Standard / Normal / Major / Emergency" + charakter: "Verbindlich" + + korrektur: | + Wenn SO feststellt, dass SHM-Routing nicht passt: + - Change ist eigentlich Demand → SO gibt zurück an SHM/DPM + - Demand ist eigentlich Change → SO übernimmt und klassifiziert + + referenz: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLE: SERVICE TRANSITION + # --------------------------------------------------------------------------- + service_transition: + + beschreibung: | + Nach SOR-Autorisierung durchläuft ein Major Change den regulären + Service-Lifecycle ab dem von der SOR festgelegten Einstiegspunkt + (Design oder Transition). Die Lifecycle-Gates sind dabei reguläre + Gates – keine gesonderte Major-Change-Governance. + + trigger: "SOR autorisiert Major Change und legt Einstiegspunkt fest" + + uebergabe: + verantwortlich: "Service Owner" + aktion: "SO führt Major Change ab festgelegtem Einstiegspunkt im regulären Lifecycle durch" + artefakt: "Change Request wird zum Transition-/Design-Steckbrief erweitert" + + rueckweg: | + Die regulären Lifecycle-Gates (Gate 1, 2, 3) gelten unverändert. + Bei Rückweisung an einem Gate: reguläres Gate-Verfahren. + + referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLE: PROBLEM MANAGEMENT + # --------------------------------------------------------------------------- + problem_management: + + beschreibung: | + Problem Management identifiziert strukturelle Ursachen für Incidents. + Permanente Lösungen werden über Change Enablement umgesetzt. + + ablauf: + - schritt: 1 + beschreibung: "Problem Manager identifiziert permanente Lösung" + verantwortlich: "Problem Manager / Service Owner" + + - schritt: 2 + beschreibung: "Change Request wird erstellt" + verantwortlich: "Problem Manager" + inhalt: + - "Verweis auf Problem Record" + - "Beschreibung der Ursache" + - "Vorgeschlagene Lösung" + + - schritt: 3 + beschreibung: "SO klassifiziert den Change" + verantwortlich: "Service Owner" + + - schritt: 4 + beschreibung: "Change wird gemäß Typ bearbeitet" + verantwortlich: "Je nach Change-Typ" + + - schritt: 5 + beschreibung: "Problem Record wird nach erfolgreicher Umsetzung geschlossen" + verantwortlich: "Problem Manager" + + referenz: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLE: DPM (ABGRENZUNG CHANGE VS. DEMAND) + # --------------------------------------------------------------------------- + dpm_abgrenzung: + + beschreibung: | + Die Abgrenzung zwischen Change und Demand basiert auf der Frage: + "Bleibt der Service im Kern derselbe?" + + kriterium: "Service-Identität" + + proxy_fragen: + beschreibung: | + Da "Service-Identität" abstrakt ist, helfen folgende Proxy-Fragen: + + fragen: + - "Braucht es einen neuen Katalog-Eintrag?" + - "Ist ein neuer Service Owner erforderlich?" + - "Muss eine neue Service-Definition erstellt werden?" + + entscheidungsregel: | + - Mindestens eine Proxy-Frage mit "Ja" → Demand (→ DPM) + - Alle Proxy-Fragen mit "Nein" → Change (ggf. Major) + + grauzone: | + Bei Unsicherheit: + - SO bespricht mit SPM + - Im Zweifel: Als Major Change starten, bei Gate 1 kann SOR + entscheiden, ob Rückgabe an DPM erforderlich + +# ============================================================================= +# 5. GOVERNANCE +# ============================================================================= + +governance: + + # --------------------------------------------------------------------------- + # CHANGE AUTHORITY MATRIX + # --------------------------------------------------------------------------- + change_authority_matrix: + + beschreibung: | + Die Change Authority ist die Rolle/Instanz, die einen Change autorisiert. + Sie variiert je nach Change-Typ und Risiko. + + matrix: + - change_typ: "Standard" + authority: "Pre-authorized (via Change-Modell)" + genehmigung_durch: "Entfällt (einmalig bei Modell-Freigabe)" + + - change_typ: "Normal" + authority: "Service Owner" + genehmigung_durch: "SO-Einzelentscheidung" + + - change_typ: "Normal (Cross-Service)" + authority: "Service Owner + SPM" + genehmigung_durch: "SO-Entscheidung nach SPM-Konsultation" + + - change_typ: "Major" + authority: "SOR" + genehmigung_durch: "SOR-Autorisierung (einmalig, inkl. Festlegung Einstiegspunkt)" + hinweis: "EIN Entscheidungspunkt: initiale Autorisierung. Danach regulärer Lifecycle mit regulären Gates." + + - change_typ: "Emergency" + authority: "Betrieb/Support" + genehmigung_durch: "Sofortumsetzung, nachträgliche Dokumentation" + + # --------------------------------------------------------------------------- + # WARTUNGSFENSTER KRITISCHE SERVICES + # --------------------------------------------------------------------------- + wartungsfenster_kritische_services: + + governance_referenz: "GOV-CE-004" + + beschreibung: | + Für Services mit Kritikalitätsstufe 'geschaeftskritisch' (gemäß + Service-Definition) gelten besondere Anforderungen an die Change-Planung. + + referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet" + + anforderungen: + - id: "WF-01" + beschreibung: "Wartungsarbeiten bevorzugt außerhalb der Kernarbeitszeiten" + hinweis: "Kernarbeitszeiten gemäß Service-Definition (verfuegbarkeit.servicezeit)" + + - id: "WF-02" + beschreibung: "Vorabkommunikation an betroffene Nutzergruppen (mind. 48h)" + ausnahme: "Emergency Changes sind hiervon ausgenommen" + + - id: "WF-03" + beschreibung: "Rollback-Plan muss vor Durchführung dokumentiert sein" + hinweis: "Gilt auch für Normal Changes an kritischen Services" + + - id: "WF-04" + beschreibung: "Bei Major Changes: Abstimmung mit Service Owner und ggf. Kundenvertretung" + hinweis: "Erhöhte Sorgfaltspflicht bei geschäftskritischen Services" + + impact_auf_klassifizierung: | + Die Geschäftskritikalität eines Services beeinflusst nicht die + Change-Typ-Klassifizierung (Standard/Normal/Major/Emergency), + sondern die Umsetzungsmodalitäten (Zeitfenster, Kommunikation, Rollback). + + # --------------------------------------------------------------------------- + # ESKALATION + # --------------------------------------------------------------------------- + eskalation: + + bei_unsicherheit: + beschreibung: | + Wenn der SO bei der Klassifizierung oder Bewertung unsicher ist, + kann er formlos Rücksprache mit SPM halten. + verfahren: "Formlos (Gespräch, E-Mail, Teams)" + ergebnis: "SPM gibt Einschätzung, SO entscheidet" + + bei_cross_service: + beschreibung: | + Bei Changes mit Cross-Service-Impact wird SPM einbezogen. + verfahren: "SO informiert SPM, SPM gibt Einschätzung" + bei_dissens: "Eskalation an SOR" + + bei_so_dpm_unklarheit: + beschreibung: | + Wenn unklar ist, ob etwas ein Change oder Demand ist. + verfahren: "SO bespricht mit SPM und/oder DPM (ROUTE-SO)" + bei_dissens: "Klärung bilateral mit Service Owner (GOV-SHM-029) oder Eskalation an DSR" + + # --------------------------------------------------------------------------- + # TRANSPARENZ + # --------------------------------------------------------------------------- + transparenz: + + change_modelle: + regel: "SPM erhält Kopie aller Change-Modelle zur Kenntnis" + zweck: "Portfolio-Transparenz, nicht Genehmigung" + frequenz: "Bei Erstellung/Änderung eines Change-Modells" + + major_changes: + regel: "Alle Major Changes werden in SOR behandelt" + dokumentation: "SOR-Protokoll" + + reporting: + mvp_status: "Kein formales Change-Reporting im MVP" + hinweis: "Kann bei Bedarf später ergänzt werden" + +# ============================================================================= +# 6. ABSCHLUSS +# ============================================================================= + +abschluss: + + kriterium: | + Ein Change gilt als abgeschlossen, wenn der Service Owner die + erfolgreiche Umsetzung bestätigt hat. + + bestaetigung: + verantwortlich: "Service Owner" + form: "Dokumentiert im Change Request / Ticket" + inhalt: + - "Change wurde wie geplant umgesetzt" + - "Service funktioniert wie erwartet" + - "Keine unerwarteten Auswirkungen" + + bei_problemen: | + Wenn nach Umsetzung Probleme auftreten: + - Rollback prüfen (wenn möglich und sinnvoll) + - Incident erstellen (wenn Service-Störung) + - Ggf. weiteren Change initiieren (Korrektur) + + post_implementation_review: + mvp_status: "Nicht formalisiert" + beschreibung: | + Im MVP gibt es keinen formalen Post-Implementation-Review-Prozess. + Der SO bestätigt den Abschluss und beobachtet den Service. + + Bei wiederkehrenden Problemen nach Changes kann ein formaler + PIR-Prozess später ergänzt werden. + +# ============================================================================= +# 8. OFFENE PUNKTE / WEITERENTWICKLUNG +# ============================================================================= + +offene_punkte: + + - id: "OPEN-CE-001" + thema: "Change Schedule" + beschreibung: | + ITIL4 sieht einen Change Schedule zur Koordination vor. + Im MVP nicht implementiert. + prioritaet: "niedrig" + trigger_fuer_ergaenzung: "Wenn Koordinationsprobleme auftreten" + + - id: "OPEN-CE-002" + thema: "Post-Implementation Review" + beschreibung: | + Formaler PIR-Prozess ist im MVP nicht vorgesehen. + prioritaet: "niedrig" + trigger_fuer_ergaenzung: "Wenn wiederkehrende Probleme nach Changes auftreten" + + - id: "OPEN-CE-003" + thema: "Produkt/Infrastruktur-Changes" + beschreibung: | + Changes ohne Service-Bezug sind ausgeklammert (GOV-CE-002). + prioritaet: "mittel" + trigger_fuer_ergaenzung: "Bei Produkt-Konzeption in späterer Phase" + + - id: "OPEN-CE-004" + thema: "Formale Cross-Service-Schwellenwerte" + beschreibung: | + Aktuell SO-Ermessen. Ggf. später Präzisierung basierend auf Erfahrung. + prioritaet: "niedrig" + trigger_fuer_ergaenzung: "Wenn operative Probleme auftreten" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.3" + datum: "2026-02-19" + aenderung: | + Major-Change-Governance vereinfacht (Kundenvorschlag): + - SOR hat bei Major Changes genau EINE Entscheidung (initiale Autorisierung) + - Bisheriges Zwei-Entscheidungspunkte-Modell (Entry + Gate 3) aufgelöst + - Nach SOR-Autorisierung: Major Change durchläuft regulären Lifecycle + (Design/Transition) je nach Einstiegspunkt + - SOR legt als Teil der Autorisierung den Einstiegspunkt fest + - Alle Lifecycle-Gates (Gate 1, 2, 3) sind reguläre Gates + - Change Authority Matrix, Verfahren, Schnittstelle Transition angepasst + autor: "DIGITOM-Projekt" + kontext: "Vereinfachung auf Basis Kunden-Annotation: Major Change kann diverse Wege nehmen" + + - version: "1.2" + datum: "2026-01-31" + aenderung: | + Korrektur Major-Change-Routing: + - Verfahren präzisiert: SOR-Autorisierung vor Entry in Transition erforderlich + - Change Authority Matrix ergänzt: Zwei Entscheidungspunkte (Entry + Gate 3) + - Klarstellung: Major Change unterscheidet sich vom Normal Change durch + die obligatorische SOR-Autorisierung, nicht nur durch die Gate-3-Freigabe + autor: "DIGITOM-Projekt" + kontext: "Konzeptionelle Korrektur auf Basis Review" + + - version: "1.1" + datum: "2026-01-28" + aenderung: | + Ergänzung Wartungsfenster kritische Services: + - Neuer Abschnitt 'wartungsfenster_kritische_services' (GOV-CE-004) + - Anforderungen WF-01 bis WF-04 für geschäftskritische Services + - Referenz auf Service-Kritikalität aus spm_schema_service-definition.yaml + autor: "DIGITOM-Projekt" + kontext: "Integration Geschäftskritikalität in Change-Planung" + + - version: "1.0" + datum: "2025-12-17" + aenderung: | + Initiale Erstellung des Change Enablement Konzepts. + + Inhalt: + - Change-Typen (Standard, Normal, Major, Emergency) + - Klassifizierungsverfahren + - Change Authority Matrix + - Schnittstellen (SHM, Transition, Problem Management, DPM) + - Governance-Entscheidungen GOV-CE-001 bis GOV-CE-003 + + Konsolidiert aus: + - GOV-TR-003 (Major-Kriterien) + - Klärungen CE-01 bis CE-03 autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-catalog-management.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-catalog-management.yaml index d3d0601..e016fc5 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-catalog-management.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-catalog-management.yaml @@ -1,814 +1,814 @@ -# ============================================================================= -# PRACTICE: SERVICE CATALOG MANAGEMENT -# ============================================================================= - -metadata: - id: "P-01" - name: "Service Catalog Management" - version: "0.2" - status: "draft" - erstellt: "2025-11-27" - aktualisiert: "2026-01-30" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "practice-konzept" - - funktion: - id: "SPM" - name: "Service-Portfolio-Management" - - taxonomie_referenz: "00_meta/digitom_taxonomie.yaml" - - beschreibung: > - Service Catalog Management stellt sicher, dass für jeden Service eine - klare, aktuelle, vollständige und verlässliche Beschreibung existiert – - und alle Stakeholder auf dieselbe Wahrheit zugreifen. Die Practice - fungiert als Informations-Governance über alle Services und bildet die - Brücke zwischen Service-Portfolio (strategisch), Service-Definition - (operativ) und Service Level Management (qualitativ). - - itil4_referenz: "Service Catalogue Management Practice" - - lifecycle_phasen: - - design - - transition - - operation - - review - - practice_owner: "Service-Portfolio-Manager (SPM)" - - konsolidierung_hinweis: > - Im MVP ist die Practice Owner-Rolle für SCM mit der SPM-Rolle - konsolidiert, um Rolleninflation zu vermeiden. Langfristig kann - eine Trennung sinnvoll sein. - - schnittstellen: - intern: - - modul: "P-02 Service Level Management" - art: "erhält von" - beschreibung: "SLS/SLA-Referenzen zur Publikation im Katalog" - - - modul: "B-01 Service Transition" - art: "bidirektional" - beschreibung: "Katalogaufnahme als Teil des Transition-Prozesses" - - - modul: "B-03 Service Review" - art: "bidirektional" - beschreibung: "Review-Ergebnisse können Katalogänderungen triggern" - - extern: - - partner: "Stakeholder-Management (SHM)" - kontext: "Qualitätssicherung Kundenverständlichkeit" - status: "SHM-Modul in Entwicklung" - - - partner: "ITSM-Tool (Request-Katalog)" - kontext: "Stammdatenlieferung für Service-Requests" - status: "Tool-Auswahl ausstehend" - -# ============================================================================= -# KERNKONZEPTE -# ============================================================================= - -kernkonzepte: - - # --------------------------------------------------------------------------- - # ZENTRALE ARTEFAKTE - # --------------------------------------------------------------------------- - artefakte: - beschreibung: > - SCM verwaltet zwei zentrale Artefakte, die in einer - Master-Derivat-Beziehung stehen. - - artefakte: - - name: "Service-Definition" - typ: "Master-Dokument" - beschreibung: > - Internes Dokument mit allen relevanten Informationen zu einem - Service. Single Source of Truth für DIGIT. - schema: "02.5_informationsmodell/spm_schema_service-definition.yaml" - verantwortung_erstellung: "Service Owner" - verantwortung_validierung: "SPM (als SCM Practice Owner)" - - - name: "Service-Steckbrief" - typ: "Derivat" - beschreibung: > - Kundenorientierter Auszug aus der Service-Definition. - Wird im Service-Katalog publiziert. - schema: "02.5_informationsmodell/spm_schema_service-steckbrief.yaml" - verantwortung_ableitung: "Service Owner" - verantwortung_freigabe: "SPM" - verantwortung_publikation: "SPM" - - beziehung: > - Der Service-Steckbrief wird aus der Service-Definition abgeleitet. - Änderungen an der Service-Definition können Aktualisierungen des - Steckbriefs erfordern. Das Mapping ist im Schema dokumentiert. - - # --------------------------------------------------------------------------- - # SERVICE-KATALOG - # --------------------------------------------------------------------------- - service_katalog: - beschreibung: > - Der Service-Katalog ist kein einzelnes Tool, sondern ein logisches - Konstrukt: die offizielle, konsolidierte Sicht auf alle angebotenen - Services des DIGIT mit ihren wesentlichen Merkmalen. - Diese Sicht wird in geeigneten Werkzeugen (z. B. Intranet-Portal, - ITSM-Tool, Dokumentation) für unterschiedliche Zielgruppen - bereitgestellt. - - inhalt: "Alle Service-Steckbriefe für Services im Status 'Live'" - - nicht_enthalten: - - "Services in der Pipeline (noch nicht live)" - - "Stillgelegte Services (retired)" - - "Interne Services (Kategorie I) – per Definition nicht im Katalog (GOV-SPM-I-001, GOV-SPM-I-003)" - - ausschlussregel_kategorie_I: - beschreibung: | - Der Service-Katalog enthält ausschließlich Kundenservices der - Kategorien A, B und C. Interne Services (Kategorie I) werden - NICHT im Katalog publiziert. Die Sichtbarkeit ist vollständig - aus der Service-Kategorie ableitbar – ein separates Attribut - service_sichtbarkeit existiert nicht. - governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003, VAL-007" - - publikationskanaele: - beschreibung: > - Der Katalog kann über verschiedene Kanäle zugänglich gemacht werden. - Die konkrete Implementierung ist nicht Teil dieser Practice-Definition. - - stakeholder_einbindung: - beschreibung: > - Das Stakeholder-Management (SHM) unterstützt bei der Formulierung - kundenverständlicher Texte und bei der Priorisierung von - Verbesserungsbedarfen aus Sicht der Ämter. - Im MVP ist dies optional, im Zielbild standardmäßig vorgesehen. - - anforderungen: - - "Barrierefreier Zugang für alle Zielgruppen" - - "Durchsuchbarkeit" - - "Aktualität (zeitnahe Publikation von Änderungen)" - - "Kategorie-basierte Sichtbarkeitssteuerung" - - moegliche_kanaele: - - "Intranet-Seite" - - "Self-Service-Portal" - - "ITSM-Tool (Request-Katalog-View)" - - "PDF-Export (für Offline-Nutzung)" - - verantwortung_inhalt: "SPM" - verantwortung_betrieb: "TBD (abhängig von Kanal)" - - # --------------------------------------------------------------------------- - # KATALOG-VIEWS - # --------------------------------------------------------------------------- - katalog_views: - beschreibung: > - Der Katalog unterstützt unterschiedliche Sichten für - unterschiedliche Zielgruppen. - - views: - - name: "Nutzer-View" - zielgruppe: "Alle Mitarbeitenden" - fokus: "Was gibt es? Was bekomme ich? Wie beantrage ich?" - inhalte: - - "Alle Basis-Services (Kategorie A)" - - "Alle Erweiterten Services (Kategorie B)" - - "Spezial-Services nur wenn berechtigt (Kategorie C)" - - - name: "Entscheider-View" - zielgruppe: "Amtsleitungen, Kundenvertretungen" - fokus: "Welche Services nutzt mein Amt? Welche Qualität? Welche Kosten?" - inhalte: - - "Alle Services mit SLA/SLS-Referenzen" - - "Service-Owner-Kontakte" - - "Berechtigungslogik" - - - name: "Request-View" - zielgruppe: "Mitarbeitende (im ITSM-Tool)" - fokus: "Was kann ich bestellen/beantragen?" - inhalte: - - "Bestellbare Services" - - "Beantragungswege" - - "Voraussetzungen" - hinweis: "Diese View wird im ITSM-Tool realisiert, nicht im Katalog selbst" - - # --------------------------------------------------------------------------- - # KATEGORIEN IM KATALOG - # --------------------------------------------------------------------------- - kategorien_logik: - beschreibung: > - Die Service-Kategorien A/B/C (definiert in P-02 SLM) haben - direkte Auswirkungen auf die Katalogdarstellung. - - kategorie_a: - name: "Basis-Services" - katalog_sichtbarkeit: "Für alle sichtbar" - katalog_darstellung: "Vollständiger Steckbrief" - service_level_anzeige: "SLS-Referenz" - beantragung_hinweis: "Automatische Bereitstellung, keine Beantragung nötig" - - kategorie_b: - name: "Erweiterte Services" - katalog_sichtbarkeit: "Für alle sichtbar" - katalog_darstellung: "Vollständiger Steckbrief" - service_level_anzeige: "SLS-Referenz" - beantragung_hinweis: "Beantragung über definierten Weg" - - kategorie_c: - name: "Spezial-Services" - katalog_sichtbarkeit: "Eingeschränkt (nur berechtigte Ämter)" - katalog_darstellung: "Reduzierter Steckbrief oder Verweis" - service_level_anzeige: "Verweis auf bilaterales SLA" - beantragung_hinweis: "Kontakt über Service Owner" - - kategorie_i: - name: "Interne Services" - katalog_sichtbarkeit: "NICHT im Katalog (per Definition)" - katalog_darstellung: "Kein Steckbrief – nur Service-Definition (intern)" - service_level_anzeige: "OLA (intern, nicht publiziert)" - beantragung_hinweis: "Kein Beantragungsweg – rein interne Steuerung" - governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003" - - # --------------------------------------------------------------------------- - # ABGRENZUNG - # --------------------------------------------------------------------------- - abgrenzung: - beschreibung: "Was SCM NICHT ist" - - nicht_ziele: - - aspekt: "Request-Katalog / Ticketing" - abgrenzung: > - SCM liefert Stammdaten an das ITSM-Tool. - Die Request-Abwicklung ist Aufgabe von P-05 Request Management. - - - aspekt: "IT-Serviceportal" - abgrenzung: > - SCM definiert Inhalte und Struktur. - Der Portal-Betrieb ist eine separate Verantwortung. - - - aspekt: "Technische Dokumentation" - abgrenzung: > - SCM fokussiert auf kundenrelevante Informationen. - Technische Details gehören in Betriebshandbücher. - - - aspekt: "Governance-Gremium" - abgrenzung: > - SCM ist ein Prozess, kein Gremium. - Entscheidungen werden in SOR/MB getroffen. - - - aspekt: "Service-Portfolio-Steuerung" - abgrenzung: > - SCM publiziert den Katalog (Live-Services). - Die Portfolio-Steuerung (Pipeline, Retire) liegt bei SPM. - -# ============================================================================= -# AKTIVITÄTEN – PHASE: TRANSITION -# ============================================================================= - -aktivitaeten_transition: - beschreibung: > - Aktivitäten zur Aufnahme neuer Services in den Katalog, - typischerweise am Ende der Service-Transition-Phase. - - aktivitaeten: - # ------------------------------------------------------------------------- - - id: scm_01 - name: "Service-Definition validieren" - - beschreibung: > - Prüfung der vom Service Owner erstellten Service-Definition - auf Vollständigkeit, Konsistenz und Konformität mit dem Schema. - - ausloeser: - - "Neuer Service erreicht Transition-Phase" - - "Wesentliche Service-Änderung (aus Demand)" - - eingang: - - artefakt: "Service-Definition (Entwurf)" - quelle: "Service Owner" - - artefakt: "SLS/SLA-Referenz" - quelle: "P-02 Service Level Management" - - umfasst: - - "Prüfung gegen Schema (Pflichtfelder, Datentypen)" - - "Prüfung Konsistenz mit Service-Kategorie" - - "Prüfung SLS/SLA-Referenz vorhanden und korrekt" - - "Prüfung Abhängigkeiten dokumentiert" - - "Rückmeldung an Service Owner bei Mängeln" - - ausgang: - - artefakt: "Service-Definition (validiert)" - ziel: "scm_02" - - artefakt: "Validierungsprotokoll" - ziel: "Dokumentation" - - qualitaets_gate: - name: "Service-Definition vollständig" - kriterien: - - "Alle Pflichtfelder ausgefüllt" - - "Schema-Validierung erfolgreich" - - "SLS/SLA-Referenz vorhanden" - - raci: - - rolle: service_owner - raci: R - kontext: "Liefert Service-Definition, behebt Mängel" - - rolle: spm - raci: A - kontext: "Verantwortet Validierung (als SCM Practice Owner)" - - # ------------------------------------------------------------------------- - - id: scm_02 - name: "Service-Steckbrief erstellen" - - beschreibung: > - Ableitung des kundenorientierten Service-Steckbriefs - aus der validierten Service-Definition. - - eingang: - - artefakt: "Service-Definition (validiert)" - quelle: "scm_01" - - umfasst: - - "Extraktion der kundenrelevanten Attribute" - - "Transformation in kundenverständliche Sprache" - - "Ableitung kategorie-spezifischer Hinweise" - - "Erstellung Datenschutz-Hinweis" - - "Verknüpfung mit Dokumenten (SLS, Handbücher)" - - ausgang: - - artefakt: "Service-Steckbrief (Entwurf)" - ziel: "scm_03" - - raci: - - rolle: service_owner - raci: R - kontext: "Erstellt Steckbrief-Entwurf" - - rolle: spm - raci: A - kontext: "Verantwortet Prozess" - - rolle: shm - raci: C - kontext: "Prüft Kundenverständlichkeit (optional)" - - hinweis_shm: > - Die Einbindung von SHM zur Qualitätssicherung der - Kundenverständlichkeit ist empfohlen, aber im MVP optional. - - # ------------------------------------------------------------------------- - - id: scm_03 - name: "Service-Steckbrief freigeben" - - beschreibung: > - Formale Freigabe des Service-Steckbriefs zur Publikation. - Die Freigabe-Instanz hängt von der Art der Aufnahme ab. - - eingang: - - artefakt: "Service-Steckbrief (Entwurf)" - quelle: "scm_02" - - umfasst: - - "Finale Qualitätsprüfung" - - "Prüfung Konsistenz mit Service-Definition" - - "Freigabe-Entscheidung" - - freigabe_logik: - beschreibung: > - Die Freigabe des Steckbriefs ist Teil der Service-Transition-Freigabe. - Bei isolierten Steckbrief-Änderungen gilt die Änderungs-Governance. - - neuer_service: "SOR (als Teil der Transition-Freigabe)" - aenderung_major: "SOR" - aenderung_minor: "SPM" - aenderung_redaktionell: "SO" - - ausgang: - - artefakt: "Service-Steckbrief (freigegeben)" - ziel: "scm_04" - - raci: - - rolle: service_owner - raci: R - kontext: "Erstellt und pflegt Steckbrief" - - rolle: spm - raci: A - kontext: "Accountable für redaktionelle/minor-Freigaben und Governance-Konsistenz" - - rolle: sor - raci: A - kontext: "Accountable für Freigaben mit größerem Impact (z. B. neue Services, Major-Änderungen)" - - # ------------------------------------------------------------------------- - - id: scm_04 - name: "Service-Steckbrief publizieren" - - beschreibung: > - Veröffentlichung des freigegebenen Service-Steckbriefs - im Service-Katalog und ggf. im ITSM-Tool. - - eingang: - - artefakt: "Service-Steckbrief (freigegeben)" - quelle: "scm_03" - - umfasst: - - "Eintrag in Service-Katalog" - - "Konfiguration Sichtbarkeit (nach Kategorie)" - - "Synchronisation mit ITSM-Tool (falls vorhanden)" - - "Benachrichtigung relevanter Stakeholder" - - ausgang: - - artefakt: "Service-Steckbrief (publiziert)" - ziel: "Service-Katalog" - - raci: - - rolle: spm - raci: A/R - kontext: "Führt Publikation durch" - - rolle: service_owner - raci: I - kontext: "Wird über Publikation informiert" - - hinweis_itsm: > - Die Synchronisation mit dem ITSM-Tool ist abhängig von der - Tool-Auswahl. Im MVP kann dies ein manueller Schritt sein. - -# ============================================================================= -# AKTIVITÄTEN – PHASE: BETRIEB -# ============================================================================= - -aktivitaeten_betrieb: - beschreibung: > - Aktivitäten zur laufenden Pflege des Service-Katalogs. - - aktivitaeten: - # ------------------------------------------------------------------------- - - id: scm_05 - name: "Katalogänderung bearbeiten" - - beschreibung: > - Bearbeitung von Änderungsbedarfen an Service-Definitionen - und Service-Steckbriefen. - - ausloeser: - - "Service Owner meldet Änderungsbedarf" - - "SLS/SLA-Änderung (aus P-02)" - - "Organisatorische Änderung (z.B. neuer Service Owner)" - - "Feedback von Nutzern/Kunden" - - umfasst: - - "Klassifikation der Änderung (redaktionell/minor/major)" - - "Aktualisierung Service-Definition" - - "Aktualisierung Service-Steckbrief" - - "Durchlaufen des Freigabeprozesses (nach Änderungstyp)" - - "Publikation der Änderung" - - aenderungstypen: - - typ: "redaktionell" - beispiele: - - "Korrektur Tippfehler" - - "Aktualisierung Kontaktdaten" - - "Formatierungsanpassung" - entscheidung: "Service Owner (autonom)" - freigabe: "Keine separate Freigabe nötig" - - - typ: "inhaltlich_minor" - beispiele: - - "Ergänzung FAQ oder Dokument-Link" - - "Klarstellung Leistungsumfang (ohne Änderung)" - - "Aktualisierung Voraussetzungen" - entscheidung: "Service Owner + SPM (bilateral)" - freigabe: "SPM" - - - typ: "inhaltlich_major" - beispiele: - - "Änderung Leistungsumfang" - - "Änderung Service Levels" - - "Änderung Zielgruppe oder Kategorie" - entscheidung: "SOR" - freigabe: "SOR" - hinweis: "Meist gekoppelt an Service-Definition-Änderung" - - raci: - - rolle: service_owner - raci: R - kontext: "Initiiert und beschreibt Änderungsbedarf" - - rolle: spm - raci: A - kontext: "Accountable für minor/standard-Kataloganpassungen und übergreifende Konsistenz" - - rolle: sor - raci: A - kontext: "Accountable für Major-Änderungen mit Portfolio-/Governance-Relevanz" - - # ------------------------------------------------------------------------- - - id: scm_06 - name: "Service aus Katalog entfernen" - - beschreibung: > - Entfernung eines stillgelegten Services aus dem Katalog - (Übergang von "Live" zu "Retired"). - - ausloeser: - - "Service-Stilllegung beschlossen (B-03 Service Review)" - - eingang: - - artefakt: "Stilllegungsbeschluss" - quelle: "SOR oder Mission Board" - - umfasst: - - "Kennzeichnung als 'stillgelegt' im Katalog" - - "Kommunikation an betroffene Nutzer/Ämter" - - "Übergangszeit definieren (falls nötig)" - - "Endgültige Entfernung aus öffentlichem Katalog" - - "Archivierung der Service-Definition" - - ausgang: - - artefakt: "Service-Definition (archiviert)" - ziel: "Archiv" - - artefakt: "Katalog aktualisiert" - - raci: - - rolle: service_owner - raci: R - kontext: "Koordiniert Kommunikation" - - rolle: spm - raci: A - kontext: "Verantwortet Katalogaktualisierung" - - rolle: shm - raci: C - kontext: "Unterstützt Kundenkommunikation" - -# ============================================================================= -# AKTIVITÄTEN – PHASE: REVIEW -# ============================================================================= - -aktivitaeten_review: - beschreibung: > - Aktivitäten zur regelmäßigen Überprüfung des gesamten Katalogs. - - aktivitaeten: - # ------------------------------------------------------------------------- - - id: scm_07 - name: "Jährlichen Katalog-Review durchführen" - - beschreibung: > - Systematische Überprüfung aller Service-Definitionen und - Service-Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz. - - frequenz: "Jährlich" - - ausloeser: - - "Jährlicher Review-Zyklus" - - "Wesentliche organisatorische Änderungen" - - "Neue Compliance-Anforderungen" - - umfasst: - - "Prüfung aller Service-Definitionen auf Aktualität" - - "Prüfung Konsistenz mit tatsächlicher Service-Erbringung" - - "Prüfung SLS/SLA-Referenzen aktuell" - - "Prüfung Kontaktdaten aktuell" - - "Identifikation verwaister Services (kein aktiver SO)" - - "Identifikation Inkonsistenzen" - - "Ableitung Maßnahmenliste" - - ausgang: - - artefakt: "Katalog-Review-Bericht" - ziel: "SOR / Mission Board" - - artefakt: "Maßnahmenliste" - ziel: "Service Owner (zur Umsetzung)" - - raci: - - rolle: spm - raci: A/R - kontext: "Führt Review durch, erstellt Bericht" - - rolle: service_owner - raci: C - kontext: "Liefert Informationen zu ihren Services" - - rolle: sor - raci: I - kontext: "Erhält Bericht, entscheidet bei Eskalation" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance_entscheidungen: - - - id: "GOV-006" - datum: "2025-11-27" - frage: "Wer ist Practice Owner für Service Catalog Management?" - entscheidung: > - Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM. - Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden. - begruendung: > - SPM und SCM operieren beide auf Portfolio-Ebene und haben - natürliche Nähe. Eine Trennung ist langfristig möglich, - aber für die Einführungsphase nicht nötig. - status: "final" - - - id: "GOV-007" - datum: "2025-11-27" - frage: "Wer erstellt die Service-Definition?" - entscheidung: > - Der Service Owner ist verantwortlich (Accountable) für die Erstellung - der Service-Definition. SPM validiert und gibt frei. - begruendung: > - ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung - für den Service. Die Service-Definition ist Teil dieser Verantwortung. - SCM stellt Methodik, Templates und Qualitätssicherung bereit. - status: "final" - - - id: "GOV-008" - datum: "2025-11-27" - frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?" - entscheidung: | - Dreistufige Governance nach Impact: - 1. Redaktionelle Änderungen: Service Owner (autonom) - 2. Inhaltlich-minor: Service Owner + SPM (bilateral) - 3. Inhaltlich-major / Neuaufnahme: SOR - - Strukturelle Änderungen (Kategorie-Wechsel, Stilllegung): Mission Board - begruendung: > - Vermeidet Überlastung des SOR/MB mit Kleinstthemen. - Operative Themen werden operativ gelöst. - Nur portfolio-relevante Entscheidungen eskalieren. - status: "final" - - - id: "GOV-009" - datum: "2025-11-27" - frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?" - entscheidung: > - SHM wird eingebunden für die Prüfung der Kundenverständlichkeit - von Service-Steckbriefen. Im MVP ist dies optional (Empfehlung), - da das SHM-Modul noch in Entwicklung ist. - begruendung: > - SHM hat die Kompetenz für Kundenperspektive und -sprache. - Die Schnittstelle sollte etabliert werden, sobald SHM - operativ ist. - status: "draft" - abhaengig_von: "Finalisierung SHM-Modul" - - - id: "GOV-010" - datum: "2025-11-27" - frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?" - entscheidung: > - SCM (SPM) verantwortet den Inhalt des Katalogs. - Der Betrieb des Publikationskanals ist eine separate Verantwortung, - die im MVP noch zu klären ist (Webteam, IT-Betrieb, o.ä.). - begruendung: > - Trennung von Inhalt (SCM) und Betrieb (Technik). - Vermeidet, dass SCM zur Portal-Betriebs-Instanz wird. - status: "draft" - offene_frage: "Wer ist konkret für Portal-Betrieb zuständig?" - -# ============================================================================= -# METRIKEN -# ============================================================================= - -metriken: - - prozess_metriken: - - name: "Katalog-Abdeckung" - beschreibung: >- - Anteil der Live-Services, für die ein freigegebener Service-Steckbrief - im Service-Katalog publiziert ist. - ziel: "100%" - messung: "Anzahl publizierte Steckbriefe / Anzahl Services mit Status 'Live'" - - - name: "Steckbrief-Aktualität" - beschreibung: "Anteil der Steckbriefe, die im letzten Jahr geprüft wurden" - ziel: "100%" - messung: "Anzahl Steckbriefe mit Review < 12 Monate / Gesamtanzahl" - - - name: "Durchlaufzeit Katalogaufnahme" - beschreibung: "Zeit von Transition-Start bis Katalogpublikation" - ziel: "< 10 Arbeitstage" - messung: "Durchschnitt über alle Neuaufnahmen" - - qualitaets_metriken: - - name: "Schema-Konformität" - beschreibung: "Anteil der Service-Definitionen ohne Validierungsfehler" - ziel: "100%" - - - name: "Verständlichkeits-Score" - beschreibung: "Bewertung der Steckbriefe durch SHM/Nutzer" - ziel: "Definition ausstehend" - hinweis: "Einführung nach SHM-Operationalisierung" - -# ============================================================================= -# TOOLING-ANFORDERUNGEN -# ============================================================================= - -tooling: - - service_katalog_ablage: - beschreibung: > - Speicherort für Service-Definitionen und Service-Steckbriefe. - Im MVP kann dies ein strukturiertes Verzeichnis sein. - - anforderungen: - - "Versionierung" - - "Zugriffssteuerung (SO kann eigene Services bearbeiten)" - - "Such- und Filterfunktion" - - optionen: - - "Confluence/Wiki" - - "SharePoint" - - "Git-Repository" - - "Dediziertes ITSM-/CMDB-Tool" - - mvp_loesung: "TBD" - - itsm_integration: - beschreibung: > - Schnittstelle zum ITSM-Tool für den Request-Katalog. - - anforderungen: - - "Service-ID als eindeutiger Schlüssel" - - "Unidirektionale Synchronisation (SCM → ITSM)" - - "Kategorie-basierte Sichtbarkeitssteuerung" - - status: "Tool-Auswahl ausstehend" - - hinweis: > - Im MVP kann die Synchronisation manuell erfolgen. - Eine automatisierte Schnittstelle ist Ziel, aber nicht MVP-kritisch. - - cmdb_integration: - beschreibung: > - Schnittstelle zur CMDB für Abhängigkeitsinformationen. - - status: "Placeholder" - - hinweis: > - CMDB ist nicht Teil des MVP. Abhängigkeiten werden manuell - in der Service-Definition gepflegt. Langfristig sollte eine - bidirektionale Synchronisation etabliert werden. - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-P01-001" - beschreibung: "Template Service-Definition erstellen (Markdown)" - prioritaet: "hoch" - ziel_ordner: "02.6_arbeitsmaterialien" - abhaengig_von: "Finalisierung Schema" - - - id: "OPEN-P01-002" - beschreibung: "Template Service-Steckbrief erstellen (Markdown/HTML)" - prioritaet: "hoch" - ziel_ordner: "02.6_arbeitsmaterialien" - abhaengig_von: "Finalisierung Schema" - - - id: "OPEN-P01-003" - beschreibung: "Checkliste Katalog-Review erstellen" - prioritaet: "mittel" - ziel_ordner: "02.6_arbeitsmaterialien" - - - id: "OPEN-P01-004" - beschreibung: "Klärung Publikationskanal und Betriebsverantwortung" - prioritaet: "mittel" - status: "Abstimmung mit IT-Betrieb/Webteam nötig" - - - id: "OPEN-P01-005" - beschreibung: "SHM-Einbindung operationalisieren" - prioritaet: "niedrig" - abhaengig_von: "Finalisierung SHM-Modul" - - - id: "OPEN-P01-006" - beschreibung: "ITSM-Tool-Integration spezifizieren" - prioritaet: "niedrig" - abhaengig_von: "Tool-Auswahl" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.4" - datum: "2026-03-09" - aenderung: | - - Kategorie I (Interne Services) in kategorien_logik und Katalog-Ausschlussregel ergänzt - - Expliziter Hinweis: Katalog enthält ausschließlich Kategorie A, B, C - - nicht_enthalten-Liste aktualisiert (Verweis auf GOV-SPM-I-001, GOV-SPM-I-003) - autor: "DIGITOM-Projekt" - referenz: "PENDING-SPM-001, DC-001, DC-003" - - - version: "0.3" - datum: "2026-01-31" - aenderung: "Metrik 'Katalog-Abdeckung' präzisiert: Bezug auf Steckbriefe statt Definitionen" - autor: "DIGITOM-Projekt" - referenz: "Begriffskonsistenz Portfolio/Katalog vs. Definition/Steckbrief" - - - version: "0.2" - datum: "2026-01-30" - aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation)" - autor: "DIGITOM-Projekt" - referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" - - - version: "0.1" - datum: "2025-11-27" - aenderung: "Initiale Practice-Konzeption" +# ============================================================================= +# PRACTICE: SERVICE CATALOG MANAGEMENT +# ============================================================================= + +metadata: + id: "P-01" + name: "Service Catalog Management" + version: "0.2" + status: "draft" + erstellt: "2025-11-27" + aktualisiert: "2026-01-30" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "practice-konzept" + + funktion: + id: "SPM" + name: "Service-Portfolio-Management" + + taxonomie_referenz: "00_meta/digitom_taxonomie.yaml" + + beschreibung: > + Service Catalog Management stellt sicher, dass für jeden Service eine + klare, aktuelle, vollständige und verlässliche Beschreibung existiert – + und alle Stakeholder auf dieselbe Wahrheit zugreifen. Die Practice + fungiert als Informations-Governance über alle Services und bildet die + Brücke zwischen Service-Portfolio (strategisch), Service-Definition + (operativ) und Service Level Management (qualitativ). + + itil4_referenz: "Service Catalogue Management Practice" + + lifecycle_phasen: + - design + - transition + - operation + - review + + practice_owner: "Service-Portfolio-Manager (SPM)" + + konsolidierung_hinweis: > + Im MVP ist die Practice Owner-Rolle für SCM mit der SPM-Rolle + konsolidiert, um Rolleninflation zu vermeiden. Langfristig kann + eine Trennung sinnvoll sein. + + schnittstellen: + intern: + - modul: "P-02 Service Level Management" + art: "erhält von" + beschreibung: "SLS/SLA-Referenzen zur Publikation im Katalog" + + - modul: "B-01 Service Transition" + art: "bidirektional" + beschreibung: "Katalogaufnahme als Teil des Transition-Prozesses" + + - modul: "B-03 Service Review" + art: "bidirektional" + beschreibung: "Review-Ergebnisse können Katalogänderungen triggern" + + extern: + - partner: "Stakeholder-Management (SHM)" + kontext: "Qualitätssicherung Kundenverständlichkeit" + status: "SHM-Modul in Entwicklung" + + - partner: "ITSM-Tool (Request-Katalog)" + kontext: "Stammdatenlieferung für Service-Requests" + status: "Tool-Auswahl ausstehend" + +# ============================================================================= +# KERNKONZEPTE +# ============================================================================= + +kernkonzepte: + + # --------------------------------------------------------------------------- + # ZENTRALE ARTEFAKTE + # --------------------------------------------------------------------------- + artefakte: + beschreibung: > + SCM verwaltet zwei zentrale Artefakte, die in einer + Master-Derivat-Beziehung stehen. + + artefakte: + - name: "Service-Definition" + typ: "Master-Dokument" + beschreibung: > + Internes Dokument mit allen relevanten Informationen zu einem + Service. Single Source of Truth für DIGIT. + schema: "02.5_informationsmodell/spm_schema_service-definition.yaml" + verantwortung_erstellung: "Service Owner" + verantwortung_validierung: "SPM (als SCM Practice Owner)" + + - name: "Service-Steckbrief" + typ: "Derivat" + beschreibung: > + Kundenorientierter Auszug aus der Service-Definition. + Wird im Service-Katalog publiziert. + schema: "02.5_informationsmodell/spm_schema_service-steckbrief.yaml" + verantwortung_ableitung: "Service Owner" + verantwortung_freigabe: "SPM" + verantwortung_publikation: "SPM" + + beziehung: > + Der Service-Steckbrief wird aus der Service-Definition abgeleitet. + Änderungen an der Service-Definition können Aktualisierungen des + Steckbriefs erfordern. Das Mapping ist im Schema dokumentiert. + + # --------------------------------------------------------------------------- + # SERVICE-KATALOG + # --------------------------------------------------------------------------- + service_katalog: + beschreibung: > + Der Service-Katalog ist kein einzelnes Tool, sondern ein logisches + Konstrukt: die offizielle, konsolidierte Sicht auf alle angebotenen + Services des DIGIT mit ihren wesentlichen Merkmalen. + Diese Sicht wird in geeigneten Werkzeugen (z. B. Intranet-Portal, + ITSM-Tool, Dokumentation) für unterschiedliche Zielgruppen + bereitgestellt. + + inhalt: "Alle Service-Steckbriefe für Services im Status 'Live'" + + nicht_enthalten: + - "Services in der Pipeline (noch nicht live)" + - "Stillgelegte Services (retired)" + - "Interne Services (Kategorie I) – per Definition nicht im Katalog (GOV-SPM-I-001, GOV-SPM-I-003)" + + ausschlussregel_kategorie_I: + beschreibung: | + Der Service-Katalog enthält ausschließlich Kundenservices der + Kategorien A, B und C. Interne Services (Kategorie I) werden + NICHT im Katalog publiziert. Die Sichtbarkeit ist vollständig + aus der Service-Kategorie ableitbar – ein separates Attribut + service_sichtbarkeit existiert nicht. + governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003, VAL-007" + + publikationskanaele: + beschreibung: > + Der Katalog kann über verschiedene Kanäle zugänglich gemacht werden. + Die konkrete Implementierung ist nicht Teil dieser Practice-Definition. + + stakeholder_einbindung: + beschreibung: > + Das Stakeholder-Management (SHM) unterstützt bei der Formulierung + kundenverständlicher Texte und bei der Priorisierung von + Verbesserungsbedarfen aus Sicht der Ämter. + Im MVP ist dies optional, im Zielbild standardmäßig vorgesehen. + + anforderungen: + - "Barrierefreier Zugang für alle Zielgruppen" + - "Durchsuchbarkeit" + - "Aktualität (zeitnahe Publikation von Änderungen)" + - "Kategorie-basierte Sichtbarkeitssteuerung" + + moegliche_kanaele: + - "Intranet-Seite" + - "Self-Service-Portal" + - "ITSM-Tool (Request-Katalog-View)" + - "PDF-Export (für Offline-Nutzung)" + + verantwortung_inhalt: "SPM" + verantwortung_betrieb: "TBD (abhängig von Kanal)" + + # --------------------------------------------------------------------------- + # KATALOG-VIEWS + # --------------------------------------------------------------------------- + katalog_views: + beschreibung: > + Der Katalog unterstützt unterschiedliche Sichten für + unterschiedliche Zielgruppen. + + views: + - name: "Nutzer-View" + zielgruppe: "Alle Mitarbeitenden" + fokus: "Was gibt es? Was bekomme ich? Wie beantrage ich?" + inhalte: + - "Alle Basis-Services (Kategorie A)" + - "Alle Erweiterten Services (Kategorie B)" + - "Spezial-Services nur wenn berechtigt (Kategorie C)" + + - name: "Entscheider-View" + zielgruppe: "Amtsleitungen, Kundenvertretungen" + fokus: "Welche Services nutzt mein Amt? Welche Qualität? Welche Kosten?" + inhalte: + - "Alle Services mit SLA/SLS-Referenzen" + - "Service-Owner-Kontakte" + - "Berechtigungslogik" + + - name: "Request-View" + zielgruppe: "Mitarbeitende (im ITSM-Tool)" + fokus: "Was kann ich bestellen/beantragen?" + inhalte: + - "Bestellbare Services" + - "Beantragungswege" + - "Voraussetzungen" + hinweis: "Diese View wird im ITSM-Tool realisiert, nicht im Katalog selbst" + + # --------------------------------------------------------------------------- + # KATEGORIEN IM KATALOG + # --------------------------------------------------------------------------- + kategorien_logik: + beschreibung: > + Die Service-Kategorien A/B/C (definiert in P-02 SLM) haben + direkte Auswirkungen auf die Katalogdarstellung. + + kategorie_a: + name: "Basis-Services" + katalog_sichtbarkeit: "Für alle sichtbar" + katalog_darstellung: "Vollständiger Steckbrief" + service_level_anzeige: "SLS-Referenz" + beantragung_hinweis: "Automatische Bereitstellung, keine Beantragung nötig" + + kategorie_b: + name: "Erweiterte Services" + katalog_sichtbarkeit: "Für alle sichtbar" + katalog_darstellung: "Vollständiger Steckbrief" + service_level_anzeige: "SLS-Referenz" + beantragung_hinweis: "Beantragung über definierten Weg" + + kategorie_c: + name: "Spezial-Services" + katalog_sichtbarkeit: "Eingeschränkt (nur berechtigte Ämter)" + katalog_darstellung: "Reduzierter Steckbrief oder Verweis" + service_level_anzeige: "Verweis auf bilaterales SLA" + beantragung_hinweis: "Kontakt über Service Owner" + + kategorie_i: + name: "Interne Services" + katalog_sichtbarkeit: "NICHT im Katalog (per Definition)" + katalog_darstellung: "Kein Steckbrief – nur Service-Definition (intern)" + service_level_anzeige: "OLA (intern, nicht publiziert)" + beantragung_hinweis: "Kein Beantragungsweg – rein interne Steuerung" + governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003" + + # --------------------------------------------------------------------------- + # ABGRENZUNG + # --------------------------------------------------------------------------- + abgrenzung: + beschreibung: "Was SCM NICHT ist" + + nicht_ziele: + - aspekt: "Request-Katalog / Ticketing" + abgrenzung: > + SCM liefert Stammdaten an das ITSM-Tool. + Die Request-Abwicklung ist Aufgabe von P-05 Request Management. + + - aspekt: "IT-Serviceportal" + abgrenzung: > + SCM definiert Inhalte und Struktur. + Der Portal-Betrieb ist eine separate Verantwortung. + + - aspekt: "Technische Dokumentation" + abgrenzung: > + SCM fokussiert auf kundenrelevante Informationen. + Technische Details gehören in Betriebshandbücher. + + - aspekt: "Governance-Gremium" + abgrenzung: > + SCM ist ein Prozess, kein Gremium. + Entscheidungen werden in SOR/MB getroffen. + + - aspekt: "Service-Portfolio-Steuerung" + abgrenzung: > + SCM publiziert den Katalog (Live-Services). + Die Portfolio-Steuerung (Pipeline, Retire) liegt bei SPM. + +# ============================================================================= +# AKTIVITÄTEN – PHASE: TRANSITION +# ============================================================================= + +aktivitaeten_transition: + beschreibung: > + Aktivitäten zur Aufnahme neuer Services in den Katalog, + typischerweise am Ende der Service-Transition-Phase. + + aktivitaeten: + # ------------------------------------------------------------------------- + - id: scm_01 + name: "Service-Definition validieren" + + beschreibung: > + Prüfung der vom Service Owner erstellten Service-Definition + auf Vollständigkeit, Konsistenz und Konformität mit dem Schema. + + ausloeser: + - "Neuer Service erreicht Transition-Phase" + - "Wesentliche Service-Änderung (aus Demand)" + + eingang: + - artefakt: "Service-Definition (Entwurf)" + quelle: "Service Owner" + - artefakt: "SLS/SLA-Referenz" + quelle: "P-02 Service Level Management" + + umfasst: + - "Prüfung gegen Schema (Pflichtfelder, Datentypen)" + - "Prüfung Konsistenz mit Service-Kategorie" + - "Prüfung SLS/SLA-Referenz vorhanden und korrekt" + - "Prüfung Abhängigkeiten dokumentiert" + - "Rückmeldung an Service Owner bei Mängeln" + + ausgang: + - artefakt: "Service-Definition (validiert)" + ziel: "scm_02" + - artefakt: "Validierungsprotokoll" + ziel: "Dokumentation" + + qualitaets_gate: + name: "Service-Definition vollständig" + kriterien: + - "Alle Pflichtfelder ausgefüllt" + - "Schema-Validierung erfolgreich" + - "SLS/SLA-Referenz vorhanden" + + raci: + - rolle: service_owner + raci: R + kontext: "Liefert Service-Definition, behebt Mängel" + - rolle: spm + raci: A + kontext: "Verantwortet Validierung (als SCM Practice Owner)" + + # ------------------------------------------------------------------------- + - id: scm_02 + name: "Service-Steckbrief erstellen" + + beschreibung: > + Ableitung des kundenorientierten Service-Steckbriefs + aus der validierten Service-Definition. + + eingang: + - artefakt: "Service-Definition (validiert)" + quelle: "scm_01" + + umfasst: + - "Extraktion der kundenrelevanten Attribute" + - "Transformation in kundenverständliche Sprache" + - "Ableitung kategorie-spezifischer Hinweise" + - "Erstellung Datenschutz-Hinweis" + - "Verknüpfung mit Dokumenten (SLS, Handbücher)" + + ausgang: + - artefakt: "Service-Steckbrief (Entwurf)" + ziel: "scm_03" + + raci: + - rolle: service_owner + raci: R + kontext: "Erstellt Steckbrief-Entwurf" + - rolle: spm + raci: A + kontext: "Verantwortet Prozess" + - rolle: shm + raci: C + kontext: "Prüft Kundenverständlichkeit (optional)" + + hinweis_shm: > + Die Einbindung von SHM zur Qualitätssicherung der + Kundenverständlichkeit ist empfohlen, aber im MVP optional. + + # ------------------------------------------------------------------------- + - id: scm_03 + name: "Service-Steckbrief freigeben" + + beschreibung: > + Formale Freigabe des Service-Steckbriefs zur Publikation. + Die Freigabe-Instanz hängt von der Art der Aufnahme ab. + + eingang: + - artefakt: "Service-Steckbrief (Entwurf)" + quelle: "scm_02" + + umfasst: + - "Finale Qualitätsprüfung" + - "Prüfung Konsistenz mit Service-Definition" + - "Freigabe-Entscheidung" + + freigabe_logik: + beschreibung: > + Die Freigabe des Steckbriefs ist Teil der Service-Transition-Freigabe. + Bei isolierten Steckbrief-Änderungen gilt die Änderungs-Governance. + + neuer_service: "SOR (als Teil der Transition-Freigabe)" + aenderung_major: "SOR" + aenderung_minor: "SPM" + aenderung_redaktionell: "SO" + + ausgang: + - artefakt: "Service-Steckbrief (freigegeben)" + ziel: "scm_04" + + raci: + - rolle: service_owner + raci: R + kontext: "Erstellt und pflegt Steckbrief" + - rolle: spm + raci: A + kontext: "Accountable für redaktionelle/minor-Freigaben und Governance-Konsistenz" + - rolle: sor + raci: A + kontext: "Accountable für Freigaben mit größerem Impact (z. B. neue Services, Major-Änderungen)" + + # ------------------------------------------------------------------------- + - id: scm_04 + name: "Service-Steckbrief publizieren" + + beschreibung: > + Veröffentlichung des freigegebenen Service-Steckbriefs + im Service-Katalog und ggf. im ITSM-Tool. + + eingang: + - artefakt: "Service-Steckbrief (freigegeben)" + quelle: "scm_03" + + umfasst: + - "Eintrag in Service-Katalog" + - "Konfiguration Sichtbarkeit (nach Kategorie)" + - "Synchronisation mit ITSM-Tool (falls vorhanden)" + - "Benachrichtigung relevanter Stakeholder" + + ausgang: + - artefakt: "Service-Steckbrief (publiziert)" + ziel: "Service-Katalog" + + raci: + - rolle: spm + raci: A/R + kontext: "Führt Publikation durch" + - rolle: service_owner + raci: I + kontext: "Wird über Publikation informiert" + + hinweis_itsm: > + Die Synchronisation mit dem ITSM-Tool ist abhängig von der + Tool-Auswahl. Im MVP kann dies ein manueller Schritt sein. + +# ============================================================================= +# AKTIVITÄTEN – PHASE: BETRIEB +# ============================================================================= + +aktivitaeten_betrieb: + beschreibung: > + Aktivitäten zur laufenden Pflege des Service-Katalogs. + + aktivitaeten: + # ------------------------------------------------------------------------- + - id: scm_05 + name: "Katalogänderung bearbeiten" + + beschreibung: > + Bearbeitung von Änderungsbedarfen an Service-Definitionen + und Service-Steckbriefen. + + ausloeser: + - "Service Owner meldet Änderungsbedarf" + - "SLS/SLA-Änderung (aus P-02)" + - "Organisatorische Änderung (z.B. neuer Service Owner)" + - "Feedback von Nutzern/Kunden" + + umfasst: + - "Klassifikation der Änderung (redaktionell/minor/major)" + - "Aktualisierung Service-Definition" + - "Aktualisierung Service-Steckbrief" + - "Durchlaufen des Freigabeprozesses (nach Änderungstyp)" + - "Publikation der Änderung" + + aenderungstypen: + - typ: "redaktionell" + beispiele: + - "Korrektur Tippfehler" + - "Aktualisierung Kontaktdaten" + - "Formatierungsanpassung" + entscheidung: "Service Owner (autonom)" + freigabe: "Keine separate Freigabe nötig" + + - typ: "inhaltlich_minor" + beispiele: + - "Ergänzung FAQ oder Dokument-Link" + - "Klarstellung Leistungsumfang (ohne Änderung)" + - "Aktualisierung Voraussetzungen" + entscheidung: "Service Owner + SPM (bilateral)" + freigabe: "SPM" + + - typ: "inhaltlich_major" + beispiele: + - "Änderung Leistungsumfang" + - "Änderung Service Levels" + - "Änderung Zielgruppe oder Kategorie" + entscheidung: "SOR" + freigabe: "SOR" + hinweis: "Meist gekoppelt an Service-Definition-Änderung" + + raci: + - rolle: service_owner + raci: R + kontext: "Initiiert und beschreibt Änderungsbedarf" + - rolle: spm + raci: A + kontext: "Accountable für minor/standard-Kataloganpassungen und übergreifende Konsistenz" + - rolle: sor + raci: A + kontext: "Accountable für Major-Änderungen mit Portfolio-/Governance-Relevanz" + + # ------------------------------------------------------------------------- + - id: scm_06 + name: "Service aus Katalog entfernen" + + beschreibung: > + Entfernung eines stillgelegten Services aus dem Katalog + (Übergang von "Live" zu "Retired"). + + ausloeser: + - "Service-Stilllegung beschlossen (B-03 Service Review)" + + eingang: + - artefakt: "Stilllegungsbeschluss" + quelle: "SOR oder Mission Board" + + umfasst: + - "Kennzeichnung als 'stillgelegt' im Katalog" + - "Kommunikation an betroffene Nutzer/Ämter" + - "Übergangszeit definieren (falls nötig)" + - "Endgültige Entfernung aus öffentlichem Katalog" + - "Archivierung der Service-Definition" + + ausgang: + - artefakt: "Service-Definition (archiviert)" + ziel: "Archiv" + - artefakt: "Katalog aktualisiert" + + raci: + - rolle: service_owner + raci: R + kontext: "Koordiniert Kommunikation" + - rolle: spm + raci: A + kontext: "Verantwortet Katalogaktualisierung" + - rolle: shm + raci: C + kontext: "Unterstützt Kundenkommunikation" + +# ============================================================================= +# AKTIVITÄTEN – PHASE: REVIEW +# ============================================================================= + +aktivitaeten_review: + beschreibung: > + Aktivitäten zur regelmäßigen Überprüfung des gesamten Katalogs. + + aktivitaeten: + # ------------------------------------------------------------------------- + - id: scm_07 + name: "Jährlichen Katalog-Review durchführen" + + beschreibung: > + Systematische Überprüfung aller Service-Definitionen und + Service-Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz. + + frequenz: "Jährlich" + + ausloeser: + - "Jährlicher Review-Zyklus" + - "Wesentliche organisatorische Änderungen" + - "Neue Compliance-Anforderungen" + + umfasst: + - "Prüfung aller Service-Definitionen auf Aktualität" + - "Prüfung Konsistenz mit tatsächlicher Service-Erbringung" + - "Prüfung SLS/SLA-Referenzen aktuell" + - "Prüfung Kontaktdaten aktuell" + - "Identifikation verwaister Services (kein aktiver SO)" + - "Identifikation Inkonsistenzen" + - "Ableitung Maßnahmenliste" + + ausgang: + - artefakt: "Katalog-Review-Bericht" + ziel: "SOR / Mission Board" + - artefakt: "Maßnahmenliste" + ziel: "Service Owner (zur Umsetzung)" + + raci: + - rolle: spm + raci: A/R + kontext: "Führt Review durch, erstellt Bericht" + - rolle: service_owner + raci: C + kontext: "Liefert Informationen zu ihren Services" + - rolle: sor + raci: I + kontext: "Erhält Bericht, entscheidet bei Eskalation" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance_entscheidungen: + + - id: "GOV-006" + datum: "2025-11-27" + frage: "Wer ist Practice Owner für Service Catalog Management?" + entscheidung: > + Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM. + Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden. + begruendung: > + SPM und SCM operieren beide auf Portfolio-Ebene und haben + natürliche Nähe. Eine Trennung ist langfristig möglich, + aber für die Einführungsphase nicht nötig. + status: "final" + + - id: "GOV-007" + datum: "2025-11-27" + frage: "Wer erstellt die Service-Definition?" + entscheidung: > + Der Service Owner ist verantwortlich (Accountable) für die Erstellung + der Service-Definition. SPM validiert und gibt frei. + begruendung: > + ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung + für den Service. Die Service-Definition ist Teil dieser Verantwortung. + SCM stellt Methodik, Templates und Qualitätssicherung bereit. + status: "final" + + - id: "GOV-008" + datum: "2025-11-27" + frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?" + entscheidung: | + Dreistufige Governance nach Impact: + 1. Redaktionelle Änderungen: Service Owner (autonom) + 2. Inhaltlich-minor: Service Owner + SPM (bilateral) + 3. Inhaltlich-major / Neuaufnahme: SOR + + Strukturelle Änderungen (Kategorie-Wechsel, Stilllegung): Mission Board + begruendung: > + Vermeidet Überlastung des SOR/MB mit Kleinstthemen. + Operative Themen werden operativ gelöst. + Nur portfolio-relevante Entscheidungen eskalieren. + status: "final" + + - id: "GOV-009" + datum: "2025-11-27" + frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?" + entscheidung: > + SHM wird eingebunden für die Prüfung der Kundenverständlichkeit + von Service-Steckbriefen. Im MVP ist dies optional (Empfehlung), + da das SHM-Modul noch in Entwicklung ist. + begruendung: > + SHM hat die Kompetenz für Kundenperspektive und -sprache. + Die Schnittstelle sollte etabliert werden, sobald SHM + operativ ist. + status: "draft" + abhaengig_von: "Finalisierung SHM-Modul" + + - id: "GOV-010" + datum: "2025-11-27" + frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?" + entscheidung: > + SCM (SPM) verantwortet den Inhalt des Katalogs. + Der Betrieb des Publikationskanals ist eine separate Verantwortung, + die im MVP noch zu klären ist (Webteam, IT-Betrieb, o.ä.). + begruendung: > + Trennung von Inhalt (SCM) und Betrieb (Technik). + Vermeidet, dass SCM zur Portal-Betriebs-Instanz wird. + status: "draft" + offene_frage: "Wer ist konkret für Portal-Betrieb zuständig?" + +# ============================================================================= +# METRIKEN +# ============================================================================= + +metriken: + + prozess_metriken: + - name: "Katalog-Abdeckung" + beschreibung: >- + Anteil der Live-Services, für die ein freigegebener Service-Steckbrief + im Service-Katalog publiziert ist. + ziel: "100%" + messung: "Anzahl publizierte Steckbriefe / Anzahl Services mit Status 'Live'" + + - name: "Steckbrief-Aktualität" + beschreibung: "Anteil der Steckbriefe, die im letzten Jahr geprüft wurden" + ziel: "100%" + messung: "Anzahl Steckbriefe mit Review < 12 Monate / Gesamtanzahl" + + - name: "Durchlaufzeit Katalogaufnahme" + beschreibung: "Zeit von Transition-Start bis Katalogpublikation" + ziel: "< 10 Arbeitstage" + messung: "Durchschnitt über alle Neuaufnahmen" + + qualitaets_metriken: + - name: "Schema-Konformität" + beschreibung: "Anteil der Service-Definitionen ohne Validierungsfehler" + ziel: "100%" + + - name: "Verständlichkeits-Score" + beschreibung: "Bewertung der Steckbriefe durch SHM/Nutzer" + ziel: "Definition ausstehend" + hinweis: "Einführung nach SHM-Operationalisierung" + +# ============================================================================= +# TOOLING-ANFORDERUNGEN +# ============================================================================= + +tooling: + + service_katalog_ablage: + beschreibung: > + Speicherort für Service-Definitionen und Service-Steckbriefe. + Im MVP kann dies ein strukturiertes Verzeichnis sein. + + anforderungen: + - "Versionierung" + - "Zugriffssteuerung (SO kann eigene Services bearbeiten)" + - "Such- und Filterfunktion" + + optionen: + - "Confluence/Wiki" + - "SharePoint" + - "Git-Repository" + - "Dediziertes ITSM-/CMDB-Tool" + + mvp_loesung: "TBD" + + itsm_integration: + beschreibung: > + Schnittstelle zum ITSM-Tool für den Request-Katalog. + + anforderungen: + - "Service-ID als eindeutiger Schlüssel" + - "Unidirektionale Synchronisation (SCM → ITSM)" + - "Kategorie-basierte Sichtbarkeitssteuerung" + + status: "Tool-Auswahl ausstehend" + + hinweis: > + Im MVP kann die Synchronisation manuell erfolgen. + Eine automatisierte Schnittstelle ist Ziel, aber nicht MVP-kritisch. + + cmdb_integration: + beschreibung: > + Schnittstelle zur CMDB für Abhängigkeitsinformationen. + + status: "Placeholder" + + hinweis: > + CMDB ist nicht Teil des MVP. Abhängigkeiten werden manuell + in der Service-Definition gepflegt. Langfristig sollte eine + bidirektionale Synchronisation etabliert werden. + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-P01-001" + beschreibung: "Template Service-Definition erstellen (Markdown)" + prioritaet: "hoch" + ziel_ordner: "02.6_arbeitsmaterialien" + abhaengig_von: "Finalisierung Schema" + + - id: "OPEN-P01-002" + beschreibung: "Template Service-Steckbrief erstellen (Markdown/HTML)" + prioritaet: "hoch" + ziel_ordner: "02.6_arbeitsmaterialien" + abhaengig_von: "Finalisierung Schema" + + - id: "OPEN-P01-003" + beschreibung: "Checkliste Katalog-Review erstellen" + prioritaet: "mittel" + ziel_ordner: "02.6_arbeitsmaterialien" + + - id: "OPEN-P01-004" + beschreibung: "Klärung Publikationskanal und Betriebsverantwortung" + prioritaet: "mittel" + status: "Abstimmung mit IT-Betrieb/Webteam nötig" + + - id: "OPEN-P01-005" + beschreibung: "SHM-Einbindung operationalisieren" + prioritaet: "niedrig" + abhaengig_von: "Finalisierung SHM-Modul" + + - id: "OPEN-P01-006" + beschreibung: "ITSM-Tool-Integration spezifizieren" + prioritaet: "niedrig" + abhaengig_von: "Tool-Auswahl" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.4" + datum: "2026-03-09" + aenderung: | + - Kategorie I (Interne Services) in kategorien_logik und Katalog-Ausschlussregel ergänzt + - Expliziter Hinweis: Katalog enthält ausschließlich Kategorie A, B, C + - nicht_enthalten-Liste aktualisiert (Verweis auf GOV-SPM-I-001, GOV-SPM-I-003) + autor: "DIGITOM-Projekt" + referenz: "PENDING-SPM-001, DC-001, DC-003" + + - version: "0.3" + datum: "2026-01-31" + aenderung: "Metrik 'Katalog-Abdeckung' präzisiert: Bezug auf Steckbriefe statt Definitionen" + autor: "DIGITOM-Projekt" + referenz: "Begriffskonsistenz Portfolio/Katalog vs. Definition/Steckbrief" + + - version: "0.2" + datum: "2026-01-30" + aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation)" + autor: "DIGITOM-Projekt" + referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" + + - version: "0.1" + datum: "2025-11-27" + aenderung: "Initiale Practice-Konzeption" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_rollen.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_rollen.yaml index 678de2a..5b72f64 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_rollen.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_rollen.yaml @@ -1,500 +1,500 @@ -# ============================================================================= -# SERVICE-SUPPORT-MANAGEMENT: ROLLEN -# ============================================================================= - -metadata: - id: "SSM-ROLLEN" - name: "Rollen Service-Support-Management" - version: "0.2" - status: "draft" - erstellt: "2025-12-07" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - beschreibung: | - Konsolidierte Rollendefinitionen für das Service-Support-Management. - Erweitert und konkretisiert die generischen Rollen aus - spm_rollen.yaml für den Support-Kontext. - - referenz_basis: "02_spm_service-lifecycle-blueprint/spm_rollen.yaml" - - design_referenz: "ssm_design-zieldimensionen.yaml" - relevante_saeulen: ["LS-03"] - -# ============================================================================= -# ROLLENKATEGORIEN -# ============================================================================= - -rollenkategorien: - - - kategorie: "Operative Rollen" - beschreibung: "Rollen in der direkten Ticket-Bearbeitung" - rollen: ["first_level_agent", "second_level_agent"] - - - kategorie: "Koordinations-Rollen" - beschreibung: "Rollen in der Steuerung und Koordination" - rollen: ["queue_koordinator"] - - - kategorie: "Management-Rollen" - beschreibung: "Rollen mit Führungs- und Prozessverantwortung" - rollen: ["support_manager", "service_owner"] - -# ============================================================================= -# ROLLENDEFINITIONEN -# ============================================================================= - -rollen: - - # --------------------------------------------------------------------------- - # OPERATIVE ROLLEN - # --------------------------------------------------------------------------- - - - id: "first_level_agent" - name: "First Level Agent" - kurzform: "L1-Agent" - kategorie: "Operative Rollen" - - beschreibung: | - Bearbeiter im First Level Support. Erster Ansprechpartner für - Nutzer, verantwortlich für Ticket-Erfassung, Erstdiagnose und - Lösung dokumentierter Störungen. - - verantwortlichkeiten: - - "Ticket-Erfassung und Qualifizierung (DoR-Prüfung)" - - "Klassifikation und Priorisierung nach Matrix" - - "KB-Konsultation und Erstdiagnose" - - "Lösung von Incidents im L1-Scope" - - "Bearbeitung von Standard-Requests" - - "Dokumentation aller Aktivitäten im Ticket" - - "Eskalation an L2 mit vollständiger DoH" - - "Erstellung von KB-Artikeln (Ebene 3)" - - befugnisse: - - "Ticket-Annahme und Selbstzuweisung (Standard-/Sofort-Pool)" - - "Priorisierung nach Impact-Urgency-Matrix" - - "Funktionale Eskalation an L2" - - "Änderung von KB-Artikeln Ebene 3" - - einschraenkungen: - - "Keine Priorisierungs-Abweichung von Matrix ohne Genehmigung" - - "Keine Ticket-Rückgabe ohne Empfänger-Akzeptanz" - - "Keine Änderung von KB-Artikeln Ebene 1/2" - - scope_definition: - kann_loesen_wenn: - - "KB-Artikel oder dokumentierte Lösung vorhanden" - - "Erforderliche technische Berechtigung vorhanden" - - "Lösung liegt im definierten L1-Scope" - eskaliert_wenn: - - "Keine passende Dokumentation vorhanden" - - "Berechtigung fehlt" - - "Explorative Diagnose (90-120 Min) ausgeschöpft ohne Fortschritt" - - "P1 nicht in 15 Min lösbar" - - qualifikation: - - "Grundkenntnisse der unterstützten Services" - - "ITSM-Tool-Schulung" - - "Kommunikationsfähigkeit" - - "KB-Nutzung und -Pflege" - - yasm_entsprechung: "1st Level Support" - itil4_entsprechung: "Service Desk Agent" - - # --------------------------------------------------------------------------- - - - id: "second_level_agent" - name: "Second Level Agent" - kurzform: "L2-Agent" - kategorie: "Operative Rollen" - - beschreibung: | - Spezialist im Second Level Support. Bearbeitet komplexe - Incidents, die im L1 nicht lösbar sind. Tiefergehende - technische Diagnose und Lösung. - - verantwortlichkeiten: - - "Bearbeitung eskalierter Incidents" - - "Tiefergehende technische Diagnose" - - "Lösung komplexer Störungen" - - "Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten" - - "Erstellung von Problem Records bei Bedarf" - - "Dokumentation von Lösungen und Workarounds" - - "Erstellung/Pflege von KB-Artikeln (Ebene 2 und 3)" - - "Unterstützung bei Major Incidents" - - "Problem Records erstellen (bei Erkennung in Incident-Bearbeitung)" - - "Root-Cause-Analyse durchführen (bei Delegation durch Service Owner)" - - "Known-Error-Artikel erstellen und pflegen" - - befugnisse: - - "Ticket-Annahme aus L2-Pool" - - "Eskalation an L3/Externe" - - "Problem Record erstellen" - - "Change Request initiieren" - - "KB-Artikel Ebene 2 erstellen (mit SO-Freigabe)" - - "KB-Artikel Ebene 3 erstellen und ändern" - - einschraenkungen: - - "Keine Ticket-Rückgabe an L1 ohne Akzeptanz + Begründung" - - "Keine Freigabe von KB-Artikeln Ebene 1" - - qualifikation: - - "Vertiefte technische Kenntnisse in Fachgebiet" - - "Diagnose- und Problemlösungskompetenz" - - "Erfahrung mit Root-Cause-Analyse" - - spezialisierungen: - beschreibung: | - L2-Agents können nach Fachgebiet spezialisiert sein. - Die Zuweisung erfolgt über Domain-Pools. - beispiele: - - "Netzwerk & Infrastruktur" - - "Client & Workplace" - - "Fachverfahren (SAP, GIS, etc.)" - - "E-Mail & Collaboration" - - yasm_entsprechung: "2nd Level Support" - itil4_entsprechung: "Technical Support Specialist" - - # --------------------------------------------------------------------------- - # KOORDINATIONS-ROLLEN - # --------------------------------------------------------------------------- - - - id: "queue_koordinator" - name: "Queue-Koordinator" - kurzform: "QK" - kategorie: "Koordinations-Rollen" - - beschreibung: | - Verantwortlich für die operative Steuerung der Ticket-Queues. - Überwacht Workload, priorisiert innerhalb der Pools und - koordiniert bei Engpässen oder Konflikten. - - verantwortlichkeiten: - - "Überwachung der Ticket-Queues und SLA-Status" - - "Aktive Zuweisung im Analyse-Pool" - - "Priorisierung bei Konflikten innerhalb eines Pools" - - "Entscheidung bei Übergabe-Konflikten" - - "Erste Eskalationsstufe für operative Probleme" - - "Qualitätssicherung: Stichproben-Review von DoH und KB-Artikeln" - - "Koordination bei Kapazitätsengpässen" - - "Leitung des monatlichen KB-Reviews (Ebene 3)" - - "Wiederkehrende Incident-Muster in Queues erkennen" - - "Service Owner auf erkannte Muster hinweisen" - - befugnisse: - - "Ticket-Umpriorisierung (mit Begründung)" - - "Ticket-Zuweisung und -Umzuweisung" - - "Eskalation an Teamleitung" - - "Wiedereröffnung geschlossener Tickets" - - "Freigabe von Abweichungen von Standard-Prozess" - - einschraenkungen: - - "Keine eigene Ticket-Bearbeitung (Fokus auf Koordination)" - - "Keine SLA-Änderungen" - - modelle: - beschreibung: | - Je nach Teamgröße und -struktur kann die Rolle unterschiedlich - besetzt werden. - varianten: - - modell: "Dediziert" - beschreibung: "Eigenständige Rolle, keine Ticket-Bearbeitung" - empfohlen_ab: "Team > 10 Agents" - - modell: "Rotierend" - beschreibung: "Wechselnde Besetzung durch erfahrene Agents" - empfohlen_fuer: "Kleinere Teams" - - modell: "Teilzeit" - beschreibung: "Kombiniert mit L2-Tätigkeit" - empfohlen_fuer: "Mittlere Teams" - - design_referenz: "LS-03 (Organisation & Teamstruktur)" - - qualifikation: - - "Erfahrung im First oder Second Level Support (mind. 2 Jahre)" - - "Überblick über alle unterstützten Services" - - "Priorisierungs- und Entscheidungskompetenz" - - "Kommunikationsfähigkeit und Durchsetzungsvermögen" - - "ITSM-Tool: Fortgeschrittene Kenntnisse (Reporting, Queue-Mgmt)" - - "Verständnis von SLA-Strukturen und Eskalationswegen" - - yasm_entsprechung: "-" - itil4_entsprechung: "Queue Manager / Shift Lead" - - # --------------------------------------------------------------------------- - # MANAGEMENT-ROLLEN - # --------------------------------------------------------------------------- - - - id: "support_manager" - name: "Support Manager" - kurzform: "SM" - kategorie: "Management-Rollen" - - beschreibung: | - Gesamtverantwortung für den Service-Support-Bereich. - Prozess-Owner für Incident, Request und Problem Management. - Führungsverantwortung für das Support-Team. - - verantwortlichkeiten: - - "Prozess-Ownership für SSM-Practices" - - "Führung des Support-Teams" - - "Kapazitätsplanung und Ressourcenmanagement" - - "Eskalationsstufe für nicht lösbare Konflikte" - - "Reporting und KPI-Verantwortung" - - "Kontinuierliche Prozessverbesserung" - - "Schnittstelle zu Service Ownern" - - "Budget-Verantwortung für Support-Bereich" - - befugnisse: - - "Prozess-Änderungen (mit Governance-Dokumentation)" - - "Ressourcen-Allokation" - - "SLA-Verhandlung (in Abstimmung mit Service Owner)" - - "Eskalation an Abteilungsleitung" - - accountable_fuer: - - "Incident Management (P-04)" - - "Request Management (P-05)" - - "Problem Management (P-06)" - - "Service Desk (P-SD)" - - "KB Ebene 3 Qualität" - - einschraenkungen: - - "Keine operative Ticket-Bearbeitung (Fokus auf Steuerung)" - - "SLA-Änderungen nur in Abstimmung mit Service Owner" - - "Prozess-Änderungen erfordern Governance-Dokumentation" - - "Budget-Entscheidungen über definiertem Schwellwert erfordern Genehmigung" - - qualifikation: - - "Mehrjährige Erfahrung im IT-Service-Management" - - "Führungserfahrung (Team > 5 Personen)" - - "ITIL Foundation oder vergleichbare Zertifizierung" - - "Kenntnisse in Prozessmanagement und -optimierung" - - "Erfahrung mit KPI-Definition und Reporting" - - "Kommunikations- und Konfliktlösungskompetenz" - - yasm_entsprechung: "Service Desk Manager" - itil4_entsprechung: "Service Desk Manager" - - # --------------------------------------------------------------------------- - - - id: "service_owner" - name: "Service Owner" - kurzform: "SO" - kategorie: "Management-Rollen" - - beschreibung: | - End-to-End-Verantwortung für einen spezifischen Service. - Im Support-Kontext: Fachliche Eskalationsinstanz und - Verantwortlicher für Service-spezifische Dokumentation. - - verantwortlichkeiten_support: - - "Fachliche Eskalationsinstanz bei Major Incidents" - - "Verantwortung für KB Ebene 1 (Grundlagendokumentation)" - - "Co-Creation KB Ebene 2 (Arbeitsdokumentation)" - - "SLA-Vereinbarung und -Überwachung für den Service" - - "Entscheidung bei Service-spezifischen Priorisierungskonflikten" - - "Kommunikation bei schwerwiegenden Service-Störungen" - - "Process Owner für Problem Management im eigenen Service-Bereich" - - "Koordination und ggf. Durchführung von Root-Cause-Analysen" - - "Sicherstellung der Workaround-Dokumentation" - - "Entscheidung über permanente Lösungen (Change-Initiierung)" - - "Problem-Priorisierung und -Überwachung" - - befugnisse_support: - - "Fachliche Eskalationsentscheidung bei Major Incidents" - - "Freigabe von KB-Artikeln Ebene 1 und 2" - - "Priorisierungs-Override für Service-spezifische Tickets (mit Begründung)" - - "Change-Initiierung aus Problem Management" - - "SLA-Vereinbarung und -Anpassung für den Service" - - "Delegation von Problem-Management-Aufgaben an L2-Agents" - - "Problem Records priorisieren und schließen" - - einschraenkungen_support: - - "Keine operative Ticket-Bearbeitung (außer im MVP als Teil des L2-Teams)" - - "Keine Pool-Steuerung (Verantwortung Queue-Koordinator)" - - "Keine Änderung von SSM-Prozessen ohne Abstimmung mit Support Manager" - - qualifikation_support: - - "Tiefes Fachwissen zum verantworteten Service" - - "Verständnis der End-to-End-Servicekette" - - "Kommunikationsfähigkeit (intern und zu Kunden/Ämtern)" - - "Grundverständnis von ITSM-Prozessen" - - schnittstelle_support: - von_support: "Eskalationen, Problem Records, Verbesserungsvorschläge" - an_support: "Service-Updates, Dokumentation, SLA-Änderungen" - - referenz: "spm_rollen.yaml → service_owner" - - yasm_entsprechung: "Service Owner" - itil4_entsprechung: "Service Owner" - -# ============================================================================= -# KONTEXTABHÄNGIGE FUNKTIONEN -# ============================================================================= - -kontextabhaengige_funktionen: - - beschreibung: | - Folgende Funktionen erscheinen in RACI-Matrizen und Prozessbeschreibungen, - sind aber keine festen SSM-Rollen. Sie werden je Kontext oder - Katalog-Eintrag zugewiesen. - - funktionen: - - - funktion: "Genehmiger" - beschreibung: | - Zuständig für die Genehmigung von Service Requests. Wird je - Katalog-Eintrag definiert. Die Genehmiger-Zuordnung ist Teil - des Service-Katalogs, nicht der SSM-Rollendefinition. - typische_genehmiger: - - "Vorgesetzter des Antragstellers" - - "IT-Sicherheitsbeauftragter" - - "Amtsleitung / Budgetverantwortlicher" - - "Service Owner (für Service-spezifische Genehmigungen)" - referenz: "sub-practice_request-management.yaml → kernkonzepte.genehmigungsprinzipien" - governance: "SSM-G-15" - - - funktion: "Lieferant / L3-Support" - beschreibung: | - Externe Hersteller oder Dienstleister für Eskalation bei - herstellerspezifischen Problemen oder vertraglich vereinbartem - Support. - einbindung: - - "Eskalation durch L2 bei Herstellerfehlern" - - "Vertraglich vereinbarter Support (SLA)" - - "Lizenz- oder Wartungsverträge" - referenz: "spm_rollen.yaml → externe.lieferant" - - hinweis_teamleitung: - beschreibung: | - In Prozessbeschreibungen wird teilweise der Begriff "Teamleitung" - verwendet. Im SSM-Kontext ist dies kontextabhängig zu verstehen: - - mapping: - - begriff: "Teamleitung" - kontext: "Hierarchische Eskalation im Service Desk" - entspricht: "Support Manager" - - - begriff: "Gruppenleitung" - kontext: "Organisatorische Einheit Service Desk" - entspricht: "Support Manager oder dedizierte Gruppenleitung" - - hinweis: | - Die konkrete Besetzung hängt von der Organisationsstruktur bei - DIGIT ab. Im MVP kann der Support Manager auch die Gruppenleitung sein. - -# ============================================================================= -# RACI-REFERENZ -# ============================================================================= - -raci_referenz: - - beschreibung: | - Die konsolidierte RACI-Matrix für alle SSM-Aktivitäten ist in - ssm_governance.yaml → raci_konsolidiert definiert. - - Dieses Dokument definiert die Rollen, nicht die Zuordnungen. - - master_dokument: "ssm_governance.yaml" - abschnitt: "raci_konsolidiert" - - bereiche: - - "incident_management" - - "request_management" - - "problem_management" - - "wissensmanagement" - - "service_desk" - - "eskalation" - - "reporting" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - modul: "spm_rollen.yaml" - art: "erweitert" - beschreibung: | - SSM-spezifische Konkretisierung der SPM-Basisrollen. - Übergeordnete Rollen (SPM, Mission Board) sind dort definiert - und werden in ssm_governance.yaml für die Eskalationskette - referenziert. - - - modul: "sub-practice_incident-management.yaml" - art: "wird referenziert von" - beschreibung: "RACI-Zuordnungen in Incident-Aktivitäten" - - - modul: "sub-practice_request-management.yaml" - art: "wird referenziert von" - beschreibung: "RACI-Zuordnungen in Request-Aktivitäten" - - - modul: "ssm_wissensmanagement.yaml" - art: "wird referenziert von" - beschreibung: "KB-Governance je Ebene" - - - modul: "sub-practice_service-desk.yaml" - art: "wird referenziert von" - beschreibung: "Service Desk Organisationsmodell nutzt Rollen" - - - modul: "ssm_governance.yaml" - art: "wird referenziert von" - beschreibung: "Eskalationskette basiert auf Rollenmodell" - - extern: - - partner: "Service-Portfolio-Management (SPM)" - kontext: "Übergeordnete Steuerung, strategische Entscheidungen" - rollen_dort: ["spm (Service-Portfolio-Manager)"] - referenz: "spm_rollen.yaml" - - - partner: "Mission Board" - kontext: "Höchste Eskalationsstufe, strategische Grundsatzentscheidungen" - referenz: "spm_rollen.yaml → sor (Service Operations Runde)" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-ROLLEN-001" - thema: "Queue-Koordinator-Modell für DIGIT" - beschreibung: "Welches Modell (dediziert/rotierend/teilzeit) passt für DIGIT?" - prioritaet: "hoch" - status: "Mit DIGIT abstimmen" - - - id: "OPEN-ROLLEN-002" - thema: "L2-Spezialisierungen" - beschreibung: "Konkrete Domain-Pools für DIGIT definieren" - prioritaet: "mittel" - status: "Nach Service-Katalog-Analyse" - - - id: "OPEN-ROLLEN-003" - thema: "Genehmiger-Zuordnung je Katalog-Eintrag" - beschreibung: | - Die konkreten Genehmiger für jeden Katalog-Eintrag müssen - im Rahmen der Service-Katalog-Implementierung definiert werden. - prioritaet: "mittel" - status: "Abhängig von SCM (P-01)" - abhaengig_von: "spm_practice_service-catalog-management.yaml" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.2" - datum: "2025-12-07" - aenderung: | - - Queue-Koordinator: Qualifikation ergänzt - - Support Manager: Einschränkungen und Qualifikation ergänzt - - Service Owner: Befugnisse und Einschränkungen für Support-Kontext ergänzt - - Neuer Abschnitt: Kontextabhängige Funktionen (Genehmiger, Lieferant, Teamleitung) - - Schnittstellen zu übergeordneten Rollen (SPM, MB) expliziert - autor: "DIGITOM-Projekt" - - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung mit Minimal-Rollensatz" - autor: "DIGITOM-Projekt" +# ============================================================================= +# SERVICE-SUPPORT-MANAGEMENT: ROLLEN +# ============================================================================= + +metadata: + id: "SSM-ROLLEN" + name: "Rollen Service-Support-Management" + version: "0.2" + status: "draft" + erstellt: "2025-12-07" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + + beschreibung: | + Konsolidierte Rollendefinitionen für das Service-Support-Management. + Erweitert und konkretisiert die generischen Rollen aus + spm_rollen.yaml für den Support-Kontext. + + referenz_basis: "02_spm_service-lifecycle-blueprint/spm_rollen.yaml" + + design_referenz: "ssm_design-zieldimensionen.yaml" + relevante_saeulen: ["LS-03"] + +# ============================================================================= +# ROLLENKATEGORIEN +# ============================================================================= + +rollenkategorien: + + - kategorie: "Operative Rollen" + beschreibung: "Rollen in der direkten Ticket-Bearbeitung" + rollen: ["first_level_agent", "second_level_agent"] + + - kategorie: "Koordinations-Rollen" + beschreibung: "Rollen in der Steuerung und Koordination" + rollen: ["queue_koordinator"] + + - kategorie: "Management-Rollen" + beschreibung: "Rollen mit Führungs- und Prozessverantwortung" + rollen: ["support_manager", "service_owner"] + +# ============================================================================= +# ROLLENDEFINITIONEN +# ============================================================================= + +rollen: + + # --------------------------------------------------------------------------- + # OPERATIVE ROLLEN + # --------------------------------------------------------------------------- + + - id: "first_level_agent" + name: "First Level Agent" + kurzform: "L1-Agent" + kategorie: "Operative Rollen" + + beschreibung: | + Bearbeiter im First Level Support. Erster Ansprechpartner für + Nutzer, verantwortlich für Ticket-Erfassung, Erstdiagnose und + Lösung dokumentierter Störungen. + + verantwortlichkeiten: + - "Ticket-Erfassung und Qualifizierung (DoR-Prüfung)" + - "Klassifikation und Priorisierung nach Matrix" + - "KB-Konsultation und Erstdiagnose" + - "Lösung von Incidents im L1-Scope" + - "Bearbeitung von Standard-Requests" + - "Dokumentation aller Aktivitäten im Ticket" + - "Eskalation an L2 mit vollständiger DoH" + - "Erstellung von KB-Artikeln (Ebene 3)" + + befugnisse: + - "Ticket-Annahme und Selbstzuweisung (Standard-/Sofort-Pool)" + - "Priorisierung nach Impact-Urgency-Matrix" + - "Funktionale Eskalation an L2" + - "Änderung von KB-Artikeln Ebene 3" + + einschraenkungen: + - "Keine Priorisierungs-Abweichung von Matrix ohne Genehmigung" + - "Keine Ticket-Rückgabe ohne Empfänger-Akzeptanz" + - "Keine Änderung von KB-Artikeln Ebene 1/2" + + scope_definition: + kann_loesen_wenn: + - "KB-Artikel oder dokumentierte Lösung vorhanden" + - "Erforderliche technische Berechtigung vorhanden" + - "Lösung liegt im definierten L1-Scope" + eskaliert_wenn: + - "Keine passende Dokumentation vorhanden" + - "Berechtigung fehlt" + - "Explorative Diagnose (90-120 Min) ausgeschöpft ohne Fortschritt" + - "P1 nicht in 15 Min lösbar" + + qualifikation: + - "Grundkenntnisse der unterstützten Services" + - "ITSM-Tool-Schulung" + - "Kommunikationsfähigkeit" + - "KB-Nutzung und -Pflege" + + yasm_entsprechung: "1st Level Support" + itil4_entsprechung: "Service Desk Agent" + + # --------------------------------------------------------------------------- + + - id: "second_level_agent" + name: "Second Level Agent" + kurzform: "L2-Agent" + kategorie: "Operative Rollen" + + beschreibung: | + Spezialist im Second Level Support. Bearbeitet komplexe + Incidents, die im L1 nicht lösbar sind. Tiefergehende + technische Diagnose und Lösung. + + verantwortlichkeiten: + - "Bearbeitung eskalierter Incidents" + - "Tiefergehende technische Diagnose" + - "Lösung komplexer Störungen" + - "Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten" + - "Erstellung von Problem Records bei Bedarf" + - "Dokumentation von Lösungen und Workarounds" + - "Erstellung/Pflege von KB-Artikeln (Ebene 2 und 3)" + - "Unterstützung bei Major Incidents" + - "Problem Records erstellen (bei Erkennung in Incident-Bearbeitung)" + - "Root-Cause-Analyse durchführen (bei Delegation durch Service Owner)" + - "Known-Error-Artikel erstellen und pflegen" + + befugnisse: + - "Ticket-Annahme aus L2-Pool" + - "Eskalation an L3/Externe" + - "Problem Record erstellen" + - "Change Request initiieren" + - "KB-Artikel Ebene 2 erstellen (mit SO-Freigabe)" + - "KB-Artikel Ebene 3 erstellen und ändern" + + einschraenkungen: + - "Keine Ticket-Rückgabe an L1 ohne Akzeptanz + Begründung" + - "Keine Freigabe von KB-Artikeln Ebene 1" + + qualifikation: + - "Vertiefte technische Kenntnisse in Fachgebiet" + - "Diagnose- und Problemlösungskompetenz" + - "Erfahrung mit Root-Cause-Analyse" + + spezialisierungen: + beschreibung: | + L2-Agents können nach Fachgebiet spezialisiert sein. + Die Zuweisung erfolgt über Domain-Pools. + beispiele: + - "Netzwerk & Infrastruktur" + - "Client & Workplace" + - "Fachverfahren (SAP, GIS, etc.)" + - "E-Mail & Collaboration" + + yasm_entsprechung: "2nd Level Support" + itil4_entsprechung: "Technical Support Specialist" + + # --------------------------------------------------------------------------- + # KOORDINATIONS-ROLLEN + # --------------------------------------------------------------------------- + + - id: "queue_koordinator" + name: "Queue-Koordinator" + kurzform: "QK" + kategorie: "Koordinations-Rollen" + + beschreibung: | + Verantwortlich für die operative Steuerung der Ticket-Queues. + Überwacht Workload, priorisiert innerhalb der Pools und + koordiniert bei Engpässen oder Konflikten. + + verantwortlichkeiten: + - "Überwachung der Ticket-Queues und SLA-Status" + - "Aktive Zuweisung im Analyse-Pool" + - "Priorisierung bei Konflikten innerhalb eines Pools" + - "Entscheidung bei Übergabe-Konflikten" + - "Erste Eskalationsstufe für operative Probleme" + - "Qualitätssicherung: Stichproben-Review von DoH und KB-Artikeln" + - "Koordination bei Kapazitätsengpässen" + - "Leitung des monatlichen KB-Reviews (Ebene 3)" + - "Wiederkehrende Incident-Muster in Queues erkennen" + - "Service Owner auf erkannte Muster hinweisen" + + befugnisse: + - "Ticket-Umpriorisierung (mit Begründung)" + - "Ticket-Zuweisung und -Umzuweisung" + - "Eskalation an Teamleitung" + - "Wiedereröffnung geschlossener Tickets" + - "Freigabe von Abweichungen von Standard-Prozess" + + einschraenkungen: + - "Keine eigene Ticket-Bearbeitung (Fokus auf Koordination)" + - "Keine SLA-Änderungen" + + modelle: + beschreibung: | + Je nach Teamgröße und -struktur kann die Rolle unterschiedlich + besetzt werden. + varianten: + - modell: "Dediziert" + beschreibung: "Eigenständige Rolle, keine Ticket-Bearbeitung" + empfohlen_ab: "Team > 10 Agents" + - modell: "Rotierend" + beschreibung: "Wechselnde Besetzung durch erfahrene Agents" + empfohlen_fuer: "Kleinere Teams" + - modell: "Teilzeit" + beschreibung: "Kombiniert mit L2-Tätigkeit" + empfohlen_fuer: "Mittlere Teams" + + design_referenz: "LS-03 (Organisation & Teamstruktur)" + + qualifikation: + - "Erfahrung im First oder Second Level Support (mind. 2 Jahre)" + - "Überblick über alle unterstützten Services" + - "Priorisierungs- und Entscheidungskompetenz" + - "Kommunikationsfähigkeit und Durchsetzungsvermögen" + - "ITSM-Tool: Fortgeschrittene Kenntnisse (Reporting, Queue-Mgmt)" + - "Verständnis von SLA-Strukturen und Eskalationswegen" + + yasm_entsprechung: "-" + itil4_entsprechung: "Queue Manager / Shift Lead" + + # --------------------------------------------------------------------------- + # MANAGEMENT-ROLLEN + # --------------------------------------------------------------------------- + + - id: "support_manager" + name: "Support Manager" + kurzform: "SM" + kategorie: "Management-Rollen" + + beschreibung: | + Gesamtverantwortung für den Service-Support-Bereich. + Prozess-Owner für Incident, Request und Problem Management. + Führungsverantwortung für das Support-Team. + + verantwortlichkeiten: + - "Prozess-Ownership für SSM-Practices" + - "Führung des Support-Teams" + - "Kapazitätsplanung und Ressourcenmanagement" + - "Eskalationsstufe für nicht lösbare Konflikte" + - "Reporting und KPI-Verantwortung" + - "Kontinuierliche Prozessverbesserung" + - "Schnittstelle zu Service Ownern" + - "Budget-Verantwortung für Support-Bereich" + + befugnisse: + - "Prozess-Änderungen (mit Governance-Dokumentation)" + - "Ressourcen-Allokation" + - "SLA-Verhandlung (in Abstimmung mit Service Owner)" + - "Eskalation an Abteilungsleitung" + + accountable_fuer: + - "Incident Management (P-04)" + - "Request Management (P-05)" + - "Problem Management (P-06)" + - "Service Desk (P-SD)" + - "KB Ebene 3 Qualität" + + einschraenkungen: + - "Keine operative Ticket-Bearbeitung (Fokus auf Steuerung)" + - "SLA-Änderungen nur in Abstimmung mit Service Owner" + - "Prozess-Änderungen erfordern Governance-Dokumentation" + - "Budget-Entscheidungen über definiertem Schwellwert erfordern Genehmigung" + + qualifikation: + - "Mehrjährige Erfahrung im IT-Service-Management" + - "Führungserfahrung (Team > 5 Personen)" + - "ITIL Foundation oder vergleichbare Zertifizierung" + - "Kenntnisse in Prozessmanagement und -optimierung" + - "Erfahrung mit KPI-Definition und Reporting" + - "Kommunikations- und Konfliktlösungskompetenz" + + yasm_entsprechung: "Service Desk Manager" + itil4_entsprechung: "Service Desk Manager" + + # --------------------------------------------------------------------------- + + - id: "service_owner" + name: "Service Owner" + kurzform: "SO" + kategorie: "Management-Rollen" + + beschreibung: | + End-to-End-Verantwortung für einen spezifischen Service. + Im Support-Kontext: Fachliche Eskalationsinstanz und + Verantwortlicher für Service-spezifische Dokumentation. + + verantwortlichkeiten_support: + - "Fachliche Eskalationsinstanz bei Major Incidents" + - "Verantwortung für KB Ebene 1 (Grundlagendokumentation)" + - "Co-Creation KB Ebene 2 (Arbeitsdokumentation)" + - "SLA-Vereinbarung und -Überwachung für den Service" + - "Entscheidung bei Service-spezifischen Priorisierungskonflikten" + - "Kommunikation bei schwerwiegenden Service-Störungen" + - "Process Owner für Problem Management im eigenen Service-Bereich" + - "Koordination und ggf. Durchführung von Root-Cause-Analysen" + - "Sicherstellung der Workaround-Dokumentation" + - "Entscheidung über permanente Lösungen (Change-Initiierung)" + - "Problem-Priorisierung und -Überwachung" + + befugnisse_support: + - "Fachliche Eskalationsentscheidung bei Major Incidents" + - "Freigabe von KB-Artikeln Ebene 1 und 2" + - "Priorisierungs-Override für Service-spezifische Tickets (mit Begründung)" + - "Change-Initiierung aus Problem Management" + - "SLA-Vereinbarung und -Anpassung für den Service" + - "Delegation von Problem-Management-Aufgaben an L2-Agents" + - "Problem Records priorisieren und schließen" + + einschraenkungen_support: + - "Keine operative Ticket-Bearbeitung (außer im MVP als Teil des L2-Teams)" + - "Keine Pool-Steuerung (Verantwortung Queue-Koordinator)" + - "Keine Änderung von SSM-Prozessen ohne Abstimmung mit Support Manager" + + qualifikation_support: + - "Tiefes Fachwissen zum verantworteten Service" + - "Verständnis der End-to-End-Servicekette" + - "Kommunikationsfähigkeit (intern und zu Kunden/Ämtern)" + - "Grundverständnis von ITSM-Prozessen" + + schnittstelle_support: + von_support: "Eskalationen, Problem Records, Verbesserungsvorschläge" + an_support: "Service-Updates, Dokumentation, SLA-Änderungen" + + referenz: "spm_rollen.yaml → service_owner" + + yasm_entsprechung: "Service Owner" + itil4_entsprechung: "Service Owner" + +# ============================================================================= +# KONTEXTABHÄNGIGE FUNKTIONEN +# ============================================================================= + +kontextabhaengige_funktionen: + + beschreibung: | + Folgende Funktionen erscheinen in RACI-Matrizen und Prozessbeschreibungen, + sind aber keine festen SSM-Rollen. Sie werden je Kontext oder + Katalog-Eintrag zugewiesen. + + funktionen: + + - funktion: "Genehmiger" + beschreibung: | + Zuständig für die Genehmigung von Service Requests. Wird je + Katalog-Eintrag definiert. Die Genehmiger-Zuordnung ist Teil + des Service-Katalogs, nicht der SSM-Rollendefinition. + typische_genehmiger: + - "Vorgesetzter des Antragstellers" + - "IT-Sicherheitsbeauftragter" + - "Amtsleitung / Budgetverantwortlicher" + - "Service Owner (für Service-spezifische Genehmigungen)" + referenz: "sub-practice_request-management.yaml → kernkonzepte.genehmigungsprinzipien" + governance: "SSM-G-15" + + - funktion: "Lieferant / L3-Support" + beschreibung: | + Externe Hersteller oder Dienstleister für Eskalation bei + herstellerspezifischen Problemen oder vertraglich vereinbartem + Support. + einbindung: + - "Eskalation durch L2 bei Herstellerfehlern" + - "Vertraglich vereinbarter Support (SLA)" + - "Lizenz- oder Wartungsverträge" + referenz: "spm_rollen.yaml → externe.lieferant" + + hinweis_teamleitung: + beschreibung: | + In Prozessbeschreibungen wird teilweise der Begriff "Teamleitung" + verwendet. Im SSM-Kontext ist dies kontextabhängig zu verstehen: + + mapping: + - begriff: "Teamleitung" + kontext: "Hierarchische Eskalation im Service Desk" + entspricht: "Support Manager" + + - begriff: "Gruppenleitung" + kontext: "Organisatorische Einheit Service Desk" + entspricht: "Support Manager oder dedizierte Gruppenleitung" + + hinweis: | + Die konkrete Besetzung hängt von der Organisationsstruktur bei + DIGIT ab. Im MVP kann der Support Manager auch die Gruppenleitung sein. + +# ============================================================================= +# RACI-REFERENZ +# ============================================================================= + +raci_referenz: + + beschreibung: | + Die konsolidierte RACI-Matrix für alle SSM-Aktivitäten ist in + ssm_governance.yaml → raci_konsolidiert definiert. + + Dieses Dokument definiert die Rollen, nicht die Zuordnungen. + + master_dokument: "ssm_governance.yaml" + abschnitt: "raci_konsolidiert" + + bereiche: + - "incident_management" + - "request_management" + - "problem_management" + - "wissensmanagement" + - "service_desk" + - "eskalation" + - "reporting" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + - modul: "spm_rollen.yaml" + art: "erweitert" + beschreibung: | + SSM-spezifische Konkretisierung der SPM-Basisrollen. + Übergeordnete Rollen (SPM, Mission Board) sind dort definiert + und werden in ssm_governance.yaml für die Eskalationskette + referenziert. + + - modul: "sub-practice_incident-management.yaml" + art: "wird referenziert von" + beschreibung: "RACI-Zuordnungen in Incident-Aktivitäten" + + - modul: "sub-practice_request-management.yaml" + art: "wird referenziert von" + beschreibung: "RACI-Zuordnungen in Request-Aktivitäten" + + - modul: "ssm_wissensmanagement.yaml" + art: "wird referenziert von" + beschreibung: "KB-Governance je Ebene" + + - modul: "sub-practice_service-desk.yaml" + art: "wird referenziert von" + beschreibung: "Service Desk Organisationsmodell nutzt Rollen" + + - modul: "ssm_governance.yaml" + art: "wird referenziert von" + beschreibung: "Eskalationskette basiert auf Rollenmodell" + + extern: + - partner: "Service-Portfolio-Management (SPM)" + kontext: "Übergeordnete Steuerung, strategische Entscheidungen" + rollen_dort: ["spm (Service-Portfolio-Manager)"] + referenz: "spm_rollen.yaml" + + - partner: "Mission Board" + kontext: "Höchste Eskalationsstufe, strategische Grundsatzentscheidungen" + referenz: "spm_rollen.yaml → sor (Service Operations Runde)" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-ROLLEN-001" + thema: "Queue-Koordinator-Modell für DIGIT" + beschreibung: "Welches Modell (dediziert/rotierend/teilzeit) passt für DIGIT?" + prioritaet: "hoch" + status: "Mit DIGIT abstimmen" + + - id: "OPEN-ROLLEN-002" + thema: "L2-Spezialisierungen" + beschreibung: "Konkrete Domain-Pools für DIGIT definieren" + prioritaet: "mittel" + status: "Nach Service-Katalog-Analyse" + + - id: "OPEN-ROLLEN-003" + thema: "Genehmiger-Zuordnung je Katalog-Eintrag" + beschreibung: | + Die konkreten Genehmiger für jeden Katalog-Eintrag müssen + im Rahmen der Service-Katalog-Implementierung definiert werden. + prioritaet: "mittel" + status: "Abhängig von SCM (P-01)" + abhaengig_von: "spm_practice_service-catalog-management.yaml" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.2" + datum: "2025-12-07" + aenderung: | + - Queue-Koordinator: Qualifikation ergänzt + - Support Manager: Einschränkungen und Qualifikation ergänzt + - Service Owner: Befugnisse und Einschränkungen für Support-Kontext ergänzt + - Neuer Abschnitt: Kontextabhängige Funktionen (Genehmiger, Lieferant, Teamleitung) + - Schnittstellen zu übergeordneten Rollen (SPM, MB) expliziert + autor: "DIGITOM-Projekt" + + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung mit Minimal-Rollensatz" + autor: "DIGITOM-Projekt" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_schema_ticket.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_schema_ticket.yaml index dcbcdd2..d9d5b41 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_schema_ticket.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_schema_ticket.yaml @@ -1,990 +1,990 @@ -# ============================================================================= -# SSM SCHEMA: TICKET -# ============================================================================= -# Modul: Service-Support-Management (SSM) -# Typ: Schema (Informationsmodell) -# Version: 0.1 -# Datum: 2025-12-07 -# Status: draft -# ============================================================================= - -meta: - schema_id: "SSM-S-01" - name: "Ticket-Schema" - typ: "Schema" - - zweck: | - Definiert die Datenstruktur für Support-Tickets (Incidents und Requests). - Das Schema dient als Grundlage für: - - ITSM-Tool-Konfiguration (Pflichtfelder, Feldtypen) - - Definition of Ready (DoR) – Qualitätskriterien bei Ticket-Erfassung - - Reporting und KPI-Auswertung - - Prozess-Schnittstellen (Eskalation, Übergabe) - - gilt_fuer: - - "sub-practice_incident-management.yaml" - - "sub-practice_request-management.yaml" - - "sub-practice_service-desk.yaml" - - klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml" - rollen_referenz: "ssm_rollen.yaml" - - design_prinzip: | - Das Schema unterscheidet drei Attribut-Kategorien: - 1. Basis-Attribute: Für alle Ticket-Typen identisch - 2. Typ-spezifische Attribute: Nur für Incident oder Request - 3. Prozess-Attribute: Werden im Lifecycle befüllt (nicht bei Erfassung) - - Pflichtfelder sind so definiert, dass sie die DoR (Definition of Ready) - erfüllen, ohne den Erfassungsprozess zu überlasten. - -# ============================================================================= -# BASIS-ATTRIBUTE (ALLE TICKET-TYPEN) -# ============================================================================= - -basis_attribute: - - beschreibung: | - Diese Attribute gelten für alle Ticket-Typen (Incident, Request, Projekt). - Sie werden bei Ticket-Erfassung oder im frühen Lifecycle befüllt. - - # --------------------------------------------------------------------------- - # IDENTIFIKATION - # --------------------------------------------------------------------------- - identifikation: - - beschreibung: "Eindeutige Identifikation und Grunddaten" - - attribute: - - - name: "ticket_id" - typ: "string" - pflicht: true - erfassung: "automatisch" - beschreibung: "Eindeutiger Identifier, vom System vergeben" - format: "INC-YYYYMMDD-XXXXX oder REQ-YYYYMMDD-XXXXX" - beispiel: "INC-20251207-00423" - - - name: "ticket_typ" - typ: "enum" - pflicht: true - erfassung: "manuell" - beschreibung: "Grundlegende Ticket-Klassifikation" - werte: - - id: "INCIDENT" - name: "Störung" - - id: "REQUEST" - name: "Service-Anfrage" - - id: "PROJEKT" - name: "Projekt-Ticket" - referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen" - - - name: "titel" - typ: "string" - pflicht: true - erfassung: "manuell" - beschreibung: "Kurze, aussagekräftige Zusammenfassung" - max_laenge: 120 - beispiel: "Outlook stürzt beim Öffnen von Anhängen ab" - qualitaetskriterium: | - Der Titel muss das Problem/die Anfrage erkennbar machen, - ohne die Beschreibung lesen zu müssen. - - - name: "beschreibung" - typ: "text" - pflicht: true - erfassung: "manuell" - beschreibung: "Ausführliche Beschreibung des Problems oder der Anfrage" - min_laenge: 50 - qualitaetskriterium: | - Die Beschreibung muss ausreichend Kontext liefern, um - ohne Rückfrage mit der Bearbeitung beginnen zu können. - - # --------------------------------------------------------------------------- - # MELDER & BETROFFENER - # --------------------------------------------------------------------------- - personen: - - beschreibung: "Beteiligte Personen" - - attribute: - - - name: "melder" - typ: "objekt" - pflicht: true - erfassung: "automatisch/manuell" - beschreibung: "Person, die das Ticket erstellt hat" - schema: - - name: "person_id" - typ: "string" - beschreibung: "Referenz auf Verzeichnisdienst (AD)" - - name: "name" - typ: "string" - - name: "email" - typ: "string" - - name: "telefon" - typ: "string" - pflicht: false - - name: "amt" - typ: "string" - beschreibung: "Organisationseinheit des Melders" - - name: "standort" - typ: "string" - pflicht: false - - - name: "betroffener" - typ: "objekt" - pflicht: true - erfassung: "manuell" - beschreibung: | - Person, die von der Störung betroffen ist oder die Anfrage stellt. - Kann identisch mit Melder sein (Standardfall). - schema: - - name: "person_id" - typ: "string" - - name: "name" - typ: "string" - - name: "amt" - typ: "string" - default: "Melder" - - - name: "vip_flag" - typ: "boolean" - pflicht: false - erfassung: "automatisch" - beschreibung: | - Kennzeichnung für besondere Behandlung (z.B. Amtsleitung, OB-Bereich). - Beeinflusst nicht die Priorität, aber die Kommunikation. - default: false - - # --------------------------------------------------------------------------- - # KLASSIFIKATION - # --------------------------------------------------------------------------- - klassifikation: - - beschreibung: "Klassifikations-Attribute gemäß Priorisierungs-Framework" - referenz: "ssm_klassifikation-priorisierung.yaml" - - attribute: - - - name: "impact" - typ: "enum" - pflicht: true - erfassung: "manuell" - beschreibung: "Auswirkung auf den Geschäftsbetrieb" - werte: - - id: "HOCH" - code: "I-H" - kriterien: ">10 Nutzer, geschäftskritisch, Security" - - id: "NORMAL" - code: "I-N" - kriterien: "Einzelnutzer/kleine Gruppe, eingeschränkt" - - id: "NIEDRIG" - code: "I-L" - kriterien: "Komfort, Workaround verfügbar" - - - name: "urgency" - typ: "enum" - pflicht: true - erfassung: "manuell" - beschreibung: "Zeitliche Dringlichkeit" - werte: - - id: "HOCH" - code: "U-H" - kriterien: "Sofort, kein Workaround, Deadline" - - id: "NORMAL" - code: "U-N" - kriterien: "Zeitnah, temporärer Workaround" - - id: "NIEDRIG" - code: "U-L" - kriterien: "Kann warten" - - - name: "prioritaet" - typ: "enum" - pflicht: true - erfassung: "automatisch" - beschreibung: "Abgeleitet aus Impact × Urgency" - werte: - - id: "P1" - name: "Kritisch" - - id: "P2" - name: "Hoch" - - id: "P3" - name: "Normal" - - id: "P4" - name: "Niedrig" - ableitung: "ssm_klassifikation-priorisierung.yaml → impact_urgency_matrix" - - - name: "charakteristik" - typ: "enum" - pflicht: true - erfassung: "manuell" - beschreibung: "Bearbeitungscharakter des Tickets" - werte: - - id: "STANDARD" - name: "Standard-Ticket" - beschreibung: "Bekanntes Muster, klare Lösung" - - id: "ANALYSE" - name: "Analyse-Ticket" - beschreibung: "Unklare Ursache, Diagnose erforderlich" - - id: "PROJEKT" - name: "Projekt-Ticket" - beschreibung: "Planbar, umfangreich, Koordination nötig" - - - name: "pool" - typ: "enum" - pflicht: true - erfassung: "automatisch" - beschreibung: "Zugeordneter Bearbeitungs-Pool" - werte: - - id: "POOL-SOFORT" - name: "Sofort-Pool" - - id: "POOL-STANDARD" - name: "Standard Service-Pool" - - id: "POOL-ANALYSE" - name: "Analyse-Pool" - - id: "POOL-PROJEKT" - name: "Projekt-Pool" - ableitung: "ssm_klassifikation-priorisierung.yaml → ableitungslogik" - - # --------------------------------------------------------------------------- - # SERVICE-ZUORDNUNG - # --------------------------------------------------------------------------- - service_zuordnung: - - beschreibung: "Verknüpfung mit Service-Portfolio" - - attribute: - - - name: "service_id" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Referenz auf betroffenen Service (aus Service-Katalog)" - referenz: "spm_schema_service-definition.yaml" - beispiel: "SVC-EMAIL-001" - - - name: "service_name" - typ: "string" - pflicht: false - erfassung: "automatisch" - beschreibung: "Name des Services (abgeleitet aus service_id)" - - - name: "service_komponente" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Betroffene Komponente innerhalb des Services" - beispiel: "Outlook Client" - - - name: "kategorie" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Thematische Kategorie (für Reporting)" - beispiel: "E-Mail / Netzwerk / Hardware / Software" - - - name: "unterkategorie" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Feingranulare Kategorie" - beispiel: "Outlook / Exchange / Spam" - - # --------------------------------------------------------------------------- - # STATUS & WORKFLOW - # --------------------------------------------------------------------------- - status: - - beschreibung: "Status-Informationen und Workflow-Steuerung" - - attribute: - - - name: "status" - typ: "enum" - pflicht: true - erfassung: "automatisch" - beschreibung: "Aktueller Bearbeitungsstatus" - werte: - - id: "NEU" - name: "Neu" - beschreibung: "Ticket erfasst, noch nicht angenommen" - - id: "ANGENOMMEN" - name: "Angenommen" - beschreibung: "Ticket von Bearbeiter übernommen" - - id: "WARTEN_GENEHMIGUNG" - name: "Warten auf Genehmigung" - beschreibung: "Genehmigungsanfrage ausgelöst (nur bei Requests)" - request_spezifisch: true - - id: "IN_BEARBEITUNG" - name: "In Bearbeitung" - beschreibung: "Aktive Bearbeitung läuft" - - id: "WARTEN_NUTZER" - name: "Warten auf Nutzer" - beschreibung: "Rückfrage an Melder/Betroffenen" - - id: "WARTEN_EXTERN" - name: "Warten auf Externe" - beschreibung: "Warten auf Drittanbieter/Lieferant" - - id: "WARTEN_CHANGE" - name: "Warten auf Change" - beschreibung: "Lösung erfordert genehmigten Change" - - id: "GELOEST" - name: "Gelöst" - beschreibung: "Lösung implementiert, Bestätigung ausstehend" - - id: "GESCHLOSSEN" - name: "Geschlossen" - beschreibung: "Ticket abgeschlossen" - - id: "STORNIERT" - name: "Storniert" - beschreibung: "Ticket ohne Bearbeitung beendet" - default: "NEU" - hinweis: | - Der Status WARTEN_GENEHMIGUNG ist Request-spezifisch und wird - bei Incidents nicht verwendet. - - - name: "substatus" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Optionaler Detail-Status" - beispiel: "Wartet auf Rückruf / Termin vereinbart" - - - name: "langlaeufer_flag" - typ: "boolean" - pflicht: false - erfassung: "automatisch" - beschreibung: "Kennzeichnung für Tickets >20 AT Laufzeit" - default: false - governance: "SSM-G-04" - - status_transitionen: - - beschreibung: | - Erlaubte Status-Übergänge. Das ITSM-Tool sollte diese - Transitionen technisch durchsetzen. - - referenz: "sub-practice_incident-management.yaml → status_lifecycle" - - transitionen: - NEU: ["ANGENOMMEN", "STORNIERT"] - ANGENOMMEN: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"] - WARTEN_GENEHMIGUNG: ["IN_BEARBEITUNG", "STORNIERT"] - IN_BEARBEITUNG: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"] - WARTEN_NUTZER: ["IN_BEARBEITUNG", "STORNIERT"] - WARTEN_EXTERN: ["IN_BEARBEITUNG"] - WARTEN_CHANGE: ["IN_BEARBEITUNG", "GELOEST"] - GELOEST: ["GESCHLOSSEN", "IN_BEARBEITUNG"] - GESCHLOSSEN: ["IN_BEARBEITUNG"] - STORNIERT: [] - - hinweis_request_spezifisch: | - Die Transition ANGENOMMEN → WARTEN_GENEHMIGUNG und alle Transitionen - von WARTEN_GENEHMIGUNG sind nur bei Requests relevant. - - einbahnstrassen: - - von: "ANGENOMMEN" - nicht_nach: "NEU" - grund: "Ownership-Prinzip: Nach Annahme keine Rückgabe an Queue" - - # --------------------------------------------------------------------------- - # ZEITEN - # --------------------------------------------------------------------------- - zeiten: - - beschreibung: "Zeitstempel für SLA-Messung und Reporting" - - attribute: - - - name: "erstellt_am" - typ: "datetime" - pflicht: true - erfassung: "automatisch" - beschreibung: "Zeitpunkt der Ticket-Erstellung" - - - name: "erste_reaktion_am" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Zeitpunkt der ersten qualifizierten Reaktion" - sla_relevant: true - - - name: "angenommen_am" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Zeitpunkt der Ticket-Übernahme" - - - name: "geloest_am" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Zeitpunkt der Lösungsbereitstellung" - sla_relevant: true - - - name: "geschlossen_am" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Zeitpunkt des Ticket-Abschlusses" - - - name: "sla_reaktion_ziel" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Berechnetes SLA-Ziel für Reaktionszeit" - - - name: "sla_loesung_ziel" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Berechnetes SLA-Ziel für Lösungszeit" - - - name: "wartezeit_gesamt" - typ: "duration" - pflicht: false - erfassung: "automatisch" - beschreibung: | - Summe aller Wartezeiten (WARTEN_NUTZER, WARTEN_EXTERN). - Wird von SLA-Zeit abgezogen ("Clock Stop"). - - - name: "bearbeitungszeit_netto" - typ: "duration" - pflicht: false - erfassung: "automatisch" - beschreibung: "Tatsächliche Bearbeitungszeit ohne Wartezeiten" - - # --------------------------------------------------------------------------- - # ZUWEISUNG - # --------------------------------------------------------------------------- - zuweisung: - - beschreibung: "Bearbeiter und Team-Zuordnung" - - attribute: - - - name: "zugewiesen_an" - typ: "objekt" - pflicht: false - erfassung: "manuell" - beschreibung: "Aktuell zuständiger Bearbeiter" - schema: - - name: "person_id" - typ: "string" - - name: "name" - typ: "string" - - name: "team" - typ: "string" - - - name: "support_team" - typ: "enum" - pflicht: false - erfassung: "manuell" - beschreibung: "Zuständiges Support-Team" - werte: - - id: "L1" - name: "First Level Support" - - id: "L2" - name: "Second Level Support" - - id: "L2-SPEC" - name: "Spezialistengruppe" - - id: "L3" - name: "Third Level / Extern" - - - name: "eskaliert_an" - typ: "objekt" - pflicht: false - erfassung: "manuell" - beschreibung: "Person/Gruppe bei Eskalation" - schema: - - name: "person_id" - typ: "string" - - name: "name" - typ: "string" - - name: "eskalationsgrund" - typ: "string" - - name: "eskaliert_am" - typ: "datetime" - -# ============================================================================= -# INCIDENT-SPEZIFISCHE ATTRIBUTE -# ============================================================================= - -incident_attribute: - - beschreibung: | - Zusätzliche Attribute, die nur für Incidents relevant sind. - Diese ergänzen die Basis-Attribute. - - gilt_fuer: "ticket_typ = INCIDENT" - - attribute: - - - name: "symptom" - typ: "text" - pflicht: false - erfassung: "manuell" - beschreibung: "Beobachtetes Symptom (was sieht der Nutzer?)" - beispiel: "Fehlermeldung 'Verbindung zum Server unterbrochen'" - - - name: "fehlermeldung" - typ: "text" - pflicht: false - erfassung: "manuell" - beschreibung: "Exakter Wortlaut der Fehlermeldung" - - - name: "reproduzierbar" - typ: "enum" - pflicht: false - erfassung: "manuell" - beschreibung: "Ist das Problem reproduzierbar?" - werte: - - id: "IMMER" - name: "Immer reproduzierbar" - - id: "MANCHMAL" - name: "Sporadisch" - - id: "EINMALIG" - name: "Bisher einmalig" - - id: "UNBEKANNT" - name: "Nicht getestet" - - - name: "workaround_vorhanden" - typ: "boolean" - pflicht: false - erfassung: "manuell" - beschreibung: "Existiert ein temporärer Workaround?" - default: false - - - name: "workaround_beschreibung" - typ: "text" - pflicht: false - erfassung: "manuell" - beschreibung: "Beschreibung des Workarounds (wenn vorhanden)" - - - name: "ursache" - typ: "text" - pflicht: false - erfassung: "manuell" - beschreibung: "Ermittelte Ursache (nach Diagnose)" - - - name: "loesung" - typ: "text" - pflicht: true - erfassung: "manuell" - beschreibung: "Beschreibung der durchgeführten Lösung" - bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN" - - - name: "first_call_resolution" - typ: "boolean" - pflicht: false - erfassung: "automatisch" - beschreibung: "Wurde das Ticket im Erstkontakt gelöst?" - kpi_relevant: true - - - name: "problem_referenz" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Verknüpfung zu Problem-Ticket (wenn vorhanden)" - beispiel: "PRB-20251207-00012" - - - name: "known_error_referenz" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Referenz auf Known Error Database (KEDB)" - - # ------------------------------------------------------------------------- - # FEEDBACK-FELDER - # ------------------------------------------------------------------------- - - - name: "nutzer_feedback" - beschreibung: | - Optionales Feedback des Nutzers zur Lösungsqualität und - Zufriedenheit mit der Bearbeitung. Wird bei Ticket-Abschluss - oder nach Auto-Close erhoben. - - typ: "objekt" - pflicht: false - erfassung: "manuell" - - unterfelder: - - - name: "zufriedenheit" - typ: "enum" - pflicht: false - werte: - - id: "SEHR_ZUFRIEDEN" - name: "Sehr zufrieden" - - id: "ZUFRIEDEN" - name: "Zufrieden" - - id: "NEUTRAL" - name: "Neutral" - - id: "UNZUFRIEDEN" - name: "Unzufrieden" - - id: "SEHR_UNZUFRIEDEN" - name: "Sehr unzufrieden" - - - name: "kommentar" - typ: "text" - pflicht: false - max_laenge: 1000 - beschreibung: "Freitext-Feedback des Nutzers" - - - name: "feedback_datum" - typ: "datetime" - pflicht: false - erfassung: "automatisch" - beschreibung: "Zeitpunkt der Feedback-Abgabe" - - erhebung: - zeitpunkt: "Nach Ticket-Abschluss oder Auto-Close" - methode: "E-Mail mit Feedback-Link oder Portal-Popup" - erinnerung: "Optional nach 3 Tagen" - - auswertung: - kpi: "Nutzerzufriedenheit (CSAT)" - aggregation: "Monatlich pro Service-Bereich" - reporting: "ssm_governance.yaml → reporting" - - mvp_status: "OPTIONAL" - hinweis: | - Im MVP ist die Feedback-Erhebung optional und abhängig von - der Tool-Unterstützung. Die Struktur ist definiert, die - Implementierung kann nachgelagert erfolgen. - -# ============================================================================= -# REQUEST-SPEZIFISCHE ATTRIBUTE -# ============================================================================= - -request_attribute: - - beschreibung: | - Zusätzliche Attribute, die nur für Service Requests relevant sind. - Diese ergänzen die Basis-Attribute. - - gilt_fuer: "ticket_typ = REQUEST" - - attribute: - - - name: "request_typ" - typ: "enum" - pflicht: true - erfassung: "manuell" - beschreibung: "Art der Anfrage" - werte: - - id: "BERECHTIGUNG" - name: "Berechtigungsanfrage" - - id: "SOFTWARE" - name: "Software-Installation" - - id: "HARDWARE" - name: "Hardware-Anfrage" - - id: "ACCOUNT" - name: "Account-Management" - - id: "INFORMATION" - name: "Informationsanfrage" - - id: "AENDERUNG" - name: "Änderungsanfrage" - - id: "SONSTIGE" - name: "Sonstige Anfrage" - - - name: "request_katalog_id" - typ: "string" - pflicht: false - erfassung: "manuell" - beschreibung: "Referenz auf Standard-Request im Request-Katalog" - beispiel: "REQ-CAT-SW-001" - - - name: "genehmigung_erforderlich" - typ: "boolean" - pflicht: false - erfassung: "automatisch" - beschreibung: "Ist eine Genehmigung erforderlich?" - ableitung: "Basierend auf request_typ und Katalog-Definition" - - - name: "genehmiger" - typ: "objekt" - pflicht: false - erfassung: "manuell" - beschreibung: "Person, die die Genehmigung erteilt" - schema: - - name: "person_id" - typ: "string" - - name: "name" - typ: "string" - - name: "genehmigt_am" - typ: "datetime" - - name: "kommentar" - typ: "string" - bedingung: "Pflicht wenn genehmigung_erforderlich = true" - - - name: "genehmigung_status" - typ: "enum" - pflicht: false - erfassung: "manuell" - beschreibung: "Status des Genehmigungsprozesses" - werte: - - id: "OFFEN" - name: "Genehmigung ausstehend" - - id: "GENEHMIGT" - name: "Genehmigt" - - id: "ABGELEHNT" - name: "Abgelehnt" - - id: "NICHT_ERFORDERLICH" - name: "Keine Genehmigung erforderlich" - - - name: "wunschtermin" - typ: "date" - pflicht: false - erfassung: "manuell" - beschreibung: "Vom Nutzer gewünschter Erledigungstermin" - - - name: "kosten_relevant" - typ: "boolean" - pflicht: false - erfassung: "automatisch" - beschreibung: "Entstehen Kosten für das Amt?" - ableitung: "Basierend auf Service-Kategorie und Request-Typ" - - - name: "erfuellung" - typ: "text" - pflicht: true - erfassung: "manuell" - beschreibung: "Beschreibung der durchgeführten Erfüllung" - bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN" - -# ============================================================================= -# STATUS-MODELL -# ============================================================================= - -status_modell: - - beschreibung: | - Definition der erlaubten Status-Übergänge. Nur die hier definierten - Transitionen sind im System erlaubt. - - transitionen: - - - von: "NEU" - nach: ["ANGENOMMEN", "STORNIERT"] - bedingung: null - - - von: "ANGENOMMEN" - nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"] - bedingung: "zugewiesen_an muss gesetzt sein" - hinweis: "WARTEN_GENEHMIGUNG nur bei Requests" - - - von: "WARTEN_GENEHMIGUNG" - nach: ["IN_BEARBEITUNG", "STORNIERT"] - bedingung: "Genehmigung erteilt → IN_BEARBEITUNG, abgelehnt → STORNIERT" - ticket_typ: "Nur für REQUEST" - - - von: "IN_BEARBEITUNG" - nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST", "STORNIERT"] - bedingung: null - - - von: "WARTEN_NUTZER" - nach: ["IN_BEARBEITUNG", "GELOEST", "STORNIERT"] - bedingung: null - timeout: "5 Arbeitstage" - timeout_aktion: "Automatische Erinnerung, nach weiteren 5 AT → STORNIERT" - - - von: "WARTEN_EXTERN" - nach: ["IN_BEARBEITUNG", "GELOEST"] - bedingung: null - - - von: "WARTEN_CHANGE" - nach: ["IN_BEARBEITUNG", "GELOEST"] - bedingung: "Change-Ticket muss verknüpft sein" - - - von: "GELOEST" - nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"] - bedingung: null - timeout: "3 Arbeitstage" - timeout_aktion: "Automatisch → GESCHLOSSEN" - - - von: "GESCHLOSSEN" - nach: ["IN_BEARBEITUNG"] - bedingung: "Wiedereröffnung durch Queue-Koordinator, Begründung erforderlich" - - - von: "STORNIERT" - nach: [] - bedingung: "Endstatus, keine Wiedereröffnung" - -# ============================================================================= -# DEFINITION OF READY (DoR) -# ============================================================================= - -definition_of_ready: - - beschreibung: | - Mindestanforderungen, die ein Ticket erfüllen muss, bevor es zur - Bearbeitung angenommen werden kann. Tickets, die die DoR nicht - erfüllen, können zurückgewiesen werden. - - governance: "SSM-G-04 (DoR-Verbindlichkeit)" - - pflichtfelder_alle: - - "titel" - - "beschreibung" - - "melder" - - "betroffener" - - "ticket_typ" - - "impact" - - "urgency" - - "charakteristik" - - pflichtfelder_incident: - - "symptom ODER fehlermeldung" - - pflichtfelder_request: - - "request_typ" - - qualitaetskriterien: - - - id: "DoR-Q-01" - name: "Verständlicher Titel" - beschreibung: "Titel beschreibt Problem/Anfrage erkennbar (ohne Beschreibung lesen zu müssen)" - pruefung: "manuell" - - - id: "DoR-Q-02" - name: "Ausreichende Beschreibung" - beschreibung: "Beschreibung enthält genug Kontext für Bearbeitung ohne Rückfrage" - pruefung: "manuell" - mindestlaenge: "50 Zeichen" - - - id: "DoR-Q-03" - name: "Erreichbarkeit" - beschreibung: "Melder ist erreichbar (Telefon oder E-Mail dokumentiert)" - pruefung: "automatisch" - - - id: "DoR-Q-04" - name: "Service-Zuordnung (wenn möglich)" - beschreibung: "Betroffener Service ist identifiziert" - pruefung: "manuell" - verbindlichkeit: "empfohlen" - - rueckweisung: - beschreibung: | - Tickets, die die DoR nicht erfüllen, werden an den Melder - zurückgewiesen mit der Aufforderung zur Nachbesserung. - verantwortlich: "First Level Agent" - dokumentation: "Rückweisungsgrund im Ticket vermerken" - status_bei_rueckweisung: "WARTEN_NUTZER" - -# ============================================================================= -# VALIDIERUNGSREGELN -# ============================================================================= - -validierung: - - regeln: - - - id: "VAL-T-001" - name: "Priorität-Pool-Konsistenz" - beschreibung: "Pool muss zur Priorität × Charakteristik passen" - regel: "Pool wird automatisch aus Ableitungslogik gesetzt" - referenz: "ssm_klassifikation-priorisierung.yaml" - - - id: "VAL-T-002" - name: "Lösungspflicht bei Abschluss" - beschreibung: "Vor Schließen muss Lösung/Erfüllung dokumentiert sein" - regel: | - Status = GESCHLOSSEN erfordert: - - Bei INCIDENT: loesung ist gesetzt - - Bei REQUEST: erfuellung ist gesetzt - - - id: "VAL-T-003" - name: "Genehmigung bei Genehmigungspflicht" - beschreibung: "Genehmigungspflichtige Requests brauchen Freigabe" - regel: | - Wenn genehmigung_erforderlich = true, dann - genehmigung_status muss GENEHMIGT sein vor Status = IN_BEARBEITUNG - - - id: "VAL-T-004" - name: "SLA-Ziele bei Priorität" - beschreibung: "SLA-Zielzeiten werden aus Priorität abgeleitet" - regel: "Automatische Berechnung bei Ticket-Erstellung" - referenz: "ssm_klassifikation-priorisierung.yaml → prioritaetsstufen" - - - id: "VAL-T-005" - name: "Langläufer-Kennzeichnung" - beschreibung: "Tickets >20 AT werden automatisch gekennzeichnet" - regel: | - Wenn (geschlossen_am - erstellt_am) > 20 Arbeitstage - ODER aktuelles Datum - erstellt_am > 20 Arbeitstage, - dann langlaeufer_flag = true - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - modul: "ssm_klassifikation-priorisierung.yaml" - art: "referenziert" - beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele" - - - modul: "sub-practice_incident-management.yaml" - art: "wird verwendet von" - beschreibung: "Incident-Prozess arbeitet auf diesem Schema" - - - modul: "sub-practice_request-management.yaml" - art: "wird verwendet von" - beschreibung: "Request-Prozess arbeitet auf diesem Schema" - - - modul: "spm_schema_service-definition.yaml" - art: "referenziert" - beschreibung: "Service-Zuordnung über service_id" - - - modul: "ssm_rollen.yaml" - art: "referenziert" - beschreibung: "Bearbeiter-Zuordnung" - - extern: - - partner: "ITSM-Tool" - kontext: "Schema definiert Feldstruktur für Tool-Konfiguration" - status: "Tool-Auswahl ausstehend" - - - partner: "Active Directory" - kontext: "Personen-Lookup für Melder/Betroffener/Bearbeiter" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-SCHEMA-T-001" - beschreibung: "Request-Katalog-Struktur definieren (referenziert von request_katalog_id)" - prioritaet: "hoch" - - - id: "OPEN-SCHEMA-T-002" - beschreibung: "Kategorie/Unterkategorie-Taxonomie abstimmen" - prioritaet: "mittel" - - - id: "OPEN-SCHEMA-T-003" - beschreibung: "CMDB-Integration: CI-Verknüpfung als Attribut ergänzen?" - prioritaet: "niedrig" - - - id: "OPEN-SCHEMA-T-004" - beschreibung: "Attachment-Handling: Wie werden Screenshots, Logs etc. abgebildet?" - prioritaet: "mittel" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.2" - datum: "2025-12-07" - aenderung: | - - Feld 'nutzer_feedback' ergänzt (Zufriedenheit, Kommentar) - - MVP-Status: Optional, Tool-abhängig - autor: "DIGITOM-Projekt" - quelle: "Review-Finding K-03" - - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung" +# ============================================================================= +# SSM SCHEMA: TICKET +# ============================================================================= +# Modul: Service-Support-Management (SSM) +# Typ: Schema (Informationsmodell) +# Version: 0.1 +# Datum: 2025-12-07 +# Status: draft +# ============================================================================= + +meta: + schema_id: "SSM-S-01" + name: "Ticket-Schema" + typ: "Schema" + + zweck: | + Definiert die Datenstruktur für Support-Tickets (Incidents und Requests). + Das Schema dient als Grundlage für: + - ITSM-Tool-Konfiguration (Pflichtfelder, Feldtypen) + - Definition of Ready (DoR) – Qualitätskriterien bei Ticket-Erfassung + - Reporting und KPI-Auswertung + - Prozess-Schnittstellen (Eskalation, Übergabe) + + gilt_fuer: + - "sub-practice_incident-management.yaml" + - "sub-practice_request-management.yaml" + - "sub-practice_service-desk.yaml" + + klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml" + rollen_referenz: "ssm_rollen.yaml" + + design_prinzip: | + Das Schema unterscheidet drei Attribut-Kategorien: + 1. Basis-Attribute: Für alle Ticket-Typen identisch + 2. Typ-spezifische Attribute: Nur für Incident oder Request + 3. Prozess-Attribute: Werden im Lifecycle befüllt (nicht bei Erfassung) + + Pflichtfelder sind so definiert, dass sie die DoR (Definition of Ready) + erfüllen, ohne den Erfassungsprozess zu überlasten. + +# ============================================================================= +# BASIS-ATTRIBUTE (ALLE TICKET-TYPEN) +# ============================================================================= + +basis_attribute: + + beschreibung: | + Diese Attribute gelten für alle Ticket-Typen (Incident, Request, Projekt). + Sie werden bei Ticket-Erfassung oder im frühen Lifecycle befüllt. + + # --------------------------------------------------------------------------- + # IDENTIFIKATION + # --------------------------------------------------------------------------- + identifikation: + + beschreibung: "Eindeutige Identifikation und Grunddaten" + + attribute: + + - name: "ticket_id" + typ: "string" + pflicht: true + erfassung: "automatisch" + beschreibung: "Eindeutiger Identifier, vom System vergeben" + format: "INC-YYYYMMDD-XXXXX oder REQ-YYYYMMDD-XXXXX" + beispiel: "INC-20251207-00423" + + - name: "ticket_typ" + typ: "enum" + pflicht: true + erfassung: "manuell" + beschreibung: "Grundlegende Ticket-Klassifikation" + werte: + - id: "INCIDENT" + name: "Störung" + - id: "REQUEST" + name: "Service-Anfrage" + - id: "PROJEKT" + name: "Projekt-Ticket" + referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen" + + - name: "titel" + typ: "string" + pflicht: true + erfassung: "manuell" + beschreibung: "Kurze, aussagekräftige Zusammenfassung" + max_laenge: 120 + beispiel: "Outlook stürzt beim Öffnen von Anhängen ab" + qualitaetskriterium: | + Der Titel muss das Problem/die Anfrage erkennbar machen, + ohne die Beschreibung lesen zu müssen. + + - name: "beschreibung" + typ: "text" + pflicht: true + erfassung: "manuell" + beschreibung: "Ausführliche Beschreibung des Problems oder der Anfrage" + min_laenge: 50 + qualitaetskriterium: | + Die Beschreibung muss ausreichend Kontext liefern, um + ohne Rückfrage mit der Bearbeitung beginnen zu können. + + # --------------------------------------------------------------------------- + # MELDER & BETROFFENER + # --------------------------------------------------------------------------- + personen: + + beschreibung: "Beteiligte Personen" + + attribute: + + - name: "melder" + typ: "objekt" + pflicht: true + erfassung: "automatisch/manuell" + beschreibung: "Person, die das Ticket erstellt hat" + schema: + - name: "person_id" + typ: "string" + beschreibung: "Referenz auf Verzeichnisdienst (AD)" + - name: "name" + typ: "string" + - name: "email" + typ: "string" + - name: "telefon" + typ: "string" + pflicht: false + - name: "amt" + typ: "string" + beschreibung: "Organisationseinheit des Melders" + - name: "standort" + typ: "string" + pflicht: false + + - name: "betroffener" + typ: "objekt" + pflicht: true + erfassung: "manuell" + beschreibung: | + Person, die von der Störung betroffen ist oder die Anfrage stellt. + Kann identisch mit Melder sein (Standardfall). + schema: + - name: "person_id" + typ: "string" + - name: "name" + typ: "string" + - name: "amt" + typ: "string" + default: "Melder" + + - name: "vip_flag" + typ: "boolean" + pflicht: false + erfassung: "automatisch" + beschreibung: | + Kennzeichnung für besondere Behandlung (z.B. Amtsleitung, OB-Bereich). + Beeinflusst nicht die Priorität, aber die Kommunikation. + default: false + + # --------------------------------------------------------------------------- + # KLASSIFIKATION + # --------------------------------------------------------------------------- + klassifikation: + + beschreibung: "Klassifikations-Attribute gemäß Priorisierungs-Framework" + referenz: "ssm_klassifikation-priorisierung.yaml" + + attribute: + + - name: "impact" + typ: "enum" + pflicht: true + erfassung: "manuell" + beschreibung: "Auswirkung auf den Geschäftsbetrieb" + werte: + - id: "HOCH" + code: "I-H" + kriterien: ">10 Nutzer, geschäftskritisch, Security" + - id: "NORMAL" + code: "I-N" + kriterien: "Einzelnutzer/kleine Gruppe, eingeschränkt" + - id: "NIEDRIG" + code: "I-L" + kriterien: "Komfort, Workaround verfügbar" + + - name: "urgency" + typ: "enum" + pflicht: true + erfassung: "manuell" + beschreibung: "Zeitliche Dringlichkeit" + werte: + - id: "HOCH" + code: "U-H" + kriterien: "Sofort, kein Workaround, Deadline" + - id: "NORMAL" + code: "U-N" + kriterien: "Zeitnah, temporärer Workaround" + - id: "NIEDRIG" + code: "U-L" + kriterien: "Kann warten" + + - name: "prioritaet" + typ: "enum" + pflicht: true + erfassung: "automatisch" + beschreibung: "Abgeleitet aus Impact × Urgency" + werte: + - id: "P1" + name: "Kritisch" + - id: "P2" + name: "Hoch" + - id: "P3" + name: "Normal" + - id: "P4" + name: "Niedrig" + ableitung: "ssm_klassifikation-priorisierung.yaml → impact_urgency_matrix" + + - name: "charakteristik" + typ: "enum" + pflicht: true + erfassung: "manuell" + beschreibung: "Bearbeitungscharakter des Tickets" + werte: + - id: "STANDARD" + name: "Standard-Ticket" + beschreibung: "Bekanntes Muster, klare Lösung" + - id: "ANALYSE" + name: "Analyse-Ticket" + beschreibung: "Unklare Ursache, Diagnose erforderlich" + - id: "PROJEKT" + name: "Projekt-Ticket" + beschreibung: "Planbar, umfangreich, Koordination nötig" + + - name: "pool" + typ: "enum" + pflicht: true + erfassung: "automatisch" + beschreibung: "Zugeordneter Bearbeitungs-Pool" + werte: + - id: "POOL-SOFORT" + name: "Sofort-Pool" + - id: "POOL-STANDARD" + name: "Standard Service-Pool" + - id: "POOL-ANALYSE" + name: "Analyse-Pool" + - id: "POOL-PROJEKT" + name: "Projekt-Pool" + ableitung: "ssm_klassifikation-priorisierung.yaml → ableitungslogik" + + # --------------------------------------------------------------------------- + # SERVICE-ZUORDNUNG + # --------------------------------------------------------------------------- + service_zuordnung: + + beschreibung: "Verknüpfung mit Service-Portfolio" + + attribute: + + - name: "service_id" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Referenz auf betroffenen Service (aus Service-Katalog)" + referenz: "spm_schema_service-definition.yaml" + beispiel: "SVC-EMAIL-001" + + - name: "service_name" + typ: "string" + pflicht: false + erfassung: "automatisch" + beschreibung: "Name des Services (abgeleitet aus service_id)" + + - name: "service_komponente" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Betroffene Komponente innerhalb des Services" + beispiel: "Outlook Client" + + - name: "kategorie" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Thematische Kategorie (für Reporting)" + beispiel: "E-Mail / Netzwerk / Hardware / Software" + + - name: "unterkategorie" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Feingranulare Kategorie" + beispiel: "Outlook / Exchange / Spam" + + # --------------------------------------------------------------------------- + # STATUS & WORKFLOW + # --------------------------------------------------------------------------- + status: + + beschreibung: "Status-Informationen und Workflow-Steuerung" + + attribute: + + - name: "status" + typ: "enum" + pflicht: true + erfassung: "automatisch" + beschreibung: "Aktueller Bearbeitungsstatus" + werte: + - id: "NEU" + name: "Neu" + beschreibung: "Ticket erfasst, noch nicht angenommen" + - id: "ANGENOMMEN" + name: "Angenommen" + beschreibung: "Ticket von Bearbeiter übernommen" + - id: "WARTEN_GENEHMIGUNG" + name: "Warten auf Genehmigung" + beschreibung: "Genehmigungsanfrage ausgelöst (nur bei Requests)" + request_spezifisch: true + - id: "IN_BEARBEITUNG" + name: "In Bearbeitung" + beschreibung: "Aktive Bearbeitung läuft" + - id: "WARTEN_NUTZER" + name: "Warten auf Nutzer" + beschreibung: "Rückfrage an Melder/Betroffenen" + - id: "WARTEN_EXTERN" + name: "Warten auf Externe" + beschreibung: "Warten auf Drittanbieter/Lieferant" + - id: "WARTEN_CHANGE" + name: "Warten auf Change" + beschreibung: "Lösung erfordert genehmigten Change" + - id: "GELOEST" + name: "Gelöst" + beschreibung: "Lösung implementiert, Bestätigung ausstehend" + - id: "GESCHLOSSEN" + name: "Geschlossen" + beschreibung: "Ticket abgeschlossen" + - id: "STORNIERT" + name: "Storniert" + beschreibung: "Ticket ohne Bearbeitung beendet" + default: "NEU" + hinweis: | + Der Status WARTEN_GENEHMIGUNG ist Request-spezifisch und wird + bei Incidents nicht verwendet. + + - name: "substatus" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Optionaler Detail-Status" + beispiel: "Wartet auf Rückruf / Termin vereinbart" + + - name: "langlaeufer_flag" + typ: "boolean" + pflicht: false + erfassung: "automatisch" + beschreibung: "Kennzeichnung für Tickets >20 AT Laufzeit" + default: false + governance: "SSM-G-04" + + status_transitionen: + + beschreibung: | + Erlaubte Status-Übergänge. Das ITSM-Tool sollte diese + Transitionen technisch durchsetzen. + + referenz: "sub-practice_incident-management.yaml → status_lifecycle" + + transitionen: + NEU: ["ANGENOMMEN", "STORNIERT"] + ANGENOMMEN: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"] + WARTEN_GENEHMIGUNG: ["IN_BEARBEITUNG", "STORNIERT"] + IN_BEARBEITUNG: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"] + WARTEN_NUTZER: ["IN_BEARBEITUNG", "STORNIERT"] + WARTEN_EXTERN: ["IN_BEARBEITUNG"] + WARTEN_CHANGE: ["IN_BEARBEITUNG", "GELOEST"] + GELOEST: ["GESCHLOSSEN", "IN_BEARBEITUNG"] + GESCHLOSSEN: ["IN_BEARBEITUNG"] + STORNIERT: [] + + hinweis_request_spezifisch: | + Die Transition ANGENOMMEN → WARTEN_GENEHMIGUNG und alle Transitionen + von WARTEN_GENEHMIGUNG sind nur bei Requests relevant. + + einbahnstrassen: + - von: "ANGENOMMEN" + nicht_nach: "NEU" + grund: "Ownership-Prinzip: Nach Annahme keine Rückgabe an Queue" + + # --------------------------------------------------------------------------- + # ZEITEN + # --------------------------------------------------------------------------- + zeiten: + + beschreibung: "Zeitstempel für SLA-Messung und Reporting" + + attribute: + + - name: "erstellt_am" + typ: "datetime" + pflicht: true + erfassung: "automatisch" + beschreibung: "Zeitpunkt der Ticket-Erstellung" + + - name: "erste_reaktion_am" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Zeitpunkt der ersten qualifizierten Reaktion" + sla_relevant: true + + - name: "angenommen_am" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Zeitpunkt der Ticket-Übernahme" + + - name: "geloest_am" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Zeitpunkt der Lösungsbereitstellung" + sla_relevant: true + + - name: "geschlossen_am" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Zeitpunkt des Ticket-Abschlusses" + + - name: "sla_reaktion_ziel" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Berechnetes SLA-Ziel für Reaktionszeit" + + - name: "sla_loesung_ziel" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Berechnetes SLA-Ziel für Lösungszeit" + + - name: "wartezeit_gesamt" + typ: "duration" + pflicht: false + erfassung: "automatisch" + beschreibung: | + Summe aller Wartezeiten (WARTEN_NUTZER, WARTEN_EXTERN). + Wird von SLA-Zeit abgezogen ("Clock Stop"). + + - name: "bearbeitungszeit_netto" + typ: "duration" + pflicht: false + erfassung: "automatisch" + beschreibung: "Tatsächliche Bearbeitungszeit ohne Wartezeiten" + + # --------------------------------------------------------------------------- + # ZUWEISUNG + # --------------------------------------------------------------------------- + zuweisung: + + beschreibung: "Bearbeiter und Team-Zuordnung" + + attribute: + + - name: "zugewiesen_an" + typ: "objekt" + pflicht: false + erfassung: "manuell" + beschreibung: "Aktuell zuständiger Bearbeiter" + schema: + - name: "person_id" + typ: "string" + - name: "name" + typ: "string" + - name: "team" + typ: "string" + + - name: "support_team" + typ: "enum" + pflicht: false + erfassung: "manuell" + beschreibung: "Zuständiges Support-Team" + werte: + - id: "L1" + name: "First Level Support" + - id: "L2" + name: "Second Level Support" + - id: "L2-SPEC" + name: "Spezialistengruppe" + - id: "L3" + name: "Third Level / Extern" + + - name: "eskaliert_an" + typ: "objekt" + pflicht: false + erfassung: "manuell" + beschreibung: "Person/Gruppe bei Eskalation" + schema: + - name: "person_id" + typ: "string" + - name: "name" + typ: "string" + - name: "eskalationsgrund" + typ: "string" + - name: "eskaliert_am" + typ: "datetime" + +# ============================================================================= +# INCIDENT-SPEZIFISCHE ATTRIBUTE +# ============================================================================= + +incident_attribute: + + beschreibung: | + Zusätzliche Attribute, die nur für Incidents relevant sind. + Diese ergänzen die Basis-Attribute. + + gilt_fuer: "ticket_typ = INCIDENT" + + attribute: + + - name: "symptom" + typ: "text" + pflicht: false + erfassung: "manuell" + beschreibung: "Beobachtetes Symptom (was sieht der Nutzer?)" + beispiel: "Fehlermeldung 'Verbindung zum Server unterbrochen'" + + - name: "fehlermeldung" + typ: "text" + pflicht: false + erfassung: "manuell" + beschreibung: "Exakter Wortlaut der Fehlermeldung" + + - name: "reproduzierbar" + typ: "enum" + pflicht: false + erfassung: "manuell" + beschreibung: "Ist das Problem reproduzierbar?" + werte: + - id: "IMMER" + name: "Immer reproduzierbar" + - id: "MANCHMAL" + name: "Sporadisch" + - id: "EINMALIG" + name: "Bisher einmalig" + - id: "UNBEKANNT" + name: "Nicht getestet" + + - name: "workaround_vorhanden" + typ: "boolean" + pflicht: false + erfassung: "manuell" + beschreibung: "Existiert ein temporärer Workaround?" + default: false + + - name: "workaround_beschreibung" + typ: "text" + pflicht: false + erfassung: "manuell" + beschreibung: "Beschreibung des Workarounds (wenn vorhanden)" + + - name: "ursache" + typ: "text" + pflicht: false + erfassung: "manuell" + beschreibung: "Ermittelte Ursache (nach Diagnose)" + + - name: "loesung" + typ: "text" + pflicht: true + erfassung: "manuell" + beschreibung: "Beschreibung der durchgeführten Lösung" + bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN" + + - name: "first_call_resolution" + typ: "boolean" + pflicht: false + erfassung: "automatisch" + beschreibung: "Wurde das Ticket im Erstkontakt gelöst?" + kpi_relevant: true + + - name: "problem_referenz" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Verknüpfung zu Problem-Ticket (wenn vorhanden)" + beispiel: "PRB-20251207-00012" + + - name: "known_error_referenz" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Referenz auf Known Error Database (KEDB)" + + # ------------------------------------------------------------------------- + # FEEDBACK-FELDER + # ------------------------------------------------------------------------- + + - name: "nutzer_feedback" + beschreibung: | + Optionales Feedback des Nutzers zur Lösungsqualität und + Zufriedenheit mit der Bearbeitung. Wird bei Ticket-Abschluss + oder nach Auto-Close erhoben. + + typ: "objekt" + pflicht: false + erfassung: "manuell" + + unterfelder: + + - name: "zufriedenheit" + typ: "enum" + pflicht: false + werte: + - id: "SEHR_ZUFRIEDEN" + name: "Sehr zufrieden" + - id: "ZUFRIEDEN" + name: "Zufrieden" + - id: "NEUTRAL" + name: "Neutral" + - id: "UNZUFRIEDEN" + name: "Unzufrieden" + - id: "SEHR_UNZUFRIEDEN" + name: "Sehr unzufrieden" + + - name: "kommentar" + typ: "text" + pflicht: false + max_laenge: 1000 + beschreibung: "Freitext-Feedback des Nutzers" + + - name: "feedback_datum" + typ: "datetime" + pflicht: false + erfassung: "automatisch" + beschreibung: "Zeitpunkt der Feedback-Abgabe" + + erhebung: + zeitpunkt: "Nach Ticket-Abschluss oder Auto-Close" + methode: "E-Mail mit Feedback-Link oder Portal-Popup" + erinnerung: "Optional nach 3 Tagen" + + auswertung: + kpi: "Nutzerzufriedenheit (CSAT)" + aggregation: "Monatlich pro Service-Bereich" + reporting: "ssm_governance.yaml → reporting" + + mvp_status: "OPTIONAL" + hinweis: | + Im MVP ist die Feedback-Erhebung optional und abhängig von + der Tool-Unterstützung. Die Struktur ist definiert, die + Implementierung kann nachgelagert erfolgen. + +# ============================================================================= +# REQUEST-SPEZIFISCHE ATTRIBUTE +# ============================================================================= + +request_attribute: + + beschreibung: | + Zusätzliche Attribute, die nur für Service Requests relevant sind. + Diese ergänzen die Basis-Attribute. + + gilt_fuer: "ticket_typ = REQUEST" + + attribute: + + - name: "request_typ" + typ: "enum" + pflicht: true + erfassung: "manuell" + beschreibung: "Art der Anfrage" + werte: + - id: "BERECHTIGUNG" + name: "Berechtigungsanfrage" + - id: "SOFTWARE" + name: "Software-Installation" + - id: "HARDWARE" + name: "Hardware-Anfrage" + - id: "ACCOUNT" + name: "Account-Management" + - id: "INFORMATION" + name: "Informationsanfrage" + - id: "AENDERUNG" + name: "Änderungsanfrage" + - id: "SONSTIGE" + name: "Sonstige Anfrage" + + - name: "request_katalog_id" + typ: "string" + pflicht: false + erfassung: "manuell" + beschreibung: "Referenz auf Standard-Request im Request-Katalog" + beispiel: "REQ-CAT-SW-001" + + - name: "genehmigung_erforderlich" + typ: "boolean" + pflicht: false + erfassung: "automatisch" + beschreibung: "Ist eine Genehmigung erforderlich?" + ableitung: "Basierend auf request_typ und Katalog-Definition" + + - name: "genehmiger" + typ: "objekt" + pflicht: false + erfassung: "manuell" + beschreibung: "Person, die die Genehmigung erteilt" + schema: + - name: "person_id" + typ: "string" + - name: "name" + typ: "string" + - name: "genehmigt_am" + typ: "datetime" + - name: "kommentar" + typ: "string" + bedingung: "Pflicht wenn genehmigung_erforderlich = true" + + - name: "genehmigung_status" + typ: "enum" + pflicht: false + erfassung: "manuell" + beschreibung: "Status des Genehmigungsprozesses" + werte: + - id: "OFFEN" + name: "Genehmigung ausstehend" + - id: "GENEHMIGT" + name: "Genehmigt" + - id: "ABGELEHNT" + name: "Abgelehnt" + - id: "NICHT_ERFORDERLICH" + name: "Keine Genehmigung erforderlich" + + - name: "wunschtermin" + typ: "date" + pflicht: false + erfassung: "manuell" + beschreibung: "Vom Nutzer gewünschter Erledigungstermin" + + - name: "kosten_relevant" + typ: "boolean" + pflicht: false + erfassung: "automatisch" + beschreibung: "Entstehen Kosten für das Amt?" + ableitung: "Basierend auf Service-Kategorie und Request-Typ" + + - name: "erfuellung" + typ: "text" + pflicht: true + erfassung: "manuell" + beschreibung: "Beschreibung der durchgeführten Erfüllung" + bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN" + +# ============================================================================= +# STATUS-MODELL +# ============================================================================= + +status_modell: + + beschreibung: | + Definition der erlaubten Status-Übergänge. Nur die hier definierten + Transitionen sind im System erlaubt. + + transitionen: + + - von: "NEU" + nach: ["ANGENOMMEN", "STORNIERT"] + bedingung: null + + - von: "ANGENOMMEN" + nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"] + bedingung: "zugewiesen_an muss gesetzt sein" + hinweis: "WARTEN_GENEHMIGUNG nur bei Requests" + + - von: "WARTEN_GENEHMIGUNG" + nach: ["IN_BEARBEITUNG", "STORNIERT"] + bedingung: "Genehmigung erteilt → IN_BEARBEITUNG, abgelehnt → STORNIERT" + ticket_typ: "Nur für REQUEST" + + - von: "IN_BEARBEITUNG" + nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST", "STORNIERT"] + bedingung: null + + - von: "WARTEN_NUTZER" + nach: ["IN_BEARBEITUNG", "GELOEST", "STORNIERT"] + bedingung: null + timeout: "5 Arbeitstage" + timeout_aktion: "Automatische Erinnerung, nach weiteren 5 AT → STORNIERT" + + - von: "WARTEN_EXTERN" + nach: ["IN_BEARBEITUNG", "GELOEST"] + bedingung: null + + - von: "WARTEN_CHANGE" + nach: ["IN_BEARBEITUNG", "GELOEST"] + bedingung: "Change-Ticket muss verknüpft sein" + + - von: "GELOEST" + nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"] + bedingung: null + timeout: "3 Arbeitstage" + timeout_aktion: "Automatisch → GESCHLOSSEN" + + - von: "GESCHLOSSEN" + nach: ["IN_BEARBEITUNG"] + bedingung: "Wiedereröffnung durch Queue-Koordinator, Begründung erforderlich" + + - von: "STORNIERT" + nach: [] + bedingung: "Endstatus, keine Wiedereröffnung" + +# ============================================================================= +# DEFINITION OF READY (DoR) +# ============================================================================= + +definition_of_ready: + + beschreibung: | + Mindestanforderungen, die ein Ticket erfüllen muss, bevor es zur + Bearbeitung angenommen werden kann. Tickets, die die DoR nicht + erfüllen, können zurückgewiesen werden. + + governance: "SSM-G-04 (DoR-Verbindlichkeit)" + + pflichtfelder_alle: + - "titel" + - "beschreibung" + - "melder" + - "betroffener" + - "ticket_typ" + - "impact" + - "urgency" + - "charakteristik" + + pflichtfelder_incident: + - "symptom ODER fehlermeldung" + + pflichtfelder_request: + - "request_typ" + + qualitaetskriterien: + + - id: "DoR-Q-01" + name: "Verständlicher Titel" + beschreibung: "Titel beschreibt Problem/Anfrage erkennbar (ohne Beschreibung lesen zu müssen)" + pruefung: "manuell" + + - id: "DoR-Q-02" + name: "Ausreichende Beschreibung" + beschreibung: "Beschreibung enthält genug Kontext für Bearbeitung ohne Rückfrage" + pruefung: "manuell" + mindestlaenge: "50 Zeichen" + + - id: "DoR-Q-03" + name: "Erreichbarkeit" + beschreibung: "Melder ist erreichbar (Telefon oder E-Mail dokumentiert)" + pruefung: "automatisch" + + - id: "DoR-Q-04" + name: "Service-Zuordnung (wenn möglich)" + beschreibung: "Betroffener Service ist identifiziert" + pruefung: "manuell" + verbindlichkeit: "empfohlen" + + rueckweisung: + beschreibung: | + Tickets, die die DoR nicht erfüllen, werden an den Melder + zurückgewiesen mit der Aufforderung zur Nachbesserung. + verantwortlich: "First Level Agent" + dokumentation: "Rückweisungsgrund im Ticket vermerken" + status_bei_rueckweisung: "WARTEN_NUTZER" + +# ============================================================================= +# VALIDIERUNGSREGELN +# ============================================================================= + +validierung: + + regeln: + + - id: "VAL-T-001" + name: "Priorität-Pool-Konsistenz" + beschreibung: "Pool muss zur Priorität × Charakteristik passen" + regel: "Pool wird automatisch aus Ableitungslogik gesetzt" + referenz: "ssm_klassifikation-priorisierung.yaml" + + - id: "VAL-T-002" + name: "Lösungspflicht bei Abschluss" + beschreibung: "Vor Schließen muss Lösung/Erfüllung dokumentiert sein" + regel: | + Status = GESCHLOSSEN erfordert: + - Bei INCIDENT: loesung ist gesetzt + - Bei REQUEST: erfuellung ist gesetzt + + - id: "VAL-T-003" + name: "Genehmigung bei Genehmigungspflicht" + beschreibung: "Genehmigungspflichtige Requests brauchen Freigabe" + regel: | + Wenn genehmigung_erforderlich = true, dann + genehmigung_status muss GENEHMIGT sein vor Status = IN_BEARBEITUNG + + - id: "VAL-T-004" + name: "SLA-Ziele bei Priorität" + beschreibung: "SLA-Zielzeiten werden aus Priorität abgeleitet" + regel: "Automatische Berechnung bei Ticket-Erstellung" + referenz: "ssm_klassifikation-priorisierung.yaml → prioritaetsstufen" + + - id: "VAL-T-005" + name: "Langläufer-Kennzeichnung" + beschreibung: "Tickets >20 AT werden automatisch gekennzeichnet" + regel: | + Wenn (geschlossen_am - erstellt_am) > 20 Arbeitstage + ODER aktuelles Datum - erstellt_am > 20 Arbeitstage, + dann langlaeufer_flag = true + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + - modul: "ssm_klassifikation-priorisierung.yaml" + art: "referenziert" + beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele" + + - modul: "sub-practice_incident-management.yaml" + art: "wird verwendet von" + beschreibung: "Incident-Prozess arbeitet auf diesem Schema" + + - modul: "sub-practice_request-management.yaml" + art: "wird verwendet von" + beschreibung: "Request-Prozess arbeitet auf diesem Schema" + + - modul: "spm_schema_service-definition.yaml" + art: "referenziert" + beschreibung: "Service-Zuordnung über service_id" + + - modul: "ssm_rollen.yaml" + art: "referenziert" + beschreibung: "Bearbeiter-Zuordnung" + + extern: + - partner: "ITSM-Tool" + kontext: "Schema definiert Feldstruktur für Tool-Konfiguration" + status: "Tool-Auswahl ausstehend" + + - partner: "Active Directory" + kontext: "Personen-Lookup für Melder/Betroffener/Bearbeiter" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-SCHEMA-T-001" + beschreibung: "Request-Katalog-Struktur definieren (referenziert von request_katalog_id)" + prioritaet: "hoch" + + - id: "OPEN-SCHEMA-T-002" + beschreibung: "Kategorie/Unterkategorie-Taxonomie abstimmen" + prioritaet: "mittel" + + - id: "OPEN-SCHEMA-T-003" + beschreibung: "CMDB-Integration: CI-Verknüpfung als Attribut ergänzen?" + prioritaet: "niedrig" + + - id: "OPEN-SCHEMA-T-004" + beschreibung: "Attachment-Handling: Wie werden Screenshots, Logs etc. abgebildet?" + prioritaet: "mittel" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.2" + datum: "2025-12-07" + aenderung: | + - Feld 'nutzer_feedback' ergänzt (Zufriedenheit, Kommentar) + - MVP-Status: Optional, Tool-abhängig + autor: "DIGITOM-Projekt" + quelle: "Review-Finding K-03" + + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_wissensmanagement.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_wissensmanagement.yaml index aa56c69..68536b0 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_wissensmanagement.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_wissensmanagement.yaml @@ -1,1214 +1,1214 @@ -# ============================================================================= -# SSM WISSENSMANAGEMENT -# ============================================================================= - -metadata: - id: "SSM-WM" - name: "Wissensmanagement im Service-Support" - version: "0.1" - status: "draft" - erstellt: "2025-12-07" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - beschreibung: | - Querschnitts-Dokument für das Wissensmanagement im Service-Support. - Definiert das 3-Schichten-Modell, Artikel-Struktur, Governance und - Prozesse für die Wissensdatenbank (KB). - - design_referenz: "ssm_design-zieldimensionen.yaml" - relevante_saeulen: ["LS-05"] - - gilt_fuer: - - "sub-practice_incident-management.yaml" - - "sub-practice_request-management.yaml" - - "sub-practice_problem-management.yaml" - - "sub-practice_service-desk.yaml" - - blueprint_referenz: "service-lifecycle_service-support.yaml" - relevante_aktivitaeten: ["ss_02"] - -# ============================================================================= -# ZWECK & SCOPE -# ============================================================================= - -zweck: - - definition: | - Das Wissensmanagement stellt sicher, dass Lösungswissen systematisch - erfasst, gepflegt und genutzt wird. Es durchbricht den Teufelskreis - aus mangelnder Dokumentation, fehlender Nutzung und Frustration. - - ziele: - - "Erhöhung der First-Call-Resolution durch verfügbares Lösungswissen" - - "Reduzierung von Eskalationen durch dokumentierte L1-Lösungen" - - "Vermeidung von Wissensverlusten bei Personalwechsel" - - "Systematische Überführung von Erfahrungswissen in strukturierte Dokumentation" - - "Klare Verantwortlichkeiten für Erstellung, Pflege und Qualitätssicherung" - - problemstellung: - beschreibung: | - Die Analyse hat einen Teufelskreis identifiziert: - - L2 erstellt keine Anleitungen ("wird eh nicht gelesen") - - L1 findet nichts Brauchbares - - L1 fragt direkt nach - - L2 ist frustriert - - (zurück zum Anfang) - - ursachen: - - "Keine klare Governance (jeder kann ändern ohne Kontrolle)" - - "Keine Qualitätssicherung" - - "Keine Aktualitätsprüfung" - - "Keine Verbindlichkeit der Nutzung" - - referenz: "ssm_synthese_analyse-grundlagen.yaml → KB-06" - - scope: - inkludiert: - - "Alle Dokumentation für den operativen Support" - - "Service-bezogene Troubleshooting-Anleitungen" - - "Workarounds und Known Errors" - - "Standard-Request-Anleitungen" - - "Operative Erkenntnisse aus Ticket-Bearbeitung" - - exkludiert: - - "Strategische Service-Dokumentation (→ Service Catalog)" - - "Projekt-Dokumentation (→ Projektmanagement)" - - "Nutzer-Dokumentation / Handbücher (→ separate Verantwortung)" - -# ============================================================================= -# 3-SCHICHTEN-MODELL -# ============================================================================= - -drei_schichten_modell: - - beschreibung: | - Das Wissensmanagement folgt einem 3-Schichten-Modell mit - differenzierter Verantwortung, Änderungsfrequenz und Qualitätssicherung. - Die Schichten bauen aufeinander auf und haben unterschiedliche - Governance-Anforderungen. - - referenz: "LS-05 (Design-Zieldimensionen)" - - # --------------------------------------------------------------------------- - # EBENE 1: GRUNDLAGENDOKUMENTATION - # --------------------------------------------------------------------------- - ebene_1: - - id: "KB-E1" - name: "Grundlagendokumentation" - - beschreibung: | - Stabile, grundlegende Service-Dokumentation. Beschreibt WAS der - Service tut und WIE er funktioniert. Änderungen nur bei - Service-Updates oder strukturellen Anpassungen. - - verantwortung: - accountable: "Service Owner" - responsible: "Service Owner / Fachexperte" - consulted: "Second Level Support, Betriebsteam" - informed: "First Level Support, Service Desk Manager" - - charakteristika: - - "Verbindlich und qualitätsgesichert" - - "Versioniert mit Change-Log" - - "Formal freigegeben" - - "Änderungen proaktiv kommuniziert" - - inhalte: - - inhalt: "Service-Beschreibung und Scope" - beschreibung: "Was leistet der Service? Was nicht?" - - inhalt: "Technische Architektur" - beschreibung: "Komponenten, Abhängigkeiten, Schnittstellen" - - inhalt: "Basis-Troubleshooting" - beschreibung: "Grundlegende Diagnose- und Lösungswege" - - inhalt: "Eskalationswege" - beschreibung: "Ansprechpartner, Zuständigkeiten" - - inhalt: "SLA-relevante Parameter" - beschreibung: "Kritische Schwellwerte, Verfügbarkeitszeiten" - - aenderungsfrequenz: "Bei Service-Updates oder strukturellen Änderungen" - - governance: - erstellung: "Service Owner erstellt oder beauftragt" - freigabe: "Service Owner (alleinig)" - aenderung: "Nur durch Service Owner oder delegierte Fachexperten" - review: "Bei jedem Service-Release, mindestens jährlich" - - qualitaetssicherung: - - "Versionierung verpflichtend" - - "Change-Log mit Datum und Autor" - - "Formale Freigabe dokumentiert" - - "Kommunikation an Service Desk bei Updates" - - # --------------------------------------------------------------------------- - # EBENE 2: ARBEITSDOKUMENTATION - # --------------------------------------------------------------------------- - ebene_2: - - id: "KB-E2" - name: "Arbeitsdokumentation" - - beschreibung: | - Operative Übersetzung der Grundlagendokumentation in - praxisorientierte Handlungsanweisungen. Gemeinsam erarbeitet - von Service Owner und Service Desk Team. - - verantwortung: - accountable: "Service Owner" - responsible: "Service Owner + Service Desk Team (Co-Creation)" - consulted: "Queue-Koordinator" - informed: "Support Manager" - - charakteristika: - - "Praxisorientiert und handlungsleitend" - - "Step-by-Step-Anleitungen" - - "Regelmäßig aktualisiert basierend auf Erfahrungen" - - "Gemeinsam erarbeitet und validiert" - - inhalte: - - inhalt: "Step-by-Step-Anleitungen" - beschreibung: "Konkrete Schrittfolgen für häufige Szenarien" - - inhalt: "Checklisten" - beschreibung: "Prüflisten für Diagnose und Lösung" - - inhalt: "Entscheidungsbäume" - beschreibung: "Wenn-Dann-Logiken für Triage" - - inhalt: "Workarounds" - beschreibung: "Dokumentierte temporäre Lösungen" - - inhalt: "Quick-Reference-Guides" - beschreibung: "Kurzanleitungen für Standardsituationen" - - inhalt: "Tool-spezifische Anleitungen" - beschreibung: "Bedienung von Support-Tools" - - aenderungsfrequenz: "Quartalsweise Review, Ad-hoc bei Bedarf" - - governance: - erstellung: "Co-Creation in Workshop-Sessions" - freigabe: "Service Owner (inhaltlich) + Queue-Koordinator (praktikabel)" - aenderung: "Service Desk Team mit Review durch Service Owner" - review: "Quartalsweise Workshop-Sessions" - - co_creation_prozess: - beschreibung: | - Quartalsweise gemeinsame Workshop-Sessions, in denen - Service Owner und Service Desk Team Arbeitsdokumentation - erarbeiten und validieren. - rhythmus: "Quartalsweise" - teilnehmer: - - "Service Owner (moderiert)" - - "Queue-Koordinator" - - "2-3 erfahrene Agents (rotierend)" - agenda: - - "Review bestehender Arbeitsdoku" - - "Feedback aus Praxis einarbeiten" - - "Neue Themen aus Ebene 3 übernehmen (Promotion)" - - "Veraltete Inhalte identifizieren" - output: - - "Aktualisierte Arbeitsdokumentation" - - "Promotion-Entscheidungen (E3 → E2)" - - "Archivierungs-Entscheidungen" - - qualitaetssicherung: - - "Praxis-Validierung durch Service Desk" - - "Inhaltliche Freigabe durch Service Owner" - - "Quartalsweises Review" - - # --------------------------------------------------------------------------- - # KNOWN ERROR ARTIKEL - # --------------------------------------------------------------------------- - known_error_artikel: - - beschreibung: | - Known Errors werden als spezieller KB-Artikel-Typ dokumentiert. - Sie sind Teil der Ebene 2 (Arbeitsdokumentation) und werden - von Problem Management erstellt. - - referenz: "sub-practice_problem-management.yaml → kernkonzepte.known_error" - governance: "SSM-G-20" - - artikel_typ: "KNOWN_ERROR" - kb_ebene: "Ebene 2" - - pflichtfelder: - - feld: "symptome" - beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?" - - feld: "workaround" - beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?" - - feld: "root_cause" - beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)" - - feld: "problem_referenz" - beschreibung: "Verknüpfung zum Problem Record (ID)" - - feld: "status" - beschreibung: "AKTIV oder OBSOLET" - werte: ["AKTIV", "OBSOLET"] - default: "AKTIV" - - optionale_felder: - - feld: "permanente_loesung" - beschreibung: "Geplante Lösung, wenn bekannt" - - feld: "change_referenz" - beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit" - - feld: "betroffene_services" - beschreibung: "Liste der betroffenen Services" - - lebenszyklus: - erstellung: "Bei PRB-02, wenn Workaround dokumentiert wird" - nutzung: "L1/L2 finden Artikel bei Incident-Bearbeitung via KB-Suche" - aktualisierung: "Bei neuen Erkenntnissen oder verbessertem Workaround" - obsolet: "Nach Implementierung permanenter Lösung" - - verantwortung: - ersteller: "Second Level Agent" - freigabe: "Service Owner" - pflege: "Service Owner" - - # --------------------------------------------------------------------------- - # EBENE 3: OPERATIVE ERKENNTNISSE - # --------------------------------------------------------------------------- - ebene_3: - - id: "KB-E3" - name: "Operative Erkenntnisse" - - beschreibung: | - Dynamische, schnell änderbare Wissensbasis. Bottom-up aus - täglicher Arbeit. Peer-Review statt zentraler Kontrolle. - Experimenteller Charakter erlaubt. - - verantwortung: - accountable: "Support Manager" - responsible: "Service Desk Team (jeder Agent)" - consulted: "-" - informed: "Queue-Koordinator" - - charakteristika: - - "Wiki-Prinzip: Jeder kann erstellen und editieren" - - "Niedrige Einstiegshürde" - - "Schnelle Verfügbarkeit" - - "Experimenteller Charakter erlaubt" - - "Peer-Review statt zentrale Kontrolle" - - inhalte: - - inhalt: "Edge-Case-Lösungen" - beschreibung: "Lösungen für spezielle Einzelfälle" - - inhalt: "Tipps und Tricks" - beschreibung: "Praktische Hinweise aus Erfahrung" - - inhalt: "Temporäre Workarounds" - beschreibung: "Kurzfristige Lösungen (mit Verfallsdatum)" - - inhalt: "Beobachtungen und Muster" - beschreibung: "Erkannte Zusammenhänge" - - inhalt: "Lessons Learned" - beschreibung: "Erkenntnisse aus schwierigen Tickets" - - inhalt: "Sackgassen" - beschreibung: "Dokumentierte Fehlversuche (was NICHT funktioniert)" - - aenderungsfrequenz: "Laufend" - - governance: - erstellung: "Jeder Agent kann erstellen" - freigabe: "Keine formale Freigabe (Peer-Review)" - aenderung: "Jeder Agent kann editieren" - review: "Monatliches Review-Meeting" - - review_prozess: - beschreibung: | - Monatliches Review-Meeting zur Qualitätssicherung und - Identifikation von Promotion-Kandidaten. - rhythmus: "Monatlich" - dauer: "60 Minuten" - teilnehmer: - - "Queue-Koordinator (leitet)" - - "2-3 Agents (rotierend)" - agenda: - - "Neue Einträge sichten" - - "Qualität prüfen (verständlich? korrekt?)" - - "Promotion-Kandidaten identifizieren (→ Ebene 2)" - - "Veraltete Einträge archivieren" - - "Duplikate zusammenführen" - output: - - "Qualitätsgesicherte Ebene-3-Einträge" - - "Promotion-Vorschläge für Quartals-Workshop" - - "Archivierte Einträge" - - qualitaetssicherung: - - "Peer-Review durch Kollegen" - - "Monatliches Review-Meeting" - - "Promotion bewährter Inhalte nach Ebene 2" - - # --------------------------------------------------------------------------- - # PROMOTION-PROZESS (E3 → E2) - # --------------------------------------------------------------------------- - promotion_prozess: - - beschreibung: | - Bewährte Erkenntnisse aus Ebene 3 werden in die formale - Arbeitsdokumentation (Ebene 2) überführt. - - kriterien: - - kriterium: "Häufigkeit" - beschreibung: "Lösung wurde mehrfach erfolgreich angewendet" - - kriterium: "Relevanz" - beschreibung: "Betrifft häufiges Szenario oder kritischen Service" - - kriterium: "Stabilität" - beschreibung: "Lösung ist nicht nur temporär gültig" - - kriterium: "Generalisierbarkeit" - beschreibung: "Lösung ist nicht nur für Einzelfall relevant" - - ablauf: - - schritt: 1 - name: "Identifikation" - beschreibung: "Im monatlichen Review werden Kandidaten markiert" - verantwortlich: "Queue-Koordinator" - - schritt: 2 - name: "Vorschlag" - beschreibung: "Kandidaten werden für Quartals-Workshop vorgeschlagen" - verantwortlich: "Queue-Koordinator" - - schritt: 3 - name: "Überarbeitung" - beschreibung: "Im Workshop wird Inhalt in E2-Format überführt" - verantwortlich: "Service Owner + Team" - - schritt: 4 - name: "Freigabe" - beschreibung: "Service Owner gibt formalisierte Version frei" - verantwortlich: "Service Owner" - - schritt: 5 - name: "Archivierung" - beschreibung: "Original-E3-Eintrag wird als 'promoviert' markiert" - verantwortlich: "Queue-Koordinator" - -# ============================================================================= -# KB-ARTIKEL-SCHEMA -# ============================================================================= - -artikel_schema: - - beschreibung: | - Einheitliche Struktur für KB-Artikel. Die Pflichtfelder variieren - je nach Ebene, aber die Grundstruktur ist konsistent. - - # --------------------------------------------------------------------------- - # ARTIKEL-TEMPLATE - # --------------------------------------------------------------------------- - template: - - metadaten: - - feld: "artikel_id" - typ: "string" - pflicht: true - beschreibung: "Eindeutiger Identifier" - format: "KB-[SERVICE]-[NNN]" - beispiel: "KB-OUTLOOK-042" - - - feld: "titel" - typ: "string" - pflicht: true - beschreibung: "Aussagekräftiger Titel" - max_laenge: 100 - beispiel: "Outlook stürzt beim Öffnen von Anhängen ab" - - - feld: "ebene" - typ: "enum" - pflicht: true - beschreibung: "Zuordnung im 3-Schichten-Modell" - werte: ["E1", "E2", "E3"] - - - feld: "service_zuordnung" - typ: "string" - pflicht: true - beschreibung: "Betroffener Service" - referenz: "Service-Katalog" - - - feld: "kategorie" - typ: "string" - pflicht: false - beschreibung: "Thematische Kategorie für Suche" - beispiele: ["E-Mail", "Netzwerk", "Drucker", "SAP"] - - - feld: "status" - typ: "enum" - pflicht: true - beschreibung: "Lebenszyklusstatus" - werte: - - id: "ENTWURF" - beschreibung: "In Bearbeitung, noch nicht nutzbar" - - id: "AKTIV" - beschreibung: "Freigegeben und nutzbar" - - id: "PRUEFUNG" - beschreibung: "Aktualität wird geprüft" - - id: "VERALTET" - beschreibung: "Nicht mehr gültig, aber sichtbar" - - id: "ARCHIVIERT" - beschreibung: "Nicht mehr sichtbar" - - - feld: "erstellt_von" - typ: "string" - pflicht: true - beschreibung: "Autor" - - - feld: "erstellt_am" - typ: "date" - pflicht: true - beschreibung: "Erstellungsdatum" - - - feld: "geaendert_von" - typ: "string" - pflicht: false - beschreibung: "Letzter Bearbeiter" - - - feld: "geaendert_am" - typ: "date" - pflicht: false - beschreibung: "Letzte Änderung" - - - feld: "freigegeben_von" - typ: "string" - pflicht: "E1, E2" - beschreibung: "Freigebende Person" - - - feld: "freigegeben_am" - typ: "date" - pflicht: "E1, E2" - beschreibung: "Freigabedatum" - - - feld: "naechste_pruefung" - typ: "date" - pflicht: "E1, E2" - beschreibung: "Fälligkeit der nächsten Aktualitätsprüfung" - - inhalt: - - feld: "symptom" - typ: "text" - pflicht: true - beschreibung: "Beschreibung des Problems/Symptoms aus Nutzersicht" - hinweis: "Wie beschreibt der Nutzer das Problem?" - - - feld: "ursache" - typ: "text" - pflicht: false - beschreibung: "Bekannte Ursache (wenn ermittelt)" - - - feld: "loesung" - typ: "text" - pflicht: true - beschreibung: "Lösungsschritte" - format: "Nummerierte Schritt-für-Schritt-Anleitung" - - - feld: "voraussetzungen" - typ: "list" - pflicht: false - beschreibung: "Benötigte Berechtigungen, Tools, Zugänge" - - - feld: "l1_scope" - typ: "boolean" - pflicht: true - beschreibung: "Kann von L1 umgesetzt werden?" - default: true - - - feld: "zeitaufwand" - typ: "string" - pflicht: false - beschreibung: "Geschätzter Zeitaufwand" - beispiel: "5-10 Minuten" - - - feld: "hinweise" - typ: "text" - pflicht: false - beschreibung: "Wichtige Hinweise, Warnungen, Tipps" - - - feld: "verwandte_artikel" - typ: "list" - pflicht: false - beschreibung: "Links zu verwandten KB-Artikeln" - - - feld: "problem_referenz" - typ: "string" - pflicht: false - beschreibung: "Verknüpfung zu Problem Record (wenn vorhanden)" - - - feld: "known_error" - typ: "boolean" - pflicht: false - beschreibung: "Handelt es sich um einen Known Error?" - default: false - - ebene_3_zusatz: - beschreibung: "Zusätzliche Felder nur für Ebene 3" - felder: - - feld: "experimentell" - typ: "boolean" - beschreibung: "Lösung ist noch nicht ausreichend validiert" - - feld: "verfallsdatum" - typ: "date" - beschreibung: "Bei temporären Workarounds: Gültigkeit bis" - - feld: "sackgasse" - typ: "boolean" - beschreibung: "Dokumentiert, was NICHT funktioniert" - - # --------------------------------------------------------------------------- - # QUALITÄTSKRITERIEN - # --------------------------------------------------------------------------- - qualitaetskriterien: - - beschreibung: | - Kriterien für einen "guten" KB-Artikel. Werden im Review geprüft. - - kriterien: - - id: "QK-01" - name: "Verständlichkeit" - beschreibung: "Artikel ist ohne Vorkenntnisse verständlich" - prueffrage: "Kann ein neuer L1-Agent den Artikel verstehen?" - - - id: "QK-02" - name: "Vollständigkeit" - beschreibung: "Alle Schritte sind dokumentiert" - prueffrage: "Kann die Lösung nur mit diesem Artikel umgesetzt werden?" - - - id: "QK-03" - name: "Aktualität" - beschreibung: "Artikel entspricht aktuellem Service-Stand" - prueffrage: "Funktioniert die Lösung noch?" - - - id: "QK-04" - name: "Auffindbarkeit" - beschreibung: "Artikel ist über Symptom-Suche findbar" - prueffrage: "Würde ein Agent diesen Artikel finden?" - - - id: "QK-05" - name: "Korrektheit" - beschreibung: "Lösung ist technisch korrekt" - prueffrage: "Führt die Lösung zum gewünschten Ergebnis?" - -# ============================================================================= -# PROZESSE -# ============================================================================= - -prozesse: - - # --------------------------------------------------------------------------- - # ARTIKEL ERSTELLEN - # --------------------------------------------------------------------------- - artikel_erstellen: - - id: "WM-01" - name: "KB-Artikel erstellen" - - beschreibung: | - Prozess zur Erstellung neuer KB-Artikel. Der Prozess variiert - je nach Ebene. - - trigger: - - trigger: "Explorative Diagnose abgeschlossen" - beschreibung: "Nach jeder Explorativen Diagnose MUSS ein Artikel erstellt werden" - ebene: "E3" - pflicht: true - - - trigger: "Neue Lösung gefunden" - beschreibung: "Agent findet Lösung, die nicht dokumentiert ist" - ebene: "E3" - pflicht: true - - - trigger: "Workaround aus Problem Management" - beschreibung: "Problem Manager liefert dokumentierten Workaround" - ebene: "E2 oder E3" - pflicht: true - - - trigger: "Service-Update/Release" - beschreibung: "Service Owner aktualisiert Grundlagendokumentation" - ebene: "E1" - pflicht: true - - - trigger: "Quartals-Workshop" - beschreibung: "Neue Arbeitsdokumentation wird erarbeitet" - ebene: "E2" - pflicht: false - - ablauf_e3: - - schritt: 1 - name: "Artikel anlegen" - beschreibung: "Agent erstellt neuen Artikel im Wiki" - verantwortlich: "First Level Agent / Second Level Agent" - - - schritt: 2 - name: "Template ausfüllen" - beschreibung: "Pflichtfelder gemäß Schema ausfüllen" - verantwortlich: "Agent" - - - schritt: 3 - name: "Status setzen" - beschreibung: "Status auf AKTIV setzen (kein Freigabe-Gate)" - verantwortlich: "Agent" - - - schritt: 4 - name: "Kollegen informieren" - beschreibung: "Optional: Team über neuen Artikel informieren" - verantwortlich: "Agent" - - ablauf_e2: - - schritt: 1 - name: "Thema identifizieren" - beschreibung: "Im Quartals-Workshop oder aus E3-Promotion" - verantwortlich: "Service Owner + Team" - - - schritt: 2 - name: "Artikel erarbeiten" - beschreibung: "Gemeinsame Erstellung im Workshop" - verantwortlich: "Service Owner + Team" - - - schritt: 3 - name: "Praxis-Check" - beschreibung: "Agent prüft Umsetzbarkeit" - verantwortlich: "Queue-Koordinator" - - - schritt: 4 - name: "Freigabe" - beschreibung: "Service Owner gibt frei" - verantwortlich: "Service Owner" - - - schritt: 5 - name: "Kommunikation" - beschreibung: "Team über neuen Artikel informieren" - verantwortlich: "Queue-Koordinator" - - ablauf_e1: - - schritt: 1 - name: "Dokumentation erstellen" - beschreibung: "Service Owner oder Fachexperte erstellt" - verantwortlich: "Service Owner" - - - schritt: 2 - name: "Review" - beschreibung: "Technische Prüfung durch L2/Betrieb" - verantwortlich: "Second Level / Betriebsteam" - - - schritt: 3 - name: "Freigabe" - beschreibung: "Formale Freigabe durch Service Owner" - verantwortlich: "Service Owner" - - - schritt: 4 - name: "Kommunikation" - beschreibung: "Proaktive Information an Service Desk" - verantwortlich: "Service Owner" - - - schritt: 5 - name: "Review-Termin setzen" - beschreibung: "Nächsten Prüftermin festlegen" - verantwortlich: "Service Owner" - - # --------------------------------------------------------------------------- - # ARTIKEL KONSULTIEREN - # --------------------------------------------------------------------------- - artikel_konsultieren: - - id: "WM-02" - name: "KB-Artikel konsultieren" - - beschreibung: | - KB-Konsultation ist Pflichtschritt vor jeder Eskalation und - sollte bei jeder Ticket-Bearbeitung erfolgen. - - pflicht: true - - nachweis: - beschreibung: | - Die konsultierten KB-Artikel müssen im Ticket dokumentiert werden. - Dies ist ein Pflichtfeld bei Eskalation. - ticket_feld: "kb_konsultiert" - bei_eskalation: "Pflichtfeld in DoH" - - ablauf: - - schritt: 1 - name: "Symptom-Suche" - beschreibung: "Suche nach Symptom-Beschreibung des Nutzers" - verantwortlich: "Agent" - - - schritt: 2 - name: "Service-Filter" - beschreibung: "Eingrenzung auf betroffenen Service" - verantwortlich: "Agent" - - - schritt: 3 - name: "Artikel sichten" - beschreibung: "Relevante Artikel prüfen" - verantwortlich: "Agent" - - - schritt: 4 - name: "Dokumentieren" - beschreibung: "Konsultierte Artikel im Ticket vermerken" - verantwortlich: "Agent" - - - schritt: 5 - name: "Anwenden oder Eskalieren" - beschreibung: | - Bei Treffer: Lösung anwenden - Bei Nicht-Treffer: Explorative Diagnose oder Eskalation (mit DoH) - verantwortlich: "Agent" - - ergebnisse: - - ergebnis: "Artikel gefunden, Lösung anwendbar" - aktion: "Lösung umsetzen gemäß Artikel" - - - ergebnis: "Artikel gefunden, aber nicht anwendbar" - aktion: "Dokumentieren warum nicht, ggf. Artikel-Feedback" - - - ergebnis: "Kein passender Artikel" - aktion: "Dokumentieren, Explorative Diagnose oder Eskalation" - - # --------------------------------------------------------------------------- - # ARTIKEL AKTUALISIEREN - # --------------------------------------------------------------------------- - artikel_aktualisieren: - - id: "WM-03" - name: "KB-Artikel aktualisieren" - - beschreibung: | - Prozess zur Aktualisierung bestehender Artikel bei neuen - Erkenntnissen oder Änderungen. - - trigger: - - "Artikel war nicht korrekt" - - "Bessere Lösung gefunden" - - "Service-Änderung" - - "Feedback von Agent" - - "Review-Termin erreicht" - - ablauf_e3: - - schritt: 1 - name: "Direktbearbeitung" - beschreibung: "Agent kann direkt editieren" - verantwortlich: "Agent" - - - schritt: 2 - name: "Änderung dokumentieren" - beschreibung: "Änderungsgrund kurz vermerken" - verantwortlich: "Agent" - - ablauf_e2: - - schritt: 1 - name: "Änderungsbedarf melden" - beschreibung: "Agent meldet Bedarf an Queue-Koordinator" - verantwortlich: "Agent" - - - schritt: 2 - name: "Sammeln für Workshop" - beschreibung: "Änderungswünsche werden gesammelt" - verantwortlich: "Queue-Koordinator" - - - schritt: 3 - name: "Im Workshop bearbeiten" - beschreibung: "Änderung wird im Quartals-Workshop umgesetzt" - verantwortlich: "Service Owner + Team" - - - schritt: 4 - name: "Freigabe" - beschreibung: "Service Owner gibt aktualisierte Version frei" - verantwortlich: "Service Owner" - - dringend: - beschreibung: | - Bei dringenden Korrekturen (z.B. Sicherheitsrelevant, falsche - Anleitung) kann außerhalb des Workshop-Rhythmus aktualisiert werden. - freigabe: "Service Owner" - - ablauf_e1: - - schritt: 1 - name: "Änderungsbedarf identifizieren" - beschreibung: "Service Owner oder L2 erkennt Bedarf" - verantwortlich: "Service Owner / Second Level" - - - schritt: 2 - name: "Aktualisierung durchführen" - beschreibung: "Service Owner aktualisiert Dokumentation" - verantwortlich: "Service Owner" - - - schritt: 3 - name: "Review" - beschreibung: "Technische Prüfung bei wesentlichen Änderungen" - verantwortlich: "Second Level / Betrieb" - - - schritt: 4 - name: "Freigabe und Kommunikation" - beschreibung: "Formale Freigabe, Info an Service Desk" - verantwortlich: "Service Owner" - - # --------------------------------------------------------------------------- - # ARTIKEL ARCHIVIEREN - # --------------------------------------------------------------------------- - artikel_archivieren: - - id: "WM-04" - name: "KB-Artikel archivieren" - - beschreibung: | - Veraltete Artikel werden archiviert, um die KB übersichtlich - zu halten. Archivierte Artikel sind nicht mehr in der - Standard-Suche sichtbar. - - trigger: - - "Service wurde stillgelegt" - - "Lösung ist nicht mehr gültig" - - "Artikel wurde durch neueren ersetzt" - - "Review ergibt: Artikel obsolet" - - ablauf: - - schritt: 1 - name: "Veraltung feststellen" - beschreibung: "Im Review oder durch Feedback" - verantwortlich: "Queue-Koordinator / Service Owner" - - - schritt: 2 - name: "Status ändern" - beschreibung: "Status auf VERALTET setzen (noch sichtbar mit Warnung)" - verantwortlich: "Entsprechend Ebene" - - - schritt: 3 - name: "Übergangsfrist" - beschreibung: "30 Tage als VERALTET, dann ARCHIVIERT" - verantwortlich: "System" - - - schritt: 4 - name: "Archivieren" - beschreibung: "Status auf ARCHIVIERT, nicht mehr in Standard-Suche" - verantwortlich: "System / Queue-Koordinator" - - hinweis: | - Archivierte Artikel werden NICHT gelöscht, sondern nur - ausgeblendet. Sie können bei Bedarf wiederhergestellt werden. - -# ============================================================================= -# INTEGRATION MIT EIGENSTÄNDIGER DIAGNOSE (INC-06) -# ============================================================================= - -eigenstaendige_diagnose_integration: - - beschreibung: | - Bei ANALYSE-Tickets führt der Agent eine eigenständige Diagnose durch. - Die Dokumentation der Erkenntnisse ist erwünscht, aber nicht verpflichtend - (MVP-Regelung). Dies ersetzt das frühere Konzept "Explorative Diagnose" - mit verpflichtender KB-Artikel-Erstellung. - - governance: "SSM-G-09 (MVP-Abschwächung)" - - dokumentation_mvp: - beschreibung: | - Im MVP gilt eine abgestufte Dokumentationsanforderung: - - Minimum: Kurznotiz im Ticket (Was versucht? Ergebnis?) - - Ziel: KB-Artikel (E3) bei wiederverwendbarer Lösung - - Die vollständige KB-Artikel-Pflicht ist das Zielbild nach MVP. - - minimum: - typ: "Kurznotiz im Ticket" - pflicht: true - inhalte: - - "Was wurde versucht?" - - "Was war das Ergebnis?" - - "Nächster Schritt (gelöst/eskaliert)?" - - empfohlen: - typ: "KB-Artikel (E3)" - pflicht: false - wann_sinnvoll: - - "Wiederverwendbare Lösung gefunden" - - "Relevanter Workaround identifiziert" - - "Häufig auftretendes Problem" - - artikel_typen: - bei_erfolg: - typ: "Lösung" - ebene: "E3" - empfohlene_felder: - - "Symptom" - - "Lösung (Schritte)" - - "L1-Scope (ja/nein)" - - bei_workaround: - typ: "Workaround" - ebene: "E3" - empfohlene_felder: - - "Symptom" - - "Workaround (Schritte)" - - "Einschränkungen" - - bei_sackgasse: - typ: "Sackgasse" - ebene: "E3" - empfohlene_felder: - - "Symptom" - - "Versuchte Ansätze" - - "Warum nicht funktioniert" - wert: | - Auch Sackgassen können wertvolles Wissen sein - sie verhindern, - dass andere Agents dieselben erfolglosen Wege gehen. - - uebergang_zu_zielbild: - beschreibung: | - Nach erfolgreicher MVP-Phase (Review nach 6 Monaten) wird die - vollständige KB-Artikel-Pflicht evaluiert. - kriterien: - - "KB-Artikel-Quote bei ANALYSE-Tickets > 50%" - - "Qualität der Kurznotizen ausreichend" - - "Team-Feedback positiv" - - qualitaetssicherung: - verantwortlich: "Queue-Koordinator" - methode: "Stichproben-Review" - frequenz: "Im monatlichen E3-Review" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - modul: "sub-practice_incident-management.yaml" - art: "bidirektional" - beschreibung: | - - KB-Konsultation in INC-04 (Pflicht vor Eskalation) - - Artikel-Erstellung aus Explorativer Diagnose (INC-06) - - Artikel-Erstellung bei neuen Lösungen (INC-05, INC-08) - - - modul: "sub-practice_request-management.yaml" - art: "liefert an" - beschreibung: "Standard-Request-Anleitungen" - - - modul: "sub-practice_problem-management.yaml" - art: "liefert an" - beschreibung: "Known-Error-Artikel aus Problem Management" - artikel_typ: "KNOWN_ERROR" - details: | - - Problem Management liefert Known Errors und Workarounds als KB-Artikel - - KB-Artikel können Problem-Kandidaten identifizieren (wiederkehrende Muster) - - Known Errors werden als spezielle KB-Artikel (Typ KNOWN_ERROR) dokumentiert - - Keine separate KEDB, sondern Integration in bestehende Wissensdatenbank - - - modul: "sub-practice_service-desk.yaml" - art: "wird genutzt von" - beschreibung: "Service Desk ist Hauptnutzer und -pfleger der KB" - - - modul: "spm_practice_service-catalog-management.yaml" - art: "erhält von" - beschreibung: "Service-Zuordnung für Artikel" - - - modul: "ssm_governance.yaml" - art: "wird gesteuert durch" - beschreibung: "Knowledge Review als Governance-Gremium, Qualitätssicherung" - - extern: - - partner: "ITSM-Tool" - kontext: "KB-Integration, Ticket-Verknüpfung" - status: "Tool-Auswahl ausstehend" - - - partner: "Wiki-System" - kontext: "Mögliche Plattform für Ebene 3" - status: "Tool-Entscheidung ausstehend" - -# ============================================================================= -# KENNZAHLEN (PLATZHALTER) -# ============================================================================= - -kennzahlen: - - status: "PLATZHALTER" - - beschreibung: | - Kennzahlen zur Messung der KB-Qualität und -Nutzung. - Details werden später erarbeitet. - - vorgeschlagene_kpis: - - - id: "KPI-KB-01" - name: "KB-Nutzungsrate" - beschreibung: "Anteil der Tickets mit KB-Konsultation" - formel: "(Tickets mit kb_konsultiert ≠ leer) / (Alle Tickets) × 100" - ziel: "tbd (Empfehlung: >80%)" - - - id: "KPI-KB-02" - name: "KB-Trefferquote" - beschreibung: "Anteil der Konsultationen mit relevantem Treffer" - formel: "Qualitative Erhebung" - ziel: "tbd" - - - id: "KPI-KB-03" - name: "Artikel-Aktualität" - beschreibung: "Anteil der Artikel mit Status AKTIV und Prüfung nicht überfällig" - formel: "(Aktive Artikel ohne überfällige Prüfung) / (Alle aktiven Artikel) × 100" - ziel: ">95%" - - - id: "KPI-KB-04" - name: "Explorative-Diagnose-zu-Artikel-Rate" - beschreibung: "Anteil der Explorativen Diagnosen, die zu einem Artikel führten" - formel: "(Explorative Diagnosen mit Artikel) / (Alle Explorativen Diagnosen) × 100" - ziel: "100% (Pflicht)" - - - id: "KPI-KB-05" - name: "E3-Promotion-Rate" - beschreibung: "Anteil der E3-Artikel, die nach E2 promoviert werden" - formel: "(Promovierte E3-Artikel) / (Alle E3-Artikel) × 100" - ziel: "tbd" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance: - - entscheidungen: - - - id: "SSM-G-09" - name: "Dokumentationspflicht nach Explorativer Diagnose" - - entscheidung_mvp: | - Nach jeder Explorativen Diagnose (Analyse-Pool, 90-120 Min) MUSS mindestens - eine Kurznotiz im Ticket dokumentiert werden: - - Was wurde versucht? - - Was war das Ergebnis? - - Warum wurde eskaliert / wie wurde gelöst? - - Ein vollständiger KB-Artikel (Ebene 3) ist nur erforderlich, wenn: - - Eine wiederverwendbare Lösung gefunden wurde, ODER - - Ein relevanter Workaround dokumentiert werden kann - - Die Kurznotiz im Ticket ist das Minimum, der KB-Artikel das Ziel. - - entscheidung_ziel: | - Nach jeder Explorativen Diagnose MUSS ein KB-Artikel (Ebene 3) erstellt - werden, der die Erkenntnisse dokumentiert – auch bei Misserfolg. - Dies ist das Zielbild nach MVP-Phase. - - begruendung_mvp: | - Die ursprüngliche Regel (KB-Artikel-Pflicht) ist für den MVP - zu ambitioniert und riskiert "Alibi-Artikel" oder Umgehung - der Explorativen-Diagnose-Markierung. Die abgestufte Anforderung - (Kurznotiz als Minimum) senkt die Hürde und fördert dennoch - systematische Dokumentation. - - uebergang_zu_ziel: - trigger: "Review nach 6 Monaten Betrieb" - kriterien: - - "KB-Artikel-Quote bei Explorativer Diagnose > 50%" - - "Qualität der Kurznotizen ausreichend" - - "Team-Feedback positiv" - - status: "vorgeschlagen" - mvp_anpassung: true - - - id: "SSM-G-10" - name: "KB-Konsultation Nachweispflicht" - entscheidung: | - Die Konsultation der Wissensdatenbank muss im Ticket - dokumentiert werden (Feld: kb_konsultiert). - Bei Eskalation ist dies ein Pflichtfeld in der DoH. - begruendung: | - Ohne Nachweispflicht wird KB-Konsultation umgangen. - Die Pflicht fördert systematische Nutzung. - status: "vorgeschlagen" - - - id: "SSM-G-11" - name: "Ebene-1-Freigabe durch Service Owner" - entscheidung: | - Grundlagendokumentation (Ebene 1) wird ausschließlich - durch den Service Owner freigegeben. Keine Co-Freigabe - durch SPM oder andere Rollen erforderlich. - begruendung: | - Service Owner trägt End-to-End-Verantwortung für den - Service. Die Dokumentation ist Teil dieser Verantwortung. - Zusätzliche Freigaben würden den Prozess verzögern. - status: "vorgeschlagen" - - - id: "SSM-G-12" - name: "Veraltet-Markierung manuell" - entscheidung: | - Die Markierung von Artikeln als VERALTET erfolgt manuell - im Review-Prozess, nicht automatisch nach Zeitablauf. - begruendung: | - Automatische Veraltung erzeugt Rauschen und erfordert - unnötige Prüfungen. Manuelle Markierung im Review ist - zielgerichteter und berücksichtigt fachliche Einschätzung. - status: "vorgeschlagen" - -# ============================================================================= -# RACI-REFERENZ -# ============================================================================= - -raci_referenz: - - beschreibung: | - Die verbindliche RACI-Matrix für Wissensmanagement ist in - ssm_governance.yaml → raci_konsolidiert.wissensmanagement definiert. - - Diese Kurzübersicht dient der schnellen Orientierung. - - master_dokument: "ssm_governance.yaml" - abschnitt: "raci_konsolidiert.wissensmanagement" - - rollen_mapping: - hinweis: "Rollen-IDs harmonisiert mit ssm_rollen.yaml" - first_level_agent: "L1" - second_level_agent: "L2" - queue_koordinator: "QK" - support_manager: "SM" - service_owner: "SO" - - kurzuebersicht: - # L1 L2 QK SM SO - e1_erstellen: "I C I I A/R" - e1_freigeben: "- - - - A/R" - e2_erstellen: "R C R - A/R" - e2_freigeben: "- - C - A/R" - e3_erstellen: "R R - A -" - e3_review: "C C R A -" - promotion_e3_e2: "C C R - A/R" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-WM-001" - thema: "Tool-Entscheidung" - beschreibung: "Welches System wird für die KB genutzt?" - optionen: - - "ITSM-Tool integriert" - - "Separates Wiki (Confluence, MediaWiki, etc.)" - - "Hybrid" - prioritaet: "hoch" - status: "offen" - - - id: "OPEN-WM-002" - thema: "Kategorie-Taxonomie" - beschreibung: "Einheitliche Kategorien für KB-Artikel definieren" - prioritaet: "mittel" - status: "offen" - - - id: "OPEN-WM-003" - thema: "Initiale Befüllung" - beschreibung: "Wie wird die KB initial befüllt? Migration bestehender Doku?" - prioritaet: "mittel" - status: "offen" - - - id: "OPEN-WM-004" - thema: "Kennzahlen-Zielwerte" - beschreibung: "Konkrete Zielwerte für KB-KPIs festlegen" - prioritaet: "niedrig" - status: "offen" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.2" - datum: "2025-12-07" - aenderung: | - - SSM-G-09: MVP-Abschwächung der Dokumentationspflicht - (Kurznotiz als Minimum, KB-Artikel als Ziel) - autor: "DIGITOM-Projekt" - - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung mit 3-Schichten-Modell, Artikel-Schema, Prozessen" +# ============================================================================= +# SSM WISSENSMANAGEMENT +# ============================================================================= + +metadata: + id: "SSM-WM" + name: "Wissensmanagement im Service-Support" + version: "0.1" + status: "draft" + erstellt: "2025-12-07" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + + beschreibung: | + Querschnitts-Dokument für das Wissensmanagement im Service-Support. + Definiert das 3-Schichten-Modell, Artikel-Struktur, Governance und + Prozesse für die Wissensdatenbank (KB). + + design_referenz: "ssm_design-zieldimensionen.yaml" + relevante_saeulen: ["LS-05"] + + gilt_fuer: + - "sub-practice_incident-management.yaml" + - "sub-practice_request-management.yaml" + - "sub-practice_problem-management.yaml" + - "sub-practice_service-desk.yaml" + + blueprint_referenz: "service-lifecycle_service-support.yaml" + relevante_aktivitaeten: ["ss_02"] + +# ============================================================================= +# ZWECK & SCOPE +# ============================================================================= + +zweck: + + definition: | + Das Wissensmanagement stellt sicher, dass Lösungswissen systematisch + erfasst, gepflegt und genutzt wird. Es durchbricht den Teufelskreis + aus mangelnder Dokumentation, fehlender Nutzung und Frustration. + + ziele: + - "Erhöhung der First-Call-Resolution durch verfügbares Lösungswissen" + - "Reduzierung von Eskalationen durch dokumentierte L1-Lösungen" + - "Vermeidung von Wissensverlusten bei Personalwechsel" + - "Systematische Überführung von Erfahrungswissen in strukturierte Dokumentation" + - "Klare Verantwortlichkeiten für Erstellung, Pflege und Qualitätssicherung" + + problemstellung: + beschreibung: | + Die Analyse hat einen Teufelskreis identifiziert: + - L2 erstellt keine Anleitungen ("wird eh nicht gelesen") + - L1 findet nichts Brauchbares + - L1 fragt direkt nach + - L2 ist frustriert + - (zurück zum Anfang) + + ursachen: + - "Keine klare Governance (jeder kann ändern ohne Kontrolle)" + - "Keine Qualitätssicherung" + - "Keine Aktualitätsprüfung" + - "Keine Verbindlichkeit der Nutzung" + + referenz: "ssm_synthese_analyse-grundlagen.yaml → KB-06" + + scope: + inkludiert: + - "Alle Dokumentation für den operativen Support" + - "Service-bezogene Troubleshooting-Anleitungen" + - "Workarounds und Known Errors" + - "Standard-Request-Anleitungen" + - "Operative Erkenntnisse aus Ticket-Bearbeitung" + + exkludiert: + - "Strategische Service-Dokumentation (→ Service Catalog)" + - "Projekt-Dokumentation (→ Projektmanagement)" + - "Nutzer-Dokumentation / Handbücher (→ separate Verantwortung)" + +# ============================================================================= +# 3-SCHICHTEN-MODELL +# ============================================================================= + +drei_schichten_modell: + + beschreibung: | + Das Wissensmanagement folgt einem 3-Schichten-Modell mit + differenzierter Verantwortung, Änderungsfrequenz und Qualitätssicherung. + Die Schichten bauen aufeinander auf und haben unterschiedliche + Governance-Anforderungen. + + referenz: "LS-05 (Design-Zieldimensionen)" + + # --------------------------------------------------------------------------- + # EBENE 1: GRUNDLAGENDOKUMENTATION + # --------------------------------------------------------------------------- + ebene_1: + + id: "KB-E1" + name: "Grundlagendokumentation" + + beschreibung: | + Stabile, grundlegende Service-Dokumentation. Beschreibt WAS der + Service tut und WIE er funktioniert. Änderungen nur bei + Service-Updates oder strukturellen Anpassungen. + + verantwortung: + accountable: "Service Owner" + responsible: "Service Owner / Fachexperte" + consulted: "Second Level Support, Betriebsteam" + informed: "First Level Support, Service Desk Manager" + + charakteristika: + - "Verbindlich und qualitätsgesichert" + - "Versioniert mit Change-Log" + - "Formal freigegeben" + - "Änderungen proaktiv kommuniziert" + + inhalte: + - inhalt: "Service-Beschreibung und Scope" + beschreibung: "Was leistet der Service? Was nicht?" + - inhalt: "Technische Architektur" + beschreibung: "Komponenten, Abhängigkeiten, Schnittstellen" + - inhalt: "Basis-Troubleshooting" + beschreibung: "Grundlegende Diagnose- und Lösungswege" + - inhalt: "Eskalationswege" + beschreibung: "Ansprechpartner, Zuständigkeiten" + - inhalt: "SLA-relevante Parameter" + beschreibung: "Kritische Schwellwerte, Verfügbarkeitszeiten" + + aenderungsfrequenz: "Bei Service-Updates oder strukturellen Änderungen" + + governance: + erstellung: "Service Owner erstellt oder beauftragt" + freigabe: "Service Owner (alleinig)" + aenderung: "Nur durch Service Owner oder delegierte Fachexperten" + review: "Bei jedem Service-Release, mindestens jährlich" + + qualitaetssicherung: + - "Versionierung verpflichtend" + - "Change-Log mit Datum und Autor" + - "Formale Freigabe dokumentiert" + - "Kommunikation an Service Desk bei Updates" + + # --------------------------------------------------------------------------- + # EBENE 2: ARBEITSDOKUMENTATION + # --------------------------------------------------------------------------- + ebene_2: + + id: "KB-E2" + name: "Arbeitsdokumentation" + + beschreibung: | + Operative Übersetzung der Grundlagendokumentation in + praxisorientierte Handlungsanweisungen. Gemeinsam erarbeitet + von Service Owner und Service Desk Team. + + verantwortung: + accountable: "Service Owner" + responsible: "Service Owner + Service Desk Team (Co-Creation)" + consulted: "Queue-Koordinator" + informed: "Support Manager" + + charakteristika: + - "Praxisorientiert und handlungsleitend" + - "Step-by-Step-Anleitungen" + - "Regelmäßig aktualisiert basierend auf Erfahrungen" + - "Gemeinsam erarbeitet und validiert" + + inhalte: + - inhalt: "Step-by-Step-Anleitungen" + beschreibung: "Konkrete Schrittfolgen für häufige Szenarien" + - inhalt: "Checklisten" + beschreibung: "Prüflisten für Diagnose und Lösung" + - inhalt: "Entscheidungsbäume" + beschreibung: "Wenn-Dann-Logiken für Triage" + - inhalt: "Workarounds" + beschreibung: "Dokumentierte temporäre Lösungen" + - inhalt: "Quick-Reference-Guides" + beschreibung: "Kurzanleitungen für Standardsituationen" + - inhalt: "Tool-spezifische Anleitungen" + beschreibung: "Bedienung von Support-Tools" + + aenderungsfrequenz: "Quartalsweise Review, Ad-hoc bei Bedarf" + + governance: + erstellung: "Co-Creation in Workshop-Sessions" + freigabe: "Service Owner (inhaltlich) + Queue-Koordinator (praktikabel)" + aenderung: "Service Desk Team mit Review durch Service Owner" + review: "Quartalsweise Workshop-Sessions" + + co_creation_prozess: + beschreibung: | + Quartalsweise gemeinsame Workshop-Sessions, in denen + Service Owner und Service Desk Team Arbeitsdokumentation + erarbeiten und validieren. + rhythmus: "Quartalsweise" + teilnehmer: + - "Service Owner (moderiert)" + - "Queue-Koordinator" + - "2-3 erfahrene Agents (rotierend)" + agenda: + - "Review bestehender Arbeitsdoku" + - "Feedback aus Praxis einarbeiten" + - "Neue Themen aus Ebene 3 übernehmen (Promotion)" + - "Veraltete Inhalte identifizieren" + output: + - "Aktualisierte Arbeitsdokumentation" + - "Promotion-Entscheidungen (E3 → E2)" + - "Archivierungs-Entscheidungen" + + qualitaetssicherung: + - "Praxis-Validierung durch Service Desk" + - "Inhaltliche Freigabe durch Service Owner" + - "Quartalsweises Review" + + # --------------------------------------------------------------------------- + # KNOWN ERROR ARTIKEL + # --------------------------------------------------------------------------- + known_error_artikel: + + beschreibung: | + Known Errors werden als spezieller KB-Artikel-Typ dokumentiert. + Sie sind Teil der Ebene 2 (Arbeitsdokumentation) und werden + von Problem Management erstellt. + + referenz: "sub-practice_problem-management.yaml → kernkonzepte.known_error" + governance: "SSM-G-20" + + artikel_typ: "KNOWN_ERROR" + kb_ebene: "Ebene 2" + + pflichtfelder: + - feld: "symptome" + beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?" + - feld: "workaround" + beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?" + - feld: "root_cause" + beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)" + - feld: "problem_referenz" + beschreibung: "Verknüpfung zum Problem Record (ID)" + - feld: "status" + beschreibung: "AKTIV oder OBSOLET" + werte: ["AKTIV", "OBSOLET"] + default: "AKTIV" + + optionale_felder: + - feld: "permanente_loesung" + beschreibung: "Geplante Lösung, wenn bekannt" + - feld: "change_referenz" + beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit" + - feld: "betroffene_services" + beschreibung: "Liste der betroffenen Services" + + lebenszyklus: + erstellung: "Bei PRB-02, wenn Workaround dokumentiert wird" + nutzung: "L1/L2 finden Artikel bei Incident-Bearbeitung via KB-Suche" + aktualisierung: "Bei neuen Erkenntnissen oder verbessertem Workaround" + obsolet: "Nach Implementierung permanenter Lösung" + + verantwortung: + ersteller: "Second Level Agent" + freigabe: "Service Owner" + pflege: "Service Owner" + + # --------------------------------------------------------------------------- + # EBENE 3: OPERATIVE ERKENNTNISSE + # --------------------------------------------------------------------------- + ebene_3: + + id: "KB-E3" + name: "Operative Erkenntnisse" + + beschreibung: | + Dynamische, schnell änderbare Wissensbasis. Bottom-up aus + täglicher Arbeit. Peer-Review statt zentraler Kontrolle. + Experimenteller Charakter erlaubt. + + verantwortung: + accountable: "Support Manager" + responsible: "Service Desk Team (jeder Agent)" + consulted: "-" + informed: "Queue-Koordinator" + + charakteristika: + - "Wiki-Prinzip: Jeder kann erstellen und editieren" + - "Niedrige Einstiegshürde" + - "Schnelle Verfügbarkeit" + - "Experimenteller Charakter erlaubt" + - "Peer-Review statt zentrale Kontrolle" + + inhalte: + - inhalt: "Edge-Case-Lösungen" + beschreibung: "Lösungen für spezielle Einzelfälle" + - inhalt: "Tipps und Tricks" + beschreibung: "Praktische Hinweise aus Erfahrung" + - inhalt: "Temporäre Workarounds" + beschreibung: "Kurzfristige Lösungen (mit Verfallsdatum)" + - inhalt: "Beobachtungen und Muster" + beschreibung: "Erkannte Zusammenhänge" + - inhalt: "Lessons Learned" + beschreibung: "Erkenntnisse aus schwierigen Tickets" + - inhalt: "Sackgassen" + beschreibung: "Dokumentierte Fehlversuche (was NICHT funktioniert)" + + aenderungsfrequenz: "Laufend" + + governance: + erstellung: "Jeder Agent kann erstellen" + freigabe: "Keine formale Freigabe (Peer-Review)" + aenderung: "Jeder Agent kann editieren" + review: "Monatliches Review-Meeting" + + review_prozess: + beschreibung: | + Monatliches Review-Meeting zur Qualitätssicherung und + Identifikation von Promotion-Kandidaten. + rhythmus: "Monatlich" + dauer: "60 Minuten" + teilnehmer: + - "Queue-Koordinator (leitet)" + - "2-3 Agents (rotierend)" + agenda: + - "Neue Einträge sichten" + - "Qualität prüfen (verständlich? korrekt?)" + - "Promotion-Kandidaten identifizieren (→ Ebene 2)" + - "Veraltete Einträge archivieren" + - "Duplikate zusammenführen" + output: + - "Qualitätsgesicherte Ebene-3-Einträge" + - "Promotion-Vorschläge für Quartals-Workshop" + - "Archivierte Einträge" + + qualitaetssicherung: + - "Peer-Review durch Kollegen" + - "Monatliches Review-Meeting" + - "Promotion bewährter Inhalte nach Ebene 2" + + # --------------------------------------------------------------------------- + # PROMOTION-PROZESS (E3 → E2) + # --------------------------------------------------------------------------- + promotion_prozess: + + beschreibung: | + Bewährte Erkenntnisse aus Ebene 3 werden in die formale + Arbeitsdokumentation (Ebene 2) überführt. + + kriterien: + - kriterium: "Häufigkeit" + beschreibung: "Lösung wurde mehrfach erfolgreich angewendet" + - kriterium: "Relevanz" + beschreibung: "Betrifft häufiges Szenario oder kritischen Service" + - kriterium: "Stabilität" + beschreibung: "Lösung ist nicht nur temporär gültig" + - kriterium: "Generalisierbarkeit" + beschreibung: "Lösung ist nicht nur für Einzelfall relevant" + + ablauf: + - schritt: 1 + name: "Identifikation" + beschreibung: "Im monatlichen Review werden Kandidaten markiert" + verantwortlich: "Queue-Koordinator" + - schritt: 2 + name: "Vorschlag" + beschreibung: "Kandidaten werden für Quartals-Workshop vorgeschlagen" + verantwortlich: "Queue-Koordinator" + - schritt: 3 + name: "Überarbeitung" + beschreibung: "Im Workshop wird Inhalt in E2-Format überführt" + verantwortlich: "Service Owner + Team" + - schritt: 4 + name: "Freigabe" + beschreibung: "Service Owner gibt formalisierte Version frei" + verantwortlich: "Service Owner" + - schritt: 5 + name: "Archivierung" + beschreibung: "Original-E3-Eintrag wird als 'promoviert' markiert" + verantwortlich: "Queue-Koordinator" + +# ============================================================================= +# KB-ARTIKEL-SCHEMA +# ============================================================================= + +artikel_schema: + + beschreibung: | + Einheitliche Struktur für KB-Artikel. Die Pflichtfelder variieren + je nach Ebene, aber die Grundstruktur ist konsistent. + + # --------------------------------------------------------------------------- + # ARTIKEL-TEMPLATE + # --------------------------------------------------------------------------- + template: + + metadaten: + - feld: "artikel_id" + typ: "string" + pflicht: true + beschreibung: "Eindeutiger Identifier" + format: "KB-[SERVICE]-[NNN]" + beispiel: "KB-OUTLOOK-042" + + - feld: "titel" + typ: "string" + pflicht: true + beschreibung: "Aussagekräftiger Titel" + max_laenge: 100 + beispiel: "Outlook stürzt beim Öffnen von Anhängen ab" + + - feld: "ebene" + typ: "enum" + pflicht: true + beschreibung: "Zuordnung im 3-Schichten-Modell" + werte: ["E1", "E2", "E3"] + + - feld: "service_zuordnung" + typ: "string" + pflicht: true + beschreibung: "Betroffener Service" + referenz: "Service-Katalog" + + - feld: "kategorie" + typ: "string" + pflicht: false + beschreibung: "Thematische Kategorie für Suche" + beispiele: ["E-Mail", "Netzwerk", "Drucker", "SAP"] + + - feld: "status" + typ: "enum" + pflicht: true + beschreibung: "Lebenszyklusstatus" + werte: + - id: "ENTWURF" + beschreibung: "In Bearbeitung, noch nicht nutzbar" + - id: "AKTIV" + beschreibung: "Freigegeben und nutzbar" + - id: "PRUEFUNG" + beschreibung: "Aktualität wird geprüft" + - id: "VERALTET" + beschreibung: "Nicht mehr gültig, aber sichtbar" + - id: "ARCHIVIERT" + beschreibung: "Nicht mehr sichtbar" + + - feld: "erstellt_von" + typ: "string" + pflicht: true + beschreibung: "Autor" + + - feld: "erstellt_am" + typ: "date" + pflicht: true + beschreibung: "Erstellungsdatum" + + - feld: "geaendert_von" + typ: "string" + pflicht: false + beschreibung: "Letzter Bearbeiter" + + - feld: "geaendert_am" + typ: "date" + pflicht: false + beschreibung: "Letzte Änderung" + + - feld: "freigegeben_von" + typ: "string" + pflicht: "E1, E2" + beschreibung: "Freigebende Person" + + - feld: "freigegeben_am" + typ: "date" + pflicht: "E1, E2" + beschreibung: "Freigabedatum" + + - feld: "naechste_pruefung" + typ: "date" + pflicht: "E1, E2" + beschreibung: "Fälligkeit der nächsten Aktualitätsprüfung" + + inhalt: + - feld: "symptom" + typ: "text" + pflicht: true + beschreibung: "Beschreibung des Problems/Symptoms aus Nutzersicht" + hinweis: "Wie beschreibt der Nutzer das Problem?" + + - feld: "ursache" + typ: "text" + pflicht: false + beschreibung: "Bekannte Ursache (wenn ermittelt)" + + - feld: "loesung" + typ: "text" + pflicht: true + beschreibung: "Lösungsschritte" + format: "Nummerierte Schritt-für-Schritt-Anleitung" + + - feld: "voraussetzungen" + typ: "list" + pflicht: false + beschreibung: "Benötigte Berechtigungen, Tools, Zugänge" + + - feld: "l1_scope" + typ: "boolean" + pflicht: true + beschreibung: "Kann von L1 umgesetzt werden?" + default: true + + - feld: "zeitaufwand" + typ: "string" + pflicht: false + beschreibung: "Geschätzter Zeitaufwand" + beispiel: "5-10 Minuten" + + - feld: "hinweise" + typ: "text" + pflicht: false + beschreibung: "Wichtige Hinweise, Warnungen, Tipps" + + - feld: "verwandte_artikel" + typ: "list" + pflicht: false + beschreibung: "Links zu verwandten KB-Artikeln" + + - feld: "problem_referenz" + typ: "string" + pflicht: false + beschreibung: "Verknüpfung zu Problem Record (wenn vorhanden)" + + - feld: "known_error" + typ: "boolean" + pflicht: false + beschreibung: "Handelt es sich um einen Known Error?" + default: false + + ebene_3_zusatz: + beschreibung: "Zusätzliche Felder nur für Ebene 3" + felder: + - feld: "experimentell" + typ: "boolean" + beschreibung: "Lösung ist noch nicht ausreichend validiert" + - feld: "verfallsdatum" + typ: "date" + beschreibung: "Bei temporären Workarounds: Gültigkeit bis" + - feld: "sackgasse" + typ: "boolean" + beschreibung: "Dokumentiert, was NICHT funktioniert" + + # --------------------------------------------------------------------------- + # QUALITÄTSKRITERIEN + # --------------------------------------------------------------------------- + qualitaetskriterien: + + beschreibung: | + Kriterien für einen "guten" KB-Artikel. Werden im Review geprüft. + + kriterien: + - id: "QK-01" + name: "Verständlichkeit" + beschreibung: "Artikel ist ohne Vorkenntnisse verständlich" + prueffrage: "Kann ein neuer L1-Agent den Artikel verstehen?" + + - id: "QK-02" + name: "Vollständigkeit" + beschreibung: "Alle Schritte sind dokumentiert" + prueffrage: "Kann die Lösung nur mit diesem Artikel umgesetzt werden?" + + - id: "QK-03" + name: "Aktualität" + beschreibung: "Artikel entspricht aktuellem Service-Stand" + prueffrage: "Funktioniert die Lösung noch?" + + - id: "QK-04" + name: "Auffindbarkeit" + beschreibung: "Artikel ist über Symptom-Suche findbar" + prueffrage: "Würde ein Agent diesen Artikel finden?" + + - id: "QK-05" + name: "Korrektheit" + beschreibung: "Lösung ist technisch korrekt" + prueffrage: "Führt die Lösung zum gewünschten Ergebnis?" + +# ============================================================================= +# PROZESSE +# ============================================================================= + +prozesse: + + # --------------------------------------------------------------------------- + # ARTIKEL ERSTELLEN + # --------------------------------------------------------------------------- + artikel_erstellen: + + id: "WM-01" + name: "KB-Artikel erstellen" + + beschreibung: | + Prozess zur Erstellung neuer KB-Artikel. Der Prozess variiert + je nach Ebene. + + trigger: + - trigger: "Explorative Diagnose abgeschlossen" + beschreibung: "Nach jeder Explorativen Diagnose MUSS ein Artikel erstellt werden" + ebene: "E3" + pflicht: true + + - trigger: "Neue Lösung gefunden" + beschreibung: "Agent findet Lösung, die nicht dokumentiert ist" + ebene: "E3" + pflicht: true + + - trigger: "Workaround aus Problem Management" + beschreibung: "Problem Manager liefert dokumentierten Workaround" + ebene: "E2 oder E3" + pflicht: true + + - trigger: "Service-Update/Release" + beschreibung: "Service Owner aktualisiert Grundlagendokumentation" + ebene: "E1" + pflicht: true + + - trigger: "Quartals-Workshop" + beschreibung: "Neue Arbeitsdokumentation wird erarbeitet" + ebene: "E2" + pflicht: false + + ablauf_e3: + - schritt: 1 + name: "Artikel anlegen" + beschreibung: "Agent erstellt neuen Artikel im Wiki" + verantwortlich: "First Level Agent / Second Level Agent" + + - schritt: 2 + name: "Template ausfüllen" + beschreibung: "Pflichtfelder gemäß Schema ausfüllen" + verantwortlich: "Agent" + + - schritt: 3 + name: "Status setzen" + beschreibung: "Status auf AKTIV setzen (kein Freigabe-Gate)" + verantwortlich: "Agent" + + - schritt: 4 + name: "Kollegen informieren" + beschreibung: "Optional: Team über neuen Artikel informieren" + verantwortlich: "Agent" + + ablauf_e2: + - schritt: 1 + name: "Thema identifizieren" + beschreibung: "Im Quartals-Workshop oder aus E3-Promotion" + verantwortlich: "Service Owner + Team" + + - schritt: 2 + name: "Artikel erarbeiten" + beschreibung: "Gemeinsame Erstellung im Workshop" + verantwortlich: "Service Owner + Team" + + - schritt: 3 + name: "Praxis-Check" + beschreibung: "Agent prüft Umsetzbarkeit" + verantwortlich: "Queue-Koordinator" + + - schritt: 4 + name: "Freigabe" + beschreibung: "Service Owner gibt frei" + verantwortlich: "Service Owner" + + - schritt: 5 + name: "Kommunikation" + beschreibung: "Team über neuen Artikel informieren" + verantwortlich: "Queue-Koordinator" + + ablauf_e1: + - schritt: 1 + name: "Dokumentation erstellen" + beschreibung: "Service Owner oder Fachexperte erstellt" + verantwortlich: "Service Owner" + + - schritt: 2 + name: "Review" + beschreibung: "Technische Prüfung durch L2/Betrieb" + verantwortlich: "Second Level / Betriebsteam" + + - schritt: 3 + name: "Freigabe" + beschreibung: "Formale Freigabe durch Service Owner" + verantwortlich: "Service Owner" + + - schritt: 4 + name: "Kommunikation" + beschreibung: "Proaktive Information an Service Desk" + verantwortlich: "Service Owner" + + - schritt: 5 + name: "Review-Termin setzen" + beschreibung: "Nächsten Prüftermin festlegen" + verantwortlich: "Service Owner" + + # --------------------------------------------------------------------------- + # ARTIKEL KONSULTIEREN + # --------------------------------------------------------------------------- + artikel_konsultieren: + + id: "WM-02" + name: "KB-Artikel konsultieren" + + beschreibung: | + KB-Konsultation ist Pflichtschritt vor jeder Eskalation und + sollte bei jeder Ticket-Bearbeitung erfolgen. + + pflicht: true + + nachweis: + beschreibung: | + Die konsultierten KB-Artikel müssen im Ticket dokumentiert werden. + Dies ist ein Pflichtfeld bei Eskalation. + ticket_feld: "kb_konsultiert" + bei_eskalation: "Pflichtfeld in DoH" + + ablauf: + - schritt: 1 + name: "Symptom-Suche" + beschreibung: "Suche nach Symptom-Beschreibung des Nutzers" + verantwortlich: "Agent" + + - schritt: 2 + name: "Service-Filter" + beschreibung: "Eingrenzung auf betroffenen Service" + verantwortlich: "Agent" + + - schritt: 3 + name: "Artikel sichten" + beschreibung: "Relevante Artikel prüfen" + verantwortlich: "Agent" + + - schritt: 4 + name: "Dokumentieren" + beschreibung: "Konsultierte Artikel im Ticket vermerken" + verantwortlich: "Agent" + + - schritt: 5 + name: "Anwenden oder Eskalieren" + beschreibung: | + Bei Treffer: Lösung anwenden + Bei Nicht-Treffer: Explorative Diagnose oder Eskalation (mit DoH) + verantwortlich: "Agent" + + ergebnisse: + - ergebnis: "Artikel gefunden, Lösung anwendbar" + aktion: "Lösung umsetzen gemäß Artikel" + + - ergebnis: "Artikel gefunden, aber nicht anwendbar" + aktion: "Dokumentieren warum nicht, ggf. Artikel-Feedback" + + - ergebnis: "Kein passender Artikel" + aktion: "Dokumentieren, Explorative Diagnose oder Eskalation" + + # --------------------------------------------------------------------------- + # ARTIKEL AKTUALISIEREN + # --------------------------------------------------------------------------- + artikel_aktualisieren: + + id: "WM-03" + name: "KB-Artikel aktualisieren" + + beschreibung: | + Prozess zur Aktualisierung bestehender Artikel bei neuen + Erkenntnissen oder Änderungen. + + trigger: + - "Artikel war nicht korrekt" + - "Bessere Lösung gefunden" + - "Service-Änderung" + - "Feedback von Agent" + - "Review-Termin erreicht" + + ablauf_e3: + - schritt: 1 + name: "Direktbearbeitung" + beschreibung: "Agent kann direkt editieren" + verantwortlich: "Agent" + + - schritt: 2 + name: "Änderung dokumentieren" + beschreibung: "Änderungsgrund kurz vermerken" + verantwortlich: "Agent" + + ablauf_e2: + - schritt: 1 + name: "Änderungsbedarf melden" + beschreibung: "Agent meldet Bedarf an Queue-Koordinator" + verantwortlich: "Agent" + + - schritt: 2 + name: "Sammeln für Workshop" + beschreibung: "Änderungswünsche werden gesammelt" + verantwortlich: "Queue-Koordinator" + + - schritt: 3 + name: "Im Workshop bearbeiten" + beschreibung: "Änderung wird im Quartals-Workshop umgesetzt" + verantwortlich: "Service Owner + Team" + + - schritt: 4 + name: "Freigabe" + beschreibung: "Service Owner gibt aktualisierte Version frei" + verantwortlich: "Service Owner" + + dringend: + beschreibung: | + Bei dringenden Korrekturen (z.B. Sicherheitsrelevant, falsche + Anleitung) kann außerhalb des Workshop-Rhythmus aktualisiert werden. + freigabe: "Service Owner" + + ablauf_e1: + - schritt: 1 + name: "Änderungsbedarf identifizieren" + beschreibung: "Service Owner oder L2 erkennt Bedarf" + verantwortlich: "Service Owner / Second Level" + + - schritt: 2 + name: "Aktualisierung durchführen" + beschreibung: "Service Owner aktualisiert Dokumentation" + verantwortlich: "Service Owner" + + - schritt: 3 + name: "Review" + beschreibung: "Technische Prüfung bei wesentlichen Änderungen" + verantwortlich: "Second Level / Betrieb" + + - schritt: 4 + name: "Freigabe und Kommunikation" + beschreibung: "Formale Freigabe, Info an Service Desk" + verantwortlich: "Service Owner" + + # --------------------------------------------------------------------------- + # ARTIKEL ARCHIVIEREN + # --------------------------------------------------------------------------- + artikel_archivieren: + + id: "WM-04" + name: "KB-Artikel archivieren" + + beschreibung: | + Veraltete Artikel werden archiviert, um die KB übersichtlich + zu halten. Archivierte Artikel sind nicht mehr in der + Standard-Suche sichtbar. + + trigger: + - "Service wurde stillgelegt" + - "Lösung ist nicht mehr gültig" + - "Artikel wurde durch neueren ersetzt" + - "Review ergibt: Artikel obsolet" + + ablauf: + - schritt: 1 + name: "Veraltung feststellen" + beschreibung: "Im Review oder durch Feedback" + verantwortlich: "Queue-Koordinator / Service Owner" + + - schritt: 2 + name: "Status ändern" + beschreibung: "Status auf VERALTET setzen (noch sichtbar mit Warnung)" + verantwortlich: "Entsprechend Ebene" + + - schritt: 3 + name: "Übergangsfrist" + beschreibung: "30 Tage als VERALTET, dann ARCHIVIERT" + verantwortlich: "System" + + - schritt: 4 + name: "Archivieren" + beschreibung: "Status auf ARCHIVIERT, nicht mehr in Standard-Suche" + verantwortlich: "System / Queue-Koordinator" + + hinweis: | + Archivierte Artikel werden NICHT gelöscht, sondern nur + ausgeblendet. Sie können bei Bedarf wiederhergestellt werden. + +# ============================================================================= +# INTEGRATION MIT EIGENSTÄNDIGER DIAGNOSE (INC-06) +# ============================================================================= + +eigenstaendige_diagnose_integration: + + beschreibung: | + Bei ANALYSE-Tickets führt der Agent eine eigenständige Diagnose durch. + Die Dokumentation der Erkenntnisse ist erwünscht, aber nicht verpflichtend + (MVP-Regelung). Dies ersetzt das frühere Konzept "Explorative Diagnose" + mit verpflichtender KB-Artikel-Erstellung. + + governance: "SSM-G-09 (MVP-Abschwächung)" + + dokumentation_mvp: + beschreibung: | + Im MVP gilt eine abgestufte Dokumentationsanforderung: + - Minimum: Kurznotiz im Ticket (Was versucht? Ergebnis?) + - Ziel: KB-Artikel (E3) bei wiederverwendbarer Lösung + + Die vollständige KB-Artikel-Pflicht ist das Zielbild nach MVP. + + minimum: + typ: "Kurznotiz im Ticket" + pflicht: true + inhalte: + - "Was wurde versucht?" + - "Was war das Ergebnis?" + - "Nächster Schritt (gelöst/eskaliert)?" + + empfohlen: + typ: "KB-Artikel (E3)" + pflicht: false + wann_sinnvoll: + - "Wiederverwendbare Lösung gefunden" + - "Relevanter Workaround identifiziert" + - "Häufig auftretendes Problem" + + artikel_typen: + bei_erfolg: + typ: "Lösung" + ebene: "E3" + empfohlene_felder: + - "Symptom" + - "Lösung (Schritte)" + - "L1-Scope (ja/nein)" + + bei_workaround: + typ: "Workaround" + ebene: "E3" + empfohlene_felder: + - "Symptom" + - "Workaround (Schritte)" + - "Einschränkungen" + + bei_sackgasse: + typ: "Sackgasse" + ebene: "E3" + empfohlene_felder: + - "Symptom" + - "Versuchte Ansätze" + - "Warum nicht funktioniert" + wert: | + Auch Sackgassen können wertvolles Wissen sein - sie verhindern, + dass andere Agents dieselben erfolglosen Wege gehen. + + uebergang_zu_zielbild: + beschreibung: | + Nach erfolgreicher MVP-Phase (Review nach 6 Monaten) wird die + vollständige KB-Artikel-Pflicht evaluiert. + kriterien: + - "KB-Artikel-Quote bei ANALYSE-Tickets > 50%" + - "Qualität der Kurznotizen ausreichend" + - "Team-Feedback positiv" + + qualitaetssicherung: + verantwortlich: "Queue-Koordinator" + methode: "Stichproben-Review" + frequenz: "Im monatlichen E3-Review" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + - modul: "sub-practice_incident-management.yaml" + art: "bidirektional" + beschreibung: | + - KB-Konsultation in INC-04 (Pflicht vor Eskalation) + - Artikel-Erstellung aus Explorativer Diagnose (INC-06) + - Artikel-Erstellung bei neuen Lösungen (INC-05, INC-08) + + - modul: "sub-practice_request-management.yaml" + art: "liefert an" + beschreibung: "Standard-Request-Anleitungen" + + - modul: "sub-practice_problem-management.yaml" + art: "liefert an" + beschreibung: "Known-Error-Artikel aus Problem Management" + artikel_typ: "KNOWN_ERROR" + details: | + - Problem Management liefert Known Errors und Workarounds als KB-Artikel + - KB-Artikel können Problem-Kandidaten identifizieren (wiederkehrende Muster) + - Known Errors werden als spezielle KB-Artikel (Typ KNOWN_ERROR) dokumentiert + - Keine separate KEDB, sondern Integration in bestehende Wissensdatenbank + + - modul: "sub-practice_service-desk.yaml" + art: "wird genutzt von" + beschreibung: "Service Desk ist Hauptnutzer und -pfleger der KB" + + - modul: "spm_practice_service-catalog-management.yaml" + art: "erhält von" + beschreibung: "Service-Zuordnung für Artikel" + + - modul: "ssm_governance.yaml" + art: "wird gesteuert durch" + beschreibung: "Knowledge Review als Governance-Gremium, Qualitätssicherung" + + extern: + - partner: "ITSM-Tool" + kontext: "KB-Integration, Ticket-Verknüpfung" + status: "Tool-Auswahl ausstehend" + + - partner: "Wiki-System" + kontext: "Mögliche Plattform für Ebene 3" + status: "Tool-Entscheidung ausstehend" + +# ============================================================================= +# KENNZAHLEN (PLATZHALTER) +# ============================================================================= + +kennzahlen: + + status: "PLATZHALTER" + + beschreibung: | + Kennzahlen zur Messung der KB-Qualität und -Nutzung. + Details werden später erarbeitet. + + vorgeschlagene_kpis: + + - id: "KPI-KB-01" + name: "KB-Nutzungsrate" + beschreibung: "Anteil der Tickets mit KB-Konsultation" + formel: "(Tickets mit kb_konsultiert ≠ leer) / (Alle Tickets) × 100" + ziel: "tbd (Empfehlung: >80%)" + + - id: "KPI-KB-02" + name: "KB-Trefferquote" + beschreibung: "Anteil der Konsultationen mit relevantem Treffer" + formel: "Qualitative Erhebung" + ziel: "tbd" + + - id: "KPI-KB-03" + name: "Artikel-Aktualität" + beschreibung: "Anteil der Artikel mit Status AKTIV und Prüfung nicht überfällig" + formel: "(Aktive Artikel ohne überfällige Prüfung) / (Alle aktiven Artikel) × 100" + ziel: ">95%" + + - id: "KPI-KB-04" + name: "Explorative-Diagnose-zu-Artikel-Rate" + beschreibung: "Anteil der Explorativen Diagnosen, die zu einem Artikel führten" + formel: "(Explorative Diagnosen mit Artikel) / (Alle Explorativen Diagnosen) × 100" + ziel: "100% (Pflicht)" + + - id: "KPI-KB-05" + name: "E3-Promotion-Rate" + beschreibung: "Anteil der E3-Artikel, die nach E2 promoviert werden" + formel: "(Promovierte E3-Artikel) / (Alle E3-Artikel) × 100" + ziel: "tbd" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance: + + entscheidungen: + + - id: "SSM-G-09" + name: "Dokumentationspflicht nach Explorativer Diagnose" + + entscheidung_mvp: | + Nach jeder Explorativen Diagnose (Analyse-Pool, 90-120 Min) MUSS mindestens + eine Kurznotiz im Ticket dokumentiert werden: + - Was wurde versucht? + - Was war das Ergebnis? + - Warum wurde eskaliert / wie wurde gelöst? + + Ein vollständiger KB-Artikel (Ebene 3) ist nur erforderlich, wenn: + - Eine wiederverwendbare Lösung gefunden wurde, ODER + - Ein relevanter Workaround dokumentiert werden kann + + Die Kurznotiz im Ticket ist das Minimum, der KB-Artikel das Ziel. + + entscheidung_ziel: | + Nach jeder Explorativen Diagnose MUSS ein KB-Artikel (Ebene 3) erstellt + werden, der die Erkenntnisse dokumentiert – auch bei Misserfolg. + Dies ist das Zielbild nach MVP-Phase. + + begruendung_mvp: | + Die ursprüngliche Regel (KB-Artikel-Pflicht) ist für den MVP + zu ambitioniert und riskiert "Alibi-Artikel" oder Umgehung + der Explorativen-Diagnose-Markierung. Die abgestufte Anforderung + (Kurznotiz als Minimum) senkt die Hürde und fördert dennoch + systematische Dokumentation. + + uebergang_zu_ziel: + trigger: "Review nach 6 Monaten Betrieb" + kriterien: + - "KB-Artikel-Quote bei Explorativer Diagnose > 50%" + - "Qualität der Kurznotizen ausreichend" + - "Team-Feedback positiv" + + status: "vorgeschlagen" + mvp_anpassung: true + + - id: "SSM-G-10" + name: "KB-Konsultation Nachweispflicht" + entscheidung: | + Die Konsultation der Wissensdatenbank muss im Ticket + dokumentiert werden (Feld: kb_konsultiert). + Bei Eskalation ist dies ein Pflichtfeld in der DoH. + begruendung: | + Ohne Nachweispflicht wird KB-Konsultation umgangen. + Die Pflicht fördert systematische Nutzung. + status: "vorgeschlagen" + + - id: "SSM-G-11" + name: "Ebene-1-Freigabe durch Service Owner" + entscheidung: | + Grundlagendokumentation (Ebene 1) wird ausschließlich + durch den Service Owner freigegeben. Keine Co-Freigabe + durch SPM oder andere Rollen erforderlich. + begruendung: | + Service Owner trägt End-to-End-Verantwortung für den + Service. Die Dokumentation ist Teil dieser Verantwortung. + Zusätzliche Freigaben würden den Prozess verzögern. + status: "vorgeschlagen" + + - id: "SSM-G-12" + name: "Veraltet-Markierung manuell" + entscheidung: | + Die Markierung von Artikeln als VERALTET erfolgt manuell + im Review-Prozess, nicht automatisch nach Zeitablauf. + begruendung: | + Automatische Veraltung erzeugt Rauschen und erfordert + unnötige Prüfungen. Manuelle Markierung im Review ist + zielgerichteter und berücksichtigt fachliche Einschätzung. + status: "vorgeschlagen" + +# ============================================================================= +# RACI-REFERENZ +# ============================================================================= + +raci_referenz: + + beschreibung: | + Die verbindliche RACI-Matrix für Wissensmanagement ist in + ssm_governance.yaml → raci_konsolidiert.wissensmanagement definiert. + + Diese Kurzübersicht dient der schnellen Orientierung. + + master_dokument: "ssm_governance.yaml" + abschnitt: "raci_konsolidiert.wissensmanagement" + + rollen_mapping: + hinweis: "Rollen-IDs harmonisiert mit ssm_rollen.yaml" + first_level_agent: "L1" + second_level_agent: "L2" + queue_koordinator: "QK" + support_manager: "SM" + service_owner: "SO" + + kurzuebersicht: + # L1 L2 QK SM SO + e1_erstellen: "I C I I A/R" + e1_freigeben: "- - - - A/R" + e2_erstellen: "R C R - A/R" + e2_freigeben: "- - C - A/R" + e3_erstellen: "R R - A -" + e3_review: "C C R A -" + promotion_e3_e2: "C C R - A/R" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-WM-001" + thema: "Tool-Entscheidung" + beschreibung: "Welches System wird für die KB genutzt?" + optionen: + - "ITSM-Tool integriert" + - "Separates Wiki (Confluence, MediaWiki, etc.)" + - "Hybrid" + prioritaet: "hoch" + status: "offen" + + - id: "OPEN-WM-002" + thema: "Kategorie-Taxonomie" + beschreibung: "Einheitliche Kategorien für KB-Artikel definieren" + prioritaet: "mittel" + status: "offen" + + - id: "OPEN-WM-003" + thema: "Initiale Befüllung" + beschreibung: "Wie wird die KB initial befüllt? Migration bestehender Doku?" + prioritaet: "mittel" + status: "offen" + + - id: "OPEN-WM-004" + thema: "Kennzahlen-Zielwerte" + beschreibung: "Konkrete Zielwerte für KB-KPIs festlegen" + prioritaet: "niedrig" + status: "offen" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.2" + datum: "2025-12-07" + aenderung: | + - SSM-G-09: MVP-Abschwächung der Dokumentationspflicht + (Kurznotiz als Minimum, KB-Artikel als Ziel) + autor: "DIGITOM-Projekt" + + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung mit 3-Schichten-Modell, Artikel-Schema, Prozessen" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml index 07b1f03..69b20cc 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml @@ -1,843 +1,843 @@ -# ============================================================================= -# SUB-PRACTICE: PROBLEM MANAGEMENT -# ============================================================================= - -metadata: - id: "P-06" - name: "Problem Management" - version: "0.1" - status: "draft" - erstellt: "2025-12-07" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - parent_practice: "practice_service-support-management" - - itil4_referenz: "Problem Management Practice" - yasm_referenz: "LP4.7.2, LP4.7.3, LP4.7.4, LP4.7.5" - - hinweis_yasm: | - LP4.7.1 (Proaktives Identifizieren) ist im MVP nicht im Scope. - Nur reaktive Problem-Identifikation aus Incidents. - - blueprint_referenz: "service-lifecycle_service-support.yaml" - relevante_aktivitaeten: ["ss_09", "ss_10", "ss_11"] - - design_referenz: "ssm_design-zieldimensionen.yaml" - relevante_saeulen: ["LS-05", "LS-06"] - - schema_referenz: "ssm_schema_ticket.yaml" - rollen_referenz: "ssm_rollen.yaml" - wissensmanagement_referenz: "ssm_wissensmanagement.yaml" - -# ============================================================================= -# ZWECK & SCOPE -# ============================================================================= - -zweck: - - definition: | - Problem Management reduziert die Wahrscheinlichkeit und Auswirkungen - von Incidents durch Identifikation der zugrundeliegenden Ursachen, - Entwicklung von Workarounds und Initiierung nachhaltiger Lösungen. - - ziele: - - "Identifikation der Ursachen wiederkehrender oder schwerwiegender Incidents" - - "Bereitstellung von Workarounds zur Reduktion von Incident-Auswirkungen" - - "Dokumentation von Known Errors für schnellere Incident-Bearbeitung" - - "Initiierung permanenter Lösungen über Change Management" - - "Reduktion der Gesamtzahl von Incidents durch Ursachenbeseitigung" - - mvp_scope: - beschreibung: | - Im MVP ist Problem Management auf reaktive Identifikation aus - Incidents beschränkt. Proaktive Problem-Identifikation (Trend-Analyse, - Monitoring-basiert) ist nicht im Scope. - - im_scope: - - "Reaktive Problem-Identifikation aus Incidents" - - "Basis-Root-Cause-Analyse" - - "Workaround-Dokumentation als Known Error" - - "Change-Initiierung für permanente Lösungen" - - nicht_im_scope: - - "Proaktive Problem-Identifikation (LP4.7.1)" - - "Systematische Trend-Analyse" - - "Formale RCA-Methoden (5-Why, Ishikawa) – können genutzt werden, sind aber nicht vorgeschrieben" - - "Separate Known Error Database (KEDB)" - - governance: "SSM-G-19" - - abgrenzung: - - problem_vs_incident: | - Ein Incident ist eine ungeplante Unterbrechung, die schnellstmöglich - behoben werden muss (Symptombehandlung). Ein Problem ist die - zugrundeliegende Ursache eines oder mehrerer Incidents. - - Incident Management: "Wie stelle ich den Service wieder her?" - Problem Management: "Warum ist der Service ausgefallen?" - - problem_vs_change: | - Problem Management identifiziert Ursachen und entwickelt Lösungsvorschläge. - Die Implementierung permanenter Lösungen erfolgt über Change Enablement. - Problem Management initiiert Changes, implementiert sie aber nicht selbst. - - problem_vs_known_error: | - Ein Problem ist eine identifizierte oder vermutete Ursache. - Ein Known Error ist ein Problem, dessen Ursache analysiert wurde - und für das ein dokumentierter Workaround existiert. - -# ============================================================================= -# KERNKONZEPTE -# ============================================================================= - -kernkonzepte: - - # --------------------------------------------------------------------------- - # ROLLENMODELL - # --------------------------------------------------------------------------- - rollenmodell: - - beschreibung: | - Im MVP gibt es keine dedizierte Problem-Manager-Rolle. Die Verantwortung - ist auf bestehende Rollen verteilt, mit dem Service Owner als - Process Owner für Problem Management in seinem Service-Bereich. - - governance: "SSM-G-18" - - begruendung: | - ITIL4 warnt explizit davor, Problem Management als separate Funktion - aufzubauen: "If it is set up as a separate team or group, there is - a danger it will just become a dumping ground for everything the - other support staff find too difficult." - - Im MVP-Kontext von DIGIT ist der Service Owner ohnehin Teil des - operativen Teams und kann die Koordination übernehmen. - - verantwortlichkeiten: - - service_owner: - rolle: "Process Owner Problem Management (für seinen Service)" - aufgaben: - - "Wiederkehrende Muster im Blick behalten" - - "Root-Cause-Analyse koordinieren und ggf. durchführen" - - "Sicherstellen, dass Workarounds dokumentiert werden" - - "Entscheidung über permanente Lösungen (Change)" - - "Problem-Priorisierung und -Überwachung" - - "Problem-Abschluss" - kann_delegieren_an: "Second Level Agents (Experten)" - - second_level_agent: - rolle: "Operative Durchführung" - aufgaben: - - "Problem Record erstellen (bei Erkennung in Incident-Bearbeitung)" - - "Root-Cause-Analyse durchführen (bei Delegation durch SO)" - - "Workaround entwickeln und dokumentieren" - - "Known-Error-Artikel erstellen" - - queue_koordinator: - rolle: "Muster-Erkennung" - aufgaben: - - "Wiederkehrende Incidents in Queues erkennen" - - "Service Owner auf Muster hinweisen" - - "Problem-Record-Erstellung anstoßen (via INC-12)" - - support_manager: - rolle: "Übergreifende Koordination" - aufgaben: - - "Koordination bei Service-übergreifenden Problemen" - - "Eskalation bei Ressourcen-Konflikten" - - "Reporting über Problem-Status" - - # --------------------------------------------------------------------------- - # PROBLEM-IDENTIFIKATION (REAKTIV) - # --------------------------------------------------------------------------- - problem_identifikation: - - beschreibung: | - Im MVP werden Probleme ausschließlich reaktiv aus dem Incident - Management identifiziert. Es gibt zwei definierte Trigger. - - trigger: - - - id: "TRIGGER-01" - name: "Nicht lösbarer Incident" - quelle: "INC-11" - beschreibung: | - Ein Incident kann im L2 nicht gelöst werden, obwohl Diagnose - durchgeführt wurde. Es wird eine strukturelle Ursache vermutet. - kriterien: - - "L2-Diagnose abgeschlossen ohne Lösung" - - "Workaround implementiert, aber Ursache unbekannt" - - "Strukturelle Ursache vermutet" - - - id: "TRIGGER-02" - name: "Wiederkehrende Incidents" - quelle: "INC-12" - beschreibung: | - Mehrere ähnliche Incidents deuten auf ein zugrundeliegendes - Problem hin. - kriterien: - - "≥3 ähnliche Incidents innerhalb von 5 Arbeitstagen" - - "Gemeinsame Symptome oder betroffene Komponente" - - "Queue-Koordinator oder L2 erkennt Muster" - - nicht_im_mvp_scope: - - "Proaktive Identifikation aus Monitoring-Daten" - - "Trend-Analyse über Incident-Statistiken" - - "Supplier- oder Partner-Informationen" - - "Erkenntnisse aus Testing oder Entwicklung" - - # --------------------------------------------------------------------------- - # PRIORISIERUNG - # --------------------------------------------------------------------------- - priorisierung: - - beschreibung: | - Problems werden nicht über eine eigene Prioritäts-Matrix bewertet, - sondern über eine einfache Ableitung aus Service-Kontext und - Incident-Auswirkung. - - modellentscheidung: | - Diese Priorisierungslogik ist ein konzeptioneller Vorschlag für - den MVP. Bei steigender Problem-Anzahl kann eine differenziertere - Matrix erforderlich werden. - - dringlichkeitsstufen: - - - stufe: "HOCH" - kriterien: - - "Service-Kategorie C" - - "ODER >5 verknüpfte Incidents" - - "ODER kein Workaround verfügbar" - erwartung: "Sofortige Bearbeitung, RCA innerhalb 5 AT" - - - stufe: "MITTEL" - kriterien: - - "Service-Kategorie B" - - "UND 3-5 verknüpfte Incidents" - - "UND Workaround vorhanden" - erwartung: "Bearbeitung innerhalb 10 AT" - - - stufe: "NIEDRIG" - kriterien: - - "Service-Kategorie A" - - "ODER <3 verknüpfte Incidents" - - "UND Workaround vorhanden" - erwartung: "Bearbeitung nach Kapazität" - - hinweis: | - Die Dringlichkeit kann vom Service Owner bei Bedarf angepasst - werden (z.B. bei politischer Relevanz oder Außenwirkung). - - # --------------------------------------------------------------------------- - # KNOWN ERROR KONZEPT - # --------------------------------------------------------------------------- - known_error: - - beschreibung: | - Ein Known Error ist ein Problem, dessen Ursache analysiert wurde - (auch wenn nicht vollständig verstanden) und für das ein - dokumentierter Workaround existiert. - - governance: "SSM-G-20" - - dokumentation: - beschreibung: | - Known Errors werden nicht in einer separaten KEDB geführt, - sondern als KB-Artikel mit speziellem Typ in der bestehenden - Wissensdatenbank dokumentiert. - - kb_integration: - artikel_typ: "KNOWN_ERROR" - kb_ebene: "Ebene 2 (Arbeitsdokumentation)" - referenz: "ssm_wissensmanagement.yaml" - - pflichtfelder: - - feld: "symptome" - beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?" - - feld: "workaround" - beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?" - - feld: "root_cause" - beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)" - - feld: "problem_referenz" - beschreibung: "Verknüpfung zum Problem Record" - - feld: "status" - beschreibung: "AKTIV oder OBSOLET" - werte: ["AKTIV", "OBSOLET"] - - optionale_felder: - - feld: "permanente_loesung" - beschreibung: "Geplante Lösung, wenn bekannt" - - feld: "change_referenz" - beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit" - - feld: "betroffene_services" - beschreibung: "Liste der betroffenen Services" - - lebenszyklus: - - "Problem wird als KNOWN_ERROR markiert, wenn Workaround dokumentiert" - - "Known-Error-Artikel wird erstellt/aktualisiert" - - "Bei Incident-Bearbeitung: KB-Suche findet Known Error" - - "Agent wendet Workaround an" - - "Nach permanenter Lösung: Artikel-Status auf OBSOLET" - -# ============================================================================= -# PROZESS-AKTIVITÄTEN -# ============================================================================= - -aktivitaeten_uebersicht: | - Problem Management im MVP besteht aus 4 Kernaktivitäten. - Der Prozess ist schlank gehalten und fokussiert auf die - wesentlichen Schritte von Erfassung bis Schließung. - -aktivitaeten: - - # --------------------------------------------------------------------------- - # PRB-01: PROBLEM ERFASSEN - # --------------------------------------------------------------------------- - - id: "PRB-01" - name: "Problem erfassen" - phase: "Identifikation" - blueprint_referenz: "ss_09, ss_10" - yasm_referenz: "LP4.7.2" - - beschreibung: | - Erstellung eines Problem Records basierend auf einem der - definierten Trigger. Dokumentation der Symptome und - Verknüpfung mit auslösenden Incidents. - - trigger: - - "INC-11: Nicht lösbarer Incident" - - "INC-12: Wiederkehrende Incidents identifiziert" - - aktivitaeten: - - "Problem Record im ITSM-Tool erstellen" - - "Symptome und Auswirkungen dokumentieren" - - "Auslösende Incidents verknüpfen" - - "Betroffenen Service identifizieren" - - "Service-Kategorie übernehmen" - - "Erste Hypothese zur Ursache (wenn vorhanden)" - - "Dringlichkeit ableiten" - - "Service Owner informieren" - - problem_record_felder: - pflicht: - - "problem_id (automatisch)" - - "titel" - - "symptom_beschreibung" - - "betroffener_service" - - "service_kategorie" - - "verknuepfte_incidents (mindestens 1)" - - "erstellt_von" - - "erstellt_am" - - "status (NEU)" - - "dringlichkeit" - optional: - - "erste_hypothese" - - "bekannter_workaround" - - "betroffene_komponente" - - output: - - "Problem Record mit Status NEU" - - "Verknüpfung zu auslösenden Incidents" - - "Service Owner informiert" - - raci: - r: "Second Level Agent" - a: "Service Owner" - c: "Queue-Koordinator" - i: "-" - - # --------------------------------------------------------------------------- - # PRB-02: PROBLEM ANALYSIEREN - # --------------------------------------------------------------------------- - - id: "PRB-02" - name: "Problem analysieren (Root-Cause-Analyse)" - phase: "Analyse" - blueprint_referenz: "ss_11" - yasm_referenz: "LP4.7.3" - - beschreibung: | - Durchführung einer Root-Cause-Analyse zur Identifikation der - zugrundeliegenden Ursache. Entwicklung eines Workarounds, - wenn keine sofortige Lösung möglich ist. - - vorbedingung: "Problem Record mit Status NEU" - - aktivitaeten: - - "Status auf IN_ANALYSE setzen" - - "Verfügbare Informationen sammeln und sichten" - - "Verknüpfte Incidents analysieren (Gemeinsamkeiten)" - - "Hypothesen zur Ursache entwickeln" - - "Hypothesen systematisch prüfen" - - "Root Cause identifizieren oder eingrenzen" - - "Workaround entwickeln (wenn Ursache nicht sofort behebbar)" - - "Ergebnisse dokumentieren" - - rca_methoden: - beschreibung: | - Im MVP sind keine formalen RCA-Methoden vorgeschrieben. - Folgende Ansätze können bei Bedarf genutzt werden: - optionale_methoden: - - "5-Why-Analyse" - - "Ishikawa-Diagramm (Fishbone)" - - "Timeline-Analyse" - - "Vergleichsanalyse (funktionierend vs. nicht funktionierend)" - hinweis: "Pragmatisches Vorgehen ist im MVP ausreichend." - - ergebnis_varianten: - - root_cause_gefunden: - beschreibung: "Ursache wurde identifiziert" - naechster_schritt: - workaround_reicht: "→ Status KNOWN_ERROR, KB-Artikel erstellen" - permanente_loesung_noetig: "→ PRB-03 (Lösung initiieren)" - - root_cause_nicht_gefunden: - beschreibung: "Ursache konnte nicht eindeutig identifiziert werden" - naechster_schritt: - workaround_vorhanden: "→ Status KNOWN_ERROR, weiter beobachten" - kein_workaround: "→ Problem bleibt IN_ANALYSE, Eskalation prüfen" - - workaround_dokumentation: - beschreibung: | - Wenn ein Workaround entwickelt wurde, muss dieser als - Known-Error-Artikel dokumentiert werden. - verantwortlich: "Second Level Agent" - freigabe: "Service Owner" - referenz: "kernkonzepte.known_error" - - output: - - "Dokumentierte Analyseergebnisse" - - "Root Cause (wenn identifiziert)" - - "Workaround (wenn entwickelt)" - - "Known-Error-Artikel (wenn Workaround dokumentiert)" - - "Empfehlung für weiteres Vorgehen" - - raci: - r: "Second Level Agent / Service Owner" - a: "Service Owner" - c: "Lieferant (bei externen Komponenten)" - i: "Support Manager" - - # --------------------------------------------------------------------------- - # PRB-03: LÖSUNG INITIIEREN - # --------------------------------------------------------------------------- - - id: "PRB-03" - name: "Lösung initiieren" - phase: "Lösung" - blueprint_referenz: "ss_11" - yasm_referenz: "LP4.7.3, LP4.7.4" - - beschreibung: | - Initiierung einer permanenten Lösung, wenn ein Workaround - nicht ausreicht oder die Ursache nachhaltig beseitigt werden soll. - Die Implementierung erfolgt über Change Enablement. - - vorbedingung: | - - Root Cause identifiziert oder eingegrenzt - - Entscheidung: Permanente Lösung erforderlich/wirtschaftlich sinnvoll - - entscheidungskriterien: - beschreibung: | - Der Service Owner entscheidet, ob eine permanente Lösung - angestrebt wird. Kriterien: - kriterien: - - "Workaround ist aufwändig oder fehleranfällig" - - "Incident-Häufigkeit rechtfertigt Investition" - - "Risiko bei Fortbestehen des Problems" - - "Kosten-Nutzen-Verhältnis einer permanenten Lösung" - hinweis: | - Nicht jedes Problem muss permanent gelöst werden. Ein stabiler - Workaround kann eine akzeptable Dauerlösung sein. - - aktivitaeten: - - "Lösungsoptionen bewerten" - - "Kosten-Nutzen-Abschätzung (informell)" - - "Entscheidung: Change oder alternative Maßnahme" - - "Bei Change: Change Request erstellen" - - "Problem Record mit Change verknüpfen" - - "Status auf WARTEN_CHANGE setzen" - - "Problem-Überwachung während Change-Implementierung" - - change_initiierung: - beschreibung: | - Die meisten permanenten Lösungen erfordern einen Change. - Problem Management erstellt den Change Request, die - Implementierung erfolgt über Change Enablement. - change_request_inhalt: - - "Verweis auf Problem Record" - - "Beschreibung der Ursache" - - "Vorgeschlagene Lösung" - - "Erwarteter Nutzen (reduzierte Incidents)" - schnittstelle: "practice_change-enablement.yaml (Platzhalter)" - - alternative_massnahmen: - beschreibung: | - Nicht alle Lösungen erfordern einen formalen Change. - beispiele: - - "Konfigurationsanpassung im Standard-Scope" - - "Schulung/Kommunikation an Nutzer" - - "Prozessanpassung" - - "Lieferanten-Eskalation" - - output: - - "Entscheidung dokumentiert" - - "Change Request (wenn erforderlich)" - - "Problem Record Status WARTEN_CHANGE oder KNOWN_ERROR" - - raci: - r: "Service Owner" - a: "Service Owner" - c: "Support Manager" - i: "Second Level Agent" - - # --------------------------------------------------------------------------- - # PRB-04: PROBLEM SCHLIESSEN - # --------------------------------------------------------------------------- - - id: "PRB-04" - name: "Problem schließen" - phase: "Abschluss" - yasm_referenz: "LP4.7.5" - - beschreibung: | - Abschluss des Problem Records nach erfolgreicher Lösung - oder bewusster Entscheidung, das Problem nicht weiter zu verfolgen. - - schliessungsgruende: - - loesung_implementiert: - beschreibung: "Permanente Lösung wurde via Change implementiert" - aktivitaeten: - - "Validieren: Lösung wirksam? (keine neuen Incidents)" - - "Known-Error-Artikel auf OBSOLET setzen" - - "Verknüpfte Incidents prüfen" - - "Problem Record auf GESCHLOSSEN setzen" - - "Abschlussdokumentation" - - workaround_akzeptiert: - beschreibung: "Workaround ist Dauerlösung, keine weitere Aktion geplant" - aktivitaeten: - - "Entscheidung dokumentieren (warum keine permanente Lösung)" - - "Known-Error-Artikel bleibt AKTIV" - - "Problem Record auf GESCHLOSSEN setzen" - - "Hinweis: Bei Änderung der Situation kann neu bewertet werden" - - duplikat_oder_ungueltig: - beschreibung: "Problem ist Duplikat oder war kein echtes Problem" - aktivitaeten: - - "Begründung dokumentieren" - - "Ggf. mit anderem Problem Record verknüpfen" - - "Problem Record auf GESCHLOSSEN setzen" - - validierung_bei_loesung: - beschreibung: | - Nach Implementierung einer permanenten Lösung muss validiert - werden, dass das Problem tatsächlich behoben ist. - methoden: - - "Monitoring der Incident-Rate für betroffenen Service" - - "Beobachtungszeitraum (empfohlen: 2-4 Wochen)" - - "Rückmeldung von L1/L2 zur Incident-Entwicklung" - bei_misserfolg: "Zurück zu IN_ANALYSE" - - output: - - "Problem Record mit Status GESCHLOSSEN" - - "Abschlussdokumentation" - - "Known-Error-Artikel aktualisiert (OBSOLET wenn gelöst)" - - "Lessons Learned (optional)" - - raci: - r: "Service Owner" - a: "Service Owner" - c: "-" - i: "Support Manager" - -# ============================================================================= -# STATUS-LIFECYCLE -# ============================================================================= - -status_lifecycle: - - beschreibung: | - Vereinfachtes Status-Modell für Problem Records im MVP. - Analog zum Ticket-Schema, aber auf Problem-Spezifika angepasst. - - status_werte: - - - id: "NEU" - name: "Neu" - beschreibung: "Problem Record erstellt, noch nicht in Analyse" - - - id: "IN_ANALYSE" - name: "In Analyse" - beschreibung: "Root-Cause-Analyse läuft" - - - id: "KNOWN_ERROR" - name: "Known Error" - beschreibung: | - Ursache bekannt oder eingegrenzt, Workaround dokumentiert. - Keine permanente Lösung geplant oder in Bewertung. - - - id: "WARTEN_CHANGE" - name: "Warten auf Change" - beschreibung: "Permanente Lösung via Change in Arbeit" - - - id: "GELOEST" - name: "Gelöst" - beschreibung: "Lösung implementiert, Validierung läuft" - - - id: "GESCHLOSSEN" - name: "Geschlossen" - beschreibung: "Problem final abgeschlossen" - - transitionen: - - - von: "NEU" - nach: ["IN_ANALYSE", "GESCHLOSSEN"] - beschreibung: "Analyse starten oder als Duplikat/ungültig schließen" - - - von: "IN_ANALYSE" - nach: ["KNOWN_ERROR", "WARTEN_CHANGE", "GESCHLOSSEN"] - beschreibung: "Analyse abgeschlossen mit verschiedenen Ergebnissen" - - - von: "KNOWN_ERROR" - nach: ["WARTEN_CHANGE", "IN_ANALYSE", "GESCHLOSSEN"] - beschreibung: "Change initiieren, neu analysieren oder akzeptieren" - - - von: "WARTEN_CHANGE" - nach: ["GELOEST", "IN_ANALYSE"] - beschreibung: "Change erfolgreich oder gescheitert" - - - von: "GELOEST" - nach: ["GESCHLOSSEN", "IN_ANALYSE"] - beschreibung: "Validierung erfolgreich oder Problem tritt erneut auf" - - - von: "GESCHLOSSEN" - nach: ["IN_ANALYSE"] - beschreibung: "Wiedereröffnung bei erneutem Auftreten" - bedingung: "Nur mit Begründung durch Service Owner" - -# ============================================================================= -# RACI-REFERENZ -# ============================================================================= - -raci_referenz: - - beschreibung: | - Die verbindliche RACI-Matrix für Problem Management ist in - ssm_governance.yaml → raci_konsolidiert.problem_management definiert. - - Diese Kurzübersicht dient der schnellen Orientierung. - - master_dokument: "ssm_governance.yaml" - abschnitt: "raci_konsolidiert.problem_management" - - hinweis_service_owner: | - Der Service Owner ist Process Owner für Problem Management (SSM-G-18). - Er kann operative Tätigkeiten (R) an Second Level Agents delegieren, - bleibt aber immer Accountable (A). - - kurzuebersicht: - # L2 QK SM SO - problem_erfassen: "R C - A" - problem_analysieren: "R - I A/R" - loesung_initiieren: "I - C A/R" - problem_schliessen: "- - I A/R" - known_error_erstellen: "R - - A" - muster_erkennen: "C R - A" - - hinweis: "L1 ist im Problem Management nicht direkt beteiligt" - -# ============================================================================= -# KENNZAHLEN -# ============================================================================= - -kennzahlen: - - beschreibung: | - Basis-KPIs für Problem Management im MVP. Fokus auf Wirksamkeit, - nicht auf Prozess-Compliance. - - kpis: - - - id: "KPI-PRB-01" - name: "Anzahl offener Probleme" - beschreibung: "Aktuelle Anzahl nicht geschlossener Problem Records" - messung: "Stichtag" - ziel: "Kein festes Ziel, Trend beobachten" - - - id: "KPI-PRB-02" - name: "Problem-Lösungsrate" - beschreibung: "Anteil der Probleme mit permanenter Lösung (nicht nur Workaround)" - formel: "(Probleme mit Lösung) / (Geschlossene Probleme) × 100" - ziel: "tbd" - hinweis: "Nicht jedes Problem muss permanent gelöst werden" - - - id: "KPI-PRB-03" - name: "Known Errors mit aktivem Workaround" - beschreibung: "Anzahl dokumentierter Known Errors" - messung: "Stichtag" - ziel: "Kein festes Ziel – zeigt Reife des Prozesses" - - - id: "KPI-PRB-04" - name: "Incident-Reduktion nach Problem-Lösung" - beschreibung: "Reduktion der Incidents nach Implementierung einer Lösung" - messung: "Vergleich Incident-Rate vor/nach Lösung" - ziel: ">50% Reduktion" - hinweis: "Nur messbar bei ausreichender Datenbasis" - - todo: | - - Zielwerte mit DIGIT abstimmen - - Reporting-Frequenz festlegen (empfohlen: monatlich) - - Baseline nach 3 Monaten Betrieb etablieren - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - - modul: "sub-practice_incident-management.yaml" - art: "erhält von" - beschreibung: "Problem Records aus INC-11 und INC-12" - aktivitaeten: ["INC-11", "INC-12"] - - - modul: "ssm_wissensmanagement.yaml" - art: "liefert an" - beschreibung: "Known-Error-Artikel (Ebene 2)" - artikel_typ: "KNOWN_ERROR" - - - modul: "ssm_schema_ticket.yaml" - art: "implementiert" - beschreibung: "Problem Record Datenstruktur (analog zu Ticket)" - - - modul: "spm_practice_service-level-management.yaml" - art: "referenziert" - beschreibung: "Service-Kategorien für Priorisierung" - - - modul: "sub-practice_service-desk.yaml" - art: "erhält von" - beschreibung: "Problem Records werden oft durch Service Desk (via L2) erstellt" - - - modul: "ssm_governance.yaml" - art: "wird gesteuert durch" - beschreibung: "Reporting-Struktur, Service Owner Reviews" - - extern: - - - partner: "Change Enablement" - kontext: "Initiierung permanenter Lösungen via Change" - status: "Schnittstelle zu P-03 (Platzhalter)" - aktivitaet: "PRB-03" - - - partner: "ITSM-Tool" - kontext: "Problem Record Lifecycle" - status: "Tool-Auswahl ausstehend" - - - partner: "Lieferanten" - kontext: "RCA-Unterstützung bei externen Komponenten" - status: "Fallweise" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance: - - beschreibung: | - Governance-Entscheidungen für Problem Management. - Zur Übertragung ins zentrale Log. - - entscheidungen: - - - id: "SSM-G-18" - name: "Keine dedizierte Problem-Manager-Rolle" - entscheidung: | - Im MVP gibt es keine dedizierte Problem-Manager-Rolle. - Der Service Owner ist Process Owner für Problem Management - in seinem Service-Bereich. Operative Tätigkeiten können an - Second Level Agents delegiert werden. - begruendung: | - Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs- - strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung - für die Service-Qualität. ITIL4 warnt explizit davor, Problem - Management als separate Funktion aufzubauen. - status: "vorgeschlagen" - - - id: "SSM-G-19" - name: "Problem Management nur reaktiv im MVP" - entscheidung: | - Problem-Identifikation erfolgt im MVP ausschließlich reaktiv - aus dem Incident Management (nicht lösbare oder wiederkehrende - Incidents). Proaktive Problem-Identifikation (LP4.7.1) ist - nicht im Scope. - begruendung: | - MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt - die Datenbasis (Incident-Trends, Monitoring-Integration). - Kann in späteren Ausbaustufen ergänzt werden. - status: "vorgeschlagen" - - - id: "SSM-G-20" - name: "Known Errors als KB-Artikel" - entscheidung: | - Known Errors werden als KB-Artikel mit speziellem Typ - (KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert. - Es wird keine separate Known Error Database (KEDB) geführt. - begruendung: | - Integration in bestehendes Wissensmanagement, vermeidet - Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen - ohnehin in der KB – Known Errors werden so automatisch gefunden. - status: "vorgeschlagen" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-PRB-001" - thema: "Problem Record Schema" - beschreibung: | - Das Problem Record Schema muss analog zum Ticket Schema - definiert werden. Kann als Erweiterung von ssm_schema_ticket.yaml - oder als eigenes Schema erfolgen. - prioritaet: "mittel" - status: "Entscheidung ausstehend" - - - id: "OPEN-PRB-002" - thema: "Change-Schnittstelle" - beschreibung: | - Detaillierte Schnittstelle zu Change Enablement (P-03) definieren, - sobald dieses Modul entwickelt ist. - prioritaet: "mittel" - status: "Abhängig von P-03 Entwicklung" - abhaengig_von: "practice_change-enablement.yaml" - - - id: "OPEN-PRB-003" - thema: "Known-Error-Artikel-Template" - beschreibung: | - Template für Known-Error-Artikel in der KB erstellen und - in ssm_wissensmanagement.yaml integrieren. - prioritaet: "hoch" - status: "Bei KB-Implementierung" - - - id: "OPEN-PRB-004" - thema: "Problem-Incident-Verknüpfung im Tool" - beschreibung: | - Technische Umsetzung der Verknüpfung zwischen Problem Records - und Incidents im ITSM-Tool. - prioritaet: "hoch" - status: "Tool-Auswahl ausstehend" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung als MVP-Version" +# ============================================================================= +# SUB-PRACTICE: PROBLEM MANAGEMENT +# ============================================================================= + +metadata: + id: "P-06" + name: "Problem Management" + version: "0.1" + status: "draft" + erstellt: "2025-12-07" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + + parent_practice: "practice_service-support-management" + + itil4_referenz: "Problem Management Practice" + yasm_referenz: "LP4.7.2, LP4.7.3, LP4.7.4, LP4.7.5" + + hinweis_yasm: | + LP4.7.1 (Proaktives Identifizieren) ist im MVP nicht im Scope. + Nur reaktive Problem-Identifikation aus Incidents. + + blueprint_referenz: "service-lifecycle_service-support.yaml" + relevante_aktivitaeten: ["ss_09", "ss_10", "ss_11"] + + design_referenz: "ssm_design-zieldimensionen.yaml" + relevante_saeulen: ["LS-05", "LS-06"] + + schema_referenz: "ssm_schema_ticket.yaml" + rollen_referenz: "ssm_rollen.yaml" + wissensmanagement_referenz: "ssm_wissensmanagement.yaml" + +# ============================================================================= +# ZWECK & SCOPE +# ============================================================================= + +zweck: + + definition: | + Problem Management reduziert die Wahrscheinlichkeit und Auswirkungen + von Incidents durch Identifikation der zugrundeliegenden Ursachen, + Entwicklung von Workarounds und Initiierung nachhaltiger Lösungen. + + ziele: + - "Identifikation der Ursachen wiederkehrender oder schwerwiegender Incidents" + - "Bereitstellung von Workarounds zur Reduktion von Incident-Auswirkungen" + - "Dokumentation von Known Errors für schnellere Incident-Bearbeitung" + - "Initiierung permanenter Lösungen über Change Management" + - "Reduktion der Gesamtzahl von Incidents durch Ursachenbeseitigung" + + mvp_scope: + beschreibung: | + Im MVP ist Problem Management auf reaktive Identifikation aus + Incidents beschränkt. Proaktive Problem-Identifikation (Trend-Analyse, + Monitoring-basiert) ist nicht im Scope. + + im_scope: + - "Reaktive Problem-Identifikation aus Incidents" + - "Basis-Root-Cause-Analyse" + - "Workaround-Dokumentation als Known Error" + - "Change-Initiierung für permanente Lösungen" + + nicht_im_scope: + - "Proaktive Problem-Identifikation (LP4.7.1)" + - "Systematische Trend-Analyse" + - "Formale RCA-Methoden (5-Why, Ishikawa) – können genutzt werden, sind aber nicht vorgeschrieben" + - "Separate Known Error Database (KEDB)" + + governance: "SSM-G-19" + + abgrenzung: + + problem_vs_incident: | + Ein Incident ist eine ungeplante Unterbrechung, die schnellstmöglich + behoben werden muss (Symptombehandlung). Ein Problem ist die + zugrundeliegende Ursache eines oder mehrerer Incidents. + + Incident Management: "Wie stelle ich den Service wieder her?" + Problem Management: "Warum ist der Service ausgefallen?" + + problem_vs_change: | + Problem Management identifiziert Ursachen und entwickelt Lösungsvorschläge. + Die Implementierung permanenter Lösungen erfolgt über Change Enablement. + Problem Management initiiert Changes, implementiert sie aber nicht selbst. + + problem_vs_known_error: | + Ein Problem ist eine identifizierte oder vermutete Ursache. + Ein Known Error ist ein Problem, dessen Ursache analysiert wurde + und für das ein dokumentierter Workaround existiert. + +# ============================================================================= +# KERNKONZEPTE +# ============================================================================= + +kernkonzepte: + + # --------------------------------------------------------------------------- + # ROLLENMODELL + # --------------------------------------------------------------------------- + rollenmodell: + + beschreibung: | + Im MVP gibt es keine dedizierte Problem-Manager-Rolle. Die Verantwortung + ist auf bestehende Rollen verteilt, mit dem Service Owner als + Process Owner für Problem Management in seinem Service-Bereich. + + governance: "SSM-G-18" + + begruendung: | + ITIL4 warnt explizit davor, Problem Management als separate Funktion + aufzubauen: "If it is set up as a separate team or group, there is + a danger it will just become a dumping ground for everything the + other support staff find too difficult." + + Im MVP-Kontext von DIGIT ist der Service Owner ohnehin Teil des + operativen Teams und kann die Koordination übernehmen. + + verantwortlichkeiten: + + service_owner: + rolle: "Process Owner Problem Management (für seinen Service)" + aufgaben: + - "Wiederkehrende Muster im Blick behalten" + - "Root-Cause-Analyse koordinieren und ggf. durchführen" + - "Sicherstellen, dass Workarounds dokumentiert werden" + - "Entscheidung über permanente Lösungen (Change)" + - "Problem-Priorisierung und -Überwachung" + - "Problem-Abschluss" + kann_delegieren_an: "Second Level Agents (Experten)" + + second_level_agent: + rolle: "Operative Durchführung" + aufgaben: + - "Problem Record erstellen (bei Erkennung in Incident-Bearbeitung)" + - "Root-Cause-Analyse durchführen (bei Delegation durch SO)" + - "Workaround entwickeln und dokumentieren" + - "Known-Error-Artikel erstellen" + + queue_koordinator: + rolle: "Muster-Erkennung" + aufgaben: + - "Wiederkehrende Incidents in Queues erkennen" + - "Service Owner auf Muster hinweisen" + - "Problem-Record-Erstellung anstoßen (via INC-12)" + + support_manager: + rolle: "Übergreifende Koordination" + aufgaben: + - "Koordination bei Service-übergreifenden Problemen" + - "Eskalation bei Ressourcen-Konflikten" + - "Reporting über Problem-Status" + + # --------------------------------------------------------------------------- + # PROBLEM-IDENTIFIKATION (REAKTIV) + # --------------------------------------------------------------------------- + problem_identifikation: + + beschreibung: | + Im MVP werden Probleme ausschließlich reaktiv aus dem Incident + Management identifiziert. Es gibt zwei definierte Trigger. + + trigger: + + - id: "TRIGGER-01" + name: "Nicht lösbarer Incident" + quelle: "INC-11" + beschreibung: | + Ein Incident kann im L2 nicht gelöst werden, obwohl Diagnose + durchgeführt wurde. Es wird eine strukturelle Ursache vermutet. + kriterien: + - "L2-Diagnose abgeschlossen ohne Lösung" + - "Workaround implementiert, aber Ursache unbekannt" + - "Strukturelle Ursache vermutet" + + - id: "TRIGGER-02" + name: "Wiederkehrende Incidents" + quelle: "INC-12" + beschreibung: | + Mehrere ähnliche Incidents deuten auf ein zugrundeliegendes + Problem hin. + kriterien: + - "≥3 ähnliche Incidents innerhalb von 5 Arbeitstagen" + - "Gemeinsame Symptome oder betroffene Komponente" + - "Queue-Koordinator oder L2 erkennt Muster" + + nicht_im_mvp_scope: + - "Proaktive Identifikation aus Monitoring-Daten" + - "Trend-Analyse über Incident-Statistiken" + - "Supplier- oder Partner-Informationen" + - "Erkenntnisse aus Testing oder Entwicklung" + + # --------------------------------------------------------------------------- + # PRIORISIERUNG + # --------------------------------------------------------------------------- + priorisierung: + + beschreibung: | + Problems werden nicht über eine eigene Prioritäts-Matrix bewertet, + sondern über eine einfache Ableitung aus Service-Kontext und + Incident-Auswirkung. + + modellentscheidung: | + Diese Priorisierungslogik ist ein konzeptioneller Vorschlag für + den MVP. Bei steigender Problem-Anzahl kann eine differenziertere + Matrix erforderlich werden. + + dringlichkeitsstufen: + + - stufe: "HOCH" + kriterien: + - "Service-Kategorie C" + - "ODER >5 verknüpfte Incidents" + - "ODER kein Workaround verfügbar" + erwartung: "Sofortige Bearbeitung, RCA innerhalb 5 AT" + + - stufe: "MITTEL" + kriterien: + - "Service-Kategorie B" + - "UND 3-5 verknüpfte Incidents" + - "UND Workaround vorhanden" + erwartung: "Bearbeitung innerhalb 10 AT" + + - stufe: "NIEDRIG" + kriterien: + - "Service-Kategorie A" + - "ODER <3 verknüpfte Incidents" + - "UND Workaround vorhanden" + erwartung: "Bearbeitung nach Kapazität" + + hinweis: | + Die Dringlichkeit kann vom Service Owner bei Bedarf angepasst + werden (z.B. bei politischer Relevanz oder Außenwirkung). + + # --------------------------------------------------------------------------- + # KNOWN ERROR KONZEPT + # --------------------------------------------------------------------------- + known_error: + + beschreibung: | + Ein Known Error ist ein Problem, dessen Ursache analysiert wurde + (auch wenn nicht vollständig verstanden) und für das ein + dokumentierter Workaround existiert. + + governance: "SSM-G-20" + + dokumentation: + beschreibung: | + Known Errors werden nicht in einer separaten KEDB geführt, + sondern als KB-Artikel mit speziellem Typ in der bestehenden + Wissensdatenbank dokumentiert. + + kb_integration: + artikel_typ: "KNOWN_ERROR" + kb_ebene: "Ebene 2 (Arbeitsdokumentation)" + referenz: "ssm_wissensmanagement.yaml" + + pflichtfelder: + - feld: "symptome" + beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?" + - feld: "workaround" + beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?" + - feld: "root_cause" + beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)" + - feld: "problem_referenz" + beschreibung: "Verknüpfung zum Problem Record" + - feld: "status" + beschreibung: "AKTIV oder OBSOLET" + werte: ["AKTIV", "OBSOLET"] + + optionale_felder: + - feld: "permanente_loesung" + beschreibung: "Geplante Lösung, wenn bekannt" + - feld: "change_referenz" + beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit" + - feld: "betroffene_services" + beschreibung: "Liste der betroffenen Services" + + lebenszyklus: + - "Problem wird als KNOWN_ERROR markiert, wenn Workaround dokumentiert" + - "Known-Error-Artikel wird erstellt/aktualisiert" + - "Bei Incident-Bearbeitung: KB-Suche findet Known Error" + - "Agent wendet Workaround an" + - "Nach permanenter Lösung: Artikel-Status auf OBSOLET" + +# ============================================================================= +# PROZESS-AKTIVITÄTEN +# ============================================================================= + +aktivitaeten_uebersicht: | + Problem Management im MVP besteht aus 4 Kernaktivitäten. + Der Prozess ist schlank gehalten und fokussiert auf die + wesentlichen Schritte von Erfassung bis Schließung. + +aktivitaeten: + + # --------------------------------------------------------------------------- + # PRB-01: PROBLEM ERFASSEN + # --------------------------------------------------------------------------- + - id: "PRB-01" + name: "Problem erfassen" + phase: "Identifikation" + blueprint_referenz: "ss_09, ss_10" + yasm_referenz: "LP4.7.2" + + beschreibung: | + Erstellung eines Problem Records basierend auf einem der + definierten Trigger. Dokumentation der Symptome und + Verknüpfung mit auslösenden Incidents. + + trigger: + - "INC-11: Nicht lösbarer Incident" + - "INC-12: Wiederkehrende Incidents identifiziert" + + aktivitaeten: + - "Problem Record im ITSM-Tool erstellen" + - "Symptome und Auswirkungen dokumentieren" + - "Auslösende Incidents verknüpfen" + - "Betroffenen Service identifizieren" + - "Service-Kategorie übernehmen" + - "Erste Hypothese zur Ursache (wenn vorhanden)" + - "Dringlichkeit ableiten" + - "Service Owner informieren" + + problem_record_felder: + pflicht: + - "problem_id (automatisch)" + - "titel" + - "symptom_beschreibung" + - "betroffener_service" + - "service_kategorie" + - "verknuepfte_incidents (mindestens 1)" + - "erstellt_von" + - "erstellt_am" + - "status (NEU)" + - "dringlichkeit" + optional: + - "erste_hypothese" + - "bekannter_workaround" + - "betroffene_komponente" + + output: + - "Problem Record mit Status NEU" + - "Verknüpfung zu auslösenden Incidents" + - "Service Owner informiert" + + raci: + r: "Second Level Agent" + a: "Service Owner" + c: "Queue-Koordinator" + i: "-" + + # --------------------------------------------------------------------------- + # PRB-02: PROBLEM ANALYSIEREN + # --------------------------------------------------------------------------- + - id: "PRB-02" + name: "Problem analysieren (Root-Cause-Analyse)" + phase: "Analyse" + blueprint_referenz: "ss_11" + yasm_referenz: "LP4.7.3" + + beschreibung: | + Durchführung einer Root-Cause-Analyse zur Identifikation der + zugrundeliegenden Ursache. Entwicklung eines Workarounds, + wenn keine sofortige Lösung möglich ist. + + vorbedingung: "Problem Record mit Status NEU" + + aktivitaeten: + - "Status auf IN_ANALYSE setzen" + - "Verfügbare Informationen sammeln und sichten" + - "Verknüpfte Incidents analysieren (Gemeinsamkeiten)" + - "Hypothesen zur Ursache entwickeln" + - "Hypothesen systematisch prüfen" + - "Root Cause identifizieren oder eingrenzen" + - "Workaround entwickeln (wenn Ursache nicht sofort behebbar)" + - "Ergebnisse dokumentieren" + + rca_methoden: + beschreibung: | + Im MVP sind keine formalen RCA-Methoden vorgeschrieben. + Folgende Ansätze können bei Bedarf genutzt werden: + optionale_methoden: + - "5-Why-Analyse" + - "Ishikawa-Diagramm (Fishbone)" + - "Timeline-Analyse" + - "Vergleichsanalyse (funktionierend vs. nicht funktionierend)" + hinweis: "Pragmatisches Vorgehen ist im MVP ausreichend." + + ergebnis_varianten: + + root_cause_gefunden: + beschreibung: "Ursache wurde identifiziert" + naechster_schritt: + workaround_reicht: "→ Status KNOWN_ERROR, KB-Artikel erstellen" + permanente_loesung_noetig: "→ PRB-03 (Lösung initiieren)" + + root_cause_nicht_gefunden: + beschreibung: "Ursache konnte nicht eindeutig identifiziert werden" + naechster_schritt: + workaround_vorhanden: "→ Status KNOWN_ERROR, weiter beobachten" + kein_workaround: "→ Problem bleibt IN_ANALYSE, Eskalation prüfen" + + workaround_dokumentation: + beschreibung: | + Wenn ein Workaround entwickelt wurde, muss dieser als + Known-Error-Artikel dokumentiert werden. + verantwortlich: "Second Level Agent" + freigabe: "Service Owner" + referenz: "kernkonzepte.known_error" + + output: + - "Dokumentierte Analyseergebnisse" + - "Root Cause (wenn identifiziert)" + - "Workaround (wenn entwickelt)" + - "Known-Error-Artikel (wenn Workaround dokumentiert)" + - "Empfehlung für weiteres Vorgehen" + + raci: + r: "Second Level Agent / Service Owner" + a: "Service Owner" + c: "Lieferant (bei externen Komponenten)" + i: "Support Manager" + + # --------------------------------------------------------------------------- + # PRB-03: LÖSUNG INITIIEREN + # --------------------------------------------------------------------------- + - id: "PRB-03" + name: "Lösung initiieren" + phase: "Lösung" + blueprint_referenz: "ss_11" + yasm_referenz: "LP4.7.3, LP4.7.4" + + beschreibung: | + Initiierung einer permanenten Lösung, wenn ein Workaround + nicht ausreicht oder die Ursache nachhaltig beseitigt werden soll. + Die Implementierung erfolgt über Change Enablement. + + vorbedingung: | + - Root Cause identifiziert oder eingegrenzt + - Entscheidung: Permanente Lösung erforderlich/wirtschaftlich sinnvoll + + entscheidungskriterien: + beschreibung: | + Der Service Owner entscheidet, ob eine permanente Lösung + angestrebt wird. Kriterien: + kriterien: + - "Workaround ist aufwändig oder fehleranfällig" + - "Incident-Häufigkeit rechtfertigt Investition" + - "Risiko bei Fortbestehen des Problems" + - "Kosten-Nutzen-Verhältnis einer permanenten Lösung" + hinweis: | + Nicht jedes Problem muss permanent gelöst werden. Ein stabiler + Workaround kann eine akzeptable Dauerlösung sein. + + aktivitaeten: + - "Lösungsoptionen bewerten" + - "Kosten-Nutzen-Abschätzung (informell)" + - "Entscheidung: Change oder alternative Maßnahme" + - "Bei Change: Change Request erstellen" + - "Problem Record mit Change verknüpfen" + - "Status auf WARTEN_CHANGE setzen" + - "Problem-Überwachung während Change-Implementierung" + + change_initiierung: + beschreibung: | + Die meisten permanenten Lösungen erfordern einen Change. + Problem Management erstellt den Change Request, die + Implementierung erfolgt über Change Enablement. + change_request_inhalt: + - "Verweis auf Problem Record" + - "Beschreibung der Ursache" + - "Vorgeschlagene Lösung" + - "Erwarteter Nutzen (reduzierte Incidents)" + schnittstelle: "practice_change-enablement.yaml (Platzhalter)" + + alternative_massnahmen: + beschreibung: | + Nicht alle Lösungen erfordern einen formalen Change. + beispiele: + - "Konfigurationsanpassung im Standard-Scope" + - "Schulung/Kommunikation an Nutzer" + - "Prozessanpassung" + - "Lieferanten-Eskalation" + + output: + - "Entscheidung dokumentiert" + - "Change Request (wenn erforderlich)" + - "Problem Record Status WARTEN_CHANGE oder KNOWN_ERROR" + + raci: + r: "Service Owner" + a: "Service Owner" + c: "Support Manager" + i: "Second Level Agent" + + # --------------------------------------------------------------------------- + # PRB-04: PROBLEM SCHLIESSEN + # --------------------------------------------------------------------------- + - id: "PRB-04" + name: "Problem schließen" + phase: "Abschluss" + yasm_referenz: "LP4.7.5" + + beschreibung: | + Abschluss des Problem Records nach erfolgreicher Lösung + oder bewusster Entscheidung, das Problem nicht weiter zu verfolgen. + + schliessungsgruende: + + loesung_implementiert: + beschreibung: "Permanente Lösung wurde via Change implementiert" + aktivitaeten: + - "Validieren: Lösung wirksam? (keine neuen Incidents)" + - "Known-Error-Artikel auf OBSOLET setzen" + - "Verknüpfte Incidents prüfen" + - "Problem Record auf GESCHLOSSEN setzen" + - "Abschlussdokumentation" + + workaround_akzeptiert: + beschreibung: "Workaround ist Dauerlösung, keine weitere Aktion geplant" + aktivitaeten: + - "Entscheidung dokumentieren (warum keine permanente Lösung)" + - "Known-Error-Artikel bleibt AKTIV" + - "Problem Record auf GESCHLOSSEN setzen" + - "Hinweis: Bei Änderung der Situation kann neu bewertet werden" + + duplikat_oder_ungueltig: + beschreibung: "Problem ist Duplikat oder war kein echtes Problem" + aktivitaeten: + - "Begründung dokumentieren" + - "Ggf. mit anderem Problem Record verknüpfen" + - "Problem Record auf GESCHLOSSEN setzen" + + validierung_bei_loesung: + beschreibung: | + Nach Implementierung einer permanenten Lösung muss validiert + werden, dass das Problem tatsächlich behoben ist. + methoden: + - "Monitoring der Incident-Rate für betroffenen Service" + - "Beobachtungszeitraum (empfohlen: 2-4 Wochen)" + - "Rückmeldung von L1/L2 zur Incident-Entwicklung" + bei_misserfolg: "Zurück zu IN_ANALYSE" + + output: + - "Problem Record mit Status GESCHLOSSEN" + - "Abschlussdokumentation" + - "Known-Error-Artikel aktualisiert (OBSOLET wenn gelöst)" + - "Lessons Learned (optional)" + + raci: + r: "Service Owner" + a: "Service Owner" + c: "-" + i: "Support Manager" + +# ============================================================================= +# STATUS-LIFECYCLE +# ============================================================================= + +status_lifecycle: + + beschreibung: | + Vereinfachtes Status-Modell für Problem Records im MVP. + Analog zum Ticket-Schema, aber auf Problem-Spezifika angepasst. + + status_werte: + + - id: "NEU" + name: "Neu" + beschreibung: "Problem Record erstellt, noch nicht in Analyse" + + - id: "IN_ANALYSE" + name: "In Analyse" + beschreibung: "Root-Cause-Analyse läuft" + + - id: "KNOWN_ERROR" + name: "Known Error" + beschreibung: | + Ursache bekannt oder eingegrenzt, Workaround dokumentiert. + Keine permanente Lösung geplant oder in Bewertung. + + - id: "WARTEN_CHANGE" + name: "Warten auf Change" + beschreibung: "Permanente Lösung via Change in Arbeit" + + - id: "GELOEST" + name: "Gelöst" + beschreibung: "Lösung implementiert, Validierung läuft" + + - id: "GESCHLOSSEN" + name: "Geschlossen" + beschreibung: "Problem final abgeschlossen" + + transitionen: + + - von: "NEU" + nach: ["IN_ANALYSE", "GESCHLOSSEN"] + beschreibung: "Analyse starten oder als Duplikat/ungültig schließen" + + - von: "IN_ANALYSE" + nach: ["KNOWN_ERROR", "WARTEN_CHANGE", "GESCHLOSSEN"] + beschreibung: "Analyse abgeschlossen mit verschiedenen Ergebnissen" + + - von: "KNOWN_ERROR" + nach: ["WARTEN_CHANGE", "IN_ANALYSE", "GESCHLOSSEN"] + beschreibung: "Change initiieren, neu analysieren oder akzeptieren" + + - von: "WARTEN_CHANGE" + nach: ["GELOEST", "IN_ANALYSE"] + beschreibung: "Change erfolgreich oder gescheitert" + + - von: "GELOEST" + nach: ["GESCHLOSSEN", "IN_ANALYSE"] + beschreibung: "Validierung erfolgreich oder Problem tritt erneut auf" + + - von: "GESCHLOSSEN" + nach: ["IN_ANALYSE"] + beschreibung: "Wiedereröffnung bei erneutem Auftreten" + bedingung: "Nur mit Begründung durch Service Owner" + +# ============================================================================= +# RACI-REFERENZ +# ============================================================================= + +raci_referenz: + + beschreibung: | + Die verbindliche RACI-Matrix für Problem Management ist in + ssm_governance.yaml → raci_konsolidiert.problem_management definiert. + + Diese Kurzübersicht dient der schnellen Orientierung. + + master_dokument: "ssm_governance.yaml" + abschnitt: "raci_konsolidiert.problem_management" + + hinweis_service_owner: | + Der Service Owner ist Process Owner für Problem Management (SSM-G-18). + Er kann operative Tätigkeiten (R) an Second Level Agents delegieren, + bleibt aber immer Accountable (A). + + kurzuebersicht: + # L2 QK SM SO + problem_erfassen: "R C - A" + problem_analysieren: "R - I A/R" + loesung_initiieren: "I - C A/R" + problem_schliessen: "- - I A/R" + known_error_erstellen: "R - - A" + muster_erkennen: "C R - A" + + hinweis: "L1 ist im Problem Management nicht direkt beteiligt" + +# ============================================================================= +# KENNZAHLEN +# ============================================================================= + +kennzahlen: + + beschreibung: | + Basis-KPIs für Problem Management im MVP. Fokus auf Wirksamkeit, + nicht auf Prozess-Compliance. + + kpis: + + - id: "KPI-PRB-01" + name: "Anzahl offener Probleme" + beschreibung: "Aktuelle Anzahl nicht geschlossener Problem Records" + messung: "Stichtag" + ziel: "Kein festes Ziel, Trend beobachten" + + - id: "KPI-PRB-02" + name: "Problem-Lösungsrate" + beschreibung: "Anteil der Probleme mit permanenter Lösung (nicht nur Workaround)" + formel: "(Probleme mit Lösung) / (Geschlossene Probleme) × 100" + ziel: "tbd" + hinweis: "Nicht jedes Problem muss permanent gelöst werden" + + - id: "KPI-PRB-03" + name: "Known Errors mit aktivem Workaround" + beschreibung: "Anzahl dokumentierter Known Errors" + messung: "Stichtag" + ziel: "Kein festes Ziel – zeigt Reife des Prozesses" + + - id: "KPI-PRB-04" + name: "Incident-Reduktion nach Problem-Lösung" + beschreibung: "Reduktion der Incidents nach Implementierung einer Lösung" + messung: "Vergleich Incident-Rate vor/nach Lösung" + ziel: ">50% Reduktion" + hinweis: "Nur messbar bei ausreichender Datenbasis" + + todo: | + - Zielwerte mit DIGIT abstimmen + - Reporting-Frequenz festlegen (empfohlen: monatlich) + - Baseline nach 3 Monaten Betrieb etablieren + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + + - modul: "sub-practice_incident-management.yaml" + art: "erhält von" + beschreibung: "Problem Records aus INC-11 und INC-12" + aktivitaeten: ["INC-11", "INC-12"] + + - modul: "ssm_wissensmanagement.yaml" + art: "liefert an" + beschreibung: "Known-Error-Artikel (Ebene 2)" + artikel_typ: "KNOWN_ERROR" + + - modul: "ssm_schema_ticket.yaml" + art: "implementiert" + beschreibung: "Problem Record Datenstruktur (analog zu Ticket)" + + - modul: "spm_practice_service-level-management.yaml" + art: "referenziert" + beschreibung: "Service-Kategorien für Priorisierung" + + - modul: "sub-practice_service-desk.yaml" + art: "erhält von" + beschreibung: "Problem Records werden oft durch Service Desk (via L2) erstellt" + + - modul: "ssm_governance.yaml" + art: "wird gesteuert durch" + beschreibung: "Reporting-Struktur, Service Owner Reviews" + + extern: + + - partner: "Change Enablement" + kontext: "Initiierung permanenter Lösungen via Change" + status: "Schnittstelle zu P-03 (Platzhalter)" + aktivitaet: "PRB-03" + + - partner: "ITSM-Tool" + kontext: "Problem Record Lifecycle" + status: "Tool-Auswahl ausstehend" + + - partner: "Lieferanten" + kontext: "RCA-Unterstützung bei externen Komponenten" + status: "Fallweise" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance: + + beschreibung: | + Governance-Entscheidungen für Problem Management. + Zur Übertragung ins zentrale Log. + + entscheidungen: + + - id: "SSM-G-18" + name: "Keine dedizierte Problem-Manager-Rolle" + entscheidung: | + Im MVP gibt es keine dedizierte Problem-Manager-Rolle. + Der Service Owner ist Process Owner für Problem Management + in seinem Service-Bereich. Operative Tätigkeiten können an + Second Level Agents delegiert werden. + begruendung: | + Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs- + strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung + für die Service-Qualität. ITIL4 warnt explizit davor, Problem + Management als separate Funktion aufzubauen. + status: "vorgeschlagen" + + - id: "SSM-G-19" + name: "Problem Management nur reaktiv im MVP" + entscheidung: | + Problem-Identifikation erfolgt im MVP ausschließlich reaktiv + aus dem Incident Management (nicht lösbare oder wiederkehrende + Incidents). Proaktive Problem-Identifikation (LP4.7.1) ist + nicht im Scope. + begruendung: | + MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt + die Datenbasis (Incident-Trends, Monitoring-Integration). + Kann in späteren Ausbaustufen ergänzt werden. + status: "vorgeschlagen" + + - id: "SSM-G-20" + name: "Known Errors als KB-Artikel" + entscheidung: | + Known Errors werden als KB-Artikel mit speziellem Typ + (KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert. + Es wird keine separate Known Error Database (KEDB) geführt. + begruendung: | + Integration in bestehendes Wissensmanagement, vermeidet + Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen + ohnehin in der KB – Known Errors werden so automatisch gefunden. + status: "vorgeschlagen" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-PRB-001" + thema: "Problem Record Schema" + beschreibung: | + Das Problem Record Schema muss analog zum Ticket Schema + definiert werden. Kann als Erweiterung von ssm_schema_ticket.yaml + oder als eigenes Schema erfolgen. + prioritaet: "mittel" + status: "Entscheidung ausstehend" + + - id: "OPEN-PRB-002" + thema: "Change-Schnittstelle" + beschreibung: | + Detaillierte Schnittstelle zu Change Enablement (P-03) definieren, + sobald dieses Modul entwickelt ist. + prioritaet: "mittel" + status: "Abhängig von P-03 Entwicklung" + abhaengig_von: "practice_change-enablement.yaml" + + - id: "OPEN-PRB-003" + thema: "Known-Error-Artikel-Template" + beschreibung: | + Template für Known-Error-Artikel in der KB erstellen und + in ssm_wissensmanagement.yaml integrieren. + prioritaet: "hoch" + status: "Bei KB-Implementierung" + + - id: "OPEN-PRB-004" + thema: "Problem-Incident-Verknüpfung im Tool" + beschreibung: | + Technische Umsetzung der Verknüpfung zwischen Problem Records + und Incidents im ITSM-Tool. + prioritaet: "hoch" + status: "Tool-Auswahl ausstehend" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung als MVP-Version" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_request-management.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_request-management.yaml index 2297657..54d6313 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_request-management.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_request-management.yaml @@ -1,1246 +1,1246 @@ -# ============================================================================= -# SUB-PRACTICE: REQUEST MANAGEMENT -# ============================================================================= - -metadata: - id: "P-05" - name: "Request Management" - version: "0.1" - status: "draft" - erstellt: "2025-12-07" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - parent_practice: "practice_service-support-management" - - itil4_referenz: "Service Request Management Practice" - yasm_referenz: "LP4.6.2, LP4.6.3, LP4.6.6, LP4.6.7" - - blueprint_referenz: "service-lifecycle_service-support.yaml" - relevante_aktivitaeten: ["ss_03", "ss_04", "ss_09", "ss_10"] - - design_referenz: "ssm_design-zieldimensionen.yaml" - relevante_saeulen: ["LS-04", "LS-05"] - - schema_referenz: "ssm_schema_ticket.yaml" - klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml" - rollen_referenz: "ssm_rollen.yaml" - wissensmanagement_referenz: "ssm_wissensmanagement.yaml" - -# ============================================================================= -# ZWECK & SCOPE -# ============================================================================= - -zweck: - - definition: | - Request Management steuert die Erfassung, Genehmigung und Erfüllung - von Service-Anfragen. Es stellt sicher, dass Nutzer definierte - Leistungen aus dem Service-Katalog effizient und nachvollziehbar - erhalten. - - ziele: - - "Effiziente Erfüllung von Service-Anfragen" - - "Transparenter Genehmigungsprozess" - - "Einhaltung definierter Fulfillment-Zeiten" - - "Nachvollziehbare Dokumentation aller Requests" - - "Klare Abgrenzung zu Incidents und Demands" - - abgrenzung: - - request_vs_incident: | - Ein Request ist eine formelle Anfrage für eine definierte Leistung - aus dem Service-Katalog. Es liegt keine Störung vor. - Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung. - Siehe: ssm_klassifikation-priorisierung.yaml → ticket_typen - - request_vs_demand: | - Ein Request bezieht sich auf eine Leistung, die im Service-Katalog - definiert ist. Anfragen für nicht-katalogisierte Leistungen sind - Demands und werden über das Demand-Portfolio-Management (DPM) - bearbeitet. - - ENTSCHEIDUNGSREGEL: - - Im Service-Katalog → Request (P-05) - - Nicht im Service-Katalog → Demand (DPM) - - Governance: SSM-G-14 - - request_vs_change: | - Wenn die Request-Erfüllung eine Änderung an der IT-Infrastruktur - erfordert, die über Standard-Fulfillment hinausgeht, wird ein - Change angestoßen. Der Request bleibt offen (Status WARTEN_CHANGE) - bis der Change implementiert ist. - -# ============================================================================= -# KERNKONZEPTE -# ============================================================================= - -kernkonzepte: - - # --------------------------------------------------------------------------- - # KATALOG-PRINZIP - # --------------------------------------------------------------------------- - katalog_prinzip: - - beschreibung: | - Request Management ist katalogbasiert. Nur Leistungen, die im - Service-Katalog definiert sind, können als Request bearbeitet werden. - Der Service-Katalog ist die "Single Source of Truth" für bestellbare - Leistungen. - - governance: "SSM-G-14" - - konsequenzen: - - "Keine Ad-hoc-Requests für nicht-katalogisierte Leistungen" - - "Katalog-Pflege ist Voraussetzung für effizientes Request Management" - - "Nicht-Katalog-Anfragen werden in DPM-Prozess überführt" - - katalog_struktur: - beschreibung: | - Der Request-Katalog ist Teil des Service-Katalogs (keine separate - Struktur). Jeder Service definiert seine bestellbaren Leistungen. - - referenz: "spm_practice_service-catalog-management.yaml" - - je_katalog_eintrag: - - "Eindeutige ID (request_katalog_id)" - - "Name und Beschreibung" - - "Zugehöriger Service" - - "Genehmigungsanforderung" - - "Genehmiger-Definition" - - "Fulfillment-Pfad" - - "Standard-Fulfillment-Zeit" - - "Kostenrelevanz" - - hinweis: | - Die Service-Kategorie (A/B/C) ist KEIN Attribut des Katalog-Eintrags, - sondern wird vom zugehörigen Service geerbt. - - offener_punkt: "OPEN-REQ-001" - - # --------------------------------------------------------------------------- - # SERVICE-KATEGORIE-GOVERNANCE - # --------------------------------------------------------------------------- - service_kategorie_governance: - - beschreibung: | - Die Service-Kategorie (A/B/C aus SLM/SCM) bestimmt die - Governance-Anforderungen für Requests. Dies ersetzt die - klassische Unterscheidung "Standard vs. Non-Standard". - - vererbung: - beschreibung: | - Die Service-Kategorie ist ein Attribut des Services - (definiert in SLM). Der Katalog-Eintrag erbt die Kategorie - vom zugehörigen Service. Ein Katalog-Eintrag kann keine - abweichende Kategorie haben. - - referenz: "spm_practice_service-level-management.yaml → service_kategorien" - - kategorien: - - - kategorie: "A" - name: "Basis-Services" - request_charakteristik: | - Automatische Bereitstellung bei Eintritt (z.B. Onboarding). - Wenige aktive Requests, da Services "einfach da sind". - typische_requests: - - "Passwort zurücksetzen" - - "Informationsanfrage" - genehmigung: "Meist keine" - typischer_pool: "Sofort-Pool / Standard-Pool" - - - kategorie: "B" - name: "Erweiterte Services" - request_charakteristik: | - Beantragung erforderlich. Definierter Fulfillment-Prozess. - Genehmigung je nach Katalog-Eintrag. - typische_requests: - - "Software-Installation (aus Liste)" - - "Berechtigung für Fachverfahren" - - "Hardware-Zubehör" - genehmigung: "Je nach Katalog-Eintrag definiert" - typischer_pool: "Standard-Pool" - - - kategorie: "C" - name: "Spezial-Services" - request_charakteristik: | - Individuelle Abstimmung erforderlich. Oft mehrstufige - Genehmigung. Möglicherweise Kosten für das Amt. - typische_requests: - - "Spezial-Software (nicht in Standard-Liste)" - - "Spezial-Hardware" - - "Erweiterter Speicherplatz" - genehmigung: "Immer erforderlich (oft mehrstufig)" - typischer_pool: "Analyse-Pool" - - # --------------------------------------------------------------------------- - # GENEHMIGUNGSPRINZIPIEN - # --------------------------------------------------------------------------- - genehmigungsprinzipien: - - beschreibung: | - Die Genehmigungslogik wird je Katalog-Eintrag definiert. - Dieses Dokument definiert die Prinzipien, nicht die konkreten - Workflows. - - modellentscheidung: | - HINWEIS: Die folgenden Genehmigungsprinzipien sind konzeptionelle - Vorschläge und müssen in der Implementierung validiert und ggf. - angepasst werden. Die konkreten Workflows sind tool-abhängig. - - governance: "SSM-G-15, SSM-G-16" - - prinzipien: - - - prinzip: "Genehmiger je Katalog-Eintrag" - beschreibung: | - Jeder Katalog-Eintrag definiert, wer Genehmiger ist. - Dies ermöglicht Flexibilität für unterschiedliche Anforderungen. - governance: "SSM-G-15" - - - prinzip: "Mehrstufige Genehmigung bei Bedarf" - beschreibung: | - Bei Kosten- oder Sicherheitsrelevanz kann eine mehrstufige - Genehmigung erforderlich sein (z.B. Vorgesetzter + IT-Sicherheit). - governance: "SSM-G-16" - kriterien_mehrstufig: - - "Kosten über definierter Schwelle" - - "Sicherheitsrelevante Berechtigungen" - - "Zugriff auf sensible Daten" - - "Externe Lizenzen/Verträge" - - - prinzip: "Automatische Genehmigung möglich" - beschreibung: | - Für risikoarme, häufige Requests kann eine automatische - Genehmigung konfiguriert werden (z.B. Passwort-Reset). - - genehmiger_typen: - beschreibung: "Mögliche Genehmiger-Rollen" - typen: - - typ: "Fachvorgesetzter" - anwendung: "Standard für personenbezogene Requests" - - typ: "Kostenstellenverantwortlicher" - anwendung: "Bei kostenrelevanten Requests" - - typ: "Service Owner" - anwendung: "Bei Spezial-Services (Kategorie C)" - - typ: "IT-Sicherheit" - anwendung: "Bei sicherheitsrelevanten Berechtigungen" - - typ: "Automatisch" - anwendung: "Bei vordefinierten, risikoarmen Requests" - - # --------------------------------------------------------------------------- - # FULFILLMENT-VARIANTEN - # --------------------------------------------------------------------------- - fulfillment_varianten: - - beschreibung: | - Requests können auf unterschiedlichen Wegen erfüllt werden. - Der Fulfillment-Pfad wird je Katalog-Eintrag definiert. - - modellentscheidung: | - HINWEIS: Die folgenden Fulfillment-Varianten sind konzeptionelle - Vorschläge. Die tatsächlichen Pfade hängen von Tool-Landschaft, - Automatisierungsgrad und Organisationsstruktur ab. - - varianten: - - - id: "FULFILL-AUTO" - name: "Automatische Erfüllung" - beschreibung: | - Request wird ohne manuelle Bearbeitung erfüllt - (z.B. Self-Service-Portal, automatisierte Workflows). - beispiele: - - "Passwort-Reset (Self-Service)" - - "Standard-Software-Installation (Software-Center)" - - "Gruppenmitgliedschaft (automatisiert)" - bearbeitung: "System" - typische_fulfillment_zeit: "Sofort bis wenige Minuten" - - - id: "FULFILL-L1" - name: "L1 Direkterfüllung" - beschreibung: | - Request wird direkt durch First Level Agent erfüllt. - Keine Spezialkenntnisse erforderlich. - beispiele: - - "Berechtigung setzen (manuell)" - - "Account entsperren" - - "Informationsanfrage beantworten" - bearbeitung: "First Level Agent" - typische_fulfillment_zeit: "< 1 Arbeitstag" - - - id: "FULFILL-L2" - name: "L2 Spezialist" - beschreibung: | - Request erfordert Spezialkenntnisse oder erweiterte - Berechtigungen und wird an L2 übergeben. - beispiele: - - "Komplexe Software-Installation" - - "Spezial-Konfiguration" - - "Datenbank-Berechtigung" - bearbeitung: "Second Level Agent" - typische_fulfillment_zeit: "1-5 Arbeitstage" - - - id: "FULFILL-BESCHAFFUNG" - name: "Beschaffung" - beschreibung: | - Request erfordert externe Beschaffung (Hardware, Lizenzen). - Fulfillment nach Wareneingang. - beispiele: - - "Hardware-Bestellung" - - "Lizenz-Beschaffung" - - "Externer Service" - bearbeitung: "Beschaffungsprozess + Übergabe an IT" - typische_fulfillment_zeit: "Variabel (Beschaffungszeit)" - status_waehrend: "WARTEN_EXTERN" - - - id: "FULFILL-CHANGE" - name: "Via Change" - beschreibung: | - Request-Erfüllung erfordert Infrastruktur-Änderung, - die über Change Enablement gesteuert wird. - beispiele: - - "Neuer Server-Zugang" - - "Firewall-Regel" - - "Systemanpassung" - bearbeitung: "Change Enablement Prozess" - typische_fulfillment_zeit: "Abhängig von Change-Typ" - status_waehrend: "WARTEN_CHANGE" - - entscheidungsbaum: - beschreibung: | - Logik zur Bestimmung des Fulfillment-Pfads. - Wird idealerweise im Katalog-Eintrag vordefiniert. - - schritte: - - frage: "Ist automatische Erfüllung möglich?" - wenn_ja: "→ FULFILL-AUTO" - wenn_nein: "Weiter" - - - frage: "Liegt die Erfüllung im L1-Scope (dokumentiert, keine Spezialrechte)?" - wenn_ja: "→ FULFILL-L1" - wenn_nein: "Weiter" - - - frage: "Ist externe Beschaffung erforderlich?" - wenn_ja: "→ FULFILL-BESCHAFFUNG" - wenn_nein: "Weiter" - - - frage: "Ist eine Infrastruktur-Änderung erforderlich?" - wenn_ja: "→ FULFILL-CHANGE" - wenn_nein: "→ FULFILL-L2" - - # --------------------------------------------------------------------------- - # KOSTEN-HANDLING - # --------------------------------------------------------------------------- - kosten_handling: - - beschreibung: | - Manche Requests verursachen Kosten für das anfragende Amt. - Die Kostenfreigabe ist Teil der normalen Genehmigung. - - governance: "SSM-G-16" - - modellentscheidung: | - HINWEIS: Das Kosten-Handling ist ein konzeptioneller Vorschlag. - Konkrete Kostenschwellen und Freigabeprozesse müssen in der - Implementierung mit Finanzprozessen abgestimmt werden. - - prinzipien: - - "Kostenrelevanz wird im Katalog-Eintrag definiert" - - "Kosten werden vor Erfüllung transparent kommuniziert" - - "Kostenfreigabe ist Teil der Genehmigung (kein separater Schritt)" - - "Bei Kosten über Schwelle: mehrstufige Genehmigung" - - typische_kosten_requests: - - "Hardware-Beschaffung" - - "Spezial-Software / Lizenzen" - - "Erweiterte Services (Kategorie C)" - - "Externe Dienstleistungen" - - # --------------------------------------------------------------------------- - # SELF-SERVICE - # --------------------------------------------------------------------------- - self_service: - - beschreibung: | - Bestimmte Requests können von Nutzern selbst über ein - Self-Service-Portal ausgelöst werden. - - modellentscheidung: | - HINWEIS: Der Self-Service-Scope ist stark von Tool-Landschaft - und organisatorischem Reifegrad abhängig. Die folgenden - Aussagen sind Platzhalter und müssen in der Implementierung - konkretisiert werden. - - status: "PLATZHALTER" - - konzept: - beschreibung: | - Self-Service reduziert Aufwand für Service Desk und erhöht - Nutzer-Autonomie. Erfordert aber geeignete Tool-Unterstützung - und Nutzer-Akzeptanz. - - typische_self_service_requests: - - "Passwort-Reset" - - "Standard-Software aus Katalog" - - "Informations-Anfragen (FAQ/KB)" - - "Einfache Berechtigungsanfragen" - - voraussetzungen: - - "Self-Service-Portal / ITSM-Tool-Unterstützung" - - "Integrierte Genehmigungsworkflows" - - "Nutzer-Schulung und Kommunikation" - - "KB/FAQ für häufige Fragen" - - offener_punkt: "OPEN-REQ-002" - -# ============================================================================= -# PROZESS-AKTIVITÄTEN -# ============================================================================= - -aktivitaeten_uebersicht: | - Der Request-Prozess besteht aus 6 Kernaktivitäten. - Die Aktivitäten REQ-04 (Genehmigung) und REQ-05 (Fulfillment) - haben je nach Request-Typ unterschiedliche Ausprägungen. - -aktivitaeten: - - # --------------------------------------------------------------------------- - # REQ-01: REQUEST ERFASSEN - # --------------------------------------------------------------------------- - - id: "REQ-01" - name: "Request erfassen und Katalog prüfen" - phase: "Erfassung" - blueprint_referenz: "ss_03" - - beschreibung: | - Aufnahme der Anfrage über verfügbare Kanäle. Zentrale Prüfung: - Ist die Anfrage im Service-Katalog abgebildet? Diese Prüfung - entscheidet über den weiteren Prozess. - - trigger: - - kanal: "Telefon" - erfassung: "Agent erfasst in ITSM-Tool" - - kanal: "E-Mail" - erfassung: "Agent erfasst in ITSM-Tool" - - kanal: "Self-Service-Portal" - erfassung: "Nutzer erfasst selbst" - - kanal: "Persönlich" - erfassung: "Agent erfasst in ITSM-Tool" - - aktivitaeten: - - "Melder identifizieren" - - "Anfrage aufnehmen" - - "Katalog-Prüfung durchführen" - - "Entscheidung: Request oder Demand?" - - # ------------------------------------------------------------------------- - # VARIANTEN BASIEREND AUF KATALOG-PRÜFUNG - # ------------------------------------------------------------------------- - varianten: - - katalog_treffer: - beschreibung: "Anfrage ist im Service-Katalog → weiter als Request" - aktivitaeten: - - "Request-Typ bestimmen" - - "Katalog-Eintrag zuordnen" - - "Service-Kategorie ermitteln (vom Service geerbt)" - - "Relevante Felder befüllen" - - "Wunschtermin erfassen (wenn angegeben)" - - "DoR-Prüfung durchführen" - output: - - "Request-Ticket mit Status NEU" - - "Katalog-Referenz zugeordnet" - weiter_mit: "REQ-02" - - kein_katalog_treffer: - beschreibung: "Anfrage nicht im Katalog → Demand-Prozess" - governance: "SSM-G-14" - aktivitaeten: - - "Melder informieren: Leistung nicht im Katalog verfügbar" - - "Optionen aufzeigen: Demand über Stakeholder-Management einbringen" - - "Kontakt zu SHM vermitteln oder Demand-Meldung unterstützen" - - "Request-Ticket stornieren mit Begründung und Verweis auf Demand" - output: - - "Request-Ticket mit Status STORNIERT" - - "Stornierungsgrund: Nicht im Katalog" - - "Ggf. Verweis auf erstellte Demand-Meldung" - handoff: - ziel: "Demand-Portfolio-Management (DPM)" - via: "Stakeholder-Management (SHM)" - referenz: "dpm_funktionsbeschreibung.yaml" - weiter_mit: "Prozessende (für Request Management)" - - dor_referenz: "ssm_schema_ticket.yaml → definition_of_ready" - - raci: - r: "First Level Agent" - a: "Queue-Koordinator" - c: "-" - i: "Melder" - - # --------------------------------------------------------------------------- - # REQ-02: REQUEST KLASSIFIZIEREN - # --------------------------------------------------------------------------- - - id: "REQ-02" - name: "Request klassifizieren" - phase: "Erfassung" - blueprint_referenz: "ss_03" - - vorbedingung: "Katalog-Treffer in REQ-01" - - beschreibung: | - Bestimmung von Priorität, Pool und Governance-Anforderungen - basierend auf Katalog-Eintrag und Service-Kategorie. - - aktivitaeten: - - "Service-Kategorie vom Service ableiten (A/B/C)" - - "Genehmigungsanforderung aus Katalog-Eintrag ermitteln" - - "Fulfillment-Pfad aus Katalog-Eintrag ermitteln" - - "Impact und Urgency bewerten" - - "Priorität ableiten" - - "Pool zuweisen" - - service_kategorie_mapping: - beschreibung: | - Die Service-Kategorie bestimmt wesentliche Governance-Aspekte. - Die Kategorie wird vom Service geerbt, nicht am Request definiert. - - kategorie_a: - typische_prioritaet: "P4 oder P3" - typischer_pool: "Sofort-Pool oder Standard-Pool" - genehmigung: "Meist NICHT_ERFORDERLICH" - - kategorie_b: - typische_prioritaet: "P3 oder P2" - typischer_pool: "Standard-Pool" - genehmigung: "Je nach Katalog-Eintrag" - - kategorie_c: - typische_prioritaet: "P3 oder P2" - typischer_pool: "Analyse-Pool" - genehmigung: "Immer erforderlich" - - output: - - "Priorität (P1-P4)" - - "Pool-Zuordnung" - - "Genehmigungsanforderung (ja/nein)" - - "Genehmiger (wenn ja)" - - "Fulfillment-Pfad" - - raci: - r: "First Level Agent" - a: "Queue-Koordinator" - c: "-" - i: "-" - - # --------------------------------------------------------------------------- - # REQ-03: REQUEST ANNEHMEN - # --------------------------------------------------------------------------- - - id: "REQ-03" - name: "Request annehmen" - phase: "Bearbeitung" - blueprint_referenz: "ss_04" - - beschreibung: | - Übernahme des Requests durch einen Bearbeiter. Mit Annahme - beginnt die Ownership-Verantwortung. - - aktivitaeten: - - "Request aus Pool/Queue übernehmen" - - "Sich selbst als Bearbeiter zuweisen" - - "Status auf ANGENOMMEN setzen" - - "Ticket-Informationen sichten" - - varianten: - selbstzuweisung: - beschreibung: "Agent zieht Request selbst aus Pool" - gilt_fuer: ["Sofort-Pool", "Standard-Pool"] - - aktive_zuweisung: - beschreibung: "Queue-Koordinator weist Request gezielt zu" - gilt_fuer: ["Analyse-Pool"] - - ownership_regeln: - - "Mit Annahme beginnt Request-Ownership" - - "Request kann nicht mehr 'zurückgelegt' werden" - - "Ownership endet erst bei Schließung oder akzeptierter Übergabe" - - output: - - "Request mit Status ANGENOMMEN" - - "Bearbeiter zugewiesen" - - raci: - r: "First Level Agent / Second Level Agent" - a: "Queue-Koordinator" - c: "-" - i: "-" - - # --------------------------------------------------------------------------- - # REQ-04: GENEHMIGUNG EINHOLEN - # --------------------------------------------------------------------------- - - id: "REQ-04" - name: "Genehmigung einholen" - phase: "Bearbeitung" - blueprint_referenz: "ss_04" - - beschreibung: | - Einholen der erforderlichen Genehmigung(en) vor Fulfillment. - Nur relevant, wenn genehmigung_erforderlich = true. - - modellentscheidung: | - HINWEIS: Die konkreten Genehmigungsworkflows sind tool-abhängig - und müssen in der Implementierung ausdetailliert werden. - Dieses Dokument definiert die Prinzipien. - - vorbedingung: "genehmigung_erforderlich = true" - - aktivitaeten: - - "Genehmiger aus Katalog-Definition ermitteln" - - "Genehmigungsanfrage auslösen" - - "Status auf WARTEN_GENEHMIGUNG setzen" - - "Genehmigungsentscheidung dokumentieren" - - "Bei Mehrstufigkeit: Nächste Stufe auslösen" - - genehmigungsprinzipien_referenz: "kernkonzepte.genehmigungsprinzipien" - - varianten: - - einstufig: - beschreibung: "Ein Genehmiger entscheidet" - ablauf: - - "Genehmigungsanfrage an definierten Genehmiger" - - "Genehmiger entscheidet (genehmigt/abgelehnt)" - - "Ergebnis wird dokumentiert" - - mehrstufig: - beschreibung: "Mehrere Genehmiger in Sequenz" - ablauf: - - "Genehmigungsanfrage an ersten Genehmiger" - - "Nach Genehmigung: Anfrage an zweiten Genehmiger" - - "Ablehnung auf jeder Stufe beendet Prozess" - anwendung: "Bei Kosten- oder Sicherheitsrelevanz (SSM-G-16)" - - automatisch: - beschreibung: "Keine manuelle Genehmigung erforderlich" - ablauf: - - "System setzt genehmigung_status auf GENEHMIGT" - - "Kein Warten, direkter Übergang zu Fulfillment" - anwendung: "Bei vordefinierten, risikoarmen Requests" - - ergebnis_genehmigt: - - "genehmigung_status = GENEHMIGT" - - "Weiter zu REQ-05 (Fulfillment)" - - ergebnis_abgelehnt: - - "genehmigung_status = ABGELEHNT" - - "Melder informieren mit Begründung" - - "Request mit Status STORNIERT schließen" - - output: - - "genehmigung_status (GENEHMIGT / ABGELEHNT)" - - "genehmiger und genehmigt_am dokumentiert" - - raci: - r: "Genehmiger (je Katalog-Definition)" - a: "First Level Agent (Prozess-Owner des Requests)" - c: "Melder (bei Rückfragen)" - i: "Melder (bei Entscheidung)" - - # --------------------------------------------------------------------------- - # REQ-05: REQUEST ERFÜLLEN - # --------------------------------------------------------------------------- - - id: "REQ-05" - name: "Request erfüllen" - phase: "Bearbeitung" - blueprint_referenz: "ss_04" - - beschreibung: | - Durchführung der eigentlichen Leistungserbringung gemäß - Katalog-Definition und gewähltem Fulfillment-Pfad. - - modellentscheidung: | - HINWEIS: Die Fulfillment-Varianten sind konzeptionelle Vorschläge. - Die tatsächlichen Pfade müssen in der Implementierung basierend - auf Tool-Landschaft und Automatisierungsgrad validiert werden. - - vorbedingung: | - - genehmigung_status = GENEHMIGT oder NICHT_ERFORDERLICH - - Status = ANGENOMMEN oder nach Genehmigung - - aktivitaeten_allgemein: - - "Status auf IN_BEARBEITUNG setzen" - - "Fulfillment gemäß Katalog-Definition durchführen" - - "Alle Schritte dokumentieren" - - "Erfüllung im Feld 'erfuellung' beschreiben" - - "Status auf GELOEST setzen" - - # ------------------------------------------------------------------------- - # FULFILLMENT-VARIANTEN (DETAILLIERT) - # ------------------------------------------------------------------------- - varianten: - - fulfill_auto: - id: "FULFILL-AUTO" - name: "Automatische Erfüllung" - beschreibung: "Request wird ohne manuelle Bearbeitung erfüllt" - aktivitaeten: - - "Automatisierter Workflow wird ausgelöst" - - "System dokumentiert Ergebnis" - - "Status wird automatisch auf GELOEST gesetzt" - bearbeiter: "System" - raci: - r: "System" - a: "Support Manager (Prozess-Owner)" - - fulfill_l1: - id: "FULFILL-L1" - name: "L1 Direkterfüllung" - beschreibung: "Request wird direkt durch First Level Agent erfüllt" - aktivitaeten: - - "KB konsultieren (Standard-Request-Anleitungen)" - - "Dokumentierte Schritte ausführen" - - "Durchgeführte Aktionen dokumentieren" - - "Status auf GELOEST setzen" - bearbeiter: "First Level Agent" - kb_referenz: "ssm_wissensmanagement.yaml → Ebene 2" - raci: - r: "First Level Agent" - a: "Queue-Koordinator" - - fulfill_l2: - id: "FULFILL-L2" - name: "L2 Spezialist" - beschreibung: "Request erfordert Spezialkenntnisse" - aktivitaeten: - - "Übergabe an L2 mit vollständigem Kontext" - - "L2 führt Fulfillment durch" - - "L2 dokumentiert durchgeführte Aktionen" - - "L2 setzt Status auf GELOEST" - bearbeiter: "Second Level Agent" - raci: - r: "Second Level Agent" - a: "Support Manager" - - fulfill_beschaffung: - id: "FULFILL-BESCHAFFUNG" - name: "Beschaffung" - beschreibung: "Request erfordert externe Beschaffung" - aktivitaeten: - - "Beschaffungsanforderung auslösen" - - "Status auf WARTEN_EXTERN setzen" - - "Beschaffungsprozess abwarten" - - "Nach Wareneingang: Übergabe/Installation durchführen" - - "Dokumentation und Status GELOEST" - bearbeiter: "Agent + Beschaffung" - status_waehrend: "WARTEN_EXTERN" - raci: - r: "First Level Agent / Second Level Agent" - a: "Queue-Koordinator" - c: "Beschaffung (extern)" - - fulfill_change: - id: "FULFILL-CHANGE" - name: "Via Change" - beschreibung: "Fulfillment erfordert Infrastruktur-Änderung" - aktivitaeten: - - "Change Request erstellen mit Verweis auf Request" - - "Status auf WARTEN_CHANGE setzen" - - "Change-Prozess durchlaufen" - - "Nach Change-Implementierung: Prüfung" - - "Status auf GELOEST setzen" - bearbeiter: "Agent + Change Enablement" - status_waehrend: "WARTEN_CHANGE" - raci: - r: "First Level Agent / Second Level Agent" - a: "Queue-Koordinator" - c: "Change Enablement" - - output: - - "Request mit Status GELOEST" - - "erfuellung-Feld dokumentiert" - - "Ggf. Verweis auf erstellte Artefakte (Account, Installation, etc.)" - - # --------------------------------------------------------------------------- - # REQ-06: REQUEST ABSCHLIESSEN - # --------------------------------------------------------------------------- - - id: "REQ-06" - name: "Request abschließen" - phase: "Abschluss" - blueprint_referenz: "ss_09, ss_10" - - beschreibung: | - Bestätigung der erfolgreichen Erfüllung durch den Melder - und formaler Abschluss des Requests. - - aktivitaeten: - - "Melder über Erfüllung informieren" - - "Bestätigung anfordern" - - "Bei Bestätigung: Status auf GESCHLOSSEN setzen" - - "Bei Nicht-Zufriedenheit: Nachbesserung oder Wiedereröffnung" - - "Ticket-Dokumentation vervollständigen" - - bestaetigungsprozess: - beschreibung: | - Der Melder bestätigt, dass die Anfrage zu seiner Zufriedenheit - erfüllt wurde. - - kanaele: - - "E-Mail-Bestätigung" - - "Self-Service-Portal" - - "Telefonische Bestätigung (vom Agent dokumentiert)" - - timeout: - beschreibung: | - Wenn keine Rückmeldung erfolgt, wird der Request nach - definierter Frist automatisch geschlossen. - frist: "5 Arbeitstage" - aktion: "Automatischer Abschluss mit Status GESCHLOSSEN" - - nicht_zufriedenheit: - beschreibung: | - Wenn der Melder nicht zufrieden ist, wird der Request - zurück in Bearbeitung genommen. - ablauf: - - "Grund der Unzufriedenheit dokumentieren" - - "Status zurück auf IN_BEARBEITUNG" - - "Nachbesserung durchführen" - - "Erneut REQ-06 durchlaufen" - - output: - - "Request mit Status GESCHLOSSEN" - - "Bestätigung dokumentiert" - - "Abschlusszeit dokumentiert" - - raci: - r: "First Level Agent" - a: "Queue-Koordinator" - c: "-" - i: "Melder" - -# ============================================================================= -# STATUS-LIFECYCLE -# ============================================================================= - -status_lifecycle: - - beschreibung: | - Definition der erlaubten Status-Übergänge für Request-Tickets. - Ergänzt das Schema um den WARTEN_GENEHMIGUNG-Status. - - schema_referenz: "ssm_schema_ticket.yaml" - - status_werte: - - NEU - - ANGENOMMEN - - WARTEN_GENEHMIGUNG - - IN_BEARBEITUNG - - WARTEN_NUTZER - - WARTEN_EXTERN - - WARTEN_CHANGE - - GELOEST - - GESCHLOSSEN - - STORNIERT - - transitionen: - - - von: "NEU" - nach: ["ANGENOMMEN", "STORNIERT"] - beschreibung: "Neuer Request wird angenommen oder storniert (z.B. kein Katalog-Service)" - - - von: "ANGENOMMEN" - nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "STORNIERT"] - beschreibung: "Nach Annahme: Genehmigung einholen oder direkt bearbeiten" - - - von: "WARTEN_GENEHMIGUNG" - nach: ["IN_BEARBEITUNG", "STORNIERT"] - beschreibung: "Nach Genehmigung weiter, bei Ablehnung storniert" - - - von: "IN_BEARBEITUNG" - nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"] - beschreibung: "Bearbeitung führt zu Erfüllung oder Wartezustand" - - - von: "WARTEN_NUTZER" - nach: ["IN_BEARBEITUNG", "STORNIERT"] - beschreibung: "Nach Nutzer-Antwort weiter oder Timeout-Stornierung" - - - von: "WARTEN_EXTERN" - nach: ["IN_BEARBEITUNG"] - beschreibung: "Nach Lieferung/externer Rückmeldung weiter" - - - von: "WARTEN_CHANGE" - nach: ["IN_BEARBEITUNG", "GELOEST"] - beschreibung: "Nach Change-Implementierung weiter" - - - von: "GELOEST" - nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"] - beschreibung: "Bestätigung oder Nachbesserung" - - - von: "GESCHLOSSEN" - nach: ["IN_BEARBEITUNG"] - beschreibung: "Wiedereröffnung bei erneutem Bedarf" - bedingung: "Nur mit Begründung" - - - von: "STORNIERT" - nach: [] - beschreibung: "Endstatus, keine Transition möglich" - - request_spezifisch: - beschreibung: | - Request-Tickets nutzen zusätzlich WARTEN_GENEHMIGUNG. - Dieser Status existiert bei Incidents nicht. - - neuer_status: - id: "WARTEN_GENEHMIGUNG" - name: "Warten auf Genehmigung" - beschreibung: "Genehmigungsanfrage wurde ausgelöst, Entscheidung ausstehend" - clock_stop: true - -# ============================================================================= -# ESKALATIONSMODELL -# ============================================================================= - -eskalationsmodell: - - beschreibung: | - Eskalation bei Requests unterscheidet sich von Incidents. - Der Fokus liegt auf Genehmigungseskalation und Fulfillment-Verzögerungen, - nicht auf technischer Eskalation. - - # --------------------------------------------------------------------------- - # GENEHMIGUNGSESKALATION - # --------------------------------------------------------------------------- - genehmigungseskalation: - - beschreibung: | - Eskalation bei ausbleibender oder verzögerter Genehmigung. - - modellentscheidung: | - HINWEIS: Die konkreten Zeitgrenzen müssen in der Implementierung - festgelegt werden. - - stufen: - - stufe: "Erinnerung" - trigger: "Keine Genehmigungsentscheidung nach definierter Zeit" - aktion: "Erinnerung an Genehmiger" - - - stufe: "Eskalation an Vorgesetzten" - trigger: "Keine Genehmigungsentscheidung nach weiterer Frist" - aktion: "Information an Vorgesetzten des Genehmigers" - - - stufe: "Eskalation an Service Owner" - trigger: "Kritischer Request ohne Genehmigung" - aktion: "Service Owner entscheidet über weiteres Vorgehen" - - # --------------------------------------------------------------------------- - # FULFILLMENT-ESKALATION - # --------------------------------------------------------------------------- - fulfillment_eskalation: - - beschreibung: | - Eskalation bei Verzögerungen in der Erfüllung. - - stufen: - - stufe: "Agent → Queue-Koordinator" - trigger: - - "Fulfillment-Zeit droht zu überschreiten" - - "Ressourcen-Engpass" - - "Unklare Zuständigkeit" - - - stufe: "Queue-Koordinator → Support Manager" - trigger: - - "Wiederholte Verzögerungen" - - "Kapazitätsengpass im Team" - - "Prozess-Problem identifiziert" - - - stufe: "Support Manager → Service Owner" - trigger: - - "Systematische Fulfillment-Probleme" - - "Katalog-Definition nicht umsetzbar" - - # --------------------------------------------------------------------------- - # HINWEIS HIERARCHISCHE ESKALATION - # --------------------------------------------------------------------------- - hinweis_hierarchische_eskalation: | - Bei Requests gibt es typischerweise keine hierarchische Eskalation - wie bei Incidents (P1/P2-Zeitgrenzen), da keine akute Störung vorliegt. - - Ausnahme: Bei VIP-Requests oder geschäftskritischen Anfragen kann - eine priorisierte Bearbeitung erfolgen. - -# ============================================================================= -# KENNZAHLEN -# ============================================================================= - -kennzahlen: - - beschreibung: | - KPIs für Request Management. Die Zielwerte sind mit DIGIT - abzustimmen. - - kpis: - - - id: "KPI-REQ-01" - name: "Request Fulfillment Rate" - beschreibung: "Anteil der Requests, die innerhalb SLA erfüllt wurden" - formel: "(Requests in SLA erfüllt) / (Alle geschlossenen Requests) × 100" - ziel: ">90%" - - - id: "KPI-REQ-02" - name: "Durchschnittliche Fulfillment-Zeit" - beschreibung: "Mittlere Zeit von Erfassung bis Schließung" - formel: "Summe(Fulfillment-Zeiten) / Anzahl Requests" - ziel: "tbd (abhängig von Request-Mix)" - - - id: "KPI-REQ-03" - name: "Genehmigungsdurchlaufzeit" - beschreibung: "Mittlere Zeit für Genehmigungsprozess" - formel: "Summe(Genehmigungszeiten) / Anzahl genehmigungspflichtiger Requests" - ziel: "tbd" - - - id: "KPI-REQ-04" - name: "Ablehnungsrate" - beschreibung: "Anteil der abgelehnten Requests" - formel: "(Abgelehnte Requests) / (Alle Requests mit Genehmigungspflicht) × 100" - ziel: "<10%" - hinweis: "Hohe Rate kann auf Kommunikationsproblem hindeuten" - - - id: "KPI-REQ-05" - name: "Self-Service-Quote" - beschreibung: "Anteil der über Self-Service erfassten Requests" - formel: "(Self-Service Requests) / (Alle Requests) × 100" - ziel: "tbd (abhängig von Tool-Verfügbarkeit)" - status: "PLATZHALTER" - - - id: "KPI-REQ-06" - name: "Katalog-Trefferquote" - beschreibung: "Anteil der Anfragen, die im Katalog gefunden wurden" - formel: "(Katalog-Treffer) / (Alle Anfragen) × 100" - ziel: ">85%" - hinweis: "Niedrige Quote deutet auf Katalog-Lücken hin" - - todo: | - - Zielwerte mit DIGIT abstimmen - - Baseline aus historischen Daten ermitteln - - Reporting-Frequenz festlegen - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - modul: "ssm_klassifikation-priorisierung.yaml" - art: "verwendet" - beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele" - - - modul: "ssm_schema_ticket.yaml" - art: "implementiert" - beschreibung: "Datenstruktur für Request-Tickets" - - - modul: "sub-practice_incident-management.yaml" - art: "abgegrenzt von" - beschreibung: "Klare Typen-Trennung bei Ticket-Erfassung" - - - modul: "sub-practice_service-desk.yaml" - art: "wird ausgeführt durch" - beschreibung: "Service Desk als organisatorische Einheit führt Prozess aus" - - - modul: "spm_practice_service-level-management.yaml" - art: "wird gesteuert durch" - beschreibung: "SLA-Ziele und Service-Kategorien (A/B/C)" - - - modul: "spm_practice_service-catalog-management.yaml" - art: "referenziert" - beschreibung: "Request-Katalog als Teil des Service-Katalogs" - - - modul: "ssm_wissensmanagement.yaml" - art: "referenziert" - beschreibung: "Standard-Request-Anleitungen (Ebene 2)" - - - modul: "service-lifecycle_service-support.yaml" - art: "basiert auf" - beschreibung: "Blueprint-Aktivitäten ss_03, ss_04, ss_09, ss_10" - - - modul: "ssm_governance.yaml" - art: "wird gesteuert durch" - beschreibung: "Übergreifende Eskalationslogik, Reporting-Struktur, Governance-Gremien" - - extern: - - partner: "ITSM-Tool" - kontext: "Request-Lifecycle, Genehmigungsworkflows" - status: "Tool-Auswahl ausstehend" - - - partner: "Service-Katalog" - kontext: "Katalog-Einträge als Basis für Requests" - status: "Teil von SCM (P-01)" - - - partner: "Demand-Portfolio-Management" - kontext: "Nicht-Katalog-Anfragen werden an DPM übergeben" - referenz: "dpm_funktionsbeschreibung.yaml" - - - partner: "Change Enablement" - kontext: "Fulfillment via Change" - status: "Schnittstelle zu P-03 (Platzhalter)" - - - partner: "Beschaffung" - kontext: "Hardware- und Lizenzbeschaffung" - status: "Externer Prozess" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance: - - beschreibung: | - Governance-Entscheidungen, die in diesem Dokument getroffen oder - referenziert werden. Zur Übertragung ins zentrale Log. - - entscheidungen: - - - id: "SSM-G-14" - name: "Requests nur für Katalog-Services" - entscheidung: | - Service-Anfragen (Requests) können nur für Leistungen gestellt - werden, die im Service-Katalog definiert sind. Anfragen für - nicht-katalogisierte Leistungen sind Demands und werden über - das Demand-Portfolio-Management bearbeitet. - begruendung: | - Klare Prozessabgrenzung verhindert Wildwuchs und stellt sicher, - dass nur definierte, planbare Leistungen als Request bearbeitet - werden. Dies entlastet den Service Desk und schafft Transparenz. - status: "vorgeschlagen" - - - id: "SSM-G-15" - name: "Genehmiger je Katalog-Eintrag" - entscheidung: | - Die Genehmigungslogik (wer genehmigt, ob Genehmigung erforderlich) - wird je Katalog-Eintrag definiert. Dies ermöglicht Flexibilität - für unterschiedliche Anforderungen. - begruendung: | - Unterschiedliche Request-Typen haben unterschiedliche - Genehmigungsanforderungen. Eine zentrale Definition würde - entweder zu restriktiv oder zu lax sein. - status: "vorgeschlagen" - modellentscheidung: true - validierung_erforderlich: | - Konkrete Genehmiger-Zuordnungen müssen in der Implementierung - je Katalog-Eintrag definiert werden. - - - id: "SSM-G-16" - name: "Mehrstufige Genehmigung bei Kosten/Sicherheit" - entscheidung: | - Bei kostenrelevanten oder sicherheitsrelevanten Requests ist - eine mehrstufige Genehmigung erforderlich. Die Kosten-Freigabe - ist Teil der normalen Genehmigung (kein separater Schritt). - begruendung: | - Kosten- und Sicherheitsrisiken erfordern eine zweite Prüfebene. - Die Integration in den Genehmigungsprozess vermeidet zusätzliche - Prozessschritte. - status: "vorgeschlagen" - modellentscheidung: true - validierung_erforderlich: | - Konkrete Kostenschwellen und Sicherheitskriterien müssen in - der Implementierung definiert werden. - -# ============================================================================= -# RACI-REFERENZ -# ============================================================================= - -raci_referenz: - - beschreibung: | - Die verbindliche RACI-Matrix für Request Management ist in - ssm_governance.yaml → raci_konsolidiert.request_management definiert. - - Diese Kurzübersicht dient der schnellen Orientierung. - - master_dokument: "ssm_governance.yaml" - abschnitt: "raci_konsolidiert.request_management" - - kurzuebersicht: - # L1 L2 QK SM SO GEN - erfassung: "R - A - - -" - genehmigung_einholen: "R - A - C R" - fulfillment_l1: "R - A - - -" - fulfillment_l2: "- R - A - -" - abschluss: "R R A - - -" - - aenderungen: - - datum: "2025-12-07" - aenderung: "REQ-04: L1→QK als Accountable (Entscheidungsautorität)" - - datum: "2025-12-07" - aenderung: "REQ-05c (L2): QK→SM als Accountable (Konsistenz mit INC-08)" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-REQ-001" - thema: "Request-Katalog-Struktur im Detail" - beschreibung: | - Die genaue Struktur der Katalog-Einträge (Felder, Genehmiger-Definition, - Fulfillment-Pfad-Zuordnung) muss mit SCM abgestimmt werden. - prioritaet: "hoch" - status: "Abhängig von P-01 SCM" - abhaengig_von: "spm_practice_service-catalog-management.yaml" - - - id: "OPEN-REQ-002" - thema: "Self-Service-Scope" - beschreibung: | - Welche Requests sollen über Self-Service verfügbar sein? - Abhängig von Tool-Landschaft und Reifegrad. - prioritaet: "mittel" - status: "Platzhalter" - - - id: "OPEN-REQ-003" - thema: "Genehmigungsworkflows im Tool" - beschreibung: | - Konkrete Genehmigungsworkflows müssen im ITSM-Tool konfiguriert werden. - Abhängig von Tool-Auswahl. - prioritaet: "hoch" - status: "Tool-Auswahl ausstehend" - - - id: "OPEN-REQ-004" - thema: "Kostenschwellen für mehrstufige Genehmigung" - beschreibung: | - Ab welchem Betrag ist eine zweistufige Genehmigung erforderlich? - Abstimmung mit Finanzprozessen notwendig. - prioritaet: "mittel" - status: "Abstimmung erforderlich" - - - id: "OPEN-REQ-005" - thema: "Integration Beschaffungsprozess" - beschreibung: | - Die Schnittstelle zur Beschaffung (Hardware, Lizenzen) ist als - externer Prozess behandelt. In der kommunalen Verwaltung ist - Beschaffung komplex (Haushaltsrecht, Vergaberecht, Rahmenverträge). - Die Integration erfordert Abstimmung mit den relevanten - Verwaltungsprozessen. - prioritaet: "mittel" - status: "Externer Prozess, Schnittstelle zu definieren" - komplexitaet: "hoch" - - - id: "OPEN-REQ-006" - thema: "WARTEN_GENEHMIGUNG im Schema" - beschreibung: | - Der Status WARTEN_GENEHMIGUNG muss in ssm_schema_ticket.yaml - ergänzt werden (Request-spezifisch). - prioritaet: "hoch" - status: "Patch erforderlich" - blocker: true - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung mit Kernkonzepten, Aktivitäten, Governance" - autor: "DIGITOM-Projekt" +# ============================================================================= +# SUB-PRACTICE: REQUEST MANAGEMENT +# ============================================================================= + +metadata: + id: "P-05" + name: "Request Management" + version: "0.1" + status: "draft" + erstellt: "2025-12-07" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + + parent_practice: "practice_service-support-management" + + itil4_referenz: "Service Request Management Practice" + yasm_referenz: "LP4.6.2, LP4.6.3, LP4.6.6, LP4.6.7" + + blueprint_referenz: "service-lifecycle_service-support.yaml" + relevante_aktivitaeten: ["ss_03", "ss_04", "ss_09", "ss_10"] + + design_referenz: "ssm_design-zieldimensionen.yaml" + relevante_saeulen: ["LS-04", "LS-05"] + + schema_referenz: "ssm_schema_ticket.yaml" + klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml" + rollen_referenz: "ssm_rollen.yaml" + wissensmanagement_referenz: "ssm_wissensmanagement.yaml" + +# ============================================================================= +# ZWECK & SCOPE +# ============================================================================= + +zweck: + + definition: | + Request Management steuert die Erfassung, Genehmigung und Erfüllung + von Service-Anfragen. Es stellt sicher, dass Nutzer definierte + Leistungen aus dem Service-Katalog effizient und nachvollziehbar + erhalten. + + ziele: + - "Effiziente Erfüllung von Service-Anfragen" + - "Transparenter Genehmigungsprozess" + - "Einhaltung definierter Fulfillment-Zeiten" + - "Nachvollziehbare Dokumentation aller Requests" + - "Klare Abgrenzung zu Incidents und Demands" + + abgrenzung: + + request_vs_incident: | + Ein Request ist eine formelle Anfrage für eine definierte Leistung + aus dem Service-Katalog. Es liegt keine Störung vor. + Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung. + Siehe: ssm_klassifikation-priorisierung.yaml → ticket_typen + + request_vs_demand: | + Ein Request bezieht sich auf eine Leistung, die im Service-Katalog + definiert ist. Anfragen für nicht-katalogisierte Leistungen sind + Demands und werden über das Demand-Portfolio-Management (DPM) + bearbeitet. + + ENTSCHEIDUNGSREGEL: + - Im Service-Katalog → Request (P-05) + - Nicht im Service-Katalog → Demand (DPM) + + Governance: SSM-G-14 + + request_vs_change: | + Wenn die Request-Erfüllung eine Änderung an der IT-Infrastruktur + erfordert, die über Standard-Fulfillment hinausgeht, wird ein + Change angestoßen. Der Request bleibt offen (Status WARTEN_CHANGE) + bis der Change implementiert ist. + +# ============================================================================= +# KERNKONZEPTE +# ============================================================================= + +kernkonzepte: + + # --------------------------------------------------------------------------- + # KATALOG-PRINZIP + # --------------------------------------------------------------------------- + katalog_prinzip: + + beschreibung: | + Request Management ist katalogbasiert. Nur Leistungen, die im + Service-Katalog definiert sind, können als Request bearbeitet werden. + Der Service-Katalog ist die "Single Source of Truth" für bestellbare + Leistungen. + + governance: "SSM-G-14" + + konsequenzen: + - "Keine Ad-hoc-Requests für nicht-katalogisierte Leistungen" + - "Katalog-Pflege ist Voraussetzung für effizientes Request Management" + - "Nicht-Katalog-Anfragen werden in DPM-Prozess überführt" + + katalog_struktur: + beschreibung: | + Der Request-Katalog ist Teil des Service-Katalogs (keine separate + Struktur). Jeder Service definiert seine bestellbaren Leistungen. + + referenz: "spm_practice_service-catalog-management.yaml" + + je_katalog_eintrag: + - "Eindeutige ID (request_katalog_id)" + - "Name und Beschreibung" + - "Zugehöriger Service" + - "Genehmigungsanforderung" + - "Genehmiger-Definition" + - "Fulfillment-Pfad" + - "Standard-Fulfillment-Zeit" + - "Kostenrelevanz" + + hinweis: | + Die Service-Kategorie (A/B/C) ist KEIN Attribut des Katalog-Eintrags, + sondern wird vom zugehörigen Service geerbt. + + offener_punkt: "OPEN-REQ-001" + + # --------------------------------------------------------------------------- + # SERVICE-KATEGORIE-GOVERNANCE + # --------------------------------------------------------------------------- + service_kategorie_governance: + + beschreibung: | + Die Service-Kategorie (A/B/C aus SLM/SCM) bestimmt die + Governance-Anforderungen für Requests. Dies ersetzt die + klassische Unterscheidung "Standard vs. Non-Standard". + + vererbung: + beschreibung: | + Die Service-Kategorie ist ein Attribut des Services + (definiert in SLM). Der Katalog-Eintrag erbt die Kategorie + vom zugehörigen Service. Ein Katalog-Eintrag kann keine + abweichende Kategorie haben. + + referenz: "spm_practice_service-level-management.yaml → service_kategorien" + + kategorien: + + - kategorie: "A" + name: "Basis-Services" + request_charakteristik: | + Automatische Bereitstellung bei Eintritt (z.B. Onboarding). + Wenige aktive Requests, da Services "einfach da sind". + typische_requests: + - "Passwort zurücksetzen" + - "Informationsanfrage" + genehmigung: "Meist keine" + typischer_pool: "Sofort-Pool / Standard-Pool" + + - kategorie: "B" + name: "Erweiterte Services" + request_charakteristik: | + Beantragung erforderlich. Definierter Fulfillment-Prozess. + Genehmigung je nach Katalog-Eintrag. + typische_requests: + - "Software-Installation (aus Liste)" + - "Berechtigung für Fachverfahren" + - "Hardware-Zubehör" + genehmigung: "Je nach Katalog-Eintrag definiert" + typischer_pool: "Standard-Pool" + + - kategorie: "C" + name: "Spezial-Services" + request_charakteristik: | + Individuelle Abstimmung erforderlich. Oft mehrstufige + Genehmigung. Möglicherweise Kosten für das Amt. + typische_requests: + - "Spezial-Software (nicht in Standard-Liste)" + - "Spezial-Hardware" + - "Erweiterter Speicherplatz" + genehmigung: "Immer erforderlich (oft mehrstufig)" + typischer_pool: "Analyse-Pool" + + # --------------------------------------------------------------------------- + # GENEHMIGUNGSPRINZIPIEN + # --------------------------------------------------------------------------- + genehmigungsprinzipien: + + beschreibung: | + Die Genehmigungslogik wird je Katalog-Eintrag definiert. + Dieses Dokument definiert die Prinzipien, nicht die konkreten + Workflows. + + modellentscheidung: | + HINWEIS: Die folgenden Genehmigungsprinzipien sind konzeptionelle + Vorschläge und müssen in der Implementierung validiert und ggf. + angepasst werden. Die konkreten Workflows sind tool-abhängig. + + governance: "SSM-G-15, SSM-G-16" + + prinzipien: + + - prinzip: "Genehmiger je Katalog-Eintrag" + beschreibung: | + Jeder Katalog-Eintrag definiert, wer Genehmiger ist. + Dies ermöglicht Flexibilität für unterschiedliche Anforderungen. + governance: "SSM-G-15" + + - prinzip: "Mehrstufige Genehmigung bei Bedarf" + beschreibung: | + Bei Kosten- oder Sicherheitsrelevanz kann eine mehrstufige + Genehmigung erforderlich sein (z.B. Vorgesetzter + IT-Sicherheit). + governance: "SSM-G-16" + kriterien_mehrstufig: + - "Kosten über definierter Schwelle" + - "Sicherheitsrelevante Berechtigungen" + - "Zugriff auf sensible Daten" + - "Externe Lizenzen/Verträge" + + - prinzip: "Automatische Genehmigung möglich" + beschreibung: | + Für risikoarme, häufige Requests kann eine automatische + Genehmigung konfiguriert werden (z.B. Passwort-Reset). + + genehmiger_typen: + beschreibung: "Mögliche Genehmiger-Rollen" + typen: + - typ: "Fachvorgesetzter" + anwendung: "Standard für personenbezogene Requests" + - typ: "Kostenstellenverantwortlicher" + anwendung: "Bei kostenrelevanten Requests" + - typ: "Service Owner" + anwendung: "Bei Spezial-Services (Kategorie C)" + - typ: "IT-Sicherheit" + anwendung: "Bei sicherheitsrelevanten Berechtigungen" + - typ: "Automatisch" + anwendung: "Bei vordefinierten, risikoarmen Requests" + + # --------------------------------------------------------------------------- + # FULFILLMENT-VARIANTEN + # --------------------------------------------------------------------------- + fulfillment_varianten: + + beschreibung: | + Requests können auf unterschiedlichen Wegen erfüllt werden. + Der Fulfillment-Pfad wird je Katalog-Eintrag definiert. + + modellentscheidung: | + HINWEIS: Die folgenden Fulfillment-Varianten sind konzeptionelle + Vorschläge. Die tatsächlichen Pfade hängen von Tool-Landschaft, + Automatisierungsgrad und Organisationsstruktur ab. + + varianten: + + - id: "FULFILL-AUTO" + name: "Automatische Erfüllung" + beschreibung: | + Request wird ohne manuelle Bearbeitung erfüllt + (z.B. Self-Service-Portal, automatisierte Workflows). + beispiele: + - "Passwort-Reset (Self-Service)" + - "Standard-Software-Installation (Software-Center)" + - "Gruppenmitgliedschaft (automatisiert)" + bearbeitung: "System" + typische_fulfillment_zeit: "Sofort bis wenige Minuten" + + - id: "FULFILL-L1" + name: "L1 Direkterfüllung" + beschreibung: | + Request wird direkt durch First Level Agent erfüllt. + Keine Spezialkenntnisse erforderlich. + beispiele: + - "Berechtigung setzen (manuell)" + - "Account entsperren" + - "Informationsanfrage beantworten" + bearbeitung: "First Level Agent" + typische_fulfillment_zeit: "< 1 Arbeitstag" + + - id: "FULFILL-L2" + name: "L2 Spezialist" + beschreibung: | + Request erfordert Spezialkenntnisse oder erweiterte + Berechtigungen und wird an L2 übergeben. + beispiele: + - "Komplexe Software-Installation" + - "Spezial-Konfiguration" + - "Datenbank-Berechtigung" + bearbeitung: "Second Level Agent" + typische_fulfillment_zeit: "1-5 Arbeitstage" + + - id: "FULFILL-BESCHAFFUNG" + name: "Beschaffung" + beschreibung: | + Request erfordert externe Beschaffung (Hardware, Lizenzen). + Fulfillment nach Wareneingang. + beispiele: + - "Hardware-Bestellung" + - "Lizenz-Beschaffung" + - "Externer Service" + bearbeitung: "Beschaffungsprozess + Übergabe an IT" + typische_fulfillment_zeit: "Variabel (Beschaffungszeit)" + status_waehrend: "WARTEN_EXTERN" + + - id: "FULFILL-CHANGE" + name: "Via Change" + beschreibung: | + Request-Erfüllung erfordert Infrastruktur-Änderung, + die über Change Enablement gesteuert wird. + beispiele: + - "Neuer Server-Zugang" + - "Firewall-Regel" + - "Systemanpassung" + bearbeitung: "Change Enablement Prozess" + typische_fulfillment_zeit: "Abhängig von Change-Typ" + status_waehrend: "WARTEN_CHANGE" + + entscheidungsbaum: + beschreibung: | + Logik zur Bestimmung des Fulfillment-Pfads. + Wird idealerweise im Katalog-Eintrag vordefiniert. + + schritte: + - frage: "Ist automatische Erfüllung möglich?" + wenn_ja: "→ FULFILL-AUTO" + wenn_nein: "Weiter" + + - frage: "Liegt die Erfüllung im L1-Scope (dokumentiert, keine Spezialrechte)?" + wenn_ja: "→ FULFILL-L1" + wenn_nein: "Weiter" + + - frage: "Ist externe Beschaffung erforderlich?" + wenn_ja: "→ FULFILL-BESCHAFFUNG" + wenn_nein: "Weiter" + + - frage: "Ist eine Infrastruktur-Änderung erforderlich?" + wenn_ja: "→ FULFILL-CHANGE" + wenn_nein: "→ FULFILL-L2" + + # --------------------------------------------------------------------------- + # KOSTEN-HANDLING + # --------------------------------------------------------------------------- + kosten_handling: + + beschreibung: | + Manche Requests verursachen Kosten für das anfragende Amt. + Die Kostenfreigabe ist Teil der normalen Genehmigung. + + governance: "SSM-G-16" + + modellentscheidung: | + HINWEIS: Das Kosten-Handling ist ein konzeptioneller Vorschlag. + Konkrete Kostenschwellen und Freigabeprozesse müssen in der + Implementierung mit Finanzprozessen abgestimmt werden. + + prinzipien: + - "Kostenrelevanz wird im Katalog-Eintrag definiert" + - "Kosten werden vor Erfüllung transparent kommuniziert" + - "Kostenfreigabe ist Teil der Genehmigung (kein separater Schritt)" + - "Bei Kosten über Schwelle: mehrstufige Genehmigung" + + typische_kosten_requests: + - "Hardware-Beschaffung" + - "Spezial-Software / Lizenzen" + - "Erweiterte Services (Kategorie C)" + - "Externe Dienstleistungen" + + # --------------------------------------------------------------------------- + # SELF-SERVICE + # --------------------------------------------------------------------------- + self_service: + + beschreibung: | + Bestimmte Requests können von Nutzern selbst über ein + Self-Service-Portal ausgelöst werden. + + modellentscheidung: | + HINWEIS: Der Self-Service-Scope ist stark von Tool-Landschaft + und organisatorischem Reifegrad abhängig. Die folgenden + Aussagen sind Platzhalter und müssen in der Implementierung + konkretisiert werden. + + status: "PLATZHALTER" + + konzept: + beschreibung: | + Self-Service reduziert Aufwand für Service Desk und erhöht + Nutzer-Autonomie. Erfordert aber geeignete Tool-Unterstützung + und Nutzer-Akzeptanz. + + typische_self_service_requests: + - "Passwort-Reset" + - "Standard-Software aus Katalog" + - "Informations-Anfragen (FAQ/KB)" + - "Einfache Berechtigungsanfragen" + + voraussetzungen: + - "Self-Service-Portal / ITSM-Tool-Unterstützung" + - "Integrierte Genehmigungsworkflows" + - "Nutzer-Schulung und Kommunikation" + - "KB/FAQ für häufige Fragen" + + offener_punkt: "OPEN-REQ-002" + +# ============================================================================= +# PROZESS-AKTIVITÄTEN +# ============================================================================= + +aktivitaeten_uebersicht: | + Der Request-Prozess besteht aus 6 Kernaktivitäten. + Die Aktivitäten REQ-04 (Genehmigung) und REQ-05 (Fulfillment) + haben je nach Request-Typ unterschiedliche Ausprägungen. + +aktivitaeten: + + # --------------------------------------------------------------------------- + # REQ-01: REQUEST ERFASSEN + # --------------------------------------------------------------------------- + - id: "REQ-01" + name: "Request erfassen und Katalog prüfen" + phase: "Erfassung" + blueprint_referenz: "ss_03" + + beschreibung: | + Aufnahme der Anfrage über verfügbare Kanäle. Zentrale Prüfung: + Ist die Anfrage im Service-Katalog abgebildet? Diese Prüfung + entscheidet über den weiteren Prozess. + + trigger: + - kanal: "Telefon" + erfassung: "Agent erfasst in ITSM-Tool" + - kanal: "E-Mail" + erfassung: "Agent erfasst in ITSM-Tool" + - kanal: "Self-Service-Portal" + erfassung: "Nutzer erfasst selbst" + - kanal: "Persönlich" + erfassung: "Agent erfasst in ITSM-Tool" + + aktivitaeten: + - "Melder identifizieren" + - "Anfrage aufnehmen" + - "Katalog-Prüfung durchführen" + - "Entscheidung: Request oder Demand?" + + # ------------------------------------------------------------------------- + # VARIANTEN BASIEREND AUF KATALOG-PRÜFUNG + # ------------------------------------------------------------------------- + varianten: + + katalog_treffer: + beschreibung: "Anfrage ist im Service-Katalog → weiter als Request" + aktivitaeten: + - "Request-Typ bestimmen" + - "Katalog-Eintrag zuordnen" + - "Service-Kategorie ermitteln (vom Service geerbt)" + - "Relevante Felder befüllen" + - "Wunschtermin erfassen (wenn angegeben)" + - "DoR-Prüfung durchführen" + output: + - "Request-Ticket mit Status NEU" + - "Katalog-Referenz zugeordnet" + weiter_mit: "REQ-02" + + kein_katalog_treffer: + beschreibung: "Anfrage nicht im Katalog → Demand-Prozess" + governance: "SSM-G-14" + aktivitaeten: + - "Melder informieren: Leistung nicht im Katalog verfügbar" + - "Optionen aufzeigen: Demand über Stakeholder-Management einbringen" + - "Kontakt zu SHM vermitteln oder Demand-Meldung unterstützen" + - "Request-Ticket stornieren mit Begründung und Verweis auf Demand" + output: + - "Request-Ticket mit Status STORNIERT" + - "Stornierungsgrund: Nicht im Katalog" + - "Ggf. Verweis auf erstellte Demand-Meldung" + handoff: + ziel: "Demand-Portfolio-Management (DPM)" + via: "Stakeholder-Management (SHM)" + referenz: "dpm_funktionsbeschreibung.yaml" + weiter_mit: "Prozessende (für Request Management)" + + dor_referenz: "ssm_schema_ticket.yaml → definition_of_ready" + + raci: + r: "First Level Agent" + a: "Queue-Koordinator" + c: "-" + i: "Melder" + + # --------------------------------------------------------------------------- + # REQ-02: REQUEST KLASSIFIZIEREN + # --------------------------------------------------------------------------- + - id: "REQ-02" + name: "Request klassifizieren" + phase: "Erfassung" + blueprint_referenz: "ss_03" + + vorbedingung: "Katalog-Treffer in REQ-01" + + beschreibung: | + Bestimmung von Priorität, Pool und Governance-Anforderungen + basierend auf Katalog-Eintrag und Service-Kategorie. + + aktivitaeten: + - "Service-Kategorie vom Service ableiten (A/B/C)" + - "Genehmigungsanforderung aus Katalog-Eintrag ermitteln" + - "Fulfillment-Pfad aus Katalog-Eintrag ermitteln" + - "Impact und Urgency bewerten" + - "Priorität ableiten" + - "Pool zuweisen" + + service_kategorie_mapping: + beschreibung: | + Die Service-Kategorie bestimmt wesentliche Governance-Aspekte. + Die Kategorie wird vom Service geerbt, nicht am Request definiert. + + kategorie_a: + typische_prioritaet: "P4 oder P3" + typischer_pool: "Sofort-Pool oder Standard-Pool" + genehmigung: "Meist NICHT_ERFORDERLICH" + + kategorie_b: + typische_prioritaet: "P3 oder P2" + typischer_pool: "Standard-Pool" + genehmigung: "Je nach Katalog-Eintrag" + + kategorie_c: + typische_prioritaet: "P3 oder P2" + typischer_pool: "Analyse-Pool" + genehmigung: "Immer erforderlich" + + output: + - "Priorität (P1-P4)" + - "Pool-Zuordnung" + - "Genehmigungsanforderung (ja/nein)" + - "Genehmiger (wenn ja)" + - "Fulfillment-Pfad" + + raci: + r: "First Level Agent" + a: "Queue-Koordinator" + c: "-" + i: "-" + + # --------------------------------------------------------------------------- + # REQ-03: REQUEST ANNEHMEN + # --------------------------------------------------------------------------- + - id: "REQ-03" + name: "Request annehmen" + phase: "Bearbeitung" + blueprint_referenz: "ss_04" + + beschreibung: | + Übernahme des Requests durch einen Bearbeiter. Mit Annahme + beginnt die Ownership-Verantwortung. + + aktivitaeten: + - "Request aus Pool/Queue übernehmen" + - "Sich selbst als Bearbeiter zuweisen" + - "Status auf ANGENOMMEN setzen" + - "Ticket-Informationen sichten" + + varianten: + selbstzuweisung: + beschreibung: "Agent zieht Request selbst aus Pool" + gilt_fuer: ["Sofort-Pool", "Standard-Pool"] + + aktive_zuweisung: + beschreibung: "Queue-Koordinator weist Request gezielt zu" + gilt_fuer: ["Analyse-Pool"] + + ownership_regeln: + - "Mit Annahme beginnt Request-Ownership" + - "Request kann nicht mehr 'zurückgelegt' werden" + - "Ownership endet erst bei Schließung oder akzeptierter Übergabe" + + output: + - "Request mit Status ANGENOMMEN" + - "Bearbeiter zugewiesen" + + raci: + r: "First Level Agent / Second Level Agent" + a: "Queue-Koordinator" + c: "-" + i: "-" + + # --------------------------------------------------------------------------- + # REQ-04: GENEHMIGUNG EINHOLEN + # --------------------------------------------------------------------------- + - id: "REQ-04" + name: "Genehmigung einholen" + phase: "Bearbeitung" + blueprint_referenz: "ss_04" + + beschreibung: | + Einholen der erforderlichen Genehmigung(en) vor Fulfillment. + Nur relevant, wenn genehmigung_erforderlich = true. + + modellentscheidung: | + HINWEIS: Die konkreten Genehmigungsworkflows sind tool-abhängig + und müssen in der Implementierung ausdetailliert werden. + Dieses Dokument definiert die Prinzipien. + + vorbedingung: "genehmigung_erforderlich = true" + + aktivitaeten: + - "Genehmiger aus Katalog-Definition ermitteln" + - "Genehmigungsanfrage auslösen" + - "Status auf WARTEN_GENEHMIGUNG setzen" + - "Genehmigungsentscheidung dokumentieren" + - "Bei Mehrstufigkeit: Nächste Stufe auslösen" + + genehmigungsprinzipien_referenz: "kernkonzepte.genehmigungsprinzipien" + + varianten: + + einstufig: + beschreibung: "Ein Genehmiger entscheidet" + ablauf: + - "Genehmigungsanfrage an definierten Genehmiger" + - "Genehmiger entscheidet (genehmigt/abgelehnt)" + - "Ergebnis wird dokumentiert" + + mehrstufig: + beschreibung: "Mehrere Genehmiger in Sequenz" + ablauf: + - "Genehmigungsanfrage an ersten Genehmiger" + - "Nach Genehmigung: Anfrage an zweiten Genehmiger" + - "Ablehnung auf jeder Stufe beendet Prozess" + anwendung: "Bei Kosten- oder Sicherheitsrelevanz (SSM-G-16)" + + automatisch: + beschreibung: "Keine manuelle Genehmigung erforderlich" + ablauf: + - "System setzt genehmigung_status auf GENEHMIGT" + - "Kein Warten, direkter Übergang zu Fulfillment" + anwendung: "Bei vordefinierten, risikoarmen Requests" + + ergebnis_genehmigt: + - "genehmigung_status = GENEHMIGT" + - "Weiter zu REQ-05 (Fulfillment)" + + ergebnis_abgelehnt: + - "genehmigung_status = ABGELEHNT" + - "Melder informieren mit Begründung" + - "Request mit Status STORNIERT schließen" + + output: + - "genehmigung_status (GENEHMIGT / ABGELEHNT)" + - "genehmiger und genehmigt_am dokumentiert" + + raci: + r: "Genehmiger (je Katalog-Definition)" + a: "First Level Agent (Prozess-Owner des Requests)" + c: "Melder (bei Rückfragen)" + i: "Melder (bei Entscheidung)" + + # --------------------------------------------------------------------------- + # REQ-05: REQUEST ERFÜLLEN + # --------------------------------------------------------------------------- + - id: "REQ-05" + name: "Request erfüllen" + phase: "Bearbeitung" + blueprint_referenz: "ss_04" + + beschreibung: | + Durchführung der eigentlichen Leistungserbringung gemäß + Katalog-Definition und gewähltem Fulfillment-Pfad. + + modellentscheidung: | + HINWEIS: Die Fulfillment-Varianten sind konzeptionelle Vorschläge. + Die tatsächlichen Pfade müssen in der Implementierung basierend + auf Tool-Landschaft und Automatisierungsgrad validiert werden. + + vorbedingung: | + - genehmigung_status = GENEHMIGT oder NICHT_ERFORDERLICH + - Status = ANGENOMMEN oder nach Genehmigung + + aktivitaeten_allgemein: + - "Status auf IN_BEARBEITUNG setzen" + - "Fulfillment gemäß Katalog-Definition durchführen" + - "Alle Schritte dokumentieren" + - "Erfüllung im Feld 'erfuellung' beschreiben" + - "Status auf GELOEST setzen" + + # ------------------------------------------------------------------------- + # FULFILLMENT-VARIANTEN (DETAILLIERT) + # ------------------------------------------------------------------------- + varianten: + + fulfill_auto: + id: "FULFILL-AUTO" + name: "Automatische Erfüllung" + beschreibung: "Request wird ohne manuelle Bearbeitung erfüllt" + aktivitaeten: + - "Automatisierter Workflow wird ausgelöst" + - "System dokumentiert Ergebnis" + - "Status wird automatisch auf GELOEST gesetzt" + bearbeiter: "System" + raci: + r: "System" + a: "Support Manager (Prozess-Owner)" + + fulfill_l1: + id: "FULFILL-L1" + name: "L1 Direkterfüllung" + beschreibung: "Request wird direkt durch First Level Agent erfüllt" + aktivitaeten: + - "KB konsultieren (Standard-Request-Anleitungen)" + - "Dokumentierte Schritte ausführen" + - "Durchgeführte Aktionen dokumentieren" + - "Status auf GELOEST setzen" + bearbeiter: "First Level Agent" + kb_referenz: "ssm_wissensmanagement.yaml → Ebene 2" + raci: + r: "First Level Agent" + a: "Queue-Koordinator" + + fulfill_l2: + id: "FULFILL-L2" + name: "L2 Spezialist" + beschreibung: "Request erfordert Spezialkenntnisse" + aktivitaeten: + - "Übergabe an L2 mit vollständigem Kontext" + - "L2 führt Fulfillment durch" + - "L2 dokumentiert durchgeführte Aktionen" + - "L2 setzt Status auf GELOEST" + bearbeiter: "Second Level Agent" + raci: + r: "Second Level Agent" + a: "Support Manager" + + fulfill_beschaffung: + id: "FULFILL-BESCHAFFUNG" + name: "Beschaffung" + beschreibung: "Request erfordert externe Beschaffung" + aktivitaeten: + - "Beschaffungsanforderung auslösen" + - "Status auf WARTEN_EXTERN setzen" + - "Beschaffungsprozess abwarten" + - "Nach Wareneingang: Übergabe/Installation durchführen" + - "Dokumentation und Status GELOEST" + bearbeiter: "Agent + Beschaffung" + status_waehrend: "WARTEN_EXTERN" + raci: + r: "First Level Agent / Second Level Agent" + a: "Queue-Koordinator" + c: "Beschaffung (extern)" + + fulfill_change: + id: "FULFILL-CHANGE" + name: "Via Change" + beschreibung: "Fulfillment erfordert Infrastruktur-Änderung" + aktivitaeten: + - "Change Request erstellen mit Verweis auf Request" + - "Status auf WARTEN_CHANGE setzen" + - "Change-Prozess durchlaufen" + - "Nach Change-Implementierung: Prüfung" + - "Status auf GELOEST setzen" + bearbeiter: "Agent + Change Enablement" + status_waehrend: "WARTEN_CHANGE" + raci: + r: "First Level Agent / Second Level Agent" + a: "Queue-Koordinator" + c: "Change Enablement" + + output: + - "Request mit Status GELOEST" + - "erfuellung-Feld dokumentiert" + - "Ggf. Verweis auf erstellte Artefakte (Account, Installation, etc.)" + + # --------------------------------------------------------------------------- + # REQ-06: REQUEST ABSCHLIESSEN + # --------------------------------------------------------------------------- + - id: "REQ-06" + name: "Request abschließen" + phase: "Abschluss" + blueprint_referenz: "ss_09, ss_10" + + beschreibung: | + Bestätigung der erfolgreichen Erfüllung durch den Melder + und formaler Abschluss des Requests. + + aktivitaeten: + - "Melder über Erfüllung informieren" + - "Bestätigung anfordern" + - "Bei Bestätigung: Status auf GESCHLOSSEN setzen" + - "Bei Nicht-Zufriedenheit: Nachbesserung oder Wiedereröffnung" + - "Ticket-Dokumentation vervollständigen" + + bestaetigungsprozess: + beschreibung: | + Der Melder bestätigt, dass die Anfrage zu seiner Zufriedenheit + erfüllt wurde. + + kanaele: + - "E-Mail-Bestätigung" + - "Self-Service-Portal" + - "Telefonische Bestätigung (vom Agent dokumentiert)" + + timeout: + beschreibung: | + Wenn keine Rückmeldung erfolgt, wird der Request nach + definierter Frist automatisch geschlossen. + frist: "5 Arbeitstage" + aktion: "Automatischer Abschluss mit Status GESCHLOSSEN" + + nicht_zufriedenheit: + beschreibung: | + Wenn der Melder nicht zufrieden ist, wird der Request + zurück in Bearbeitung genommen. + ablauf: + - "Grund der Unzufriedenheit dokumentieren" + - "Status zurück auf IN_BEARBEITUNG" + - "Nachbesserung durchführen" + - "Erneut REQ-06 durchlaufen" + + output: + - "Request mit Status GESCHLOSSEN" + - "Bestätigung dokumentiert" + - "Abschlusszeit dokumentiert" + + raci: + r: "First Level Agent" + a: "Queue-Koordinator" + c: "-" + i: "Melder" + +# ============================================================================= +# STATUS-LIFECYCLE +# ============================================================================= + +status_lifecycle: + + beschreibung: | + Definition der erlaubten Status-Übergänge für Request-Tickets. + Ergänzt das Schema um den WARTEN_GENEHMIGUNG-Status. + + schema_referenz: "ssm_schema_ticket.yaml" + + status_werte: + - NEU + - ANGENOMMEN + - WARTEN_GENEHMIGUNG + - IN_BEARBEITUNG + - WARTEN_NUTZER + - WARTEN_EXTERN + - WARTEN_CHANGE + - GELOEST + - GESCHLOSSEN + - STORNIERT + + transitionen: + + - von: "NEU" + nach: ["ANGENOMMEN", "STORNIERT"] + beschreibung: "Neuer Request wird angenommen oder storniert (z.B. kein Katalog-Service)" + + - von: "ANGENOMMEN" + nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "STORNIERT"] + beschreibung: "Nach Annahme: Genehmigung einholen oder direkt bearbeiten" + + - von: "WARTEN_GENEHMIGUNG" + nach: ["IN_BEARBEITUNG", "STORNIERT"] + beschreibung: "Nach Genehmigung weiter, bei Ablehnung storniert" + + - von: "IN_BEARBEITUNG" + nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"] + beschreibung: "Bearbeitung führt zu Erfüllung oder Wartezustand" + + - von: "WARTEN_NUTZER" + nach: ["IN_BEARBEITUNG", "STORNIERT"] + beschreibung: "Nach Nutzer-Antwort weiter oder Timeout-Stornierung" + + - von: "WARTEN_EXTERN" + nach: ["IN_BEARBEITUNG"] + beschreibung: "Nach Lieferung/externer Rückmeldung weiter" + + - von: "WARTEN_CHANGE" + nach: ["IN_BEARBEITUNG", "GELOEST"] + beschreibung: "Nach Change-Implementierung weiter" + + - von: "GELOEST" + nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"] + beschreibung: "Bestätigung oder Nachbesserung" + + - von: "GESCHLOSSEN" + nach: ["IN_BEARBEITUNG"] + beschreibung: "Wiedereröffnung bei erneutem Bedarf" + bedingung: "Nur mit Begründung" + + - von: "STORNIERT" + nach: [] + beschreibung: "Endstatus, keine Transition möglich" + + request_spezifisch: + beschreibung: | + Request-Tickets nutzen zusätzlich WARTEN_GENEHMIGUNG. + Dieser Status existiert bei Incidents nicht. + + neuer_status: + id: "WARTEN_GENEHMIGUNG" + name: "Warten auf Genehmigung" + beschreibung: "Genehmigungsanfrage wurde ausgelöst, Entscheidung ausstehend" + clock_stop: true + +# ============================================================================= +# ESKALATIONSMODELL +# ============================================================================= + +eskalationsmodell: + + beschreibung: | + Eskalation bei Requests unterscheidet sich von Incidents. + Der Fokus liegt auf Genehmigungseskalation und Fulfillment-Verzögerungen, + nicht auf technischer Eskalation. + + # --------------------------------------------------------------------------- + # GENEHMIGUNGSESKALATION + # --------------------------------------------------------------------------- + genehmigungseskalation: + + beschreibung: | + Eskalation bei ausbleibender oder verzögerter Genehmigung. + + modellentscheidung: | + HINWEIS: Die konkreten Zeitgrenzen müssen in der Implementierung + festgelegt werden. + + stufen: + - stufe: "Erinnerung" + trigger: "Keine Genehmigungsentscheidung nach definierter Zeit" + aktion: "Erinnerung an Genehmiger" + + - stufe: "Eskalation an Vorgesetzten" + trigger: "Keine Genehmigungsentscheidung nach weiterer Frist" + aktion: "Information an Vorgesetzten des Genehmigers" + + - stufe: "Eskalation an Service Owner" + trigger: "Kritischer Request ohne Genehmigung" + aktion: "Service Owner entscheidet über weiteres Vorgehen" + + # --------------------------------------------------------------------------- + # FULFILLMENT-ESKALATION + # --------------------------------------------------------------------------- + fulfillment_eskalation: + + beschreibung: | + Eskalation bei Verzögerungen in der Erfüllung. + + stufen: + - stufe: "Agent → Queue-Koordinator" + trigger: + - "Fulfillment-Zeit droht zu überschreiten" + - "Ressourcen-Engpass" + - "Unklare Zuständigkeit" + + - stufe: "Queue-Koordinator → Support Manager" + trigger: + - "Wiederholte Verzögerungen" + - "Kapazitätsengpass im Team" + - "Prozess-Problem identifiziert" + + - stufe: "Support Manager → Service Owner" + trigger: + - "Systematische Fulfillment-Probleme" + - "Katalog-Definition nicht umsetzbar" + + # --------------------------------------------------------------------------- + # HINWEIS HIERARCHISCHE ESKALATION + # --------------------------------------------------------------------------- + hinweis_hierarchische_eskalation: | + Bei Requests gibt es typischerweise keine hierarchische Eskalation + wie bei Incidents (P1/P2-Zeitgrenzen), da keine akute Störung vorliegt. + + Ausnahme: Bei VIP-Requests oder geschäftskritischen Anfragen kann + eine priorisierte Bearbeitung erfolgen. + +# ============================================================================= +# KENNZAHLEN +# ============================================================================= + +kennzahlen: + + beschreibung: | + KPIs für Request Management. Die Zielwerte sind mit DIGIT + abzustimmen. + + kpis: + + - id: "KPI-REQ-01" + name: "Request Fulfillment Rate" + beschreibung: "Anteil der Requests, die innerhalb SLA erfüllt wurden" + formel: "(Requests in SLA erfüllt) / (Alle geschlossenen Requests) × 100" + ziel: ">90%" + + - id: "KPI-REQ-02" + name: "Durchschnittliche Fulfillment-Zeit" + beschreibung: "Mittlere Zeit von Erfassung bis Schließung" + formel: "Summe(Fulfillment-Zeiten) / Anzahl Requests" + ziel: "tbd (abhängig von Request-Mix)" + + - id: "KPI-REQ-03" + name: "Genehmigungsdurchlaufzeit" + beschreibung: "Mittlere Zeit für Genehmigungsprozess" + formel: "Summe(Genehmigungszeiten) / Anzahl genehmigungspflichtiger Requests" + ziel: "tbd" + + - id: "KPI-REQ-04" + name: "Ablehnungsrate" + beschreibung: "Anteil der abgelehnten Requests" + formel: "(Abgelehnte Requests) / (Alle Requests mit Genehmigungspflicht) × 100" + ziel: "<10%" + hinweis: "Hohe Rate kann auf Kommunikationsproblem hindeuten" + + - id: "KPI-REQ-05" + name: "Self-Service-Quote" + beschreibung: "Anteil der über Self-Service erfassten Requests" + formel: "(Self-Service Requests) / (Alle Requests) × 100" + ziel: "tbd (abhängig von Tool-Verfügbarkeit)" + status: "PLATZHALTER" + + - id: "KPI-REQ-06" + name: "Katalog-Trefferquote" + beschreibung: "Anteil der Anfragen, die im Katalog gefunden wurden" + formel: "(Katalog-Treffer) / (Alle Anfragen) × 100" + ziel: ">85%" + hinweis: "Niedrige Quote deutet auf Katalog-Lücken hin" + + todo: | + - Zielwerte mit DIGIT abstimmen + - Baseline aus historischen Daten ermitteln + - Reporting-Frequenz festlegen + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + - modul: "ssm_klassifikation-priorisierung.yaml" + art: "verwendet" + beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele" + + - modul: "ssm_schema_ticket.yaml" + art: "implementiert" + beschreibung: "Datenstruktur für Request-Tickets" + + - modul: "sub-practice_incident-management.yaml" + art: "abgegrenzt von" + beschreibung: "Klare Typen-Trennung bei Ticket-Erfassung" + + - modul: "sub-practice_service-desk.yaml" + art: "wird ausgeführt durch" + beschreibung: "Service Desk als organisatorische Einheit führt Prozess aus" + + - modul: "spm_practice_service-level-management.yaml" + art: "wird gesteuert durch" + beschreibung: "SLA-Ziele und Service-Kategorien (A/B/C)" + + - modul: "spm_practice_service-catalog-management.yaml" + art: "referenziert" + beschreibung: "Request-Katalog als Teil des Service-Katalogs" + + - modul: "ssm_wissensmanagement.yaml" + art: "referenziert" + beschreibung: "Standard-Request-Anleitungen (Ebene 2)" + + - modul: "service-lifecycle_service-support.yaml" + art: "basiert auf" + beschreibung: "Blueprint-Aktivitäten ss_03, ss_04, ss_09, ss_10" + + - modul: "ssm_governance.yaml" + art: "wird gesteuert durch" + beschreibung: "Übergreifende Eskalationslogik, Reporting-Struktur, Governance-Gremien" + + extern: + - partner: "ITSM-Tool" + kontext: "Request-Lifecycle, Genehmigungsworkflows" + status: "Tool-Auswahl ausstehend" + + - partner: "Service-Katalog" + kontext: "Katalog-Einträge als Basis für Requests" + status: "Teil von SCM (P-01)" + + - partner: "Demand-Portfolio-Management" + kontext: "Nicht-Katalog-Anfragen werden an DPM übergeben" + referenz: "dpm_funktionsbeschreibung.yaml" + + - partner: "Change Enablement" + kontext: "Fulfillment via Change" + status: "Schnittstelle zu P-03 (Platzhalter)" + + - partner: "Beschaffung" + kontext: "Hardware- und Lizenzbeschaffung" + status: "Externer Prozess" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance: + + beschreibung: | + Governance-Entscheidungen, die in diesem Dokument getroffen oder + referenziert werden. Zur Übertragung ins zentrale Log. + + entscheidungen: + + - id: "SSM-G-14" + name: "Requests nur für Katalog-Services" + entscheidung: | + Service-Anfragen (Requests) können nur für Leistungen gestellt + werden, die im Service-Katalog definiert sind. Anfragen für + nicht-katalogisierte Leistungen sind Demands und werden über + das Demand-Portfolio-Management bearbeitet. + begruendung: | + Klare Prozessabgrenzung verhindert Wildwuchs und stellt sicher, + dass nur definierte, planbare Leistungen als Request bearbeitet + werden. Dies entlastet den Service Desk und schafft Transparenz. + status: "vorgeschlagen" + + - id: "SSM-G-15" + name: "Genehmiger je Katalog-Eintrag" + entscheidung: | + Die Genehmigungslogik (wer genehmigt, ob Genehmigung erforderlich) + wird je Katalog-Eintrag definiert. Dies ermöglicht Flexibilität + für unterschiedliche Anforderungen. + begruendung: | + Unterschiedliche Request-Typen haben unterschiedliche + Genehmigungsanforderungen. Eine zentrale Definition würde + entweder zu restriktiv oder zu lax sein. + status: "vorgeschlagen" + modellentscheidung: true + validierung_erforderlich: | + Konkrete Genehmiger-Zuordnungen müssen in der Implementierung + je Katalog-Eintrag definiert werden. + + - id: "SSM-G-16" + name: "Mehrstufige Genehmigung bei Kosten/Sicherheit" + entscheidung: | + Bei kostenrelevanten oder sicherheitsrelevanten Requests ist + eine mehrstufige Genehmigung erforderlich. Die Kosten-Freigabe + ist Teil der normalen Genehmigung (kein separater Schritt). + begruendung: | + Kosten- und Sicherheitsrisiken erfordern eine zweite Prüfebene. + Die Integration in den Genehmigungsprozess vermeidet zusätzliche + Prozessschritte. + status: "vorgeschlagen" + modellentscheidung: true + validierung_erforderlich: | + Konkrete Kostenschwellen und Sicherheitskriterien müssen in + der Implementierung definiert werden. + +# ============================================================================= +# RACI-REFERENZ +# ============================================================================= + +raci_referenz: + + beschreibung: | + Die verbindliche RACI-Matrix für Request Management ist in + ssm_governance.yaml → raci_konsolidiert.request_management definiert. + + Diese Kurzübersicht dient der schnellen Orientierung. + + master_dokument: "ssm_governance.yaml" + abschnitt: "raci_konsolidiert.request_management" + + kurzuebersicht: + # L1 L2 QK SM SO GEN + erfassung: "R - A - - -" + genehmigung_einholen: "R - A - C R" + fulfillment_l1: "R - A - - -" + fulfillment_l2: "- R - A - -" + abschluss: "R R A - - -" + + aenderungen: + - datum: "2025-12-07" + aenderung: "REQ-04: L1→QK als Accountable (Entscheidungsautorität)" + - datum: "2025-12-07" + aenderung: "REQ-05c (L2): QK→SM als Accountable (Konsistenz mit INC-08)" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-REQ-001" + thema: "Request-Katalog-Struktur im Detail" + beschreibung: | + Die genaue Struktur der Katalog-Einträge (Felder, Genehmiger-Definition, + Fulfillment-Pfad-Zuordnung) muss mit SCM abgestimmt werden. + prioritaet: "hoch" + status: "Abhängig von P-01 SCM" + abhaengig_von: "spm_practice_service-catalog-management.yaml" + + - id: "OPEN-REQ-002" + thema: "Self-Service-Scope" + beschreibung: | + Welche Requests sollen über Self-Service verfügbar sein? + Abhängig von Tool-Landschaft und Reifegrad. + prioritaet: "mittel" + status: "Platzhalter" + + - id: "OPEN-REQ-003" + thema: "Genehmigungsworkflows im Tool" + beschreibung: | + Konkrete Genehmigungsworkflows müssen im ITSM-Tool konfiguriert werden. + Abhängig von Tool-Auswahl. + prioritaet: "hoch" + status: "Tool-Auswahl ausstehend" + + - id: "OPEN-REQ-004" + thema: "Kostenschwellen für mehrstufige Genehmigung" + beschreibung: | + Ab welchem Betrag ist eine zweistufige Genehmigung erforderlich? + Abstimmung mit Finanzprozessen notwendig. + prioritaet: "mittel" + status: "Abstimmung erforderlich" + + - id: "OPEN-REQ-005" + thema: "Integration Beschaffungsprozess" + beschreibung: | + Die Schnittstelle zur Beschaffung (Hardware, Lizenzen) ist als + externer Prozess behandelt. In der kommunalen Verwaltung ist + Beschaffung komplex (Haushaltsrecht, Vergaberecht, Rahmenverträge). + Die Integration erfordert Abstimmung mit den relevanten + Verwaltungsprozessen. + prioritaet: "mittel" + status: "Externer Prozess, Schnittstelle zu definieren" + komplexitaet: "hoch" + + - id: "OPEN-REQ-006" + thema: "WARTEN_GENEHMIGUNG im Schema" + beschreibung: | + Der Status WARTEN_GENEHMIGUNG muss in ssm_schema_ticket.yaml + ergänzt werden (Request-spezifisch). + prioritaet: "hoch" + status: "Patch erforderlich" + blocker: true + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung mit Kernkonzepten, Aktivitäten, Governance" + autor: "DIGITOM-Projekt" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_service-desk.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_service-desk.yaml index b81c5a9..d196ad0 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_service-desk.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_service-desk.yaml @@ -1,790 +1,790 @@ -# ============================================================================= -# SUB-PRACTICE: SERVICE DESK -# ============================================================================= - -metadata: - id: "SD" - name: "Service Desk" - version: "0.2" - status: "draft" - erstellt: "2025-12-07" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - parent_practice: "practice_service-support-management" - - itil4_referenz: "Service Desk Practice" - yasm_referenz: "LP4.6.1" - - blueprint_referenz: "service-lifecycle_service-support.yaml" - relevante_aktivitaeten: ["ss_01", "ss_02", "ss_03"] - - design_referenz: "ssm_design-zieldimensionen.yaml" - relevante_saeulen: ["LS-01", "LS-02", "LS-03", "LS-04"] - - hinweis: | - Der Service Desk ist keine Prozess-Practice wie Incident oder Request - Management, sondern eine organisatorische Capability. Dieses Dokument - beschreibt die organisatorischen Rahmenbedingungen, nicht die Prozesse. - -# ============================================================================= -# ZWECK & SELBSTVERSTÄNDNIS -# ============================================================================= - -zweck: - - definition: | - Der Service Desk ist der zentrale Zugangspunkt für alle IT-bezogenen - Anfragen und Störungsmeldungen. Er fungiert als Single Point of Contact - (SPOC) zwischen Nutzern und der IT-Organisation. - - selbstverstaendnis: - - enablement_paradigma: - beschreibung: | - Der Service Desk verfolgt ein Enablement-Paradigma: Der First Level - agiert als aktiver Problemlöser und Befähiger, nicht als reiner - Ticket-Verteiler ("Ticket-Schubser"). - - prinzipien: - - "Agents gehen selbst auf Detektivsuche und schaffen Lösungen" - - "Enge Zusammenarbeit mit Second Level und Service Ownern" - - "Systematisches Lernen durch legitimierte Exploration" - - "Befähigung der Nutzer, nicht nur Symptombehandlung" - - governance: "SSM-G-03 (Explorative-Diagnose-Legitimation)" - - kernfunktionen: - - "Zentrale Anlaufstelle für alle IT-Anfragen" - - "Qualifizierte Erstanalyse und Triage" - - "First-Level-Resolution für definierte Standardfälle" - - "Koordinierte Weiterleitung bei Eskalation" - - "Proaktive Kommunikation mit Nutzern" - - "Beitrag zum organisatorischen Wissensaufbau" - - ziele: - - "Schnelle und kompetente Erstreaktion auf Nutzeranfragen" - - "Hohe First Contact Resolution Rate" - - "Transparente Kommunikation über Ticket-Status" - - "Kontinuierliche Befähigung des First Level" - - "Systematische Erfassung aller IT-Kontakte" - -# ============================================================================= -# SYSTEMGRENZE -# ============================================================================= - -systemgrenze: - - beschreibung: | - Der Service Desk etabliert eine "harte Grenze" als formale Regel: - Alle IT-Anfragen müssen durch den Service Desk. Diese Grenze gilt - als Referenzpunkt, mit dem Verständnis, dass informelle Strukturen - existieren werden. - - harte_grenze: - - prinzip: "Keine IT-Bearbeitung ohne Ticket" - - konsequenzen: - - "Alle Anfragen werden als Ticket erfasst" - - "Auch mündliche Anfragen führen zu Ticket-Erstellung" - - "Rückkanal immer über Ticketsystem" - - "Dokumentation aller Aktivitäten im Ticket" - - begruendung: | - Die harte Grenze ermöglicht: - - Vollständige Transparenz über IT-Aufwände - - Messbarkeit und Steuerbarkeit - - Nachvollziehbarkeit für Nutzer und IT - - Basis für kontinuierliche Verbesserung - - umgang_informelle_strukturen: - - akzeptanz_der_realitaet: - beschreibung: | - Informelle Strukturen werden existieren. "Lieblings-Admins" werden - direkt kontaktiert, VIPs werden Sonderwege suchen. Das Modell - akzeptiert diese Realität, etabliert aber einen Reflexionsmechanismus. - - beispiele: - - "Direkter Anruf bei bekanntem L2-Kollegen" - - "E-Mail direkt an Spezialisten statt Service Desk" - - "Flurfunk-Anfragen" - - reflexionsmechanismus: - beschreibung: "Service Owner beobachten Umgehungen" - bewertung: - - "Einmalig oder systematisch?" - - "Verursacht das Probleme?" - - "Gibt es einen legitimen Grund?" - - intervention_nur_bei: "Problematischen Mustern" - - interventionsstufen: - - stufe: 1 - aktion: "Gespräch mit beteiligten Personen" - - stufe: 2 - aktion: "Formale Erinnerung an Prozesse" - - stufe: 3 - aktion: "Eskalation an Führungsebene" - - stufe: 4 - aktion: "Anpassung der Prozesse (wenn sinnvoll)" - -# ============================================================================= -# KANALMANAGEMENT -# ============================================================================= - -kanalmanagement: - - beschreibung: | - Definition der Eingangskanäle und wie Anfragen über diese Kanäle - in das Ticketsystem überführt werden. - - eingangskanal: - - - kanal: "Service Portal" - typ: "Self-Service" - beschreibung: "Webformular im Intranet" - ticket_erstellung: "Automatisch durch Nutzer" - empfohlen: true - vorteile: - - "Strukturierte Erfassung" - - "Reduziert Rückfragen" - - "24/7 verfügbar" - - - kanal: "E-Mail" - typ: "Asynchron" - beschreibung: "E-Mail an zentrale Service-Desk-Adresse" - ticket_erstellung: "Automatisch oder durch Agent" - hinweis: | - E-Mails direkt an einzelne Agents sollen an die zentrale - Adresse weitergeleitet werden. - - - kanal: "Telefon" - typ: "Synchron" - beschreibung: "Anruf bei Service-Desk-Hotline" - ticket_erstellung: "Durch Agent während/nach Gespräch" - hinweis: | - Agent erstellt Ticket während des Gesprächs oder unmittelbar - danach. Keine Bearbeitung ohne Ticket-Dokumentation. - - - kanal: "Persönlich (Walk-in)" - typ: "Synchron" - beschreibung: "Direkter Besuch während Bürozeiten" - ticket_erstellung: "Durch Agent" - hinweis: "Nur während definierter Servicezeiten" - - ticket_pflicht: - - regel: | - Jede Anfrage, unabhängig vom Kanal, führt zu einem Ticket. - Auch wenn die Lösung im Erstkontakt erfolgt, wird dokumentiert. - - ausnahmen: - - "Reine Informationsfragen, die in <2 Minuten beantwortet sind" - - "Weiterleitung an andere Stelle (kein IT-Thema)" - - bei_ausnahmen: "Kurze Notiz im Tagesprotokoll empfohlen" - -# ============================================================================= -# SERVICEZEITEN & ERREICHBARKEIT -# ============================================================================= - -servicezeiten: - - status: "ANFORDERUNGEN" - - hinweis: | - Die konkreten Servicezeiten sind eine operative Entscheidung von DIGIT. - Dieses Dokument definiert die Anforderungen und Rahmenbedingungen. - - anforderungen: - - kernservicezeit: - beschreibung: "Zeitraum mit voller Service-Desk-Besetzung" - empfehlung: "Mindestens Kernarbeitszeit der Stadtverwaltung" - anforderung: "Telefonische Erreichbarkeit muss gewährleistet sein" - - erweiterte_erreichbarkeit: - beschreibung: "Zeitraum mit eingeschränkter Erreichbarkeit" - optionen: - - "E-Mail-Monitoring außerhalb Kernzeit" - - "Rufbereitschaft für kritische Systeme" - status: "Mit DIGIT zu klären" - - mindestbesetzung: - beschreibung: "Minimale Anzahl Agents während Kernzeit" - anforderung: | - Mindestens 2 Agents zur Abdeckung von: - - Telefonkanal - - Ticket-Bearbeitung - - Vertretung bei Kurzabwesenheit - - bei_unterschreitung: "Eskalation an Queue-Koordinator" - - kommunikation: - - anforderung: | - Servicezeiten müssen den Nutzern klar kommuniziert werden. - - kanaele: - - "Intranet-Seite des Service Desk" - - "Automatische Antwort bei E-Mail außerhalb Servicezeiten" - - "Ansage bei Telefon außerhalb Servicezeiten" - - offener_punkt: "OPEN-SD-001" - -# ============================================================================= -# EINGANGSSTEUERUNG (TRIAGE) -# ============================================================================= - -eingangssteuerung: - - beschreibung: | - Die Eingangssteuerung (Triage) ist der erste Schritt bei jeder Anfrage. - Sie bestimmt den Ticket-Typ, die initiale Klassifikation und die - Pool-Zuweisung. - - triage_prozess: - - schritt_1_ticket_typ: - frage: "Um was für eine Anfrage handelt es sich?" - entscheidung: - stoerung: "→ Incident (P-04)" - anfrage_im_katalog: "→ Request (P-05)" - anfrage_nicht_im_katalog: "→ Demand (DPM)" - ungewiss: "→ Als Incident erfassen, später umklassifizieren" - - referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen" - - schritt_2_klassifikation: - beschreibung: "Impact, Urgency und Priorität bestimmen" - - bei_incident: - - "Impact bewerten (Hoch/Normal/Niedrig)" - - "Urgency bewerten (Hoch/Normal/Niedrig)" - - "Priorität aus Matrix ableiten" - - bei_request: - - "Katalog-Eintrag identifizieren" - - "Service-Kategorie übernehmen" - - "Genehmigungsanforderung prüfen" - - referenz: "ssm_klassifikation-priorisierung.yaml" - - schritt_3_pool_zuweisung: - beschreibung: "Ticket dem richtigen Pool zuweisen" - - pools: - - pool: "Sofort-Pool" - kriterien: "P1 (alle Charakteristiken)" - ziel: "Sofortige Bearbeitung" - - - pool: "Standard-Pool" - kriterien: "P2-P4 mit Charakteristik STANDARD oder ANALYSE" - ziel: "Bearbeitung gemäß SLA" - - - pool: "Projekt-Pool" - kriterien: "Charakteristik PROJEKT (planbar, >1 Tag Aufwand)" - ziel: "Koordinierte Bearbeitung" - - hinweis: | - Version 0.2: Der bisherige Analyse-Pool entfällt. - ANALYSE-Tickets werden im Standard-Pool bearbeitet. - Die Charakteristik ANALYSE bleibt als Label für Reporting erhalten. - - referenz: "ssm_klassifikation-priorisierung.yaml → pool_modell" - - schritt_4_erste_reaktion: - beschreibung: "Nutzer über Ticket-Erstellung informieren" - inhalt: - - "Ticket-Nummer" - - "Kurze Bestätigung des Anliegens" - - "Erwartbare nächste Schritte" - - "Kontaktmöglichkeit bei Rückfragen" - - qualitaetsanforderung: - - beschreibung: | - Die Triage-Qualität bestimmt maßgeblich die Effizienz der - nachfolgenden Bearbeitung. Fehlerhafte Klassifikation führt - zu Verzögerungen und Nacharbeit. - - schulungsbedarf: "Regelmäßige Schulung der Triage-Kriterien" - - feedback_loop: | - Bei häufigen Fehlklassifikationen: Anpassung der Kriterien - oder zusätzliche Schulung. - -# ============================================================================= -# QUEUE-KOORDINATION -# ============================================================================= - -queue_koordination: - - beschreibung: | - Der Queue-Koordinator ist verantwortlich für die operative Steuerung - der Ticket-Queues. Er überwacht Workload, priorisiert innerhalb der - Pools und koordiniert bei Engpässen oder Konflikten. - - rolle: - referenz: "ssm_rollen.yaml → queue_koordinator" - - besetzung: - primaer: "Definierte Person (z.B. Gruppenleiter)" - stellvertretung: "Muss für Abwesenheiten definiert sein" - modell: "Kann dediziert, rotierend oder in Teilzeit sein" - - offener_punkt: "OPEN-ROLLEN-001" - - ueberwachungsaufgaben: - - pool_monitoring: - beschreibung: "Kontinuierliche Überwachung aller Pools" - fokus: - - "Anzahl Tickets pro Pool" - - "Liegezeiten kritischer Tickets" - - "Verteilung auf Agents" - - werkzeug: "Dashboard (Echtzeit)" - - kapazitaetssteuerung: - beschreibung: "Balance zwischen Pools und Agents" - aktivitaeten: - - "Erkennen von Kapazitätsengpässen" - - "Umverteilung bei Ungleichgewicht" - - "Eskalation bei Überlast" - - sla_ueberwachung: - beschreibung: "Überwachung der SLA-Einhaltung" - aktivitaeten: - - "Frühwarnung bei SLA-Gefährdung" - - "Priorisierung gefährdeter Tickets" - - "Eskalation bei drohender Verletzung" - - interventionsregeln: - - beschreibung: | - Der Queue-Koordinator greift aktiv ein, wenn definierte - Schwellwerte erreicht werden. - - trigger: - - - situation: "Ticket >15 Min im Sofort-Pool" - aktion: "Sofortige Intervention, Zuweisung erzwingen" - eskalation: "Bei Ressourcenmangel → Support Manager" - - - situation: "Ticket >30 Min im Sofort-Pool" - aktion: "Alarmierung Support Manager" - eskalation: "Automatisch" - - - situation: "Agent hat 2 blockierte Tickets" - aktion: "Prüfung: Warum blockiert? Unterstützung anbieten" - eskalation: "Bei strukturellem Problem → Support Manager" - - - situation: "Standard-Pool >20 Tickets" - aktion: "Kapazitätsalarm, Priorisierung, ggf. Umverteilung" - eskalation: "Bei anhaltendem Überlauf → Support Manager" - - - situation: "Extreme Ungleichverteilung" - aktion: "Ausgleich zwischen Agents" - eskalation: "Keine, direkte Koordination" - - - situation: "Übergabe nicht akzeptiert nach 4h" - aktion: "Klärung mit beteiligten Agents" - eskalation: "Bei Verweigerung → Support Manager" - - interventionsstufen: - - - stufe: 1 - name: "Anfrage" - beschreibung: "Kannst du Ticket X übernehmen?" - anwendung: "Normalfall" - - - stufe: 2 - name: "Direktive Zuweisung" - beschreibung: "Bitte übernimm Ticket X, weil..." - anwendung: "Bei Dringlichkeit oder fehlender Reaktion" - dokumentation: "Begründung im Ticket" - - - stufe: 3 - name: "Eskalation" - beschreibung: "Weiterleitung an Support Manager" - anwendung: "Bei Verweigerung oder strukturellem Problem" - - transparenz_dashboard: - - beschreibung: | - Ein zentrales, für alle sichtbares Dashboard zeigt in Echtzeit - den Status der Queues und Agents. - - inhalte: - - "Anzahl Tickets pro Pool" - - "Aktuelle Ticket-Verteilung pro Agent" - - "Liegezeiten kritischer Tickets" - - "Blockierte Tickets mit Grund" - - "Tages-Statistiken (geschlossen, neu, eskaliert)" - - anforderung: "Muss im ITSM-Tool oder separat implementiert werden" - - offener_punkt: "OPEN-SD-002" - -# ============================================================================= -# ARBEITSORGANISATION -# ============================================================================= - -arbeitsorganisation: - - # --------------------------------------------------------------------------- - # SINGLE-PIECE-FLOW - # --------------------------------------------------------------------------- - single_piece_flow: - - beschreibung: | - Das Single-Piece-Flow-Prinzip begrenzt die gleichzeitige Bearbeitung - auf maximal 2 Tickets pro Agent. Dies reduziert Context-Switching - und verbessert Durchlaufzeiten. - - regel: - primaer_ticket: "Hauptfokus (80% der Zeit)" - sekundaer_ticket: "Nur wenn Primär-Ticket blockiert ist" - maximum: "2 Tickets gleichzeitig" - - begruendung: - - "Reduziert Context-Switching" - - "Verbessert Durchlaufzeiten" - - "Erhöht Lösungsqualität" - - "Macht Fortschritt sichtbar" - - ausnahmen: - - "Kurzfristige Unterbrechung für P1-Ticket" - - "Warten auf Nutzer-Rückmeldung (Clock-Stop)" - - # --------------------------------------------------------------------------- - # COMMITMENT-PRINZIP - # --------------------------------------------------------------------------- - commitment_prinzip: - - beschreibung: | - Das Commitment-Prinzip etabliert klare Ownership: Ein gezogenes - Ticket gehört dem Agent bis zur Lösung oder formalen Übergabe. - - grundregel: "Ticket gezogen = Ticket owned" - - governance: "SSM-G-07" - - legitime_ausgaenge: - - ausgang: "GELÖST" - beschreibung: "Ticket wird mit Lösung geschlossen" - - - ausgang: "ESKALIERT" - beschreibung: "Formale Weitergabe mit dokumentierter Begründung" - anforderung: "Definition of Handover (DoH) muss erfüllt sein" - referenz: "SSM-G-08" - - - ausgang: "GEPARKT" - beschreibung: "Wartet auf externe Aktion" - gruende: - - "WARTEN_NUTZER" - - "WARTEN_EXTERN" - - "WARTEN_CHANGE" - - verboten: - - "Stille Rückgabe in den Pool" - - "Ownership-loses Ticket" - - "Weitergabe ohne Dokumentation" - - # --------------------------------------------------------------------------- - # ENABLEMENT-PHILOSOPHIE (EIGENVERANTWORTLICHES ARBEITEN) - # --------------------------------------------------------------------------- - enablement_philosophie: - - beschreibung: | - Der Service Desk verfolgt eine Enablement-Philosophie: Agents sind - eigenverantwortliche Problemlöser, nicht "Ticket-Schubser". Der Agent - entscheidet selbst über sein Vorgehen, die SLA gibt den Rahmen vor. - - konzept: - - "Agent entscheidet eigenverantwortlich über sein Vorgehen" - - "Die SLA gibt den zeitlichen Rahmen vor" - - "Eskalation ist eine Option, keine Pflicht bei Unklarheit" - - "Dokumentation von Erkenntnissen ist erwünscht (nicht verpflichtend)" - - bei_standard_tickets: - beschreibung: "Dokumentierte Lösung anwenden, schnelle Durchlaufzeit" - - bei_analyse_tickets: - beschreibung: | - Agent führt eigenständige Diagnose durch. Die SLA gibt den - zeitlichen Rahmen vor. Bei fehlender Lösung: Eskalation an L2. - - Die Charakteristik ANALYSE ist ein Label für Reporting, - keine Steuerungsgröße für einen separaten Pool. - - hinweis: | - Version 0.2: Das bisherige "Explorationsbudget" (90-120 Min) als - eigenständiges Konzept entfällt. Die SLA gibt den Zeitrahmen vor, - innerhalb dessen der Agent arbeitet. Die Enablement-Philosophie - (Agent darf eigenverantwortlich arbeiten) bleibt erhalten. - - referenz: "ssm_design-zieldimensionen.yaml → LS-02" - -# ============================================================================= -# TEAM-ORGANISATION -# ============================================================================= - -team_organisation: - - status: "EMPFEHLUNG" - - hinweis: | - Die Team-Organisation ist eine operative Entscheidung von DIGIT. - Die folgenden Strukturen sind Empfehlungen basierend auf dem - Referenzmodell. - - # --------------------------------------------------------------------------- - # MEETING-STRUKTUR - # --------------------------------------------------------------------------- - meeting_struktur: - - taeglich: - name: "Stand-up" - dauer: "15 Minuten" - zeitpunkt: "Empfohlen: Beginn der Kernzeit" - teilnehmer: "Alle anwesenden Agents, Queue-Koordinator" - agenda: - - "Pool-Status Review" - - "Blockierte Tickets" - - "Kapazitäten des Tages" - - "Besondere Vorkommnisse" - - "Kurze Abstimmungen" - - woechentlich: - name: "Team-Meeting" - dauer: "60 Minuten" - teilnehmer: "Gesamtes Team, Support Manager" - agenda: - - "Wochen-Review (Kennzahlen)" - - "Prozess-Verbesserungen" - - "Knowledge-Sharing" - - "Ankündigungen" - - "Team-Themen" - - monatlich: - name: "Service Owner Review" - dauer: "2 Stunden" - teilnehmer: "Service Owner, First Level Vertreter, ggf. Second Level" - agenda: - - "Service-spezifische Themen" - - "Dokumentations-Review" - - "Verbesserungspotentiale" - - "Schulungsbedarfe" - - governance: "Pflicht, siehe ssm_governance.yaml" - - # --------------------------------------------------------------------------- - # SCHICHTPLANUNG - # --------------------------------------------------------------------------- - schichtplanung: - - status: "ANFORDERUNGEN" - - anforderungen: - - mindestbesetzung: - beschreibung: "Minimale Besetzung während Servicezeiten" - anforderung: "Mindestens 2 Agents" - begruendung: "Telefon + Ticket-Bearbeitung + Vertretung" - - vertretungsregelung: - beschreibung: "Abdeckung bei Abwesenheit" - anforderungen: - - "Urlaub muss mit Mindestvorlauf angekündigt werden" - - "Krankheitsvertretung muss geregelt sein" - - "Queue-Koordinator-Stellvertretung muss definiert sein" - - peak_zeiten: - beschreibung: "Erhöhte Besetzung zu Stoßzeiten" - empfehlung: "Identifikation typischer Peak-Zeiten aus Ticket-Daten" - anforderung: "Berücksichtigung bei Schichtplanung" - - offener_punkt: "OPEN-SD-003" - -# ============================================================================= -# QUALITÄTSSTANDARDS -# ============================================================================= - -qualitaetsstandards: - - status: "ANFORDERUNGEN" - - # --------------------------------------------------------------------------- - # REAKTIONSZEITEN - # --------------------------------------------------------------------------- - reaktionszeiten: - - beschreibung: | - Zielzeiten für die erste qualifizierte Reaktion auf Anfragen. - Konkrete Werte sind mit SLM abzustimmen. - - anforderungen: - - kanal: "Telefon" - ziel: "Annahme innerhalb 30 Sekunden (während Servicezeit)" - - - kanal: "E-Mail" - ziel: "Erste Reaktion innerhalb SLA-Reaktionszeit" - - - kanal: "Portal" - ziel: "Automatische Bestätigung sofort, Bearbeitung gem. Priorität" - - referenz: "spm_practice_service-level-management.yaml" - - # --------------------------------------------------------------------------- - # KOMMUNIKATIONSSTANDARDS - # --------------------------------------------------------------------------- - kommunikationsstandards: - - beschreibung: | - Qualitätsanforderungen an die Kommunikation mit Nutzern. - - prinzipien: - - "Freundlich und professionell" - - "Verständliche Sprache (kein IT-Jargon)" - - "Proaktive Updates bei längerer Bearbeitung" - - "Klare Aussagen zu nächsten Schritten" - - "Erreichbarkeit für Rückfragen" - - bei_eskalation: - - "Nutzer über Eskalation informieren" - - "Neuen Ansprechpartner nennen (wenn bekannt)" - - "Erwartbare Bearbeitungszeit kommunizieren" - - bei_wartezeit: - - "Regelmäßige Status-Updates (mindestens alle 2 Arbeitstage)" - - "Proaktive Information bei Verzögerungen" - - "Transparenz über Gründe" - - # --------------------------------------------------------------------------- - # DOKUMENTATIONSSTANDARDS - # --------------------------------------------------------------------------- - dokumentationsstandards: - - beschreibung: | - Anforderungen an die Ticket-Dokumentation. - - mindestanforderungen: - - "Vollständige Problembeschreibung" - - "Durchgeführte Diagnose-Schritte" - - "Lösung oder Eskalationsgrund" - - "Kommunikation mit Nutzer dokumentiert" - - referenz: "ssm_schema_ticket.yaml" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - - modul: "sub-practice_incident-management.yaml" - art: "führt aus" - beschreibung: "Service Desk führt Incident-Prozess operativ aus" - - - modul: "sub-practice_request-management.yaml" - art: "führt aus" - beschreibung: "Service Desk führt Request-Prozess operativ aus" - - - modul: "ssm_klassifikation-priorisierung.yaml" - art: "verwendet" - beschreibung: "Pool-System, Prioritäts-Matrix" - - - modul: "ssm_rollen.yaml" - art: "implementiert" - beschreibung: "First Level Agent, Queue-Koordinator" - - - modul: "ssm_wissensmanagement.yaml" - art: "nutzt und pflegt" - beschreibung: "KB-Nutzung und Ebene-3-Beiträge" - - - modul: "ssm_governance.yaml" - art: "wird gesteuert durch" - beschreibung: "Eskalationslogik, Reporting" - - extern: - - - partner: "Second Level Support" - kontext: "Funktionale Eskalation" - schnittstelle: "Definition of Handover (DoH)" - - - partner: "Service Owner" - kontext: "Befähigung, Dokumentation, Service-Reviews" - frequenz: "Monatlich" - - - partner: "Nutzer / Anwender" - kontext: "Alle IT-Anfragen und Störungsmeldungen" - kanaele: ["Portal", "E-Mail", "Telefon", "Walk-in"] - - - partner: "ITSM-Tool" - kontext: "Ticket-Erfassung, Queue-Management, Dashboard" - status: "Tool-Auswahl ausstehend" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-SD-001" - thema: "Konkrete Servicezeiten" - beschreibung: | - Die konkreten Servicezeiten (Kernzeit, erweiterte Erreichbarkeit) - müssen mit DIGIT festgelegt werden. - prioritaet: "hoch" - status: "Mit DIGIT zu klären" - - - id: "OPEN-SD-002" - thema: "Dashboard-Implementierung" - beschreibung: | - Das Transparenz-Dashboard muss im ITSM-Tool oder als separate - Lösung implementiert werden. - prioritaet: "mittel" - status: "Abhängig von Tool-Auswahl" - - - id: "OPEN-SD-003" - thema: "Schichtplanung" - beschreibung: | - Konkrete Schichtplanung inkl. Vertretungsregelung muss mit - DIGIT erarbeitet werden. - prioritaet: "mittel" - status: "Operative Planung" - - - id: "OPEN-SD-004" - thema: "Telefonie-Integration" - beschreibung: | - Integration der Telefonie (ACD, Warteschlange, Statistik) mit - dem ITSM-Tool. - prioritaet: "mittel" - status: "Technische Klärung" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.2" - datum: "2026-01-28" - aenderung: | - Anpassung an vereinfachtes Pool-Modell: - - Triage: Drei-Pool-Struktur (Sofort, Standard, Projekt) - - Analyse-Pool entfällt, ANALYSE-Tickets gehen in Standard-Pool - - "Indifferenzraum" umbenannt zu "Enablement-Philosophie" - - Explorationsbudget entfällt als eigenständiges Konzept - - SLA gibt Zeitrahmen vor, Agent arbeitet eigenverantwortlich - autor: "DIGITOM-Projekt" - - - version: "0.1" - datum: "2025-12-07" - aenderung: "Initiale Erstellung" +# ============================================================================= +# SUB-PRACTICE: SERVICE DESK +# ============================================================================= + +metadata: + id: "SD" + name: "Service Desk" + version: "0.2" + status: "draft" + erstellt: "2025-12-07" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + + parent_practice: "practice_service-support-management" + + itil4_referenz: "Service Desk Practice" + yasm_referenz: "LP4.6.1" + + blueprint_referenz: "service-lifecycle_service-support.yaml" + relevante_aktivitaeten: ["ss_01", "ss_02", "ss_03"] + + design_referenz: "ssm_design-zieldimensionen.yaml" + relevante_saeulen: ["LS-01", "LS-02", "LS-03", "LS-04"] + + hinweis: | + Der Service Desk ist keine Prozess-Practice wie Incident oder Request + Management, sondern eine organisatorische Capability. Dieses Dokument + beschreibt die organisatorischen Rahmenbedingungen, nicht die Prozesse. + +# ============================================================================= +# ZWECK & SELBSTVERSTÄNDNIS +# ============================================================================= + +zweck: + + definition: | + Der Service Desk ist der zentrale Zugangspunkt für alle IT-bezogenen + Anfragen und Störungsmeldungen. Er fungiert als Single Point of Contact + (SPOC) zwischen Nutzern und der IT-Organisation. + + selbstverstaendnis: + + enablement_paradigma: + beschreibung: | + Der Service Desk verfolgt ein Enablement-Paradigma: Der First Level + agiert als aktiver Problemlöser und Befähiger, nicht als reiner + Ticket-Verteiler ("Ticket-Schubser"). + + prinzipien: + - "Agents gehen selbst auf Detektivsuche und schaffen Lösungen" + - "Enge Zusammenarbeit mit Second Level und Service Ownern" + - "Systematisches Lernen durch legitimierte Exploration" + - "Befähigung der Nutzer, nicht nur Symptombehandlung" + + governance: "SSM-G-03 (Explorative-Diagnose-Legitimation)" + + kernfunktionen: + - "Zentrale Anlaufstelle für alle IT-Anfragen" + - "Qualifizierte Erstanalyse und Triage" + - "First-Level-Resolution für definierte Standardfälle" + - "Koordinierte Weiterleitung bei Eskalation" + - "Proaktive Kommunikation mit Nutzern" + - "Beitrag zum organisatorischen Wissensaufbau" + + ziele: + - "Schnelle und kompetente Erstreaktion auf Nutzeranfragen" + - "Hohe First Contact Resolution Rate" + - "Transparente Kommunikation über Ticket-Status" + - "Kontinuierliche Befähigung des First Level" + - "Systematische Erfassung aller IT-Kontakte" + +# ============================================================================= +# SYSTEMGRENZE +# ============================================================================= + +systemgrenze: + + beschreibung: | + Der Service Desk etabliert eine "harte Grenze" als formale Regel: + Alle IT-Anfragen müssen durch den Service Desk. Diese Grenze gilt + als Referenzpunkt, mit dem Verständnis, dass informelle Strukturen + existieren werden. + + harte_grenze: + + prinzip: "Keine IT-Bearbeitung ohne Ticket" + + konsequenzen: + - "Alle Anfragen werden als Ticket erfasst" + - "Auch mündliche Anfragen führen zu Ticket-Erstellung" + - "Rückkanal immer über Ticketsystem" + - "Dokumentation aller Aktivitäten im Ticket" + + begruendung: | + Die harte Grenze ermöglicht: + - Vollständige Transparenz über IT-Aufwände + - Messbarkeit und Steuerbarkeit + - Nachvollziehbarkeit für Nutzer und IT + - Basis für kontinuierliche Verbesserung + + umgang_informelle_strukturen: + + akzeptanz_der_realitaet: + beschreibung: | + Informelle Strukturen werden existieren. "Lieblings-Admins" werden + direkt kontaktiert, VIPs werden Sonderwege suchen. Das Modell + akzeptiert diese Realität, etabliert aber einen Reflexionsmechanismus. + + beispiele: + - "Direkter Anruf bei bekanntem L2-Kollegen" + - "E-Mail direkt an Spezialisten statt Service Desk" + - "Flurfunk-Anfragen" + + reflexionsmechanismus: + beschreibung: "Service Owner beobachten Umgehungen" + bewertung: + - "Einmalig oder systematisch?" + - "Verursacht das Probleme?" + - "Gibt es einen legitimen Grund?" + + intervention_nur_bei: "Problematischen Mustern" + + interventionsstufen: + - stufe: 1 + aktion: "Gespräch mit beteiligten Personen" + - stufe: 2 + aktion: "Formale Erinnerung an Prozesse" + - stufe: 3 + aktion: "Eskalation an Führungsebene" + - stufe: 4 + aktion: "Anpassung der Prozesse (wenn sinnvoll)" + +# ============================================================================= +# KANALMANAGEMENT +# ============================================================================= + +kanalmanagement: + + beschreibung: | + Definition der Eingangskanäle und wie Anfragen über diese Kanäle + in das Ticketsystem überführt werden. + + eingangskanal: + + - kanal: "Service Portal" + typ: "Self-Service" + beschreibung: "Webformular im Intranet" + ticket_erstellung: "Automatisch durch Nutzer" + empfohlen: true + vorteile: + - "Strukturierte Erfassung" + - "Reduziert Rückfragen" + - "24/7 verfügbar" + + - kanal: "E-Mail" + typ: "Asynchron" + beschreibung: "E-Mail an zentrale Service-Desk-Adresse" + ticket_erstellung: "Automatisch oder durch Agent" + hinweis: | + E-Mails direkt an einzelne Agents sollen an die zentrale + Adresse weitergeleitet werden. + + - kanal: "Telefon" + typ: "Synchron" + beschreibung: "Anruf bei Service-Desk-Hotline" + ticket_erstellung: "Durch Agent während/nach Gespräch" + hinweis: | + Agent erstellt Ticket während des Gesprächs oder unmittelbar + danach. Keine Bearbeitung ohne Ticket-Dokumentation. + + - kanal: "Persönlich (Walk-in)" + typ: "Synchron" + beschreibung: "Direkter Besuch während Bürozeiten" + ticket_erstellung: "Durch Agent" + hinweis: "Nur während definierter Servicezeiten" + + ticket_pflicht: + + regel: | + Jede Anfrage, unabhängig vom Kanal, führt zu einem Ticket. + Auch wenn die Lösung im Erstkontakt erfolgt, wird dokumentiert. + + ausnahmen: + - "Reine Informationsfragen, die in <2 Minuten beantwortet sind" + - "Weiterleitung an andere Stelle (kein IT-Thema)" + + bei_ausnahmen: "Kurze Notiz im Tagesprotokoll empfohlen" + +# ============================================================================= +# SERVICEZEITEN & ERREICHBARKEIT +# ============================================================================= + +servicezeiten: + + status: "ANFORDERUNGEN" + + hinweis: | + Die konkreten Servicezeiten sind eine operative Entscheidung von DIGIT. + Dieses Dokument definiert die Anforderungen und Rahmenbedingungen. + + anforderungen: + + kernservicezeit: + beschreibung: "Zeitraum mit voller Service-Desk-Besetzung" + empfehlung: "Mindestens Kernarbeitszeit der Stadtverwaltung" + anforderung: "Telefonische Erreichbarkeit muss gewährleistet sein" + + erweiterte_erreichbarkeit: + beschreibung: "Zeitraum mit eingeschränkter Erreichbarkeit" + optionen: + - "E-Mail-Monitoring außerhalb Kernzeit" + - "Rufbereitschaft für kritische Systeme" + status: "Mit DIGIT zu klären" + + mindestbesetzung: + beschreibung: "Minimale Anzahl Agents während Kernzeit" + anforderung: | + Mindestens 2 Agents zur Abdeckung von: + - Telefonkanal + - Ticket-Bearbeitung + - Vertretung bei Kurzabwesenheit + + bei_unterschreitung: "Eskalation an Queue-Koordinator" + + kommunikation: + + anforderung: | + Servicezeiten müssen den Nutzern klar kommuniziert werden. + + kanaele: + - "Intranet-Seite des Service Desk" + - "Automatische Antwort bei E-Mail außerhalb Servicezeiten" + - "Ansage bei Telefon außerhalb Servicezeiten" + + offener_punkt: "OPEN-SD-001" + +# ============================================================================= +# EINGANGSSTEUERUNG (TRIAGE) +# ============================================================================= + +eingangssteuerung: + + beschreibung: | + Die Eingangssteuerung (Triage) ist der erste Schritt bei jeder Anfrage. + Sie bestimmt den Ticket-Typ, die initiale Klassifikation und die + Pool-Zuweisung. + + triage_prozess: + + schritt_1_ticket_typ: + frage: "Um was für eine Anfrage handelt es sich?" + entscheidung: + stoerung: "→ Incident (P-04)" + anfrage_im_katalog: "→ Request (P-05)" + anfrage_nicht_im_katalog: "→ Demand (DPM)" + ungewiss: "→ Als Incident erfassen, später umklassifizieren" + + referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen" + + schritt_2_klassifikation: + beschreibung: "Impact, Urgency und Priorität bestimmen" + + bei_incident: + - "Impact bewerten (Hoch/Normal/Niedrig)" + - "Urgency bewerten (Hoch/Normal/Niedrig)" + - "Priorität aus Matrix ableiten" + + bei_request: + - "Katalog-Eintrag identifizieren" + - "Service-Kategorie übernehmen" + - "Genehmigungsanforderung prüfen" + + referenz: "ssm_klassifikation-priorisierung.yaml" + + schritt_3_pool_zuweisung: + beschreibung: "Ticket dem richtigen Pool zuweisen" + + pools: + - pool: "Sofort-Pool" + kriterien: "P1 (alle Charakteristiken)" + ziel: "Sofortige Bearbeitung" + + - pool: "Standard-Pool" + kriterien: "P2-P4 mit Charakteristik STANDARD oder ANALYSE" + ziel: "Bearbeitung gemäß SLA" + + - pool: "Projekt-Pool" + kriterien: "Charakteristik PROJEKT (planbar, >1 Tag Aufwand)" + ziel: "Koordinierte Bearbeitung" + + hinweis: | + Version 0.2: Der bisherige Analyse-Pool entfällt. + ANALYSE-Tickets werden im Standard-Pool bearbeitet. + Die Charakteristik ANALYSE bleibt als Label für Reporting erhalten. + + referenz: "ssm_klassifikation-priorisierung.yaml → pool_modell" + + schritt_4_erste_reaktion: + beschreibung: "Nutzer über Ticket-Erstellung informieren" + inhalt: + - "Ticket-Nummer" + - "Kurze Bestätigung des Anliegens" + - "Erwartbare nächste Schritte" + - "Kontaktmöglichkeit bei Rückfragen" + + qualitaetsanforderung: + + beschreibung: | + Die Triage-Qualität bestimmt maßgeblich die Effizienz der + nachfolgenden Bearbeitung. Fehlerhafte Klassifikation führt + zu Verzögerungen und Nacharbeit. + + schulungsbedarf: "Regelmäßige Schulung der Triage-Kriterien" + + feedback_loop: | + Bei häufigen Fehlklassifikationen: Anpassung der Kriterien + oder zusätzliche Schulung. + +# ============================================================================= +# QUEUE-KOORDINATION +# ============================================================================= + +queue_koordination: + + beschreibung: | + Der Queue-Koordinator ist verantwortlich für die operative Steuerung + der Ticket-Queues. Er überwacht Workload, priorisiert innerhalb der + Pools und koordiniert bei Engpässen oder Konflikten. + + rolle: + referenz: "ssm_rollen.yaml → queue_koordinator" + + besetzung: + primaer: "Definierte Person (z.B. Gruppenleiter)" + stellvertretung: "Muss für Abwesenheiten definiert sein" + modell: "Kann dediziert, rotierend oder in Teilzeit sein" + + offener_punkt: "OPEN-ROLLEN-001" + + ueberwachungsaufgaben: + + pool_monitoring: + beschreibung: "Kontinuierliche Überwachung aller Pools" + fokus: + - "Anzahl Tickets pro Pool" + - "Liegezeiten kritischer Tickets" + - "Verteilung auf Agents" + + werkzeug: "Dashboard (Echtzeit)" + + kapazitaetssteuerung: + beschreibung: "Balance zwischen Pools und Agents" + aktivitaeten: + - "Erkennen von Kapazitätsengpässen" + - "Umverteilung bei Ungleichgewicht" + - "Eskalation bei Überlast" + + sla_ueberwachung: + beschreibung: "Überwachung der SLA-Einhaltung" + aktivitaeten: + - "Frühwarnung bei SLA-Gefährdung" + - "Priorisierung gefährdeter Tickets" + - "Eskalation bei drohender Verletzung" + + interventionsregeln: + + beschreibung: | + Der Queue-Koordinator greift aktiv ein, wenn definierte + Schwellwerte erreicht werden. + + trigger: + + - situation: "Ticket >15 Min im Sofort-Pool" + aktion: "Sofortige Intervention, Zuweisung erzwingen" + eskalation: "Bei Ressourcenmangel → Support Manager" + + - situation: "Ticket >30 Min im Sofort-Pool" + aktion: "Alarmierung Support Manager" + eskalation: "Automatisch" + + - situation: "Agent hat 2 blockierte Tickets" + aktion: "Prüfung: Warum blockiert? Unterstützung anbieten" + eskalation: "Bei strukturellem Problem → Support Manager" + + - situation: "Standard-Pool >20 Tickets" + aktion: "Kapazitätsalarm, Priorisierung, ggf. Umverteilung" + eskalation: "Bei anhaltendem Überlauf → Support Manager" + + - situation: "Extreme Ungleichverteilung" + aktion: "Ausgleich zwischen Agents" + eskalation: "Keine, direkte Koordination" + + - situation: "Übergabe nicht akzeptiert nach 4h" + aktion: "Klärung mit beteiligten Agents" + eskalation: "Bei Verweigerung → Support Manager" + + interventionsstufen: + + - stufe: 1 + name: "Anfrage" + beschreibung: "Kannst du Ticket X übernehmen?" + anwendung: "Normalfall" + + - stufe: 2 + name: "Direktive Zuweisung" + beschreibung: "Bitte übernimm Ticket X, weil..." + anwendung: "Bei Dringlichkeit oder fehlender Reaktion" + dokumentation: "Begründung im Ticket" + + - stufe: 3 + name: "Eskalation" + beschreibung: "Weiterleitung an Support Manager" + anwendung: "Bei Verweigerung oder strukturellem Problem" + + transparenz_dashboard: + + beschreibung: | + Ein zentrales, für alle sichtbares Dashboard zeigt in Echtzeit + den Status der Queues und Agents. + + inhalte: + - "Anzahl Tickets pro Pool" + - "Aktuelle Ticket-Verteilung pro Agent" + - "Liegezeiten kritischer Tickets" + - "Blockierte Tickets mit Grund" + - "Tages-Statistiken (geschlossen, neu, eskaliert)" + + anforderung: "Muss im ITSM-Tool oder separat implementiert werden" + + offener_punkt: "OPEN-SD-002" + +# ============================================================================= +# ARBEITSORGANISATION +# ============================================================================= + +arbeitsorganisation: + + # --------------------------------------------------------------------------- + # SINGLE-PIECE-FLOW + # --------------------------------------------------------------------------- + single_piece_flow: + + beschreibung: | + Das Single-Piece-Flow-Prinzip begrenzt die gleichzeitige Bearbeitung + auf maximal 2 Tickets pro Agent. Dies reduziert Context-Switching + und verbessert Durchlaufzeiten. + + regel: + primaer_ticket: "Hauptfokus (80% der Zeit)" + sekundaer_ticket: "Nur wenn Primär-Ticket blockiert ist" + maximum: "2 Tickets gleichzeitig" + + begruendung: + - "Reduziert Context-Switching" + - "Verbessert Durchlaufzeiten" + - "Erhöht Lösungsqualität" + - "Macht Fortschritt sichtbar" + + ausnahmen: + - "Kurzfristige Unterbrechung für P1-Ticket" + - "Warten auf Nutzer-Rückmeldung (Clock-Stop)" + + # --------------------------------------------------------------------------- + # COMMITMENT-PRINZIP + # --------------------------------------------------------------------------- + commitment_prinzip: + + beschreibung: | + Das Commitment-Prinzip etabliert klare Ownership: Ein gezogenes + Ticket gehört dem Agent bis zur Lösung oder formalen Übergabe. + + grundregel: "Ticket gezogen = Ticket owned" + + governance: "SSM-G-07" + + legitime_ausgaenge: + - ausgang: "GELÖST" + beschreibung: "Ticket wird mit Lösung geschlossen" + + - ausgang: "ESKALIERT" + beschreibung: "Formale Weitergabe mit dokumentierter Begründung" + anforderung: "Definition of Handover (DoH) muss erfüllt sein" + referenz: "SSM-G-08" + + - ausgang: "GEPARKT" + beschreibung: "Wartet auf externe Aktion" + gruende: + - "WARTEN_NUTZER" + - "WARTEN_EXTERN" + - "WARTEN_CHANGE" + + verboten: + - "Stille Rückgabe in den Pool" + - "Ownership-loses Ticket" + - "Weitergabe ohne Dokumentation" + + # --------------------------------------------------------------------------- + # ENABLEMENT-PHILOSOPHIE (EIGENVERANTWORTLICHES ARBEITEN) + # --------------------------------------------------------------------------- + enablement_philosophie: + + beschreibung: | + Der Service Desk verfolgt eine Enablement-Philosophie: Agents sind + eigenverantwortliche Problemlöser, nicht "Ticket-Schubser". Der Agent + entscheidet selbst über sein Vorgehen, die SLA gibt den Rahmen vor. + + konzept: + - "Agent entscheidet eigenverantwortlich über sein Vorgehen" + - "Die SLA gibt den zeitlichen Rahmen vor" + - "Eskalation ist eine Option, keine Pflicht bei Unklarheit" + - "Dokumentation von Erkenntnissen ist erwünscht (nicht verpflichtend)" + + bei_standard_tickets: + beschreibung: "Dokumentierte Lösung anwenden, schnelle Durchlaufzeit" + + bei_analyse_tickets: + beschreibung: | + Agent führt eigenständige Diagnose durch. Die SLA gibt den + zeitlichen Rahmen vor. Bei fehlender Lösung: Eskalation an L2. + + Die Charakteristik ANALYSE ist ein Label für Reporting, + keine Steuerungsgröße für einen separaten Pool. + + hinweis: | + Version 0.2: Das bisherige "Explorationsbudget" (90-120 Min) als + eigenständiges Konzept entfällt. Die SLA gibt den Zeitrahmen vor, + innerhalb dessen der Agent arbeitet. Die Enablement-Philosophie + (Agent darf eigenverantwortlich arbeiten) bleibt erhalten. + + referenz: "ssm_design-zieldimensionen.yaml → LS-02" + +# ============================================================================= +# TEAM-ORGANISATION +# ============================================================================= + +team_organisation: + + status: "EMPFEHLUNG" + + hinweis: | + Die Team-Organisation ist eine operative Entscheidung von DIGIT. + Die folgenden Strukturen sind Empfehlungen basierend auf dem + Referenzmodell. + + # --------------------------------------------------------------------------- + # MEETING-STRUKTUR + # --------------------------------------------------------------------------- + meeting_struktur: + + taeglich: + name: "Stand-up" + dauer: "15 Minuten" + zeitpunkt: "Empfohlen: Beginn der Kernzeit" + teilnehmer: "Alle anwesenden Agents, Queue-Koordinator" + agenda: + - "Pool-Status Review" + - "Blockierte Tickets" + - "Kapazitäten des Tages" + - "Besondere Vorkommnisse" + - "Kurze Abstimmungen" + + woechentlich: + name: "Team-Meeting" + dauer: "60 Minuten" + teilnehmer: "Gesamtes Team, Support Manager" + agenda: + - "Wochen-Review (Kennzahlen)" + - "Prozess-Verbesserungen" + - "Knowledge-Sharing" + - "Ankündigungen" + - "Team-Themen" + + monatlich: + name: "Service Owner Review" + dauer: "2 Stunden" + teilnehmer: "Service Owner, First Level Vertreter, ggf. Second Level" + agenda: + - "Service-spezifische Themen" + - "Dokumentations-Review" + - "Verbesserungspotentiale" + - "Schulungsbedarfe" + + governance: "Pflicht, siehe ssm_governance.yaml" + + # --------------------------------------------------------------------------- + # SCHICHTPLANUNG + # --------------------------------------------------------------------------- + schichtplanung: + + status: "ANFORDERUNGEN" + + anforderungen: + + mindestbesetzung: + beschreibung: "Minimale Besetzung während Servicezeiten" + anforderung: "Mindestens 2 Agents" + begruendung: "Telefon + Ticket-Bearbeitung + Vertretung" + + vertretungsregelung: + beschreibung: "Abdeckung bei Abwesenheit" + anforderungen: + - "Urlaub muss mit Mindestvorlauf angekündigt werden" + - "Krankheitsvertretung muss geregelt sein" + - "Queue-Koordinator-Stellvertretung muss definiert sein" + + peak_zeiten: + beschreibung: "Erhöhte Besetzung zu Stoßzeiten" + empfehlung: "Identifikation typischer Peak-Zeiten aus Ticket-Daten" + anforderung: "Berücksichtigung bei Schichtplanung" + + offener_punkt: "OPEN-SD-003" + +# ============================================================================= +# QUALITÄTSSTANDARDS +# ============================================================================= + +qualitaetsstandards: + + status: "ANFORDERUNGEN" + + # --------------------------------------------------------------------------- + # REAKTIONSZEITEN + # --------------------------------------------------------------------------- + reaktionszeiten: + + beschreibung: | + Zielzeiten für die erste qualifizierte Reaktion auf Anfragen. + Konkrete Werte sind mit SLM abzustimmen. + + anforderungen: + - kanal: "Telefon" + ziel: "Annahme innerhalb 30 Sekunden (während Servicezeit)" + + - kanal: "E-Mail" + ziel: "Erste Reaktion innerhalb SLA-Reaktionszeit" + + - kanal: "Portal" + ziel: "Automatische Bestätigung sofort, Bearbeitung gem. Priorität" + + referenz: "spm_practice_service-level-management.yaml" + + # --------------------------------------------------------------------------- + # KOMMUNIKATIONSSTANDARDS + # --------------------------------------------------------------------------- + kommunikationsstandards: + + beschreibung: | + Qualitätsanforderungen an die Kommunikation mit Nutzern. + + prinzipien: + - "Freundlich und professionell" + - "Verständliche Sprache (kein IT-Jargon)" + - "Proaktive Updates bei längerer Bearbeitung" + - "Klare Aussagen zu nächsten Schritten" + - "Erreichbarkeit für Rückfragen" + + bei_eskalation: + - "Nutzer über Eskalation informieren" + - "Neuen Ansprechpartner nennen (wenn bekannt)" + - "Erwartbare Bearbeitungszeit kommunizieren" + + bei_wartezeit: + - "Regelmäßige Status-Updates (mindestens alle 2 Arbeitstage)" + - "Proaktive Information bei Verzögerungen" + - "Transparenz über Gründe" + + # --------------------------------------------------------------------------- + # DOKUMENTATIONSSTANDARDS + # --------------------------------------------------------------------------- + dokumentationsstandards: + + beschreibung: | + Anforderungen an die Ticket-Dokumentation. + + mindestanforderungen: + - "Vollständige Problembeschreibung" + - "Durchgeführte Diagnose-Schritte" + - "Lösung oder Eskalationsgrund" + - "Kommunikation mit Nutzer dokumentiert" + + referenz: "ssm_schema_ticket.yaml" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + + - modul: "sub-practice_incident-management.yaml" + art: "führt aus" + beschreibung: "Service Desk führt Incident-Prozess operativ aus" + + - modul: "sub-practice_request-management.yaml" + art: "führt aus" + beschreibung: "Service Desk führt Request-Prozess operativ aus" + + - modul: "ssm_klassifikation-priorisierung.yaml" + art: "verwendet" + beschreibung: "Pool-System, Prioritäts-Matrix" + + - modul: "ssm_rollen.yaml" + art: "implementiert" + beschreibung: "First Level Agent, Queue-Koordinator" + + - modul: "ssm_wissensmanagement.yaml" + art: "nutzt und pflegt" + beschreibung: "KB-Nutzung und Ebene-3-Beiträge" + + - modul: "ssm_governance.yaml" + art: "wird gesteuert durch" + beschreibung: "Eskalationslogik, Reporting" + + extern: + + - partner: "Second Level Support" + kontext: "Funktionale Eskalation" + schnittstelle: "Definition of Handover (DoH)" + + - partner: "Service Owner" + kontext: "Befähigung, Dokumentation, Service-Reviews" + frequenz: "Monatlich" + + - partner: "Nutzer / Anwender" + kontext: "Alle IT-Anfragen und Störungsmeldungen" + kanaele: ["Portal", "E-Mail", "Telefon", "Walk-in"] + + - partner: "ITSM-Tool" + kontext: "Ticket-Erfassung, Queue-Management, Dashboard" + status: "Tool-Auswahl ausstehend" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-SD-001" + thema: "Konkrete Servicezeiten" + beschreibung: | + Die konkreten Servicezeiten (Kernzeit, erweiterte Erreichbarkeit) + müssen mit DIGIT festgelegt werden. + prioritaet: "hoch" + status: "Mit DIGIT zu klären" + + - id: "OPEN-SD-002" + thema: "Dashboard-Implementierung" + beschreibung: | + Das Transparenz-Dashboard muss im ITSM-Tool oder als separate + Lösung implementiert werden. + prioritaet: "mittel" + status: "Abhängig von Tool-Auswahl" + + - id: "OPEN-SD-003" + thema: "Schichtplanung" + beschreibung: | + Konkrete Schichtplanung inkl. Vertretungsregelung muss mit + DIGIT erarbeitet werden. + prioritaet: "mittel" + status: "Operative Planung" + + - id: "OPEN-SD-004" + thema: "Telefonie-Integration" + beschreibung: | + Integration der Telefonie (ACD, Warteschlange, Statistik) mit + dem ITSM-Tool. + prioritaet: "mittel" + status: "Technische Klärung" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.2" + datum: "2026-01-28" + aenderung: | + Anpassung an vereinfachtes Pool-Modell: + - Triage: Drei-Pool-Struktur (Sofort, Standard, Projekt) + - Analyse-Pool entfällt, ANALYSE-Tickets gehen in Standard-Pool + - "Indifferenzraum" umbenannt zu "Enablement-Philosophie" + - Explorationsbudget entfällt als eigenständiges Konzept + - SLA gibt Zeitrahmen vor, Agent arbeitet eigenverantwortlich + autor: "DIGITOM-Projekt" + + - version: "0.1" + datum: "2025-12-07" + aenderung: "Initiale Erstellung" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-owner.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-owner.yaml index fdd737b..6f2886f 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-owner.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-owner.yaml @@ -1,952 +1,952 @@ -# ============================================================================= -# ROLLENBESCHREIBUNG: SERVICE OWNER -# ============================================================================= -# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/ -# Dateiname: rolle_service-owner.yaml -# ============================================================================= - -metadata: - id: "R-SO" - name: "Service Owner" - kurzform: "SO" - version: "1.0" - status: "entwurf" - erstellt: "2025-12-17" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "rollenbeschreibung" - - beschreibung: | - Vollständige Rollenbeschreibung für den Service Owner. - Konsolidiert Informationen aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, - GOV-007, GOV-008), Practice-Dokumenten (SLM, SCM, Change Enablement, SSM) - und der Kurzreferenz in spm_rollen.yaml. - - referenzen: - kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml -> service_owner" - support_kontext: "03_practices/spm_practice_service-support-management/ssm_rollen.yaml" - vorlage_struktur: "#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml" - service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" - service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml" - slm: "03_practices/spm_practice_service-level-management.yaml" - scm: "03_practices/spm_practice_service-catalog-management.yaml" - change_enablement: "03_practices/spm_practice_change-enablement.yaml" - governance_log: "spm_governance-entscheidungen-log.yaml" - - kontext_tags: - - "service-portfolio-management" - - "service-ownership" - - "lifecycle-management" - - "service-review" - - "change-authority" - -# ============================================================================= -# ROLLENZWECK -# ============================================================================= - -rollenzweck: - - kurz: | - Durchgängige Accountability für einen definierten Service über dessen - gesamten Lifecycle – von der Übernahme in Transition bis zur Stilllegung. - - ausfuehrlich: | - Der Service Owner trägt die End-to-End-Verantwortung für seinen Service - im Rahmen der definierten Governance-Strukturen. Diese Verantwortung - bedeutet Lifecycle-Kontinuität, nicht Entscheidungsautonomie. - - Die Rolle umfasst: - - Fachliche Gesamtverantwortung für Service-Definition, -Qualität und -Entwicklung - - Accountability für Service-Performance und SLA-Einhaltung - - Change Authority für Normal Changes im eigenen Service-Scope - - Operative Accountability für Problem Management im Service-Kontext - - Vertretung des Service in Gremien (SOR, Kundenforum) - - Der Service Owner agiert als "Unternehmer für seinen Service" – - allerdings eingebettet in die kollektive Governance-Architektur des DIGIT - (SOR, Mission Board) und gebunden an Portfolio-Entscheidungen des SPM. - - itil4_referenz: | - "The owner of a service is accountable for the delivery of that service. - Their accountability for the service extends from when the organization - adds it to its portfolio until its eventual retirement." - (ITIL4 Direct, Plan and Improve, 7.3.1.4) - - verantwortung: - ab_wann: "Formale Übernahme bei Gate 1 (Entry Transition)" - fuer: "Service-Qualität, SLA-Einhaltung, Service-Weiterentwicklung" - bis: "Abschluss der Stilllegung (Retirement)" - governance_referenz: "GOV-TR-006" - -# ============================================================================= -# ORGANISATORISCHE EINORDNUNG -# ============================================================================= - -organisatorische_einordnung: - - zuordnung: - funktion: "Service-Portfolio-Management (SPM)" - hinweis: | - Die disziplinarische Zuordnung des SO ist kontextabhängig und - nicht Gegenstand dieser Rollenbeschreibung. Der SO kann - organisatorisch in verschiedenen Abteilungen angesiedelt sein. - - berichtslinie: - fachlich: "Service-Portfolio-Manager (SPM)" - disziplinarisch: "[Kontextabhängig – offener Punkt für MVP]" - - rollentyp: - typ: "Einzelrolle" - beschreibung: | - Jeder Service im Portfolio hat genau einen Service Owner. - Eine Person kann mehrere Services verantworten (Kapazitätsfrage). - - arbeitsmodell: - status: "Offener Punkt für MVP" - hinweis: | - Kapazitätsfragen (wie viele Services pro SO?) und Arbeitsmodell - (Voll-/Teilzeit) sind nicht Teil des MVP und werden später geklärt. - - vertretung: - allgemein: | - Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen - (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung - delegiert werden. - transition_spezifisch: | - Gate-Entscheidungen können bei kurzfristiger SO-Abwesenheit verschoben - werden. Bei Dringlichkeit: Eskalation an SOR. - governance_referenz: "GOV-TR-013" - annahme_markierung: "ANNAHME – Generelle Vertretungslogik abgeleitet aus GOV-TR-013" - -# ============================================================================= -# KERNAUFGABEN -# ============================================================================= - -kernaufgaben: - - # --------------------------------------------------------------------------- - # SERVICE TRANSITION - # --------------------------------------------------------------------------- - service_transition: - - name: "Service Transition Management" - - beschreibung: | - Übernahme neuer oder wesentlich geänderter Services aus der - Service-Entwicklung in den produktiven Betrieb. - - aktivitaeten: - - - aufgabe: "Gate 1 (Entry Transition) – SOR-Vorlage" - raci: "R" - beschreibung: "Vorbereitung und Einreichung der Gate-1-Vorlage bei SPM; Entscheidung liegt bei SOR" - governance_referenz: "GOV-TR-011" - - - aufgabe: "Accountability-Übernahme ab Gate 1" - beschreibung: | - Ab Gate 1 trägt SO die formale Accountability für den Service. - In der Phase bis Gate 2 besteht eine Überlappungszone mit der - Projektleitung (gemeinsame Verantwortung). - governance_referenz: "GOV-TR-006" - - - aufgabe: "Service-Definition erstellen" - raci: "A/R" - beschreibung: "Erstellung der vollständigen Service-Definition nach Schema" - freigabe_durch: "SPM validiert, SOR gibt frei (bei Neuaufnahme)" - governance_referenz: "GOV-007" - - - aufgabe: "Gate 2 (Entry-Prüfung nach Build) – Entscheidung" - raci: "A (Einzelentscheidung)" - beschreibung: "SO prüft Übergabefähigkeit nach Build und entscheidet eigenständig über Freigabe/Zurückweisung" - governance_referenz: "GOV-TR-012" - - - aufgabe: "ELS-Management (Early Life Support)" - raci: "A" - beschreibung: | - Verantwortung für intensivierte Betreuung nach Go-Live. - Entscheidung über ELS-Exit als SO-Einzelentscheidung. - governance_referenz: "GOV-TR-021" - - - aufgabe: "Rollback-Entscheidung (ELS)" - raci: "A (Einzelentscheidung)" - beschreibung: | - Bei fundamentalen Problemen während ELS kann SO eigenständig - Rollback entscheiden. - governance_referenz: "GOV-TR-029" - - referenz: "spm_konzept_service-transition.yaml" - - # --------------------------------------------------------------------------- - # SERVICE REVIEW - # --------------------------------------------------------------------------- - service_review: - - name: "Quartalsweiser Service Review" - - beschreibung: | - Regelmäßige Selbstbewertung des Service anhand des 4-Dimensionen-Modells. - Ableitung von Handlungsempfehlungen und ggf. Einreichung bei SOR. - - aktivitaeten: - - - aufgabe: "Service-Review durchführen" - frequenz: "Quartalsweise" - raci: "A/R" - beschreibung: | - Bewertung des Service anhand der vier Dimensionen: - - SR-D1: Leistungserbringung (SLA-Erfüllung) - - SR-D2: Betriebsstabilität (Incidents, Verfügbarkeit) - - SR-D3: Nutzerzufriedenheit (Feedback, Beschwerden) - - SR-D4: Zukunftsfähigkeit (technisch, strategisch) - governance_referenz: "GOV-SR-001" - - - aufgabe: "Handlungsempfehlung ableiten" - raci: "A/R" - optionen: - - "CONTINUE – Service läuft wie geplant" - - "IMPROVEMENT – Verbesserungsmaßnahmen erforderlich" - - "REDESIGN – Grundlegende Überarbeitung nötig" - - "RETIRE – Stilllegung empfohlen" - governance_referenz: "GOV-SR-001" - - - aufgabe: "SPM informieren" - frequenz: "Nach jedem Review" - raci: "R" - beschreibung: "Informationspflicht an SPM über Review-Ergebnis" - governance_referenz: "GOV-SR-002" - - - aufgabe: "SOR-Vorlage einreichen (bei Bedarf)" - trigger: - - "Mindestens eine Dimension auf ROT" - - "IMPROVEMENT mit Ressourcenbedarf" - - "REDESIGN oder RETIRE" - raci: "R" - governance_referenz: "GOV-SR-003" - - - aufgabe: "Improvement-Maßnahmen definieren und tracken" - raci: "A/R" - beschreibung: "Dokumentation in der Service-Definition (Abschnitt 'laufende_verbesserungen')" - governance_referenz: "GOV-SR-005" - - - aufgabe: "Wirksamkeitsprüfung im Folge-Review" - raci: "A/R" - governance_referenz: "GOV-SR-005" - - referenz: "spm_konzept_service-review.yaml" - - # --------------------------------------------------------------------------- - # SERVICE LEVEL MANAGEMENT - # --------------------------------------------------------------------------- - service_level_management: - - name: "Service Level Management" - - beschreibung: | - Verantwortung für Definition, Vereinbarung, Überwachung und - Review der Service Levels. - - aktivitaeten: - - - aufgabe: "Service-Level-Anforderungen erheben" - phase: "Transition" - raci: "A" - beschreibung: "Verantwortet die Anforderungserhebung aus Kundensicht" - aktivitaets_id: "slm_01" - - - aufgabe: "Service Level Specification (SLS) erstellen" - phase: "Transition" - raci: "A" - beschreibung: "Verantwortet SLS-Inhalt (Übersetzung in messbare Levels)" - aktivitaets_id: "slm_02" - - - aufgabe: "SLA abstimmen und fixieren" - phase: "Transition" - raci: "R" - beschreibung: "Führt Abstimmung mit SLA-Partner, moderiert Usergroup" - aktivitaets_id: "slm_03" - - - aufgabe: "SLA-Freigabe vorbereiten" - phase: "Transition" - raci: "R" - beschreibung: "Bereitet SOR-/MB-Freigabe vor" - aktivitaets_id: "slm_04" - - - aufgabe: "Service Levels überwachen" - phase: "Betrieb" - raci: "A" - beschreibung: "Verantwortet Interpretation der Messergebnisse" - aktivitaets_id: "slm_05" - - - aufgabe: "SLA-Performance reporten" - phase: "Betrieb" - raci: "A" - frequenz: "Monatlich (intern), Quartalsweise (extern)" - beschreibung: "Verantwortet Bericht und Interpretation" - aktivitaets_id: "slm_06" - - - aufgabe: "SLA-Verletzung eskalieren" - phase: "Betrieb" - raci: "R" - beschreibung: "Identifiziert, analysiert, eskaliert (Stufe 1 im Eskalationspfad)" - aktivitaets_id: "slm_07" - - - aufgabe: "Internen SLA-Review durchführen" - phase: "Review" - raci: "A" - frequenz: "Jährlich" - aktivitaets_id: "slm_08" - - - aufgabe: "Externen SLA-Review mit Kunden durchführen" - phase: "Review" - raci: "R" - frequenz: "Jährlich" - beschreibung: "Führt Review durch, moderiert Kundenforum gemeinsam mit SHM" - aktivitaets_id: "slm_09" - governance_referenz: "GOV-012" - - referenz: "spm_practice_service-level-management.yaml" - - # --------------------------------------------------------------------------- - # SERVICE CATALOG MANAGEMENT - # --------------------------------------------------------------------------- - service_catalog_management: - - name: "Service Catalog Management" - - beschreibung: | - Verantwortung für die inhaltliche Pflege der Service-Definition - und des Service-Steckbriefs im Katalog. - - aktivitaeten: - - - aufgabe: "Service-Definition erstellen" - raci: "A/R" - beschreibung: "Inhaltliche Erstellung nach Schema" - governance_referenz: "GOV-007" - - - aufgabe: "Service-Definition zur Validierung einreichen" - raci: "R" - freigabe_durch: "SPM" - aktivitaets_id: "scm_01" - - - aufgabe: "Service-Steckbrief erstellen" - raci: "R" - beschreibung: "Ableitung des kundenorientierten Auszugs" - aktivitaets_id: "scm_02" - - - aufgabe: "Katalogänderungen initiieren" - raci: "R" - beschreibung: "Meldet Änderungsbedarf, beschreibt Änderung" - aktivitaets_id: "scm_05" - - - aufgabe: "Redaktionelle Katalogänderungen (autonom)" - raci: "A/R" - beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"] - governance_referenz: "GOV-008" - - - aufgabe: "Service-Stilllegung koordinieren" - raci: "R" - beschreibung: "Koordiniert Kommunikation bei Stilllegung" - aktivitaets_id: "scm_06" - - - aufgabe: "Jährlicher Katalog-Review (Zulieferung)" - raci: "C" - beschreibung: "Liefert Informationen zu eigenen Services" - aktivitaets_id: "scm_07" - - referenz: "spm_practice_service-catalog-management.yaml" - - # --------------------------------------------------------------------------- - # CHANGE ENABLEMENT - # --------------------------------------------------------------------------- - change_enablement: - - name: "Change Enablement" - - beschreibung: | - Change Authority für Normal Changes im eigenen Service-Scope. - Klassifizierung und Bewertung von Change Requests. - - aktivitaeten: - - - aufgabe: "Change Requests klassifizieren" - raci: "A/R" - beschreibung: "Prüfung: Standard? Normal? Major?" - - - aufgabe: "Normal Changes bewerten und entscheiden" - raci: "A (Change Authority)" - beschreibung: "Risiko-, Aufwand- und Auswirkungsbewertung; Freigabe/Ablehnung" - - - aufgabe: "Cross-Service-Impact erkennen" - raci: "R" - beschreibung: | - SO ist verantwortlich für Erkennung von Cross-Service-Auswirkungen. - Bei Cross-Service-Impact: SPM als "zweite Augen" einbeziehen. - governance_referenz: "GOV-CE-003" - - - aufgabe: "Standard Change-Modelle dokumentieren" - raci: "A/R" - beschreibung: | - Dokumentation wiederkehrender, risikoarmer Changes für den - eigenen Service. SPM erhält Kopie zur Kenntnis. - - - aufgabe: "Change-Abschluss bestätigen" - raci: "A/R" - beschreibung: "Bestätigung der erfolgreichen Umsetzung" - - referenz: "spm_practice_change-enablement.yaml" - - # --------------------------------------------------------------------------- - # PROBLEM MANAGEMENT - # --------------------------------------------------------------------------- - problem_management: - - name: "Problem Management (Service-Kontext)" - - beschreibung: | - Operative Accountability für Problem Management im eigenen Service-Scope. - Der SO ist NICHT Practice Owner (liegt beim SPM), sondern trägt die - Verantwortung für die Durchführung im Service-Kontext. - - designentscheidung: "D-01" - - aktivitaeten: - - - aufgabe: "Problem-Analyse verantworten" - raci: "A" - beschreibung: "Accountable für Root-Cause-Analyse, kann an L2 delegieren" - aktivitaets_id: "PRB-02" - - - aufgabe: "Lösungsinitiierung entscheiden" - raci: "A/R" - beschreibung: | - Entscheidung: Permanente Lösung via Change oder alternative Maßnahme? - Kosten-Nutzen-Abwägung. - aktivitaets_id: "PRB-03" - - - aufgabe: "Change Request aus Problem erstellen" - raci: "A/R" - beschreibung: "Bei Bedarf: Change Request mit Problem-Verweis erstellen" - schnittstelle: "Change Enablement (P-03)" - - - aufgabe: "Problem schließen" - raci: "A/R" - beschreibung: "Abschluss nach Lösung oder bewusster Akzeptanz" - aktivitaets_id: "PRB-04" - - - aufgabe: "Known Error dokumentieren" - raci: "A" - beschreibung: "Verantwortet Known-Error-Dokumentation" - - - aufgabe: "Muster erkennen (Incident-Cluster)" - raci: "A" - beschreibung: "Verantwortet systematische Mustererkennung" - - referenz: "sub-practice_problem-management.yaml" - governance_referenz: "SSM-G-18" - - # --------------------------------------------------------------------------- - # INCIDENT MANAGEMENT (ESKALATIONSROLLE) - # --------------------------------------------------------------------------- - incident_management: - - name: "Incident Management (Eskalationsrolle)" - - beschreibung: | - Fachliche Eskalationsinstanz bei Major Incidents und komplexen - Störungen im eigenen Service-Bereich. - - aktivitaeten: - - - aufgabe: "Fachliche Eskalation annehmen" - raci: "A" - trigger: "Major Incident oder L2-Eskalation" - beschreibung: "Fachliche Klärung und Priorisierungsentscheidung" - - - aufgabe: "Hierarchische Eskalation initiieren" - raci: "R" - beschreibung: "Bei Bedarf Eskalation an SOR" - - referenz: "sub-practice_incident-management.yaml" - - # --------------------------------------------------------------------------- - # WISSENSMANAGEMENT - # --------------------------------------------------------------------------- - wissensmanagement: - - name: "Wissensmanagement (Service-Kontext)" - - beschreibung: | - Verantwortung für service-spezifische Wissensdokumentation. - - aktivitaeten: - - - aufgabe: "KB Ebene 1 verantworten" - raci: "A" - beschreibung: "Grundlagendokumentation zum Service" - - - aufgabe: "KB Ebene 2 co-erstellen" - raci: "C" - beschreibung: "Arbeitsdokumentation gemeinsam mit Support-Team" - - referenz: "ssm_rollen.yaml" - governance_referenz: "SSM-G-09" - -# ============================================================================= -# BEFUGNISSE -# ============================================================================= - -befugnisse: - - eigenstaendig: - - - befugnis: "Gate 2 (Entry-Prüfung nach Build) – Freigabe" - scope: "Eigener Service" - beschreibung: "Operative Einzelentscheidung über Übergabefähigkeit nach Build" - governance_referenz: "GOV-TR-012" - - - befugnis: "ELS-Exit-Entscheidung" - scope: "Eigener Service" - beschreibung: "Beendigung des Early Life Support" - mit_informationspflicht: "SPM" - governance_referenz: "GOV-TR-021" - - - befugnis: "Rollback während ELS" - scope: "Eigener Service" - beschreibung: "Bei fundamentalen Problemen" - governance_referenz: "GOV-TR-029" - - - befugnis: "Normal Changes genehmigen" - scope: "Eigener Service" - beschreibung: "Change Authority für Normal Changes" - governance_referenz: "GOV-CE-001" - - - befugnis: "Redaktionelle Katalogänderungen" - scope: "Eigener Service" - beispiele: ["Tippfehler", "Kontaktdaten"] - governance_referenz: "GOV-008" - - - befugnis: "Problem-Schließung" - scope: "Eigener Service" - beschreibung: "Abschluss von Problem Records" - - - befugnis: "Service-Review durchführen und bewerten" - scope: "Eigener Service" - frequenz: "Quartalsweise" - governance_referenz: "GOV-SR-001" - - in_abstimmung: - - - befugnis: "Minor Katalogänderungen" - abstimmung_mit: "SPM (bilateral)" - governance_referenz: "GOV-008" - - - befugnis: "Cross-Service-Changes" - abstimmung_mit: "SPM als 'zweite Augen'" - governance_referenz: "GOV-CE-003" - - - befugnis: "SLS/SLA-Inhalte" - abstimmung_mit: "Betriebsteam (technische Messbarkeit), SPM (Portfolio-Konsistenz)" - - ueber_gremien: - - - befugnis: "Gate 1 (Entry Transition) – Go/No-Go" - gremium: "SOR" - so_rolle: "Antragsteller, Vorlage-Einreichung" - governance_referenz: "GOV-TR-011" - - - befugnis: "Gate 3 (Go-Live-Freigabe)" - gremium: "SOR" - so_rolle: "Antragsteller, Nachweisführung" - governance_referenz: "GOV-TR-016" - - - befugnis: "Major Katalogänderungen / Neuaufnahme" - gremium: "SOR" - governance_referenz: "GOV-008" - - - befugnis: "SLA-Freigabe (Standard)" - gremium: "SOR" - - - befugnis: "SLA-Freigabe (Abweichungen/Major)" - gremium: "Mission Board" - governance_referenz: "GOV-001" - - - befugnis: "Strukturelle Katalogänderungen" - gremium: "Mission Board" - beispiele: ["Kategorie-Wechsel", "Stilllegung"] - governance_referenz: "GOV-008" - -# ============================================================================= -# EINSCHRÄNKUNGEN / NICHT-AUFGABEN -# ============================================================================= - -einschraenkungen: - - nicht_aufgabe: - - - was: "Portfolio-Entscheidungen" - zustaendig: "SPM / SOR / Mission Board" - klarstellung: | - SO bringt Service-Perspektive ein, entscheidet aber nicht über - Portfolio-Zusammensetzung, Service-Priorisierung oder Ressourcenallokation - auf Portfolio-Ebene. - - - was: "Major Changes / Transition-pflichtige Änderungen" - zustaendig: "SOR (via Transition-Gates)" - klarstellung: | - Wenn eine Änderung die Service-Identität berührt oder Transition-Gates - erfordert, liegt die Entscheidung bei SOR, nicht beim SO. - governance_referenz: "GOV-CE-004" - - - was: "Practice-Weiterentwicklung (methodisch)" - zustaendig: "SPM (als Practice Owner)" - klarstellung: | - SO führt Practices für seinen Service aus, entwickelt aber nicht - die Methodik weiter. Practice Ownership liegt beim SPM. - designentscheidung: "D-01" - - - was: "L1/L2-Support-Aktivitäten" - zustaendig: "Service Desk, Support Manager, Support-Agenten" - klarstellung: | - SO ist Eskalationsinstanz, nicht operativer Support-Bearbeiter. - - - was: "Betriebsführung / technische Operations" - zustaendig: "Operations Manager, Betriebsteam" - klarstellung: | - SO verantwortet Service fachlich (Was wird geliefert?), - nicht technisch-operativ (Wie wird es betrieben?). - hinweis: "Abgrenzung zu Operations Manager in separatem Dokument zu klären" - - - was: "SLA-Verhandlung (finale Entscheidung)" - zustaendig: "SOR / Mission Board" - klarstellung: | - SO moderiert SLA-Abstimmung mit Kunden, aber finale SLA-Freigabe - erfolgt durch SOR (Standard) oder MB (Abweichungen). - - - was: "Budget-Entscheidungen über definierte Schwellwerte" - zustaendig: "[Zu klären – offener Punkt]" - status: "Offener Punkt für MVP" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - intern: - - - partner: "Service-Portfolio-Manager (SPM)" - interaktion: - - "Fachliche Berichtslinie" - - "Service-Review-Ergebnisse kommunizieren" - - "Service-Definition zur Validierung einreichen" - - "Rücksprache bei Klassifizierungsfragen (Change/Demand)" - - "SPM als 'zweite Augen' bei Cross-Service-Changes" - frequenz: "Regelmäßig + bei Bedarf" - - - partner: "Support Manager" - interaktion: - - "Eskalationsempfang (fachlich)" - - "Abstimmung bei Problem Management" - - "Koordination L2-Aktivitäten" - frequenz: "Bei Bedarf" - referenz: "ssm_governance.yaml" - - - partner: "Operations Manager" - interaktion: - - "Abstimmung Service-Betrieb" - - "Monitoring-Anforderungen" - - "Kapazitäts- und Performance-Themen" - frequenz: "Bei Bedarf" - hinweis: "Detaillierte Abgrenzung in separatem Dokument zu klären" - - - partner: "Betriebsteam" - interaktion: - - "Koordination Betriebsaktivitäten" - - "Abstimmung bei SLS-Erstellung (technische Messbarkeit)" - - "Monitoring-Daten und Reports" - frequenz: "Laufend" - fuehrungsverhaeltnis: "[Offener Punkt – disziplinarische Einordnung ungeklärt]" - - - partner: "Projektleitung (in Transition)" - interaktion: - - "Überlappungszone Gate 1 bis Gate 2" - - "Übergabe der Service-Verantwortung" - frequenz: "Während Transition-Phase" - governance_referenz: "GOV-TR-006" - - extern: - - - partner: "Stakeholder-Manager (SHM)" - interaktion: - - "Gemeinsame Moderation Kundenforum" - - "Abstimmung bei Kundenfeedback" - - "Unterstützung bei Kundeninteraktion (SLA-Review)" - frequenz: "Bei Bedarf, Kundenforum jährlich" - governance_referenz: "GOV-012" - - - partner: "DIGIT-Mitarbeiter (interner Bedarf)" - interaktion: - - "Empfang interner Bedarfe für eigenen Service" - - "Change-Qualifizierung: Ist es ein Change oder Demand?" - - "Bei Change-Charakter: Bewertung und Umsetzung" - - "Bei Demand-Charakter: Rückverweis an SHM/DPM" - frequenz: "Bei Bedarf" - hinweis: | - Service Owner ist Ansprechpartner für interne Bedarfe, die einen - bestehenden Service betreffen. SO entscheidet, ob es ein Change - (SO-Verantwortung) oder Demand (DPM-Verantwortung) ist. - - Der Eingang erfolgt über SHM Fast Track Routing (siehe - shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern). - referenz: "shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern" - - - partner: "DPM (Demand-Portfolio-Management)" - interaktion: - - "Konsultation in Service-Entwicklung (vor Gate 1)" - - "Rückfragen zu Demand-Spezifikationen" - frequenz: "Bei Bedarf" - hinweis: "Formale Accountability beginnt bei Gate 1, Einbindung vorher empfohlen" - - - partner: "Kunden / SLA-Partner" - interaktion: - - "SLA-Abstimmung (Moderation)" - - "Jährlicher externer SLA-Review" - - "Service-bezogene Kommunikation" - frequenz: "Jährlich (Review) + bei Bedarf" - -# ============================================================================= -# GREMIENROLLEN -# ============================================================================= - -gremienrollen: - - - gremium: "SOR (Service Operations Runde)" - rolle: "Stimmberechtigtes Mitglied" - funktion: | - Vertretung des eigenen Service bei portfolio-relevanten Entscheidungen. - Stimmrecht bei Themen des eigenen Service. - befugnisse: - - "Stimmrecht bei Service-bezogenen Entscheidungen" - - "Einreichung von Vorlagen (Gate 2, Review-Eskalationen, Major Changes)" - - "Teilnahme an Portfolio-Diskussionen" - anwesenheit: "Bei Themen des eigenen Service (Details siehe G-SOR Geschäftsordnung)" - referenz: "G-SOR Geschäftsordnung (placeholder)" - hinweis: | - Portfolio-übergreifende Entscheidungen und Anwesenheitsregelung - werden in der SOR-Geschäftsordnung definiert. - - - gremium: "Mission Board" - rolle: "Bei Bedarf (Eskalation)" - funktion: "Eskalationsinstanz bei SOR-Dissens oder MB-pflichtigen Entscheidungen" - beispiele: - - "SLA-Abweichungen von Standard" - - "Strukturelle Katalogänderungen" - - "Ressourcenkonflikte" - - - gremium: "Kundenforum" - rolle: "Moderator (gemeinsam mit SHM)" - funktion: | - Moderation des integrierten Kundenforums für Service-bezogene Themen. - SLM-Review + SHM-Beziehungspflege. - frequenz: "Jährlich" - governance_referenz: "GOV-012" - -# ============================================================================= -# ANFORDERUNGSPROFIL -# ============================================================================= - -anforderungsprofil: - - fachlich: - - "Tiefes Verständnis des verantworteten Service (funktional und technisch)" - - "Kenntnisse des Service-Katalogs und der Service-Landschaft im DIGIT" - - "Grundverständnis ITIL4 Service Management Practices" - - "Verständnis des DIGITOM (SPM, DPM, SHM-Zusammenspiel)" - - "Kenntnisse der relevanten SLAs und Service Levels" - - methodisch: - - "Service-Review und -Bewertung" - - "Risiko- und Impact-Bewertung (Change Enablement)" - - "Root-Cause-Analyse (Problem Management)" - - "Stakeholder-Kommunikation und Moderation" - - "Dokumentation und strukturierte Erfassung" - - persoenlich: - - "Ownership-Mentalität und Ergebnisorientierung" - - "Entscheidungsfähigkeit unter Unsicherheit" - - "Kommunikationsstärke (intern und extern)" - - "Fähigkeit zur Priorisierung und zum Trade-off-Management" - - "Kooperationsfähigkeit in Gremienstrukturen" - - "Verbindlichkeit und Zuverlässigkeit" - -# ============================================================================= -# OFFENE PUNKTE (FÜR MVP NICHT ADRESSIERT) -# ============================================================================= - -offene_punkte: - - - id: "OPEN-SO-001" - thema: "Budget-Verantwortung für laufenden Betrieb" - beschreibung: | - Welche Budget-Befugnisse hat der SO für den laufenden Service-Betrieb? - Gibt es Schwellwerte, ab denen Abstimmung/Eskalation erforderlich ist? - prioritaet: "mittel" - status: "Für MVP nicht adressiert" - - - id: "OPEN-SO-002" - thema: "Disziplinarische Einordnung" - beschreibung: | - Wo ist der SO organisatorisch angesiedelt? Welche disziplinarische - Berichtslinie gilt? - prioritaet: "mittel" - status: "Für MVP nicht adressiert" - hinweis: "Kontextabhängig je nach Service und Organisation" - - - id: "OPEN-SO-003" - thema: "Arbeitsmodell / Kapazität" - beschreibung: | - Wie viele Services kann/soll ein SO verantworten? - Ist SO Voll- oder Teilzeitrolle? - prioritaet: "mittel" - status: "Für MVP nicht adressiert" - - - id: "OPEN-SO-004" - thema: "Abgrenzung zu Operations Manager" - beschreibung: | - Detaillierte Domänenabgrenzung zwischen SO (fachlich) und - Operations Manager (technisch-operativ). - prioritaet: "hoch" - status: "Grundlogik klar, Details in separatem Dokument zu klären" - abhaengig_von: "Rolle Operations Manager" - - - id: "OPEN-SO-005" - thema: "Führungsverantwortung Betriebsteam" - beschreibung: | - Hat der SO fachliche und/oder disziplinarische Führungsverantwortung - für das Betriebsteam? - prioritaet: "mittel" - status: "Für MVP nicht adressiert" - zusammenhang: "OPEN-SO-002" - -# ============================================================================= -# DESIGNENTSCHEIDUNGEN (DOKUMENTIERT) -# ============================================================================= - -designentscheidungen: - - - id: "D-01" - datum: "2025-12-17" - frage: "Ist SO Practice Owner für Problem Management?" - entscheidung: | - Nein. SO ist operativ accountable für Problem Management im eigenen - Service-Scope, aber NICHT Practice Owner. - Practice Ownership für alle Practices liegt beim SPM. - begruendung: | - Konsistent mit Taxonomie-Logik: SPM verantwortet Practices methodisch, - SO führt sie für seinen Service aus. Vermeidet Rolleninflation. - auswirkung_auf: - - dokument: "rolle_service-owner.yaml" - abschnitt: "kernaufgaben.problem_management" - - dokument: "rolle_service-portfolio-manager.yaml" - abschnitt: "practice_ownership" - - - id: "D-02" - datum: "2025-12-17" - frage: "Wie wird 'End-to-End-Verantwortung' präzisiert?" - entscheidung: | - "Durchgängige Accountability über den Service-Lifecycle, im Rahmen - der definierten Governance-Strukturen." - begruendung: | - Klarstellung, dass E2E Lifecycle-Kontinuität meint, nicht - Entscheidungsautonomie. SO ist an Gates, Eskalationen und - Portfolio-Governance gebunden. - auswirkung_auf: - - dokument: "rolle_service-owner.yaml" - abschnitt: "rollenzweck" - - - id: "D-03" - datum: "2025-12-17" - frage: "Wie wird die generelle Vertretungsregelung formuliert?" - entscheidung: | - "Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen - (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung - delegiert werden." - begruendung: | - Pragmatische Lösung für MVP. Ableitung aus GOV-TR-013 (Transition- - spezifische Vertretung) auf allgemeine Ebene. Als Annahme markiert. - status: "ANNAHME" - auswirkung_auf: - - dokument: "rolle_service-owner.yaml" - abschnitt: "organisatorische_einordnung.vertretung" - -# ============================================================================= -# GOVERNANCE-REFERENZEN (KONSOLIDIERT) -# ============================================================================= - -governance_referenzen: - - transition: - - "GOV-TR-011: Gate 1 als SOR-Entscheidung (Entry-Autorisierung)" - - "GOV-TR-012: Gate 2 als SO-Einzelentscheidung (Entry-Prüfung nach Build)" - - "GOV-TR-016: Gate 3 als SOR-Entscheidung (Go-Live-Freigabe)" - - "GOV-TR-004: SO-Benennung spätestens bei Gate 1" - - "GOV-TR-006: Accountability-Übernahme ab Gate 1" - - "GOV-TR-013: Vertretungsregelung (Transition)" - - "GOV-TR-021: ELS-Exit als SO-Einzelentscheidung" - - "GOV-TR-029: Rollback-Kompetenz während ELS" - - review: - - "GOV-SR-001: Quartalsweiser Selbst-Review" - - "GOV-SR-002: SPM-Informationspflicht" - - "GOV-SR-003: SOR-Einbeziehung bei Auffälligkeiten" - - "GOV-SR-005: Improvement-Tracking in der Service-Definition" - - catalog_und_level: - - "GOV-001: SLA-Freigabe-Governance" - - "GOV-007: SO erstellt Service-Definition" - - "GOV-008: Dreistufige Katalog-Änderungs-Governance" - - "GOV-012: Integriertes Kundenforum (SO + SHM)" - - change_enablement: - - "GOV-CE-001: SO als Change Authority für Normal Changes" - - "GOV-CE-003: Cross-Service-Impact-Erkennung" - - "GOV-CE-004: Abgrenzung Change vs. Demand" - - support: - - "SSM-G-18: SO als Process Owner für Problem Management" - - "SSM-G-09: KB-Verantwortung" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "0.1" - datum: "2025-12-15" - autor: "DIGITOM-Projekt" - aenderung: "Placeholder erstellt mit Gliederungsskelett" - - - version: "1.0" - datum: "2025-12-17" - autor: "DIGITOM-Projekt" - aenderung: | - Vollständige Rollenbeschreibung erstellt: - - Konsolidierung aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, etc.) - - Integration der Practice-Verantwortlichkeiten (SLM, SCM, CE, SSM) - - Dokumentation der Designentscheidungen D-01 bis D-03 - - Definition der offenen Punkte für MVP - - Strukturierung analog SHM-Rollenbeschreibungen - - - version: "1.1" - datum: "2026-01-22" - autor: "DIGITOM-Projekt" - aenderung: | - Erweiterung um interne Bedarfe: - - Neue Schnittstelle: "DIGIT-Mitarbeiter (interner Bedarf)" - - Beschreibung: Empfang interner Bedarfe für eigenen Service - - Change-Qualifizierung: SO entscheidet Change vs. Demand - - Verweis auf SHM Fast Track Routing - - Rückverweis an SHM/DPM bei Demand-Charakter +# ============================================================================= +# ROLLENBESCHREIBUNG: SERVICE OWNER +# ============================================================================= +# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/ +# Dateiname: rolle_service-owner.yaml +# ============================================================================= + +metadata: + id: "R-SO" + name: "Service Owner" + kurzform: "SO" + version: "1.0" + status: "entwurf" + erstellt: "2025-12-17" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "rollenbeschreibung" + + beschreibung: | + Vollständige Rollenbeschreibung für den Service Owner. + Konsolidiert Informationen aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, + GOV-007, GOV-008), Practice-Dokumenten (SLM, SCM, Change Enablement, SSM) + und der Kurzreferenz in spm_rollen.yaml. + + referenzen: + kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml -> service_owner" + support_kontext: "03_practices/spm_practice_service-support-management/ssm_rollen.yaml" + vorlage_struktur: "#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml" + service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" + service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml" + slm: "03_practices/spm_practice_service-level-management.yaml" + scm: "03_practices/spm_practice_service-catalog-management.yaml" + change_enablement: "03_practices/spm_practice_change-enablement.yaml" + governance_log: "spm_governance-entscheidungen-log.yaml" + + kontext_tags: + - "service-portfolio-management" + - "service-ownership" + - "lifecycle-management" + - "service-review" + - "change-authority" + +# ============================================================================= +# ROLLENZWECK +# ============================================================================= + +rollenzweck: + + kurz: | + Durchgängige Accountability für einen definierten Service über dessen + gesamten Lifecycle – von der Übernahme in Transition bis zur Stilllegung. + + ausfuehrlich: | + Der Service Owner trägt die End-to-End-Verantwortung für seinen Service + im Rahmen der definierten Governance-Strukturen. Diese Verantwortung + bedeutet Lifecycle-Kontinuität, nicht Entscheidungsautonomie. + + Die Rolle umfasst: + - Fachliche Gesamtverantwortung für Service-Definition, -Qualität und -Entwicklung + - Accountability für Service-Performance und SLA-Einhaltung + - Change Authority für Normal Changes im eigenen Service-Scope + - Operative Accountability für Problem Management im Service-Kontext + - Vertretung des Service in Gremien (SOR, Kundenforum) + + Der Service Owner agiert als "Unternehmer für seinen Service" – + allerdings eingebettet in die kollektive Governance-Architektur des DIGIT + (SOR, Mission Board) und gebunden an Portfolio-Entscheidungen des SPM. + + itil4_referenz: | + "The owner of a service is accountable for the delivery of that service. + Their accountability for the service extends from when the organization + adds it to its portfolio until its eventual retirement." + (ITIL4 Direct, Plan and Improve, 7.3.1.4) + + verantwortung: + ab_wann: "Formale Übernahme bei Gate 1 (Entry Transition)" + fuer: "Service-Qualität, SLA-Einhaltung, Service-Weiterentwicklung" + bis: "Abschluss der Stilllegung (Retirement)" + governance_referenz: "GOV-TR-006" + +# ============================================================================= +# ORGANISATORISCHE EINORDNUNG +# ============================================================================= + +organisatorische_einordnung: + + zuordnung: + funktion: "Service-Portfolio-Management (SPM)" + hinweis: | + Die disziplinarische Zuordnung des SO ist kontextabhängig und + nicht Gegenstand dieser Rollenbeschreibung. Der SO kann + organisatorisch in verschiedenen Abteilungen angesiedelt sein. + + berichtslinie: + fachlich: "Service-Portfolio-Manager (SPM)" + disziplinarisch: "[Kontextabhängig – offener Punkt für MVP]" + + rollentyp: + typ: "Einzelrolle" + beschreibung: | + Jeder Service im Portfolio hat genau einen Service Owner. + Eine Person kann mehrere Services verantworten (Kapazitätsfrage). + + arbeitsmodell: + status: "Offener Punkt für MVP" + hinweis: | + Kapazitätsfragen (wie viele Services pro SO?) und Arbeitsmodell + (Voll-/Teilzeit) sind nicht Teil des MVP und werden später geklärt. + + vertretung: + allgemein: | + Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen + (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung + delegiert werden. + transition_spezifisch: | + Gate-Entscheidungen können bei kurzfristiger SO-Abwesenheit verschoben + werden. Bei Dringlichkeit: Eskalation an SOR. + governance_referenz: "GOV-TR-013" + annahme_markierung: "ANNAHME – Generelle Vertretungslogik abgeleitet aus GOV-TR-013" + +# ============================================================================= +# KERNAUFGABEN +# ============================================================================= + +kernaufgaben: + + # --------------------------------------------------------------------------- + # SERVICE TRANSITION + # --------------------------------------------------------------------------- + service_transition: + + name: "Service Transition Management" + + beschreibung: | + Übernahme neuer oder wesentlich geänderter Services aus der + Service-Entwicklung in den produktiven Betrieb. + + aktivitaeten: + + - aufgabe: "Gate 1 (Entry Transition) – SOR-Vorlage" + raci: "R" + beschreibung: "Vorbereitung und Einreichung der Gate-1-Vorlage bei SPM; Entscheidung liegt bei SOR" + governance_referenz: "GOV-TR-011" + + - aufgabe: "Accountability-Übernahme ab Gate 1" + beschreibung: | + Ab Gate 1 trägt SO die formale Accountability für den Service. + In der Phase bis Gate 2 besteht eine Überlappungszone mit der + Projektleitung (gemeinsame Verantwortung). + governance_referenz: "GOV-TR-006" + + - aufgabe: "Service-Definition erstellen" + raci: "A/R" + beschreibung: "Erstellung der vollständigen Service-Definition nach Schema" + freigabe_durch: "SPM validiert, SOR gibt frei (bei Neuaufnahme)" + governance_referenz: "GOV-007" + + - aufgabe: "Gate 2 (Entry-Prüfung nach Build) – Entscheidung" + raci: "A (Einzelentscheidung)" + beschreibung: "SO prüft Übergabefähigkeit nach Build und entscheidet eigenständig über Freigabe/Zurückweisung" + governance_referenz: "GOV-TR-012" + + - aufgabe: "ELS-Management (Early Life Support)" + raci: "A" + beschreibung: | + Verantwortung für intensivierte Betreuung nach Go-Live. + Entscheidung über ELS-Exit als SO-Einzelentscheidung. + governance_referenz: "GOV-TR-021" + + - aufgabe: "Rollback-Entscheidung (ELS)" + raci: "A (Einzelentscheidung)" + beschreibung: | + Bei fundamentalen Problemen während ELS kann SO eigenständig + Rollback entscheiden. + governance_referenz: "GOV-TR-029" + + referenz: "spm_konzept_service-transition.yaml" + + # --------------------------------------------------------------------------- + # SERVICE REVIEW + # --------------------------------------------------------------------------- + service_review: + + name: "Quartalsweiser Service Review" + + beschreibung: | + Regelmäßige Selbstbewertung des Service anhand des 4-Dimensionen-Modells. + Ableitung von Handlungsempfehlungen und ggf. Einreichung bei SOR. + + aktivitaeten: + + - aufgabe: "Service-Review durchführen" + frequenz: "Quartalsweise" + raci: "A/R" + beschreibung: | + Bewertung des Service anhand der vier Dimensionen: + - SR-D1: Leistungserbringung (SLA-Erfüllung) + - SR-D2: Betriebsstabilität (Incidents, Verfügbarkeit) + - SR-D3: Nutzerzufriedenheit (Feedback, Beschwerden) + - SR-D4: Zukunftsfähigkeit (technisch, strategisch) + governance_referenz: "GOV-SR-001" + + - aufgabe: "Handlungsempfehlung ableiten" + raci: "A/R" + optionen: + - "CONTINUE – Service läuft wie geplant" + - "IMPROVEMENT – Verbesserungsmaßnahmen erforderlich" + - "REDESIGN – Grundlegende Überarbeitung nötig" + - "RETIRE – Stilllegung empfohlen" + governance_referenz: "GOV-SR-001" + + - aufgabe: "SPM informieren" + frequenz: "Nach jedem Review" + raci: "R" + beschreibung: "Informationspflicht an SPM über Review-Ergebnis" + governance_referenz: "GOV-SR-002" + + - aufgabe: "SOR-Vorlage einreichen (bei Bedarf)" + trigger: + - "Mindestens eine Dimension auf ROT" + - "IMPROVEMENT mit Ressourcenbedarf" + - "REDESIGN oder RETIRE" + raci: "R" + governance_referenz: "GOV-SR-003" + + - aufgabe: "Improvement-Maßnahmen definieren und tracken" + raci: "A/R" + beschreibung: "Dokumentation in der Service-Definition (Abschnitt 'laufende_verbesserungen')" + governance_referenz: "GOV-SR-005" + + - aufgabe: "Wirksamkeitsprüfung im Folge-Review" + raci: "A/R" + governance_referenz: "GOV-SR-005" + + referenz: "spm_konzept_service-review.yaml" + + # --------------------------------------------------------------------------- + # SERVICE LEVEL MANAGEMENT + # --------------------------------------------------------------------------- + service_level_management: + + name: "Service Level Management" + + beschreibung: | + Verantwortung für Definition, Vereinbarung, Überwachung und + Review der Service Levels. + + aktivitaeten: + + - aufgabe: "Service-Level-Anforderungen erheben" + phase: "Transition" + raci: "A" + beschreibung: "Verantwortet die Anforderungserhebung aus Kundensicht" + aktivitaets_id: "slm_01" + + - aufgabe: "Service Level Specification (SLS) erstellen" + phase: "Transition" + raci: "A" + beschreibung: "Verantwortet SLS-Inhalt (Übersetzung in messbare Levels)" + aktivitaets_id: "slm_02" + + - aufgabe: "SLA abstimmen und fixieren" + phase: "Transition" + raci: "R" + beschreibung: "Führt Abstimmung mit SLA-Partner, moderiert Usergroup" + aktivitaets_id: "slm_03" + + - aufgabe: "SLA-Freigabe vorbereiten" + phase: "Transition" + raci: "R" + beschreibung: "Bereitet SOR-/MB-Freigabe vor" + aktivitaets_id: "slm_04" + + - aufgabe: "Service Levels überwachen" + phase: "Betrieb" + raci: "A" + beschreibung: "Verantwortet Interpretation der Messergebnisse" + aktivitaets_id: "slm_05" + + - aufgabe: "SLA-Performance reporten" + phase: "Betrieb" + raci: "A" + frequenz: "Monatlich (intern), Quartalsweise (extern)" + beschreibung: "Verantwortet Bericht und Interpretation" + aktivitaets_id: "slm_06" + + - aufgabe: "SLA-Verletzung eskalieren" + phase: "Betrieb" + raci: "R" + beschreibung: "Identifiziert, analysiert, eskaliert (Stufe 1 im Eskalationspfad)" + aktivitaets_id: "slm_07" + + - aufgabe: "Internen SLA-Review durchführen" + phase: "Review" + raci: "A" + frequenz: "Jährlich" + aktivitaets_id: "slm_08" + + - aufgabe: "Externen SLA-Review mit Kunden durchführen" + phase: "Review" + raci: "R" + frequenz: "Jährlich" + beschreibung: "Führt Review durch, moderiert Kundenforum gemeinsam mit SHM" + aktivitaets_id: "slm_09" + governance_referenz: "GOV-012" + + referenz: "spm_practice_service-level-management.yaml" + + # --------------------------------------------------------------------------- + # SERVICE CATALOG MANAGEMENT + # --------------------------------------------------------------------------- + service_catalog_management: + + name: "Service Catalog Management" + + beschreibung: | + Verantwortung für die inhaltliche Pflege der Service-Definition + und des Service-Steckbriefs im Katalog. + + aktivitaeten: + + - aufgabe: "Service-Definition erstellen" + raci: "A/R" + beschreibung: "Inhaltliche Erstellung nach Schema" + governance_referenz: "GOV-007" + + - aufgabe: "Service-Definition zur Validierung einreichen" + raci: "R" + freigabe_durch: "SPM" + aktivitaets_id: "scm_01" + + - aufgabe: "Service-Steckbrief erstellen" + raci: "R" + beschreibung: "Ableitung des kundenorientierten Auszugs" + aktivitaets_id: "scm_02" + + - aufgabe: "Katalogänderungen initiieren" + raci: "R" + beschreibung: "Meldet Änderungsbedarf, beschreibt Änderung" + aktivitaets_id: "scm_05" + + - aufgabe: "Redaktionelle Katalogänderungen (autonom)" + raci: "A/R" + beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"] + governance_referenz: "GOV-008" + + - aufgabe: "Service-Stilllegung koordinieren" + raci: "R" + beschreibung: "Koordiniert Kommunikation bei Stilllegung" + aktivitaets_id: "scm_06" + + - aufgabe: "Jährlicher Katalog-Review (Zulieferung)" + raci: "C" + beschreibung: "Liefert Informationen zu eigenen Services" + aktivitaets_id: "scm_07" + + referenz: "spm_practice_service-catalog-management.yaml" + + # --------------------------------------------------------------------------- + # CHANGE ENABLEMENT + # --------------------------------------------------------------------------- + change_enablement: + + name: "Change Enablement" + + beschreibung: | + Change Authority für Normal Changes im eigenen Service-Scope. + Klassifizierung und Bewertung von Change Requests. + + aktivitaeten: + + - aufgabe: "Change Requests klassifizieren" + raci: "A/R" + beschreibung: "Prüfung: Standard? Normal? Major?" + + - aufgabe: "Normal Changes bewerten und entscheiden" + raci: "A (Change Authority)" + beschreibung: "Risiko-, Aufwand- und Auswirkungsbewertung; Freigabe/Ablehnung" + + - aufgabe: "Cross-Service-Impact erkennen" + raci: "R" + beschreibung: | + SO ist verantwortlich für Erkennung von Cross-Service-Auswirkungen. + Bei Cross-Service-Impact: SPM als "zweite Augen" einbeziehen. + governance_referenz: "GOV-CE-003" + + - aufgabe: "Standard Change-Modelle dokumentieren" + raci: "A/R" + beschreibung: | + Dokumentation wiederkehrender, risikoarmer Changes für den + eigenen Service. SPM erhält Kopie zur Kenntnis. + + - aufgabe: "Change-Abschluss bestätigen" + raci: "A/R" + beschreibung: "Bestätigung der erfolgreichen Umsetzung" + + referenz: "spm_practice_change-enablement.yaml" + + # --------------------------------------------------------------------------- + # PROBLEM MANAGEMENT + # --------------------------------------------------------------------------- + problem_management: + + name: "Problem Management (Service-Kontext)" + + beschreibung: | + Operative Accountability für Problem Management im eigenen Service-Scope. + Der SO ist NICHT Practice Owner (liegt beim SPM), sondern trägt die + Verantwortung für die Durchführung im Service-Kontext. + + designentscheidung: "D-01" + + aktivitaeten: + + - aufgabe: "Problem-Analyse verantworten" + raci: "A" + beschreibung: "Accountable für Root-Cause-Analyse, kann an L2 delegieren" + aktivitaets_id: "PRB-02" + + - aufgabe: "Lösungsinitiierung entscheiden" + raci: "A/R" + beschreibung: | + Entscheidung: Permanente Lösung via Change oder alternative Maßnahme? + Kosten-Nutzen-Abwägung. + aktivitaets_id: "PRB-03" + + - aufgabe: "Change Request aus Problem erstellen" + raci: "A/R" + beschreibung: "Bei Bedarf: Change Request mit Problem-Verweis erstellen" + schnittstelle: "Change Enablement (P-03)" + + - aufgabe: "Problem schließen" + raci: "A/R" + beschreibung: "Abschluss nach Lösung oder bewusster Akzeptanz" + aktivitaets_id: "PRB-04" + + - aufgabe: "Known Error dokumentieren" + raci: "A" + beschreibung: "Verantwortet Known-Error-Dokumentation" + + - aufgabe: "Muster erkennen (Incident-Cluster)" + raci: "A" + beschreibung: "Verantwortet systematische Mustererkennung" + + referenz: "sub-practice_problem-management.yaml" + governance_referenz: "SSM-G-18" + + # --------------------------------------------------------------------------- + # INCIDENT MANAGEMENT (ESKALATIONSROLLE) + # --------------------------------------------------------------------------- + incident_management: + + name: "Incident Management (Eskalationsrolle)" + + beschreibung: | + Fachliche Eskalationsinstanz bei Major Incidents und komplexen + Störungen im eigenen Service-Bereich. + + aktivitaeten: + + - aufgabe: "Fachliche Eskalation annehmen" + raci: "A" + trigger: "Major Incident oder L2-Eskalation" + beschreibung: "Fachliche Klärung und Priorisierungsentscheidung" + + - aufgabe: "Hierarchische Eskalation initiieren" + raci: "R" + beschreibung: "Bei Bedarf Eskalation an SOR" + + referenz: "sub-practice_incident-management.yaml" + + # --------------------------------------------------------------------------- + # WISSENSMANAGEMENT + # --------------------------------------------------------------------------- + wissensmanagement: + + name: "Wissensmanagement (Service-Kontext)" + + beschreibung: | + Verantwortung für service-spezifische Wissensdokumentation. + + aktivitaeten: + + - aufgabe: "KB Ebene 1 verantworten" + raci: "A" + beschreibung: "Grundlagendokumentation zum Service" + + - aufgabe: "KB Ebene 2 co-erstellen" + raci: "C" + beschreibung: "Arbeitsdokumentation gemeinsam mit Support-Team" + + referenz: "ssm_rollen.yaml" + governance_referenz: "SSM-G-09" + +# ============================================================================= +# BEFUGNISSE +# ============================================================================= + +befugnisse: + + eigenstaendig: + + - befugnis: "Gate 2 (Entry-Prüfung nach Build) – Freigabe" + scope: "Eigener Service" + beschreibung: "Operative Einzelentscheidung über Übergabefähigkeit nach Build" + governance_referenz: "GOV-TR-012" + + - befugnis: "ELS-Exit-Entscheidung" + scope: "Eigener Service" + beschreibung: "Beendigung des Early Life Support" + mit_informationspflicht: "SPM" + governance_referenz: "GOV-TR-021" + + - befugnis: "Rollback während ELS" + scope: "Eigener Service" + beschreibung: "Bei fundamentalen Problemen" + governance_referenz: "GOV-TR-029" + + - befugnis: "Normal Changes genehmigen" + scope: "Eigener Service" + beschreibung: "Change Authority für Normal Changes" + governance_referenz: "GOV-CE-001" + + - befugnis: "Redaktionelle Katalogänderungen" + scope: "Eigener Service" + beispiele: ["Tippfehler", "Kontaktdaten"] + governance_referenz: "GOV-008" + + - befugnis: "Problem-Schließung" + scope: "Eigener Service" + beschreibung: "Abschluss von Problem Records" + + - befugnis: "Service-Review durchführen und bewerten" + scope: "Eigener Service" + frequenz: "Quartalsweise" + governance_referenz: "GOV-SR-001" + + in_abstimmung: + + - befugnis: "Minor Katalogänderungen" + abstimmung_mit: "SPM (bilateral)" + governance_referenz: "GOV-008" + + - befugnis: "Cross-Service-Changes" + abstimmung_mit: "SPM als 'zweite Augen'" + governance_referenz: "GOV-CE-003" + + - befugnis: "SLS/SLA-Inhalte" + abstimmung_mit: "Betriebsteam (technische Messbarkeit), SPM (Portfolio-Konsistenz)" + + ueber_gremien: + + - befugnis: "Gate 1 (Entry Transition) – Go/No-Go" + gremium: "SOR" + so_rolle: "Antragsteller, Vorlage-Einreichung" + governance_referenz: "GOV-TR-011" + + - befugnis: "Gate 3 (Go-Live-Freigabe)" + gremium: "SOR" + so_rolle: "Antragsteller, Nachweisführung" + governance_referenz: "GOV-TR-016" + + - befugnis: "Major Katalogänderungen / Neuaufnahme" + gremium: "SOR" + governance_referenz: "GOV-008" + + - befugnis: "SLA-Freigabe (Standard)" + gremium: "SOR" + + - befugnis: "SLA-Freigabe (Abweichungen/Major)" + gremium: "Mission Board" + governance_referenz: "GOV-001" + + - befugnis: "Strukturelle Katalogänderungen" + gremium: "Mission Board" + beispiele: ["Kategorie-Wechsel", "Stilllegung"] + governance_referenz: "GOV-008" + +# ============================================================================= +# EINSCHRÄNKUNGEN / NICHT-AUFGABEN +# ============================================================================= + +einschraenkungen: + + nicht_aufgabe: + + - was: "Portfolio-Entscheidungen" + zustaendig: "SPM / SOR / Mission Board" + klarstellung: | + SO bringt Service-Perspektive ein, entscheidet aber nicht über + Portfolio-Zusammensetzung, Service-Priorisierung oder Ressourcenallokation + auf Portfolio-Ebene. + + - was: "Major Changes / Transition-pflichtige Änderungen" + zustaendig: "SOR (via Transition-Gates)" + klarstellung: | + Wenn eine Änderung die Service-Identität berührt oder Transition-Gates + erfordert, liegt die Entscheidung bei SOR, nicht beim SO. + governance_referenz: "GOV-CE-004" + + - was: "Practice-Weiterentwicklung (methodisch)" + zustaendig: "SPM (als Practice Owner)" + klarstellung: | + SO führt Practices für seinen Service aus, entwickelt aber nicht + die Methodik weiter. Practice Ownership liegt beim SPM. + designentscheidung: "D-01" + + - was: "L1/L2-Support-Aktivitäten" + zustaendig: "Service Desk, Support Manager, Support-Agenten" + klarstellung: | + SO ist Eskalationsinstanz, nicht operativer Support-Bearbeiter. + + - was: "Betriebsführung / technische Operations" + zustaendig: "Operations Manager, Betriebsteam" + klarstellung: | + SO verantwortet Service fachlich (Was wird geliefert?), + nicht technisch-operativ (Wie wird es betrieben?). + hinweis: "Abgrenzung zu Operations Manager in separatem Dokument zu klären" + + - was: "SLA-Verhandlung (finale Entscheidung)" + zustaendig: "SOR / Mission Board" + klarstellung: | + SO moderiert SLA-Abstimmung mit Kunden, aber finale SLA-Freigabe + erfolgt durch SOR (Standard) oder MB (Abweichungen). + + - was: "Budget-Entscheidungen über definierte Schwellwerte" + zustaendig: "[Zu klären – offener Punkt]" + status: "Offener Punkt für MVP" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + intern: + + - partner: "Service-Portfolio-Manager (SPM)" + interaktion: + - "Fachliche Berichtslinie" + - "Service-Review-Ergebnisse kommunizieren" + - "Service-Definition zur Validierung einreichen" + - "Rücksprache bei Klassifizierungsfragen (Change/Demand)" + - "SPM als 'zweite Augen' bei Cross-Service-Changes" + frequenz: "Regelmäßig + bei Bedarf" + + - partner: "Support Manager" + interaktion: + - "Eskalationsempfang (fachlich)" + - "Abstimmung bei Problem Management" + - "Koordination L2-Aktivitäten" + frequenz: "Bei Bedarf" + referenz: "ssm_governance.yaml" + + - partner: "Operations Manager" + interaktion: + - "Abstimmung Service-Betrieb" + - "Monitoring-Anforderungen" + - "Kapazitäts- und Performance-Themen" + frequenz: "Bei Bedarf" + hinweis: "Detaillierte Abgrenzung in separatem Dokument zu klären" + + - partner: "Betriebsteam" + interaktion: + - "Koordination Betriebsaktivitäten" + - "Abstimmung bei SLS-Erstellung (technische Messbarkeit)" + - "Monitoring-Daten und Reports" + frequenz: "Laufend" + fuehrungsverhaeltnis: "[Offener Punkt – disziplinarische Einordnung ungeklärt]" + + - partner: "Projektleitung (in Transition)" + interaktion: + - "Überlappungszone Gate 1 bis Gate 2" + - "Übergabe der Service-Verantwortung" + frequenz: "Während Transition-Phase" + governance_referenz: "GOV-TR-006" + + extern: + + - partner: "Stakeholder-Manager (SHM)" + interaktion: + - "Gemeinsame Moderation Kundenforum" + - "Abstimmung bei Kundenfeedback" + - "Unterstützung bei Kundeninteraktion (SLA-Review)" + frequenz: "Bei Bedarf, Kundenforum jährlich" + governance_referenz: "GOV-012" + + - partner: "DIGIT-Mitarbeiter (interner Bedarf)" + interaktion: + - "Empfang interner Bedarfe für eigenen Service" + - "Change-Qualifizierung: Ist es ein Change oder Demand?" + - "Bei Change-Charakter: Bewertung und Umsetzung" + - "Bei Demand-Charakter: Rückverweis an SHM/DPM" + frequenz: "Bei Bedarf" + hinweis: | + Service Owner ist Ansprechpartner für interne Bedarfe, die einen + bestehenden Service betreffen. SO entscheidet, ob es ein Change + (SO-Verantwortung) oder Demand (DPM-Verantwortung) ist. + + Der Eingang erfolgt über SHM Fast Track Routing (siehe + shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern). + referenz: "shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern" + + - partner: "DPM (Demand-Portfolio-Management)" + interaktion: + - "Konsultation in Service-Entwicklung (vor Gate 1)" + - "Rückfragen zu Demand-Spezifikationen" + frequenz: "Bei Bedarf" + hinweis: "Formale Accountability beginnt bei Gate 1, Einbindung vorher empfohlen" + + - partner: "Kunden / SLA-Partner" + interaktion: + - "SLA-Abstimmung (Moderation)" + - "Jährlicher externer SLA-Review" + - "Service-bezogene Kommunikation" + frequenz: "Jährlich (Review) + bei Bedarf" + +# ============================================================================= +# GREMIENROLLEN +# ============================================================================= + +gremienrollen: + + - gremium: "SOR (Service Operations Runde)" + rolle: "Stimmberechtigtes Mitglied" + funktion: | + Vertretung des eigenen Service bei portfolio-relevanten Entscheidungen. + Stimmrecht bei Themen des eigenen Service. + befugnisse: + - "Stimmrecht bei Service-bezogenen Entscheidungen" + - "Einreichung von Vorlagen (Gate 2, Review-Eskalationen, Major Changes)" + - "Teilnahme an Portfolio-Diskussionen" + anwesenheit: "Bei Themen des eigenen Service (Details siehe G-SOR Geschäftsordnung)" + referenz: "G-SOR Geschäftsordnung (placeholder)" + hinweis: | + Portfolio-übergreifende Entscheidungen und Anwesenheitsregelung + werden in der SOR-Geschäftsordnung definiert. + + - gremium: "Mission Board" + rolle: "Bei Bedarf (Eskalation)" + funktion: "Eskalationsinstanz bei SOR-Dissens oder MB-pflichtigen Entscheidungen" + beispiele: + - "SLA-Abweichungen von Standard" + - "Strukturelle Katalogänderungen" + - "Ressourcenkonflikte" + + - gremium: "Kundenforum" + rolle: "Moderator (gemeinsam mit SHM)" + funktion: | + Moderation des integrierten Kundenforums für Service-bezogene Themen. + SLM-Review + SHM-Beziehungspflege. + frequenz: "Jährlich" + governance_referenz: "GOV-012" + +# ============================================================================= +# ANFORDERUNGSPROFIL +# ============================================================================= + +anforderungsprofil: + + fachlich: + - "Tiefes Verständnis des verantworteten Service (funktional und technisch)" + - "Kenntnisse des Service-Katalogs und der Service-Landschaft im DIGIT" + - "Grundverständnis ITIL4 Service Management Practices" + - "Verständnis des DIGITOM (SPM, DPM, SHM-Zusammenspiel)" + - "Kenntnisse der relevanten SLAs und Service Levels" + + methodisch: + - "Service-Review und -Bewertung" + - "Risiko- und Impact-Bewertung (Change Enablement)" + - "Root-Cause-Analyse (Problem Management)" + - "Stakeholder-Kommunikation und Moderation" + - "Dokumentation und strukturierte Erfassung" + + persoenlich: + - "Ownership-Mentalität und Ergebnisorientierung" + - "Entscheidungsfähigkeit unter Unsicherheit" + - "Kommunikationsstärke (intern und extern)" + - "Fähigkeit zur Priorisierung und zum Trade-off-Management" + - "Kooperationsfähigkeit in Gremienstrukturen" + - "Verbindlichkeit und Zuverlässigkeit" + +# ============================================================================= +# OFFENE PUNKTE (FÜR MVP NICHT ADRESSIERT) +# ============================================================================= + +offene_punkte: + + - id: "OPEN-SO-001" + thema: "Budget-Verantwortung für laufenden Betrieb" + beschreibung: | + Welche Budget-Befugnisse hat der SO für den laufenden Service-Betrieb? + Gibt es Schwellwerte, ab denen Abstimmung/Eskalation erforderlich ist? + prioritaet: "mittel" + status: "Für MVP nicht adressiert" + + - id: "OPEN-SO-002" + thema: "Disziplinarische Einordnung" + beschreibung: | + Wo ist der SO organisatorisch angesiedelt? Welche disziplinarische + Berichtslinie gilt? + prioritaet: "mittel" + status: "Für MVP nicht adressiert" + hinweis: "Kontextabhängig je nach Service und Organisation" + + - id: "OPEN-SO-003" + thema: "Arbeitsmodell / Kapazität" + beschreibung: | + Wie viele Services kann/soll ein SO verantworten? + Ist SO Voll- oder Teilzeitrolle? + prioritaet: "mittel" + status: "Für MVP nicht adressiert" + + - id: "OPEN-SO-004" + thema: "Abgrenzung zu Operations Manager" + beschreibung: | + Detaillierte Domänenabgrenzung zwischen SO (fachlich) und + Operations Manager (technisch-operativ). + prioritaet: "hoch" + status: "Grundlogik klar, Details in separatem Dokument zu klären" + abhaengig_von: "Rolle Operations Manager" + + - id: "OPEN-SO-005" + thema: "Führungsverantwortung Betriebsteam" + beschreibung: | + Hat der SO fachliche und/oder disziplinarische Führungsverantwortung + für das Betriebsteam? + prioritaet: "mittel" + status: "Für MVP nicht adressiert" + zusammenhang: "OPEN-SO-002" + +# ============================================================================= +# DESIGNENTSCHEIDUNGEN (DOKUMENTIERT) +# ============================================================================= + +designentscheidungen: + + - id: "D-01" + datum: "2025-12-17" + frage: "Ist SO Practice Owner für Problem Management?" + entscheidung: | + Nein. SO ist operativ accountable für Problem Management im eigenen + Service-Scope, aber NICHT Practice Owner. + Practice Ownership für alle Practices liegt beim SPM. + begruendung: | + Konsistent mit Taxonomie-Logik: SPM verantwortet Practices methodisch, + SO führt sie für seinen Service aus. Vermeidet Rolleninflation. + auswirkung_auf: + - dokument: "rolle_service-owner.yaml" + abschnitt: "kernaufgaben.problem_management" + - dokument: "rolle_service-portfolio-manager.yaml" + abschnitt: "practice_ownership" + + - id: "D-02" + datum: "2025-12-17" + frage: "Wie wird 'End-to-End-Verantwortung' präzisiert?" + entscheidung: | + "Durchgängige Accountability über den Service-Lifecycle, im Rahmen + der definierten Governance-Strukturen." + begruendung: | + Klarstellung, dass E2E Lifecycle-Kontinuität meint, nicht + Entscheidungsautonomie. SO ist an Gates, Eskalationen und + Portfolio-Governance gebunden. + auswirkung_auf: + - dokument: "rolle_service-owner.yaml" + abschnitt: "rollenzweck" + + - id: "D-03" + datum: "2025-12-17" + frage: "Wie wird die generelle Vertretungsregelung formuliert?" + entscheidung: | + "Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen + (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung + delegiert werden." + begruendung: | + Pragmatische Lösung für MVP. Ableitung aus GOV-TR-013 (Transition- + spezifische Vertretung) auf allgemeine Ebene. Als Annahme markiert. + status: "ANNAHME" + auswirkung_auf: + - dokument: "rolle_service-owner.yaml" + abschnitt: "organisatorische_einordnung.vertretung" + +# ============================================================================= +# GOVERNANCE-REFERENZEN (KONSOLIDIERT) +# ============================================================================= + +governance_referenzen: + + transition: + - "GOV-TR-011: Gate 1 als SOR-Entscheidung (Entry-Autorisierung)" + - "GOV-TR-012: Gate 2 als SO-Einzelentscheidung (Entry-Prüfung nach Build)" + - "GOV-TR-016: Gate 3 als SOR-Entscheidung (Go-Live-Freigabe)" + - "GOV-TR-004: SO-Benennung spätestens bei Gate 1" + - "GOV-TR-006: Accountability-Übernahme ab Gate 1" + - "GOV-TR-013: Vertretungsregelung (Transition)" + - "GOV-TR-021: ELS-Exit als SO-Einzelentscheidung" + - "GOV-TR-029: Rollback-Kompetenz während ELS" + + review: + - "GOV-SR-001: Quartalsweiser Selbst-Review" + - "GOV-SR-002: SPM-Informationspflicht" + - "GOV-SR-003: SOR-Einbeziehung bei Auffälligkeiten" + - "GOV-SR-005: Improvement-Tracking in der Service-Definition" + + catalog_und_level: + - "GOV-001: SLA-Freigabe-Governance" + - "GOV-007: SO erstellt Service-Definition" + - "GOV-008: Dreistufige Katalog-Änderungs-Governance" + - "GOV-012: Integriertes Kundenforum (SO + SHM)" + + change_enablement: + - "GOV-CE-001: SO als Change Authority für Normal Changes" + - "GOV-CE-003: Cross-Service-Impact-Erkennung" + - "GOV-CE-004: Abgrenzung Change vs. Demand" + + support: + - "SSM-G-18: SO als Process Owner für Problem Management" + - "SSM-G-09: KB-Verantwortung" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "0.1" + datum: "2025-12-15" + autor: "DIGITOM-Projekt" + aenderung: "Placeholder erstellt mit Gliederungsskelett" + + - version: "1.0" + datum: "2025-12-17" + autor: "DIGITOM-Projekt" + aenderung: | + Vollständige Rollenbeschreibung erstellt: + - Konsolidierung aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, etc.) + - Integration der Practice-Verantwortlichkeiten (SLM, SCM, CE, SSM) + - Dokumentation der Designentscheidungen D-01 bis D-03 + - Definition der offenen Punkte für MVP + - Strukturierung analog SHM-Rollenbeschreibungen + + - version: "1.1" + datum: "2026-01-22" + autor: "DIGITOM-Projekt" + aenderung: | + Erweiterung um interne Bedarfe: + - Neue Schnittstelle: "DIGIT-Mitarbeiter (interner Bedarf)" + - Beschreibung: Empfang interner Bedarfe für eigenen Service + - Change-Qualifizierung: SO entscheidet Change vs. Demand + - Verweis auf SHM Fast Track Routing + - Rückverweis an SHM/DPM bei Demand-Charakter quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-portfolio-manager.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-portfolio-manager.yaml index cb8b774..ab285d0 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-portfolio-manager.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-portfolio-manager.yaml @@ -1,1139 +1,1139 @@ -# ============================================================================= -# ROLLENBESCHREIBUNG: SERVICE-PORTFOLIO-MANAGER (R-SPM) -# ============================================================================= -# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/ -# Dateiname: rolle_service-portfolio-manager.yaml -# ============================================================================= - -metadata: - id: "R-SPM" - name: "Service-Portfolio-Manager" - version: "1.0" - status: "draft" - erstellt: "2025-12-17" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "rollenbeschreibung" - - referenzen: - service_owner: "rolle_service-owner.yaml" - dpm: "dpm_rollenbeschreibung-dpm.yaml" - shm_rollen: "shm_rollen.yaml" - sor_go: "spm_sor_go.yaml" - governance_log: "spm_governance-entscheidungen-log.yaml" - scm_practice: "spm_practice_service-catalog-management.yaml" - slm_practice: "spm_practice_service-level-management.yaml" - change_enablement: "spm_practice_change-enablement.yaml" - -# ============================================================================= -# 1. ROLLENZWECK -# ============================================================================= - -rollenzweck: - - kurz: | - Der Service-Portfolio-Manager (SPM) verantwortet die Steuerung des - Service-Portfolios auf taktisch-koordinativer Ebene. Er stellt sicher, - dass das Portfolio konsistent, aktuell und an den strategischen Zielen - von DIGIT ausgerichtet ist. - - ausfuehrlich: | - Der SPM ist die zentrale Koordinationsrolle für alle portfolio-übergreifenden - Service-Management-Aktivitäten. Er verbindet die strategische Ebene - (Mission Board, Vision Board) mit der operativen Ebene (Service Owner, - Betriebsteams) und stellt sicher, dass Governance-Standards eingehalten werden. - - Im Unterschied zum Service Owner, der die End-to-End-Verantwortung für - einen einzelnen Service trägt, verantwortet der SPM die Portfolio-Perspektive - über alle Services hinweg. Er ist Practice Owner für Service Catalog - Management, Service Level Management und Change Enablement und - koordiniert die Service Operations Runde (SOR) als Vorsitz. - - Der SPM ist KEIN "Super-Service-Owner" – er trifft keine fachlich-inhaltlichen - Service-Entscheidungen, sondern stellt Governance-Konformität, - Portfolio-Konsistenz und methodische Standards sicher. - - wertbeitrag: - - "Portfolio-Transparenz: Gesamtüberblick über alle Services" - - "Governance-Sicherung: Einheitliche Standards und Prozesse" - - "Koordination: Vermittlung zwischen Service-Ebene und Steuerungsebene" - - "Methodische Führung: Best Practices für Service Management" - - "Review-Aggregation: Verdichtung von Service-Erkenntnissen für Steuerung" - -# ============================================================================= -# 2. ORGANISATORISCHE EINORDNUNG -# ============================================================================= - -organisatorische_einordnung: - - # --------------------------------------------------------------------------- - # DESIGNENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - designentscheidungen: - - - id: "D-SPM-01" - datum: "2025-12-17" - entscheidung: | - Es gibt keine separate "Leitung SPM". Die Leitungsfunktion für SPM - 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" - datum: "2025-12-17" - entscheidung: | - SPM ist organisatorisch der Abteilung Planung zugeordnet. - begruendung: | - Natürliche Nähe zu DPM. Beide Portfolio-Funktionen (Demand, Service) - sind in einer Abteilung gebündelt, was Koordination erleichtert. - - - id: "D-SPM-03" - datum: "2025-12-17" - entscheidung: | - SPM ist kein Mitglied des Mission Board. Die Leitung Planung - vertritt SPM im MB. SPM nimmt regelmäßig am MB teil, um über - den Status der Services zu berichten. - begruendung: | - MB-Mitgliedschaft auf Leitungsebene. SPM erhält Berichtsrecht - ohne Stimmrecht, was der operativen Rolle entspricht. - - # --------------------------------------------------------------------------- - # STRUKTURELLE VERORTUNG - # --------------------------------------------------------------------------- - abteilung: "Planung" - berichtslinie: "Leitung Planung" - - rollentyp: - art: "Einzelrolle" - hinweis: | - Im MVP wird SPM als Einzelrolle konzipiert. Bei Skalierung kann - die Rolle auf mehrere Personen aufgeteilt werden (z.B. nach - Service-Kategorien oder Practice-Bereichen). - - 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). - Die Entscheidung über Vertagung oder Eskalation verbleibt beim - vertretenden Vorsitz. - offener_punkt: "OPEN-SPM-002" - -# ============================================================================= -# 3. KERNAUFGABEN -# ============================================================================= - -kernaufgaben: - - # --------------------------------------------------------------------------- - # 3.1 PORTFOLIO-STEUERUNG - # --------------------------------------------------------------------------- - portfolio_steuerung: - - name: "Portfolio-Steuerung" - - beschreibung: | - Aufbau, Pflege und strategische Ausrichtung des Service-Portfolios. - Der SPM stellt sicher, dass das Portfolio die Bedarfe der Kunden - abdeckt und mit der DIGIT-Strategie aligned ist. - - aktivitaeten: - - - aufgabe: "Service-Kategorisierung vorbereiten" - raci: "R" - beschreibung: | - Vorbereitung der Kategorisierungs-Entscheidung (A/B/C) für - neue oder zu ändernde Services. SPM erstellt Empfehlung, - MB entscheidet. - governance_referenz: "GOV-001" - frequenz: "Bei Bedarf (neue Services, Änderungen)" - - - aufgabe: "Portfolio-Konsistenz sichern" - raci: "A" - beschreibung: | - Prüfung, dass Services zueinander passen, keine Redundanzen - bestehen und Abhängigkeiten dokumentiert sind. - frequenz: "Kontinuierlich" - - - aufgabe: "Portfolio-Standards definieren" - raci: "A" - beschreibung: | - Definition und Pflege von Standards für Service-Definitionen, - SLA-Templates, Steckbrief-Formate etc. - frequenz: "Bei Bedarf" - - - aufgabe: "Service-Impact bei Demands bewerten" - raci: "C" - beschreibung: | - Bei der Demand-Klassifizierung (DPM Phase 2) bewertet SPM: - - Auswirkungen auf bestehende Services - - Betroffene Services bei Umsetzung - - Abhängigkeiten zu anderen Services im Portfolio - schnittstelle: "DPM (Schritt 2.3)" - output: "Kurze Einschätzung für Entscheidungsvorlage" - hinweis: | - Die Routing-Entscheidung (Change vs. Demand) wurde in der - SHM-Bedarfsbewertung bereits getroffen. Sollte SPM feststellen, - dass ein Demand eher als Change behandelbar wäre, erfolgt ein - Hinweis an DPM zur Rückkopplung mit SHM. - - - aufgabe: "Strategischen Portfolio-Input liefern" - raci: "R" - beschreibung: | - Input für DIGIT-Strategieprozess basierend auf Portfolio-Analyse. - frequenz: "Jährlich (für Vision Board)" - - governance_referenzen: - - "GOV-001: Service-Kategorisierung" - - # --------------------------------------------------------------------------- - # 3.2 SERVICE CATALOG MANAGEMENT (PRACTICE OWNER) - # --------------------------------------------------------------------------- - service_catalog_management: - - name: "Service Catalog Management" - rolle: "Practice Owner" - governance_referenz: "GOV-006" - - beschreibung: | - Als Practice Owner für SCM verantwortet SPM die methodischen - Standards für den Service-Katalog. Die inhaltliche Pflege der - einzelnen Service-Einträge liegt bei den Service Ownern. - - aktivitaeten: - - - aufgabe: "Service-Definition validieren" - raci: "A" - beschreibung: | - Prüfung der vom SO erstellten Service-Definition auf - Vollständigkeit, Schema-Konformität und Portfolio-Konsistenz. - governance_referenz: "GOV-007" - aktivitaets_id: "scm_01" - - - aufgabe: "Katalogänderungen freigeben (Minor)" - raci: "A" - beschreibung: | - Bilaterale Freigabe von Minor-Änderungen mit dem SO. - Major-Änderungen gehen an die SOR. - governance_referenz: "GOV-008" - aktivitaets_id: "scm_05" - - - aufgabe: "Jährlichen Katalog-Review durchführen" - raci: "A/R" - beschreibung: | - Systematische Prüfung aller Service-Definitionen und - Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz. - frequenz: "Jährlich" - output: "Katalog-Review-Bericht für SOR" - aktivitaets_id: "scm_07" - - - aufgabe: "Service-Stilllegung im Katalog koordinieren" - raci: "A" - beschreibung: | - Verantwortet die Katalog-Aktualisierung bei Service-Stilllegung. - SO koordiniert die Kommunikation an Nutzer. - aktivitaets_id: "scm_06" - - - aufgabe: "Kundenverständlichkeit koordinieren" - raci: "A" - beschreibung: | - Koordiniert die Prüfung von Service-Steckbriefen auf - Kundenverständlichkeit durch SHM. Im MVP optional, - nicht blockierend. - governance_referenz: "GOV-009" - mvp_hinweis: "Optional, nicht blockierend" - - - aufgabe: "Katalog-Backlog führen" - raci: "A/R" - beschreibung: | - Sammlung und Priorisierung von Katalog-Verbesserungen, - inkl. Hinweise von DPM zu Anpassungsbedarf. - frequenz: "Kontinuierlich" - - referenz: "spm_practice_service-catalog-management.yaml" - - # --------------------------------------------------------------------------- - # 3.3 SERVICE LEVEL MANAGEMENT (PRACTICE OWNER) - # --------------------------------------------------------------------------- - service_level_management: - - name: "Service Level Management" - rolle: "Practice Owner" - - beschreibung: | - Als Practice Owner für SLM verantwortet SPM die methodischen - Standards für Service Level Agreements und deren Governance. - Die operative Durchführung (Erhebung, Abstimmung, Monitoring) - liegt bei den Service Ownern. - - aktivitaeten: - - - aufgabe: "SLA-Governance sicherstellen" - raci: "A" - beschreibung: | - Sicherstellung, dass SLAs governance-konform erstellt, - abgestimmt und freigegeben werden. - aktivitaets_id: "slm_03" - - - aufgabe: "SLA-Freigabeprozess koordinieren" - raci: "R" - beschreibung: | - Koordination der Freigabe: Standard-SLAs über SOR, - Abweichungen/Major-SLAs über MB. - aktivitaets_id: "slm_04" - - - aufgabe: "Portfolio-Konsistenz bei SLS/SLA prüfen" - raci: "C" - beschreibung: | - Prüfung, dass Service Level Specifications und SLAs - mit Portfolio-Standards konsistent sind. - aktivitaets_id: "slm_02" - - - aufgabe: "SLA-Eskalationen tracken" - raci: "C" - beschreibung: | - Dokumentation und Tracking von SLA-Verletzungen und - zugehörigen Maßnahmen auf Portfolio-Ebene. - governance_referenz: "GOV-002" - aktivitaets_id: "slm_07" - - referenz: "spm_practice_service-level-management.yaml" - - # --------------------------------------------------------------------------- - # 3.4 PORTFOLIO-REVIEW - # --------------------------------------------------------------------------- - portfolio_review: - - name: "Portfolio-Review" - - beschreibung: | - Aggregation und Verdichtung von Service-Review-Ergebnissen zu - einer Portfolio-Gesamtsicht. Der SPM erstellt regelmäßige - Status-Übersichten für die Steuerungsebene. - - aktivitaeten: - - - aufgabe: "Service-Review-Ergebnisse aggregieren" - raci: "A/R" - beschreibung: | - Zusammenführung der individuellen Service-Review-Ergebnisse - zu einer Portfolio-Gesamtsicht. Nutzung der Steckbrief-Daten, - kein zusätzliches Reporting durch SOs. - governance_referenz: "GOV-PR-001" - frequenz: "Quartalsweise" - - - aufgabe: "Portfolio-Status-Übersicht erstellen (E2)" - raci: "A/R" - beschreibung: | - Erstellung der quartalsweisen Portfolio-Status-Übersicht - für die SOR. Enthält Ampelstatus, Auffälligkeiten, - Handlungsbedarf. - governance_referenz: "GOV-PR-002" - frequenz: "Quartalsweise" - output: "Portfolio-Block für SOR" - - - aufgabe: "Portfolio-Block in SOR präsentieren" - raci: "R" - beschreibung: | - Vorstellung des Portfolio-Status in der SOR. - Identifikation von Services mit Handlungsbedarf. - governance_referenz: "GOV-PR-007" - frequenz: "Quartalsweise" - - - aufgabe: "Jahres-Portfolio-Report erstellen (E1)" - raci: "A/R" - beschreibung: | - Erstellung des jährlichen Portfolio-Reports für das - Vision Board. Strategische Analyse, Trends, Empfehlungen. - governance_referenz: "GOV-PR-002" - frequenz: "Jährlich" - output: "Jahres-Portfolio-Report für Vision Board" - - referenz: "spm_konzept_service-portfolio-review.yaml" - - # --------------------------------------------------------------------------- - # 3.5 SOR-VORSITZ - # --------------------------------------------------------------------------- - sor_vorsitz: - - name: "SOR-Vorsitz" - governance_referenz: "GOV-SOR-002" - - beschreibung: | - Der SPM führt den Vorsitz der Service Operations Runde (SOR). - Er hat Verfahrenshoheit, aber keinen Stichentscheid über - inhaltliche Fragen. - - aktivitaeten: - - - aufgabe: "SOR einberufen" - raci: "A/R" - beschreibung: "Festlegung der Termine, Einladung der Teilnehmer" - frequenz: "Alle 2 Wochen (Empfehlung)" - - - aufgabe: "Tagesordnung erstellen" - raci: "A/R" - beschreibung: | - Zusammenstellung der Agenda basierend auf: - - Transition-Gates (Gate 2) - - Portfolio-Review-Ergebnisse - - SO-Anfragen - - Eskalationen - frequenz: "Pro Sitzung" - - - aufgabe: "SOR moderieren" - raci: "R" - beschreibung: | - Leitung der Sitzung, Sicherstellung strukturierter Diskussion, - Herbeiführung von Entscheidungen. - frequenz: "Pro Sitzung" - - - aufgabe: "Bei Dissens koordinieren" - raci: "A/R" - beschreibung: | - Bei Meinungsverschiedenheiten: Strukturierung der Argumente, - Suche nach Kompromiss, ggf. Vertagung oder Eskalation. - KEIN Stichentscheid über Inhalte. - governance_referenz: "GOV-SOR-003" - - - aufgabe: "Über Vertagung/Eskalation entscheiden" - raci: "A" - beschreibung: | - Entscheidung, ob ein Thema vertagt oder ans MB eskaliert wird. - Dies ist eine Verfahrensentscheidung, keine inhaltliche. - - - aufgabe: "Protokollführung sicherstellen" - raci: "A" - beschreibung: | - Sicherstellung der Dokumentation. Kann an Teilnehmer - delegiert werden. - frequenz: "Pro Sitzung" - - referenz: "spm_sor_go.yaml" - - # --------------------------------------------------------------------------- - # 3.6 CROSS-SERVICE-KOORDINATION - # --------------------------------------------------------------------------- - cross_service_koordination: - - name: "Cross-Service-Koordination" - - beschreibung: | - Koordination bei Service-übergreifenden Themen und Sicherstellung - der Portfolio-Perspektive bei Service-Entscheidungen. - - aktivitaeten: - - - aufgabe: "Cross-Service-Changes bewerten" - raci: "C" - beschreibung: | - Bei Normal Changes mit potenziellem Cross-Service-Impact - wird SPM als "Zweite Augen" einbezogen. SPM prüft: - - Auswirkungen auf andere Services - - Erforderliche Abstimmung mit anderen SOs - - Ggf. SOR-Befassung erforderlich - governance_referenz: "GOV-CE-003" - - - aufgabe: "Service-Abhängigkeiten identifizieren" - raci: "A" - beschreibung: | - Pflege der Übersicht über Service-Abhängigkeiten im Portfolio. - Input für Impact-Bewertungen und Transition-Entscheidungen. - - - aufgabe: "Portfolio-Perspektive einbringen" - raci: "R" - beschreibung: | - Bei Service-Entscheidungen (Transition, Major Changes, - Stilllegung) die Portfolio-Perspektive einbringen. - gremien: ["SOR", "DSR"] - -# ============================================================================= -# 4. BEFUGNISSE -# ============================================================================= - -befugnisse: - - # --------------------------------------------------------------------------- - # EIGENSTÄNDIGE BEFUGNISSE - # --------------------------------------------------------------------------- - eigenstaendig: - - beschreibung: | - Entscheidungen, die der SPM ohne Gremien-Beteiligung treffen kann. - - befugnisse: - - - befugnis: "Katalog-Governance (Minor Changes)" - scope: "Bilaterale Freigabe mit SO" - governance_referenz: "GOV-008" - einschraenkung: "Major-Änderungen erfordern SOR" - - - befugnis: "Service-Definition validieren" - scope: "Alle Services" - governance_referenz: "GOV-007" - einschraenkung: "Validierung, nicht inhaltliche Änderung" - - - befugnis: "SOR-Verfahrensentscheidungen" - scope: "Einberufung, Tagesordnung, Vertagung, Eskalation" - governance_referenz: "GOV-SOR-002" - einschraenkung: "Kein Stichentscheid über Inhalte" - - - befugnis: "Portfolio-Review erstellen" - scope: "E2 (quartalsweise), E1 (jährlich)" - einschraenkung: "Aggregation, keine Einzelbewertung" - - - befugnis: "Methodische Standards definieren" - scope: "SCM, SLM, CE Practices" - einschraenkung: "Im Rahmen der Practice-Owner-Rolle" - - # --------------------------------------------------------------------------- - # BEFUGNISSE IN ABSTIMMUNG - # --------------------------------------------------------------------------- - in_abstimmung: - - beschreibung: | - Entscheidungen, die SPM gemeinsam mit anderen Rollen trifft. - - befugnisse: - - - befugnis: "Cross-Service-Change-Bewertung" - partner: "Service Owner" - verfahren: "SO entscheidet nach SPM-Konsultation" - governance_referenz: "GOV-CE-003" - - - befugnis: "Service-Perspektive bei Routing-Klärungen einbringen" - partner: "Service Owner, DPM, SHM" - verfahren: "Klärung bilateral mit Service Owner (ausgelöst durch ROUTE-SO) oder über DPM-Rückkopplung bei Unsicherheit" - governance_referenz: "GOV-SHM-029" - - # --------------------------------------------------------------------------- - # BEFUGNISSE ÜBER GREMIEN - # --------------------------------------------------------------------------- - ueber_gremien: - - beschreibung: | - Entscheidungen, die in Gremien getroffen werden, in denen SPM - eine definierte Rolle hat. - - befugnisse: - - - befugnis: "Service-Kategorisierung (A/B/C)" - gremium: "Mission Board" - spm_rolle: "Vorbereitung (R), Entscheidung liegt bei MB (A)" - governance_referenz: "GOV-001" - - - befugnis: "Service-Neuaufnahme (Katalog)" - gremium: "SOR" - spm_rolle: "Moderation (Vorsitz)" - - - befugnis: "SLA-Freigabe (Standard)" - gremium: "SOR" - spm_rolle: "Koordination" - - - befugnis: "SLA-Freigabe (Abweichung/Major)" - gremium: "Mission Board" - spm_rolle: "Via Leitung Planung" - - - befugnis: "Major Changes / Transition Gate 2" - gremium: "SOR" - spm_rolle: "Moderation (Vorsitz)" - governance_referenz: "GOV-TR-003" - - - befugnis: "Service-Stilllegung" - gremium: "SOR oder Mission Board" - spm_rolle: "Moderation (SOR) oder Vorbereitung (MB)" - -# ============================================================================= -# 5. EINSCHRÄNKUNGEN (NICHT-AUFGABEN) -# ============================================================================= - -einschraenkungen: - - beschreibung: | - Explizite Abgrenzung dessen, was NICHT zur Rolle des SPM gehört. - Diese Klarstellung vermeidet Rollenkonflikte und sichert die - Autonomie anderer Rollen. - - nicht_aufgaben: - - - bereich: "Fachliche Service-Entscheidungen" - beschreibung: | - SPM trifft keine inhaltlich-fachlichen Entscheidungen über - einzelne Services. Dies liegt beim Service Owner. - beispiele: - - "Welche Features hat ein Service?" - - "Wie wird ein Service technisch umgesetzt?" - - "Welche SLA-Zielwerte sind angemessen?" - zustaendig: "Service Owner" - - - bereich: "Service-Performance-Verantwortung" - beschreibung: | - SPM ist nicht für die Performance einzelner Services - verantwortlich. Er aggregiert nur auf Portfolio-Ebene. - zustaendig: "Service Owner" - - - bereich: "Demand-Priorisierung" - beschreibung: | - SPM priorisiert keine Demands. Dies liegt bei DPM bzw. - den Entscheidungsgremien (DSR, MB). - zustaendig: "DPM / DSR / MB" - - - bereich: "Operative Betriebsentscheidungen" - beschreibung: | - SPM trifft keine operativen Entscheidungen zum Betrieb - von Services (Incident-Handling, Ressourcen-Zuweisung etc.). - zustaendig: "Operations Manager / Support Manager" - - - bereich: "Stichentscheid bei SOR-Dissens" - beschreibung: | - SPM hat als SOR-Vorsitz Verfahrenshoheit, aber keinen - Stichentscheid über inhaltliche Fragen. Bei unauflösbarem - Dissens wird eskaliert. - governance_referenz: "GOV-SOR-003" - zustaendig: "Mission Board (bei Eskalation)" - - - bereich: "MB-Entscheidungen" - beschreibung: | - SPM ist kein MB-Mitglied und trifft keine MB-Entscheidungen. - Die Leitung Planung vertritt SPM-Interessen im MB. - zustaendig: "Leitung Planung / Mission Board" - - - bereich: "Kundenbeziehungsmanagement" - beschreibung: | - SPM ist nicht für die Beziehung zu einzelnen Stakeholdern - verantwortlich. Dies liegt bei SHM und den Service Ownern. - zustaendig: "Stakeholder-Manager / Service Owner" - -# ============================================================================= -# 6. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - # --------------------------------------------------------------------------- - # INTERNE SCHNITTSTELLEN - # --------------------------------------------------------------------------- - intern: - - # ------------------------------------------------------------------------- - service_owner: - - name: "Service Owner" - verhaeltnis: "1:n (SPM zu mehreren SOs)" - - interaktionen: - - - thema: "Service-Definition" - richtung: "SO → SPM" - beschreibung: "SO erstellt, SPM validiert und gibt frei" - governance_referenz: "GOV-007" - - - thema: "Katalog-Governance" - richtung: "Bidirektional" - beschreibung: | - Redaktionell: SO autonom - Minor: SO + SPM bilateral - Major: SOR (SPM moderiert) - governance_referenz: "GOV-008" - - - thema: "Cross-Service-Changes" - richtung: "SO → SPM" - beschreibung: "SO erkennt Impact, SPM als 'zweite Augen'" - governance_referenz: "GOV-CE-003" - - - thema: "Service-Review" - richtung: "SO → SPM" - beschreibung: "SO informiert über Review-Ergebnisse, SPM aggregiert" - governance_referenz: "GOV-SR-002" - - - thema: "SLA-Governance" - richtung: "Bidirektional" - beschreibung: "SO führt durch, SPM sichert Governance-Konformität" - - abgrenzung: | - SPM = Portfolio-Ebene (Was haben wir? Passt es zusammen?) - SO = Service-Ebene (Wie funktioniert mein Service?) - - frequenz: "Bei Bedarf + quartalsweiser Portfolio-Review" - - # ------------------------------------------------------------------------- - dpm: - - name: "Demand-Portfolio-Management" - - interaktionen: - - - thema: "Service-Impact-Bewertung" - richtung: "DPM → SPM" - beschreibung: | - Bei Demand-Klassifizierung (Phase 2, Schritt 2.3) konsultiert - DPM den SPM zur Bewertung von Service-Auswirkungen. - spm_aktivitaet: | - SPM prüft: - - Auswirkungen auf bestehende Services - - Betroffene Services bei Umsetzung - - Abhängigkeiten zu anderen Services im Portfolio - output: "Kurze Einschätzung (1-2 Sätze) für Entscheidungsvorlage" - raci: "DPM = R, SPM = C" - - - thema: "Routing-Klärung (via SO und SPM-Unterstützung)" - richtung: "Bidirektional" - beschreibung: | - Wenn SO bei der Service-Klassifizierung unsicher ist (ROUTE-SO), - unterstützt SPM mit Service-Identifikation und Portfolio-Perspektive. - Wenn DPM bei der Vollständigkeitsprüfung Zweifel am Routing hat - oder SO unsicher ist ob Demand erforderlich: DSR-Klärung oder - DPM-Rückkopplung. - governance_referenz: "GOV-SHM-029" - - - thema: "Katalog-Hinweise" - richtung: "DPM → SPM" - beschreibung: | - DPM gibt Hinweise auf Katalog-Anpassungsbedarf weiter. - SPM führt diese im Katalog-Backlog. - - gremium: "DSR (SPM als ständiges Mitglied)" - - designentscheidung: - id: "D-SPM-04" - entscheidung: | - SPM ist ständiges Mitglied der DSR. - begruendung: | - Portfolio-Perspektive bei Routing-Entscheidungen erforderlich. - DSR-Zusammensetzung: DPM (Vorsitz) + SHM + SPM. - - # ------------------------------------------------------------------------- - shm: - - name: "Stakeholder-Management" - - interaktionen: - - - thema: "Service-Katalog" - richtung: "SPM → SHM" - beschreibung: | - SPM stellt den Service-Katalog bereit, gegen den SHM - bei der Bedarfsbewertung prüft. - - - thema: "Bedarfs-Routing" - richtung: "SHM → SO (nicht SPM)" - beschreibung: | - SHM routet Changes direkt an den zuständigen Service Owner. - SPM wird nur einbezogen bei: - - Routing-Unklarheit (→ DSR) - - Cross-Service-Impact - - Major Change (→ SOR) - designentscheidung: - id: "D-SPM-05" - entscheidung: | - ROUTE-SPM (aus SHM-Dokumentation) wird als ROUTE-SO - interpretiert. Changes gehen an den SO, nicht an SPM. - begruendung: | - Change Authority ist SO, nicht SPM. SPM hat keine - operative Rolle bei der Change-Bearbeitung. - - - thema: "Kundenverständlichkeit" - richtung: "SHM → SPM" - beschreibung: | - SHM prüft Service-Steckbriefe auf Kundenverständlichkeit. - SPM koordiniert den Prozess, tracked Rückmeldungen. - governance_referenz: "GOV-009" - mvp_hinweis: "Optional, nicht blockierend" - - - thema: "Kundenforum" - richtung: "Bidirektional" - beschreibung: | - Das Kundenforum wird gemeinsam von SO und SHM moderiert. - SPM nimmt bei Kategorie-A-Services (Basisservices) teil, - bei anderen Kategorien optional. - governance_referenz: "GOV-012, GOV-SHM-015" - spm_rolle: - kategorie_a: "Teilnahme (Governance-Perspektive)" - kategorie_b_c: "Optional bei Portfolio-relevanten Themen" - - gremien: - - "DSR (SPM als ständiges Mitglied)" - - "SOR (SHM als ständiges Mitglied)" - - # ------------------------------------------------------------------------- - operations_support: - - name: "Operations Manager / Support Manager" - - interaktionen: - - - thema: "SOR-Zusammenarbeit" - beschreibung: | - Ops Mgr und Support Mgr sind ständige SOR-Mitglieder. - Gemeinsame Entscheidungen zu Transition, Major Changes, - Portfolio-Status. - governance_referenz: "GOV-SOR-002" - - - thema: "Betriebsreife-Bewertung" - beschreibung: | - Bei Transition Gate 2 bewertet Ops Mgr die Betriebsreife. - SPM moderiert als SOR-Vorsitz. - - - thema: "SSM-Reporting" - beschreibung: | - SPM ist Accountable für strategisches SSM-Reporting - auf Portfolio-Ebene. - - # ------------------------------------------------------------------------- - leitung_planung: - - name: "Leitung Planung" - - interaktionen: - - - thema: "Fachliche Berichtslinie" - beschreibung: "SPM berichtet an Leitung Planung" - - - thema: "MB-Vertretung" - beschreibung: | - Leitung Planung vertritt SPM-Interessen im Mission Board. - SPM nimmt regelmäßig am MB für Status-Reporting teil. - governance_referenz: "D-SPM-03" - - - thema: "Eskalation" - beschreibung: | - Bei Themen, die MB-Entscheidung erfordern, eskaliert - SPM über Leitung Planung. - - # --------------------------------------------------------------------------- - # EXTERNE SCHNITTSTELLEN - # --------------------------------------------------------------------------- - extern: - - ppm: - name: "Projekt-Portfolio-Management" - - interaktionen: - - - thema: "Projekt→Service-Übergang" - beschreibung: | - Nach Projektabschluss erfolgt der Übergang in den - Service-Betrieb. Der SO übernimmt bei Gate 1, - SPM koordiniert die SOR-Freigabe bei Gate 2. - offener_punkt: "OPEN-SPM-005" - - hinweis: | - Die Schnittstelle zu PPM ist im MVP nicht vollständig - operationalisiert. Sie wird bei der PPM-Konzeption - detailliert. - -# ============================================================================= -# 7. GREMIENROLLEN -# ============================================================================= - -gremienrollen: - - # --------------------------------------------------------------------------- - sor: - name: "Service Operations Runde (SOR)" - rolle: "Vorsitz" - status: "Ständiges stimmberechtigtes Mitglied" - governance_referenz: "GOV-SOR-002" - - funktion: | - Einberufung, Leitung, Tagesordnung, Protokoll, Moderation. - Verfahrenshoheit bei Dissens, Entscheidung über Vertagung - oder Eskalation. - - befugnisse: - - "Einberufung und Terminierung" - - "Tagesordnung festlegen" - - "Sitzung moderieren" - - "Vertagung oder Eskalation entscheiden" - - einschraenkungen: - - "Kein Stichentscheid über inhaltliche Fragen" - - frequenz: "Alle 2 Wochen (Empfehlung)" - - # --------------------------------------------------------------------------- - dsr: - name: "Demand & Stakeholder-Runde (DSR)" - rolle: "Ständiges Mitglied" - status: "Stimmberechtigtes Mitglied" - - funktion: | - Einbringung der Portfolio-Perspektive bei Demand-Entscheidungen - und Routing-Klärungen. Bewertung von Service-Impact. - - teilnahme_trigger: - - "Routing-Klärung (ROUTE-SO oder DPM-Rückkopplung)" - - "Service-Impact-Bewertung erforderlich" - - "Portfolio-relevante Demand-Entscheidungen" - - designentscheidung: "D-SPM-04" - - # --------------------------------------------------------------------------- - mb: - name: "Mission Board (MB)" - rolle: "Regelmäßiger Teilnehmer (kein Mitglied)" - status: "Berichtsrecht ohne Stimmrecht" - governance_referenz: "D-SPM-03" - - funktion: | - Status-Reporting Service-Portfolio. Präsentation des - Jahres-Portfolio-Reports. Vorbereitung von Entscheidungsvorlagen - (z.B. Service-Kategorisierung). - - vertretung: "Leitung Planung ist MB-Mitglied" - - frequenz: "Regelmäßig für Status-Reporting" - - # --------------------------------------------------------------------------- - vb: - name: "Vision Board (VB)" - rolle: "Berichterstatter (auf Einladung)" - - funktion: | - Jährliche Präsentation des Portfolio-Reports (E1). - Einbringung strategischer Portfolio-Empfehlungen. - - frequenz: "Jährlich" - -# ============================================================================= -# 8. ANFORDERUNGSPROFIL -# ============================================================================= - -anforderungsprofil: - - offener_punkt: "OPEN-SPM-001" - - hinweis: | - Das Anforderungsprofil wird im MVP generisch gehalten und - bei Bedarf mit DIGIT konkretisiert. - - # --------------------------------------------------------------------------- - fachlich: - - erforderlich: - - "Grundverständnis IT-Service-Management (ITIL4-Grundlagen)" - - "Verständnis kommunaler Verwaltungsprozesse" - - "Erfahrung mit Portfolio-Management oder Service-Katalog-Pflege" - - wuenschenswert: - - "ITIL4-Zertifizierung (Foundation oder höher)" - - "Erfahrung mit Service-Level-Agreements" - - "Kenntnisse in Prozessmodellierung" - - # --------------------------------------------------------------------------- - methodisch: - - erforderlich: - - "Strukturiertes, analytisches Arbeiten" - - "Fähigkeit zur Aggregation und Verdichtung von Informationen" - - "Dokumentationskompetenz" - - wuenschenswert: - - "Erfahrung mit Governance-Frameworks" - - "Moderationskompetenz für Gremien" - - # --------------------------------------------------------------------------- - persoenlich: - - erforderlich: - - "Koordinationsfähigkeit über Organisationseinheiten hinweg" - - "Kommunikationsstärke (schriftlich und mündlich)" - - "Fähigkeit, Konsens herzustellen ohne Autorität" - - wuenschenswert: - - "Durchsetzungsvermögen bei Governance-Fragen" - - "Gelassenheit bei Dissens" - -# ============================================================================= -# 9. OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-SPM-001" - thema: "Anforderungsprofil konkretisieren" - beschreibung: | - Das Anforderungsprofil ist generisch gehalten und sollte mit - DIGIT konkretisiert werden (z.B. konkrete Erfahrungsanforderungen, - Zertifizierungen). - prioritaet: "Mittel" - status: "Mit DIGIT zu klären" - - - id: "OPEN-SPM-002" - thema: "Vertretungsregelung formalisieren" - beschreibung: | - Die Vertretungsregelung bei SPM-Abwesenheit (insb. SOR-Vorsitz) - sollte formalisiert werden. - prioritaet: "Mittel" - status: "Mit DIGIT zu klären" - - - id: "OPEN-SPM-003" - thema: "Kapazitätsmodell" - beschreibung: | - Fragen zum Kapazitätsmodell sind im MVP nicht adressiert: - - Vollzeit oder Teilzeit? - - Wie viele SOs pro SPM? - - Bei Skalierung: Aufteilung nach welchen Kriterien? - prioritaet: "Niedrig (MVP)" - status: "Für spätere Phase" - - - id: "OPEN-SPM-004" - thema: "Reporting-Formate konkretisieren" - beschreibung: | - Die konkreten Formate für E1 (Jahres-Report) und E2 (Quartals-Status) - sind als Templates zu entwickeln. - prioritaet: "Niedrig (MVP)" - status: "Template-Entwicklung" - - - id: "OPEN-SPM-005" - thema: "Schnittstelle zu PPM" - beschreibung: | - Die Schnittstelle zu PPM (Projekt-Portfolio-Management) ist - nicht vollständig operationalisiert. Insbesondere: - - Projekt→Service-Übergabe - - Koordination bei Projekten mit Service-Impact - prioritaet: "Mittel" - status: "Bei PPM-Konzeption zu klären" - -# ============================================================================= -# 10. GOVERNANCE-REFERENZEN (KONSOLIDIERT) -# ============================================================================= - -governance_referenzen: - - beschreibung: | - Konsolidierte Liste aller Governance-Entscheidungen mit SPM-Relevanz. - - # --------------------------------------------------------------------------- - portfolio_governance: - - - id: "GOV-001" - thema: "Service-Kategorisierung" - spm_rolle: "Responsible (Vorbereitung)" - entscheider: "Mission Board" - - - id: "GOV-002" - thema: "SLA-Eskalationsmechanismus" - spm_rolle: "Dokumentation und Tracking" - - - id: "GOV-003" - thema: "Interner vs. externer Review" - spm_rolle: "Koordination internes Review" - - # --------------------------------------------------------------------------- - service_catalog_management: - - - id: "GOV-006" - thema: "SPM ist Practice Owner für SCM" - spm_rolle: "Practice Owner" - - - id: "GOV-007" - thema: "SO erstellt Service-Definition, SPM validiert" - spm_rolle: "Accountable (Validierung)" - - - id: "GOV-008" - thema: "Dreistufige Katalog-Governance" - spm_rolle: "Freigabe bei Minor, SOR-Vorsitz bei Major" - - - id: "GOV-009" - thema: "SHM-Einbindung für Kundenverständlichkeit" - spm_rolle: "Koordination" - mvp_hinweis: "Optional" - - - id: "GOV-010" - thema: "Trennung Inhalt (SPM) vs. Betrieb (Technik)" - spm_rolle: "Inhalt-Verantwortung" - - # --------------------------------------------------------------------------- - service_level_management: - - - id: "GOV-005" - thema: "SLA-Partner = Entscheidungsbefugte" - spm_rolle: "Governance-Konformität sicherstellen" - - - id: "GOV-012" - thema: "Integriertes Kundenforum" - spm_rolle: "Teilnahme bei Kat. A" - - # --------------------------------------------------------------------------- - service_transition: - - - id: "GOV-TR-002" - thema: "Gate 1 = SO-Einzelentscheidung" - spm_rolle: "Informiert" - - - id: "GOV-TR-003" - thema: "Gate 2 = SOR-Entscheidung" - spm_rolle: "SOR-Vorsitz (Moderation)" - - # --------------------------------------------------------------------------- - change_enablement: - - - id: "GOV-CE-001" - thema: "Emergency Changes" - spm_rolle: "Nicht beteiligt" - - - id: "GOV-CE-003" - thema: "Cross-Service-Impact" - spm_rolle: "Consulted ('Zweite Augen')" - - # --------------------------------------------------------------------------- - sor_governance: - - - id: "GOV-SOR-001" - thema: "Routing-Klärung bilateral über Service Owner (aktualisiert per GOV-SHM-029)" - spm_rolle: "Unterstützung und Portfolio-Perspektive" - - - id: "GOV-SOR-002" - thema: "SPM = SOR-Vorsitz" - spm_rolle: "Vorsitz, stimmberechtigtes Mitglied" - - - id: "GOV-SOR-003" - thema: "Koordination bei Dissens, kein Stichentscheid" - spm_rolle: "Verfahrenshoheit" - - # --------------------------------------------------------------------------- - portfolio_review: - - - id: "GOV-PR-001" - thema: "Aggregation aus Service-Steckbriefen" - spm_rolle: "Accountable/Responsible" - - - id: "GOV-PR-002" - thema: "E2 in SOR, E1 für VB" - spm_rolle: "Erstellt E1 und E2" - - - id: "GOV-PR-007" - thema: "SOR-Agenda für Portfolio-Reviews" - spm_rolle: "Erstellt und präsentiert Portfolio-Block" - -# ============================================================================= -# 11. ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-17" - aenderung: | - Initiale Erstellung der SPM-Rollenbeschreibung. - - Basierend auf: - - Konsolidierungs-Sprint (Governance-Entscheidungen, Practices) - - Schnittstellen-Validierung (DPM, SHM, SO) - - Designentscheidungen D-SPM-01 bis D-SPM-05 - - Konsolidierte Quellen: - - spm_governance-entscheidungen-log.yaml (20+ GOV-IDs) - - spm_practice_service-catalog-management.yaml - - spm_practice_service-level-management.yaml - - spm_practice_change-enablement.yaml - - spm_sor_go.yaml - - rolle_service-owner.yaml (Abgrenzung) - - dpm_funktionsbeschreibung.yaml (Schnittstelle) - - shm_bedarfsbewertung.yaml (Schnittstelle) - - shm_engagement-framework.yaml (Kundenforum) +# ============================================================================= +# ROLLENBESCHREIBUNG: SERVICE-PORTFOLIO-MANAGER (R-SPM) +# ============================================================================= +# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/ +# Dateiname: rolle_service-portfolio-manager.yaml +# ============================================================================= + +metadata: + id: "R-SPM" + name: "Service-Portfolio-Manager" + version: "1.0" + status: "draft" + erstellt: "2025-12-17" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "rollenbeschreibung" + + referenzen: + service_owner: "rolle_service-owner.yaml" + dpm: "dpm_rollenbeschreibung-dpm.yaml" + shm_rollen: "shm_rollen.yaml" + sor_go: "spm_sor_go.yaml" + governance_log: "spm_governance-entscheidungen-log.yaml" + scm_practice: "spm_practice_service-catalog-management.yaml" + slm_practice: "spm_practice_service-level-management.yaml" + change_enablement: "spm_practice_change-enablement.yaml" + +# ============================================================================= +# 1. ROLLENZWECK +# ============================================================================= + +rollenzweck: + + kurz: | + Der Service-Portfolio-Manager (SPM) verantwortet die Steuerung des + Service-Portfolios auf taktisch-koordinativer Ebene. Er stellt sicher, + dass das Portfolio konsistent, aktuell und an den strategischen Zielen + von DIGIT ausgerichtet ist. + + ausfuehrlich: | + Der SPM ist die zentrale Koordinationsrolle für alle portfolio-übergreifenden + Service-Management-Aktivitäten. Er verbindet die strategische Ebene + (Mission Board, Vision Board) mit der operativen Ebene (Service Owner, + Betriebsteams) und stellt sicher, dass Governance-Standards eingehalten werden. + + Im Unterschied zum Service Owner, der die End-to-End-Verantwortung für + einen einzelnen Service trägt, verantwortet der SPM die Portfolio-Perspektive + über alle Services hinweg. Er ist Practice Owner für Service Catalog + Management, Service Level Management und Change Enablement und + koordiniert die Service Operations Runde (SOR) als Vorsitz. + + Der SPM ist KEIN "Super-Service-Owner" – er trifft keine fachlich-inhaltlichen + Service-Entscheidungen, sondern stellt Governance-Konformität, + Portfolio-Konsistenz und methodische Standards sicher. + + wertbeitrag: + - "Portfolio-Transparenz: Gesamtüberblick über alle Services" + - "Governance-Sicherung: Einheitliche Standards und Prozesse" + - "Koordination: Vermittlung zwischen Service-Ebene und Steuerungsebene" + - "Methodische Führung: Best Practices für Service Management" + - "Review-Aggregation: Verdichtung von Service-Erkenntnissen für Steuerung" + +# ============================================================================= +# 2. ORGANISATORISCHE EINORDNUNG +# ============================================================================= + +organisatorische_einordnung: + + # --------------------------------------------------------------------------- + # DESIGNENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + designentscheidungen: + + - id: "D-SPM-01" + datum: "2025-12-17" + entscheidung: | + Es gibt keine separate "Leitung SPM". Die Leitungsfunktion für SPM + 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" + datum: "2025-12-17" + entscheidung: | + SPM ist organisatorisch der Abteilung Planung zugeordnet. + begruendung: | + Natürliche Nähe zu DPM. Beide Portfolio-Funktionen (Demand, Service) + sind in einer Abteilung gebündelt, was Koordination erleichtert. + + - id: "D-SPM-03" + datum: "2025-12-17" + entscheidung: | + SPM ist kein Mitglied des Mission Board. Die Leitung Planung + vertritt SPM im MB. SPM nimmt regelmäßig am MB teil, um über + den Status der Services zu berichten. + begruendung: | + MB-Mitgliedschaft auf Leitungsebene. SPM erhält Berichtsrecht + ohne Stimmrecht, was der operativen Rolle entspricht. + + # --------------------------------------------------------------------------- + # STRUKTURELLE VERORTUNG + # --------------------------------------------------------------------------- + abteilung: "Planung" + berichtslinie: "Leitung Planung" + + rollentyp: + art: "Einzelrolle" + hinweis: | + Im MVP wird SPM als Einzelrolle konzipiert. Bei Skalierung kann + die Rolle auf mehrere Personen aufgeteilt werden (z.B. nach + Service-Kategorien oder Practice-Bereichen). + + 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). + Die Entscheidung über Vertagung oder Eskalation verbleibt beim + vertretenden Vorsitz. + offener_punkt: "OPEN-SPM-002" + +# ============================================================================= +# 3. KERNAUFGABEN +# ============================================================================= + +kernaufgaben: + + # --------------------------------------------------------------------------- + # 3.1 PORTFOLIO-STEUERUNG + # --------------------------------------------------------------------------- + portfolio_steuerung: + + name: "Portfolio-Steuerung" + + beschreibung: | + Aufbau, Pflege und strategische Ausrichtung des Service-Portfolios. + Der SPM stellt sicher, dass das Portfolio die Bedarfe der Kunden + abdeckt und mit der DIGIT-Strategie aligned ist. + + aktivitaeten: + + - aufgabe: "Service-Kategorisierung vorbereiten" + raci: "R" + beschreibung: | + Vorbereitung der Kategorisierungs-Entscheidung (A/B/C) für + neue oder zu ändernde Services. SPM erstellt Empfehlung, + MB entscheidet. + governance_referenz: "GOV-001" + frequenz: "Bei Bedarf (neue Services, Änderungen)" + + - aufgabe: "Portfolio-Konsistenz sichern" + raci: "A" + beschreibung: | + Prüfung, dass Services zueinander passen, keine Redundanzen + bestehen und Abhängigkeiten dokumentiert sind. + frequenz: "Kontinuierlich" + + - aufgabe: "Portfolio-Standards definieren" + raci: "A" + beschreibung: | + Definition und Pflege von Standards für Service-Definitionen, + SLA-Templates, Steckbrief-Formate etc. + frequenz: "Bei Bedarf" + + - aufgabe: "Service-Impact bei Demands bewerten" + raci: "C" + beschreibung: | + Bei der Demand-Klassifizierung (DPM Phase 2) bewertet SPM: + - Auswirkungen auf bestehende Services + - Betroffene Services bei Umsetzung + - Abhängigkeiten zu anderen Services im Portfolio + schnittstelle: "DPM (Schritt 2.3)" + output: "Kurze Einschätzung für Entscheidungsvorlage" + hinweis: | + Die Routing-Entscheidung (Change vs. Demand) wurde in der + SHM-Bedarfsbewertung bereits getroffen. Sollte SPM feststellen, + dass ein Demand eher als Change behandelbar wäre, erfolgt ein + Hinweis an DPM zur Rückkopplung mit SHM. + + - aufgabe: "Strategischen Portfolio-Input liefern" + raci: "R" + beschreibung: | + Input für DIGIT-Strategieprozess basierend auf Portfolio-Analyse. + frequenz: "Jährlich (für Vision Board)" + + governance_referenzen: + - "GOV-001: Service-Kategorisierung" + + # --------------------------------------------------------------------------- + # 3.2 SERVICE CATALOG MANAGEMENT (PRACTICE OWNER) + # --------------------------------------------------------------------------- + service_catalog_management: + + name: "Service Catalog Management" + rolle: "Practice Owner" + governance_referenz: "GOV-006" + + beschreibung: | + Als Practice Owner für SCM verantwortet SPM die methodischen + Standards für den Service-Katalog. Die inhaltliche Pflege der + einzelnen Service-Einträge liegt bei den Service Ownern. + + aktivitaeten: + + - aufgabe: "Service-Definition validieren" + raci: "A" + beschreibung: | + Prüfung der vom SO erstellten Service-Definition auf + Vollständigkeit, Schema-Konformität und Portfolio-Konsistenz. + governance_referenz: "GOV-007" + aktivitaets_id: "scm_01" + + - aufgabe: "Katalogänderungen freigeben (Minor)" + raci: "A" + beschreibung: | + Bilaterale Freigabe von Minor-Änderungen mit dem SO. + Major-Änderungen gehen an die SOR. + governance_referenz: "GOV-008" + aktivitaets_id: "scm_05" + + - aufgabe: "Jährlichen Katalog-Review durchführen" + raci: "A/R" + beschreibung: | + Systematische Prüfung aller Service-Definitionen und + Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz. + frequenz: "Jährlich" + output: "Katalog-Review-Bericht für SOR" + aktivitaets_id: "scm_07" + + - aufgabe: "Service-Stilllegung im Katalog koordinieren" + raci: "A" + beschreibung: | + Verantwortet die Katalog-Aktualisierung bei Service-Stilllegung. + SO koordiniert die Kommunikation an Nutzer. + aktivitaets_id: "scm_06" + + - aufgabe: "Kundenverständlichkeit koordinieren" + raci: "A" + beschreibung: | + Koordiniert die Prüfung von Service-Steckbriefen auf + Kundenverständlichkeit durch SHM. Im MVP optional, + nicht blockierend. + governance_referenz: "GOV-009" + mvp_hinweis: "Optional, nicht blockierend" + + - aufgabe: "Katalog-Backlog führen" + raci: "A/R" + beschreibung: | + Sammlung und Priorisierung von Katalog-Verbesserungen, + inkl. Hinweise von DPM zu Anpassungsbedarf. + frequenz: "Kontinuierlich" + + referenz: "spm_practice_service-catalog-management.yaml" + + # --------------------------------------------------------------------------- + # 3.3 SERVICE LEVEL MANAGEMENT (PRACTICE OWNER) + # --------------------------------------------------------------------------- + service_level_management: + + name: "Service Level Management" + rolle: "Practice Owner" + + beschreibung: | + Als Practice Owner für SLM verantwortet SPM die methodischen + Standards für Service Level Agreements und deren Governance. + Die operative Durchführung (Erhebung, Abstimmung, Monitoring) + liegt bei den Service Ownern. + + aktivitaeten: + + - aufgabe: "SLA-Governance sicherstellen" + raci: "A" + beschreibung: | + Sicherstellung, dass SLAs governance-konform erstellt, + abgestimmt und freigegeben werden. + aktivitaets_id: "slm_03" + + - aufgabe: "SLA-Freigabeprozess koordinieren" + raci: "R" + beschreibung: | + Koordination der Freigabe: Standard-SLAs über SOR, + Abweichungen/Major-SLAs über MB. + aktivitaets_id: "slm_04" + + - aufgabe: "Portfolio-Konsistenz bei SLS/SLA prüfen" + raci: "C" + beschreibung: | + Prüfung, dass Service Level Specifications und SLAs + mit Portfolio-Standards konsistent sind. + aktivitaets_id: "slm_02" + + - aufgabe: "SLA-Eskalationen tracken" + raci: "C" + beschreibung: | + Dokumentation und Tracking von SLA-Verletzungen und + zugehörigen Maßnahmen auf Portfolio-Ebene. + governance_referenz: "GOV-002" + aktivitaets_id: "slm_07" + + referenz: "spm_practice_service-level-management.yaml" + + # --------------------------------------------------------------------------- + # 3.4 PORTFOLIO-REVIEW + # --------------------------------------------------------------------------- + portfolio_review: + + name: "Portfolio-Review" + + beschreibung: | + Aggregation und Verdichtung von Service-Review-Ergebnissen zu + einer Portfolio-Gesamtsicht. Der SPM erstellt regelmäßige + Status-Übersichten für die Steuerungsebene. + + aktivitaeten: + + - aufgabe: "Service-Review-Ergebnisse aggregieren" + raci: "A/R" + beschreibung: | + Zusammenführung der individuellen Service-Review-Ergebnisse + zu einer Portfolio-Gesamtsicht. Nutzung der Steckbrief-Daten, + kein zusätzliches Reporting durch SOs. + governance_referenz: "GOV-PR-001" + frequenz: "Quartalsweise" + + - aufgabe: "Portfolio-Status-Übersicht erstellen (E2)" + raci: "A/R" + beschreibung: | + Erstellung der quartalsweisen Portfolio-Status-Übersicht + für die SOR. Enthält Ampelstatus, Auffälligkeiten, + Handlungsbedarf. + governance_referenz: "GOV-PR-002" + frequenz: "Quartalsweise" + output: "Portfolio-Block für SOR" + + - aufgabe: "Portfolio-Block in SOR präsentieren" + raci: "R" + beschreibung: | + Vorstellung des Portfolio-Status in der SOR. + Identifikation von Services mit Handlungsbedarf. + governance_referenz: "GOV-PR-007" + frequenz: "Quartalsweise" + + - aufgabe: "Jahres-Portfolio-Report erstellen (E1)" + raci: "A/R" + beschreibung: | + Erstellung des jährlichen Portfolio-Reports für das + Vision Board. Strategische Analyse, Trends, Empfehlungen. + governance_referenz: "GOV-PR-002" + frequenz: "Jährlich" + output: "Jahres-Portfolio-Report für Vision Board" + + referenz: "spm_konzept_service-portfolio-review.yaml" + + # --------------------------------------------------------------------------- + # 3.5 SOR-VORSITZ + # --------------------------------------------------------------------------- + sor_vorsitz: + + name: "SOR-Vorsitz" + governance_referenz: "GOV-SOR-002" + + beschreibung: | + Der SPM führt den Vorsitz der Service Operations Runde (SOR). + Er hat Verfahrenshoheit, aber keinen Stichentscheid über + inhaltliche Fragen. + + aktivitaeten: + + - aufgabe: "SOR einberufen" + raci: "A/R" + beschreibung: "Festlegung der Termine, Einladung der Teilnehmer" + frequenz: "Alle 2 Wochen (Empfehlung)" + + - aufgabe: "Tagesordnung erstellen" + raci: "A/R" + beschreibung: | + Zusammenstellung der Agenda basierend auf: + - Transition-Gates (Gate 2) + - Portfolio-Review-Ergebnisse + - SO-Anfragen + - Eskalationen + frequenz: "Pro Sitzung" + + - aufgabe: "SOR moderieren" + raci: "R" + beschreibung: | + Leitung der Sitzung, Sicherstellung strukturierter Diskussion, + Herbeiführung von Entscheidungen. + frequenz: "Pro Sitzung" + + - aufgabe: "Bei Dissens koordinieren" + raci: "A/R" + beschreibung: | + Bei Meinungsverschiedenheiten: Strukturierung der Argumente, + Suche nach Kompromiss, ggf. Vertagung oder Eskalation. + KEIN Stichentscheid über Inhalte. + governance_referenz: "GOV-SOR-003" + + - aufgabe: "Über Vertagung/Eskalation entscheiden" + raci: "A" + beschreibung: | + Entscheidung, ob ein Thema vertagt oder ans MB eskaliert wird. + Dies ist eine Verfahrensentscheidung, keine inhaltliche. + + - aufgabe: "Protokollführung sicherstellen" + raci: "A" + beschreibung: | + Sicherstellung der Dokumentation. Kann an Teilnehmer + delegiert werden. + frequenz: "Pro Sitzung" + + referenz: "spm_sor_go.yaml" + + # --------------------------------------------------------------------------- + # 3.6 CROSS-SERVICE-KOORDINATION + # --------------------------------------------------------------------------- + cross_service_koordination: + + name: "Cross-Service-Koordination" + + beschreibung: | + Koordination bei Service-übergreifenden Themen und Sicherstellung + der Portfolio-Perspektive bei Service-Entscheidungen. + + aktivitaeten: + + - aufgabe: "Cross-Service-Changes bewerten" + raci: "C" + beschreibung: | + Bei Normal Changes mit potenziellem Cross-Service-Impact + wird SPM als "Zweite Augen" einbezogen. SPM prüft: + - Auswirkungen auf andere Services + - Erforderliche Abstimmung mit anderen SOs + - Ggf. SOR-Befassung erforderlich + governance_referenz: "GOV-CE-003" + + - aufgabe: "Service-Abhängigkeiten identifizieren" + raci: "A" + beschreibung: | + Pflege der Übersicht über Service-Abhängigkeiten im Portfolio. + Input für Impact-Bewertungen und Transition-Entscheidungen. + + - aufgabe: "Portfolio-Perspektive einbringen" + raci: "R" + beschreibung: | + Bei Service-Entscheidungen (Transition, Major Changes, + Stilllegung) die Portfolio-Perspektive einbringen. + gremien: ["SOR", "DSR"] + +# ============================================================================= +# 4. BEFUGNISSE +# ============================================================================= + +befugnisse: + + # --------------------------------------------------------------------------- + # EIGENSTÄNDIGE BEFUGNISSE + # --------------------------------------------------------------------------- + eigenstaendig: + + beschreibung: | + Entscheidungen, die der SPM ohne Gremien-Beteiligung treffen kann. + + befugnisse: + + - befugnis: "Katalog-Governance (Minor Changes)" + scope: "Bilaterale Freigabe mit SO" + governance_referenz: "GOV-008" + einschraenkung: "Major-Änderungen erfordern SOR" + + - befugnis: "Service-Definition validieren" + scope: "Alle Services" + governance_referenz: "GOV-007" + einschraenkung: "Validierung, nicht inhaltliche Änderung" + + - befugnis: "SOR-Verfahrensentscheidungen" + scope: "Einberufung, Tagesordnung, Vertagung, Eskalation" + governance_referenz: "GOV-SOR-002" + einschraenkung: "Kein Stichentscheid über Inhalte" + + - befugnis: "Portfolio-Review erstellen" + scope: "E2 (quartalsweise), E1 (jährlich)" + einschraenkung: "Aggregation, keine Einzelbewertung" + + - befugnis: "Methodische Standards definieren" + scope: "SCM, SLM, CE Practices" + einschraenkung: "Im Rahmen der Practice-Owner-Rolle" + + # --------------------------------------------------------------------------- + # BEFUGNISSE IN ABSTIMMUNG + # --------------------------------------------------------------------------- + in_abstimmung: + + beschreibung: | + Entscheidungen, die SPM gemeinsam mit anderen Rollen trifft. + + befugnisse: + + - befugnis: "Cross-Service-Change-Bewertung" + partner: "Service Owner" + verfahren: "SO entscheidet nach SPM-Konsultation" + governance_referenz: "GOV-CE-003" + + - befugnis: "Service-Perspektive bei Routing-Klärungen einbringen" + partner: "Service Owner, DPM, SHM" + verfahren: "Klärung bilateral mit Service Owner (ausgelöst durch ROUTE-SO) oder über DPM-Rückkopplung bei Unsicherheit" + governance_referenz: "GOV-SHM-029" + + # --------------------------------------------------------------------------- + # BEFUGNISSE ÜBER GREMIEN + # --------------------------------------------------------------------------- + ueber_gremien: + + beschreibung: | + Entscheidungen, die in Gremien getroffen werden, in denen SPM + eine definierte Rolle hat. + + befugnisse: + + - befugnis: "Service-Kategorisierung (A/B/C)" + gremium: "Mission Board" + spm_rolle: "Vorbereitung (R), Entscheidung liegt bei MB (A)" + governance_referenz: "GOV-001" + + - befugnis: "Service-Neuaufnahme (Katalog)" + gremium: "SOR" + spm_rolle: "Moderation (Vorsitz)" + + - befugnis: "SLA-Freigabe (Standard)" + gremium: "SOR" + spm_rolle: "Koordination" + + - befugnis: "SLA-Freigabe (Abweichung/Major)" + gremium: "Mission Board" + spm_rolle: "Via Leitung Planung" + + - befugnis: "Major Changes / Transition Gate 2" + gremium: "SOR" + spm_rolle: "Moderation (Vorsitz)" + governance_referenz: "GOV-TR-003" + + - befugnis: "Service-Stilllegung" + gremium: "SOR oder Mission Board" + spm_rolle: "Moderation (SOR) oder Vorbereitung (MB)" + +# ============================================================================= +# 5. EINSCHRÄNKUNGEN (NICHT-AUFGABEN) +# ============================================================================= + +einschraenkungen: + + beschreibung: | + Explizite Abgrenzung dessen, was NICHT zur Rolle des SPM gehört. + Diese Klarstellung vermeidet Rollenkonflikte und sichert die + Autonomie anderer Rollen. + + nicht_aufgaben: + + - bereich: "Fachliche Service-Entscheidungen" + beschreibung: | + SPM trifft keine inhaltlich-fachlichen Entscheidungen über + einzelne Services. Dies liegt beim Service Owner. + beispiele: + - "Welche Features hat ein Service?" + - "Wie wird ein Service technisch umgesetzt?" + - "Welche SLA-Zielwerte sind angemessen?" + zustaendig: "Service Owner" + + - bereich: "Service-Performance-Verantwortung" + beschreibung: | + SPM ist nicht für die Performance einzelner Services + verantwortlich. Er aggregiert nur auf Portfolio-Ebene. + zustaendig: "Service Owner" + + - bereich: "Demand-Priorisierung" + beschreibung: | + SPM priorisiert keine Demands. Dies liegt bei DPM bzw. + den Entscheidungsgremien (DSR, MB). + zustaendig: "DPM / DSR / MB" + + - bereich: "Operative Betriebsentscheidungen" + beschreibung: | + SPM trifft keine operativen Entscheidungen zum Betrieb + von Services (Incident-Handling, Ressourcen-Zuweisung etc.). + zustaendig: "Operations Manager / Support Manager" + + - bereich: "Stichentscheid bei SOR-Dissens" + beschreibung: | + SPM hat als SOR-Vorsitz Verfahrenshoheit, aber keinen + Stichentscheid über inhaltliche Fragen. Bei unauflösbarem + Dissens wird eskaliert. + governance_referenz: "GOV-SOR-003" + zustaendig: "Mission Board (bei Eskalation)" + + - bereich: "MB-Entscheidungen" + beschreibung: | + SPM ist kein MB-Mitglied und trifft keine MB-Entscheidungen. + Die Leitung Planung vertritt SPM-Interessen im MB. + zustaendig: "Leitung Planung / Mission Board" + + - bereich: "Kundenbeziehungsmanagement" + beschreibung: | + SPM ist nicht für die Beziehung zu einzelnen Stakeholdern + verantwortlich. Dies liegt bei SHM und den Service Ownern. + zustaendig: "Stakeholder-Manager / Service Owner" + +# ============================================================================= +# 6. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + # --------------------------------------------------------------------------- + # INTERNE SCHNITTSTELLEN + # --------------------------------------------------------------------------- + intern: + + # ------------------------------------------------------------------------- + service_owner: + + name: "Service Owner" + verhaeltnis: "1:n (SPM zu mehreren SOs)" + + interaktionen: + + - thema: "Service-Definition" + richtung: "SO → SPM" + beschreibung: "SO erstellt, SPM validiert und gibt frei" + governance_referenz: "GOV-007" + + - thema: "Katalog-Governance" + richtung: "Bidirektional" + beschreibung: | + Redaktionell: SO autonom + Minor: SO + SPM bilateral + Major: SOR (SPM moderiert) + governance_referenz: "GOV-008" + + - thema: "Cross-Service-Changes" + richtung: "SO → SPM" + beschreibung: "SO erkennt Impact, SPM als 'zweite Augen'" + governance_referenz: "GOV-CE-003" + + - thema: "Service-Review" + richtung: "SO → SPM" + beschreibung: "SO informiert über Review-Ergebnisse, SPM aggregiert" + governance_referenz: "GOV-SR-002" + + - thema: "SLA-Governance" + richtung: "Bidirektional" + beschreibung: "SO führt durch, SPM sichert Governance-Konformität" + + abgrenzung: | + SPM = Portfolio-Ebene (Was haben wir? Passt es zusammen?) + SO = Service-Ebene (Wie funktioniert mein Service?) + + frequenz: "Bei Bedarf + quartalsweiser Portfolio-Review" + + # ------------------------------------------------------------------------- + dpm: + + name: "Demand-Portfolio-Management" + + interaktionen: + + - thema: "Service-Impact-Bewertung" + richtung: "DPM → SPM" + beschreibung: | + Bei Demand-Klassifizierung (Phase 2, Schritt 2.3) konsultiert + DPM den SPM zur Bewertung von Service-Auswirkungen. + spm_aktivitaet: | + SPM prüft: + - Auswirkungen auf bestehende Services + - Betroffene Services bei Umsetzung + - Abhängigkeiten zu anderen Services im Portfolio + output: "Kurze Einschätzung (1-2 Sätze) für Entscheidungsvorlage" + raci: "DPM = R, SPM = C" + + - thema: "Routing-Klärung (via SO und SPM-Unterstützung)" + richtung: "Bidirektional" + beschreibung: | + Wenn SO bei der Service-Klassifizierung unsicher ist (ROUTE-SO), + unterstützt SPM mit Service-Identifikation und Portfolio-Perspektive. + Wenn DPM bei der Vollständigkeitsprüfung Zweifel am Routing hat + oder SO unsicher ist ob Demand erforderlich: DSR-Klärung oder + DPM-Rückkopplung. + governance_referenz: "GOV-SHM-029" + + - thema: "Katalog-Hinweise" + richtung: "DPM → SPM" + beschreibung: | + DPM gibt Hinweise auf Katalog-Anpassungsbedarf weiter. + SPM führt diese im Katalog-Backlog. + + gremium: "DSR (SPM als ständiges Mitglied)" + + designentscheidung: + id: "D-SPM-04" + entscheidung: | + SPM ist ständiges Mitglied der DSR. + begruendung: | + Portfolio-Perspektive bei Routing-Entscheidungen erforderlich. + DSR-Zusammensetzung: DPM (Vorsitz) + SHM + SPM. + + # ------------------------------------------------------------------------- + shm: + + name: "Stakeholder-Management" + + interaktionen: + + - thema: "Service-Katalog" + richtung: "SPM → SHM" + beschreibung: | + SPM stellt den Service-Katalog bereit, gegen den SHM + bei der Bedarfsbewertung prüft. + + - thema: "Bedarfs-Routing" + richtung: "SHM → SO (nicht SPM)" + beschreibung: | + SHM routet Changes direkt an den zuständigen Service Owner. + SPM wird nur einbezogen bei: + - Routing-Unklarheit (→ DSR) + - Cross-Service-Impact + - Major Change (→ SOR) + designentscheidung: + id: "D-SPM-05" + entscheidung: | + ROUTE-SPM (aus SHM-Dokumentation) wird als ROUTE-SO + interpretiert. Changes gehen an den SO, nicht an SPM. + begruendung: | + Change Authority ist SO, nicht SPM. SPM hat keine + operative Rolle bei der Change-Bearbeitung. + + - thema: "Kundenverständlichkeit" + richtung: "SHM → SPM" + beschreibung: | + SHM prüft Service-Steckbriefe auf Kundenverständlichkeit. + SPM koordiniert den Prozess, tracked Rückmeldungen. + governance_referenz: "GOV-009" + mvp_hinweis: "Optional, nicht blockierend" + + - thema: "Kundenforum" + richtung: "Bidirektional" + beschreibung: | + Das Kundenforum wird gemeinsam von SO und SHM moderiert. + SPM nimmt bei Kategorie-A-Services (Basisservices) teil, + bei anderen Kategorien optional. + governance_referenz: "GOV-012, GOV-SHM-015" + spm_rolle: + kategorie_a: "Teilnahme (Governance-Perspektive)" + kategorie_b_c: "Optional bei Portfolio-relevanten Themen" + + gremien: + - "DSR (SPM als ständiges Mitglied)" + - "SOR (SHM als ständiges Mitglied)" + + # ------------------------------------------------------------------------- + operations_support: + + name: "Operations Manager / Support Manager" + + interaktionen: + + - thema: "SOR-Zusammenarbeit" + beschreibung: | + Ops Mgr und Support Mgr sind ständige SOR-Mitglieder. + Gemeinsame Entscheidungen zu Transition, Major Changes, + Portfolio-Status. + governance_referenz: "GOV-SOR-002" + + - thema: "Betriebsreife-Bewertung" + beschreibung: | + Bei Transition Gate 2 bewertet Ops Mgr die Betriebsreife. + SPM moderiert als SOR-Vorsitz. + + - thema: "SSM-Reporting" + beschreibung: | + SPM ist Accountable für strategisches SSM-Reporting + auf Portfolio-Ebene. + + # ------------------------------------------------------------------------- + leitung_planung: + + name: "Leitung Planung" + + interaktionen: + + - thema: "Fachliche Berichtslinie" + beschreibung: "SPM berichtet an Leitung Planung" + + - thema: "MB-Vertretung" + beschreibung: | + Leitung Planung vertritt SPM-Interessen im Mission Board. + SPM nimmt regelmäßig am MB für Status-Reporting teil. + governance_referenz: "D-SPM-03" + + - thema: "Eskalation" + beschreibung: | + Bei Themen, die MB-Entscheidung erfordern, eskaliert + SPM über Leitung Planung. + + # --------------------------------------------------------------------------- + # EXTERNE SCHNITTSTELLEN + # --------------------------------------------------------------------------- + extern: + + ppm: + name: "Projekt-Portfolio-Management" + + interaktionen: + + - thema: "Projekt→Service-Übergang" + beschreibung: | + Nach Projektabschluss erfolgt der Übergang in den + Service-Betrieb. Der SO übernimmt bei Gate 1, + SPM koordiniert die SOR-Freigabe bei Gate 2. + offener_punkt: "OPEN-SPM-005" + + hinweis: | + Die Schnittstelle zu PPM ist im MVP nicht vollständig + operationalisiert. Sie wird bei der PPM-Konzeption + detailliert. + +# ============================================================================= +# 7. GREMIENROLLEN +# ============================================================================= + +gremienrollen: + + # --------------------------------------------------------------------------- + sor: + name: "Service Operations Runde (SOR)" + rolle: "Vorsitz" + status: "Ständiges stimmberechtigtes Mitglied" + governance_referenz: "GOV-SOR-002" + + funktion: | + Einberufung, Leitung, Tagesordnung, Protokoll, Moderation. + Verfahrenshoheit bei Dissens, Entscheidung über Vertagung + oder Eskalation. + + befugnisse: + - "Einberufung und Terminierung" + - "Tagesordnung festlegen" + - "Sitzung moderieren" + - "Vertagung oder Eskalation entscheiden" + + einschraenkungen: + - "Kein Stichentscheid über inhaltliche Fragen" + + frequenz: "Alle 2 Wochen (Empfehlung)" + + # --------------------------------------------------------------------------- + dsr: + name: "Demand & Stakeholder-Runde (DSR)" + rolle: "Ständiges Mitglied" + status: "Stimmberechtigtes Mitglied" + + funktion: | + Einbringung der Portfolio-Perspektive bei Demand-Entscheidungen + und Routing-Klärungen. Bewertung von Service-Impact. + + teilnahme_trigger: + - "Routing-Klärung (ROUTE-SO oder DPM-Rückkopplung)" + - "Service-Impact-Bewertung erforderlich" + - "Portfolio-relevante Demand-Entscheidungen" + + designentscheidung: "D-SPM-04" + + # --------------------------------------------------------------------------- + mb: + name: "Mission Board (MB)" + rolle: "Regelmäßiger Teilnehmer (kein Mitglied)" + status: "Berichtsrecht ohne Stimmrecht" + governance_referenz: "D-SPM-03" + + funktion: | + Status-Reporting Service-Portfolio. Präsentation des + Jahres-Portfolio-Reports. Vorbereitung von Entscheidungsvorlagen + (z.B. Service-Kategorisierung). + + vertretung: "Leitung Planung ist MB-Mitglied" + + frequenz: "Regelmäßig für Status-Reporting" + + # --------------------------------------------------------------------------- + vb: + name: "Vision Board (VB)" + rolle: "Berichterstatter (auf Einladung)" + + funktion: | + Jährliche Präsentation des Portfolio-Reports (E1). + Einbringung strategischer Portfolio-Empfehlungen. + + frequenz: "Jährlich" + +# ============================================================================= +# 8. ANFORDERUNGSPROFIL +# ============================================================================= + +anforderungsprofil: + + offener_punkt: "OPEN-SPM-001" + + hinweis: | + Das Anforderungsprofil wird im MVP generisch gehalten und + bei Bedarf mit DIGIT konkretisiert. + + # --------------------------------------------------------------------------- + fachlich: + + erforderlich: + - "Grundverständnis IT-Service-Management (ITIL4-Grundlagen)" + - "Verständnis kommunaler Verwaltungsprozesse" + - "Erfahrung mit Portfolio-Management oder Service-Katalog-Pflege" + + wuenschenswert: + - "ITIL4-Zertifizierung (Foundation oder höher)" + - "Erfahrung mit Service-Level-Agreements" + - "Kenntnisse in Prozessmodellierung" + + # --------------------------------------------------------------------------- + methodisch: + + erforderlich: + - "Strukturiertes, analytisches Arbeiten" + - "Fähigkeit zur Aggregation und Verdichtung von Informationen" + - "Dokumentationskompetenz" + + wuenschenswert: + - "Erfahrung mit Governance-Frameworks" + - "Moderationskompetenz für Gremien" + + # --------------------------------------------------------------------------- + persoenlich: + + erforderlich: + - "Koordinationsfähigkeit über Organisationseinheiten hinweg" + - "Kommunikationsstärke (schriftlich und mündlich)" + - "Fähigkeit, Konsens herzustellen ohne Autorität" + + wuenschenswert: + - "Durchsetzungsvermögen bei Governance-Fragen" + - "Gelassenheit bei Dissens" + +# ============================================================================= +# 9. OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-SPM-001" + thema: "Anforderungsprofil konkretisieren" + beschreibung: | + Das Anforderungsprofil ist generisch gehalten und sollte mit + DIGIT konkretisiert werden (z.B. konkrete Erfahrungsanforderungen, + Zertifizierungen). + prioritaet: "Mittel" + status: "Mit DIGIT zu klären" + + - id: "OPEN-SPM-002" + thema: "Vertretungsregelung formalisieren" + beschreibung: | + Die Vertretungsregelung bei SPM-Abwesenheit (insb. SOR-Vorsitz) + sollte formalisiert werden. + prioritaet: "Mittel" + status: "Mit DIGIT zu klären" + + - id: "OPEN-SPM-003" + thema: "Kapazitätsmodell" + beschreibung: | + Fragen zum Kapazitätsmodell sind im MVP nicht adressiert: + - Vollzeit oder Teilzeit? + - Wie viele SOs pro SPM? + - Bei Skalierung: Aufteilung nach welchen Kriterien? + prioritaet: "Niedrig (MVP)" + status: "Für spätere Phase" + + - id: "OPEN-SPM-004" + thema: "Reporting-Formate konkretisieren" + beschreibung: | + Die konkreten Formate für E1 (Jahres-Report) und E2 (Quartals-Status) + sind als Templates zu entwickeln. + prioritaet: "Niedrig (MVP)" + status: "Template-Entwicklung" + + - id: "OPEN-SPM-005" + thema: "Schnittstelle zu PPM" + beschreibung: | + Die Schnittstelle zu PPM (Projekt-Portfolio-Management) ist + nicht vollständig operationalisiert. Insbesondere: + - Projekt→Service-Übergabe + - Koordination bei Projekten mit Service-Impact + prioritaet: "Mittel" + status: "Bei PPM-Konzeption zu klären" + +# ============================================================================= +# 10. GOVERNANCE-REFERENZEN (KONSOLIDIERT) +# ============================================================================= + +governance_referenzen: + + beschreibung: | + Konsolidierte Liste aller Governance-Entscheidungen mit SPM-Relevanz. + + # --------------------------------------------------------------------------- + portfolio_governance: + + - id: "GOV-001" + thema: "Service-Kategorisierung" + spm_rolle: "Responsible (Vorbereitung)" + entscheider: "Mission Board" + + - id: "GOV-002" + thema: "SLA-Eskalationsmechanismus" + spm_rolle: "Dokumentation und Tracking" + + - id: "GOV-003" + thema: "Interner vs. externer Review" + spm_rolle: "Koordination internes Review" + + # --------------------------------------------------------------------------- + service_catalog_management: + + - id: "GOV-006" + thema: "SPM ist Practice Owner für SCM" + spm_rolle: "Practice Owner" + + - id: "GOV-007" + thema: "SO erstellt Service-Definition, SPM validiert" + spm_rolle: "Accountable (Validierung)" + + - id: "GOV-008" + thema: "Dreistufige Katalog-Governance" + spm_rolle: "Freigabe bei Minor, SOR-Vorsitz bei Major" + + - id: "GOV-009" + thema: "SHM-Einbindung für Kundenverständlichkeit" + spm_rolle: "Koordination" + mvp_hinweis: "Optional" + + - id: "GOV-010" + thema: "Trennung Inhalt (SPM) vs. Betrieb (Technik)" + spm_rolle: "Inhalt-Verantwortung" + + # --------------------------------------------------------------------------- + service_level_management: + + - id: "GOV-005" + thema: "SLA-Partner = Entscheidungsbefugte" + spm_rolle: "Governance-Konformität sicherstellen" + + - id: "GOV-012" + thema: "Integriertes Kundenforum" + spm_rolle: "Teilnahme bei Kat. A" + + # --------------------------------------------------------------------------- + service_transition: + + - id: "GOV-TR-002" + thema: "Gate 1 = SO-Einzelentscheidung" + spm_rolle: "Informiert" + + - id: "GOV-TR-003" + thema: "Gate 2 = SOR-Entscheidung" + spm_rolle: "SOR-Vorsitz (Moderation)" + + # --------------------------------------------------------------------------- + change_enablement: + + - id: "GOV-CE-001" + thema: "Emergency Changes" + spm_rolle: "Nicht beteiligt" + + - id: "GOV-CE-003" + thema: "Cross-Service-Impact" + spm_rolle: "Consulted ('Zweite Augen')" + + # --------------------------------------------------------------------------- + sor_governance: + + - id: "GOV-SOR-001" + thema: "Routing-Klärung bilateral über Service Owner (aktualisiert per GOV-SHM-029)" + spm_rolle: "Unterstützung und Portfolio-Perspektive" + + - id: "GOV-SOR-002" + thema: "SPM = SOR-Vorsitz" + spm_rolle: "Vorsitz, stimmberechtigtes Mitglied" + + - id: "GOV-SOR-003" + thema: "Koordination bei Dissens, kein Stichentscheid" + spm_rolle: "Verfahrenshoheit" + + # --------------------------------------------------------------------------- + portfolio_review: + + - id: "GOV-PR-001" + thema: "Aggregation aus Service-Steckbriefen" + spm_rolle: "Accountable/Responsible" + + - id: "GOV-PR-002" + thema: "E2 in SOR, E1 für VB" + spm_rolle: "Erstellt E1 und E2" + + - id: "GOV-PR-007" + thema: "SOR-Agenda für Portfolio-Reviews" + spm_rolle: "Erstellt und präsentiert Portfolio-Block" + +# ============================================================================= +# 11. ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-17" + aenderung: | + Initiale Erstellung der SPM-Rollenbeschreibung. + + Basierend auf: + - Konsolidierungs-Sprint (Governance-Entscheidungen, Practices) + - Schnittstellen-Validierung (DPM, SHM, SO) + - Designentscheidungen D-SPM-01 bis D-SPM-05 + + Konsolidierte Quellen: + - spm_governance-entscheidungen-log.yaml (20+ GOV-IDs) + - spm_practice_service-catalog-management.yaml + - spm_practice_service-level-management.yaml + - spm_practice_change-enablement.yaml + - spm_sor_go.yaml + - rolle_service-owner.yaml (Abgrenzung) + - dpm_funktionsbeschreibung.yaml (Schnittstelle) + - shm_bedarfsbewertung.yaml (Schnittstelle) + - shm_engagement-framework.yaml (Kundenforum) autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-definition.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-definition.yaml index ab7368f..687bcd1 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-definition.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-definition.yaml @@ -1,1033 +1,1033 @@ -# ============================================================================= -# SCHEMA: SERVICE-DEFINITION -# ============================================================================= -# -# Dieses Schema definiert die Struktur einer Service-Definition. -# Die Service-Definition ist das interne Master-Dokument, das alle -# relevanten Informationen zu einem Service enthält (Single Source of Truth). -# -# Abgrenzung: -# - Service-Definition = internes Master-Dokument (dieses Schema) -# - Service-Steckbrief = kundenorientierter Auszug (separates Schema) -# -# ============================================================================= - -schema: - name: "Service-Definition" - version: "0.1" - status: "draft" - erstellt: "2025-11-27" - projekt: "DIGITOM" - - beschreibung: > - Die Service-Definition ist das zentrale Artefakt des Service Catalog - Management. Sie enthält alle Informationen, die DIGIT intern über - einen Service wissen muss – von der fachlichen Beschreibung über - Qualitätsparameter bis hin zu Betriebsmodell und Governance. - - verantwortung: - erstellung: "Service Owner (A/R)" - validierung: "Service-Portfolio-Manager (A/R)" - freigabe: "SOR oder Mission Board (je nach Kategorie)" - - referenzen: - glossar: "service-portfolio-management_glossar.yaml" - practice: "spm_practice_service-catalog-management.yaml" - abgeleitetes_artefakt: "spm_schema_service-steckbrief.yaml" - -# ============================================================================= -# ATTRIBUT-DEFINITIONEN -# ============================================================================= - -attribute: - - # --------------------------------------------------------------------------- - # METADATEN - # --------------------------------------------------------------------------- - metadaten: - beschreibung: "Verwaltungsinformationen zur Service-Definition selbst" - - attribute: - - name: "service_id" - typ: "string" - pflicht: true - beschreibung: "Eindeutiger Identifier des Services (z.B. SVC-001)" - beispiel: "SVC-042" - - - name: "version" - typ: "string" - pflicht: true - beschreibung: "Versionsnummer der Service-Definition" - format: "semver (major.minor)" - beispiel: "1.2" - - - name: "status" - typ: "enum" - pflicht: true - beschreibung: | - Dokumenten-Status der Service-Definition. Beschreibt die Gültigkeit - des Dokuments, NICHT die Lifecycle-Phase des Services. - Siehe Abschnitt 'lifecycle' für den Lifecycle-Status. - werte: - - "entwurf" # In Erstellung - - "freigegeben" # Aktiv und gültig - - "archiviert" # Historisch, nicht mehr gültig - hinweis: "Nicht zu verwechseln mit lifecycle_status (GOV-TR-019)" - - - name: "erstellt_am" - typ: "date" - pflicht: true - beschreibung: "Datum der Ersterstellung" - - - name: "geaendert_am" - typ: "date" - pflicht: true - beschreibung: "Datum der letzten Änderung" - - - name: "freigegeben_am" - typ: "date" - pflicht: false - beschreibung: "Datum der letzten Freigabe" - bedingung: "Pflicht wenn status = 'freigegeben'" - - - name: "freigegeben_durch" - typ: "string" - pflicht: false - beschreibung: "Gremium oder Rolle, die die Freigabe erteilt hat" - beispiel: "SOR" - bedingung: "Pflicht wenn status = 'freigegeben'" - - # --------------------------------------------------------------------------- - # LIFECYCLE-STATUS - # --------------------------------------------------------------------------- - lifecycle: - beschreibung: | - Der Lifecycle-Status beschreibt die aktuelle Phase des Services im - Service-Lifecycle. Er ist unabhängig vom Dokumenten-Status der - Service-Definition (Attribut 'status' in metadata). - - governance_referenz: "GOV-TR-019" - - attribute: - - name: "lifecycle_status" - typ: "enum" - pflicht: true - beschreibung: "Aktuelle Phase des Services im Lifecycle" - werte: - - id: "in_entwicklung" - beschreibung: "Service befindet sich in der Entwicklungsphase (Projekt läuft)" - gate_voraussetzung: null - nachfolger: ["in_transition", "abgebrochen"] - - - id: "in_transition" - beschreibung: "Service hat Gate 1 passiert, befindet sich in Transition" - gate_voraussetzung: "Gate 1 (Entry Transition)" - nachfolger: ["aktiv", "in_entwicklung"] - - - id: "aktiv" - beschreibung: "Service ist live und für Nutzer verfügbar" - gate_voraussetzung: "Gate 2 (Go-Live-Freigabe)" - nachfolger: ["in_stilllegung"] - - - id: "in_stilllegung" - beschreibung: "Stilllegung eingeleitet, Service noch verfügbar mit Einschränkungen" - gate_voraussetzung: "SOR-Stilllegungsbeschluss" - nachfolger: ["stillgelegt"] - - - id: "stillgelegt" - beschreibung: "Service ist deaktiviert und aus dem Katalog entfernt" - gate_voraussetzung: "Stilllegung abgeschlossen" - nachfolger: [] - - - id: "abgebrochen" - beschreibung: "Service wurde vor Go-Live abgebrochen (Projektabbruch)" - gate_voraussetzung: "Projektabbruch-Entscheidung" - nachfolger: [] - - - name: "lifecycle_status_seit" - typ: "date" - pflicht: true - beschreibung: "Datum des letzten Status-Übergangs" - - - name: "lifecycle_status_durch" - typ: "string" - pflicht: false - beschreibung: "Entscheidungsinstanz des letzten Übergangs (z.B. 'SO', 'SOR')" - - mapping_zu_dokument_status: - beschreibung: | - Der Dokumenten-Status (metadata.status) und der Lifecycle-Status sind - unabhängig, aber es gibt typische Korrelationen. - - regeln: - - lifecycle: "in_entwicklung" - dokument_status_typisch: "entwurf" - dokument_status_erlaubt: ["entwurf"] - - - lifecycle: "in_transition" - dokument_status_typisch: "entwurf" - dokument_status_erlaubt: ["entwurf", "freigegeben"] - - - lifecycle: "aktiv" - dokument_status_erforderlich: "freigegeben" - dokument_status_erlaubt: ["freigegeben"] - - - lifecycle: "in_stilllegung" - dokument_status_typisch: "freigegeben" - dokument_status_erlaubt: ["freigegeben"] - - - lifecycle: "stillgelegt" - dokument_status_typisch: "archiviert" - dokument_status_erlaubt: ["freigegeben", "archiviert"] - - - lifecycle: "abgebrochen" - dokument_status_typisch: "archiviert" - dokument_status_erlaubt: ["entwurf", "archiviert"] - - # --------------------------------------------------------------------------- - # IDENTITÄT & ZWECK - # --------------------------------------------------------------------------- - identitaet: - beschreibung: "Grundlegende Identifikation und Zweckbestimmung des Services" - - attribute: - - name: "service_name" - typ: "string" - pflicht: true - beschreibung: "Offizieller Name des Services" - beispiel: "Digitaler Arbeitsplatz" - - - name: "service_name_kurz" - typ: "string" - pflicht: false - beschreibung: "Kurzbezeichnung oder Akronym" - beispiel: "DAP" - - - name: "kurzbeschreibung" - typ: "string" - pflicht: true - beschreibung: "Einzeilige Beschreibung des Services (max. 200 Zeichen)" - max_laenge: 200 - - - name: "zweck" - typ: "text" - pflicht: true - beschreibung: > - Warum existiert dieser Service? Welches Problem löst er? - Welchen Nutzen stiftet er für die Verwaltung? - glossar_referenz: "Nutzen (Utility)" - - - name: "zielgruppe" - typ: "list[string]" - pflicht: true - beschreibung: "Für wen ist der Service bestimmt?" - beispiel: - - "Alle Mitarbeitenden der Stadtverwaltung" - - "Amtsleitungen" - - "Amt für Soziales (exklusiv)" - - - name: "service_kategorie" - typ: "enum" - pflicht: true - beschreibung: "Strategische Kategorie gemäß Portfolio-Stratifikation" - werte: - - id: "A" - name: "Basis-Services" - beschreibung: "Flächendeckend, umlagefinanziert, nicht abwählbar" - - id: "B" - name: "Erweiterte Services" - beschreibung: "Optional, bedarfsgesteuert, clusterspezifisch" - - id: "C" - name: "Spezial-Services" - beschreibung: "Individuell, hochgradig domänenspezifisch" - - id: "I" - name: "Interne Services" - beschreibung: "Interne Governance-Objekte, nicht im Katalog sichtbar" - sichtbarkeit: "per Definition nicht im Service-Katalog" - referenz: "P-02 Service Level Management, Kernkonzepte" - governance_referenz: "GOV-SPM-I-001" - - # --------------------------------------------------------------------------- - # LEISTUNGSUMFANG (UTILITY) - # --------------------------------------------------------------------------- - leistungsumfang: - beschreibung: "Was der Service leistet und was nicht" - glossar_referenz: "Nutzen (Utility)" - - attribute: - - name: "leistungen_inkludiert" - typ: "list[string]" - pflicht: true - beschreibung: "Konkrete Leistungen, die der Service umfasst" - beispiel: - - "Bereitstellung eines Windows-Arbeitsplatzes" - - "Standard-Office-Anwendungen" - - "E-Mail-Postfach (5 GB)" - - - name: "leistungen_exkludiert" - typ: "list[string]" - pflicht: true - beschreibung: "Explizit nicht enthaltene Leistungen (Abgrenzung)" - beispiel: - - "Spezialsoftware (siehe Erweiterte Services)" - - "Mobile Endgeräte (separater Service)" - - - name: "service_komponenten" - typ: "list[objekt]" - pflicht: false - beschreibung: "Technische oder fachliche Bestandteile des Services" - schema: - - name: "komponente_name" - typ: "string" - - name: "komponente_beschreibung" - typ: "string" - - name: "komponente_typ" - typ: "enum" - werte: ["hardware", "software", "plattform", "prozess", "sonstiges"] - - - name: "voraussetzungen" - typ: "list[string]" - pflicht: false - beschreibung: "Was muss gegeben sein, damit der Service genutzt werden kann?" - beispiel: - - "Gültiger Benutzeraccount im Active Directory" - - "Abgeschlossene Datenschutzunterweisung" - - # --------------------------------------------------------------------------- - # QUALITÄT & SERVICE LEVELS (WARRANTY) - # --------------------------------------------------------------------------- - qualitaet: - beschreibung: "Qualitätszusagen und Service Levels" - glossar_referenz: "Service Level, Gewährleistung (Warranty)" - - attribute: - - name: "service_level_referenz" - typ: "objekt" - pflicht: true - beschreibung: > - Verweis auf die geltenden Service Levels. - Die Struktur unterscheidet sich je nach Service-Kategorie. - schema: - - name: "typ" - typ: "enum" - werte: - - id: "SLS" - beschreibung: "Separates SLS-Dokument (Kategorie A, B)" - - id: "SLA_integriert" - beschreibung: "Service Levels im bilateralen SLA (Kategorie C)" - - id: "OLA" - beschreibung: "Operational Level Agreement (für Kategorie I – Interne Services)" - hinweis: "OLA-Feld bleibt in Pilotphase leer (keine Placeholder-Werte). Begründung siehe Pilot-Scope-Dokumentation." - governance_referenz: "GOV-SPM-I-002" - - name: "dokument_id" - typ: "string" - beschreibung: "Referenz auf SLS oder SLA" - - name: "hinweis" - typ: "string" - pflicht: false - beschreibung: "Zusätzliche Erläuterung, z.B. 'SLS siehe Abschnitt 4 des SLA'" - - - name: "verfuegbarkeit" - typ: "objekt" - pflicht: true - beschreibung: "Wann ist der Service verfügbar?" - schema: - - name: "servicezeit" - typ: "string" - beschreibung: "Reguläre Betriebszeit" - beispiel: "Mo-Fr 06:00-22:00, Sa 08:00-14:00" - - name: "supportzeit" - typ: "string" - beschreibung: "Zeiten mit aktivem Support" - beispiel: "Mo-Fr 08:00-17:00" - - name: "wartungsfenster" - typ: "string" - beschreibung: "Geplante Wartungszeiten" - beispiel: "So 02:00-06:00" - - - name: "sla_governance" - typ: "objekt" - pflicht: true - beschreibung: "Governance-Struktur für Service Level Agreements" - schema: - - name: "sla_partner" - typ: "string" - beschreibung: "Wer ist der SLA-Partner auf Kundenseite?" - beispiel_kategorie_a: "Kundenvertretung Basisservices" - beispiel_kategorie_b: "Kundenvertretung [Servicename]" - beispiel_kategorie_c: "Amtsleitung [Amt]" - - name: "review_zyklus" - typ: "string" - beschreibung: "Wie oft wird das SLA reviewed?" - beispiel: "jährlich" - referenz: "P-02 Service Level Management, GOV-001 bis GOV-005" - - # --------------------------------------------------------------------------- - # VERANTWORTLICHKEITEN - # --------------------------------------------------------------------------- - verantwortlichkeiten: - beschreibung: "Rollen und Zuständigkeiten für den Service" - - attribute: - - name: "service_owner" - typ: "objekt" - pflicht: true - beschreibung: "Fachlich Gesamtverantwortlicher für den Service" - glossar_referenz: "Service-Owner:in" - schema: - - name: "rolle_id" - typ: "string" - beschreibung: "Referenz auf Rollendefinition" - wert: "service_owner" - - name: "person_name" - typ: "string" - beschreibung: "Aktuelle:r Rolleninhaber:in" - - name: "person_kontakt" - typ: "string" - beschreibung: "E-Mail oder Telefon" - - name: "stellvertretung" - typ: "string" - pflicht: false - - - name: "weitere_rollen" - typ: "list[objekt]" - pflicht: false - beschreibung: "Weitere relevante Rollen für diesen Service" - schema: - - name: "rolle_id" - typ: "string" - beschreibung: "Referenz auf spm_rollen.yaml" - - name: "person_name" - typ: "string" - - name: "kontext" - typ: "string" - beschreibung: "Spezifische Verantwortung im Service-Kontext" - - # --------------------------------------------------------------------------- - # ABHÄNGIGKEITEN - # --------------------------------------------------------------------------- - abhaengigkeiten: - beschreibung: > - Beziehungen zu anderen Services, Systemen und externen Partnern. - Hinweis: Im MVP wird keine CMDB-Integration vorausgesetzt. - Abhängigkeiten werden manuell gepflegt. - - attribute: - - name: "abhaengig_von" - typ: "list[objekt]" - pflicht: false - beschreibung: "Services oder Systeme, von denen dieser Service abhängt" - schema: - - name: "service_id" - typ: "string" - beschreibung: "ID des abhängigen Services (falls DIGIT-intern)" - - name: "name" - typ: "string" - beschreibung: "Name des abhängigen Services/Systems" - - name: "typ" - typ: "enum" - werte: ["intern", "extern", "infrastruktur"] - - name: "kritikalitaet" - typ: "enum" - werte: ["kritisch", "wichtig", "optional"] - beschreibung: "Auswirkung bei Ausfall der Abhängigkeit" - - - name: "genutzt_von" - typ: "list[objekt]" - pflicht: false - beschreibung: "Services, die diesen Service nutzen" - schema: - - name: "service_id" - typ: "string" - - name: "name" - typ: "string" - - - name: "externe_lieferanten" - typ: "list[objekt]" - pflicht: false - beschreibung: "Externe Anbieter, die zur Service-Erbringung beitragen" - schema: - - name: "lieferant_name" - typ: "string" - - name: "leistung" - typ: "string" - - name: "vertrag_referenz" - typ: "string" - pflicht: false - - hinweis_cmdb: > - Placeholder für zukünftige CMDB-Integration. Im MVP werden - Abhängigkeiten manuell in der Service-Definition gepflegt. - Langfristig sollte eine bidirektionale Synchronisation mit - der CMDB erfolgen (Service Configuration Management Practice). - - # --------------------------------------------------------------------------- - # BETRIEBSMODELL - # --------------------------------------------------------------------------- - betriebsmodell: - beschreibung: "Wie wird der Service operativ erbracht?" - - attribute: - - name: "betriebsverantwortung" - typ: "enum" - pflicht: true - beschreibung: "Wer betreibt den Service operativ?" - werte: - - id: "intern" - beschreibung: "Vollständig durch DIGIT" - - id: "hybrid" - beschreibung: "DIGIT + externe Partner" - - id: "extern_gesteuert" - beschreibung: "Externer Betrieb, DIGIT steuert" - - - name: "betriebsteam" - typ: "string" - pflicht: true - beschreibung: "Zuständiges Team/Gruppe innerhalb DIGIT" - beispiel: "Team Infrastruktur, Gruppe Netzwerk" - - - name: "support_modell" - typ: "objekt" - pflicht: true - beschreibung: "Wie ist der Support organisiert?" - schema: - - name: "first_level" - typ: "string" - beschreibung: "Wer nimmt Anfragen entgegen?" - beispiel: "Service Desk DIGIT" - - name: "second_level" - typ: "string" - beschreibung: "Wer bearbeitet komplexere Anfragen?" - - name: "third_level" - typ: "string" - pflicht: false - beschreibung: "Spezialistenebene (falls vorhanden)" - - - name: "request_wege" - typ: "list[string]" - pflicht: true - beschreibung: "Wie kann der Service angefragt/beauftragt werden?" - beispiel: - - "Self-Service-Portal" - - "Service Desk Ticket" - - "E-Mail an servicedesk@digit.freiburg.de" - - - name: "monitoring" - typ: "objekt" - pflicht: false - beschreibung: "Wie wird der Service überwacht?" - schema: - - name: "monitoring_aktiv" - typ: "boolean" - - name: "metriken" - typ: "list[string]" - beschreibung: "Welche KPIs werden überwacht?" - - name: "alerting" - typ: "string" - beschreibung: "Wie werden Störungen erkannt und eskaliert?" - - # --------------------------------------------------------------------------- - # KOSTEN & RESSOURCEN - # --------------------------------------------------------------------------- - kosten: - beschreibung: "Wirtschaftliche Aspekte des Services" - - attribute: - - name: "kostenmodell" - typ: "enum" - pflicht: true - beschreibung: "Wie werden die Kosten verrechnet?" - werte: - - id: "umlage" - beschreibung: "Zentral finanziert, keine Einzelverrechnung (typisch Kat. A)" - - id: "nutzungsbasiert" - beschreibung: "Verrechnung nach Nutzung/Anzahl" - - id: "pauschal" - beschreibung: "Fixe Pauschale je Nutzer/Amt" - - id: "projekt" - beschreibung: "Projektfinanziert (typisch Kat. C)" - - - name: "kostentreiber" - typ: "list[string]" - pflicht: false - beschreibung: "Hauptfaktoren, die die Kosten beeinflussen" - beispiel: - - "Anzahl Arbeitsplätze" - - "Speichervolumen" - - "Lizenzkosten Hersteller" - - - name: "budget_referenz" - typ: "string" - pflicht: false - beschreibung: "Verweis auf Budgetposition/Kostenstelle" - - # --------------------------------------------------------------------------- - # COMPLIANCE & SICHERHEIT - # --------------------------------------------------------------------------- - compliance: - beschreibung: "Regulatorische und sicherheitsrelevante Aspekte" - - attribute: - - name: "datenschutz_klassifikation" - typ: "enum" - pflicht: true - beschreibung: "Datenschutzrelevanz des Services" - werte: - - "keine_pbD" # Keine personenbezogenen Daten - - "pbD_normal" # Personenbezogene Daten, normaler Schutzbedarf - - "pbD_hoch" # Personenbezogene Daten, hoher Schutzbedarf - - "besondere_kategorien" # Art. 9 DSGVO - - - name: "rechtsgrundlagen" - typ: "list[string]" - pflicht: false - beschreibung: "Relevante Rechtsgrundlagen für den Service" - beispiel: - - "DSGVO" - - "LDSG BW" - - "E-Government-Gesetz BW" - - - name: "schutzbedarf" - typ: "objekt" - pflicht: false - beschreibung: "IT-Sicherheits-Schutzbedarf nach BSI" - schema: - - name: "vertraulichkeit" - typ: "enum" - werte: ["normal", "hoch", "sehr_hoch"] - - name: "integritaet" - typ: "enum" - werte: ["normal", "hoch", "sehr_hoch"] - - name: "verfuegbarkeit" - typ: "enum" - werte: ["normal", "hoch", "sehr_hoch"] - - - name: "sicherheitsmassnahmen" - typ: "list[string]" - pflicht: false - beschreibung: "Wesentliche technische/organisatorische Maßnahmen" - - # --------------------------------------------------------------------------- - # GESCHÄFTSKRITIKALITÄT - # --------------------------------------------------------------------------- - geschaeftskritikalitaet: - beschreibung: > - Bewertung der Bedeutung des Services für den Geschäftsbetrieb, - basierend auf einer vereinfachten Business Impact Analysis (BIA). - Dient als Grundlage für die Impact-Bewertung im Incident Management - und für Wartungsfenster-Restriktionen im Change Enablement. - - itil4_referenz: "Business Impact Analysis (BIA), Vital Business Functions (VBF)" - - verantwortung: - bewertung: "Service Owner (R)" - entscheidung: "SOR (A)" - - attribute: - - name: "kritikalitaetsstufe" - typ: "enum" - pflicht: true - beschreibung: "Einstufung der Geschäftskritikalität des Services" - werte: - - id: "geschaeftskritisch" - beschreibung: > - Ausfall führt unmittelbar zu Handlungsunfähigkeit wesentlicher - Verwaltungsbereiche. Kein oder nur sehr eingeschränkter - Workaround verfügbar. - rto_indikator: "< 4 Stunden" - impact_mapping: "Störung → automatisch Impact HOCH" - beispiele: - - "Netzwerk-Backbone" - - "Zentrales Identitätsmanagement (Active Directory)" - - "SAP-Kernsystem" - - "Telefonanlage Bürgerservice" - - - id: "wichtig" - beschreibung: > - Ausfall beeinträchtigt Arbeitsfähigkeit erheblich. - Workarounds möglich, aber aufwändig oder nur temporär tragbar. - rto_indikator: "4–24 Stunden" - impact_mapping: "Störung → standardmäßig Impact NORMAL, Hochstufung bei >10 Betroffenen" - beispiele: - - "E-Mail-System" - - "Standard-Arbeitsplatz" - - "Dokumentenmanagementsystem" - - "Fachverfahren mit Tagesgeschäft-Relevanz" - - - id: "unterstuetzend" - beschreibung: > - Ausfall verursacht Komforteinbußen. Kernarbeit bleibt möglich, - einfache Workarounds verfügbar. - rto_indikator: "> 24 Stunden" - impact_mapping: "Störung → standardmäßig Impact NIEDRIG" - beispiele: - - "Raumbuchungssystem" - - "Intranet-Redaktionssystem" - - "Nicht-kritische Reporting-Tools" - - - name: "rto_stunden" - typ: "number" - pflicht: false - beschreibung: > - Recovery Time Objective – maximale tolerierbare Ausfallzeit - in Stunden, bevor der Geschäftsbetrieb schwerwiegend - beeinträchtigt wird. - empfehlung: "Sollte für Services der Kategorie A und B angegeben werden" - validierung: "Muss konsistent mit kritikalitaetsstufe sein (siehe VAL-005)" - - - name: "betroffene_kernprozesse" - typ: "list[string]" - pflicht: false - beschreibung: > - Verwaltungsprozesse, die durch den Service unterstützt werden. - Dient der Nachvollziehbarkeit der Kritikalitätsbewertung. - hinweis: > - Freitext-Eingabe. Perspektivisch Referenz auf zentralen - Prozesskatalog der Stadtverwaltung (sofern verfügbar). - beispiel: - - "Bürgerservice / Antragsbearbeitung" - - "Personalwesen / Gehaltsabrechnung" - - "Haushaltswesen / Zahlungsverkehr" - - - name: "kritikalitaet_begruendung" - typ: "text" - pflicht: true - beschreibung: > - Nachvollziehbare Begründung der Kritikalitätseinstufung. - Muss erklären, warum der Service die gewählte Stufe hat - und welche Auswirkungen ein Ausfall konkret hätte. - beispiel: > - "Der Service unterstützt die zentrale Authentifizierung aller - Mitarbeitenden. Bei Ausfall können sich Nutzer nicht anmelden, - was sämtliche IT-gestützten Arbeitsprozesse blockiert. - Kein Workaround verfügbar." - - # --------------------------------------------------------------------------- - # SERVICE-REVIEW-STATUS - # --------------------------------------------------------------------------- - service_review: - beschreibung: | - Aktueller Stand des quartalsweisen Service-Reviews (GOV-SR-001, GOV-SR-002). - Diese Informationen sind interne Steuerungsdaten und werden NICHT im - kundenorientierten Service-Steckbrief publiziert. - - governance_referenz: "GOV-SR-001, GOV-SR-002, GOV-SR-005" - referenz: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" - - attribute: - - name: "letzter_review_datum" - typ: "date" - pflicht: false - beschreibung: "Datum des letzten abgeschlossenen Quartals-Reviews" - quelle: "Service Owner nach Review-Durchführung" - format: "YYYY-MM-DD" - - - name: "review_ergebnis" - typ: "objekt" - pflicht: false - beschreibung: "Ergebnis des letzten Reviews nach 4-Dimensionen-Modell" - quelle: "Service Owner" - referenz: "konzept_service-review.yaml -> bewertungsschema" - schema: - - name: "d1_leistungserbringung" - typ: "enum" - werte: ["gruen", "gelb", "rot"] - beschreibung: "Bewertung Dimension 1: Liefert der Service den erwarteten Nutzen?" - - name: "d2_betriebsstabilitaet" - typ: "enum" - werte: ["gruen", "gelb", "rot"] - beschreibung: "Bewertung Dimension 2: Laeuft der Service stoerungsarm?" - - name: "d3_nutzerzufriedenheit" - typ: "enum" - werte: ["gruen", "gelb", "rot"] - beschreibung: "Bewertung Dimension 3: Wie bewerten die Nutzer den Service?" - - name: "d4_zukunftsfaehigkeit" - typ: "enum" - werte: ["gruen", "gelb", "rot"] - beschreibung: "Bewertung Dimension 4: Ist der Service mittelfristig tragfaehig?" - - name: "handlungsempfehlung" - typ: "enum" - werte: ["continue", "improvement", "redesign", "retire"] - beschreibung: "Abgeleitete Handlungsempfehlung des SO" - - name: "begruendung" - typ: "text" - pflicht: false - beschreibung: "Kurzbegruendung bei Abweichung von typischer Konstellation" - - - name: "naechster_review_faellig" - typ: "date" - pflicht: false - beschreibung: "Faelligkeitsdatum des naechsten Quartals-Reviews" - berechnung: "letzter_review_datum + 3 Monate" - - # --------------------------------------------------------------------------- - # LAUFENDE VERBESSERUNGEN (IMPROVEMENT-TRACKING) - # --------------------------------------------------------------------------- - laufende_verbesserungen: - beschreibung: | - Improvement-Tracking gemaess Service-Review-Konzept (GOV-SR-005). - Diese Informationen sind interne Steuerungsdaten und werden NICHT im - kundenorientierten Service-Steckbrief publiziert. - - governance_referenz: "GOV-SR-005" - referenz: "konzept_service-review.yaml -> improvement_steuerung.mvp_loesung" - - attribute: - - name: "massnahmen" - typ: "list[objekt]" - pflicht: false - beschreibung: "Aktive und abgeschlossene Improvement-Massnahmen" - schema: - - name: "id" - typ: "string" - pflicht: true - format: "IMP-[SERVICE-ID]-[NNN]" - beispiel: "IMP-SVC-042-001" - - name: "beschreibung" - typ: "string" - pflicht: true - max_zeichen: 200 - beschreibung: "Kurzbeschreibung der Massnahme" - - name: "ziel_dimension" - typ: "enum" - pflicht: true - werte: ["SR-D1", "SR-D2", "SR-D3", "SR-D4"] - beschreibung: "Welche Review-Dimension soll verbessert werden?" - - name: "verantwortlich" - typ: "string" - pflicht: true - beschreibung: "Person oder Rolle fuer Umsetzung" - - name: "zieltermin" - typ: "date" - pflicht: true - - name: "status" - typ: "enum" - pflicht: true - werte: ["offen", "in_arbeit", "abgeschlossen", "abgebrochen"] - - name: "wirksamkeit" - typ: "enum" - pflicht: false - werte: ["wirksam", "teilweise_wirksam", "nicht_wirksam", "nicht_bewertet"] - beschreibung: "Bewertung im Folge-Review" - - name: "kommentar" - typ: "text" - pflicht: false - beschreibung: "Ergaenzende Informationen oder Wirksamkeits-Begruendung" - - # --------------------------------------------------------------------------- - # DOKUMENTATION & REFERENZEN - # --------------------------------------------------------------------------- - dokumentation: - beschreibung: "Verweise auf weitere Dokumente und Ressourcen" - - attribute: - - name: "dokumente" - typ: "list[objekt]" - pflicht: false - beschreibung: "Verknüpfte Dokumente" - schema: - - name: "titel" - typ: "string" - - name: "typ" - typ: "enum" - werte: - - "sls" - - "sla" - - "betriebshandbuch" - - "benutzerhandbuch" - - "faq" - - "schulungsunterlage" - - "sonstiges" - - name: "pfad_oder_url" - typ: "string" - - name: "stand" - typ: "date" - - - name: "aenderungshistorie" - typ: "list[objekt]" - pflicht: true - beschreibung: "Änderungsprotokoll der Service-Definition" - schema: - - name: "version" - typ: "string" - - name: "datum" - typ: "date" - - name: "autor" - typ: "string" - - name: "aenderung" - typ: "string" - -# ============================================================================= -# VALIDIERUNGSREGELN -# ============================================================================= - -validierung: - - regeln: - - id: "VAL-001" - beschreibung: "Service-Kategorie muss konsistent mit SLA-Governance sein" - regel: > - Wenn service_kategorie = 'A', dann sla_partner muss - 'Kundenvertretung Basisservices' sein. - - - id: "VAL-002" - beschreibung: "Kategorie C erfordert SLA_integriert" - regel: > - Wenn service_kategorie = 'C', dann service_level_referenz.typ - muss 'SLA_integriert' sein. - - - id: "VAL-003" - beschreibung: "Service Owner muss benannt sein" - regel: > - service_owner.person_name darf nicht leer sein. - - - id: "VAL-004" - beschreibung: "Freigabe erfordert vollständige Pflichtfelder" - regel: > - Vor Statuswechsel auf 'freigegeben' müssen alle Pflichtfelder - ausgefüllt sein. - - - id: "VAL-005" - beschreibung: "RTO-Konsistenz mit Kritikalitätsstufe" - regel: > - Wenn rto_stunden angegeben ist, sollte die kritikalitaetsstufe - konsistent sein: - - rto_stunden < 4 → kritikalitaetsstufe sollte 'geschaeftskritisch' sein - - rto_stunden 4-24 → kritikalitaetsstufe sollte 'wichtig' sein - - rto_stunden > 24 → kritikalitaetsstufe sollte 'unterstuetzend' sein - Abweichungen sind zulässig, erfordern aber eine explizite - Begründung in kritikalitaet_begruendung. - - - id: "VAL-006" - beschreibung: "Kategorie I erfordert OLA als SLA-Typ" - regel: > - Wenn service_kategorie = 'I', dann service_level_referenz.typ - muss 'OLA' sein. Umgekehrt darf 'OLA' nur bei Kategorie I - verwendet werden. - governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-002" - - - id: "VAL-007" - beschreibung: "Kategorie I ist nicht im Katalog" - regel: > - Wenn service_kategorie = 'I', dann darf kein Service-Steckbrief - für den Service-Katalog publiziert werden. Interne Services - werden ausschließlich über die Service-Definition gesteuert. - governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003" - -# ============================================================================= -# MAPPING: SERVICE-DEFINITION → SERVICE-STECKBRIEF -# ============================================================================= - -mapping_steckbrief: - beschreibung: > - Definiert, welche Attribute der Service-Definition in den - Service-Steckbrief (kundenorientierte Sicht) übernommen werden. - - uebernommen: - - service_name - - kurzbeschreibung - - zweck - - zielgruppe - - service_kategorie - - leistungen_inkludiert - - leistungen_exkludiert - - voraussetzungen - - service_level_referenz - - verfuegbarkeit.servicezeit - - verfuegbarkeit.supportzeit - - request_wege - - service_owner.person_name # nur Name, nicht Kontaktdetails - - nicht_uebernommen: - - service_komponenten # zu technisch - - betriebsteam # internes Detail - - support_modell # internes Detail - - monitoring # internes Detail - - kostentreiber # internes Detail - - budget_referenz # internes Detail - - schutzbedarf # internes Detail - - sicherheitsmassnahmen # internes Detail - - aenderungshistorie # internes Detail - - geschaeftskritikalitaet # interne Steuerungsgröße, nicht kundenrelevant - - service_review # interne Steuerungsdaten (Review-Status, Dimensionsbewertung) - - laufende_verbesserungen # interne Steuerungsdaten (Improvement-Tracking) - - transformiert: - - quelle: "compliance.datenschutz_klassifikation" - ziel: "datenschutz_hinweis" - transformation: "Ableitung eines kundenverständlichen Hinweistextes" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - id: "OPEN-SCHEMA-001" - beschreibung: "CMDB-Integration: Attribut-Mapping definieren" - prioritaet: "niedrig" - status: "Placeholder im MVP" - - - id: "OPEN-SCHEMA-002" - beschreibung: "Template für Service-Definition erstellen (Markdown/Word)" - prioritaet: "mittel" - ziel_ordner: "02.6_arbeitsmaterialien" - - - id: "OPEN-SCHEMA-003" - beschreibung: "Schema Service-Steckbrief ableiten" - prioritaet: "hoch" - abhaengig_von: "Review dieses Schemas" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.4" - datum: "2026-03-09" - aenderung: | - - Kategorie I (Interne Services) unter identitaet.service_kategorie hinzugefügt - - OLA als neuer SLA-Typ unter qualitaet.service_level_referenz ergänzt - - Validierungsregeln VAL-006 (Kategorie I ↔ OLA) und VAL-007 (Kategorie I nicht im Katalog) hinzugefügt - - Hinweis: OLA-Feld bleibt in Pilotphase leer (Begründung in Pilot-Scope-Doku) - autor: "DIGITOM-Projekt" - kontext: "Bestätigung Designentscheidungen DC-001 bis DC-003 (PENDING-SPM-001)" - referenz: "GOV-SPM-I-001, GOV-SPM-I-002, GOV-SPM-I-003" - - - version: "1.3" - datum: "2026-01-31" - aenderung: | - - Neuer Abschnitt 'service_review' hinzugefügt (aus Service-Steckbrief verschoben) - - Neuer Abschnitt 'laufende_verbesserungen' hinzugefügt (aus Service-Steckbrief verschoben) - - Mapping aktualisiert: service_review und laufende_verbesserungen explizit als - 'nicht übernommen' markiert - - Begründung: Review- und Improvement-Informationen sind interne Steuerungsdaten - und gehören in die Service-Definition (Single Source of Truth), nicht in den - kundenorientierten Service-Steckbrief. - autor: "DIGITOM-Projekt" - kontext: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht" - referenz: "GOV-SR-001, GOV-SR-002, GOV-SR-005" - - - version: "1.2" - datum: "2026-01-28" - aenderung: | - - Neuer Abschnitt 'geschaeftskritikalitaet' hinzugefügt - - Attribute: kritikalitaetsstufe, rto_stunden, betroffene_kernprozesse, kritikalitaet_begruendung - - Validierungsregel VAL-005 (RTO-Konsistenz) - - Mapping: Kritikalität wird nicht in Service-Steckbrief übernommen - autor: "DIGITOM-Projekt" - kontext: "SSM-Anforderung: Grundlage für Incident-Impact-Bewertung" - referenz: "ITIL4 Business Impact Analysis (BIA)" - - - version: "1.1" - datum: "2025-12-17" - aenderung: | - - Neuer Abschnitt 'lifecycle' mit lifecycle_status hinzugefügt (GOV-TR-022) - - Hinweis bei metadata.status zur Abgrenzung von lifecycle_status - - Mapping-Regeln zwischen Dokumenten-Status und Lifecycle-Status - autor: "DIGITOM-Projekt" - referenz: "AP-06 Begriffliche Harmonisierung" - - - version: "1.0" - datum: "2025-11-27" - aenderung: "Initiale Version des Schemas" +# ============================================================================= +# SCHEMA: SERVICE-DEFINITION +# ============================================================================= +# +# Dieses Schema definiert die Struktur einer Service-Definition. +# Die Service-Definition ist das interne Master-Dokument, das alle +# relevanten Informationen zu einem Service enthält (Single Source of Truth). +# +# Abgrenzung: +# - Service-Definition = internes Master-Dokument (dieses Schema) +# - Service-Steckbrief = kundenorientierter Auszug (separates Schema) +# +# ============================================================================= + +schema: + name: "Service-Definition" + version: "0.1" + status: "draft" + erstellt: "2025-11-27" + projekt: "DIGITOM" + + beschreibung: > + Die Service-Definition ist das zentrale Artefakt des Service Catalog + Management. Sie enthält alle Informationen, die DIGIT intern über + einen Service wissen muss – von der fachlichen Beschreibung über + Qualitätsparameter bis hin zu Betriebsmodell und Governance. + + verantwortung: + erstellung: "Service Owner (A/R)" + validierung: "Service-Portfolio-Manager (A/R)" + freigabe: "SOR oder Mission Board (je nach Kategorie)" + + referenzen: + glossar: "service-portfolio-management_glossar.yaml" + practice: "spm_practice_service-catalog-management.yaml" + abgeleitetes_artefakt: "spm_schema_service-steckbrief.yaml" + +# ============================================================================= +# ATTRIBUT-DEFINITIONEN +# ============================================================================= + +attribute: + + # --------------------------------------------------------------------------- + # METADATEN + # --------------------------------------------------------------------------- + metadaten: + beschreibung: "Verwaltungsinformationen zur Service-Definition selbst" + + attribute: + - name: "service_id" + typ: "string" + pflicht: true + beschreibung: "Eindeutiger Identifier des Services (z.B. SVC-001)" + beispiel: "SVC-042" + + - name: "version" + typ: "string" + pflicht: true + beschreibung: "Versionsnummer der Service-Definition" + format: "semver (major.minor)" + beispiel: "1.2" + + - name: "status" + typ: "enum" + pflicht: true + beschreibung: | + Dokumenten-Status der Service-Definition. Beschreibt die Gültigkeit + des Dokuments, NICHT die Lifecycle-Phase des Services. + Siehe Abschnitt 'lifecycle' für den Lifecycle-Status. + werte: + - "entwurf" # In Erstellung + - "freigegeben" # Aktiv und gültig + - "archiviert" # Historisch, nicht mehr gültig + hinweis: "Nicht zu verwechseln mit lifecycle_status (GOV-TR-019)" + + - name: "erstellt_am" + typ: "date" + pflicht: true + beschreibung: "Datum der Ersterstellung" + + - name: "geaendert_am" + typ: "date" + pflicht: true + beschreibung: "Datum der letzten Änderung" + + - name: "freigegeben_am" + typ: "date" + pflicht: false + beschreibung: "Datum der letzten Freigabe" + bedingung: "Pflicht wenn status = 'freigegeben'" + + - name: "freigegeben_durch" + typ: "string" + pflicht: false + beschreibung: "Gremium oder Rolle, die die Freigabe erteilt hat" + beispiel: "SOR" + bedingung: "Pflicht wenn status = 'freigegeben'" + + # --------------------------------------------------------------------------- + # LIFECYCLE-STATUS + # --------------------------------------------------------------------------- + lifecycle: + beschreibung: | + Der Lifecycle-Status beschreibt die aktuelle Phase des Services im + Service-Lifecycle. Er ist unabhängig vom Dokumenten-Status der + Service-Definition (Attribut 'status' in metadata). + + governance_referenz: "GOV-TR-019" + + attribute: + - name: "lifecycle_status" + typ: "enum" + pflicht: true + beschreibung: "Aktuelle Phase des Services im Lifecycle" + werte: + - id: "in_entwicklung" + beschreibung: "Service befindet sich in der Entwicklungsphase (Projekt läuft)" + gate_voraussetzung: null + nachfolger: ["in_transition", "abgebrochen"] + + - id: "in_transition" + beschreibung: "Service hat Gate 1 passiert, befindet sich in Transition" + gate_voraussetzung: "Gate 1 (Entry Transition)" + nachfolger: ["aktiv", "in_entwicklung"] + + - id: "aktiv" + beschreibung: "Service ist live und für Nutzer verfügbar" + gate_voraussetzung: "Gate 2 (Go-Live-Freigabe)" + nachfolger: ["in_stilllegung"] + + - id: "in_stilllegung" + beschreibung: "Stilllegung eingeleitet, Service noch verfügbar mit Einschränkungen" + gate_voraussetzung: "SOR-Stilllegungsbeschluss" + nachfolger: ["stillgelegt"] + + - id: "stillgelegt" + beschreibung: "Service ist deaktiviert und aus dem Katalog entfernt" + gate_voraussetzung: "Stilllegung abgeschlossen" + nachfolger: [] + + - id: "abgebrochen" + beschreibung: "Service wurde vor Go-Live abgebrochen (Projektabbruch)" + gate_voraussetzung: "Projektabbruch-Entscheidung" + nachfolger: [] + + - name: "lifecycle_status_seit" + typ: "date" + pflicht: true + beschreibung: "Datum des letzten Status-Übergangs" + + - name: "lifecycle_status_durch" + typ: "string" + pflicht: false + beschreibung: "Entscheidungsinstanz des letzten Übergangs (z.B. 'SO', 'SOR')" + + mapping_zu_dokument_status: + beschreibung: | + Der Dokumenten-Status (metadata.status) und der Lifecycle-Status sind + unabhängig, aber es gibt typische Korrelationen. + + regeln: + - lifecycle: "in_entwicklung" + dokument_status_typisch: "entwurf" + dokument_status_erlaubt: ["entwurf"] + + - lifecycle: "in_transition" + dokument_status_typisch: "entwurf" + dokument_status_erlaubt: ["entwurf", "freigegeben"] + + - lifecycle: "aktiv" + dokument_status_erforderlich: "freigegeben" + dokument_status_erlaubt: ["freigegeben"] + + - lifecycle: "in_stilllegung" + dokument_status_typisch: "freigegeben" + dokument_status_erlaubt: ["freigegeben"] + + - lifecycle: "stillgelegt" + dokument_status_typisch: "archiviert" + dokument_status_erlaubt: ["freigegeben", "archiviert"] + + - lifecycle: "abgebrochen" + dokument_status_typisch: "archiviert" + dokument_status_erlaubt: ["entwurf", "archiviert"] + + # --------------------------------------------------------------------------- + # IDENTITÄT & ZWECK + # --------------------------------------------------------------------------- + identitaet: + beschreibung: "Grundlegende Identifikation und Zweckbestimmung des Services" + + attribute: + - name: "service_name" + typ: "string" + pflicht: true + beschreibung: "Offizieller Name des Services" + beispiel: "Digitaler Arbeitsplatz" + + - name: "service_name_kurz" + typ: "string" + pflicht: false + beschreibung: "Kurzbezeichnung oder Akronym" + beispiel: "DAP" + + - name: "kurzbeschreibung" + typ: "string" + pflicht: true + beschreibung: "Einzeilige Beschreibung des Services (max. 200 Zeichen)" + max_laenge: 200 + + - name: "zweck" + typ: "text" + pflicht: true + beschreibung: > + Warum existiert dieser Service? Welches Problem löst er? + Welchen Nutzen stiftet er für die Verwaltung? + glossar_referenz: "Nutzen (Utility)" + + - name: "zielgruppe" + typ: "list[string]" + pflicht: true + beschreibung: "Für wen ist der Service bestimmt?" + beispiel: + - "Alle Mitarbeitenden der Stadtverwaltung" + - "Amtsleitungen" + - "Amt für Soziales (exklusiv)" + + - name: "service_kategorie" + typ: "enum" + pflicht: true + beschreibung: "Strategische Kategorie gemäß Portfolio-Stratifikation" + werte: + - id: "A" + name: "Basis-Services" + beschreibung: "Flächendeckend, umlagefinanziert, nicht abwählbar" + - id: "B" + name: "Erweiterte Services" + beschreibung: "Optional, bedarfsgesteuert, clusterspezifisch" + - id: "C" + name: "Spezial-Services" + beschreibung: "Individuell, hochgradig domänenspezifisch" + - id: "I" + name: "Interne Services" + beschreibung: "Interne Governance-Objekte, nicht im Katalog sichtbar" + sichtbarkeit: "per Definition nicht im Service-Katalog" + referenz: "P-02 Service Level Management, Kernkonzepte" + governance_referenz: "GOV-SPM-I-001" + + # --------------------------------------------------------------------------- + # LEISTUNGSUMFANG (UTILITY) + # --------------------------------------------------------------------------- + leistungsumfang: + beschreibung: "Was der Service leistet und was nicht" + glossar_referenz: "Nutzen (Utility)" + + attribute: + - name: "leistungen_inkludiert" + typ: "list[string]" + pflicht: true + beschreibung: "Konkrete Leistungen, die der Service umfasst" + beispiel: + - "Bereitstellung eines Windows-Arbeitsplatzes" + - "Standard-Office-Anwendungen" + - "E-Mail-Postfach (5 GB)" + + - name: "leistungen_exkludiert" + typ: "list[string]" + pflicht: true + beschreibung: "Explizit nicht enthaltene Leistungen (Abgrenzung)" + beispiel: + - "Spezialsoftware (siehe Erweiterte Services)" + - "Mobile Endgeräte (separater Service)" + + - name: "service_komponenten" + typ: "list[objekt]" + pflicht: false + beschreibung: "Technische oder fachliche Bestandteile des Services" + schema: + - name: "komponente_name" + typ: "string" + - name: "komponente_beschreibung" + typ: "string" + - name: "komponente_typ" + typ: "enum" + werte: ["hardware", "software", "plattform", "prozess", "sonstiges"] + + - name: "voraussetzungen" + typ: "list[string]" + pflicht: false + beschreibung: "Was muss gegeben sein, damit der Service genutzt werden kann?" + beispiel: + - "Gültiger Benutzeraccount im Active Directory" + - "Abgeschlossene Datenschutzunterweisung" + + # --------------------------------------------------------------------------- + # QUALITÄT & SERVICE LEVELS (WARRANTY) + # --------------------------------------------------------------------------- + qualitaet: + beschreibung: "Qualitätszusagen und Service Levels" + glossar_referenz: "Service Level, Gewährleistung (Warranty)" + + attribute: + - name: "service_level_referenz" + typ: "objekt" + pflicht: true + beschreibung: > + Verweis auf die geltenden Service Levels. + Die Struktur unterscheidet sich je nach Service-Kategorie. + schema: + - name: "typ" + typ: "enum" + werte: + - id: "SLS" + beschreibung: "Separates SLS-Dokument (Kategorie A, B)" + - id: "SLA_integriert" + beschreibung: "Service Levels im bilateralen SLA (Kategorie C)" + - id: "OLA" + beschreibung: "Operational Level Agreement (für Kategorie I – Interne Services)" + hinweis: "OLA-Feld bleibt in Pilotphase leer (keine Placeholder-Werte). Begründung siehe Pilot-Scope-Dokumentation." + governance_referenz: "GOV-SPM-I-002" + - name: "dokument_id" + typ: "string" + beschreibung: "Referenz auf SLS oder SLA" + - name: "hinweis" + typ: "string" + pflicht: false + beschreibung: "Zusätzliche Erläuterung, z.B. 'SLS siehe Abschnitt 4 des SLA'" + + - name: "verfuegbarkeit" + typ: "objekt" + pflicht: true + beschreibung: "Wann ist der Service verfügbar?" + schema: + - name: "servicezeit" + typ: "string" + beschreibung: "Reguläre Betriebszeit" + beispiel: "Mo-Fr 06:00-22:00, Sa 08:00-14:00" + - name: "supportzeit" + typ: "string" + beschreibung: "Zeiten mit aktivem Support" + beispiel: "Mo-Fr 08:00-17:00" + - name: "wartungsfenster" + typ: "string" + beschreibung: "Geplante Wartungszeiten" + beispiel: "So 02:00-06:00" + + - name: "sla_governance" + typ: "objekt" + pflicht: true + beschreibung: "Governance-Struktur für Service Level Agreements" + schema: + - name: "sla_partner" + typ: "string" + beschreibung: "Wer ist der SLA-Partner auf Kundenseite?" + beispiel_kategorie_a: "Kundenvertretung Basisservices" + beispiel_kategorie_b: "Kundenvertretung [Servicename]" + beispiel_kategorie_c: "Amtsleitung [Amt]" + - name: "review_zyklus" + typ: "string" + beschreibung: "Wie oft wird das SLA reviewed?" + beispiel: "jährlich" + referenz: "P-02 Service Level Management, GOV-001 bis GOV-005" + + # --------------------------------------------------------------------------- + # VERANTWORTLICHKEITEN + # --------------------------------------------------------------------------- + verantwortlichkeiten: + beschreibung: "Rollen und Zuständigkeiten für den Service" + + attribute: + - name: "service_owner" + typ: "objekt" + pflicht: true + beschreibung: "Fachlich Gesamtverantwortlicher für den Service" + glossar_referenz: "Service-Owner:in" + schema: + - name: "rolle_id" + typ: "string" + beschreibung: "Referenz auf Rollendefinition" + wert: "service_owner" + - name: "person_name" + typ: "string" + beschreibung: "Aktuelle:r Rolleninhaber:in" + - name: "person_kontakt" + typ: "string" + beschreibung: "E-Mail oder Telefon" + - name: "stellvertretung" + typ: "string" + pflicht: false + + - name: "weitere_rollen" + typ: "list[objekt]" + pflicht: false + beschreibung: "Weitere relevante Rollen für diesen Service" + schema: + - name: "rolle_id" + typ: "string" + beschreibung: "Referenz auf spm_rollen.yaml" + - name: "person_name" + typ: "string" + - name: "kontext" + typ: "string" + beschreibung: "Spezifische Verantwortung im Service-Kontext" + + # --------------------------------------------------------------------------- + # ABHÄNGIGKEITEN + # --------------------------------------------------------------------------- + abhaengigkeiten: + beschreibung: > + Beziehungen zu anderen Services, Systemen und externen Partnern. + Hinweis: Im MVP wird keine CMDB-Integration vorausgesetzt. + Abhängigkeiten werden manuell gepflegt. + + attribute: + - name: "abhaengig_von" + typ: "list[objekt]" + pflicht: false + beschreibung: "Services oder Systeme, von denen dieser Service abhängt" + schema: + - name: "service_id" + typ: "string" + beschreibung: "ID des abhängigen Services (falls DIGIT-intern)" + - name: "name" + typ: "string" + beschreibung: "Name des abhängigen Services/Systems" + - name: "typ" + typ: "enum" + werte: ["intern", "extern", "infrastruktur"] + - name: "kritikalitaet" + typ: "enum" + werte: ["kritisch", "wichtig", "optional"] + beschreibung: "Auswirkung bei Ausfall der Abhängigkeit" + + - name: "genutzt_von" + typ: "list[objekt]" + pflicht: false + beschreibung: "Services, die diesen Service nutzen" + schema: + - name: "service_id" + typ: "string" + - name: "name" + typ: "string" + + - name: "externe_lieferanten" + typ: "list[objekt]" + pflicht: false + beschreibung: "Externe Anbieter, die zur Service-Erbringung beitragen" + schema: + - name: "lieferant_name" + typ: "string" + - name: "leistung" + typ: "string" + - name: "vertrag_referenz" + typ: "string" + pflicht: false + + hinweis_cmdb: > + Placeholder für zukünftige CMDB-Integration. Im MVP werden + Abhängigkeiten manuell in der Service-Definition gepflegt. + Langfristig sollte eine bidirektionale Synchronisation mit + der CMDB erfolgen (Service Configuration Management Practice). + + # --------------------------------------------------------------------------- + # BETRIEBSMODELL + # --------------------------------------------------------------------------- + betriebsmodell: + beschreibung: "Wie wird der Service operativ erbracht?" + + attribute: + - name: "betriebsverantwortung" + typ: "enum" + pflicht: true + beschreibung: "Wer betreibt den Service operativ?" + werte: + - id: "intern" + beschreibung: "Vollständig durch DIGIT" + - id: "hybrid" + beschreibung: "DIGIT + externe Partner" + - id: "extern_gesteuert" + beschreibung: "Externer Betrieb, DIGIT steuert" + + - name: "betriebsteam" + typ: "string" + pflicht: true + beschreibung: "Zuständiges Team/Gruppe innerhalb DIGIT" + beispiel: "Team Infrastruktur, Gruppe Netzwerk" + + - name: "support_modell" + typ: "objekt" + pflicht: true + beschreibung: "Wie ist der Support organisiert?" + schema: + - name: "first_level" + typ: "string" + beschreibung: "Wer nimmt Anfragen entgegen?" + beispiel: "Service Desk DIGIT" + - name: "second_level" + typ: "string" + beschreibung: "Wer bearbeitet komplexere Anfragen?" + - name: "third_level" + typ: "string" + pflicht: false + beschreibung: "Spezialistenebene (falls vorhanden)" + + - name: "request_wege" + typ: "list[string]" + pflicht: true + beschreibung: "Wie kann der Service angefragt/beauftragt werden?" + beispiel: + - "Self-Service-Portal" + - "Service Desk Ticket" + - "E-Mail an servicedesk@digit.freiburg.de" + + - name: "monitoring" + typ: "objekt" + pflicht: false + beschreibung: "Wie wird der Service überwacht?" + schema: + - name: "monitoring_aktiv" + typ: "boolean" + - name: "metriken" + typ: "list[string]" + beschreibung: "Welche KPIs werden überwacht?" + - name: "alerting" + typ: "string" + beschreibung: "Wie werden Störungen erkannt und eskaliert?" + + # --------------------------------------------------------------------------- + # KOSTEN & RESSOURCEN + # --------------------------------------------------------------------------- + kosten: + beschreibung: "Wirtschaftliche Aspekte des Services" + + attribute: + - name: "kostenmodell" + typ: "enum" + pflicht: true + beschreibung: "Wie werden die Kosten verrechnet?" + werte: + - id: "umlage" + beschreibung: "Zentral finanziert, keine Einzelverrechnung (typisch Kat. A)" + - id: "nutzungsbasiert" + beschreibung: "Verrechnung nach Nutzung/Anzahl" + - id: "pauschal" + beschreibung: "Fixe Pauschale je Nutzer/Amt" + - id: "projekt" + beschreibung: "Projektfinanziert (typisch Kat. C)" + + - name: "kostentreiber" + typ: "list[string]" + pflicht: false + beschreibung: "Hauptfaktoren, die die Kosten beeinflussen" + beispiel: + - "Anzahl Arbeitsplätze" + - "Speichervolumen" + - "Lizenzkosten Hersteller" + + - name: "budget_referenz" + typ: "string" + pflicht: false + beschreibung: "Verweis auf Budgetposition/Kostenstelle" + + # --------------------------------------------------------------------------- + # COMPLIANCE & SICHERHEIT + # --------------------------------------------------------------------------- + compliance: + beschreibung: "Regulatorische und sicherheitsrelevante Aspekte" + + attribute: + - name: "datenschutz_klassifikation" + typ: "enum" + pflicht: true + beschreibung: "Datenschutzrelevanz des Services" + werte: + - "keine_pbD" # Keine personenbezogenen Daten + - "pbD_normal" # Personenbezogene Daten, normaler Schutzbedarf + - "pbD_hoch" # Personenbezogene Daten, hoher Schutzbedarf + - "besondere_kategorien" # Art. 9 DSGVO + + - name: "rechtsgrundlagen" + typ: "list[string]" + pflicht: false + beschreibung: "Relevante Rechtsgrundlagen für den Service" + beispiel: + - "DSGVO" + - "LDSG BW" + - "E-Government-Gesetz BW" + + - name: "schutzbedarf" + typ: "objekt" + pflicht: false + beschreibung: "IT-Sicherheits-Schutzbedarf nach BSI" + schema: + - name: "vertraulichkeit" + typ: "enum" + werte: ["normal", "hoch", "sehr_hoch"] + - name: "integritaet" + typ: "enum" + werte: ["normal", "hoch", "sehr_hoch"] + - name: "verfuegbarkeit" + typ: "enum" + werte: ["normal", "hoch", "sehr_hoch"] + + - name: "sicherheitsmassnahmen" + typ: "list[string]" + pflicht: false + beschreibung: "Wesentliche technische/organisatorische Maßnahmen" + + # --------------------------------------------------------------------------- + # GESCHÄFTSKRITIKALITÄT + # --------------------------------------------------------------------------- + geschaeftskritikalitaet: + beschreibung: > + Bewertung der Bedeutung des Services für den Geschäftsbetrieb, + basierend auf einer vereinfachten Business Impact Analysis (BIA). + Dient als Grundlage für die Impact-Bewertung im Incident Management + und für Wartungsfenster-Restriktionen im Change Enablement. + + itil4_referenz: "Business Impact Analysis (BIA), Vital Business Functions (VBF)" + + verantwortung: + bewertung: "Service Owner (R)" + entscheidung: "SOR (A)" + + attribute: + - name: "kritikalitaetsstufe" + typ: "enum" + pflicht: true + beschreibung: "Einstufung der Geschäftskritikalität des Services" + werte: + - id: "geschaeftskritisch" + beschreibung: > + Ausfall führt unmittelbar zu Handlungsunfähigkeit wesentlicher + Verwaltungsbereiche. Kein oder nur sehr eingeschränkter + Workaround verfügbar. + rto_indikator: "< 4 Stunden" + impact_mapping: "Störung → automatisch Impact HOCH" + beispiele: + - "Netzwerk-Backbone" + - "Zentrales Identitätsmanagement (Active Directory)" + - "SAP-Kernsystem" + - "Telefonanlage Bürgerservice" + + - id: "wichtig" + beschreibung: > + Ausfall beeinträchtigt Arbeitsfähigkeit erheblich. + Workarounds möglich, aber aufwändig oder nur temporär tragbar. + rto_indikator: "4–24 Stunden" + impact_mapping: "Störung → standardmäßig Impact NORMAL, Hochstufung bei >10 Betroffenen" + beispiele: + - "E-Mail-System" + - "Standard-Arbeitsplatz" + - "Dokumentenmanagementsystem" + - "Fachverfahren mit Tagesgeschäft-Relevanz" + + - id: "unterstuetzend" + beschreibung: > + Ausfall verursacht Komforteinbußen. Kernarbeit bleibt möglich, + einfache Workarounds verfügbar. + rto_indikator: "> 24 Stunden" + impact_mapping: "Störung → standardmäßig Impact NIEDRIG" + beispiele: + - "Raumbuchungssystem" + - "Intranet-Redaktionssystem" + - "Nicht-kritische Reporting-Tools" + + - name: "rto_stunden" + typ: "number" + pflicht: false + beschreibung: > + Recovery Time Objective – maximale tolerierbare Ausfallzeit + in Stunden, bevor der Geschäftsbetrieb schwerwiegend + beeinträchtigt wird. + empfehlung: "Sollte für Services der Kategorie A und B angegeben werden" + validierung: "Muss konsistent mit kritikalitaetsstufe sein (siehe VAL-005)" + + - name: "betroffene_kernprozesse" + typ: "list[string]" + pflicht: false + beschreibung: > + Verwaltungsprozesse, die durch den Service unterstützt werden. + Dient der Nachvollziehbarkeit der Kritikalitätsbewertung. + hinweis: > + Freitext-Eingabe. Perspektivisch Referenz auf zentralen + Prozesskatalog der Stadtverwaltung (sofern verfügbar). + beispiel: + - "Bürgerservice / Antragsbearbeitung" + - "Personalwesen / Gehaltsabrechnung" + - "Haushaltswesen / Zahlungsverkehr" + + - name: "kritikalitaet_begruendung" + typ: "text" + pflicht: true + beschreibung: > + Nachvollziehbare Begründung der Kritikalitätseinstufung. + Muss erklären, warum der Service die gewählte Stufe hat + und welche Auswirkungen ein Ausfall konkret hätte. + beispiel: > + "Der Service unterstützt die zentrale Authentifizierung aller + Mitarbeitenden. Bei Ausfall können sich Nutzer nicht anmelden, + was sämtliche IT-gestützten Arbeitsprozesse blockiert. + Kein Workaround verfügbar." + + # --------------------------------------------------------------------------- + # SERVICE-REVIEW-STATUS + # --------------------------------------------------------------------------- + service_review: + beschreibung: | + Aktueller Stand des quartalsweisen Service-Reviews (GOV-SR-001, GOV-SR-002). + Diese Informationen sind interne Steuerungsdaten und werden NICHT im + kundenorientierten Service-Steckbrief publiziert. + + governance_referenz: "GOV-SR-001, GOV-SR-002, GOV-SR-005" + referenz: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml" + + attribute: + - name: "letzter_review_datum" + typ: "date" + pflicht: false + beschreibung: "Datum des letzten abgeschlossenen Quartals-Reviews" + quelle: "Service Owner nach Review-Durchführung" + format: "YYYY-MM-DD" + + - name: "review_ergebnis" + typ: "objekt" + pflicht: false + beschreibung: "Ergebnis des letzten Reviews nach 4-Dimensionen-Modell" + quelle: "Service Owner" + referenz: "konzept_service-review.yaml -> bewertungsschema" + schema: + - name: "d1_leistungserbringung" + typ: "enum" + werte: ["gruen", "gelb", "rot"] + beschreibung: "Bewertung Dimension 1: Liefert der Service den erwarteten Nutzen?" + - name: "d2_betriebsstabilitaet" + typ: "enum" + werte: ["gruen", "gelb", "rot"] + beschreibung: "Bewertung Dimension 2: Laeuft der Service stoerungsarm?" + - name: "d3_nutzerzufriedenheit" + typ: "enum" + werte: ["gruen", "gelb", "rot"] + beschreibung: "Bewertung Dimension 3: Wie bewerten die Nutzer den Service?" + - name: "d4_zukunftsfaehigkeit" + typ: "enum" + werte: ["gruen", "gelb", "rot"] + beschreibung: "Bewertung Dimension 4: Ist der Service mittelfristig tragfaehig?" + - name: "handlungsempfehlung" + typ: "enum" + werte: ["continue", "improvement", "redesign", "retire"] + beschreibung: "Abgeleitete Handlungsempfehlung des SO" + - name: "begruendung" + typ: "text" + pflicht: false + beschreibung: "Kurzbegruendung bei Abweichung von typischer Konstellation" + + - name: "naechster_review_faellig" + typ: "date" + pflicht: false + beschreibung: "Faelligkeitsdatum des naechsten Quartals-Reviews" + berechnung: "letzter_review_datum + 3 Monate" + + # --------------------------------------------------------------------------- + # LAUFENDE VERBESSERUNGEN (IMPROVEMENT-TRACKING) + # --------------------------------------------------------------------------- + laufende_verbesserungen: + beschreibung: | + Improvement-Tracking gemaess Service-Review-Konzept (GOV-SR-005). + Diese Informationen sind interne Steuerungsdaten und werden NICHT im + kundenorientierten Service-Steckbrief publiziert. + + governance_referenz: "GOV-SR-005" + referenz: "konzept_service-review.yaml -> improvement_steuerung.mvp_loesung" + + attribute: + - name: "massnahmen" + typ: "list[objekt]" + pflicht: false + beschreibung: "Aktive und abgeschlossene Improvement-Massnahmen" + schema: + - name: "id" + typ: "string" + pflicht: true + format: "IMP-[SERVICE-ID]-[NNN]" + beispiel: "IMP-SVC-042-001" + - name: "beschreibung" + typ: "string" + pflicht: true + max_zeichen: 200 + beschreibung: "Kurzbeschreibung der Massnahme" + - name: "ziel_dimension" + typ: "enum" + pflicht: true + werte: ["SR-D1", "SR-D2", "SR-D3", "SR-D4"] + beschreibung: "Welche Review-Dimension soll verbessert werden?" + - name: "verantwortlich" + typ: "string" + pflicht: true + beschreibung: "Person oder Rolle fuer Umsetzung" + - name: "zieltermin" + typ: "date" + pflicht: true + - name: "status" + typ: "enum" + pflicht: true + werte: ["offen", "in_arbeit", "abgeschlossen", "abgebrochen"] + - name: "wirksamkeit" + typ: "enum" + pflicht: false + werte: ["wirksam", "teilweise_wirksam", "nicht_wirksam", "nicht_bewertet"] + beschreibung: "Bewertung im Folge-Review" + - name: "kommentar" + typ: "text" + pflicht: false + beschreibung: "Ergaenzende Informationen oder Wirksamkeits-Begruendung" + + # --------------------------------------------------------------------------- + # DOKUMENTATION & REFERENZEN + # --------------------------------------------------------------------------- + dokumentation: + beschreibung: "Verweise auf weitere Dokumente und Ressourcen" + + attribute: + - name: "dokumente" + typ: "list[objekt]" + pflicht: false + beschreibung: "Verknüpfte Dokumente" + schema: + - name: "titel" + typ: "string" + - name: "typ" + typ: "enum" + werte: + - "sls" + - "sla" + - "betriebshandbuch" + - "benutzerhandbuch" + - "faq" + - "schulungsunterlage" + - "sonstiges" + - name: "pfad_oder_url" + typ: "string" + - name: "stand" + typ: "date" + + - name: "aenderungshistorie" + typ: "list[objekt]" + pflicht: true + beschreibung: "Änderungsprotokoll der Service-Definition" + schema: + - name: "version" + typ: "string" + - name: "datum" + typ: "date" + - name: "autor" + typ: "string" + - name: "aenderung" + typ: "string" + +# ============================================================================= +# VALIDIERUNGSREGELN +# ============================================================================= + +validierung: + + regeln: + - id: "VAL-001" + beschreibung: "Service-Kategorie muss konsistent mit SLA-Governance sein" + regel: > + Wenn service_kategorie = 'A', dann sla_partner muss + 'Kundenvertretung Basisservices' sein. + + - id: "VAL-002" + beschreibung: "Kategorie C erfordert SLA_integriert" + regel: > + Wenn service_kategorie = 'C', dann service_level_referenz.typ + muss 'SLA_integriert' sein. + + - id: "VAL-003" + beschreibung: "Service Owner muss benannt sein" + regel: > + service_owner.person_name darf nicht leer sein. + + - id: "VAL-004" + beschreibung: "Freigabe erfordert vollständige Pflichtfelder" + regel: > + Vor Statuswechsel auf 'freigegeben' müssen alle Pflichtfelder + ausgefüllt sein. + + - id: "VAL-005" + beschreibung: "RTO-Konsistenz mit Kritikalitätsstufe" + regel: > + Wenn rto_stunden angegeben ist, sollte die kritikalitaetsstufe + konsistent sein: + - rto_stunden < 4 → kritikalitaetsstufe sollte 'geschaeftskritisch' sein + - rto_stunden 4-24 → kritikalitaetsstufe sollte 'wichtig' sein + - rto_stunden > 24 → kritikalitaetsstufe sollte 'unterstuetzend' sein + Abweichungen sind zulässig, erfordern aber eine explizite + Begründung in kritikalitaet_begruendung. + + - id: "VAL-006" + beschreibung: "Kategorie I erfordert OLA als SLA-Typ" + regel: > + Wenn service_kategorie = 'I', dann service_level_referenz.typ + muss 'OLA' sein. Umgekehrt darf 'OLA' nur bei Kategorie I + verwendet werden. + governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-002" + + - id: "VAL-007" + beschreibung: "Kategorie I ist nicht im Katalog" + regel: > + Wenn service_kategorie = 'I', dann darf kein Service-Steckbrief + für den Service-Katalog publiziert werden. Interne Services + werden ausschließlich über die Service-Definition gesteuert. + governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003" + +# ============================================================================= +# MAPPING: SERVICE-DEFINITION → SERVICE-STECKBRIEF +# ============================================================================= + +mapping_steckbrief: + beschreibung: > + Definiert, welche Attribute der Service-Definition in den + Service-Steckbrief (kundenorientierte Sicht) übernommen werden. + + uebernommen: + - service_name + - kurzbeschreibung + - zweck + - zielgruppe + - service_kategorie + - leistungen_inkludiert + - leistungen_exkludiert + - voraussetzungen + - service_level_referenz + - verfuegbarkeit.servicezeit + - verfuegbarkeit.supportzeit + - request_wege + - service_owner.person_name # nur Name, nicht Kontaktdetails + + nicht_uebernommen: + - service_komponenten # zu technisch + - betriebsteam # internes Detail + - support_modell # internes Detail + - monitoring # internes Detail + - kostentreiber # internes Detail + - budget_referenz # internes Detail + - schutzbedarf # internes Detail + - sicherheitsmassnahmen # internes Detail + - aenderungshistorie # internes Detail + - geschaeftskritikalitaet # interne Steuerungsgröße, nicht kundenrelevant + - service_review # interne Steuerungsdaten (Review-Status, Dimensionsbewertung) + - laufende_verbesserungen # interne Steuerungsdaten (Improvement-Tracking) + + transformiert: + - quelle: "compliance.datenschutz_klassifikation" + ziel: "datenschutz_hinweis" + transformation: "Ableitung eines kundenverständlichen Hinweistextes" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + - id: "OPEN-SCHEMA-001" + beschreibung: "CMDB-Integration: Attribut-Mapping definieren" + prioritaet: "niedrig" + status: "Placeholder im MVP" + + - id: "OPEN-SCHEMA-002" + beschreibung: "Template für Service-Definition erstellen (Markdown/Word)" + prioritaet: "mittel" + ziel_ordner: "02.6_arbeitsmaterialien" + + - id: "OPEN-SCHEMA-003" + beschreibung: "Schema Service-Steckbrief ableiten" + prioritaet: "hoch" + abhaengig_von: "Review dieses Schemas" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.4" + datum: "2026-03-09" + aenderung: | + - Kategorie I (Interne Services) unter identitaet.service_kategorie hinzugefügt + - OLA als neuer SLA-Typ unter qualitaet.service_level_referenz ergänzt + - Validierungsregeln VAL-006 (Kategorie I ↔ OLA) und VAL-007 (Kategorie I nicht im Katalog) hinzugefügt + - Hinweis: OLA-Feld bleibt in Pilotphase leer (Begründung in Pilot-Scope-Doku) + autor: "DIGITOM-Projekt" + kontext: "Bestätigung Designentscheidungen DC-001 bis DC-003 (PENDING-SPM-001)" + referenz: "GOV-SPM-I-001, GOV-SPM-I-002, GOV-SPM-I-003" + + - version: "1.3" + datum: "2026-01-31" + aenderung: | + - Neuer Abschnitt 'service_review' hinzugefügt (aus Service-Steckbrief verschoben) + - Neuer Abschnitt 'laufende_verbesserungen' hinzugefügt (aus Service-Steckbrief verschoben) + - Mapping aktualisiert: service_review und laufende_verbesserungen explizit als + 'nicht übernommen' markiert + - Begründung: Review- und Improvement-Informationen sind interne Steuerungsdaten + und gehören in die Service-Definition (Single Source of Truth), nicht in den + kundenorientierten Service-Steckbrief. + autor: "DIGITOM-Projekt" + kontext: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht" + referenz: "GOV-SR-001, GOV-SR-002, GOV-SR-005" + + - version: "1.2" + datum: "2026-01-28" + aenderung: | + - Neuer Abschnitt 'geschaeftskritikalitaet' hinzugefügt + - Attribute: kritikalitaetsstufe, rto_stunden, betroffene_kernprozesse, kritikalitaet_begruendung + - Validierungsregel VAL-005 (RTO-Konsistenz) + - Mapping: Kritikalität wird nicht in Service-Steckbrief übernommen + autor: "DIGITOM-Projekt" + kontext: "SSM-Anforderung: Grundlage für Incident-Impact-Bewertung" + referenz: "ITIL4 Business Impact Analysis (BIA)" + + - version: "1.1" + datum: "2025-12-17" + aenderung: | + - Neuer Abschnitt 'lifecycle' mit lifecycle_status hinzugefügt (GOV-TR-022) + - Hinweis bei metadata.status zur Abgrenzung von lifecycle_status + - Mapping-Regeln zwischen Dokumenten-Status und Lifecycle-Status + autor: "DIGITOM-Projekt" + referenz: "AP-06 Begriffliche Harmonisierung" + + - version: "1.0" + datum: "2025-11-27" + aenderung: "Initiale Version des Schemas" autor: "DIGITOM-Projekt" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml index 48d574b..2bfb1b6 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml @@ -1,657 +1,657 @@ -# ============================================================================= -# SCHEMA: SERVICE-STECKBRIEF -# ============================================================================= -# -# Dieses Schema definiert die Struktur eines Service-Steckbriefs. -# Der Service-Steckbrief ist die kundenorientierte Darstellung eines Services -# im Service-Katalog – ein Auszug aus der Service-Definition. -# -# Abgrenzung: -# - Service-Definition = internes Master-Dokument (spm_schema_service-definition.yaml) -# - Service-Steckbrief = kundenorientierter Auszug (dieses Schema) -# -# Prinzip: -# - Der Steckbrief enthält NUR Informationen, die für Kunden relevant sind -# - Technische Details, interne Prozesse und Kostenstrukturen werden ausgeblendet -# - Die Sprache ist bewusst nicht-technisch und verständlich -# -# ============================================================================= - -schema: - name: "Service-Steckbrief" - version: "0.3" - status: "draft" - erstellt: "2025-11-27" - geaendert: "2026-01-31" - projekt: "DIGITOM" - - beschreibung: > - Der Service-Steckbrief ist die offizielle, kundenorientierte Beschreibung - eines Services im Service-Katalog. Er beantwortet die Fragen, die Ämter - und Mitarbeitende typischerweise haben: Was ist der Service? Was bekomme - ich? Was bekomme ich nicht? Wie gut ist er? Wie beantrage ich ihn? - - ableitung_von: "spm_schema_service-definition.yaml" - - verantwortung: - inhalt: "Service Owner (liefert)" - qualitaetssicherung: "Service-Portfolio-Manager (prüft Konsistenz und Verständlichkeit)" - freigabe: "Service-Portfolio-Manager" - publikation: "Service-Portfolio-Manager" - - zielgruppe: - primaer: "Mitarbeitende der Stadtverwaltung (Nutzer)" - sekundaer: "Amtsleitungen und deren Delegierte (Kunden/Entscheider)" - - publikationsort: - beschreibung: > - Der Service-Steckbrief wird im Service-Katalog publiziert. - Der konkrete Publikationskanal (Intranet, Self-Service-Portal) - ist implementierungsabhängig. - anforderung: "Barrierefreier, durchsuchbarer Zugang für alle Zielgruppen" - -# ============================================================================= -# ATTRIBUT-DEFINITIONEN -# ============================================================================= - -attribute: - - # --------------------------------------------------------------------------- - # IDENTIFIKATION - # --------------------------------------------------------------------------- - identifikation: - beschreibung: "Eindeutige Identifikation und Grundinformationen" - - attribute: - - name: "service_id" - typ: "string" - pflicht: true - beschreibung: "Eindeutiger Identifier (aus Service-Definition übernommen)" - quelle: "service-definition.metadaten.service_id" - sichtbarkeit: "Kann angezeigt werden, primär für Referenzzwecke" - - - name: "service_name" - typ: "string" - pflicht: true - beschreibung: "Offizieller Name des Services" - quelle: "service-definition.identitaet.service_name" - beispiel: "Digitaler Arbeitsplatz" - - - name: "service_name_kurz" - typ: "string" - pflicht: false - beschreibung: "Kurzbezeichnung oder Akronym (falls gebräuchlich)" - quelle: "service-definition.identitaet.service_name_kurz" - beispiel: "DAP" - - - name: "version" - typ: "string" - pflicht: true - beschreibung: "Version des Steckbriefs" - quelle: "service-definition.metadaten.version" - - - name: "stand" - typ: "date" - pflicht: true - beschreibung: "Datum der letzten Aktualisierung" - quelle: "service-definition.metadaten.geaendert_am" - anzeige_format: "TT.MM.JJJJ" - - # --------------------------------------------------------------------------- - # ÜBERBLICK - # --------------------------------------------------------------------------- - ueberblick: - beschreibung: "Schnelle Orientierung: Was ist das? Für wen?" - - attribute: - - name: "kurzbeschreibung" - typ: "string" - pflicht: true - beschreibung: "Einzeilige Beschreibung (max. 200 Zeichen)" - quelle: "service-definition.identitaet.kurzbeschreibung" - hinweis: "Soll auch ohne Kontext verständlich sein" - beispiel: "Standardisierter PC-Arbeitsplatz mit Office-Anwendungen und E-Mail für alle Mitarbeitenden" - - - name: "nutzen" - typ: "text" - pflicht: true - beschreibung: > - Was bringt mir dieser Service? Welches Problem löst er? - Formulierung aus Kundenperspektive, nicht aus IT-Sicht. - quelle: "service-definition.identitaet.zweck" - transformation: "Ggf. Umformulierung in kundenorientierte Sprache" - beispiel: > - Mit dem Digitalen Arbeitsplatz können Sie Ihre täglichen - Büroaufgaben erledigen: E-Mails schreiben, Dokumente erstellen, - an Videokonferenzen teilnehmen und auf zentrale Anwendungen zugreifen. - - - name: "zielgruppe" - typ: "list[string]" - pflicht: true - beschreibung: "Für wen ist dieser Service gedacht?" - quelle: "service-definition.identitaet.zielgruppe" - beispiel: - - "Alle Mitarbeitenden der Stadtverwaltung" - - - name: "service_kategorie" - typ: "objekt" - pflicht: true - beschreibung: "Art des Services (beeinflusst Verfügbarkeit und Beantragung)" - quelle: "service-definition.identitaet.service_kategorie" - schema: - - name: "kategorie_id" - typ: "enum" - werte: ["A", "B", "C"] - - name: "kategorie_bezeichnung" - typ: "string" - beschreibung: "Kundenfreundliche Bezeichnung" - mapping: - A: "Basis-Service (für alle Mitarbeitenden)" - B: "Erweiterungs-Service (optional buchbar)" - C: "Spezial-Service (für bestimmte Ämter)" - - name: "hinweis" - typ: "string" - pflicht: false - beschreibung: "Zusatzinformation zur Kategorie" - beispiel_c: "Dieser Service ist exklusiv für das Amt für Soziales verfügbar." - - # --------------------------------------------------------------------------- - # LEISTUNGSUMFANG - # --------------------------------------------------------------------------- - leistungsumfang: - beschreibung: "Was bekomme ich? Was bekomme ich nicht?" - - attribute: - - name: "das_ist_enthalten" - typ: "list[string]" - pflicht: true - beschreibung: "Konkrete Leistungen, die im Service enthalten sind" - quelle: "service-definition.leistungsumfang.leistungen_inkludiert" - hinweis: "Kundenverständlich formulieren, keine technischen Details" - beispiel: - - "Windows-PC oder Laptop" - - "Microsoft Office (Word, Excel, PowerPoint, Outlook)" - - "E-Mail-Postfach mit 5 GB Speicher" - - "Zugang zum städtischen Netzwerk" - - "Standarddrucker in Ihrem Gebäude" - - - name: "das_ist_nicht_enthalten" - typ: "list[string]" - pflicht: true - beschreibung: "Explizit nicht enthaltene Leistungen" - quelle: "service-definition.leistungsumfang.leistungen_exkludiert" - hinweis: "Vermeidet Missverständnisse und Enttäuschungen" - beispiel: - - "Spezialsoftware (z.B. CAD, Statistik) – siehe Erweiterungs-Services" - - "Diensthandy – siehe Service 'Mobile Endgeräte'" - - "Individuelle Software-Installationen" - - - name: "voraussetzungen" - typ: "list[string]" - pflicht: false - beschreibung: "Was muss gegeben sein, damit ich den Service nutzen kann?" - quelle: "service-definition.leistungsumfang.voraussetzungen" - beispiel: - - "Gültiger Benutzeraccount (wird bei Dienstantritt automatisch erstellt)" - - "Abgeschlossene IT-Sicherheitsunterweisung" - - # --------------------------------------------------------------------------- - # SERVICEQUALITÄT - # --------------------------------------------------------------------------- - servicequalitaet: - beschreibung: "Wie gut ist der Service? Wann ist er verfügbar?" - - attribute: - - name: "verfuegbarkeit" - typ: "objekt" - pflicht: true - beschreibung: "Wann kann ich den Service nutzen?" - quelle: "service-definition.qualitaet.verfuegbarkeit" - schema: - - name: "servicezeit" - typ: "string" - beschreibung: "Wann ist der Service verfügbar?" - beispiel: "Montag bis Freitag, 6:00 bis 22:00 Uhr; Samstag 8:00 bis 14:00 Uhr" - - name: "wartungsfenster" - typ: "string" - beschreibung: "Wann finden geplante Wartungen statt?" - beispiel: "Sonntags zwischen 2:00 und 6:00 Uhr (der Service kann in dieser Zeit eingeschränkt sein)" - - - name: "service_level_dokument" - typ: "objekt" - pflicht: true - beschreibung: > - Verweis auf die detaillierten Qualitätszusagen. - Die Struktur unterscheidet sich je nach Service-Kategorie. - quelle: "service-definition.qualitaet.service_level_referenz" - schema: - - name: "typ" - typ: "enum" - werte: - - id: "SLS" - anzeige: "Service Level Specification" - beschreibung: "Detaillierte Qualitätsbeschreibung für diesen Service" - - id: "SLA_integriert" - anzeige: "Individuelle Vereinbarung" - beschreibung: "Die Qualitätszusagen sind Teil der bilateralen Vereinbarung mit Ihrem Amt" - - name: "dokument_titel" - typ: "string" - beschreibung: "Titel des referenzierten Dokuments" - - name: "dokument_link" - typ: "string" - pflicht: false - beschreibung: "Link zum Dokument (falls öffentlich zugänglich)" - - name: "hinweis" - typ: "string" - pflicht: false - beispiel_c: "Für Details wenden Sie sich an Ihre Amtsleitung oder den Service Owner." - - - name: "qualitaets_highlights" - typ: "list[string]" - pflicht: false - beschreibung: > - Ausgewählte, kundenrelevante Qualitätsmerkmale aus der SLS. - Keine vollständige Liste, sondern die wichtigsten Punkte. - transformation: "Extraktion aus SLS, kundenverständlich formuliert" - beispiel: - - "Verfügbarkeit: 99,5% während der Servicezeiten" - - "Bei Störungen: Reaktion innerhalb von 4 Stunden" - - "Geplante Wartungen werden mindestens 3 Tage vorher angekündigt" - - # --------------------------------------------------------------------------- - # SUPPORT & KONTAKT - # --------------------------------------------------------------------------- - support: - beschreibung: "Wie bekomme ich Hilfe? An wen wende ich mich?" - - attribute: - - name: "supportzeiten" - typ: "string" - pflicht: true - beschreibung: "Wann ist der Support erreichbar?" - quelle: "service-definition.qualitaet.verfuegbarkeit.supportzeit" - beispiel: "Montag bis Freitag, 8:00 bis 17:00 Uhr" - - - name: "kontaktwege" - typ: "list[objekt]" - pflicht: true - beschreibung: "Wie erreiche ich den Support?" - schema: - - name: "kanal" - typ: "string" - beispiele: ["Telefon", "E-Mail", "Self-Service-Portal", "Vor Ort"] - - name: "details" - typ: "string" - beispiele: - - "0761 / 201-XXXX" - - "servicedesk@digit.freiburg.de" - - "https://selfservice.digit.freiburg.de" - - name: "hinweis" - typ: "string" - pflicht: false - beispiel: "Für schnelle Hilfe bei Störungen" - - - name: "service_owner_kontakt" - typ: "objekt" - pflicht: true - beschreibung: "Ansprechperson für grundsätzliche Fragen zum Service" - quelle: "service-definition.verantwortlichkeiten.service_owner" - schema: - - name: "name" - typ: "string" - quelle: "service_owner.person_name" - - name: "rolle" - typ: "string" - wert: "Service Owner" - - name: "kontakt" - typ: "string" - pflicht: false - beschreibung: "E-Mail (nur wenn explizit freigegeben)" - hinweis: > - Im Regelfall sollten Anfragen über den Service Desk laufen. - Der direkte Kontakt zum SO ist für strategische Fragen - und Amtsleitungen gedacht. - - # --------------------------------------------------------------------------- - # BEANTRAGUNG - # --------------------------------------------------------------------------- - beantragung: - beschreibung: "Wie bekomme ich den Service?" - - attribute: - - name: "beantragungswege" - typ: "list[objekt]" - pflicht: true - beschreibung: "Wie kann ich den Service anfordern?" - quelle: "service-definition.betriebsmodell.request_wege" - schema: - - name: "weg" - typ: "string" - beispiele: - - "Self-Service-Portal" - - "Service Desk" - - "Über Ihre Amtsleitung" - - name: "link" - typ: "string" - pflicht: false - - name: "hinweis" - typ: "string" - pflicht: false - beispiel: "Für Basis-Services ist keine Beantragung nötig – Sie erhalten den Service automatisch." - - - name: "berechtigungslogik" - typ: "text" - pflicht: false - beschreibung: "Wer darf den Service beantragen/nutzen?" - transformation: "Ableitung aus service_kategorie und zielgruppe" - beispiele: - kategorie_a: "Alle Mitarbeitenden erhalten diesen Service automatisch bei Dienstantritt." - kategorie_b: "Die Beantragung erfolgt über Ihre Amtsleitung. Es können Kosten für Ihr Amt entstehen." - kategorie_c: "Dieser Service ist nur für berechtigte Ämter verfügbar. Bei Interesse wenden Sie sich an den Service Owner." - - # --------------------------------------------------------------------------- - # DATENSCHUTZ & HINWEISE - # --------------------------------------------------------------------------- - hinweise: - beschreibung: "Wichtige Hinweise für Nutzer" - - attribute: - - name: "datenschutz_hinweis" - typ: "text" - pflicht: true - beschreibung: "Kundenverständlicher Hinweis zum Datenschutz" - quelle: "service-definition.compliance.datenschutz_klassifikation" - transformation: - keine_pbD: "In diesem Service werden keine personenbezogenen Daten verarbeitet." - pbD_normal: "In diesem Service werden personenbezogene Daten verarbeitet. Die Verarbeitung erfolgt gemäß DSGVO und LDSG BW." - pbD_hoch: "In diesem Service werden sensible personenbezogene Daten verarbeitet. Bitte beachten Sie die besonderen Schutzmaßnahmen in der Nutzungsanleitung." - besondere_kategorien: "In diesem Service werden besonders schützenswerte Daten verarbeitet (z.B. Gesundheitsdaten). Die Nutzung erfordert besondere Sorgfalt. Details finden Sie in der Datenschutzdokumentation." - - - name: "wichtige_hinweise" - typ: "list[string]" - pflicht: false - beschreibung: "Sonstige wichtige Hinweise für Nutzer" - beispiel: - - "Bitte melden Sie sich am Ende des Arbeitstages ab, um Sicherheitsrisiken zu vermeiden." - - "Private Nutzung ist nur im Rahmen der IT-Nutzungsrichtlinie gestattet." - - # --------------------------------------------------------------------------- - # WEITERFÜHRENDE INFORMATIONEN - # --------------------------------------------------------------------------- - weiterführend: - beschreibung: "Links zu weiteren Dokumenten und Ressourcen" - - attribute: - - name: "dokumente" - typ: "list[objekt]" - pflicht: false - beschreibung: "Für Kunden relevante Dokumente" - quelle: "service-definition.dokumentation.dokumente (gefiltert)" - filter: "Nur Dokumente mit typ in ['sls', 'benutzerhandbuch', 'faq', 'schulungsunterlage']" - schema: - - name: "titel" - typ: "string" - - name: "typ" - typ: "enum" - werte: - - id: "sls" - anzeige: "Qualitätsbeschreibung" - - id: "benutzerhandbuch" - anzeige: "Benutzerhandbuch" - - id: "faq" - anzeige: "Häufige Fragen" - - id: "schulungsunterlage" - anzeige: "Schulungsmaterial" - - name: "link" - typ: "string" - - - name: "verwandte_services" - typ: "list[objekt]" - pflicht: false - beschreibung: "Services, die für Nutzer dieses Services relevant sein könnten" - schema: - - name: "service_id" - typ: "string" - - name: "service_name" - typ: "string" - - name: "beziehung" - typ: "string" - beispiele: - - "Ergänzend verfügbar" - - "Alternative für spezielle Anforderungen" - - "Wird für diesen Service benötigt" - -# ============================================================================= -# DARSTELLUNGSVARIANTEN (VIEWS) -# ============================================================================= - -views: - beschreibung: > - Der Service-Steckbrief kann in verschiedenen Kontexten unterschiedlich - dargestellt werden. Die Views definieren, welche Attribute in welchem - Kontext angezeigt werden. - - varianten: - - name: "katalog_uebersicht" - beschreibung: "Listenansicht im Service-Katalog" - anzeige: - - service_name - - kurzbeschreibung - - service_kategorie.kategorie_bezeichnung - - zielgruppe (gekürzt) - - - name: "katalog_detail" - beschreibung: "Vollständige Detailansicht eines Services" - anzeige: "Alle Attribute" - - - name: "request_katalog" - beschreibung: "Ansicht im ITSM-Tool für Service-Anfragen" - anzeige: - - service_name - - kurzbeschreibung - - das_ist_enthalten - - das_ist_nicht_enthalten - - beantragungswege - - kontaktwege - hinweis: > - Diese View wird für die Integration mit dem ITSM-Tool benötigt. - Die konkrete Implementierung hängt vom gewählten Tool ab. - - - name: "entscheider_view" - beschreibung: "Ansicht für Amtsleitungen (Steuerungsperspektive)" - anzeige: - - service_name - - kurzbeschreibung - - service_kategorie - - service_level_dokument - - service_owner_kontakt - - berechtigungslogik - zusaetzlich: - - sla_referenz: "Link zum vollständigen SLA (falls vorhanden)" - -# ============================================================================= -# VALIDIERUNGSREGELN -# ============================================================================= - -validierung: - - regeln: - - id: "VAL-STB-001" - beschreibung: "Kurzbeschreibung muss ohne Kontext verständlich sein" - typ: "qualitativ" - pruefung: "Review durch SHM oder SPM" - - - id: "VAL-STB-002" - beschreibung: "Keine technischen Fachbegriffe ohne Erklärung" - typ: "qualitativ" - pruefung: "Review durch SHM" - - - id: "VAL-STB-003" - beschreibung: "Mindestens ein Kontaktweg muss angegeben sein" - typ: "formal" - regel: "kontaktwege.length >= 1" - - - id: "VAL-STB-004" - beschreibung: "Bei Kategorie B/C muss Berechtigungslogik ausgefüllt sein" - typ: "formal" - regel: > - Wenn service_kategorie in ['B', 'C'], - dann berechtigungslogik darf nicht leer sein. - - - id: "VAL-STB-005" - beschreibung: "Service-Level-Dokument muss referenziert sein" - typ: "formal" - regel: "service_level_dokument.typ ist gesetzt" - - qualitaetskriterien: - beschreibung: > - Qualitative Kriterien, die vor Publikation geprüft werden sollten. - Verantwortung: SPM in Abstimmung mit SHM. - - kriterien: - - "Verständlichkeit: Ein fachfremder Mitarbeitender versteht den Steckbrief" - - "Vollständigkeit: Alle Pflichtfelder sind ausgefüllt" - - "Konsistenz: Informationen widersprechen nicht der Service-Definition" - - "Aktualität: Informationen entsprechen dem aktuellen Stand" - - "Barrierefreiheit: Texte sind in einfacher Sprache verfasst" - -# ============================================================================= -# PFLEGEPROZESS -# ============================================================================= - -pflege: - - trigger: - beschreibung: "Wann muss der Steckbrief aktualisiert werden?" - ereignisse: - - trigger: "Änderung der Service-Definition" - aktion: "Prüfen, ob Steckbrief betroffen" - verantwortung: "Service Owner" - - - trigger: "SLS/SLA-Änderung" - aktion: "Qualitäts-Highlights und Referenzen aktualisieren" - verantwortung: "Service Owner" - - - trigger: "Änderung Kontaktdaten" - aktion: "Support-Abschnitt aktualisieren" - verantwortung: "Service Owner" - - - trigger: "Jährlicher Katalog-Review" - aktion: "Vollständige Prüfung aller Steckbriefe" - verantwortung: "SPM" - - aenderungstypen: - beschreibung: "Klassifikation von Änderungen für Governance-Routing" - - typen: - - typ: "redaktionell" - beispiele: - - "Korrektur Tippfehler" - - "Aktualisierung Telefonnummer" - - "Umformulierung ohne inhaltliche Änderung" - entscheidung: "Service Owner (autonom)" - publikation: "sofort" - - - typ: "inhaltlich_minor" - beispiele: - - "Ergänzung FAQ-Link" - - "Klarstellung Leistungsumfang (ohne Änderung)" - - "Hinzufügen verwandter Service" - entscheidung: "Service Owner + SPM (bilateral)" - publikation: "nach Freigabe SPM" - - - typ: "inhaltlich_major" - beispiele: - - "Änderung Leistungsumfang" - - "Neue/geänderte Service Levels" - - "Änderung Zielgruppe" - entscheidung: "SOR" - publikation: "nach SOR-Freigabe" - hinweis: "Meist gekoppelt an Änderung der Service-Definition" - -# ============================================================================= -# SCHNITTSTELLE ZU ITSM-TOOL -# ============================================================================= - -itsm_integration: - beschreibung: > - Der Service-Steckbrief dient als Stammdatenquelle für den Request-Katalog - im ITSM-Tool. Diese Sektion definiert die Anforderungen an die Integration. - - status: "Anforderungsdefinition (Tool noch nicht final)" - - anforderungen: - - id: "ITSM-REQ-001" - beschreibung: "Service-ID muss als eindeutiger Schlüssel dienen" - - - id: "ITSM-REQ-002" - beschreibung: "Beantragungswege müssen in Request-Formulare überführbar sein" - - - id: "ITSM-REQ-003" - beschreibung: "Änderungen am Steckbrief müssen in das ITSM-Tool synchronisiert werden" - hinweis: "Richtung: SCM → ITSM (unidirektional)" - - - id: "ITSM-REQ-004" - beschreibung: "Kategorie-basierte Sichtbarkeitssteuerung muss möglich sein" - detail: > - Kategorie A: Für alle sichtbar - Kategorie B: Für alle sichtbar, Beantragung eingeschränkt - Kategorie C: Nur für berechtigte Ämter sichtbar - - datenhoheit: "SCM (Service-Steckbrief ist führend)" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - id: "OPEN-STB-001" - beschreibung: "Template für Service-Steckbrief erstellen (Markdown/HTML)" - prioritaet: "hoch" - ziel_ordner: "02.6_arbeitsmaterialien" - - - id: "OPEN-STB-002" - beschreibung: "Abstimmung mit SHM: Qualitätskriterien für Verständlichkeit" - prioritaet: "mittel" - abhaengig_von: "Finalisierung SHM-Rollenbeschreibung" - - - id: "OPEN-STB-003" - beschreibung: "ITSM-Tool-Auswahl: Konkrete Mapping-Spezifikation" - prioritaet: "niedrig" - status: "Wartet auf Tool-Entscheidung" - - - id: "OPEN-STB-004" - beschreibung: "Barrierefreiheit: Prüfung gegen BITV 2.0" - prioritaet: "mittel" - hinweis: "Relevant für Publikationsformat" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-11-27" - aenderung: "Initiale Version erstellt" - autor: "DIGITOM-Projekt" - - - version: "0.2" - datum: "2025-12-17" - aenderung: | - - Neuer Abschnitt 'review_status' fuer Service-Review-Ergebnisse (GOV-SR-001) - - Neuer Abschnitt 'laufende_verbesserungen' fuer Improvement-Tracking (GOV-SR-005) - - Neuer Pflege-Trigger fuer quartalsweisen Service-Review - autor: "DIGITOM-Projekt" - referenz: "konzept_service-review.yaml" - - - version: "0.3" - datum: "2026-01-31" - aenderung: | - - Abschnitt 'review_status' entfernt (verschoben nach Service-Definition) - - Abschnitt 'laufende_verbesserungen' entfernt (verschoben nach Service-Definition) - - Pflege-Trigger fuer quartalsweisen Service-Review entfernt - - Begruendung: Review- und Improvement-Informationen sind interne Steuerungsdaten, - nicht kundenrelevant. Sie gehoeren in die Service-Definition (Single Source of Truth), - nicht in den kundenorientierten Service-Steckbrief. - autor: "DIGITOM-Projekt" +# ============================================================================= +# SCHEMA: SERVICE-STECKBRIEF +# ============================================================================= +# +# Dieses Schema definiert die Struktur eines Service-Steckbriefs. +# Der Service-Steckbrief ist die kundenorientierte Darstellung eines Services +# im Service-Katalog – ein Auszug aus der Service-Definition. +# +# Abgrenzung: +# - Service-Definition = internes Master-Dokument (spm_schema_service-definition.yaml) +# - Service-Steckbrief = kundenorientierter Auszug (dieses Schema) +# +# Prinzip: +# - Der Steckbrief enthält NUR Informationen, die für Kunden relevant sind +# - Technische Details, interne Prozesse und Kostenstrukturen werden ausgeblendet +# - Die Sprache ist bewusst nicht-technisch und verständlich +# +# ============================================================================= + +schema: + name: "Service-Steckbrief" + version: "0.3" + status: "draft" + erstellt: "2025-11-27" + geaendert: "2026-01-31" + projekt: "DIGITOM" + + beschreibung: > + Der Service-Steckbrief ist die offizielle, kundenorientierte Beschreibung + eines Services im Service-Katalog. Er beantwortet die Fragen, die Ämter + und Mitarbeitende typischerweise haben: Was ist der Service? Was bekomme + ich? Was bekomme ich nicht? Wie gut ist er? Wie beantrage ich ihn? + + ableitung_von: "spm_schema_service-definition.yaml" + + verantwortung: + inhalt: "Service Owner (liefert)" + qualitaetssicherung: "Service-Portfolio-Manager (prüft Konsistenz und Verständlichkeit)" + freigabe: "Service-Portfolio-Manager" + publikation: "Service-Portfolio-Manager" + + zielgruppe: + primaer: "Mitarbeitende der Stadtverwaltung (Nutzer)" + sekundaer: "Amtsleitungen und deren Delegierte (Kunden/Entscheider)" + + publikationsort: + beschreibung: > + Der Service-Steckbrief wird im Service-Katalog publiziert. + Der konkrete Publikationskanal (Intranet, Self-Service-Portal) + ist implementierungsabhängig. + anforderung: "Barrierefreier, durchsuchbarer Zugang für alle Zielgruppen" + +# ============================================================================= +# ATTRIBUT-DEFINITIONEN +# ============================================================================= + +attribute: + + # --------------------------------------------------------------------------- + # IDENTIFIKATION + # --------------------------------------------------------------------------- + identifikation: + beschreibung: "Eindeutige Identifikation und Grundinformationen" + + attribute: + - name: "service_id" + typ: "string" + pflicht: true + beschreibung: "Eindeutiger Identifier (aus Service-Definition übernommen)" + quelle: "service-definition.metadaten.service_id" + sichtbarkeit: "Kann angezeigt werden, primär für Referenzzwecke" + + - name: "service_name" + typ: "string" + pflicht: true + beschreibung: "Offizieller Name des Services" + quelle: "service-definition.identitaet.service_name" + beispiel: "Digitaler Arbeitsplatz" + + - name: "service_name_kurz" + typ: "string" + pflicht: false + beschreibung: "Kurzbezeichnung oder Akronym (falls gebräuchlich)" + quelle: "service-definition.identitaet.service_name_kurz" + beispiel: "DAP" + + - name: "version" + typ: "string" + pflicht: true + beschreibung: "Version des Steckbriefs" + quelle: "service-definition.metadaten.version" + + - name: "stand" + typ: "date" + pflicht: true + beschreibung: "Datum der letzten Aktualisierung" + quelle: "service-definition.metadaten.geaendert_am" + anzeige_format: "TT.MM.JJJJ" + + # --------------------------------------------------------------------------- + # ÜBERBLICK + # --------------------------------------------------------------------------- + ueberblick: + beschreibung: "Schnelle Orientierung: Was ist das? Für wen?" + + attribute: + - name: "kurzbeschreibung" + typ: "string" + pflicht: true + beschreibung: "Einzeilige Beschreibung (max. 200 Zeichen)" + quelle: "service-definition.identitaet.kurzbeschreibung" + hinweis: "Soll auch ohne Kontext verständlich sein" + beispiel: "Standardisierter PC-Arbeitsplatz mit Office-Anwendungen und E-Mail für alle Mitarbeitenden" + + - name: "nutzen" + typ: "text" + pflicht: true + beschreibung: > + Was bringt mir dieser Service? Welches Problem löst er? + Formulierung aus Kundenperspektive, nicht aus IT-Sicht. + quelle: "service-definition.identitaet.zweck" + transformation: "Ggf. Umformulierung in kundenorientierte Sprache" + beispiel: > + Mit dem Digitalen Arbeitsplatz können Sie Ihre täglichen + Büroaufgaben erledigen: E-Mails schreiben, Dokumente erstellen, + an Videokonferenzen teilnehmen und auf zentrale Anwendungen zugreifen. + + - name: "zielgruppe" + typ: "list[string]" + pflicht: true + beschreibung: "Für wen ist dieser Service gedacht?" + quelle: "service-definition.identitaet.zielgruppe" + beispiel: + - "Alle Mitarbeitenden der Stadtverwaltung" + + - name: "service_kategorie" + typ: "objekt" + pflicht: true + beschreibung: "Art des Services (beeinflusst Verfügbarkeit und Beantragung)" + quelle: "service-definition.identitaet.service_kategorie" + schema: + - name: "kategorie_id" + typ: "enum" + werte: ["A", "B", "C"] + - name: "kategorie_bezeichnung" + typ: "string" + beschreibung: "Kundenfreundliche Bezeichnung" + mapping: + A: "Basis-Service (für alle Mitarbeitenden)" + B: "Erweiterungs-Service (optional buchbar)" + C: "Spezial-Service (für bestimmte Ämter)" + - name: "hinweis" + typ: "string" + pflicht: false + beschreibung: "Zusatzinformation zur Kategorie" + beispiel_c: "Dieser Service ist exklusiv für das Amt für Soziales verfügbar." + + # --------------------------------------------------------------------------- + # LEISTUNGSUMFANG + # --------------------------------------------------------------------------- + leistungsumfang: + beschreibung: "Was bekomme ich? Was bekomme ich nicht?" + + attribute: + - name: "das_ist_enthalten" + typ: "list[string]" + pflicht: true + beschreibung: "Konkrete Leistungen, die im Service enthalten sind" + quelle: "service-definition.leistungsumfang.leistungen_inkludiert" + hinweis: "Kundenverständlich formulieren, keine technischen Details" + beispiel: + - "Windows-PC oder Laptop" + - "Microsoft Office (Word, Excel, PowerPoint, Outlook)" + - "E-Mail-Postfach mit 5 GB Speicher" + - "Zugang zum städtischen Netzwerk" + - "Standarddrucker in Ihrem Gebäude" + + - name: "das_ist_nicht_enthalten" + typ: "list[string]" + pflicht: true + beschreibung: "Explizit nicht enthaltene Leistungen" + quelle: "service-definition.leistungsumfang.leistungen_exkludiert" + hinweis: "Vermeidet Missverständnisse und Enttäuschungen" + beispiel: + - "Spezialsoftware (z.B. CAD, Statistik) – siehe Erweiterungs-Services" + - "Diensthandy – siehe Service 'Mobile Endgeräte'" + - "Individuelle Software-Installationen" + + - name: "voraussetzungen" + typ: "list[string]" + pflicht: false + beschreibung: "Was muss gegeben sein, damit ich den Service nutzen kann?" + quelle: "service-definition.leistungsumfang.voraussetzungen" + beispiel: + - "Gültiger Benutzeraccount (wird bei Dienstantritt automatisch erstellt)" + - "Abgeschlossene IT-Sicherheitsunterweisung" + + # --------------------------------------------------------------------------- + # SERVICEQUALITÄT + # --------------------------------------------------------------------------- + servicequalitaet: + beschreibung: "Wie gut ist der Service? Wann ist er verfügbar?" + + attribute: + - name: "verfuegbarkeit" + typ: "objekt" + pflicht: true + beschreibung: "Wann kann ich den Service nutzen?" + quelle: "service-definition.qualitaet.verfuegbarkeit" + schema: + - name: "servicezeit" + typ: "string" + beschreibung: "Wann ist der Service verfügbar?" + beispiel: "Montag bis Freitag, 6:00 bis 22:00 Uhr; Samstag 8:00 bis 14:00 Uhr" + - name: "wartungsfenster" + typ: "string" + beschreibung: "Wann finden geplante Wartungen statt?" + beispiel: "Sonntags zwischen 2:00 und 6:00 Uhr (der Service kann in dieser Zeit eingeschränkt sein)" + + - name: "service_level_dokument" + typ: "objekt" + pflicht: true + beschreibung: > + Verweis auf die detaillierten Qualitätszusagen. + Die Struktur unterscheidet sich je nach Service-Kategorie. + quelle: "service-definition.qualitaet.service_level_referenz" + schema: + - name: "typ" + typ: "enum" + werte: + - id: "SLS" + anzeige: "Service Level Specification" + beschreibung: "Detaillierte Qualitätsbeschreibung für diesen Service" + - id: "SLA_integriert" + anzeige: "Individuelle Vereinbarung" + beschreibung: "Die Qualitätszusagen sind Teil der bilateralen Vereinbarung mit Ihrem Amt" + - name: "dokument_titel" + typ: "string" + beschreibung: "Titel des referenzierten Dokuments" + - name: "dokument_link" + typ: "string" + pflicht: false + beschreibung: "Link zum Dokument (falls öffentlich zugänglich)" + - name: "hinweis" + typ: "string" + pflicht: false + beispiel_c: "Für Details wenden Sie sich an Ihre Amtsleitung oder den Service Owner." + + - name: "qualitaets_highlights" + typ: "list[string]" + pflicht: false + beschreibung: > + Ausgewählte, kundenrelevante Qualitätsmerkmale aus der SLS. + Keine vollständige Liste, sondern die wichtigsten Punkte. + transformation: "Extraktion aus SLS, kundenverständlich formuliert" + beispiel: + - "Verfügbarkeit: 99,5% während der Servicezeiten" + - "Bei Störungen: Reaktion innerhalb von 4 Stunden" + - "Geplante Wartungen werden mindestens 3 Tage vorher angekündigt" + + # --------------------------------------------------------------------------- + # SUPPORT & KONTAKT + # --------------------------------------------------------------------------- + support: + beschreibung: "Wie bekomme ich Hilfe? An wen wende ich mich?" + + attribute: + - name: "supportzeiten" + typ: "string" + pflicht: true + beschreibung: "Wann ist der Support erreichbar?" + quelle: "service-definition.qualitaet.verfuegbarkeit.supportzeit" + beispiel: "Montag bis Freitag, 8:00 bis 17:00 Uhr" + + - name: "kontaktwege" + typ: "list[objekt]" + pflicht: true + beschreibung: "Wie erreiche ich den Support?" + schema: + - name: "kanal" + typ: "string" + beispiele: ["Telefon", "E-Mail", "Self-Service-Portal", "Vor Ort"] + - name: "details" + typ: "string" + beispiele: + - "0761 / 201-XXXX" + - "servicedesk@digit.freiburg.de" + - "https://selfservice.digit.freiburg.de" + - name: "hinweis" + typ: "string" + pflicht: false + beispiel: "Für schnelle Hilfe bei Störungen" + + - name: "service_owner_kontakt" + typ: "objekt" + pflicht: true + beschreibung: "Ansprechperson für grundsätzliche Fragen zum Service" + quelle: "service-definition.verantwortlichkeiten.service_owner" + schema: + - name: "name" + typ: "string" + quelle: "service_owner.person_name" + - name: "rolle" + typ: "string" + wert: "Service Owner" + - name: "kontakt" + typ: "string" + pflicht: false + beschreibung: "E-Mail (nur wenn explizit freigegeben)" + hinweis: > + Im Regelfall sollten Anfragen über den Service Desk laufen. + Der direkte Kontakt zum SO ist für strategische Fragen + und Amtsleitungen gedacht. + + # --------------------------------------------------------------------------- + # BEANTRAGUNG + # --------------------------------------------------------------------------- + beantragung: + beschreibung: "Wie bekomme ich den Service?" + + attribute: + - name: "beantragungswege" + typ: "list[objekt]" + pflicht: true + beschreibung: "Wie kann ich den Service anfordern?" + quelle: "service-definition.betriebsmodell.request_wege" + schema: + - name: "weg" + typ: "string" + beispiele: + - "Self-Service-Portal" + - "Service Desk" + - "Über Ihre Amtsleitung" + - name: "link" + typ: "string" + pflicht: false + - name: "hinweis" + typ: "string" + pflicht: false + beispiel: "Für Basis-Services ist keine Beantragung nötig – Sie erhalten den Service automatisch." + + - name: "berechtigungslogik" + typ: "text" + pflicht: false + beschreibung: "Wer darf den Service beantragen/nutzen?" + transformation: "Ableitung aus service_kategorie und zielgruppe" + beispiele: + kategorie_a: "Alle Mitarbeitenden erhalten diesen Service automatisch bei Dienstantritt." + kategorie_b: "Die Beantragung erfolgt über Ihre Amtsleitung. Es können Kosten für Ihr Amt entstehen." + kategorie_c: "Dieser Service ist nur für berechtigte Ämter verfügbar. Bei Interesse wenden Sie sich an den Service Owner." + + # --------------------------------------------------------------------------- + # DATENSCHUTZ & HINWEISE + # --------------------------------------------------------------------------- + hinweise: + beschreibung: "Wichtige Hinweise für Nutzer" + + attribute: + - name: "datenschutz_hinweis" + typ: "text" + pflicht: true + beschreibung: "Kundenverständlicher Hinweis zum Datenschutz" + quelle: "service-definition.compliance.datenschutz_klassifikation" + transformation: + keine_pbD: "In diesem Service werden keine personenbezogenen Daten verarbeitet." + pbD_normal: "In diesem Service werden personenbezogene Daten verarbeitet. Die Verarbeitung erfolgt gemäß DSGVO und LDSG BW." + pbD_hoch: "In diesem Service werden sensible personenbezogene Daten verarbeitet. Bitte beachten Sie die besonderen Schutzmaßnahmen in der Nutzungsanleitung." + besondere_kategorien: "In diesem Service werden besonders schützenswerte Daten verarbeitet (z.B. Gesundheitsdaten). Die Nutzung erfordert besondere Sorgfalt. Details finden Sie in der Datenschutzdokumentation." + + - name: "wichtige_hinweise" + typ: "list[string]" + pflicht: false + beschreibung: "Sonstige wichtige Hinweise für Nutzer" + beispiel: + - "Bitte melden Sie sich am Ende des Arbeitstages ab, um Sicherheitsrisiken zu vermeiden." + - "Private Nutzung ist nur im Rahmen der IT-Nutzungsrichtlinie gestattet." + + # --------------------------------------------------------------------------- + # WEITERFÜHRENDE INFORMATIONEN + # --------------------------------------------------------------------------- + weiterführend: + beschreibung: "Links zu weiteren Dokumenten und Ressourcen" + + attribute: + - name: "dokumente" + typ: "list[objekt]" + pflicht: false + beschreibung: "Für Kunden relevante Dokumente" + quelle: "service-definition.dokumentation.dokumente (gefiltert)" + filter: "Nur Dokumente mit typ in ['sls', 'benutzerhandbuch', 'faq', 'schulungsunterlage']" + schema: + - name: "titel" + typ: "string" + - name: "typ" + typ: "enum" + werte: + - id: "sls" + anzeige: "Qualitätsbeschreibung" + - id: "benutzerhandbuch" + anzeige: "Benutzerhandbuch" + - id: "faq" + anzeige: "Häufige Fragen" + - id: "schulungsunterlage" + anzeige: "Schulungsmaterial" + - name: "link" + typ: "string" + + - name: "verwandte_services" + typ: "list[objekt]" + pflicht: false + beschreibung: "Services, die für Nutzer dieses Services relevant sein könnten" + schema: + - name: "service_id" + typ: "string" + - name: "service_name" + typ: "string" + - name: "beziehung" + typ: "string" + beispiele: + - "Ergänzend verfügbar" + - "Alternative für spezielle Anforderungen" + - "Wird für diesen Service benötigt" + +# ============================================================================= +# DARSTELLUNGSVARIANTEN (VIEWS) +# ============================================================================= + +views: + beschreibung: > + Der Service-Steckbrief kann in verschiedenen Kontexten unterschiedlich + dargestellt werden. Die Views definieren, welche Attribute in welchem + Kontext angezeigt werden. + + varianten: + - name: "katalog_uebersicht" + beschreibung: "Listenansicht im Service-Katalog" + anzeige: + - service_name + - kurzbeschreibung + - service_kategorie.kategorie_bezeichnung + - zielgruppe (gekürzt) + + - name: "katalog_detail" + beschreibung: "Vollständige Detailansicht eines Services" + anzeige: "Alle Attribute" + + - name: "request_katalog" + beschreibung: "Ansicht im ITSM-Tool für Service-Anfragen" + anzeige: + - service_name + - kurzbeschreibung + - das_ist_enthalten + - das_ist_nicht_enthalten + - beantragungswege + - kontaktwege + hinweis: > + Diese View wird für die Integration mit dem ITSM-Tool benötigt. + Die konkrete Implementierung hängt vom gewählten Tool ab. + + - name: "entscheider_view" + beschreibung: "Ansicht für Amtsleitungen (Steuerungsperspektive)" + anzeige: + - service_name + - kurzbeschreibung + - service_kategorie + - service_level_dokument + - service_owner_kontakt + - berechtigungslogik + zusaetzlich: + - sla_referenz: "Link zum vollständigen SLA (falls vorhanden)" + +# ============================================================================= +# VALIDIERUNGSREGELN +# ============================================================================= + +validierung: + + regeln: + - id: "VAL-STB-001" + beschreibung: "Kurzbeschreibung muss ohne Kontext verständlich sein" + typ: "qualitativ" + pruefung: "Review durch SHM oder SPM" + + - id: "VAL-STB-002" + beschreibung: "Keine technischen Fachbegriffe ohne Erklärung" + typ: "qualitativ" + pruefung: "Review durch SHM" + + - id: "VAL-STB-003" + beschreibung: "Mindestens ein Kontaktweg muss angegeben sein" + typ: "formal" + regel: "kontaktwege.length >= 1" + + - id: "VAL-STB-004" + beschreibung: "Bei Kategorie B/C muss Berechtigungslogik ausgefüllt sein" + typ: "formal" + regel: > + Wenn service_kategorie in ['B', 'C'], + dann berechtigungslogik darf nicht leer sein. + + - id: "VAL-STB-005" + beschreibung: "Service-Level-Dokument muss referenziert sein" + typ: "formal" + regel: "service_level_dokument.typ ist gesetzt" + + qualitaetskriterien: + beschreibung: > + Qualitative Kriterien, die vor Publikation geprüft werden sollten. + Verantwortung: SPM in Abstimmung mit SHM. + + kriterien: + - "Verständlichkeit: Ein fachfremder Mitarbeitender versteht den Steckbrief" + - "Vollständigkeit: Alle Pflichtfelder sind ausgefüllt" + - "Konsistenz: Informationen widersprechen nicht der Service-Definition" + - "Aktualität: Informationen entsprechen dem aktuellen Stand" + - "Barrierefreiheit: Texte sind in einfacher Sprache verfasst" + +# ============================================================================= +# PFLEGEPROZESS +# ============================================================================= + +pflege: + + trigger: + beschreibung: "Wann muss der Steckbrief aktualisiert werden?" + ereignisse: + - trigger: "Änderung der Service-Definition" + aktion: "Prüfen, ob Steckbrief betroffen" + verantwortung: "Service Owner" + + - trigger: "SLS/SLA-Änderung" + aktion: "Qualitäts-Highlights und Referenzen aktualisieren" + verantwortung: "Service Owner" + + - trigger: "Änderung Kontaktdaten" + aktion: "Support-Abschnitt aktualisieren" + verantwortung: "Service Owner" + + - trigger: "Jährlicher Katalog-Review" + aktion: "Vollständige Prüfung aller Steckbriefe" + verantwortung: "SPM" + + aenderungstypen: + beschreibung: "Klassifikation von Änderungen für Governance-Routing" + + typen: + - typ: "redaktionell" + beispiele: + - "Korrektur Tippfehler" + - "Aktualisierung Telefonnummer" + - "Umformulierung ohne inhaltliche Änderung" + entscheidung: "Service Owner (autonom)" + publikation: "sofort" + + - typ: "inhaltlich_minor" + beispiele: + - "Ergänzung FAQ-Link" + - "Klarstellung Leistungsumfang (ohne Änderung)" + - "Hinzufügen verwandter Service" + entscheidung: "Service Owner + SPM (bilateral)" + publikation: "nach Freigabe SPM" + + - typ: "inhaltlich_major" + beispiele: + - "Änderung Leistungsumfang" + - "Neue/geänderte Service Levels" + - "Änderung Zielgruppe" + entscheidung: "SOR" + publikation: "nach SOR-Freigabe" + hinweis: "Meist gekoppelt an Änderung der Service-Definition" + +# ============================================================================= +# SCHNITTSTELLE ZU ITSM-TOOL +# ============================================================================= + +itsm_integration: + beschreibung: > + Der Service-Steckbrief dient als Stammdatenquelle für den Request-Katalog + im ITSM-Tool. Diese Sektion definiert die Anforderungen an die Integration. + + status: "Anforderungsdefinition (Tool noch nicht final)" + + anforderungen: + - id: "ITSM-REQ-001" + beschreibung: "Service-ID muss als eindeutiger Schlüssel dienen" + + - id: "ITSM-REQ-002" + beschreibung: "Beantragungswege müssen in Request-Formulare überführbar sein" + + - id: "ITSM-REQ-003" + beschreibung: "Änderungen am Steckbrief müssen in das ITSM-Tool synchronisiert werden" + hinweis: "Richtung: SCM → ITSM (unidirektional)" + + - id: "ITSM-REQ-004" + beschreibung: "Kategorie-basierte Sichtbarkeitssteuerung muss möglich sein" + detail: > + Kategorie A: Für alle sichtbar + Kategorie B: Für alle sichtbar, Beantragung eingeschränkt + Kategorie C: Nur für berechtigte Ämter sichtbar + + datenhoheit: "SCM (Service-Steckbrief ist führend)" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + - id: "OPEN-STB-001" + beschreibung: "Template für Service-Steckbrief erstellen (Markdown/HTML)" + prioritaet: "hoch" + ziel_ordner: "02.6_arbeitsmaterialien" + + - id: "OPEN-STB-002" + beschreibung: "Abstimmung mit SHM: Qualitätskriterien für Verständlichkeit" + prioritaet: "mittel" + abhaengig_von: "Finalisierung SHM-Rollenbeschreibung" + + - id: "OPEN-STB-003" + beschreibung: "ITSM-Tool-Auswahl: Konkrete Mapping-Spezifikation" + prioritaet: "niedrig" + status: "Wartet auf Tool-Entscheidung" + + - id: "OPEN-STB-004" + beschreibung: "Barrierefreiheit: Prüfung gegen BITV 2.0" + prioritaet: "mittel" + hinweis: "Relevant für Publikationsformat" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-11-27" + aenderung: "Initiale Version erstellt" + autor: "DIGITOM-Projekt" + + - version: "0.2" + datum: "2025-12-17" + aenderung: | + - Neuer Abschnitt 'review_status' fuer Service-Review-Ergebnisse (GOV-SR-001) + - Neuer Abschnitt 'laufende_verbesserungen' fuer Improvement-Tracking (GOV-SR-005) + - Neuer Pflege-Trigger fuer quartalsweisen Service-Review + autor: "DIGITOM-Projekt" + referenz: "konzept_service-review.yaml" + + - version: "0.3" + datum: "2026-01-31" + aenderung: | + - Abschnitt 'review_status' entfernt (verschoben nach Service-Definition) + - Abschnitt 'laufende_verbesserungen' entfernt (verschoben nach Service-Definition) + - Pflege-Trigger fuer quartalsweisen Service-Review entfernt + - Begruendung: Review- und Improvement-Informationen sind interne Steuerungsdaten, + nicht kundenrelevant. Sie gehoeren in die Service-Definition (Single Source of Truth), + nicht in den kundenorientierten Service-Steckbrief. + autor: "DIGITOM-Projekt" referenz: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_transition-steckbrief.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_transition-steckbrief.yaml index 6fdab90..2f3554a 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_transition-steckbrief.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_transition-steckbrief.yaml @@ -1,633 +1,633 @@ -# ============================================================================= -# SCHEMA: TRANSITION-STECKBRIEF -# ============================================================================= -# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/ -# Dateiname: spm_schema_transition-steckbrief.yaml -# ============================================================================= - -metadata: - id: "SCHEMA-TR-STECKBRIEF" - name: "Schema Transition-Steckbrief" - version: "0.3" - status: "draft" - erstellt: "2025-12-17" - aktualisiert: "2026-02-18" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - dokumenttyp: "schema" - - beschreibung: | - Schema-Definition für den Transition-Steckbrief. Der Transition- - Steckbrief ist ein temporäres Prozessdokument, das die Service - Transition von Gate 1 (tr_01, Entry-Gate) bis zum ELS-Exit dokumentiert. - - Nach Abschluss wird er als Anhang in den Service-Steckbrief überführt. - - Hinweis zur Gate-Nummerierung: Gate 1 (tr_01) ist das Entry-Gate der - Transition-Phase. Gate 2 (tr_09) ist die Entry-Prüfung nach Build, - Gate 3 (tr_12) ist die Go-Live-Freigabe. Alle drei Gates gehören zur - Transition-Phase und werden im Transition-Steckbrief dokumentiert. - - mvp_hinweis: | - Dieses Schema folgt dem MVP-Ansatz: Minimale Pflichtfelder, - Freitext wo sinnvoll, keine Über-Strukturierung. Erweiterungen - basierend auf operativer Erfahrung sind explizit vorgesehen. - - referenzen: - governance: - - "GOV-TR-018: Einführung Transition-Steckbrief" - - "GOV-TR-019: Überführung in Service-Steckbrief" - - "GOV-TR-020: Begriffliches Mapping" - konzept: "02a_lifecycle-konzepte/konzept_service-transition.yaml" - verwandtes_schema: "spm_schema_service-steckbrief.yaml" - arbeitspakete: - - "AP-01: Gate-Struktur" - - "AP-02: Entscheidungskriterien" - - "AP-03: Governance-Verfahren" - - "AP-04: ELS-Konzept" - - "AP-05: Rollback-Szenarien" - -# ============================================================================= -# SCHEMA-DEFINITION -# ============================================================================= - -schema: - - # --------------------------------------------------------------------------- - # HEADER - # --------------------------------------------------------------------------- - header: - beschreibung: "Identifikation und Statusverfolgung" - - felder: - - - name: "id" - typ: "string" - pflicht: true - beschreibung: "Eindeutige ID des Transition-Steckbriefs" - format: "TR-[SERVICE-ID]-[YYYY]" - beispiel: "TR-SVC-001-2025" - - - name: "service_referenz" - typ: "string" - pflicht: true - beschreibung: "ID des zugehörigen Service-Steckbriefs" - beispiel: "SVC-001" - - - name: "service_name" - typ: "string" - pflicht: true - beschreibung: "Name des Services (für Lesbarkeit)" - beispiel: "Dokumentenmanagement-System" - - - name: "transition_typ" - typ: "enum" - pflicht: true - beschreibung: "Art der Transition" - werte: - - "neuer_service" - - "wesentliche_aenderung" - mvp_hinweis: "Für MVP nur diese zwei Typen. Differenzierung nach Service-Kategorie kann später ergänzt werden." - - - name: "status" - typ: "enum" - pflicht: true - beschreibung: "Aktueller Status im Transition-Prozess" - werte: - - "angelegt" - - "gate_2_offen" - - "gate_2_passiert" - - "pilot_aktiv" - - "gate_3_offen" - - "go_live" - - "els_aktiv" - - "abgeschlossen" - - "abgebrochen" - - - name: "transition_start" - typ: "date" - pflicht: true - beschreibung: "Datum des Gate-1-Eintritts (tr_01) in die Transition-Phase" - - - name: "transition_ende" - typ: "date" - pflicht: false - beschreibung: "Datum des ELS-Exit (bei Abschluss)" - - # --------------------------------------------------------------------------- - # GATE 2: ENTRY-PRÜFUNG NACH BUILD - # --------------------------------------------------------------------------- - gate_2: - beschreibung: "Dokumentation der Entry-Prüfung nach Build (Gate-Keeper: Service Owner)" - lifecycle_aktivitaet: "tr_09" - referenz: "AP-01, AP-02" - - felder: - - - name: "datum" - typ: "date" - pflicht: true - beschreibung: "Datum der Gate-2-Entscheidung" - - - name: "entscheidung" - typ: "enum" - pflicht: true - beschreibung: "Ergebnis der Gate-2-Prüfung" - werte: - - "freigabe" - - "freigabe_mit_auflagen" - - "zurueckweisung" - - "eskalation_an_sor" - - # --- Prüfdimensionen --- - - name: "pruefung_uebergabe_vollstaendigkeit" - typ: "enum" - pflicht: true - beschreibung: "Liegen alle Artefakte aus der Build-Phase vor? (Showstopper)" - werte: - - "erfuellt" - - "nicht_erfuellt" - referenz: "AP-02, G2-DIM-01" - - - name: "pruefung_betriebsvorbereitung" - typ: "enum" - pflicht: true - beschreibung: "Sind Betrieb und Support informiert/vorbereitet?" - werte: - - "erfuellt" - - "mit_auflagen" - - "nicht_erfuellt" - referenz: "AP-02, G2-DIM-02" - - # --- Pilot-Entscheidung --- - - name: "pilot_erforderlich" - typ: "boolean" - pflicht: true - beschreibung: "Ist ein Pilot vor Go-Live erforderlich?" - referenz: "AP-01, Pilot-Konzept" - - - name: "pilot_begruendung" - typ: "text" - pflicht: false - beschreibung: "Begründung für Pilot-Entscheidung (bei ja oder bei bewusstem Verzicht)" - max_zeichen: 500 - - # --- Auflagen --- - - name: "auflagen" - typ: "text" - pflicht: false - beschreibung: "Auflagen bei 'freigabe_mit_auflagen' (Beschreibung, Frist, Verantwortlicher)" - hinweis: "Freitext für MVP. Strukturierte Auflagen-Liste kann später ergänzt werden." - - # --- Begründung --- - - name: "begruendung" - typ: "text" - pflicht: false - beschreibung: "Begründung bei Zurückweisung oder Eskalation" - max_zeichen: 500 - - # --------------------------------------------------------------------------- - # PILOT (optional) - # --------------------------------------------------------------------------- - pilot: - beschreibung: "Dokumentation der Pilot-Phase (nur wenn pilot_erforderlich = true)" - referenz: "AP-01, Teil C" - - felder: - - - name: "status" - typ: "enum" - pflicht: true - beschreibung: "Status der Pilot-Phase" - werte: - - "nicht_erforderlich" - - "geplant" - - "aktiv" - - "erfolgreich_abgeschlossen" - - "mit_einschraenkungen_abgeschlossen" - - "abgebrochen" - - - name: "start_datum" - typ: "date" - pflicht: false - beschreibung: "Start der Pilot-Phase" - - - name: "ende_datum" - typ: "date" - pflicht: false - beschreibung: "Ende der Pilot-Phase" - - - name: "scope" - typ: "text" - pflicht: false - beschreibung: "Pilot-Scope (Nutzergruppe, Funktionsumfang)" - max_zeichen: 300 - mvp_hinweis: "Freitext für MVP. Strukturierte Scope-Definition kann später ergänzt werden." - - - name: "ergebnis_zusammenfassung" - typ: "text" - pflicht: false - beschreibung: "Zusammenfassung der Pilot-Ergebnisse" - max_zeichen: 500 - - # --------------------------------------------------------------------------- - # GATE 3: GO-LIVE-FREIGABE - # --------------------------------------------------------------------------- - gate_3: - beschreibung: "Dokumentation der Go-Live-Freigabe (Gate-Keeper: SOR)" - lifecycle_aktivitaet: "tr_12" - referenz: "AP-01, AP-02, AP-03" - - felder: - - - name: "datum" - typ: "date" - pflicht: true - beschreibung: "Datum der SOR-Sitzung mit Gate-2-Entscheidung" - - - name: "sor_protokoll_referenz" - typ: "string" - pflicht: true - beschreibung: "Referenz auf das SOR-Protokoll" - beispiel: "SOR-2025-03-15" - - - name: "entscheidung" - typ: "enum" - pflicht: true - beschreibung: "Ergebnis der Gate-3-Prüfung" - werte: - - "go_live" - - "go_live_mit_auflagen" - - "zurueck_an_transition" - - "ablehnung" - - # --- Prüfdimensionen --- - - name: "pruefung_so_readiness" - typ: "boolean" - pflicht: true - beschreibung: "Hat SO die Betriebsreife bestätigt? (Showstopper)" - referenz: "AP-02, G3-DIM-01" - - - name: "pruefung_dokumentation" - typ: "boolean" - pflicht: true - beschreibung: "Ist Dokumentation vorhanden UND implementiert? (Showstopper)" - referenz: "AP-02, G3-DIM-02" - - - name: "pruefung_portfolio_passung" - typ: "boolean" - pflicht: true - beschreibung: "Kein Widerspruch zu bestehenden Services? (Showstopper)" - referenz: "AP-02, G3-DIM-03" - - - name: "pruefung_ressourcen_commitment" - typ: "enum" - pflicht: true - beschreibung: | - Haben Betrieb und Support die OPERATIVE Übernahme für den - Go-Live-Termin bestätigt? - - WICHTIG: Dies ist die operative Bestätigung (konkreter Termin, - Personal eingeplant, Übergabe erfolgt). Die grundsätzliche - Bereitschaft wurde bereits an Gate 1 geprüft. - - Falls hier "nicht_bestaetigt" ausgewählt wird, ist zu prüfen, - ob sich die Situation gegenüber Gate 1 verändert hat (z.B. - unerwarteter Personalabgang, Priorisierungsänderungen). - werte: - - "bestaetigt" - - "mit_auflagen" - - "nicht_bestaetigt" - referenz: "AP-02, G3-DIM-04" - abgrenzung_gate_1: | - Gate 1: Grundsätzliches Commitment ("Wir können/wollen diesen Service übernehmen") - Gate 3: Operatives Commitment ("Wir sind JETZT bereit für die Übernahme") - - - name: "pruefung_auflagen_gate_2" - typ: "enum" - pflicht: true - beschreibung: "Auflagen aus Gate 2 erfüllt? (Showstopper wenn vorhanden)" - werte: - - "erfuellt" - - "nicht_erfuellt" - - "keine_auflagen" - referenz: "AP-02, G3-DIM-05" - - # --- Formalia --- - - name: "so_bestaetigung_durch_sor" - typ: "boolean" - pflicht: true - beschreibung: "SO wurde durch SOR formal bestätigt" - referenz: "GOV-TR-004" - - # --- Auflagen --- - - name: "auflagen" - typ: "text" - pflicht: false - beschreibung: "Auflagen bei 'go_live_mit_auflagen' (Gate 3)" - max_zeichen: 500 - - # --------------------------------------------------------------------------- - # ELS: EARLY LIFE SUPPORT - # --------------------------------------------------------------------------- - els: - beschreibung: "Dokumentation der ELS-Phase" - referenz: "AP-04" - - felder: - - - name: "start" - typ: "date" - pflicht: true - beschreibung: "ELS-Start (= Go-Live-Datum)" - - - name: "ende" - typ: "date" - pflicht: false - beschreibung: "ELS-Ende (Datum der SO-Entscheidung)" - - - name: "dauer_wochen" - typ: "integer" - pflicht: false - beschreibung: "Tatsächliche ELS-Dauer in Wochen (gerundet)" - hinweis: "Wird bei Abschluss berechnet" - - - name: "kritische_stoerungen_anzahl" - typ: "integer" - pflicht: true - beschreibung: "Anzahl kritischer Störungen während ELS" - default: 0 - referenz: "AP-04, Definition 'kritische Störung'" - - - name: "exit_begruendung" - typ: "text" - pflicht: true - beschreibung: "Begründung, warum Exit-Kriterien als erfüllt gelten" - max_zeichen: 500 - beispiel: "Keine kritischen Störungen seit 3 Wochen, Support-Aufkommen normalisiert." - - - name: "lessons_learned" - typ: "text" - pflicht: false - beschreibung: "Wesentliche Erkenntnisse für Service Review" - max_zeichen: 500 - mvp_hinweis: "Optional für MVP. Kann bei Bedarf verpflichtend werden." - - - name: "eskalation_erfolgt" - typ: "boolean" - pflicht: true - beschreibung: "Wurde an SOR eskaliert (bei Überschreitung Maximaldauer)?" - default: false - - - name: "eskalation_ergebnis" - typ: "text" - pflicht: false - beschreibung: "SOR-Entscheidung bei Eskalation" - max_zeichen: 300 - hinweis: "Nur ausfüllen wenn eskalation_erfolgt = true" - - # --------------------------------------------------------------------------- - # ABSCHLUSS-CHECKLISTE - # --------------------------------------------------------------------------- - abschluss_checkliste: - beschreibung: "Checkliste zur Sicherstellung der Vollständigkeit bei Abschluss" - referenz: "AP-07" - - mvp_hinweis: | - Für MVP als einfache Boolean-Checkliste. Kann später um - Nachweise/Referenzen pro Punkt erweitert werden. - - felder: - - - name: "gate_2_passiert" - typ: "boolean" - pflicht: true - beschreibung: "Gate 2 (Entry-Prüfung nach Build) wurde erfolgreich passiert" - - - name: "pilot_abgeschlossen" - typ: "boolean" - pflicht: true - beschreibung: "Pilot abgeschlossen (oder nicht erforderlich)" - - - name: "gate_3_passiert" - typ: "boolean" - pflicht: true - beschreibung: "Gate 3 (Go-Live-Freigabe) wurde erfolgreich passiert" - - - name: "els_abgeschlossen" - typ: "boolean" - pflicht: true - beschreibung: "ELS wurde abgeschlossen" - - - name: "service_im_katalog" - typ: "boolean" - pflicht: true - beschreibung: "Service ist im Katalog aktiviert" - - - name: "so_bestaetigt" - typ: "boolean" - pflicht: true - beschreibung: "SO wurde durch SOR bestätigt" - - - name: "dokumentation_vollstaendig" - typ: "boolean" - pflicht: true - beschreibung: "Betriebsdokumentation ist vollständig und implementiert" - - # --------------------------------------------------------------------------- - # SONDERFÄLLE: ABBRUCH / ROLLBACK - # --------------------------------------------------------------------------- - abbruch: - beschreibung: "Dokumentation bei Abbruch oder Rollback (nur bei negativem Ausgang)" - referenz: "AP-05" - - mvp_hinweis: | - Minimale Dokumentation für MVP. Detaillierte Abbruch-Analyse - kann bei Bedarf ergänzt werden. - - felder: - - - name: "abbruch_erfolgt" - typ: "boolean" - pflicht: true - beschreibung: "Wurde die Transition abgebrochen?" - default: false - - - name: "abbruch_zeitpunkt" - typ: "enum" - pflicht: false - beschreibung: "In welcher Phase erfolgte der Abbruch?" - werte: - - "vor_gate_2" - - "nach_gate_2" - - "waehrend_pilot" - - "vor_gate_3" - - "nach_gate_3" - - "waehrend_els" - - - name: "abbruch_typ" - typ: "enum" - pflicht: false - beschreibung: "Art des Abbruchs" - werte: - - "zurueckweisung" - - "rollback" - - "termination" - referenz: "AP-05" - - - name: "abbruch_begruendung" - typ: "text" - pflicht: false - beschreibung: "Begründung für den Abbruch" - max_zeichen: 500 - - - name: "entscheider" - typ: "string" - pflicht: false - beschreibung: "Wer hat den Abbruch entschieden (SO/SOR)" - - # --------------------------------------------------------------------------- - # META - # --------------------------------------------------------------------------- - meta: - beschreibung: "Metadaten zur Dokumentenverwaltung" - - felder: - - - name: "erstellt_von" - typ: "string" - pflicht: true - beschreibung: "Wer hat den Steckbrief angelegt" - - - name: "erstellt_am" - typ: "date" - pflicht: true - beschreibung: "Erstellungsdatum" - - - name: "letzte_aenderung_von" - typ: "string" - pflicht: false - beschreibung: "Wer hat zuletzt geändert" - - - name: "letzte_aenderung_am" - typ: "date" - pflicht: false - beschreibung: "Datum der letzten Änderung" - - - name: "ueberfuehrt_am" - typ: "date" - pflicht: false - beschreibung: "Datum der Überführung in Service-Steckbrief" - hinweis: "Wird bei Status 'abgeschlossen' gesetzt" - -# ============================================================================= -# MVP-ENTSCHEIDUNGEN UND ERWEITERUNGSPOTENTIAL -# ============================================================================= - -mvp_entscheidungen: - - beschreibung: | - Folgende Vereinfachungen wurden für den MVP getroffen. Sie können - basierend auf operativer Erfahrung angepasst werden. - - entscheidungen: - - - bereich: "Auflagen-Dokumentation" - mvp: "Freitext-Feld" - erweiterung: "Strukturierte Liste mit Auflagen-ID, Frist, Status, Verantwortlicher" - trigger: "Wenn Auflagen-Tracking systematisch nötig wird" - - - bereich: "Pilot-Scope" - mvp: "Freitext-Feld" - erweiterung: "Strukturiert: Nutzergruppe, Funktionsumfang, Erfolgskriterien, Exit-Kriterien" - trigger: "Wenn Pilots häufiger und komplexer werden" - - - bereich: "Abschluss-Checkliste" - mvp: "Boolean-Felder" - erweiterung: "Pro Punkt: Nachweis-Referenz, Datum, Prüfer" - trigger: "Wenn Audit-Anforderungen steigen" - - - bereich: "Kritische Störungen" - mvp: "Nur Anzahl" - erweiterung: "Liste mit Incident-IDs, Datum, Kurzbeschreibung" - trigger: "Wenn Detailanalyse für Service Review nötig wird" - - - bereich: "Transition-Typ" - mvp: "neuer_service | wesentliche_aenderung" - erweiterung: "Differenzierung nach Service-Kategorie (Basis, Standard, Premium)" - trigger: "Wenn Portfolio-Vielfalt zunimmt" - - - bereich: "Versionierung" - mvp: "Keine explizite Versionierung des Steckbriefs" - erweiterung: "Änderungshistorie mit Version, Datum, Autor, Änderung" - trigger: "Wenn Nachvollziehbarkeit von Änderungen relevant wird" - -# ============================================================================= -# VALIDIERUNGSREGELN -# ============================================================================= - -validierung: - - beschreibung: | - Regeln zur Konsistenzprüfung. Können bei Tool-Implementierung - genutzt werden. - - regeln: - - - regel: "Gate-2-Vollständigkeit" - bedingung: "status != 'angelegt'" - pruefung: "gate_2.datum UND gate_2.entscheidung müssen gesetzt sein" - - - regel: "Pilot-Konsistenz" - bedingung: "gate_2.pilot_erforderlich = true" - pruefung: "pilot.status muss != 'nicht_erforderlich' sein" - - - regel: "Gate-3-nach-Gate-2" - bedingung: "gate_3.datum ist gesetzt" - pruefung: "gate_2.entscheidung muss 'freigabe' oder 'freigabe_mit_auflagen' sein" - - - regel: "ELS-nach-Gate-3" - bedingung: "els.start ist gesetzt" - pruefung: "gate_3.entscheidung muss 'go_live' oder 'go_live_mit_auflagen' sein" - - - regel: "Abschluss-Vollständigkeit" - bedingung: "status = 'abgeschlossen'" - pruefung: "Alle Felder in abschluss_checkliste müssen true sein" - - - regel: "Abbruch-Dokumentation" - bedingung: "abbruch.abbruch_erfolgt = true" - pruefung: "abbruch.abbruch_zeitpunkt UND abbruch.abbruch_begruendung müssen gesetzt sein" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.3" - datum: "2026-01-30" - aenderung: | - Präzisierung Ressourcen-Commitment: Klarstellung der Zwei-Stufen-Prüfung. - - Gate 1 (tr_01) prüft grundsätzliches Commitment (in service-lifecycle_transition.yaml) - - Gate 3 prüft operatives Commitment (Beschreibung präzisiert) - Hintergrund: Ressourcenfrage muss VOR Transition geklärt sein, um - Ressourcenverschwendung zu vermeiden. - autor: "DIGITOM-Projekt" - referenz: "Konzeptionelle Überprüfung Ressourcenprüfung" - - - version: "0.3" - datum: "2026-02-18" - aenderung: "Gate 1 in Transition verschoben (tr_01). Gate-IDs aktualisiert: Gate 2 = tr_09, Gate 3 = tr_12. Transition-Steckbrief dokumentiert nun alle 3 Gates." - autor: "DIGITOM-Projekt" - referenz: "service-lifecycle_transition.yaml v2.0" - - - version: "0.2" - datum: "2026-01-30" - aenderung: "Anpassung an Service-Lifecycle 3.0 (5-Phasen-Konsolidierung): Gate-Nummerierung auf globale Nummerierung umgestellt (Gate 2 = tr_08, Gate 3 = tr_11). Terminologie aktualisiert (Design-Phase statt Service-Entwicklung)." - autor: "DIGITOM-Projekt" - referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" - - - version: "0.1" - datum: "2025-12-17" - aenderung: "Initiale Schema-Definition (MVP)" - autor: "DIGITOM-Projekt" +# ============================================================================= +# SCHEMA: TRANSITION-STECKBRIEF +# ============================================================================= +# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/ +# Dateiname: spm_schema_transition-steckbrief.yaml +# ============================================================================= + +metadata: + id: "SCHEMA-TR-STECKBRIEF" + name: "Schema Transition-Steckbrief" + version: "0.3" + status: "draft" + erstellt: "2025-12-17" + aktualisiert: "2026-02-18" + projekt: "DIGITOM" + organisation: "Stadt Freiburg / DIGIT" + dokumenttyp: "schema" + + beschreibung: | + Schema-Definition für den Transition-Steckbrief. Der Transition- + Steckbrief ist ein temporäres Prozessdokument, das die Service + Transition von Gate 1 (tr_01, Entry-Gate) bis zum ELS-Exit dokumentiert. + + Nach Abschluss wird er als Anhang in den Service-Steckbrief überführt. + + Hinweis zur Gate-Nummerierung: Gate 1 (tr_01) ist das Entry-Gate der + Transition-Phase. Gate 2 (tr_09) ist die Entry-Prüfung nach Build, + Gate 3 (tr_12) ist die Go-Live-Freigabe. Alle drei Gates gehören zur + Transition-Phase und werden im Transition-Steckbrief dokumentiert. + + mvp_hinweis: | + Dieses Schema folgt dem MVP-Ansatz: Minimale Pflichtfelder, + Freitext wo sinnvoll, keine Über-Strukturierung. Erweiterungen + basierend auf operativer Erfahrung sind explizit vorgesehen. + + referenzen: + governance: + - "GOV-TR-018: Einführung Transition-Steckbrief" + - "GOV-TR-019: Überführung in Service-Steckbrief" + - "GOV-TR-020: Begriffliches Mapping" + konzept: "02a_lifecycle-konzepte/konzept_service-transition.yaml" + verwandtes_schema: "spm_schema_service-steckbrief.yaml" + arbeitspakete: + - "AP-01: Gate-Struktur" + - "AP-02: Entscheidungskriterien" + - "AP-03: Governance-Verfahren" + - "AP-04: ELS-Konzept" + - "AP-05: Rollback-Szenarien" + +# ============================================================================= +# SCHEMA-DEFINITION +# ============================================================================= + +schema: + + # --------------------------------------------------------------------------- + # HEADER + # --------------------------------------------------------------------------- + header: + beschreibung: "Identifikation und Statusverfolgung" + + felder: + + - name: "id" + typ: "string" + pflicht: true + beschreibung: "Eindeutige ID des Transition-Steckbriefs" + format: "TR-[SERVICE-ID]-[YYYY]" + beispiel: "TR-SVC-001-2025" + + - name: "service_referenz" + typ: "string" + pflicht: true + beschreibung: "ID des zugehörigen Service-Steckbriefs" + beispiel: "SVC-001" + + - name: "service_name" + typ: "string" + pflicht: true + beschreibung: "Name des Services (für Lesbarkeit)" + beispiel: "Dokumentenmanagement-System" + + - name: "transition_typ" + typ: "enum" + pflicht: true + beschreibung: "Art der Transition" + werte: + - "neuer_service" + - "wesentliche_aenderung" + mvp_hinweis: "Für MVP nur diese zwei Typen. Differenzierung nach Service-Kategorie kann später ergänzt werden." + + - name: "status" + typ: "enum" + pflicht: true + beschreibung: "Aktueller Status im Transition-Prozess" + werte: + - "angelegt" + - "gate_2_offen" + - "gate_2_passiert" + - "pilot_aktiv" + - "gate_3_offen" + - "go_live" + - "els_aktiv" + - "abgeschlossen" + - "abgebrochen" + + - name: "transition_start" + typ: "date" + pflicht: true + beschreibung: "Datum des Gate-1-Eintritts (tr_01) in die Transition-Phase" + + - name: "transition_ende" + typ: "date" + pflicht: false + beschreibung: "Datum des ELS-Exit (bei Abschluss)" + + # --------------------------------------------------------------------------- + # GATE 2: ENTRY-PRÜFUNG NACH BUILD + # --------------------------------------------------------------------------- + gate_2: + beschreibung: "Dokumentation der Entry-Prüfung nach Build (Gate-Keeper: Service Owner)" + lifecycle_aktivitaet: "tr_09" + referenz: "AP-01, AP-02" + + felder: + + - name: "datum" + typ: "date" + pflicht: true + beschreibung: "Datum der Gate-2-Entscheidung" + + - name: "entscheidung" + typ: "enum" + pflicht: true + beschreibung: "Ergebnis der Gate-2-Prüfung" + werte: + - "freigabe" + - "freigabe_mit_auflagen" + - "zurueckweisung" + - "eskalation_an_sor" + + # --- Prüfdimensionen --- + - name: "pruefung_uebergabe_vollstaendigkeit" + typ: "enum" + pflicht: true + beschreibung: "Liegen alle Artefakte aus der Build-Phase vor? (Showstopper)" + werte: + - "erfuellt" + - "nicht_erfuellt" + referenz: "AP-02, G2-DIM-01" + + - name: "pruefung_betriebsvorbereitung" + typ: "enum" + pflicht: true + beschreibung: "Sind Betrieb und Support informiert/vorbereitet?" + werte: + - "erfuellt" + - "mit_auflagen" + - "nicht_erfuellt" + referenz: "AP-02, G2-DIM-02" + + # --- Pilot-Entscheidung --- + - name: "pilot_erforderlich" + typ: "boolean" + pflicht: true + beschreibung: "Ist ein Pilot vor Go-Live erforderlich?" + referenz: "AP-01, Pilot-Konzept" + + - name: "pilot_begruendung" + typ: "text" + pflicht: false + beschreibung: "Begründung für Pilot-Entscheidung (bei ja oder bei bewusstem Verzicht)" + max_zeichen: 500 + + # --- Auflagen --- + - name: "auflagen" + typ: "text" + pflicht: false + beschreibung: "Auflagen bei 'freigabe_mit_auflagen' (Beschreibung, Frist, Verantwortlicher)" + hinweis: "Freitext für MVP. Strukturierte Auflagen-Liste kann später ergänzt werden." + + # --- Begründung --- + - name: "begruendung" + typ: "text" + pflicht: false + beschreibung: "Begründung bei Zurückweisung oder Eskalation" + max_zeichen: 500 + + # --------------------------------------------------------------------------- + # PILOT (optional) + # --------------------------------------------------------------------------- + pilot: + beschreibung: "Dokumentation der Pilot-Phase (nur wenn pilot_erforderlich = true)" + referenz: "AP-01, Teil C" + + felder: + + - name: "status" + typ: "enum" + pflicht: true + beschreibung: "Status der Pilot-Phase" + werte: + - "nicht_erforderlich" + - "geplant" + - "aktiv" + - "erfolgreich_abgeschlossen" + - "mit_einschraenkungen_abgeschlossen" + - "abgebrochen" + + - name: "start_datum" + typ: "date" + pflicht: false + beschreibung: "Start der Pilot-Phase" + + - name: "ende_datum" + typ: "date" + pflicht: false + beschreibung: "Ende der Pilot-Phase" + + - name: "scope" + typ: "text" + pflicht: false + beschreibung: "Pilot-Scope (Nutzergruppe, Funktionsumfang)" + max_zeichen: 300 + mvp_hinweis: "Freitext für MVP. Strukturierte Scope-Definition kann später ergänzt werden." + + - name: "ergebnis_zusammenfassung" + typ: "text" + pflicht: false + beschreibung: "Zusammenfassung der Pilot-Ergebnisse" + max_zeichen: 500 + + # --------------------------------------------------------------------------- + # GATE 3: GO-LIVE-FREIGABE + # --------------------------------------------------------------------------- + gate_3: + beschreibung: "Dokumentation der Go-Live-Freigabe (Gate-Keeper: SOR)" + lifecycle_aktivitaet: "tr_12" + referenz: "AP-01, AP-02, AP-03" + + felder: + + - name: "datum" + typ: "date" + pflicht: true + beschreibung: "Datum der SOR-Sitzung mit Gate-2-Entscheidung" + + - name: "sor_protokoll_referenz" + typ: "string" + pflicht: true + beschreibung: "Referenz auf das SOR-Protokoll" + beispiel: "SOR-2025-03-15" + + - name: "entscheidung" + typ: "enum" + pflicht: true + beschreibung: "Ergebnis der Gate-3-Prüfung" + werte: + - "go_live" + - "go_live_mit_auflagen" + - "zurueck_an_transition" + - "ablehnung" + + # --- Prüfdimensionen --- + - name: "pruefung_so_readiness" + typ: "boolean" + pflicht: true + beschreibung: "Hat SO die Betriebsreife bestätigt? (Showstopper)" + referenz: "AP-02, G3-DIM-01" + + - name: "pruefung_dokumentation" + typ: "boolean" + pflicht: true + beschreibung: "Ist Dokumentation vorhanden UND implementiert? (Showstopper)" + referenz: "AP-02, G3-DIM-02" + + - name: "pruefung_portfolio_passung" + typ: "boolean" + pflicht: true + beschreibung: "Kein Widerspruch zu bestehenden Services? (Showstopper)" + referenz: "AP-02, G3-DIM-03" + + - name: "pruefung_ressourcen_commitment" + typ: "enum" + pflicht: true + beschreibung: | + Haben Betrieb und Support die OPERATIVE Übernahme für den + Go-Live-Termin bestätigt? + + WICHTIG: Dies ist die operative Bestätigung (konkreter Termin, + Personal eingeplant, Übergabe erfolgt). Die grundsätzliche + Bereitschaft wurde bereits an Gate 1 geprüft. + + Falls hier "nicht_bestaetigt" ausgewählt wird, ist zu prüfen, + ob sich die Situation gegenüber Gate 1 verändert hat (z.B. + unerwarteter Personalabgang, Priorisierungsänderungen). + werte: + - "bestaetigt" + - "mit_auflagen" + - "nicht_bestaetigt" + referenz: "AP-02, G3-DIM-04" + abgrenzung_gate_1: | + Gate 1: Grundsätzliches Commitment ("Wir können/wollen diesen Service übernehmen") + Gate 3: Operatives Commitment ("Wir sind JETZT bereit für die Übernahme") + + - name: "pruefung_auflagen_gate_2" + typ: "enum" + pflicht: true + beschreibung: "Auflagen aus Gate 2 erfüllt? (Showstopper wenn vorhanden)" + werte: + - "erfuellt" + - "nicht_erfuellt" + - "keine_auflagen" + referenz: "AP-02, G3-DIM-05" + + # --- Formalia --- + - name: "so_bestaetigung_durch_sor" + typ: "boolean" + pflicht: true + beschreibung: "SO wurde durch SOR formal bestätigt" + referenz: "GOV-TR-004" + + # --- Auflagen --- + - name: "auflagen" + typ: "text" + pflicht: false + beschreibung: "Auflagen bei 'go_live_mit_auflagen' (Gate 3)" + max_zeichen: 500 + + # --------------------------------------------------------------------------- + # ELS: EARLY LIFE SUPPORT + # --------------------------------------------------------------------------- + els: + beschreibung: "Dokumentation der ELS-Phase" + referenz: "AP-04" + + felder: + + - name: "start" + typ: "date" + pflicht: true + beschreibung: "ELS-Start (= Go-Live-Datum)" + + - name: "ende" + typ: "date" + pflicht: false + beschreibung: "ELS-Ende (Datum der SO-Entscheidung)" + + - name: "dauer_wochen" + typ: "integer" + pflicht: false + beschreibung: "Tatsächliche ELS-Dauer in Wochen (gerundet)" + hinweis: "Wird bei Abschluss berechnet" + + - name: "kritische_stoerungen_anzahl" + typ: "integer" + pflicht: true + beschreibung: "Anzahl kritischer Störungen während ELS" + default: 0 + referenz: "AP-04, Definition 'kritische Störung'" + + - name: "exit_begruendung" + typ: "text" + pflicht: true + beschreibung: "Begründung, warum Exit-Kriterien als erfüllt gelten" + max_zeichen: 500 + beispiel: "Keine kritischen Störungen seit 3 Wochen, Support-Aufkommen normalisiert." + + - name: "lessons_learned" + typ: "text" + pflicht: false + beschreibung: "Wesentliche Erkenntnisse für Service Review" + max_zeichen: 500 + mvp_hinweis: "Optional für MVP. Kann bei Bedarf verpflichtend werden." + + - name: "eskalation_erfolgt" + typ: "boolean" + pflicht: true + beschreibung: "Wurde an SOR eskaliert (bei Überschreitung Maximaldauer)?" + default: false + + - name: "eskalation_ergebnis" + typ: "text" + pflicht: false + beschreibung: "SOR-Entscheidung bei Eskalation" + max_zeichen: 300 + hinweis: "Nur ausfüllen wenn eskalation_erfolgt = true" + + # --------------------------------------------------------------------------- + # ABSCHLUSS-CHECKLISTE + # --------------------------------------------------------------------------- + abschluss_checkliste: + beschreibung: "Checkliste zur Sicherstellung der Vollständigkeit bei Abschluss" + referenz: "AP-07" + + mvp_hinweis: | + Für MVP als einfache Boolean-Checkliste. Kann später um + Nachweise/Referenzen pro Punkt erweitert werden. + + felder: + + - name: "gate_2_passiert" + typ: "boolean" + pflicht: true + beschreibung: "Gate 2 (Entry-Prüfung nach Build) wurde erfolgreich passiert" + + - name: "pilot_abgeschlossen" + typ: "boolean" + pflicht: true + beschreibung: "Pilot abgeschlossen (oder nicht erforderlich)" + + - name: "gate_3_passiert" + typ: "boolean" + pflicht: true + beschreibung: "Gate 3 (Go-Live-Freigabe) wurde erfolgreich passiert" + + - name: "els_abgeschlossen" + typ: "boolean" + pflicht: true + beschreibung: "ELS wurde abgeschlossen" + + - name: "service_im_katalog" + typ: "boolean" + pflicht: true + beschreibung: "Service ist im Katalog aktiviert" + + - name: "so_bestaetigt" + typ: "boolean" + pflicht: true + beschreibung: "SO wurde durch SOR bestätigt" + + - name: "dokumentation_vollstaendig" + typ: "boolean" + pflicht: true + beschreibung: "Betriebsdokumentation ist vollständig und implementiert" + + # --------------------------------------------------------------------------- + # SONDERFÄLLE: ABBRUCH / ROLLBACK + # --------------------------------------------------------------------------- + abbruch: + beschreibung: "Dokumentation bei Abbruch oder Rollback (nur bei negativem Ausgang)" + referenz: "AP-05" + + mvp_hinweis: | + Minimale Dokumentation für MVP. Detaillierte Abbruch-Analyse + kann bei Bedarf ergänzt werden. + + felder: + + - name: "abbruch_erfolgt" + typ: "boolean" + pflicht: true + beschreibung: "Wurde die Transition abgebrochen?" + default: false + + - name: "abbruch_zeitpunkt" + typ: "enum" + pflicht: false + beschreibung: "In welcher Phase erfolgte der Abbruch?" + werte: + - "vor_gate_2" + - "nach_gate_2" + - "waehrend_pilot" + - "vor_gate_3" + - "nach_gate_3" + - "waehrend_els" + + - name: "abbruch_typ" + typ: "enum" + pflicht: false + beschreibung: "Art des Abbruchs" + werte: + - "zurueckweisung" + - "rollback" + - "termination" + referenz: "AP-05" + + - name: "abbruch_begruendung" + typ: "text" + pflicht: false + beschreibung: "Begründung für den Abbruch" + max_zeichen: 500 + + - name: "entscheider" + typ: "string" + pflicht: false + beschreibung: "Wer hat den Abbruch entschieden (SO/SOR)" + + # --------------------------------------------------------------------------- + # META + # --------------------------------------------------------------------------- + meta: + beschreibung: "Metadaten zur Dokumentenverwaltung" + + felder: + + - name: "erstellt_von" + typ: "string" + pflicht: true + beschreibung: "Wer hat den Steckbrief angelegt" + + - name: "erstellt_am" + typ: "date" + pflicht: true + beschreibung: "Erstellungsdatum" + + - name: "letzte_aenderung_von" + typ: "string" + pflicht: false + beschreibung: "Wer hat zuletzt geändert" + + - name: "letzte_aenderung_am" + typ: "date" + pflicht: false + beschreibung: "Datum der letzten Änderung" + + - name: "ueberfuehrt_am" + typ: "date" + pflicht: false + beschreibung: "Datum der Überführung in Service-Steckbrief" + hinweis: "Wird bei Status 'abgeschlossen' gesetzt" + +# ============================================================================= +# MVP-ENTSCHEIDUNGEN UND ERWEITERUNGSPOTENTIAL +# ============================================================================= + +mvp_entscheidungen: + + beschreibung: | + Folgende Vereinfachungen wurden für den MVP getroffen. Sie können + basierend auf operativer Erfahrung angepasst werden. + + entscheidungen: + + - bereich: "Auflagen-Dokumentation" + mvp: "Freitext-Feld" + erweiterung: "Strukturierte Liste mit Auflagen-ID, Frist, Status, Verantwortlicher" + trigger: "Wenn Auflagen-Tracking systematisch nötig wird" + + - bereich: "Pilot-Scope" + mvp: "Freitext-Feld" + erweiterung: "Strukturiert: Nutzergruppe, Funktionsumfang, Erfolgskriterien, Exit-Kriterien" + trigger: "Wenn Pilots häufiger und komplexer werden" + + - bereich: "Abschluss-Checkliste" + mvp: "Boolean-Felder" + erweiterung: "Pro Punkt: Nachweis-Referenz, Datum, Prüfer" + trigger: "Wenn Audit-Anforderungen steigen" + + - bereich: "Kritische Störungen" + mvp: "Nur Anzahl" + erweiterung: "Liste mit Incident-IDs, Datum, Kurzbeschreibung" + trigger: "Wenn Detailanalyse für Service Review nötig wird" + + - bereich: "Transition-Typ" + mvp: "neuer_service | wesentliche_aenderung" + erweiterung: "Differenzierung nach Service-Kategorie (Basis, Standard, Premium)" + trigger: "Wenn Portfolio-Vielfalt zunimmt" + + - bereich: "Versionierung" + mvp: "Keine explizite Versionierung des Steckbriefs" + erweiterung: "Änderungshistorie mit Version, Datum, Autor, Änderung" + trigger: "Wenn Nachvollziehbarkeit von Änderungen relevant wird" + +# ============================================================================= +# VALIDIERUNGSREGELN +# ============================================================================= + +validierung: + + beschreibung: | + Regeln zur Konsistenzprüfung. Können bei Tool-Implementierung + genutzt werden. + + regeln: + + - regel: "Gate-2-Vollständigkeit" + bedingung: "status != 'angelegt'" + pruefung: "gate_2.datum UND gate_2.entscheidung müssen gesetzt sein" + + - regel: "Pilot-Konsistenz" + bedingung: "gate_2.pilot_erforderlich = true" + pruefung: "pilot.status muss != 'nicht_erforderlich' sein" + + - regel: "Gate-3-nach-Gate-2" + bedingung: "gate_3.datum ist gesetzt" + pruefung: "gate_2.entscheidung muss 'freigabe' oder 'freigabe_mit_auflagen' sein" + + - regel: "ELS-nach-Gate-3" + bedingung: "els.start ist gesetzt" + pruefung: "gate_3.entscheidung muss 'go_live' oder 'go_live_mit_auflagen' sein" + + - regel: "Abschluss-Vollständigkeit" + bedingung: "status = 'abgeschlossen'" + pruefung: "Alle Felder in abschluss_checkliste müssen true sein" + + - regel: "Abbruch-Dokumentation" + bedingung: "abbruch.abbruch_erfolgt = true" + pruefung: "abbruch.abbruch_zeitpunkt UND abbruch.abbruch_begruendung müssen gesetzt sein" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.3" + datum: "2026-01-30" + aenderung: | + Präzisierung Ressourcen-Commitment: Klarstellung der Zwei-Stufen-Prüfung. + - Gate 1 (tr_01) prüft grundsätzliches Commitment (in service-lifecycle_transition.yaml) + - Gate 3 prüft operatives Commitment (Beschreibung präzisiert) + Hintergrund: Ressourcenfrage muss VOR Transition geklärt sein, um + Ressourcenverschwendung zu vermeiden. + autor: "DIGITOM-Projekt" + referenz: "Konzeptionelle Überprüfung Ressourcenprüfung" + + - version: "0.3" + datum: "2026-02-18" + aenderung: "Gate 1 in Transition verschoben (tr_01). Gate-IDs aktualisiert: Gate 2 = tr_09, Gate 3 = tr_12. Transition-Steckbrief dokumentiert nun alle 3 Gates." + autor: "DIGITOM-Projekt" + referenz: "service-lifecycle_transition.yaml v2.0" + + - version: "0.2" + datum: "2026-01-30" + aenderung: "Anpassung an Service-Lifecycle 3.0 (5-Phasen-Konsolidierung): Gate-Nummerierung auf globale Nummerierung umgestellt (Gate 2 = tr_08, Gate 3 = tr_11). Terminologie aktualisiert (Design-Phase statt Service-Entwicklung)." + autor: "DIGITOM-Projekt" + referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0" + + - version: "0.1" + datum: "2025-12-17" + aenderung: "Initiale Schema-Definition (MVP)" + autor: "DIGITOM-Projekt" referenz: "AP-07, GOV-TR-018" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/06_template_ola-kategorie-i.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/06_template_ola-kategorie-i.yaml index 6bcd6ee..d1af1e5 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/06_template_ola-kategorie-i.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/06_template_ola-kategorie-i.yaml @@ -1,165 +1,165 @@ -# ============================================================================= -# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I) -# ============================================================================= -# -# Version: 1.0 -# Datum: 2026-03-09 -# Status: Entwurf (Pilotphase) -# Autor: DIGITOM-Projekt -# Governance: GOV-SPM-I-002 -# -# Zweck: -# Vorlage zur Erstellung eines Operational Level Agreements (OLA) für -# Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase -# befüllt, wenn operative Erfahrungswerte vorliegen. -# -# Abgrenzung: -# - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C) -# - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I) -# -# ============================================================================= - -# ----------------------------------------------------------------------------- -# 1. IDENTIFIKATION -# ----------------------------------------------------------------------------- - -identifikation: - ola_id: "" # z.B. "OLA-INT-001" - ola_titel: "" # z.B. "OLA Active Directory Services" - version: "" # z.B. "1.0" - status: "" # Entwurf | Aktiv | In Review | Außer Kraft - erstellungsdatum: "" # YYYY-MM-DD - letzte_aktualisierung: "" # YYYY-MM-DD - naechster_review: "" # YYYY-MM-DD - - service_referenz: - service_name: "" # Name des Internen Services - service_id: "" # ID gemäß Service-Definition - service_kategorie: "I" # Immer "I" für Interne Services - service_owner: "" # Name / Rolle - -# ----------------------------------------------------------------------------- -# 2. VERTRAGSPARTEIEN (INTERN) -# ----------------------------------------------------------------------------- - -vertragsparteien: - - liefernde_einheit: - name: "" # z.B. "Team Infrastruktur" - verantwortlich: "" # Name / Rolle des Ansprechpartners - kontakt: "" # E-Mail / Telefon - - nutzende_einheiten: - - name: "" # z.B. "Team Applikationsbetrieb" - verantwortlich: "" - kontakt: "" - abhängige_kundenservices: # Welche Kategorie A/B/C-Services hängen davon ab? - - "" - - hinweis: | - Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden. - Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices - (Kategorie A/B/C) vom Internen Service abhängen. - -# ----------------------------------------------------------------------------- -# 3. LEISTUNGSBESCHREIBUNG -# ----------------------------------------------------------------------------- - -leistungsbeschreibung: - - kurzbeschreibung: "" # 2-3 Sätze: Was leistet der Service? - - leistungsumfang: - enthalten: - - "" # Auflistung der enthaltenen Leistungen - nicht_enthalten: - - "" # Explizite Ausschlüsse - - betriebszeiten: - regulaer: "" # z.B. "Mo-Fr 07:00-18:00" - erweitert: "" # z.B. "24/7 für kritische Systeme" - wartungsfenster: "" # z.B. "Sonntag 02:00-06:00" - -# ----------------------------------------------------------------------------- -# 4. QUALITÄTSZIELE -# ----------------------------------------------------------------------------- - -qualitaetsziele: - - verfuegbarkeit: - zielwert: "" # z.B. "99,5 %" - messperiode: "" # z.B. "Kalendermonat" - messmethode: "" # z.B. "Monitoring-Tool X, Uptime-Berechnung" - ausnahmen: "" # z.B. "Geplante Wartung ausgenommen" - - performance: - - metrik: "" # z.B. "Antwortzeit Authentifizierung" - zielwert: "" # z.B. "< 200 ms (95. Perzentil)" - messmethode: "" - - kapazitaet: - aktuell: "" # z.B. "500 gleichzeitige Nutzer" - geplant: "" # z.B. "800 gleichzeitige Nutzer bis Q4/2026" - -# ----------------------------------------------------------------------------- -# 5. ESKALATIONSWEGE -# ----------------------------------------------------------------------------- - -eskalationswege: - - stufe_1: - beschreibung: "Operativer Kontakt" - verantwortlich: "" - reaktionszeit: "" # z.B. "30 Minuten während Betriebszeiten" - - stufe_2: - beschreibung: "Teamleitung / Service Owner" - verantwortlich: "" - reaktionszeit: "" - - stufe_3: - beschreibung: "Eskalation an SOR / Mission Board" - ausloeser: | - - Wiederholte Verfehlung der Qualitätsziele - - Cross-Service-Impact auf Kundenservices - referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)" - -# ----------------------------------------------------------------------------- -# 6. REVIEW-MECHANISMUS -# ----------------------------------------------------------------------------- - -review: - - review_zyklus: "" # z.B. "Halbjährlich" - naechster_review: "" # YYYY-MM-DD - review_teilnehmer: - - "" # Rollen / Namen - - aenderungsverfahren: | - Änderungen am OLA werden vom Service Owner des Internen Services - initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen - mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich - (vgl. GOV-SOR-006). - -# ----------------------------------------------------------------------------- -# 7. LAUFZEIT UND KÜNDIGUNG -# ----------------------------------------------------------------------------- - -laufzeit: - beginn: "" # YYYY-MM-DD - laufzeit: "" # z.B. "Unbefristet, jährlicher Review" - kuendigungsfrist: "" # z.B. "3 Monate zum Quartalsende" - kuendigungsbedingungen: | - Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den - Internen Service durch den SOR voraus (vgl. GOV-SOR-006). - -# ----------------------------------------------------------------------------- -# CHANGELOG -# ----------------------------------------------------------------------------- - -changelog: - - version: "1.0" - datum: "2026-03-09" - aenderung: "Erstfassung des OLA-Templates" - autor: "DIGITOM-Projekt" - referenz: "GOV-SPM-I-002, OQ-001" +# ============================================================================= +# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I) +# ============================================================================= +# +# Version: 1.0 +# Datum: 2026-03-09 +# Status: Entwurf (Pilotphase) +# Autor: DIGITOM-Projekt +# Governance: GOV-SPM-I-002 +# +# Zweck: +# Vorlage zur Erstellung eines Operational Level Agreements (OLA) für +# Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase +# befüllt, wenn operative Erfahrungswerte vorliegen. +# +# Abgrenzung: +# - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C) +# - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I) +# +# ============================================================================= + +# ----------------------------------------------------------------------------- +# 1. IDENTIFIKATION +# ----------------------------------------------------------------------------- + +identifikation: + ola_id: "" # z.B. "OLA-INT-001" + ola_titel: "" # z.B. "OLA Active Directory Services" + version: "" # z.B. "1.0" + status: "" # Entwurf | Aktiv | In Review | Außer Kraft + erstellungsdatum: "" # YYYY-MM-DD + letzte_aktualisierung: "" # YYYY-MM-DD + naechster_review: "" # YYYY-MM-DD + + service_referenz: + service_name: "" # Name des Internen Services + service_id: "" # ID gemäß Service-Definition + service_kategorie: "I" # Immer "I" für Interne Services + service_owner: "" # Name / Rolle + +# ----------------------------------------------------------------------------- +# 2. VERTRAGSPARTEIEN (INTERN) +# ----------------------------------------------------------------------------- + +vertragsparteien: + + liefernde_einheit: + name: "" # z.B. "Team Infrastruktur" + verantwortlich: "" # Name / Rolle des Ansprechpartners + kontakt: "" # E-Mail / Telefon + + nutzende_einheiten: + - name: "" # z.B. "Team Applikationsbetrieb" + verantwortlich: "" + kontakt: "" + abhängige_kundenservices: # Welche Kategorie A/B/C-Services hängen davon ab? + - "" + + hinweis: | + Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden. + Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices + (Kategorie A/B/C) vom Internen Service abhängen. + +# ----------------------------------------------------------------------------- +# 3. LEISTUNGSBESCHREIBUNG +# ----------------------------------------------------------------------------- + +leistungsbeschreibung: + + kurzbeschreibung: "" # 2-3 Sätze: Was leistet der Service? + + leistungsumfang: + enthalten: + - "" # Auflistung der enthaltenen Leistungen + nicht_enthalten: + - "" # Explizite Ausschlüsse + + betriebszeiten: + regulaer: "" # z.B. "Mo-Fr 07:00-18:00" + erweitert: "" # z.B. "24/7 für kritische Systeme" + wartungsfenster: "" # z.B. "Sonntag 02:00-06:00" + +# ----------------------------------------------------------------------------- +# 4. QUALITÄTSZIELE +# ----------------------------------------------------------------------------- + +qualitaetsziele: + + verfuegbarkeit: + zielwert: "" # z.B. "99,5 %" + messperiode: "" # z.B. "Kalendermonat" + messmethode: "" # z.B. "Monitoring-Tool X, Uptime-Berechnung" + ausnahmen: "" # z.B. "Geplante Wartung ausgenommen" + + performance: + - metrik: "" # z.B. "Antwortzeit Authentifizierung" + zielwert: "" # z.B. "< 200 ms (95. Perzentil)" + messmethode: "" + + kapazitaet: + aktuell: "" # z.B. "500 gleichzeitige Nutzer" + geplant: "" # z.B. "800 gleichzeitige Nutzer bis Q4/2026" + +# ----------------------------------------------------------------------------- +# 5. ESKALATIONSWEGE +# ----------------------------------------------------------------------------- + +eskalationswege: + + stufe_1: + beschreibung: "Operativer Kontakt" + verantwortlich: "" + reaktionszeit: "" # z.B. "30 Minuten während Betriebszeiten" + + stufe_2: + beschreibung: "Teamleitung / Service Owner" + verantwortlich: "" + reaktionszeit: "" + + stufe_3: + beschreibung: "Eskalation an SOR / Mission Board" + ausloeser: | + - Wiederholte Verfehlung der Qualitätsziele + - Cross-Service-Impact auf Kundenservices + referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)" + +# ----------------------------------------------------------------------------- +# 6. REVIEW-MECHANISMUS +# ----------------------------------------------------------------------------- + +review: + + review_zyklus: "" # z.B. "Halbjährlich" + naechster_review: "" # YYYY-MM-DD + review_teilnehmer: + - "" # Rollen / Namen + + aenderungsverfahren: | + Änderungen am OLA werden vom Service Owner des Internen Services + initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen + mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich + (vgl. GOV-SOR-006). + +# ----------------------------------------------------------------------------- +# 7. LAUFZEIT UND KÜNDIGUNG +# ----------------------------------------------------------------------------- + +laufzeit: + beginn: "" # YYYY-MM-DD + laufzeit: "" # z.B. "Unbefristet, jährlicher Review" + kuendigungsfrist: "" # z.B. "3 Monate zum Quartalsende" + kuendigungsbedingungen: | + Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den + Internen Service durch den SOR voraus (vgl. GOV-SOR-006). + +# ----------------------------------------------------------------------------- +# CHANGELOG +# ----------------------------------------------------------------------------- + +changelog: + - version: "1.0" + datum: "2026-03-09" + aenderung: "Erstfassung des OLA-Templates" + autor: "DIGITOM-Projekt" + referenz: "GOV-SPM-I-002, OQ-001" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/07_leitfaden_sieben-fragen-orientierung.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/07_leitfaden_sieben-fragen-orientierung.yaml index 1ec6eaf..c9dedb8 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/07_leitfaden_sieben-fragen-orientierung.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/07_leitfaden_sieben-fragen-orientierung.yaml @@ -1,186 +1,186 @@ -# ============================================================================= -# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN -# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente -# ============================================================================= -# -# Version: 1.0 -# Datum: 2026-03-09 -# Status: Final -# Autor: DIGITOM-Projekt -# Governance: GOV-SPM-I-005 -# -# Zweck: -# Dieser Leitfaden unterstützt die systematische Einordnung von -# Infrastruktur-Komponenten als Interne Services (Kategorie I) oder -# als passive Service-Komponenten. Er ist eine Orientierungshilfe, -# kein Automatismus – die finale Entscheidung trifft das SPM/SOR. -# -# Kontext: -# Mit der Einführung der Kategorie I (Interne Services) entsteht die -# Frage, welche Infrastruktur-Komponenten als eigenständige Governance- -# Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare -# Kriterien für diese Abgrenzung. -# -# ============================================================================= - -# ----------------------------------------------------------------------------- -# DIE SIEBEN FRAGEN -# ----------------------------------------------------------------------------- - -fragen: - - - nr: 1 - frage: "Gibt es einen identifizierbaren internen 'Kunden'?" - erlaeuterung: | - Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente - als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs- - beziehung (Lieferant → Nutzer)? - beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt" - beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit" - - - nr: 2 - frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?" - erlaeuterung: | - Kann eine Person oder Rolle die Gesamtverantwortung für Qualität, - Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist - diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle - abgrenzbar? - beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen" - beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung" - - - nr: 3 - frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?" - erlaeuterung: | - Können Verfügbarkeit, Performance oder andere Qualitätsmetriken - für diese Komponente eigenständig definiert und gemessen werden – - unabhängig von den darüberliegenden Kundenservices? - beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms" - beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele" - - - nr: 4 - frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?" - erlaeuterung: | - Wird die Komponente als Shared Service von mehr als einem - Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen - Mehrfachnutzungs-Charakter? - beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt" - beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service" - - - nr: 5 - frage: "Gibt es operative Steuerungsnotwendigkeit?" - erlaeuterung: | - Erfordert die Komponente regelmäßige operative Entscheidungen - (Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über - den normalen Betrieb hinausgehen? - beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform" - beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung" - - - nr: 6 - frage: "Ist die Komponente für Incident Management eigenständig relevant?" - erlaeuterung: | - Kann es Incidents geben, die primär dieser Komponente zugeordnet - werden und nicht sofort einem darüberliegenden Kundenservice? - Gibt es einen eigenen Incident-Kontext? - beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident" - beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet" - - - nr: 7 - frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?" - erlaeuterung: | - Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit - ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR) - vorzulegen – analog zur Stilllegung eines Kundenservices? - beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant" - beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung" - -# ----------------------------------------------------------------------------- -# AUSWERTUNGSSCHEMA -# ----------------------------------------------------------------------------- - -auswertung: - - schema: - - bereich: "5–7 × Ja" - ergebnis: "Interner Service (Kategorie I)" - beschreibung: | - Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale - eines eigenständigen Governance-Objekts und sollte als Interner - Service mit eigener Service-Definition geführt werden. - - - bereich: "3–4 × Ja" - ergebnis: "Grenzfall – Entscheidung durch SPM/SOR" - beschreibung: | - Die Komponente zeigt einige Service-Merkmale, aber nicht alle. - Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR - zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde) - und 2 (Owner-Rolle) haben dabei besonderes Gewicht. - - - bereich: "0–2 × Ja" - ergebnis: "Passive Service-Komponente" - beschreibung: | - Die Komponente ist ein Bestandteil eines übergeordneten Services - und wird nicht als eigenständiges Governance-Objekt geführt. - Sie erscheint ggf. als Abhängigkeit in der Service-Definition - des nutzenden Services. - - hinweis_grenzfaelle: | - Der Leitfaden ist eine Orientierungshilfe, kein Automatismus. - Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte - zusätzlich berücksichtigt werden: - - Strategische Bedeutung der Komponente für DIGIT - - Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?) - - Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?) - -# ----------------------------------------------------------------------------- -# ANWENDUNGSBEISPIEL -# ----------------------------------------------------------------------------- - -anwendungsbeispiel: - - komponente: "Active Directory Services" - - bewertung: - - frage_nr: 1 - antwort: "Ja" - begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst" - - frage_nr: 2 - antwort: "Ja" - begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen" - - frage_nr: 3 - antwort: "Ja" - begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar" - - frage_nr: 4 - antwort: "Ja" - begruendung: "Wird von >10 Kundenservices genutzt" - - frage_nr: 5 - antwort: "Ja" - begruendung: "Migration zu Entra ID erfordert strategische Steuerung" - - frage_nr: 6 - antwort: "Ja" - begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident" - - frage_nr: 7 - antwort: "Ja" - begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung" - - ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)" - -# ----------------------------------------------------------------------------- -# REFERENZEN -# ----------------------------------------------------------------------------- - -referenzen: - - "GOV-SPM-I-001: Einführung Kategorie I" - - "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept" - - "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)" - - "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR" - -# ----------------------------------------------------------------------------- -# CHANGELOG -# ----------------------------------------------------------------------------- - -changelog: - - version: "1.0" - datum: "2026-03-09" - aenderung: "Erstfassung als eigenständiges Arbeitsdokument" - autor: "DIGITOM-Projekt" - referenz: "GOV-SPM-I-005, OQ-003" +# ============================================================================= +# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN +# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente +# ============================================================================= +# +# Version: 1.0 +# Datum: 2026-03-09 +# Status: Final +# Autor: DIGITOM-Projekt +# Governance: GOV-SPM-I-005 +# +# Zweck: +# Dieser Leitfaden unterstützt die systematische Einordnung von +# Infrastruktur-Komponenten als Interne Services (Kategorie I) oder +# als passive Service-Komponenten. Er ist eine Orientierungshilfe, +# kein Automatismus – die finale Entscheidung trifft das SPM/SOR. +# +# Kontext: +# Mit der Einführung der Kategorie I (Interne Services) entsteht die +# Frage, welche Infrastruktur-Komponenten als eigenständige Governance- +# Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare +# Kriterien für diese Abgrenzung. +# +# ============================================================================= + +# ----------------------------------------------------------------------------- +# DIE SIEBEN FRAGEN +# ----------------------------------------------------------------------------- + +fragen: + + - nr: 1 + frage: "Gibt es einen identifizierbaren internen 'Kunden'?" + erlaeuterung: | + Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente + als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs- + beziehung (Lieferant → Nutzer)? + beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt" + beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit" + + - nr: 2 + frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?" + erlaeuterung: | + Kann eine Person oder Rolle die Gesamtverantwortung für Qualität, + Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist + diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle + abgrenzbar? + beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen" + beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung" + + - nr: 3 + frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?" + erlaeuterung: | + Können Verfügbarkeit, Performance oder andere Qualitätsmetriken + für diese Komponente eigenständig definiert und gemessen werden – + unabhängig von den darüberliegenden Kundenservices? + beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms" + beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele" + + - nr: 4 + frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?" + erlaeuterung: | + Wird die Komponente als Shared Service von mehr als einem + Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen + Mehrfachnutzungs-Charakter? + beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt" + beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service" + + - nr: 5 + frage: "Gibt es operative Steuerungsnotwendigkeit?" + erlaeuterung: | + Erfordert die Komponente regelmäßige operative Entscheidungen + (Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über + den normalen Betrieb hinausgehen? + beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform" + beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung" + + - nr: 6 + frage: "Ist die Komponente für Incident Management eigenständig relevant?" + erlaeuterung: | + Kann es Incidents geben, die primär dieser Komponente zugeordnet + werden und nicht sofort einem darüberliegenden Kundenservice? + Gibt es einen eigenen Incident-Kontext? + beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident" + beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet" + + - nr: 7 + frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?" + erlaeuterung: | + Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit + ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR) + vorzulegen – analog zur Stilllegung eines Kundenservices? + beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant" + beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung" + +# ----------------------------------------------------------------------------- +# AUSWERTUNGSSCHEMA +# ----------------------------------------------------------------------------- + +auswertung: + + schema: + - bereich: "5–7 × Ja" + ergebnis: "Interner Service (Kategorie I)" + beschreibung: | + Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale + eines eigenständigen Governance-Objekts und sollte als Interner + Service mit eigener Service-Definition geführt werden. + + - bereich: "3–4 × Ja" + ergebnis: "Grenzfall – Entscheidung durch SPM/SOR" + beschreibung: | + Die Komponente zeigt einige Service-Merkmale, aber nicht alle. + Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR + zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde) + und 2 (Owner-Rolle) haben dabei besonderes Gewicht. + + - bereich: "0–2 × Ja" + ergebnis: "Passive Service-Komponente" + beschreibung: | + Die Komponente ist ein Bestandteil eines übergeordneten Services + und wird nicht als eigenständiges Governance-Objekt geführt. + Sie erscheint ggf. als Abhängigkeit in der Service-Definition + des nutzenden Services. + + hinweis_grenzfaelle: | + Der Leitfaden ist eine Orientierungshilfe, kein Automatismus. + Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte + zusätzlich berücksichtigt werden: + - Strategische Bedeutung der Komponente für DIGIT + - Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?) + - Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?) + +# ----------------------------------------------------------------------------- +# ANWENDUNGSBEISPIEL +# ----------------------------------------------------------------------------- + +anwendungsbeispiel: + + komponente: "Active Directory Services" + + bewertung: + - frage_nr: 1 + antwort: "Ja" + begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst" + - frage_nr: 2 + antwort: "Ja" + begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen" + - frage_nr: 3 + antwort: "Ja" + begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar" + - frage_nr: 4 + antwort: "Ja" + begruendung: "Wird von >10 Kundenservices genutzt" + - frage_nr: 5 + antwort: "Ja" + begruendung: "Migration zu Entra ID erfordert strategische Steuerung" + - frage_nr: 6 + antwort: "Ja" + begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident" + - frage_nr: 7 + antwort: "Ja" + begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung" + + ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)" + +# ----------------------------------------------------------------------------- +# REFERENZEN +# ----------------------------------------------------------------------------- + +referenzen: + - "GOV-SPM-I-001: Einführung Kategorie I" + - "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept" + - "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)" + - "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR" + +# ----------------------------------------------------------------------------- +# CHANGELOG +# ----------------------------------------------------------------------------- + +changelog: + - version: "1.0" + datum: "2026-03-09" + aenderung: "Erstfassung als eigenständiges Arbeitsdokument" + autor: "DIGITOM-Projekt" + referenz: "GOV-SPM-I-005, OQ-003" diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml index ef7b240..f108320 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml @@ -1,1112 +1,1112 @@ -# ============================================================================= -# 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 +# ============================================================================= +# 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" \ No newline at end of file diff --git a/#02_service-portfolio-management/02.1_spm_konzepte/spm_governance-entscheidungen-log.yaml b/#02_service-portfolio-management/02.1_spm_konzepte/spm_governance-entscheidungen-log.yaml index bb7cae5..394980e 100644 --- a/#02_service-portfolio-management/02.1_spm_konzepte/spm_governance-entscheidungen-log.yaml +++ b/#02_service-portfolio-management/02.1_spm_konzepte/spm_governance-entscheidungen-log.yaml @@ -1,2550 +1,2550 @@ -governance_entscheidungen: - - - id: GOV-001 - datum: 2025-11-26 - quelle_modul: "P-02 Service Level Management" - - frage: "Wer verantwortet und entscheidet die Service-Kategorisierung (A/B/C)?" - - entscheidung: | - - Responsible: Service-Portfolio-Manager - - Accountable: Mission Board (Freigabe) - - begründung: | - Die Kategorisierung hat strukturelle Implikationen für Governance - (welches Gremium, welcher SLA-Typ). Das ist eine taktische - Portfolio-Entscheidung, keine operative SLM-Frage. Das Mission Board - als taktisches Entscheidungsgremium (AL + Abteilungsleiter) ist - die richtige Ebene. - - auswirkung_auf: - - dokument: "G-01 Portfolio Governance" - abschnitt: "Entscheidungsmatrix" - - dokument: "R-02 Service-Portfolio-Manager" - abschnitt: "Verantwortlichkeiten" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: GOV-002 - datum: 2025-11-26 - quelle_modul: "P-02 Service Level Management" - - frage: "Was ist der Eskalations- und Sanktionsmechanismus bei SLA-Verletzungen?" - - entscheidung: | - 1. Service Owner identifiziert systematische SLA-Verletzung - 2. Eskalation ins Mission Board - 3. Mission Board definiert gemeinsam mit Service Owner - verpflichtende Verbesserungsmaßnahmen - 4. Kommunikation an Usergroup und via SLS-Update - 5. Ultima Ratio: Sichtbarkeit auf OB-Ebene (Standing des Amtsleiters) - - begründung: | - Kein vertraglicher Sanktionsmechanismus (unrealistisch im - Verwaltungskontext), aber klare Governance-Konsequenz: - Verpflichtende Verbesserung mit Accountability auf - Amtsleitungsebene. - - auswirkung_auf: - - dokument: "G-01 Portfolio Governance" - abschnitt: "Eskalationswege" - - dokument: "G-02 SOR Geschäftsordnung" - abschnitt: "Schnittstelle zu Mission Board" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: GOV-003 - datum: 2025-11-26 - quelle_modul: "P-02 Service Level Management" - - frage: "Wie verhält sich der interne Service Review zum externen SLA Review?" - - entscheidung: | - Zwei-Stufen-Logik: - 1. Interner Service Review (Blueprint sr_02): - Service Owner → SOR → ggf. Mission Board - = Vorbereitung und interne Abstimmung - - 2. Externer SLA Review (neu zu modellieren): - Service Owner → Usergroup/Kunden-Gremium - = Kommunikation, Validierung, SLA-Anpassung - - begründung: | - Trennung von interner Steuerung (was können/wollen wir liefern?) - und externer Abstimmung (was brauchen die Kunden?). Der interne - Review ist Voraussetzung für den externen – nicht umgekehrt. - - auswirkung_auf: - - dokument: "B-03 service_review.yaml" - abschnitt: "Neue Aktivität: SLA Review mit Kunden" - - dokument: "P-02 Service Level Management" - abschnitt: "Review-Aktivitäten" - - status: "final" - - offene_fragen: - - "Modellierung der neuen Aktivität im Blueprint" - - # --------------------------------------------------------------------------- - - - id: GOV-004 - datum: 2025-11-26 - quelle_modul: "P-02 Service Level Management" - - frage: "Wer ist der SLA-Partner für Kategorie-A-Services (Basisversorgung)?" - - entscheidung: | - Konzeptionelle Anforderung an ein "Kundengremium Basisversorgung": - - 1. Repräsentiert die Kundenperspektive der Gesamtverwaltung - 2. Ist SLA-fähig (Entscheidungskompetenz für Leistungsvereinbarungen) - 3. Strukturvorschlag: - - Pflichtvertreter: Querschnittsämter (z.B. HPA, ggf. weitere) - - Wechselnde Vertreter: Rotation aus Fachämtern/Dezernaten - 4. Folgt der Usergroup-Logik (analog Kategorie B) - - Finale Besetzung und Verankerung: - Abstimmung mit Verwaltungsführung erforderlich. - - begründung: | - Konsistente Governance-Logik über alle Service-Kategorien: - Auch Kategorie A hat eine Usergroup – nur mit besonderer - Zusammensetzung wegen des Querschnittscharakters. - Pflichtvertreter sichern Kontinuität, wechselnde Vertreter - sichern Repräsentativität. - - auswirkung_auf: - - dokument: "G-01 Portfolio Governance" - abschnitt: "SLA-Partnerstruktur" - - dokument: "Konzept SLA/SLM" - abschnitt: "Gremienstruktur Kategorie A" - - status: "draft" # Finale Abstimmung mit Verwaltung ausstehend - - offene_fragen: - - "Welche Ämter sind 'Pflichtvertreter'?" - - "Rotationslogik für wechselnde Vertreter?" - - "Organisatorische Verankerung (wo angesiedelt)?" - - # --------------------------------------------------------------------------- - - - id: GOV-005 - datum: 2025-11-26 - quelle_modul: "P-02 Service Level Management" - - frage: "Wer darf als SLA-Partner für Kundenseite agieren?" - - entscheidung: | - SLA-Partner auf Kundenseite müssen Entscheidungsbefugnis haben: - - 1. Grundsatz: Amtsleiter:in des nutzenden Amtes - 2. Alternative: Explizit delegierte Person mit dokumentierter - Entscheidungsbefugnis (z.B. Abteilungsleiter:in, - Verwaltungsleiter:in des Amtes) - - Für Kategorie A und B gilt: - - Mitglieder der Kundenvertretung sind Amtsleitungen oder - deren delegierte Vertreter:innen - - Die Delegation muss dokumentiert sein - - Die Kundenvertretung ist kein "Anwenderforum", sondern - ein Entscheidungsgremium - - Terminologie: - - Kategorie A: "Kundenvertretung Basisservices" - - Kategorie B: "Kundenvertretung [Servicename]" - - Kategorie C: "Amtsleitung [Amt]" (bilateral) - - begründung: | - SLAs sind Governance-Instrumente, keine Nutzerfeedback-Runden. - Nur wer Entscheidungsbefugnis hat, kann verbindliche - Leistungsvereinbarungen abschließen. Die Delegation ermöglicht - Flexibilität, ohne die Legitimation zu untergraben. - - auswirkung_auf: - - dokument: "P-02 Service Level Management" - abschnitt: "Kernkonzepte, alle Aktivitäten mit SLA-Partner" - - dokument: "G-01 Portfolio Governance" - abschnitt: "SLA-Partnerstruktur" - - dokument: "Konzept SLA/SLM (Ideenskizze)" - abschnitt: "Abschnitte 4 und 6" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: GOV-006 - datum: 2025-11-27 - quelle_modul: "P-01 Service Catalog Management" - - frage: "Wer ist Practice Owner für Service Catalog Management?" - - entscheidung: | - Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM. - Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden. - - begruendung: | - SPM und SCM operieren beide auf Portfolio-Ebene und haben - natürliche Nähe. Eine Trennung ist langfristig möglich, - aber für die Einführungsphase nicht nötig. Die Konsolidierung - reduziert Komplexität bei der Einführung rollenbasierten Arbeitens. - - auswirkung_auf: - - dokument: "P-01 Service Catalog Management" - abschnitt: "metadata.practice_owner" - - dokument: "R-02 Service-Portfolio-Manager" - abschnitt: "Verantwortlichkeiten" - - dokument: "G-01 Portfolio Governance" - abschnitt: "Rollenübersicht" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-007 - datum: 2025-11-27 - quelle_modul: "P-01 Service Catalog Management" - - frage: "Wer erstellt die Service-Definition?" - - entscheidung: | - Der Service Owner ist verantwortlich (Accountable) für die Erstellung - der Service-Definition. SPM validiert und gibt frei. - - RACI: - - Service-Definition erstellen: SO (A/R), SPM (C) - - Service-Definition validieren: SPM (A/R), SO (C) - - Katalogeintrag freigeben: SPM (A) oder SOR (A) je nach Änderungstyp - - begruendung: | - ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung - für den Service. Die Service-Definition ist Teil dieser Verantwortung. - SCM stellt Methodik, Templates und Qualitätssicherung bereit, - aber die inhaltliche Verantwortung liegt beim SO. - - auswirkung_auf: - - dokument: "P-01 Service Catalog Management" - abschnitt: "aktivitaeten_transition" - - dokument: "R-01 Service Owner" - abschnitt: "Verantwortlichkeiten" - - dokument: "02.5_informationsmodell/spm_schema_service-definition.yaml" - abschnitt: "schema.verantwortung" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-008 - datum: 2025-11-27 - quelle_modul: "P-01 Service Catalog Management" - - frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?" - - entscheidung: | - Dreistufige Governance nach Impact: - - 1. Redaktionelle Änderungen: - - Beispiele: Tippfehler, Telefonnummer, Formatierung - - Entscheidung: Service Owner (autonom) - - Keine separate Freigabe nötig - - 2. Inhaltlich-minor: - - Beispiele: FAQ-Link, Klarstellung ohne Änderung, neue Doku-Referenz - - Entscheidung: Service Owner + SPM (bilateral) - - Freigabe: SPM - - 3. Inhaltlich-major / Neuaufnahme: - - Beispiele: Leistungsumfang, Service Levels, Zielgruppe - - Entscheidung: SOR - - Freigabe: SOR - - 4. Strukturell (Sonderfall): - - Beispiele: Kategorie-Wechsel, Stilllegung - - Entscheidung: Mission Board - - begruendung: | - Vermeidet Überlastung des SOR/MB mit Kleinstthemen. - Operative Themen werden operativ gelöst. Nur portfolio-relevante - Entscheidungen eskalieren. Die Logik entspricht dem Subsidiaritätsprinzip - und spiegelt die Änderungs-Governance in P-02 SLM. - - auswirkung_auf: - - dokument: "P-01 Service Catalog Management" - abschnitt: "aktivitaeten_betrieb.scm_05" - - dokument: "G-01 Portfolio Governance" - abschnitt: "Entscheidungsmatrix" - - dokument: "G-02 SOR Geschäftsordnung" - abschnitt: "Entscheidungsgegenstände" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-009 - datum: 2025-11-27 - quelle_modul: "P-01 Service Catalog Management" - - frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?" - - entscheidung: | - SHM wird eingebunden für die Prüfung der Kundenverständlichkeit - von Service-Steckbriefen. - - Im MVP ist dies optional (Empfehlung), da das SHM-Modul noch - in Entwicklung ist. - - Prozess: - - SO erstellt Service-Steckbrief - - SPM prüft Schema-Konformität und Konsistenz - - SHM prüft Kundenverständlichkeit (optional im MVP) - - SPM gibt frei - - begruendung: | - SHM hat die Kompetenz für Kundenperspektive und -sprache. - Die Einbindung vermeidet IT-zentrische Formulierungen und - erhöht die Akzeptanz des Katalogs bei den Ämtern. - Die Schnittstelle sollte etabliert werden, sobald SHM operativ ist. - - auswirkung_auf: - - dokument: "P-01 Service Catalog Management" - abschnitt: "aktivitaeten_transition.scm_02" - - dokument: "SHM Funktionsbeschreibung" - abschnitt: "3.2 Bedarfsaufbereitung und Routing" - - status: "draft" - - abhaengig_von: - - "Finalisierung SHM-Modul" - - offene_fragen: - - "Konkrete Qualitätskriterien für Verständlichkeit definieren" - - "Prüfprozess in SHM-Workflow integrieren" - - # --------------------------------------------------------------------------- - - id: GOV-010 - datum: 2025-11-27 - quelle_modul: "P-01 Service Catalog Management" - - frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?" - - entscheidung: | - Trennung von Inhalt und Betrieb: - - - SCM (SPM) verantwortet den INHALT des Katalogs - (Was steht drin? Ist es aktuell? Ist es korrekt?) - - - Der BETRIEB des Publikationskanals ist eine separate Verantwortung - (Webteam, IT-Betrieb, Kommunikation – je nach Kanal) - - Im MVP ist die konkrete Zuordnung noch zu klären. - - begruendung: | - SCM ist ein Managementprozess, kein Portal-Betrieb. - Die Vermischung würde SCM mit technischen Betriebsaufgaben - überfrachten und von der eigentlichen Aufgabe (Informations-Governance) - ablenken. Die Trennung ermöglicht auch verschiedene Publikationskanäle - (Intranet, ITSM-Tool, PDF) ohne SCM-Prozessänderung. - - auswirkung_auf: - - dokument: "P-01 Service Catalog Management" - abschnitt: "kernkonzepte.service_katalog.publikationskanaele" - - dokument: "G-01 Portfolio Governance" - abschnitt: "Verantwortungsmatrix" - - status: "draft" - - offene_fragen: - - "Wer ist konkret für Portal-Betrieb zuständig?" - - "Welcher Kanal wird primär verwendet (Intranet, Self-Service-Portal)?" - - "Wie erfolgt die Synchronisation mit ITSM-Tool?" - - # --------------------------------------------------------------------------- - - id: GOV-011 - datum: 2025-12-03 - quelle_modul: "SPM / SHM Harmonisierung" - - frage: | - Wie soll die Service-Kategorie B benannt werden, um terminologische - Konsistenz zwischen SPM (Service-Perspektive) und SHM (Amt-Perspektive) - herzustellen? - - entscheidung: | - Umbenennung von "Modular-Services" zu "Erweiterte Services" (Kategorie B). - - Begründung der Begriffswahl: - - "Modular" beschreibt die technische Architektur (zubuchbar, kombinierbar) - - "Erweitert" beschreibt die Beziehung zum Basis-Level - - "Erweitert" funktioniert für beide Perspektiven: - * SPM: Service erweitert die Basis-Ausstattung - * SHM: Amt hat erweiterte Anforderungen über Basis hinaus - - Die drei Kategorien heißen nun konsistent: - - Kategorie A: Basis-Services / Basis-Profil - - Kategorie B: Erweiterte Services / Erweitertes Profil - - Kategorie C: Spezial-Services / Spezial-Profil - - begruendung: | - Terminologische Konsistenz zwischen SPM und SHM reduziert - Begriffsverwirrung und ermöglicht einheitliche Kommunikation - über Funktionsgrenzen hinweg. - - auswirkung_auf: - - dokument: "P-02 Service Level Management" - abschnitt: "kernkonzepte.service_kategorien" - - dokument: "P-01 Service Catalog Management" - abschnitt: "kategorien_logik, katalog_views" - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "identitaet.service_kategorie" - - dokument: "readme_spm_vorgehen-entwicklung-spm-mvp-konzept.md" - abschnitt: "Arbeitsmaterialien" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-012 - datum: 2025-12-09 - quelle_modul: "P-02 Service Level Management + SHM Engagement-Framework" - - frage: | - Wie werden die Kundenvertretungen (SLM) mit den - Stakeholder-Management-Formaten (SHM) koordiniert? - - entscheidung: | - Integration zu einem "Kundenforum"-Konzept: - - Die Kundenvertretungen nach P-02 werden mit den SHM-Formaten - zusammengeführt. Das Kundenforum erfüllt beide Funktionen: - - SLA-Abstimmung und Review (SLM-Verantwortung) - - Beziehungspflege und Bedarfssammlung (SHM-Verantwortung) - - Die Governance-Kompetenz für SLA-Entscheidungen bleibt unverändert. - - begruendung: | - Konsistenz der Kundeninteraktion: Ein Gremium statt paralleler - Formate mit denselben Teilnehmern. Reduziert Aufwand für - Ämter und DIGIT, stärkt gemeinsame Außenwirkung. - - auswirkung_auf: - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "kundenvertretung" - - dokument: "shm_engagement-framework.yaml" - abschnitt: "kollektive_formate" - - status: "final" - - verweis: "GOV-SHM-015 (SHM-Governance-Log)" - -# =========================================================================== - # P-04/05/06 SERVICE-SUPPORT-MANAGEMENT (SSM) - # =========================================================================== - - - id: SSM-G-01 - datum: 2025-12-07 - quelle_modul: "Service-Support-Management / Klassifikation" - - frage: "Wer bestimmt die Priorität eines Tickets?" - - entscheidung: | - Service Desk (First Level) priorisiert nach verbindlicher - Impact-Urgency-Matrix. Eskalation bei Widerspruch an - Queue-Koordinator oder Teamleitung. - - Kunden können Dringlichkeit (Urgency) melden, aber nicht - die Priorität festlegen. Die Matrix ist nicht verhandelbar. - - begruendung: | - Aktuelle "4 low"-Monokultur verhindert sinnvolle Triage. - Regelbasierte Priorisierung ersetzt informelle Verhandlungen - und schafft Transparenz über Entscheidungsgrundlagen. - - auswirkung_auf: - - dokument: "ssm_klassifikation-priorisierung.yaml" - abschnitt: "grundprinzipien.autoritaet" - - dokument: "sub-practice_incident-management.yaml" - abschnitt: "Klassifikationsschritt (noch zu entwickeln)" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: SSM-G-02 - datum: 2025-12-07 - quelle_modul: "Service-Support-Management / Klassifikation" - - frage: "Ist die Impact-Urgency-Matrix verbindlich?" - - entscheidung: | - Die Impact-Urgency-Matrix ist verbindlich anzuwenden. - Abweichungen nur durch Queue-Koordinator oder Teamleitung - mit dokumentierter Begründung. - - begruendung: | - Nur verbindliche Anwendung schafft Vergleichbarkeit für - KPI-Auswertungen und verhindert subjektive Priorisierung. - Die Eskalationsmöglichkeit wahrt Flexibilität für Ausnahmen. - - auswirkung_auf: - - dokument: "ssm_klassifikation-priorisierung.yaml" - abschnitt: "governance.entscheidungen.KLASS-G-01" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: SSM-G-03 - datum: 2025-12-07 - quelle_modul: "Service-Support-Management / Klassifikation" - - frage: "Wie wird Explorative Diagnose legitimiert?" - - entscheidung: | - Analyse-Tickets legitimieren 90-120 Minuten Explorative - Diagnose. Voraussetzungen: - - Ticket ist als Charakteristik "ANALYSE" klassifiziert - - Dokumentation der Erkenntnisse ist verpflichtend - - Erkenntnisse werden in Wissensdatenbank überführt - - begruendung: | - Exploratives Arbeiten ist bei unbekannten Problemen notwendig - und fördert systematisches Lernen. Ohne explizite Legitimation - entsteht Rechtfertigungsdruck, der zu oberflächlichen Lösungen führt. - Die Dokumentationspflicht verhindert Missbrauch. - - auswirkung_auf: - - dokument: "ssm_klassifikation-priorisierung.yaml" - abschnitt: "ticket_charakteristik.charakteristiken.ANALYSE.explorative_diagnose" - - dokument: "ssm_design-zieldimensionen.yaml" - abschnitt: "LS-02 (Rollenverständnis)" - - referenz: - - dokument: "Lösungssäulen-Vision" - abschnitt: "Säule 2: Rollenverständnis" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: SSM-G-04 - datum: 2025-12-07 - quelle_modul: "Service-Support-Management / Klassifikation" - - frage: "Wie werden Langläufer-Tickets behandelt?" - - entscheidung: | - Tickets mit Laufzeit >20 Arbeitstage werden als "Langläufer" - gekennzeichnet und aus operativen KPIs (MTTR, FCR) exkludiert. - - Optionen nach Kennzeichnung: - 1. Umklassifikation zu PROJEKT (Pool-Wechsel) - 2. Verbleib mit separater Auswertung - - Die Kennzeichnung erfolgt automatisch durch das System. - - begruendung: | - Langläufer verzerren operative Metriken massiv. Die aktuelle - MTTR ist nicht aussagekräftig, weil Pseudo-Projekte mit - Incidents vermischt werden. Die Exklusion schafft - vergleichbare Kennzahlen für den Regelbetrieb. - - auswirkung_auf: - - dokument: "ssm_klassifikation-priorisierung.yaml" - abschnitt: "umklassifikation, pool_modell.pools.POOL-PROJEKT" - - dokument: "ssm_kennzahlen.yaml" - abschnitt: "(noch zu entwickeln)" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: SSM-G-05 - datum: 2025-12-07 - quelle_modul: "Service-Support-Management / Klassifikation" - - frage: "Welche SLA-Ziele gelten für die Prioritätsstufen?" - - entscheidung: | - Rahmenparameter für SLA-Ziele: - - | Prio | Reaktion | Lösung (Ziel) | Lösung (Max) | - |------|----------|---------------|--------------| - | P1 | 15 Min | 4h | 8h | - | P2 | 1h | 8h | 16h (2 AT) | - | P3 | 4h | 3 AT | 5 AT | - | P4 | 1 AT | 5 AT | 10 AT | - - Service-spezifische SLAs können abweichen; bei Abweichung - gilt die service-spezifische Vereinbarung. - - begruendung: | - Die Rahmenparameter schaffen einen Standard für den Fall, - dass kein service-spezifisches SLA existiert. Sie verhindern - willkürliche Erwartungshaltungen und ermöglichen messbare - Eskalationskriterien. - - auswirkung_auf: - - dokument: "ssm_klassifikation-priorisierung.yaml" - abschnitt: "prioritaetsstufen" - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "sla_typen (Referenz)" - - status: "draft" - - offene_fragen: - - "Abstimmung mit Service Owner für kritische Services" - - "Tool-Umsetzung der Eskalationstrigger" - - - id: "SSM-G-06" - name: "L1/L2-Grenzziehung" - entscheidung: | - L1 bearbeitet Tickets, solange: - 1. Dokumentation (KB) die Lösung ermöglicht UND - 2. L1-Agent die erforderlichen Berechtigungen hat - - Zusätzlich: Bei Analyse-Tickets ist Explorative Diagnose - (90-120 Min) erlaubt. - - Eskalation an L2 ist legitim, wenn: - - Keine passende Dokumentation vorhanden - - Lösung erfordert Berechtigungen außerhalb L1-Scope - - Explorative Diagnose ausgeschöpft ohne Fortschritt - - Komplexität übersteigt dokumentierten L1-Scope - - Eskalation erfordert "Definition of Handover" (DoH): - - Was wurde versucht? - - Welche KB-Artikel konsultiert? - - Beobachtungen/Erkenntnisse - - Eskalationsgrund - status: "vorgeschlagen" - - - id: "SSM-G-07" - name: "Ticket-Ownership-Prinzip" - entscheidung: | - Wer ein Ticket annimmt, ist verantwortlich bis: - a) Ticket ist geschlossen, ODER - b) Übergabe wurde vom Empfänger akzeptiert - - Regeln: - - Tickets ohne Owner (Status NEU nach Annahme) sind verboten - - "Zurücklegen" (Rückgabe an Queue ohne Empfänger) ist verboten - - "Parken" (Status WARTEN_*) ist erlaubt mit Begründung - - Ausnahme: - - L1 → L2 Domain Pool: Keine explizite Akzeptanz erforderlich - (Pool-Verantwortung wird durch Queue-Koordinator gesteuert) - - L2 → L1 Rückgabe: Akzeptanz + Begründung erforderlich - - Nicht-Akzeptanz innerhalb 4h: Auto-Eskalation an Queue-Koordinator - status: "vorgeschlagen" - - # --------------------------------------------------------------------------- - - - id: "SSM-G-17" - name: "(Reserviert)" - datum: "2025-12-07" - quelle_modul: "-" - - frage: "-" - - entscheidung: | - Diese ID ist reserviert für zukünftige Governance-Entscheidungen - im Request-Management-Kontext. - - begruendung: "Nummerierungskonsistenz" - - status: "reserviert" - kategorie: "Request Management" - - # --------------------------------------------------------------------------- - - - id: "SSM-G-18" - name: "Keine dedizierte Problem-Manager-Rolle" - datum: "2025-12-07" - quelle_modul: "sub-practice_problem-management.yaml" - - frage: "Brauchen wir eine dedizierte Problem-Manager-Rolle?" - - entscheidung: | - Im MVP gibt es keine dedizierte Problem-Manager-Rolle. - Der Service Owner ist Process Owner für Problem Management - in seinem Service-Bereich. Operative Tätigkeiten können an - Second Level Agents delegiert werden. - - begruendung: | - Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs- - strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung - für die Service-Qualität. ITIL4 warnt explizit davor, Problem - Management als separate Funktion aufzubauen. - - auswirkung_auf: - - dokument: "sub-practice_problem-management.yaml" - abschnitt: "organisationsmodell" - - dokument: "ssm_rollen.yaml" - abschnitt: "service_owner, second_level_agent" - - status: "vorgeschlagen" - kategorie: "Rollenmodell" - - # --------------------------------------------------------------------------- - - - id: "SSM-G-19" - name: "Problem Management nur reaktiv im MVP" - datum: "2025-12-07" - quelle_modul: "sub-practice_problem-management.yaml" - - frage: "Welche Problem-Identifikationswege werden im MVP unterstützt?" - - entscheidung: | - Problem-Identifikation erfolgt im MVP ausschließlich reaktiv - aus dem Incident Management (nicht lösbare oder wiederkehrende - Incidents). Proaktive Problem-Identifikation (YaSM LP4.7.1) ist - nicht im Scope. - - begruendung: | - MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt - die Datenbasis (Incident-Trends, Monitoring-Integration). - Kann in späteren Ausbaustufen ergänzt werden. - - auswirkung_auf: - - dokument: "sub-practice_problem-management.yaml" - abschnitt: "aktivitaeten.PRB-01" - - status: "vorgeschlagen" - kategorie: "Scope" - - offene_fragen: - - "Ausbaustufe 2: Trend-Analyse und proaktive Identifikation?" - - # --------------------------------------------------------------------------- - - - id: "SSM-G-20" - name: "Known Errors als KB-Artikel" - datum: "2025-12-07" - quelle_modul: "sub-practice_problem-management.yaml" - - frage: "Wie werden Known Errors dokumentiert?" - - entscheidung: | - Known Errors werden als KB-Artikel mit speziellem Typ - (KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert. - Es wird keine separate Known Error Database (KEDB) geführt. - - begruendung: | - Integration in bestehendes Wissensmanagement, vermeidet - Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen - ohnehin in der KB – Known Errors werden so automatisch gefunden. - - auswirkung_auf: - - dokument: "sub-practice_problem-management.yaml" - abschnitt: "kernkonzepte.known_error" - - dokument: "ssm_wissensmanagement.yaml" - abschnitt: "known_error_artikel" - - status: "vorgeschlagen" - kategorie: "Wissensmanagement" - -# ============================================================================= -# TMP-BAUSTEIN: Governance-Entscheidungen Service Transition (AP-01 + AP-02) -# ============================================================================= -# Zur Integration in: spm_governance-entscheidungen-log.yaml -# Arbeitspakete: AP-01 Gate-Struktur, AP-02 Entscheidungskriterien -# Datum: 2025-12-17 -# ============================================================================= - -metadata: - beschreibung: > - Zusammenstellung aller Governance-Entscheidungen aus den Arbeitspaketen - AP-01 (Gate-Struktur) und AP-02 (Entscheidungskriterien) für die - Integration in das zentrale SPM Governance-Entscheidungs-Log. - - id_bereich: "GOV-TR-001 bis GOV-TR-012" - - referenzen: - ap_01: "[tmp]_ap-01_gate-struktur.yaml" - ap_02: "[tmp]_ap-02_entscheidungskriterien.yaml" - ziel: "spm_governance-entscheidungen-log.yaml" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-01: GATE-STRUKTUR -# ============================================================================= - -entscheidungen_ap_01: - - # --------------------------------------------------------------------------- - - id: GOV-TR-001 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Was ist ein 'Gate' im DIGITOM-Kontext?" - - entscheidung: | - Ein Gate ist ein formaler Entscheidungspunkt im Lifecycle, der kombiniert: - - Prüfkriterien (Was muss erfüllt sein?) - - Gate-Keeper (Wer entscheidet?) - - Entscheidungsoptionen (Welche Ergebnisse sind möglich?) - - Dokumentation (Wie wird die Entscheidung festgehalten?) - - begruendung: | - Ein Gate nur als Checkliste hat keine Steuerungswirkung – es wird zum - bürokratischen Durchwinken. Ein Gate nur als Entscheidung ohne Prüfkriterien - wird beliebig. Die Kombination stellt sicher, dass es objektive Kriterien - gibt UND jemand die Verantwortung für die Freigabe übernimmt. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates" - - dokument: "SPM Glossar" - abschnitt: "Gate-Definition" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-002 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Wie viele Gates hat die Service Transition und wer ist Gate-Keeper?" - - entscheidung: | - Zwei-Gate-Modell: - - Gate 1 "Entry Transition": Gate-Keeper ist Service Owner - - Gate 2 "Go-Live-Freigabe": Gate-Keeper ist Service Operations Runde (SOR) - - begruendung: | - Gate 1 ist eine operative Entscheidung des SO (fachlich-inhaltlich). - Gate 2 ist eine Governance-Entscheidung der SOR (Portfolio-Perspektive). - Die Trennung spiegelt die Verantwortungslogik: SO verantwortet den Service, - SOR verantwortet das Portfolio. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Entscheidungsgegenstände" - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Entscheidungsbefugnisse" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-003 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Für welche Service-Änderungen gilt die Gate-Struktur?" - - entscheidung: | - Major Changes erfordern eine einmalige SOR-Autorisierung. Die SOR entscheidet - in einem Schritt, ob der Major Change durchgeführt werden darf, und legt dabei - den Einstiegspunkt im Lifecycle fest. Nach der Autorisierung durchläuft der - Major Change den regulären Service-Lifecycle einschließlich der üblichen - Transition-Gates (inkl. Gate 3 für Go-Live). - - Die Gate-Struktur gilt für: - - Neue Services (erstmalige Aktivierung) - - Major Changes an bestehenden Services - - Minor Changes laufen über Change Enablement (Standard/Normal Change). - - Major-Kriterien: - - Änderung der Service-Definition (Scope, Zielgruppe, Kernfunktionalität) - - Änderung der SLA/SLO-Vereinbarungen - - Signifikante Architektur-Änderung - - DPM-Klassifizierung "komplex" oder "hochkomplex" - - begruendung: | - Die Gate-Struktur ist Governance-Overhead, der sich nur bei signifikanten - Veränderungen rechtfertigt. Für Minor Changes wäre das unverhältnismäßig. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Geltungsbereich" - - dokument: "P-03 Change Enablement" - abschnitt: "Major/Minor-Abgrenzung" - - status: "final" - - offene_punkte: - - "Major/Minor-Abgrenzung muss mit P-03 Change Enablement synchronisiert werden" - - # --------------------------------------------------------------------------- - - id: GOV-TR-004 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Wann muss ein Service Owner für einen neuen Service benannt sein?" - - entscheidung: | - Zweistufige Regelung: - - 1. Empfehlung: Frühzeitige Benennung bei/kurz nach Projektfreigabe - - SPM identifiziert und schlägt vor - - SO wird als Consulted in Projektentscheidungen eingebunden - - 2. Harter Constraint: Spätestens bei Gate 1 - - SO ist Gate-Keeper für Gate 1 - - Ohne SO kann Gate 1 nicht durchgeführt werden - - Formale Bestätigung: SOR bestätigt SO bei Gate 2 (Go-Live-Freigabe) - - Fallback: Bei fehlendem SO-Kandidaten eskaliert SPM an Abteilungsleitung - (spätestens 4 Wochen vor geplantem Gate 1) - - begruendung: | - Ein harter Constraint bei Projektfreigabe kann zum Bottleneck werden. - Die Empfehlung zur frühzeitigen Benennung bleibt, aber der unbedingte - Zwang liegt erst bei Gate 1. - - auswirkung_auf: - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Benennung und Bestätigung" - - dokument: "R-SPM Rollenbeschreibung" - abschnitt: "Mandat SO-Identifikation" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "SO-Bestätigung" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-005 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Welche Entscheidungsergebnisse sind an den Gates möglich?" - - entscheidung: | - Vierstufige Entscheidungsoptionen analog DSR-Verfahren: - - Gate 1 (SO): - - Freigabe - - Freigabe mit Auflagen - - Zurückweisung - - Eskalation an SOR - - Gate 2 (SOR): - - Go-Live-Freigabe - - Go-Live mit Auflagen - - Zurück an Transition - - Service-Ablehnung - - begruendung: | - Das DSR-Entscheidungsverfahren kennt bereits differenzierte Optionen. - Diese Logik auf die Gates zu übertragen schafft Konsistenz und reduziert - Lernaufwand. Die Vierstufigkeit ermöglicht differenzierte Steuerung – - besonders "Freigabe mit Auflagen" verhindert, dass kleine Mängel den - gesamten Prozess blockieren. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates / Entscheidungsoptionen" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Entscheidungsverfahren" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-006 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Wie ist die Verantwortungsübergabe PL → SO geregelt?" - - entscheidung: | - Modell "Überlappungszone mit differenzierter Accountability": - - - Projektphase (bis Gate 1): PL ist A/R, SO ist C (falls benannt) - - Überlappungszone (Gate 1 bis Gate 2): - - PL: A/R für Projekt-Deliverables - - SO: A/R für Service-Scope - - Betrieb (ab Gate 2): SO ist A/R, Projekt abgeschlossen - - Formaler Übergabepunkt: Mit positivem Gate 1 geht die Service-Accountability - auf den SO über. PL bleibt für Projekt-Deliverables verantwortlich bis - Projektabschluss (nach Gate 2, spätestens Ende ELS). - - begruendung: | - In der Transition-Phase gibt es eine Überlappung – das Projekt läuft - möglicherweise noch, aber der Service geht bereits Richtung Betrieb. - Klare Abgrenzung ist erforderlich, um Verantwortungslücken zu vermeiden. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Verantwortungsübergang" - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Accountability-Übernahme" - - dokument: "service-lifecycle_service-transition.yaml" - abschnitt: "RACI" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-007 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Ist der Pilot ein eigenständiges Gate?" - - entscheidung: | - Nein. Die Pilot-Entscheidung ist kein eigenständiges Gate, sondern ein - Routing innerhalb von Gate 1. - - Der SO prüft im Entry-Gate, ob ein Pilot erforderlich ist, und legt - ggf. die Pilot-Parameter fest. Der Pilot ist eine optionale Phase - zwischen Gate 1 und Gate 2. - - begruendung: | - Ein drittes Gate würde Overhead erzeugen. Die Pilot-Entscheidung ist - Teil der Entry-Prüfung – der SO kennt seinen Service und kann - einschätzen, ob ein Pilot nötig ist. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Pilot-Konzept" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-008 - datum: "2025-12-16" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" - - frage: "Ist ELS-Exit ein formales Gate?" - - entscheidung: | - Nein. Der Übergang von ELS in den Normalbetrieb ist kein formales Gate, - sondern eine SO-Entscheidung mit Orientierungsprinzipien. - - Der SO entscheidet, wann ELS endet, und dokumentiert dies im - Service-Steckbrief oder informiert die SOR. - - begruendung: | - Ein drittes Gate würde Overhead erzeugen. ELS ist eine - Stabilisierungsphase, deren Ende der SO am besten einschätzen kann. - Formale Governance ist hier nicht erforderlich. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - status: "final" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-02: ENTSCHEIDUNGSKRITERIEN -# ============================================================================= - -entscheidungen_ap_02: - - # --------------------------------------------------------------------------- - - id: GOV-TR-009 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" - - frage: "Wie werden die Gate-Kriterien gestaltet – prinzipienbasiert oder checklistenbasiert?" - - entscheidung: | - Prinzipienbasierter Ansatz für beide Gates (MVP). - - Grundsatz: "Informed Judgment statt mechanische Prüfung" - - Der Gate-Keeper trifft eine Gesamtbewertung auf Basis definierter - Prüfdimensionen. Die Dimensionen geben die Richtung vor, ohne jeden - Einzelfall vorab zu regeln. - - begruendung: | - Für den MVP ist ein prinzipienbasierter Ansatz angemessen. Detaillierte - Checklisten erzeugen Governance-Overhead ohne nachgewiesenen Mehrwert. - Die operative Erfahrung wird zeigen, wo Präzisierung nötig ist. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates / Prüfdimensionen" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-010 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" - - frage: "Welche Prüfdimensionen gelten für Gate 1 (Entry Transition)?" - - entscheidung: | - Drei Prüfdimensionen: - - 1. Übergabe-Vollständigkeit (Showstopper) - Kernfrage: "Liegt alles vor, was ich für die Transition brauche?" - - 2. Betriebsvorbereitung (kein Showstopper) - Kernfrage: "Sind Betrieb und Support informiert und vorbereitet?" - - 3. Pilot-Erfordernis (Routing-Entscheidung) - Kernfrage: "Braucht dieser Service einen Pilot vor Go-Live?" - - Nachweisform: Formlos, aber dokumentiert (kurze Notiz, E-Mail, Protokolleintrag) - - begruendung: | - Minimale Prüfdimensionen für den MVP. Nur Übergabe-Vollständigkeit ist - Showstopper, da ohne Artefakte keine sinnvolle Transition möglich ist. - Betriebsvorbereitung kann mit Auflagen nachgeholt werden. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Gate 1 / Prüfdimensionen" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-011 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" - - frage: "Welche Prüfdimensionen gelten für Gate 2 (Go-Live-Freigabe)?" - - entscheidung: | - Fünf Prüfdimensionen: - - 1. SO-Readiness-Bestätigung (Showstopper) - Kernfrage: "Hat der SO die Betriebsreife bestätigt?" - - 2. Betriebs-/Support-Dokumentation (Showstopper) - Kernfrage: "Ist die Dokumentation vorhanden UND implementiert?" - "Implementiert" bedeutet: verfügbar, bekannt, zugänglich - - 3. Portfolio-Passung (Showstopper) - Kernfrage: "Kein Widerspruch zu bestehenden Services?" - MVP-Interpretation: Minimale Prüfung (Variante A) - - 4. Ressourcen-Commitment (kein Showstopper) - Kernfrage: "Haben Betrieb und Support die Kapazität bestätigt?" - - 5. Auflagen aus Gate 1 (Showstopper, falls vorhanden) - Kernfrage: "Falls Auflagen existieren: Sind diese erfüllt?" - - Nachweisform: Teil des SOR-Protokolls - - begruendung: | - Gate 2 hat mehr Showstopper, da es die finale Freigabe für das - Portfolio ist. Insbesondere die Dokumentations-Dimension wurde - geschärft: "vorhanden" reicht nicht, "implementiert" ist erforderlich. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Gate 2 / Prüfdimensionen" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Go-Live-Entscheidung" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-012 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" - - frage: "Was bedeutet 'Portfolio-Passung' bei Gate 2?" - - entscheidung: | - Variante A (minimale Prüfung): - - "Kein Widerspruch zu bestehenden Services" – im Zweifel passt es. - - Kein aktiver Strategie-Fit-Nachweis erforderlich, nur Abwesenheit - von Konflikten. - - begruendung: | - Für den MVP ist eine niedrige Hürde angemessen. Governance-Overhead - gering halten. Variante B (aktive Strategie-Prüfung) macht Sinn, - wenn das Portfolio wächst und Priorisierungskonflikte entstehen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Gate 2 / Portfolio-Passung" - - status: "final" - -# ============================================================================= -# ZUSAMMENFASSUNG -# ============================================================================= - -zusammenfassung: - - anzahl_entscheidungen: 24 - - nach_arbeitspaket: - ap_01: 8 - ap_02: 4 - ap_03: 4 - ap_04: 5 - ap_05: 3 - ap_06: 4 - - nach_status: - final: 24 - draft: 0 - - offene_abhaengigkeiten: - - id: "GOV-TR-003" - abhaengigkeit: "Synchronisation mit P-03 Change Enablement (Major/Minor)" - - betroffene_module: - - "konzept_service-transition.yaml" - - "G-SOR Geschäftsordnung" - - "R-SO Rollenbeschreibung" - - "R-SPM Rollenbeschreibung" - - "service-lifecycle_service-transition.yaml (Blueprint)" - - "SPM Glossar" - - "P-03 Change Enablement" - -entscheidungen_ap_03: - - # --------------------------------------------------------------------------- - - id: GOV-TR-011 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" - - frage: "Nach welchem Verfahren entscheidet die SOR bei Gate 2?" - - entscheidung: | - Vereinfachtes Konsent-Verfahren: - - - Grundprinzip: Konsent (Beschluss gilt ohne schwerwiegenden Einwand) - - Bei Einwand: Vertagung, SO muss Vorlage überarbeiten - - Bei erneutem Einwand: SOR kann eskalieren (MB) oder ablehnen - - Kein Alternativzwang für einwendende Rolle - - Das Verfahren gilt für alle SOR-Entscheidungen (Gate 2, Routing, - Service-Anpassungen). - - begruendung: | - Gate-2-Entscheidungen sind operativ-taktisch. Das DSR-Konsent-Verfahren - mit iterativem Alternativzwang ist für Routinefreigaben überdimensioniert. - - Die Überarbeitungspflicht liegt beim SO (nicht bei der einwendenden Rolle), - weil der SO für den Service accountable ist. Das vereinfacht das Verfahren - und stärkt die SO-Verantwortung. - - auswirkung_auf: - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Entscheidungsverfahren" - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates / Gate 2" - - status: "final" - - abgrenzung_zu_dsr: | - Unterschied zur DSR-GO: Kein Alternativzwang, keine feste Iterationsgrenze. - Gemeinsamkeit: Konsent als Grundprinzip, Eskalation an MB möglich. - - # --------------------------------------------------------------------------- - - id: GOV-TR-012 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" - - frage: "Wie werden Auflagen bei 'Freigabe mit Auflagen' gehandhabt?" - - entscheidung: | - Protokoll-basiertes Tracking: - - 1. Formulierung: Gate-Keeper formuliert Auflagen (konkret, mit Frist, - mit Verantwortlichem) - - 2. Dokumentation: Im Gate-Protokoll (SOR-Protokoll für Gate 2) - - 3. Tracking: - - Gate-1-Auflagen: SO bestätigt Erfüllung in Gate-2-Vorlage, - SOR prüft bei Gate 2 - - Gate-2-Auflagen: SO dokumentiert im Steckbrief, - SOR prüft bei ELS-Ende - - 4. Bei Nicht-Erfüllung: - - Vor Folgegate: Gate kann nicht positiv entschieden werden - - Im ELS: ELS kann nicht beendet werden - - begruendung: | - Ein formales Auflagen-Register würde Overhead ohne nachgewiesenen Nutzen - erzeugen. Das Protokoll-basierte Tracking nutzt bestehende Strukturen - (SOR-Protokoll, Service-Steckbrief) und etabliert eine klare Prüflogik. - - Auflagen sind verbindlich (nicht nur Empfehlungen) – die Integration - in die Gate-Logik sichert die Durchsetzung. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates / Auflagen" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Protokollierung" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-013 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" - - frage: "Wie wird Gate 1 bei SO-Abwesenheit gehandhabt?" - - entscheidung: | - Verschiebung mit Eskalationsoption: - - 1. Regelfall (kurzfristige Abwesenheit bis 4 Wochen): - - Gate 1 wird verschoben bis SO verfügbar ist - - Keine automatische Vertretung - - 2. Ausnahme bei Dringlichkeit: - - SPM beurteilt, ob Verzögerung kritisch wäre - - SPM kann an SOR eskalieren - - SOR entscheidet dann Gate 1 + Gate 2 gemeinsam - - 3. Längere Vakanz (über 4 Wochen): - - SOR entscheidet über Interim-SO oder Neubenennung - - SPM bringt Vorschlag ein - - Keine Pflicht zur präventiven Stellvertreter-Benennung (nur Empfehlung). - - begruendung: | - Der SO ist persönlich accountable für Gate-1-Entscheidungen. Eine - automatische Stellvertretung würde diese Accountability verwässern. - - Die Verschiebung ist in den meisten Fällen unproblematisch. Die - Eskalationsoption sichert Handlungsfähigkeit bei echten Dringlichkeiten, - ohne eine Pflicht zur Stellvertreter-Benennung zu erzeugen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Quality Gates / Gate 1 / Vertretung" - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Vertretung" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-014 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" - - frage: "Wie werden Gate-Entscheidungen vorbereitet?" - - entscheidung: | - Steckbrief-Integration mit Pflichtfeldern: - - 1. Vorlage-Dokument: Service-Steckbrief (erweitert um Gate-Readiness) - - 2. Verantwortlich: - - Gate 1: PL erstellt, SO gibt frei - - Gate 2: SO erstellt und reicht ein - - 3. Pflichtinhalte Gate 1: - - Service-Bezeichnung und Version - - Kurzbeschreibung des Service-Scopes - - Benannter Service Owner - - Abnahme durch Auftraggeber - - Bekannte Einschränkungen oder Risiken - - Pilot-Empfehlung - - 4. Pflichtinhalte Gate 2: - - Erfüllung Gate-1-Auflagen - - Betriebsbereitschaft (bestätigt) - - Support-Bereitschaft (bestätigt) - - Pilot-Ergebnis (falls durchgeführt) - - SLA/SLO-Entwurf - - Katalog-Eintrag-Entwurf - - 5. Einreichungsfrist: 3 Arbeitstage vor SOR-Sitzung - - 6. Vollständigkeitsprüfung durch SPM bei Einreichung - - begruendung: | - Der Service-Steckbrief existiert bereits und wird ohnehin gepflegt. Die - Integration vermeidet Doppelarbeit und stellt Konsistenz sicher. - - Die 3-Tage-Frist ermöglicht Tagesordnungs-Erstellung und Vorab-Prüfung. - Unvollständige Vorlagen werden nicht in der Sitzung diskutiert, um - Sitzungszeit zu schonen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Gate-Vorbereitung" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Sitzungsvorbereitung" - - dokument: "spm_schema_service-steckbrief.yaml" - abschnitt: "Gate-Readiness (neuer Abschnitt)" - - status: "final" - - - id: GOV-TR-013 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" - - frage: "Wie wird ELS zeitlich parametrisiert?" - - entscheidung: | - Hybrid-Korridor mit drei Parametern: - - Mindestdauer: 2 Wochen (verbindlich) - - Regeldauer: 4 Wochen (Orientierung) - - Maximaldauer: 8 Wochen (Eskalations-Trigger) - - Innerhalb des Korridors entscheidet SO zustandsbasiert anhand - der Exit-Kriterien. Vor Ablauf der Mindestdauer ist kein Exit - möglich, auch bei Stabilität. - - begruendung: | - Der Hybrid-Ansatz balanciert SO-Ermessen (Governance-Prinzip - "Informed Judgment") mit operativer Planbarkeit. Er vermeidet - die Extreme von mechanischem Zeitablauf und völliger Beliebigkeit. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - status: "final" - - validierungshinweis: | - ACHTUNG: Alle Zeitwerte (2/4/8 Wochen) sind MVP-ANNAHMEN. - Erforderlich: - - Bestätigung vor MVP-Start mit DIGIT-Stakeholdern - - Bewertung während MVP-Phase anhand konkreter Fälle - - Ggf. Anpassung nach ersten operativen Erfahrungen - - # --------------------------------------------------------------------------- - - id: GOV-TR-014 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" - - frage: "Wie ist die Projektverfügbarkeit während ELS geregelt?" - - entscheidung: | - Gestaffelte Übergabe mit abnehmender Intensität: - - Phase 1 (ELS-Woche 1-2): - - Verfügbarkeit: verpflichtend - - Reaktionszeit: 4 Stunden (Geschäftszeiten) - - Umfang: Troubleshooting, Wissenstransfer, Bug-Fixes - - Phase 2 (ab ELS-Woche 3): - - Verfügbarkeit: auf Abruf - - Reaktionszeit: 2 Arbeitstage - - Umfang: Nur dokumentierte Eskalationsfälle (Severity 1-2) - - Projekt-Exit frühestens nach Mindestdauer (2 Wochen). - Abruf-Verfügbarkeit für 4 Wochen nach Projekt-Exit. - - begruendung: | - Realistischer Kompromiss zwischen Projekt-Abschlussdruck und - Absicherung der kritischen Phase. Korrespondiert mit ELS-Dauer-Logik - (Phase 1 = Mindestdauer). Verantwortung (A) bleibt beim SO. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - status: "final" - - validierungshinweis: | - ACHTUNG: Zeiträume und Reaktionszeiten sind MVP-ANNAHMEN. - Erforderlich: - - Prüfung der Kompatibilität mit DIGIT-Projektbudget-/Ressourcenlogik - - Bestätigung vor MVP-Start - - Bewertung anhand konkreter Fälle - - # --------------------------------------------------------------------------- - - id: GOV-TR-015 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" - - frage: "Was ist eine 'kritische Störung' im ELS-Kontext?" - - entscheidung: | - Minimaldefinition für ELS-Exit-Bewertung: - - Eine Störung gilt als kritisch, wenn BEIDE Kriterien erfüllt sind: - - (1) Nutzbarkeitseinschränkung: - Service ist für wesentliche Nutzergruppe (>20% oder - geschäftskritisch) nicht oder nur stark eingeschränkt nutzbar. - - (2) Kein Workaround: - Es existiert kein praktikabler Workaround, der die - Einschränkung kompensiert. - - Bei Grenzfällen entscheidet SO und dokumentiert Einschätzung. - - begruendung: | - Operationalisierbar ohne vollständige Severity-Klassifikation. - Vermeidet Abhängigkeit von SSM-Entwicklung. Anschlussfähig an - spätere Severity-Klassifikation (entspricht dort Severity 1-2). - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - dokument: "SSM Incident Management" - abschnitt: "Severity-Klassifikation" - hinweis: "Konsistenzprüfung bei SSM-Finalisierung erforderlich" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-016 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" - - frage: "Wie wird das ELS-Ende dokumentiert?" - - entscheidung: | - Leichtgewichtiger ELS-Vermerk im Service-Steckbrief. - Kein separater Abschlussbericht erforderlich. - - Pflichtfelder: - - els_start (Datum) - - els_ende (Datum) - - els_dauer_wochen (Zahl) - - kritische_stoerungen_anzahl (Zahl) - - exit_begruendung (Kurztext, max. 500 Zeichen) - - Optionales Feld: - - lessons_learned (Kurztext) - - Erweiterung bei Auffälligkeiten (>6 Wochen ODER >2 krit. Störungen): - - ursachenanalyse (Pflicht) - - massnahmen_fuer_zukunft (Pflicht) - - begruendung: | - Passt zu leichtgewichtiger Governance ("kein formales Gate"). - Vermeidet Artefakt-Inflation durch Integration in Steckbrief. - Stellt Nachweisbarkeit für ersten Service Review sicher. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - dokument: "spm_schema_service-steckbrief.yaml" - abschnitt: "Neue Felder: els_verlauf" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-017 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" - - frage: "Was passiert bei Überschreitung der ELS-Maximaldauer?" - - entscheidung: | - Automatische Eskalation an SOR bei Überschreitung der Maximaldauer - (8 Wochen). - - Mechanismus: - - SPM überwacht ELS-Dauern - - Bei Überschreitung: Pflicht-Agenda-Punkt in nächster SOR - - SO bereitet Sachstandsbericht vor (Frist: 3 AT vor SOR) - - SOR-Entscheidungsoptionen: - (1) ELS-Verlängerung (max. 4 Wochen, mit neuem Zieldatum) - (2) Rückführung in Transition (neuer Gate-2-Antrag erforderlich) - (3) Zwangs-Exit (mit dokumentierter Risiko-Akzeptanz durch SOR) - (4) Service-Stilllegung (nur in Extremfällen) - - Bei erneuter Überschreitung nach Verlängerung: erneute Eskalation. - - begruendung: | - Überschreitung der Maximaldauer signalisiert Problem, das - SO-Kompetenz übersteigt. SOR als Portfolio-Governance ist - richtiger Adressat. Definierte Optionen geben klaren - Handlungsrahmen und vermeiden Endlos-Schleifen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "ELS-Konzept" - - dokument: "spm_sor-geschaeftsordnung.yaml" - abschnitt: "Standard-Agenda-Punkte" - hinweis: "ELS-Eskalation als möglichen Punkt aufnehmen" - - status: "final" - - - id: GOV-TR-018 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" - - frage: "Was bedeutet 'Zurück an Transition' bei Gate-2-Zurückweisung operativ?" - - entscheidung: | - SO-Verantwortung mit Zeitrahmen: - - 1. Verantwortlichkeit: - - SO verantwortet die Mängelbeseitigung - - SO entscheidet über Wiedervorlage-Zeitpunkt - - SPM überwacht Fristen - - 2. Zeitrahmen: - - Standardfrist: 8 Wochen für Wiedervorlage - - Verlängerung durch SOR möglich (begründeter Antrag) - - Eskalation an SOR nach 10 Wochen ohne Wiedervorlage - - 3. Status: - - Service bleibt in "in_transition" - - Keine formale Statusänderung - - 4. Dokumentation: - - Zurückweisungsgründe im SOR-Protokoll - - Erwartete Wiedervorlage (Datum/KW) - - begruendung: | - Schlanke Variante ohne Bürokratie-Overhead. Nutzt die bestehende - SO-Accountability für den Service-Erfolg. Die Zeitbegrenzung verhindert - "Zombie-Services", die endlos in der Transition-Schleife bleiben. - - Keine formale Statusänderung, da der Service konzeptionell weiterhin - "in Transition" ist – nur mit identifizierten Nachbesserungsbedarfen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Rollback-Szenarien / Gate-2-Zurückweisung" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Protokollierung / Zurückweisungen" - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Verantwortlichkeiten / Nachbesserung" - - status: "final" - - confidence: "75%" - - unsicherheit: | - Die 8-Wochen-Frist ist eine Orientierung. Je nach Art der Mängel - kann mehr oder weniger Zeit erforderlich sein. Die Frist sollte - als Richtwert, nicht als harter Constraint verstanden werden. - - # --------------------------------------------------------------------------- - - id: GOV-TR-019 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" - - frage: "Wer kann während ELS einen Service stoppen, und wie?" - - entscheidung: | - SO-Einzelentscheidung mit Informationspflicht: - - 1. Entscheidungskompetenz: - - SO hat Mandat zur Einzelentscheidung "Service-Stopp" - - Keine vorherige SOR-Abstimmung erforderlich - - Begründung ist erforderlich - - 2. Kommunikationspflichten: - Unverzüglich: - - SPM (koordiniert SOR-Behandlung) - - Support Manager (Nutzer-Kommunikation) - - Operations Manager (technische Deaktivierung) - - Innerhalb 24h: - - SOR (alle Mitglieder) per E-Mail - - 3. Folgezustand: - - Service-Status wird "suspended" - - Katalog zeigt "temporär nicht verfügbar" - - 4. Nächste Schritte: - - SOR-Behandlung innerhalb 5 Werktagen - - SOR entscheidet: Wiederaufnahme / Zurück an Transition / Ablehnung - - begruendung: | - In einer Krisensituation muss jemand handlungsfähig sein – das ist der SO - als Accountable für den Service-Erfolg. Die Informationspflicht stellt - sicher, dass die SOR involviert wird, ohne dass sie zum Bottleneck wird. - - Wichtig: Ein Service-Stopp ist ein Qualitätssicherungsinstrument, keine - Schuldzuweisung. SOs sollten diese Kompetenz bei Bedarf nutzen. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Rollback-Szenarien / ELS-Rollback" - - dokument: "R-SO Rollenbeschreibung" - abschnitt: "Entscheidungsbefugnisse / Service-Stopp" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Außerordentliche Behandlung" - - status: "final" - - confidence: "70%" - - unsicherheit: | - Die Governance allein löst nicht die Frage, ob SOs diese Kompetenz - auch tatsächlich wahrnehmen werden. Es besteht das Risiko, dass SOs - aus Angst vor Gesichtsverlust zu lange warten. Das ist eine kulturelle - Frage, die das Modell nicht allein adressieren kann. - - abgrenzung: | - Ein Service-Stopp ist NICHT die Reaktion auf einzelne Incidents. - Incidents werden über das reguläre Incident Management behandelt. - Ein Service-Stopp ist angezeigt, wenn der Service als Ganzes seinen - Zweck nicht erfüllt und keine kurzfristige Lösung absehbar ist. - - # --------------------------------------------------------------------------- - - id: GOV-TR-020 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" - - frage: "Gibt es eine formale Iterationsgrenze für Zurückweisungen bei Gate 2?" - - entscheidung: | - MVP: Keine formale Grenze – situative SOR-Entscheidung. - - 1. Grundsatz: - - Die SOR entscheidet bei jeder Zurückweisung situativ - - Keine automatischen Trigger für Service-Ablehnung - - Keine feste Anzahl erlaubter Iterationen - - 2. Orientierungshilfe für SOR: - Bei jeder Zurückweisung sollte die SOR prüfen: - - Sind die Probleme grundsätzlich lösbar? - - Sind Ressourcen für weitere Iteration verfügbar? - - Ist die strategische Passung noch gegeben? - - Wie lange ist der Service schon in Transition? - - Wie viele Zurückweisungen gab es bereits? - - 3. Empfehlung: - Ab der dritten Zurückweisung sollte die SOR explizit begründen, - warum eine Fortsetzung noch sinnvoll ist – oder Service-Ablehnung - beschließen. - - begruendung: | - Für den MVP ist eine situative Entscheidung angemessen. Die Praxis wird - zeigen, ob und wann formale Grenzen nötig sind. Zu frühe Formalisierung - könnte entweder zu starr sein (verhindert sinnvolle Fortsetzungen) oder - zu weich (verhindert nötige Abbrüche). - - Das Risiko von "Zombie-Services" ist bekannt und muss von der SOR aktiv - gemanagt werden. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Rollback-Szenarien / Projekt-Termination" - - dokument: "G-SOR Geschäftsordnung" - abschnitt: "Service-Ablehnung" - - status: "final" - - confidence: "65%" - - unsicherheit: | - Ohne formale Grenzen besteht das Risiko von "Zombie-Services", die - endlos in der Transition-Schleife bleiben. Die SOR muss dieses Risiko - aktiv managen. - - evolutionspfad: | - Bei Praxisproblemen (Zombie-Services, Willkür-Vorwürfe, Entscheidungs- - Paralyse) sollte das Modell weiterentwickelt werden zu: - - "Option D: Kombiniertes Modell" - - Nach 2. Zurückweisung: Pflicht-Analyse durch SPM - - Nach 3. Zurückweisung ODER nach 6 Monaten: Default = Ablehnung - - Fortsetzung nur durch expliziten SOR-Beschluss mit Begründung - - Indikatoren für Weiterentwicklung: - - Services länger als 6 Monate in Transition ohne Fortschritt - - SOR-Mitglieder beklagen fehlende Orientierung - - Wahrnehmung von Willkür bei Ablehnungsentscheidungen - - Ressourcenkonflikte durch zu viele parallele Transition-Services - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-06: BEGRIFFLICHE HARMONISIERUNG -# ============================================================================= - -entscheidungen_ap_06: - - # --------------------------------------------------------------------------- - - id: GOV-TR-021 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" - - frage: "Was bedeutet 'Aktivierung' im Service-Transition-Kontext?" - - entscheidung: | - Einheitsmodell: "Aktivierung" ist ein atomarer Akt, der durch die - Go-Live-Freigabe (Gate 2) ausgelöst wird und gleichzeitig bewirkt: - - (1) Statusübergang des Services auf lifecycle_status = "aktiv" - (2) Sichtbarkeit des Services im Service-Katalog - (3) Bestellbarkeit/Nutzbarkeit des Services durch berechtigte Nutzer - - Es gibt KEINE Trennung zwischen "Portfolio-Aufnahme" und - "Katalog-Aktivierung" bei Go-Live. - - begruendung: | - Kein validierter Use Case für eine Trennung bei Aktivierung. - MVP-Prinzip: Komplexität nur bei nachgewiesenem Bedarf. - Die Governance ist klar: SOR entscheidet einmalig, alle Effekte folgen. - - abgrenzung: | - "Aktivierung" bezeichnet nicht: - - Die Gate-2-Entscheidung selbst (diese heißt "Go-Live-Freigabe") - - Die technische Bereitstellung (diese heißt "Deployment" oder "Rollout") - - Die Aufnahme in Governance-Strukturen (implizit durch Gate 2) - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Begriffsklärungen" - - dokument: "service-lifecycle_service-transition.yaml" - abschnitt: "st_04 Begrifflichkeit" - - status: "final" - validierungsstatus: "MVP-Annahme, Workshop-Validierung empfohlen" - - # --------------------------------------------------------------------------- - - id: GOV-TR-022 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" - - frage: "Wie wird der Service-Status modelliert?" - - entscheidung: | - Zwei-Status-Modell: - - (1) Dokumenten-Status (metadata.status): entwurf / freigegeben / archiviert - Beschreibt die Gültigkeit der Service-Definition als Dokument. - - (2) Lifecycle-Status (lifecycle.lifecycle_status): - in_entwicklung / in_transition / aktiv / in_stilllegung / - stillgelegt / abgebrochen - Beschreibt die Phase des Services im Service-Lifecycle. - - Beide Status sind unabhängig, aber es gibt Korrelationsregeln - (z.B. lifecycle_status = "aktiv" erfordert status = "freigegeben"). - - begruendung: | - Die bisherige Vermischung von Dokumenten- und Lifecycle-Status führte - zu semantischer Verwirrung. Das Zwei-Status-Modell trennt sauber: - - Informationsmanagement-Perspektive (Dokument) - - Lifecycle-Management-Perspektive (Service) - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "Neuer Abschnitt 'lifecycle'" - - dokument: "service-lifecycle_service-transition.yaml" - abschnitt: "Status-Referenzen korrigieren" - - status: "final" - schema_patch: "Erforderlich – lifecycle-Abschnitt hinzufügen" - - # --------------------------------------------------------------------------- - - id: GOV-TR-023 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" - - frage: "Wie verhalten sich Service-Portfolio und Service-Katalog zueinander?" - - entscheidung: | - Hierarchisches Modell: Der Katalog ist eine Teilmenge des Portfolios. - - - Service-Portfolio: Gesamtheit aller Services in DIGIT-Verantwortung, - unabhängig vom Lifecycle-Status. Governance-Objekt der SOR. - - - Service-Katalog: Gefilterte Sicht auf das Portfolio mit - lifecycle_status = "aktiv". Für Kunden sichtbar. - - Der Katalog ist kein separates Register, sondern eine View auf das - Portfolio. "Aufnahme ins Portfolio" und "Aktivierung im Katalog" - sind bei Go-Live ein und derselbe Vorgang. - - Portfolio-Struktur: - - Pipeline: lifecycle_status in (in_entwicklung, in_transition) - - Katalog: lifecycle_status = aktiv - - In Stilllegung: lifecycle_status = in_stilllegung - - Retired: lifecycle_status = stillgelegt - - begruendung: | - ITIL4-konforme Trennung wäre konzeptionell richtig, aber für MVP - zu aufwändig. Das hierarchische Modell bietet konzeptionelle Klarheit - bei operativer Einfachheit. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Begriffsklärungen" - - dokument: "spm_practice_service-catalog-management.yaml" - abschnitt: "Katalog-Definition" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-024 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" - - frage: "Werden die ITIL4-Begriffe 'Release' und 'Deployment' übernommen?" - - entscheidung: | - Begriffe übernehmen, aber keine formale Prozess-Trennung im MVP. - - - Release: Versionspaket, das zur Bereitstellung vorbereitet wurde. - Erstellung ist Teil der Service-Entwicklung (SE). - - - Deployment: Technischer Vorgang der Installation in Zielumgebung. - Ist Aktivität in Service Transition (st_02). - - - Rollout: DIGITOM-Alltagsbegriff für die integrative Bereitstellung, - die Release-Übergabe und Deployment umfasst. - - Im MVP werden Release Management und Deployment Management NICHT - als separate Practices modelliert. - - begruendung: | - Die ITIL4-Begriffe sind branchenetabliert – sie zu vermeiden erzeugt - Reibung mit externen Stakeholdern. Eine formale Prozess-Trennung ist - für DIGIT aktuell nicht erforderlich. Bei wachsender Komplexität - kann später differenziert werden. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Begriffsklärungen / Glossar" - - status: "final" - revisionshinweis: | - Bei komplexeren Release-Zyklen (z.B. eigenentwickelte Fachverfahren) - sollte die Entscheidung revidiert werden. - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-07: TRANSITION-ARTEFAKTE -# ============================================================================= -# Zur Integration in: spm_governance-entscheidungen-log.yaml -# Arbeitspaket: AP-07 Transition-Artefakte definieren -# Datum: 2025-12-17 -# ============================================================================= - -entscheidungen_ap_07: - - # --------------------------------------------------------------------------- - - id: GOV-TR-025 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" - - frage: "Wie werden die Transition-Artefakte dokumentiert – verteilt in verschiedenen Dokumenten oder konsolidiert?" - - entscheidung: | - Einführung eines eigenständigen "Transition-Steckbriefs" als - konsolidiertes Prozessdokument. - - Der Transition-Steckbrief: - - Wird bei Übergabe aus Service-Entwicklung angelegt - - Dokumentiert alle Gate-Entscheidungen (Gate 1, Gate 2) - - Enthält Pilot-Entscheidung und -Ergebnisse (falls relevant) - - Dokumentiert den ELS-Verlauf - - Enthält eine Abschluss-Checkliste - - Wird bei ELS-Exit abgeschlossen - - Der Transition-Steckbrief ersetzt die ursprünglich geplanten - Schema-Erweiterungen für den Service-Steckbrief (gate_readiness, - els_verlauf) sowie die separaten Artefakte "Transition-Checkliste", - "Betriebsreife-Nachweis" und "ELS-Vermerk". - - begruendung: | - Ein konsolidiertes Dokument bietet mehrere Vorteile: - - 1. Kohärenz: Alle Transition-Informationen an einem Ort statt - verstreut über Steckbrief-Erweiterungen und Gate-Protokolle - - 2. Nachweisbarkeit: Vollständige Dokumentation des Transition- - Prozesses für Service Review und Audit - - 3. Prozess-Analogie: Konsistent mit dem Bedarfs-Steckbrief im - Demand-Lifecycle, der ebenfalls ein temporäres Prozessdokument - ist und nach Abschluss überführt wird - - 4. Klarheit: Eliminiert Phantom-Artefakte und begriffliche - Unschärfen (z.B. "Betriebsreife-Nachweis" vs. "SO-Readiness") - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Artefakte" - aenderung: "Neuer Abschnitt 'Transition-Steckbrief' mit Verweis auf Schema" - - - dokument: "spm_schema_transition-steckbrief.yaml" - abschnitt: "Gesamtes Dokument" - aenderung: "Neues Schema-Dokument erstellen" - - - dokument: "AP-01 bis AP-06 (TMP-Files)" - abschnitt: "Diverse" - aenderung: "Begriffe werden bei Konsolidierung (AP-09) ersetzt" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-026 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" - - frage: "Was passiert mit dem Transition-Steckbrief nach Abschluss der Transition?" - - entscheidung: | - Nach Abschluss der Transition (ELS-Exit) wird der Transition- - Steckbrief als Anhang in den Service-Steckbrief überführt. - - Überführungsprozess: - 1. SO schließt Transition-Steckbrief ab (Status: "abgeschlossen") - 2. Transition-Steckbrief wird als Anhang an Service-Steckbrief - gehängt (Abschnitt: "transition_historie" oder als verlinktes - Dokument) - 3. Wesentliche Kennzahlen (ELS-Dauer, kritische Störungen) werden - in Service-Steckbrief-Metadaten übernommen - - Der Transition-Steckbrief bleibt als historisches Dokument - erhalten und wird nicht gelöscht. - - begruendung: | - Die Überführung stellt sicher, dass: - - 1. Der Service-Steckbrief das "lebende Dokument" bleibt und nicht - mit Prozess-Details überfrachtet wird - - 2. Die Transition-Historie für Service Review verfügbar ist - - 3. Bei späteren Änderungen (Re-Transition) ein neuer Transition- - Steckbrief angelegt werden kann, ohne den alten zu überschreiben - - Das Muster entspricht dem Bedarfs-Steckbrief → Demand-Steckbrief - Übergang im DPM. - - auswirkung_auf: - - dokument: "spm_schema_service-steckbrief.yaml" - abschnitt: "anhaenge oder transition_historie" - aenderung: "Feld für Transition-Steckbrief-Referenz ergänzen" - - - dokument: "konzept_service-transition.yaml" - abschnitt: "Artefakte > Lifecycle" - aenderung: "Überführungsprozess dokumentieren" - - status: "final" - - # --------------------------------------------------------------------------- - - id: GOV-TR-027 - datum: "2025-12-17" - quelle_modul: "K-TR Rahmenkonzept Service Transition" - quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" - - frage: "Welche bisherigen Artefakt-Begriffe werden durch den Transition-Steckbrief ersetzt?" - - entscheidung: | - Folgende Begriffe werden eliminiert bzw. ersetzt: - - ERSETZT DURCH TRANSITION-STECKBRIEF: - - "Transition-Checkliste" → Transition-Steckbrief.abschluss_checkliste - - "Betriebsreife-Nachweis" → Transition-Steckbrief.gate_2.so_readiness - - "SO-Readiness-Bestätigung" → Transition-Steckbrief.gate_2.so_readiness - - "ELS-Vermerk" → Transition-Steckbrief.els - - "ELS-Abschlussbericht" → Transition-Steckbrief.els - - "Gate-1-Nachweis" → Transition-Steckbrief.gate_1 - - "Pilot-Entscheidung" → Transition-Steckbrief.gate_1.pilot_entscheidung - - "Steckbrief.gate_readiness" → Transition-Steckbrief (separates Dokument) - - "Steckbrief.els_verlauf" → Transition-Steckbrief.els - - BLEIBT UNVERÄNDERT: - - "Go-Live-Protokoll" = Teil des SOR-Protokolls (kein separates Artefakt) - - "Auflagen-Dokumentation" = Teil des jeweiligen Gate-Protokolls - - "Sachstandsbericht" = Nur bei Eskalation, separate SOR-Vorlage - - EXTERNE ARTEFAKTE (nicht K-TR-Scope): - - "Betriebshandbuch" → Input aus Service-Entwicklung - - "Testprotokolle" → Input aus Service-Entwicklung - - "SLA/SLO-Vereinbarung" → Definiert in P-02 SLM - - "Katalog-Eintrag" → Definiert in P-01 SCM - - begruendung: | - Die begriffliche Konsolidierung beseitigt Redundanzen und - Phantom-Artefakte, die in der bisherigen Dokumentation entstanden - sind. Ein klares Mapping erleichtert die Konsolidierung (AP-09) - und verhindert Inkonsistenzen im finalen Konzept. - - auswirkung_auf: - - dokument: "konzept_service-transition.yaml" - abschnitt: "Gesamtes Dokument" - aenderung: "Begriffe bei Konsolidierung ersetzen" - - - dokument: "AP-01 bis AP-06 (TMP-Files)" - abschnitt: "Diverse" - aenderung: "Mappings bei AP-09 berücksichtigen" - - konsolidierungshinweis: | - Bei der YAML-Konsolidierung (AP-09) ist dieses Mapping als - Referenz zu verwenden. Die TMP-Files werden nicht einzeln - gepatcht, sondern die Begriffe werden bei der Überführung in - das finale Konzept ersetzt. - - status: "final" - -# ============================================================================= -# K-SR KONZEPT SERVICE-REVIEW -# ============================================================================= - -entscheidungen_service_review: - - - id: GOV-SR-001 - datum: "2025-12-17" - quelle_modul: "K-SR Konzept Service-Review" - - frage: "Anhand welcher Dimensionen und mit welcher Methodik bewertet der SO den Service-Zustand?" - - entscheidung: | - 4-Dimensionen-Modell mit qualitativer Ampelbewertung: - - SR-D1: Leistungserbringung (Liefert der Service den erwarteten Nutzen?) - - SR-D2: Betriebsstabilitaet (Laeuft der Service stoerungsarm?) - - SR-D3: Nutzerzufriedenheit (Wie bewerten die Nutzer den Service?) - - SR-D4: Zukunftsfaehigkeit (Ist der Service mittelfristig tragfaehig?) - - Bewertungsskala: Gruen (stabil) / Gelb (beobachten) / Rot (Handlungsbedarf) - Keine mathematische Aggregation - SO fasst zu Gesamteinschaetzung zusammen. - - begruendung: | - - Strukturelle Analogie zu SHM (VoC-Cluster D1-D4) schafft Modellkonsistenz - - Qualitative Bewertung realistisch bei fehlender KPI-Infrastruktur - - Ampellogik intuitiv und entscheidungsvorbereitend - - SO kann Verfahren in 30-60 Min/Quartal durchfuehren - - Erweiterbar: Spaetere KPIs koennen als Indikatoren einfliessen - - auswirkung_auf: - - dokument: "spm_schema_service-steckbrief.yaml" - abschnitt: "review_status" - - dokument: "service-lifecycle_service-review.yaml" - abschnitt: "sr_02" - - status: "final" - confidence: "80%" - - # --------------------------------------------------------------------------- - - - id: GOV-SR-002 - datum: "2025-12-17" - quelle_modul: "K-SR Konzept Service-Review" - - frage: "In welchem Rhythmus findet der Service-Review statt und wie verhaelt er sich zu SOR?" - - entscheidung: | - Hybridmodell: - 1. SO fuehrt quartalsweise Selbst-Review durch (eigenstaendig) - 2. SO aktualisiert Service-Definition mit Review-Ergebnis (Abschnitt 'service_review') - 3. SO informiert SPM (alle Review-Berichte, unabhaengig vom Ergebnis) - 4. SOR-Einbeziehung nur bei: - - Mind. eine Dimension "Rot" - - Handlungsempfehlung: IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE - - SO ist unsicher - 5. Anlassbezogener Ad-hoc-Review bei Major Incident, SLA-Verletzung, Eskalation - - begruendung: | - - Skaliert mit Portfolio-Groesse (nicht jeder Service braucht SOR-Zeit) - - SO behaelt Eigenverantwortung (Subsidiaritaetsprinzip) - - SPM hat Portfolio-Uebersicht fuer Aggregation und Muster-Erkennung - - SOR fokussiert auf Ausnahmen (Management by Exception) - - Konsistent mit E2-Quartalsrhythmus im SHM - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "service_review" - - dokument: "rolle_service-owner.yaml" - abschnitt: "verantwortlichkeiten" - - dokument: "spm_rollen.yaml" - abschnitt: "service_portfolio_manager" - - status: "final" - confidence: "85%" - - # --------------------------------------------------------------------------- - - - id: GOV-SR-003 - datum: "2025-12-17" - quelle_modul: "K-SR Konzept Service-Review" - - frage: "Gibt es objektive Schwellenwerte fuer automatische Handlungen oder Eskalation?" - - entscheidung: | - Orientierungskriterien mit Urteilsvorbehalt: - - Kriterien definieren typische Konstellationen fuer jeden Entscheidungspfad - - Keine automatischen Trigger - finales Urteil beim SO - - Bei Abweichung von Orientierung: Begruendungspflicht (2-3 Saetze) - - Typische Konstellationen: - - CONTINUE: Alle Gruen oder max. eine Gelb - - IMPROVEMENT: Eine/mehrere Rot, im Service-Rahmen loesbar - - REDESIGN: Mehrere Rot ueber Quartale, Architektur-Problem - - RETIRE: Kaum genutzt, unverhaeltnismaessiger Aufwand - - begruendung: | - - Konsistent mit SHM-Logik (qualitative Trigger mit Begruendungspflicht) - - Vermeidet Schein-Objektivitaet durch nicht vorhandene Datenbasis - - Erhaelt Flexibilitaet fuer Service-spezifische Kontexte - - Begruendungspflicht bei Abweichung sichert Governance-Qualitaet - - auswirkung_auf: - - dokument: "konzept_service-review.yaml" - abschnitt: "entscheidungspfade" - - status: "final" - confidence: "75%" - - # --------------------------------------------------------------------------- - - - id: GOV-SR-004 - datum: "2025-12-17" - quelle_modul: "K-SR Konzept Service-Review" - - frage: "Wie laeuft die SOR-Behandlung eines Service-Reviews konkret ab?" - - entscheidung: | - Differenziertes Verfahren nach Handlungsempfehlung: - - 1. Kenntnisnahme (keine SOR-Agenda): - - CONTINUE - - IMPROVEMENT (SO-gefuehrt, ressourcenneutral) - -> SO dokumentiert im Steckbrief, informiert SPM - - 2. Operative Entscheidung (SOR-Behandlung): - - IMPROVEMENT (ressourcenrelevant) - -> SO reicht Review-Vorlage ein, SOR entscheidet (Konsens) - - 3. Strategische Entscheidung (SOR-Behandlung): - - REDESIGN, RETIRE - -> SOR entscheidet, bei Freigabe Uebergabe an DPM - -> Bei Dissens/Tragweite: Eskalation an MB - - Vorlage-Anforderungen: Einreichung 3 AT vor Sitzung an SPM - - begruendung: | - - Fokussiert SOR-Zeit auf Entscheidungen, die Governance erfordern - - CONTINUE und kleine IMPROVEMENTs sind SO-Verantwortung (Subsidiaritaet) - - Nur ressourcen-/portfoliorelevante Entscheidungen brauchen Gremiumszeit - - auswirkung_auf: - - dokument: "spm_sor-geschaeftsordnung.yaml" - abschnitt: "entscheidungsgegenstaende" - - dokument: "rolle_service-owner.yaml" - abschnitt: "befugnisse" - - status: "final" - confidence: "80%" - - # --------------------------------------------------------------------------- - - - id: GOV-SR-005 - datum: "2025-12-17" - quelle_modul: "K-SR Konzept Service-Review" - - frage: "Wie wird die Wirksamkeit von Improvement-Massnahmen nachgehalten?" - - entscheidung: | - MVP-Loesung: Service-Definition-Tracking - - 1. Improvement-Massnahmen werden in der Service-Definition dokumentiert - (Abschnitt "laufende_verbesserungen") - 2. Pflichtfelder: ID, Beschreibung, Ziel-Dimension, Verantwortlich, - Termin, Status - 3. Im naechsten Quartals-Review: SO prueft Wirksamkeit - (Hat sich betroffene Dimension verbessert?) - 4. Keine separate CI-Infrastruktur im MVP - - Post-MVP: Dedizierte CI-Practice mit zentralem Improvement-Register - - begruendung: | - - Minimal Viable: Kein neues Tooling/Practice erforderlich - - Governance-Anker: Service-Definition + Review-Zyklus sichert Nachverfolgung - - Erweiterbar: Bei CI-Practice-Etablierung kann migriert werden - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "laufende_verbesserungen" - - status: "final" - confidence: "70%" - - - id: "GOV-CE-001" - datum: "2025-12-17" - quelle_modul: "P-03 Change Enablement" - - frage: "Wie werden Emergency Changes gehandhabt?" - - entscheidung: | - Sofortumsetzung durch Betrieb/Support mit nachträglicher Dokumentation. - Service Owner wird informiert, nicht um Genehmigung gefragt. - - Dokumentation innerhalb 24 Stunden. - - begruendung: | - Bei kritischen Sicherheits- oder Verfügbarkeitsproblemen ist - Geschwindigkeit entscheidend. Ein Genehmigungsprozess würde - Schaden vergrößern. Die nachträgliche Dokumentation stellt - Nachvollziehbarkeit sicher. - - auswirkung_auf: - - dokument: "spm_practice_change-enablement.yaml" - abschnitt: "change_typen.emergency_change" - - status: "final" - - - id: "GOV-CE-002" - datum: "2025-12-17" - quelle_modul: "P-03 Change Enablement" - - frage: "Gilt Change Enablement für Infrastruktur ohne Service-Bezug?" - - entscheidung: | - Nein. Fokus auf Service-Changes. Infrastruktur ohne direkten - Service-Bezug (z.B. Netzwerk-Basis) ist der Produkt-Ebene - zuzuordnen und wird in dieser Phase nicht adressiert. - - begruendung: | - Die aktuelle Projektphase priorisiert die Kunden-/Service-Sicht. - Produkt-Management ist nicht im Fokus. Eine Vermischung würde - den Scope aufblähen ohne Mehrwert für die priorisierten Ziele. - - auswirkung_auf: - - dokument: "spm_practice_change-enablement.yaml" - abschnitt: "einordnung.abgrenzung_produkt" - - vermerk: | - Bei späterer Produkt-Konzeption: Change Enablement für - Produkte/Infrastruktur ergänzen. - - status: "final" - - - id: "GOV-CE-003" - datum: "2025-12-17" - quelle_modul: "P-03 Change Enablement" - - frage: "Wie wird Cross-Service-Impact bei Normal Changes erkannt und behandelt?" - - entscheidung: | - Service Owner ist verantwortlich für Erkennung von Cross-Service-Impact. - SPM wird als "Zweite Augen" einbezogen bei Changes mit potenziellem - Cross-Service-Impact. - - Schwellenwert: SO-Ermessen ("Im Zweifel SPM einbeziehen"). - Keine formalen Schwellenwerte im MVP. - - begruendung: | - Der SO kennt seinen Service und dessen Abhängigkeiten am besten. - SPM bringt die Portfolio-Perspektive ein, ohne den SO zu entmündigen. - Formale Schwellenwerte würden Gaming fördern und Bürokratie erzeugen. - - auswirkung_auf: - - dokument: "spm_practice_change-enablement.yaml" - abschnitt: "change_typen.normal_change.cross_service" - - status: "final" - - # =========================================================================== - # INTERNE SERVICES – bestätigt März 2026 (PENDING-SPM-001) - # =========================================================================== - - - id: "GOV-SPM-I-001" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services" - - frage: "Soll das Kategorienmodell um Interne Services erweitert werden?" - - entscheidung: | - Das Kategorienmodell wird von drei auf vier Werte erweitert: - - A: Basis-Services (Kundenservice, Katalog-sichtbar) - - B: Erweiterte Services (Kundenservice, Katalog-sichtbar) - - C: Spezial-Services (Kundenservice, Katalog-sichtbar) - - I: Interne Services (kein Kundenservice, NICHT im Katalog) - - Interne Services sind vollwertige Governance-Objekte mit eigenem - Service Owner, eigenem SLA-Typ (OLA), eigener Service-Definition - und Teilnahme am Service-Lifecycle. - - begruendung: | - Infrastruktur-Komponenten wie Active Directory oder der Netzwerk-Backbone - sind für die Qualität von Kundenservices kritisch, werden aber bisher - nicht systematisch gesteuert. Kategorie I ermöglicht Governance ohne - Katalog-Überfrachtung. - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "identitaet.service_kategorie" - - dokument: "service-portfolio-management_glossar.yaml" - abschnitt: "Interner Service" - - dokument: "spm_practice_service-catalog-management.yaml" - abschnitt: "kategorien_logik" - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" - pending_referenz: "PENDING-SPM-001, DC-001" - - # --------------------------------------------------------------------------- - - - id: "GOV-SPM-I-002" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services" - - frage: "Welcher SLA-Typ gilt für Interne Services?" - - entscheidung: | - Für Interne Services (Kategorie I) gilt ein Operational Level Agreement - (OLA) anstelle eines SLA. Das OLA-Feld bleibt während der Pilotphase - leer (kein Placeholder-Wert). Die Begründung wird einmalig in der - Pilot-Scope-Dokumentation festgehalten. - - begruendung: | - ITIL4-konforme Terminologie. OLAs sind der etablierte Begriff für - interne Leistungsvereinbarungen zwischen Betriebseinheiten. - Trennung von SLA (extern) und OLA (intern) schafft konzeptionelle - Klarheit ohne Mehraufwand. - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "qualitaet.service_level_referenz" - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "kernkonzepte.dokument_typen" - - dokument: "service-portfolio-management_glossar.yaml" - abschnitt: "OLA" - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" - pending_referenz: "PENDING-SPM-001, DC-002" - - # --------------------------------------------------------------------------- - - - id: "GOV-SPM-I-003" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services" - - frage: "Soll service_sichtbarkeit als eigenständiges Attribut geführt werden?" - - entscheidung: | - Das Attribut service_sichtbarkeit wird nicht eingeführt (bzw. ersatzlos - gestrichen, falls vorhanden). Die Sichtbarkeit ist vollständig aus der - service_kategorie ableitbar: - - Kategorie A, B, C → im Katalog sichtbar - - Kategorie I → NICHT im Katalog (per Definition) - - begruendung: | - Designprinzip "Encode rationale once". Redundante Attribute erhöhen - Pflegeaufwand und schaffen Widerspruchspotenzial. - - auswirkung_auf: - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "identitaet (kein neues Attribut)" - - dokument: "service-portfolio-management_glossar.yaml" - abschnitt: "Service-Sichtbarkeit" - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" - pending_referenz: "PENDING-SPM-001, DC-003" - - # --------------------------------------------------------------------------- - - - id: "GOV-SPM-I-004" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services" - - frage: "Soll ein eigenständiges Produkt-Konzept eingeführt werden?" - - entscheidung: | - Das Konzept "Produkt" als eigenständige Kategorie oder Governance-Objekt - wird nicht eingeführt. Infrastruktur-Komponenten werden entweder als - Interne Services (Kategorie I) oder als passive Service-Komponenten - behandelt. Die Abgrenzung erfolgt gemäß dem Sieben-Fragen-Leitfaden - (GOV-SPM-I-005). - - begruendung: | - Das Produkt-Konzept hätte eine dritte Governance-Ebene (neben Services - und Komponenten) eingeführt ohne klaren Mehrwert gegenüber dem - erweiterten Service-Modell. - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" - pending_referenz: "PENDING-SPM-001, DC-004" - - # --------------------------------------------------------------------------- - - - id: "GOV-SPM-I-005" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services" - - frage: "Wie wird zwischen Internem Service und passiver Komponente abgegrenzt?" - - entscheidung: | - Sieben-Fragen-Orientierungsleitfaden: - 1. Gibt es einen identifizierbaren internen "Kunden"? - 2. Gibt es eine verantwortliche Rolle für Service-Owner-Funktion? - 3. Hat die Komponente eigene, unabhängig definierbare Qualitätsziele? - 4. Kann die Komponente von mehreren Kundenservices genutzt werden? - 5. Gibt es operative Steuerungsnotwendigkeit? - 6. Ist die Komponente für Incident Management eigenständig relevant? - 7. Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen? - - Auswertung: - - 5+ Ja → Interner Service (Kategorie I) - - 3-4 Ja → Grenzfall, Entscheidung durch SPM/SOR - - 0-2 Ja → Passive Service-Komponente - - begruendung: | - Ohne Leitfaden würde die Einordnung zu subjektiv und nicht - reproduzierbar. Der Leitfaden ist Orientierung, kein Automatismus. - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" - pending_referenz: "PENDING-SPM-001, DC-005" - - # --------------------------------------------------------------------------- - - - id: "GOV-SOR-006" - datum: "2026-03-09" - quelle_modul: "SPM – Interne Services / SOR-Governance" - - frage: "Wer hat Stimmrecht bei SOR-Entscheidungen zu Internen Services?" - - entscheidung: | - Bei SOR-Entscheidungen, die Interne Services betreffen, haben - Stimmrecht: - 1. Der Service Owner des betroffenen Kundenservices (primär) - 2. Die Service Owner aller Internen Services, die den Kundenservice - maßgeblich beeinflussen - - Dies gilt für: Go-Live-Freigaben (Gate 2), Stilllegungsentscheidungen, - SLA/OLA-Anpassungen mit Cross-Service-Impact. - - Verfahren: Consent-basiert (Konsent), analog zur bestehenden - SOR-Geschäftsordnung. - - Operationalisierung: Die Aufnahme neuer Interner Services erfordert - keinen formalen Antragsprozess. Ein regulärer Tagesordnungspunkt - im SOR-Meeting ist ausreichend. - - begruendung: | - Interne Services stehen nicht direkt im Kundenverhältnis, aber ihre - Qualität bestimmt maßgeblich die Qualität der abhängigen - Kundenservices. Ohne Stimmrecht wären betroffene Service Owner - von relevanten Entscheidungen ausgeschlossen. - Die Entscheidung für einen Tagesordnungspunkt (statt formalem - Antragsprozess) vermeidet unnötige Bürokratie und nutzt die - bestehende SOR-Meetingstruktur. - - auswirkung_auf: - - dokument: "spm_sor_go.yaml" - abschnitt: "Stimmrecht / Entscheidungsverfahren" - - status: "final" - bestaetigt_durch: "Steuerungsrunde (Michael)" +governance_entscheidungen: + + - id: GOV-001 + datum: 2025-11-26 + quelle_modul: "P-02 Service Level Management" + + frage: "Wer verantwortet und entscheidet die Service-Kategorisierung (A/B/C)?" + + entscheidung: | + - Responsible: Service-Portfolio-Manager + - Accountable: Mission Board (Freigabe) + + begründung: | + Die Kategorisierung hat strukturelle Implikationen für Governance + (welches Gremium, welcher SLA-Typ). Das ist eine taktische + Portfolio-Entscheidung, keine operative SLM-Frage. Das Mission Board + als taktisches Entscheidungsgremium (AL + Abteilungsleiter) ist + die richtige Ebene. + + auswirkung_auf: + - dokument: "G-01 Portfolio Governance" + abschnitt: "Entscheidungsmatrix" + - dokument: "R-02 Service-Portfolio-Manager" + abschnitt: "Verantwortlichkeiten" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: GOV-002 + datum: 2025-11-26 + quelle_modul: "P-02 Service Level Management" + + frage: "Was ist der Eskalations- und Sanktionsmechanismus bei SLA-Verletzungen?" + + entscheidung: | + 1. Service Owner identifiziert systematische SLA-Verletzung + 2. Eskalation ins Mission Board + 3. Mission Board definiert gemeinsam mit Service Owner + verpflichtende Verbesserungsmaßnahmen + 4. Kommunikation an Usergroup und via SLS-Update + 5. Ultima Ratio: Sichtbarkeit auf OB-Ebene (Standing des Amtsleiters) + + begründung: | + Kein vertraglicher Sanktionsmechanismus (unrealistisch im + Verwaltungskontext), aber klare Governance-Konsequenz: + Verpflichtende Verbesserung mit Accountability auf + Amtsleitungsebene. + + auswirkung_auf: + - dokument: "G-01 Portfolio Governance" + abschnitt: "Eskalationswege" + - dokument: "G-02 SOR Geschäftsordnung" + abschnitt: "Schnittstelle zu Mission Board" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: GOV-003 + datum: 2025-11-26 + quelle_modul: "P-02 Service Level Management" + + frage: "Wie verhält sich der interne Service Review zum externen SLA Review?" + + entscheidung: | + Zwei-Stufen-Logik: + 1. Interner Service Review (Blueprint sr_02): + Service Owner → SOR → ggf. Mission Board + = Vorbereitung und interne Abstimmung + + 2. Externer SLA Review (neu zu modellieren): + Service Owner → Usergroup/Kunden-Gremium + = Kommunikation, Validierung, SLA-Anpassung + + begründung: | + Trennung von interner Steuerung (was können/wollen wir liefern?) + und externer Abstimmung (was brauchen die Kunden?). Der interne + Review ist Voraussetzung für den externen – nicht umgekehrt. + + auswirkung_auf: + - dokument: "B-03 service_review.yaml" + abschnitt: "Neue Aktivität: SLA Review mit Kunden" + - dokument: "P-02 Service Level Management" + abschnitt: "Review-Aktivitäten" + + status: "final" + + offene_fragen: + - "Modellierung der neuen Aktivität im Blueprint" + + # --------------------------------------------------------------------------- + + - id: GOV-004 + datum: 2025-11-26 + quelle_modul: "P-02 Service Level Management" + + frage: "Wer ist der SLA-Partner für Kategorie-A-Services (Basisversorgung)?" + + entscheidung: | + Konzeptionelle Anforderung an ein "Kundengremium Basisversorgung": + + 1. Repräsentiert die Kundenperspektive der Gesamtverwaltung + 2. Ist SLA-fähig (Entscheidungskompetenz für Leistungsvereinbarungen) + 3. Strukturvorschlag: + - Pflichtvertreter: Querschnittsämter (z.B. HPA, ggf. weitere) + - Wechselnde Vertreter: Rotation aus Fachämtern/Dezernaten + 4. Folgt der Usergroup-Logik (analog Kategorie B) + + Finale Besetzung und Verankerung: + Abstimmung mit Verwaltungsführung erforderlich. + + begründung: | + Konsistente Governance-Logik über alle Service-Kategorien: + Auch Kategorie A hat eine Usergroup – nur mit besonderer + Zusammensetzung wegen des Querschnittscharakters. + Pflichtvertreter sichern Kontinuität, wechselnde Vertreter + sichern Repräsentativität. + + auswirkung_auf: + - dokument: "G-01 Portfolio Governance" + abschnitt: "SLA-Partnerstruktur" + - dokument: "Konzept SLA/SLM" + abschnitt: "Gremienstruktur Kategorie A" + + status: "draft" # Finale Abstimmung mit Verwaltung ausstehend + + offene_fragen: + - "Welche Ämter sind 'Pflichtvertreter'?" + - "Rotationslogik für wechselnde Vertreter?" + - "Organisatorische Verankerung (wo angesiedelt)?" + + # --------------------------------------------------------------------------- + + - id: GOV-005 + datum: 2025-11-26 + quelle_modul: "P-02 Service Level Management" + + frage: "Wer darf als SLA-Partner für Kundenseite agieren?" + + entscheidung: | + SLA-Partner auf Kundenseite müssen Entscheidungsbefugnis haben: + + 1. Grundsatz: Amtsleiter:in des nutzenden Amtes + 2. Alternative: Explizit delegierte Person mit dokumentierter + Entscheidungsbefugnis (z.B. Abteilungsleiter:in, + Verwaltungsleiter:in des Amtes) + + Für Kategorie A und B gilt: + - Mitglieder der Kundenvertretung sind Amtsleitungen oder + deren delegierte Vertreter:innen + - Die Delegation muss dokumentiert sein + - Die Kundenvertretung ist kein "Anwenderforum", sondern + ein Entscheidungsgremium + + Terminologie: + - Kategorie A: "Kundenvertretung Basisservices" + - Kategorie B: "Kundenvertretung [Servicename]" + - Kategorie C: "Amtsleitung [Amt]" (bilateral) + + begründung: | + SLAs sind Governance-Instrumente, keine Nutzerfeedback-Runden. + Nur wer Entscheidungsbefugnis hat, kann verbindliche + Leistungsvereinbarungen abschließen. Die Delegation ermöglicht + Flexibilität, ohne die Legitimation zu untergraben. + + auswirkung_auf: + - dokument: "P-02 Service Level Management" + abschnitt: "Kernkonzepte, alle Aktivitäten mit SLA-Partner" + - dokument: "G-01 Portfolio Governance" + abschnitt: "SLA-Partnerstruktur" + - dokument: "Konzept SLA/SLM (Ideenskizze)" + abschnitt: "Abschnitte 4 und 6" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: GOV-006 + datum: 2025-11-27 + quelle_modul: "P-01 Service Catalog Management" + + frage: "Wer ist Practice Owner für Service Catalog Management?" + + entscheidung: | + Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM. + Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden. + + begruendung: | + SPM und SCM operieren beide auf Portfolio-Ebene und haben + natürliche Nähe. Eine Trennung ist langfristig möglich, + aber für die Einführungsphase nicht nötig. Die Konsolidierung + reduziert Komplexität bei der Einführung rollenbasierten Arbeitens. + + auswirkung_auf: + - dokument: "P-01 Service Catalog Management" + abschnitt: "metadata.practice_owner" + - dokument: "R-02 Service-Portfolio-Manager" + abschnitt: "Verantwortlichkeiten" + - dokument: "G-01 Portfolio Governance" + abschnitt: "Rollenübersicht" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-007 + datum: 2025-11-27 + quelle_modul: "P-01 Service Catalog Management" + + frage: "Wer erstellt die Service-Definition?" + + entscheidung: | + Der Service Owner ist verantwortlich (Accountable) für die Erstellung + der Service-Definition. SPM validiert und gibt frei. + + RACI: + - Service-Definition erstellen: SO (A/R), SPM (C) + - Service-Definition validieren: SPM (A/R), SO (C) + - Katalogeintrag freigeben: SPM (A) oder SOR (A) je nach Änderungstyp + + begruendung: | + ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung + für den Service. Die Service-Definition ist Teil dieser Verantwortung. + SCM stellt Methodik, Templates und Qualitätssicherung bereit, + aber die inhaltliche Verantwortung liegt beim SO. + + auswirkung_auf: + - dokument: "P-01 Service Catalog Management" + abschnitt: "aktivitaeten_transition" + - dokument: "R-01 Service Owner" + abschnitt: "Verantwortlichkeiten" + - dokument: "02.5_informationsmodell/spm_schema_service-definition.yaml" + abschnitt: "schema.verantwortung" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-008 + datum: 2025-11-27 + quelle_modul: "P-01 Service Catalog Management" + + frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?" + + entscheidung: | + Dreistufige Governance nach Impact: + + 1. Redaktionelle Änderungen: + - Beispiele: Tippfehler, Telefonnummer, Formatierung + - Entscheidung: Service Owner (autonom) + - Keine separate Freigabe nötig + + 2. Inhaltlich-minor: + - Beispiele: FAQ-Link, Klarstellung ohne Änderung, neue Doku-Referenz + - Entscheidung: Service Owner + SPM (bilateral) + - Freigabe: SPM + + 3. Inhaltlich-major / Neuaufnahme: + - Beispiele: Leistungsumfang, Service Levels, Zielgruppe + - Entscheidung: SOR + - Freigabe: SOR + + 4. Strukturell (Sonderfall): + - Beispiele: Kategorie-Wechsel, Stilllegung + - Entscheidung: Mission Board + + begruendung: | + Vermeidet Überlastung des SOR/MB mit Kleinstthemen. + Operative Themen werden operativ gelöst. Nur portfolio-relevante + Entscheidungen eskalieren. Die Logik entspricht dem Subsidiaritätsprinzip + und spiegelt die Änderungs-Governance in P-02 SLM. + + auswirkung_auf: + - dokument: "P-01 Service Catalog Management" + abschnitt: "aktivitaeten_betrieb.scm_05" + - dokument: "G-01 Portfolio Governance" + abschnitt: "Entscheidungsmatrix" + - dokument: "G-02 SOR Geschäftsordnung" + abschnitt: "Entscheidungsgegenstände" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-009 + datum: 2025-11-27 + quelle_modul: "P-01 Service Catalog Management" + + frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?" + + entscheidung: | + SHM wird eingebunden für die Prüfung der Kundenverständlichkeit + von Service-Steckbriefen. + + Im MVP ist dies optional (Empfehlung), da das SHM-Modul noch + in Entwicklung ist. + + Prozess: + - SO erstellt Service-Steckbrief + - SPM prüft Schema-Konformität und Konsistenz + - SHM prüft Kundenverständlichkeit (optional im MVP) + - SPM gibt frei + + begruendung: | + SHM hat die Kompetenz für Kundenperspektive und -sprache. + Die Einbindung vermeidet IT-zentrische Formulierungen und + erhöht die Akzeptanz des Katalogs bei den Ämtern. + Die Schnittstelle sollte etabliert werden, sobald SHM operativ ist. + + auswirkung_auf: + - dokument: "P-01 Service Catalog Management" + abschnitt: "aktivitaeten_transition.scm_02" + - dokument: "SHM Funktionsbeschreibung" + abschnitt: "3.2 Bedarfsaufbereitung und Routing" + + status: "draft" + + abhaengig_von: + - "Finalisierung SHM-Modul" + + offene_fragen: + - "Konkrete Qualitätskriterien für Verständlichkeit definieren" + - "Prüfprozess in SHM-Workflow integrieren" + + # --------------------------------------------------------------------------- + - id: GOV-010 + datum: 2025-11-27 + quelle_modul: "P-01 Service Catalog Management" + + frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?" + + entscheidung: | + Trennung von Inhalt und Betrieb: + + - SCM (SPM) verantwortet den INHALT des Katalogs + (Was steht drin? Ist es aktuell? Ist es korrekt?) + + - Der BETRIEB des Publikationskanals ist eine separate Verantwortung + (Webteam, IT-Betrieb, Kommunikation – je nach Kanal) + + Im MVP ist die konkrete Zuordnung noch zu klären. + + begruendung: | + SCM ist ein Managementprozess, kein Portal-Betrieb. + Die Vermischung würde SCM mit technischen Betriebsaufgaben + überfrachten und von der eigentlichen Aufgabe (Informations-Governance) + ablenken. Die Trennung ermöglicht auch verschiedene Publikationskanäle + (Intranet, ITSM-Tool, PDF) ohne SCM-Prozessänderung. + + auswirkung_auf: + - dokument: "P-01 Service Catalog Management" + abschnitt: "kernkonzepte.service_katalog.publikationskanaele" + - dokument: "G-01 Portfolio Governance" + abschnitt: "Verantwortungsmatrix" + + status: "draft" + + offene_fragen: + - "Wer ist konkret für Portal-Betrieb zuständig?" + - "Welcher Kanal wird primär verwendet (Intranet, Self-Service-Portal)?" + - "Wie erfolgt die Synchronisation mit ITSM-Tool?" + + # --------------------------------------------------------------------------- + - id: GOV-011 + datum: 2025-12-03 + quelle_modul: "SPM / SHM Harmonisierung" + + frage: | + Wie soll die Service-Kategorie B benannt werden, um terminologische + Konsistenz zwischen SPM (Service-Perspektive) und SHM (Amt-Perspektive) + herzustellen? + + entscheidung: | + Umbenennung von "Modular-Services" zu "Erweiterte Services" (Kategorie B). + + Begründung der Begriffswahl: + - "Modular" beschreibt die technische Architektur (zubuchbar, kombinierbar) + - "Erweitert" beschreibt die Beziehung zum Basis-Level + - "Erweitert" funktioniert für beide Perspektiven: + * SPM: Service erweitert die Basis-Ausstattung + * SHM: Amt hat erweiterte Anforderungen über Basis hinaus + + Die drei Kategorien heißen nun konsistent: + - Kategorie A: Basis-Services / Basis-Profil + - Kategorie B: Erweiterte Services / Erweitertes Profil + - Kategorie C: Spezial-Services / Spezial-Profil + + begruendung: | + Terminologische Konsistenz zwischen SPM und SHM reduziert + Begriffsverwirrung und ermöglicht einheitliche Kommunikation + über Funktionsgrenzen hinweg. + + auswirkung_auf: + - dokument: "P-02 Service Level Management" + abschnitt: "kernkonzepte.service_kategorien" + - dokument: "P-01 Service Catalog Management" + abschnitt: "kategorien_logik, katalog_views" + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "identitaet.service_kategorie" + - dokument: "readme_spm_vorgehen-entwicklung-spm-mvp-konzept.md" + abschnitt: "Arbeitsmaterialien" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-012 + datum: 2025-12-09 + quelle_modul: "P-02 Service Level Management + SHM Engagement-Framework" + + frage: | + Wie werden die Kundenvertretungen (SLM) mit den + Stakeholder-Management-Formaten (SHM) koordiniert? + + entscheidung: | + Integration zu einem "Kundenforum"-Konzept: + + Die Kundenvertretungen nach P-02 werden mit den SHM-Formaten + zusammengeführt. Das Kundenforum erfüllt beide Funktionen: + - SLA-Abstimmung und Review (SLM-Verantwortung) + - Beziehungspflege und Bedarfssammlung (SHM-Verantwortung) + + Die Governance-Kompetenz für SLA-Entscheidungen bleibt unverändert. + + begruendung: | + Konsistenz der Kundeninteraktion: Ein Gremium statt paralleler + Formate mit denselben Teilnehmern. Reduziert Aufwand für + Ämter und DIGIT, stärkt gemeinsame Außenwirkung. + + auswirkung_auf: + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "kundenvertretung" + - dokument: "shm_engagement-framework.yaml" + abschnitt: "kollektive_formate" + + status: "final" + + verweis: "GOV-SHM-015 (SHM-Governance-Log)" + +# =========================================================================== + # P-04/05/06 SERVICE-SUPPORT-MANAGEMENT (SSM) + # =========================================================================== + + - id: SSM-G-01 + datum: 2025-12-07 + quelle_modul: "Service-Support-Management / Klassifikation" + + frage: "Wer bestimmt die Priorität eines Tickets?" + + entscheidung: | + Service Desk (First Level) priorisiert nach verbindlicher + Impact-Urgency-Matrix. Eskalation bei Widerspruch an + Queue-Koordinator oder Teamleitung. + + Kunden können Dringlichkeit (Urgency) melden, aber nicht + die Priorität festlegen. Die Matrix ist nicht verhandelbar. + + begruendung: | + Aktuelle "4 low"-Monokultur verhindert sinnvolle Triage. + Regelbasierte Priorisierung ersetzt informelle Verhandlungen + und schafft Transparenz über Entscheidungsgrundlagen. + + auswirkung_auf: + - dokument: "ssm_klassifikation-priorisierung.yaml" + abschnitt: "grundprinzipien.autoritaet" + - dokument: "sub-practice_incident-management.yaml" + abschnitt: "Klassifikationsschritt (noch zu entwickeln)" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: SSM-G-02 + datum: 2025-12-07 + quelle_modul: "Service-Support-Management / Klassifikation" + + frage: "Ist die Impact-Urgency-Matrix verbindlich?" + + entscheidung: | + Die Impact-Urgency-Matrix ist verbindlich anzuwenden. + Abweichungen nur durch Queue-Koordinator oder Teamleitung + mit dokumentierter Begründung. + + begruendung: | + Nur verbindliche Anwendung schafft Vergleichbarkeit für + KPI-Auswertungen und verhindert subjektive Priorisierung. + Die Eskalationsmöglichkeit wahrt Flexibilität für Ausnahmen. + + auswirkung_auf: + - dokument: "ssm_klassifikation-priorisierung.yaml" + abschnitt: "governance.entscheidungen.KLASS-G-01" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: SSM-G-03 + datum: 2025-12-07 + quelle_modul: "Service-Support-Management / Klassifikation" + + frage: "Wie wird Explorative Diagnose legitimiert?" + + entscheidung: | + Analyse-Tickets legitimieren 90-120 Minuten Explorative + Diagnose. Voraussetzungen: + - Ticket ist als Charakteristik "ANALYSE" klassifiziert + - Dokumentation der Erkenntnisse ist verpflichtend + - Erkenntnisse werden in Wissensdatenbank überführt + + begruendung: | + Exploratives Arbeiten ist bei unbekannten Problemen notwendig + und fördert systematisches Lernen. Ohne explizite Legitimation + entsteht Rechtfertigungsdruck, der zu oberflächlichen Lösungen führt. + Die Dokumentationspflicht verhindert Missbrauch. + + auswirkung_auf: + - dokument: "ssm_klassifikation-priorisierung.yaml" + abschnitt: "ticket_charakteristik.charakteristiken.ANALYSE.explorative_diagnose" + - dokument: "ssm_design-zieldimensionen.yaml" + abschnitt: "LS-02 (Rollenverständnis)" + + referenz: + - dokument: "Lösungssäulen-Vision" + abschnitt: "Säule 2: Rollenverständnis" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: SSM-G-04 + datum: 2025-12-07 + quelle_modul: "Service-Support-Management / Klassifikation" + + frage: "Wie werden Langläufer-Tickets behandelt?" + + entscheidung: | + Tickets mit Laufzeit >20 Arbeitstage werden als "Langläufer" + gekennzeichnet und aus operativen KPIs (MTTR, FCR) exkludiert. + + Optionen nach Kennzeichnung: + 1. Umklassifikation zu PROJEKT (Pool-Wechsel) + 2. Verbleib mit separater Auswertung + + Die Kennzeichnung erfolgt automatisch durch das System. + + begruendung: | + Langläufer verzerren operative Metriken massiv. Die aktuelle + MTTR ist nicht aussagekräftig, weil Pseudo-Projekte mit + Incidents vermischt werden. Die Exklusion schafft + vergleichbare Kennzahlen für den Regelbetrieb. + + auswirkung_auf: + - dokument: "ssm_klassifikation-priorisierung.yaml" + abschnitt: "umklassifikation, pool_modell.pools.POOL-PROJEKT" + - dokument: "ssm_kennzahlen.yaml" + abschnitt: "(noch zu entwickeln)" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: SSM-G-05 + datum: 2025-12-07 + quelle_modul: "Service-Support-Management / Klassifikation" + + frage: "Welche SLA-Ziele gelten für die Prioritätsstufen?" + + entscheidung: | + Rahmenparameter für SLA-Ziele: + + | Prio | Reaktion | Lösung (Ziel) | Lösung (Max) | + |------|----------|---------------|--------------| + | P1 | 15 Min | 4h | 8h | + | P2 | 1h | 8h | 16h (2 AT) | + | P3 | 4h | 3 AT | 5 AT | + | P4 | 1 AT | 5 AT | 10 AT | + + Service-spezifische SLAs können abweichen; bei Abweichung + gilt die service-spezifische Vereinbarung. + + begruendung: | + Die Rahmenparameter schaffen einen Standard für den Fall, + dass kein service-spezifisches SLA existiert. Sie verhindern + willkürliche Erwartungshaltungen und ermöglichen messbare + Eskalationskriterien. + + auswirkung_auf: + - dokument: "ssm_klassifikation-priorisierung.yaml" + abschnitt: "prioritaetsstufen" + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "sla_typen (Referenz)" + + status: "draft" + + offene_fragen: + - "Abstimmung mit Service Owner für kritische Services" + - "Tool-Umsetzung der Eskalationstrigger" + + - id: "SSM-G-06" + name: "L1/L2-Grenzziehung" + entscheidung: | + L1 bearbeitet Tickets, solange: + 1. Dokumentation (KB) die Lösung ermöglicht UND + 2. L1-Agent die erforderlichen Berechtigungen hat + + Zusätzlich: Bei Analyse-Tickets ist Explorative Diagnose + (90-120 Min) erlaubt. + + Eskalation an L2 ist legitim, wenn: + - Keine passende Dokumentation vorhanden + - Lösung erfordert Berechtigungen außerhalb L1-Scope + - Explorative Diagnose ausgeschöpft ohne Fortschritt + - Komplexität übersteigt dokumentierten L1-Scope + + Eskalation erfordert "Definition of Handover" (DoH): + - Was wurde versucht? + - Welche KB-Artikel konsultiert? + - Beobachtungen/Erkenntnisse + - Eskalationsgrund + status: "vorgeschlagen" + + - id: "SSM-G-07" + name: "Ticket-Ownership-Prinzip" + entscheidung: | + Wer ein Ticket annimmt, ist verantwortlich bis: + a) Ticket ist geschlossen, ODER + b) Übergabe wurde vom Empfänger akzeptiert + + Regeln: + - Tickets ohne Owner (Status NEU nach Annahme) sind verboten + - "Zurücklegen" (Rückgabe an Queue ohne Empfänger) ist verboten + - "Parken" (Status WARTEN_*) ist erlaubt mit Begründung + + Ausnahme: + - L1 → L2 Domain Pool: Keine explizite Akzeptanz erforderlich + (Pool-Verantwortung wird durch Queue-Koordinator gesteuert) + - L2 → L1 Rückgabe: Akzeptanz + Begründung erforderlich + + Nicht-Akzeptanz innerhalb 4h: Auto-Eskalation an Queue-Koordinator + status: "vorgeschlagen" + + # --------------------------------------------------------------------------- + + - id: "SSM-G-17" + name: "(Reserviert)" + datum: "2025-12-07" + quelle_modul: "-" + + frage: "-" + + entscheidung: | + Diese ID ist reserviert für zukünftige Governance-Entscheidungen + im Request-Management-Kontext. + + begruendung: "Nummerierungskonsistenz" + + status: "reserviert" + kategorie: "Request Management" + + # --------------------------------------------------------------------------- + + - id: "SSM-G-18" + name: "Keine dedizierte Problem-Manager-Rolle" + datum: "2025-12-07" + quelle_modul: "sub-practice_problem-management.yaml" + + frage: "Brauchen wir eine dedizierte Problem-Manager-Rolle?" + + entscheidung: | + Im MVP gibt es keine dedizierte Problem-Manager-Rolle. + Der Service Owner ist Process Owner für Problem Management + in seinem Service-Bereich. Operative Tätigkeiten können an + Second Level Agents delegiert werden. + + begruendung: | + Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs- + strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung + für die Service-Qualität. ITIL4 warnt explizit davor, Problem + Management als separate Funktion aufzubauen. + + auswirkung_auf: + - dokument: "sub-practice_problem-management.yaml" + abschnitt: "organisationsmodell" + - dokument: "ssm_rollen.yaml" + abschnitt: "service_owner, second_level_agent" + + status: "vorgeschlagen" + kategorie: "Rollenmodell" + + # --------------------------------------------------------------------------- + + - id: "SSM-G-19" + name: "Problem Management nur reaktiv im MVP" + datum: "2025-12-07" + quelle_modul: "sub-practice_problem-management.yaml" + + frage: "Welche Problem-Identifikationswege werden im MVP unterstützt?" + + entscheidung: | + Problem-Identifikation erfolgt im MVP ausschließlich reaktiv + aus dem Incident Management (nicht lösbare oder wiederkehrende + Incidents). Proaktive Problem-Identifikation (YaSM LP4.7.1) ist + nicht im Scope. + + begruendung: | + MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt + die Datenbasis (Incident-Trends, Monitoring-Integration). + Kann in späteren Ausbaustufen ergänzt werden. + + auswirkung_auf: + - dokument: "sub-practice_problem-management.yaml" + abschnitt: "aktivitaeten.PRB-01" + + status: "vorgeschlagen" + kategorie: "Scope" + + offene_fragen: + - "Ausbaustufe 2: Trend-Analyse und proaktive Identifikation?" + + # --------------------------------------------------------------------------- + + - id: "SSM-G-20" + name: "Known Errors als KB-Artikel" + datum: "2025-12-07" + quelle_modul: "sub-practice_problem-management.yaml" + + frage: "Wie werden Known Errors dokumentiert?" + + entscheidung: | + Known Errors werden als KB-Artikel mit speziellem Typ + (KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert. + Es wird keine separate Known Error Database (KEDB) geführt. + + begruendung: | + Integration in bestehendes Wissensmanagement, vermeidet + Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen + ohnehin in der KB – Known Errors werden so automatisch gefunden. + + auswirkung_auf: + - dokument: "sub-practice_problem-management.yaml" + abschnitt: "kernkonzepte.known_error" + - dokument: "ssm_wissensmanagement.yaml" + abschnitt: "known_error_artikel" + + status: "vorgeschlagen" + kategorie: "Wissensmanagement" + +# ============================================================================= +# TMP-BAUSTEIN: Governance-Entscheidungen Service Transition (AP-01 + AP-02) +# ============================================================================= +# Zur Integration in: spm_governance-entscheidungen-log.yaml +# Arbeitspakete: AP-01 Gate-Struktur, AP-02 Entscheidungskriterien +# Datum: 2025-12-17 +# ============================================================================= + +metadata: + beschreibung: > + Zusammenstellung aller Governance-Entscheidungen aus den Arbeitspaketen + AP-01 (Gate-Struktur) und AP-02 (Entscheidungskriterien) für die + Integration in das zentrale SPM Governance-Entscheidungs-Log. + + id_bereich: "GOV-TR-001 bis GOV-TR-012" + + referenzen: + ap_01: "[tmp]_ap-01_gate-struktur.yaml" + ap_02: "[tmp]_ap-02_entscheidungskriterien.yaml" + ziel: "spm_governance-entscheidungen-log.yaml" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-01: GATE-STRUKTUR +# ============================================================================= + +entscheidungen_ap_01: + + # --------------------------------------------------------------------------- + - id: GOV-TR-001 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Was ist ein 'Gate' im DIGITOM-Kontext?" + + entscheidung: | + Ein Gate ist ein formaler Entscheidungspunkt im Lifecycle, der kombiniert: + - Prüfkriterien (Was muss erfüllt sein?) + - Gate-Keeper (Wer entscheidet?) + - Entscheidungsoptionen (Welche Ergebnisse sind möglich?) + - Dokumentation (Wie wird die Entscheidung festgehalten?) + + begruendung: | + Ein Gate nur als Checkliste hat keine Steuerungswirkung – es wird zum + bürokratischen Durchwinken. Ein Gate nur als Entscheidung ohne Prüfkriterien + wird beliebig. Die Kombination stellt sicher, dass es objektive Kriterien + gibt UND jemand die Verantwortung für die Freigabe übernimmt. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates" + - dokument: "SPM Glossar" + abschnitt: "Gate-Definition" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-002 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Wie viele Gates hat die Service Transition und wer ist Gate-Keeper?" + + entscheidung: | + Zwei-Gate-Modell: + - Gate 1 "Entry Transition": Gate-Keeper ist Service Owner + - Gate 2 "Go-Live-Freigabe": Gate-Keeper ist Service Operations Runde (SOR) + + begruendung: | + Gate 1 ist eine operative Entscheidung des SO (fachlich-inhaltlich). + Gate 2 ist eine Governance-Entscheidung der SOR (Portfolio-Perspektive). + Die Trennung spiegelt die Verantwortungslogik: SO verantwortet den Service, + SOR verantwortet das Portfolio. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Entscheidungsgegenstände" + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Entscheidungsbefugnisse" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-003 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Für welche Service-Änderungen gilt die Gate-Struktur?" + + entscheidung: | + Major Changes erfordern eine einmalige SOR-Autorisierung. Die SOR entscheidet + in einem Schritt, ob der Major Change durchgeführt werden darf, und legt dabei + den Einstiegspunkt im Lifecycle fest. Nach der Autorisierung durchläuft der + Major Change den regulären Service-Lifecycle einschließlich der üblichen + Transition-Gates (inkl. Gate 3 für Go-Live). + + Die Gate-Struktur gilt für: + - Neue Services (erstmalige Aktivierung) + - Major Changes an bestehenden Services + + Minor Changes laufen über Change Enablement (Standard/Normal Change). + + Major-Kriterien: + - Änderung der Service-Definition (Scope, Zielgruppe, Kernfunktionalität) + - Änderung der SLA/SLO-Vereinbarungen + - Signifikante Architektur-Änderung + - DPM-Klassifizierung "komplex" oder "hochkomplex" + + begruendung: | + Die Gate-Struktur ist Governance-Overhead, der sich nur bei signifikanten + Veränderungen rechtfertigt. Für Minor Changes wäre das unverhältnismäßig. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Geltungsbereich" + - dokument: "P-03 Change Enablement" + abschnitt: "Major/Minor-Abgrenzung" + + status: "final" + + offene_punkte: + - "Major/Minor-Abgrenzung muss mit P-03 Change Enablement synchronisiert werden" + + # --------------------------------------------------------------------------- + - id: GOV-TR-004 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Wann muss ein Service Owner für einen neuen Service benannt sein?" + + entscheidung: | + Zweistufige Regelung: + + 1. Empfehlung: Frühzeitige Benennung bei/kurz nach Projektfreigabe + - SPM identifiziert und schlägt vor + - SO wird als Consulted in Projektentscheidungen eingebunden + + 2. Harter Constraint: Spätestens bei Gate 1 + - SO ist Gate-Keeper für Gate 1 + - Ohne SO kann Gate 1 nicht durchgeführt werden + + Formale Bestätigung: SOR bestätigt SO bei Gate 2 (Go-Live-Freigabe) + + Fallback: Bei fehlendem SO-Kandidaten eskaliert SPM an Abteilungsleitung + (spätestens 4 Wochen vor geplantem Gate 1) + + begruendung: | + Ein harter Constraint bei Projektfreigabe kann zum Bottleneck werden. + Die Empfehlung zur frühzeitigen Benennung bleibt, aber der unbedingte + Zwang liegt erst bei Gate 1. + + auswirkung_auf: + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Benennung und Bestätigung" + - dokument: "R-SPM Rollenbeschreibung" + abschnitt: "Mandat SO-Identifikation" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "SO-Bestätigung" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-005 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Welche Entscheidungsergebnisse sind an den Gates möglich?" + + entscheidung: | + Vierstufige Entscheidungsoptionen analog DSR-Verfahren: + + Gate 1 (SO): + - Freigabe + - Freigabe mit Auflagen + - Zurückweisung + - Eskalation an SOR + + Gate 2 (SOR): + - Go-Live-Freigabe + - Go-Live mit Auflagen + - Zurück an Transition + - Service-Ablehnung + + begruendung: | + Das DSR-Entscheidungsverfahren kennt bereits differenzierte Optionen. + Diese Logik auf die Gates zu übertragen schafft Konsistenz und reduziert + Lernaufwand. Die Vierstufigkeit ermöglicht differenzierte Steuerung – + besonders "Freigabe mit Auflagen" verhindert, dass kleine Mängel den + gesamten Prozess blockieren. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates / Entscheidungsoptionen" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Entscheidungsverfahren" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-006 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Wie ist die Verantwortungsübergabe PL → SO geregelt?" + + entscheidung: | + Modell "Überlappungszone mit differenzierter Accountability": + + - Projektphase (bis Gate 1): PL ist A/R, SO ist C (falls benannt) + - Überlappungszone (Gate 1 bis Gate 2): + - PL: A/R für Projekt-Deliverables + - SO: A/R für Service-Scope + - Betrieb (ab Gate 2): SO ist A/R, Projekt abgeschlossen + + Formaler Übergabepunkt: Mit positivem Gate 1 geht die Service-Accountability + auf den SO über. PL bleibt für Projekt-Deliverables verantwortlich bis + Projektabschluss (nach Gate 2, spätestens Ende ELS). + + begruendung: | + In der Transition-Phase gibt es eine Überlappung – das Projekt läuft + möglicherweise noch, aber der Service geht bereits Richtung Betrieb. + Klare Abgrenzung ist erforderlich, um Verantwortungslücken zu vermeiden. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Verantwortungsübergang" + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Accountability-Übernahme" + - dokument: "service-lifecycle_service-transition.yaml" + abschnitt: "RACI" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-007 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Ist der Pilot ein eigenständiges Gate?" + + entscheidung: | + Nein. Die Pilot-Entscheidung ist kein eigenständiges Gate, sondern ein + Routing innerhalb von Gate 1. + + Der SO prüft im Entry-Gate, ob ein Pilot erforderlich ist, und legt + ggf. die Pilot-Parameter fest. Der Pilot ist eine optionale Phase + zwischen Gate 1 und Gate 2. + + begruendung: | + Ein drittes Gate würde Overhead erzeugen. Die Pilot-Entscheidung ist + Teil der Entry-Prüfung – der SO kennt seinen Service und kann + einschätzen, ob ein Pilot nötig ist. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Pilot-Konzept" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-008 + datum: "2025-12-16" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" + + frage: "Ist ELS-Exit ein formales Gate?" + + entscheidung: | + Nein. Der Übergang von ELS in den Normalbetrieb ist kein formales Gate, + sondern eine SO-Entscheidung mit Orientierungsprinzipien. + + Der SO entscheidet, wann ELS endet, und dokumentiert dies im + Service-Steckbrief oder informiert die SOR. + + begruendung: | + Ein drittes Gate würde Overhead erzeugen. ELS ist eine + Stabilisierungsphase, deren Ende der SO am besten einschätzen kann. + Formale Governance ist hier nicht erforderlich. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + + status: "final" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-02: ENTSCHEIDUNGSKRITERIEN +# ============================================================================= + +entscheidungen_ap_02: + + # --------------------------------------------------------------------------- + - id: GOV-TR-009 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" + + frage: "Wie werden die Gate-Kriterien gestaltet – prinzipienbasiert oder checklistenbasiert?" + + entscheidung: | + Prinzipienbasierter Ansatz für beide Gates (MVP). + + Grundsatz: "Informed Judgment statt mechanische Prüfung" + + Der Gate-Keeper trifft eine Gesamtbewertung auf Basis definierter + Prüfdimensionen. Die Dimensionen geben die Richtung vor, ohne jeden + Einzelfall vorab zu regeln. + + begruendung: | + Für den MVP ist ein prinzipienbasierter Ansatz angemessen. Detaillierte + Checklisten erzeugen Governance-Overhead ohne nachgewiesenen Mehrwert. + Die operative Erfahrung wird zeigen, wo Präzisierung nötig ist. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates / Prüfdimensionen" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-010 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" + + frage: "Welche Prüfdimensionen gelten für Gate 1 (Entry Transition)?" + + entscheidung: | + Drei Prüfdimensionen: + + 1. Übergabe-Vollständigkeit (Showstopper) + Kernfrage: "Liegt alles vor, was ich für die Transition brauche?" + + 2. Betriebsvorbereitung (kein Showstopper) + Kernfrage: "Sind Betrieb und Support informiert und vorbereitet?" + + 3. Pilot-Erfordernis (Routing-Entscheidung) + Kernfrage: "Braucht dieser Service einen Pilot vor Go-Live?" + + Nachweisform: Formlos, aber dokumentiert (kurze Notiz, E-Mail, Protokolleintrag) + + begruendung: | + Minimale Prüfdimensionen für den MVP. Nur Übergabe-Vollständigkeit ist + Showstopper, da ohne Artefakte keine sinnvolle Transition möglich ist. + Betriebsvorbereitung kann mit Auflagen nachgeholt werden. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Gate 1 / Prüfdimensionen" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-011 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" + + frage: "Welche Prüfdimensionen gelten für Gate 2 (Go-Live-Freigabe)?" + + entscheidung: | + Fünf Prüfdimensionen: + + 1. SO-Readiness-Bestätigung (Showstopper) + Kernfrage: "Hat der SO die Betriebsreife bestätigt?" + + 2. Betriebs-/Support-Dokumentation (Showstopper) + Kernfrage: "Ist die Dokumentation vorhanden UND implementiert?" + "Implementiert" bedeutet: verfügbar, bekannt, zugänglich + + 3. Portfolio-Passung (Showstopper) + Kernfrage: "Kein Widerspruch zu bestehenden Services?" + MVP-Interpretation: Minimale Prüfung (Variante A) + + 4. Ressourcen-Commitment (kein Showstopper) + Kernfrage: "Haben Betrieb und Support die Kapazität bestätigt?" + + 5. Auflagen aus Gate 1 (Showstopper, falls vorhanden) + Kernfrage: "Falls Auflagen existieren: Sind diese erfüllt?" + + Nachweisform: Teil des SOR-Protokolls + + begruendung: | + Gate 2 hat mehr Showstopper, da es die finale Freigabe für das + Portfolio ist. Insbesondere die Dokumentations-Dimension wurde + geschärft: "vorhanden" reicht nicht, "implementiert" ist erforderlich. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Gate 2 / Prüfdimensionen" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Go-Live-Entscheidung" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-012 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" + + frage: "Was bedeutet 'Portfolio-Passung' bei Gate 2?" + + entscheidung: | + Variante A (minimale Prüfung): + + "Kein Widerspruch zu bestehenden Services" – im Zweifel passt es. + + Kein aktiver Strategie-Fit-Nachweis erforderlich, nur Abwesenheit + von Konflikten. + + begruendung: | + Für den MVP ist eine niedrige Hürde angemessen. Governance-Overhead + gering halten. Variante B (aktive Strategie-Prüfung) macht Sinn, + wenn das Portfolio wächst und Priorisierungskonflikte entstehen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Gate 2 / Portfolio-Passung" + + status: "final" + +# ============================================================================= +# ZUSAMMENFASSUNG +# ============================================================================= + +zusammenfassung: + + anzahl_entscheidungen: 24 + + nach_arbeitspaket: + ap_01: 8 + ap_02: 4 + ap_03: 4 + ap_04: 5 + ap_05: 3 + ap_06: 4 + + nach_status: + final: 24 + draft: 0 + + offene_abhaengigkeiten: + - id: "GOV-TR-003" + abhaengigkeit: "Synchronisation mit P-03 Change Enablement (Major/Minor)" + + betroffene_module: + - "konzept_service-transition.yaml" + - "G-SOR Geschäftsordnung" + - "R-SO Rollenbeschreibung" + - "R-SPM Rollenbeschreibung" + - "service-lifecycle_service-transition.yaml (Blueprint)" + - "SPM Glossar" + - "P-03 Change Enablement" + +entscheidungen_ap_03: + + # --------------------------------------------------------------------------- + - id: GOV-TR-011 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" + + frage: "Nach welchem Verfahren entscheidet die SOR bei Gate 2?" + + entscheidung: | + Vereinfachtes Konsent-Verfahren: + + - Grundprinzip: Konsent (Beschluss gilt ohne schwerwiegenden Einwand) + - Bei Einwand: Vertagung, SO muss Vorlage überarbeiten + - Bei erneutem Einwand: SOR kann eskalieren (MB) oder ablehnen + - Kein Alternativzwang für einwendende Rolle + + Das Verfahren gilt für alle SOR-Entscheidungen (Gate 2, Routing, + Service-Anpassungen). + + begruendung: | + Gate-2-Entscheidungen sind operativ-taktisch. Das DSR-Konsent-Verfahren + mit iterativem Alternativzwang ist für Routinefreigaben überdimensioniert. + + Die Überarbeitungspflicht liegt beim SO (nicht bei der einwendenden Rolle), + weil der SO für den Service accountable ist. Das vereinfacht das Verfahren + und stärkt die SO-Verantwortung. + + auswirkung_auf: + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Entscheidungsverfahren" + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates / Gate 2" + + status: "final" + + abgrenzung_zu_dsr: | + Unterschied zur DSR-GO: Kein Alternativzwang, keine feste Iterationsgrenze. + Gemeinsamkeit: Konsent als Grundprinzip, Eskalation an MB möglich. + + # --------------------------------------------------------------------------- + - id: GOV-TR-012 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" + + frage: "Wie werden Auflagen bei 'Freigabe mit Auflagen' gehandhabt?" + + entscheidung: | + Protokoll-basiertes Tracking: + + 1. Formulierung: Gate-Keeper formuliert Auflagen (konkret, mit Frist, + mit Verantwortlichem) + + 2. Dokumentation: Im Gate-Protokoll (SOR-Protokoll für Gate 2) + + 3. Tracking: + - Gate-1-Auflagen: SO bestätigt Erfüllung in Gate-2-Vorlage, + SOR prüft bei Gate 2 + - Gate-2-Auflagen: SO dokumentiert im Steckbrief, + SOR prüft bei ELS-Ende + + 4. Bei Nicht-Erfüllung: + - Vor Folgegate: Gate kann nicht positiv entschieden werden + - Im ELS: ELS kann nicht beendet werden + + begruendung: | + Ein formales Auflagen-Register würde Overhead ohne nachgewiesenen Nutzen + erzeugen. Das Protokoll-basierte Tracking nutzt bestehende Strukturen + (SOR-Protokoll, Service-Steckbrief) und etabliert eine klare Prüflogik. + + Auflagen sind verbindlich (nicht nur Empfehlungen) – die Integration + in die Gate-Logik sichert die Durchsetzung. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates / Auflagen" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Protokollierung" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-013 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" + + frage: "Wie wird Gate 1 bei SO-Abwesenheit gehandhabt?" + + entscheidung: | + Verschiebung mit Eskalationsoption: + + 1. Regelfall (kurzfristige Abwesenheit bis 4 Wochen): + - Gate 1 wird verschoben bis SO verfügbar ist + - Keine automatische Vertretung + + 2. Ausnahme bei Dringlichkeit: + - SPM beurteilt, ob Verzögerung kritisch wäre + - SPM kann an SOR eskalieren + - SOR entscheidet dann Gate 1 + Gate 2 gemeinsam + + 3. Längere Vakanz (über 4 Wochen): + - SOR entscheidet über Interim-SO oder Neubenennung + - SPM bringt Vorschlag ein + + Keine Pflicht zur präventiven Stellvertreter-Benennung (nur Empfehlung). + + begruendung: | + Der SO ist persönlich accountable für Gate-1-Entscheidungen. Eine + automatische Stellvertretung würde diese Accountability verwässern. + + Die Verschiebung ist in den meisten Fällen unproblematisch. Die + Eskalationsoption sichert Handlungsfähigkeit bei echten Dringlichkeiten, + ohne eine Pflicht zur Stellvertreter-Benennung zu erzeugen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Quality Gates / Gate 1 / Vertretung" + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Vertretung" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-014 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" + + frage: "Wie werden Gate-Entscheidungen vorbereitet?" + + entscheidung: | + Steckbrief-Integration mit Pflichtfeldern: + + 1. Vorlage-Dokument: Service-Steckbrief (erweitert um Gate-Readiness) + + 2. Verantwortlich: + - Gate 1: PL erstellt, SO gibt frei + - Gate 2: SO erstellt und reicht ein + + 3. Pflichtinhalte Gate 1: + - Service-Bezeichnung und Version + - Kurzbeschreibung des Service-Scopes + - Benannter Service Owner + - Abnahme durch Auftraggeber + - Bekannte Einschränkungen oder Risiken + - Pilot-Empfehlung + + 4. Pflichtinhalte Gate 2: + - Erfüllung Gate-1-Auflagen + - Betriebsbereitschaft (bestätigt) + - Support-Bereitschaft (bestätigt) + - Pilot-Ergebnis (falls durchgeführt) + - SLA/SLO-Entwurf + - Katalog-Eintrag-Entwurf + + 5. Einreichungsfrist: 3 Arbeitstage vor SOR-Sitzung + + 6. Vollständigkeitsprüfung durch SPM bei Einreichung + + begruendung: | + Der Service-Steckbrief existiert bereits und wird ohnehin gepflegt. Die + Integration vermeidet Doppelarbeit und stellt Konsistenz sicher. + + Die 3-Tage-Frist ermöglicht Tagesordnungs-Erstellung und Vorab-Prüfung. + Unvollständige Vorlagen werden nicht in der Sitzung diskutiert, um + Sitzungszeit zu schonen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Gate-Vorbereitung" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Sitzungsvorbereitung" + - dokument: "spm_schema_service-steckbrief.yaml" + abschnitt: "Gate-Readiness (neuer Abschnitt)" + + status: "final" + + - id: GOV-TR-013 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" + + frage: "Wie wird ELS zeitlich parametrisiert?" + + entscheidung: | + Hybrid-Korridor mit drei Parametern: + - Mindestdauer: 2 Wochen (verbindlich) + - Regeldauer: 4 Wochen (Orientierung) + - Maximaldauer: 8 Wochen (Eskalations-Trigger) + + Innerhalb des Korridors entscheidet SO zustandsbasiert anhand + der Exit-Kriterien. Vor Ablauf der Mindestdauer ist kein Exit + möglich, auch bei Stabilität. + + begruendung: | + Der Hybrid-Ansatz balanciert SO-Ermessen (Governance-Prinzip + "Informed Judgment") mit operativer Planbarkeit. Er vermeidet + die Extreme von mechanischem Zeitablauf und völliger Beliebigkeit. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + + status: "final" + + validierungshinweis: | + ACHTUNG: Alle Zeitwerte (2/4/8 Wochen) sind MVP-ANNAHMEN. + Erforderlich: + - Bestätigung vor MVP-Start mit DIGIT-Stakeholdern + - Bewertung während MVP-Phase anhand konkreter Fälle + - Ggf. Anpassung nach ersten operativen Erfahrungen + + # --------------------------------------------------------------------------- + - id: GOV-TR-014 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" + + frage: "Wie ist die Projektverfügbarkeit während ELS geregelt?" + + entscheidung: | + Gestaffelte Übergabe mit abnehmender Intensität: + + Phase 1 (ELS-Woche 1-2): + - Verfügbarkeit: verpflichtend + - Reaktionszeit: 4 Stunden (Geschäftszeiten) + - Umfang: Troubleshooting, Wissenstransfer, Bug-Fixes + + Phase 2 (ab ELS-Woche 3): + - Verfügbarkeit: auf Abruf + - Reaktionszeit: 2 Arbeitstage + - Umfang: Nur dokumentierte Eskalationsfälle (Severity 1-2) + + Projekt-Exit frühestens nach Mindestdauer (2 Wochen). + Abruf-Verfügbarkeit für 4 Wochen nach Projekt-Exit. + + begruendung: | + Realistischer Kompromiss zwischen Projekt-Abschlussdruck und + Absicherung der kritischen Phase. Korrespondiert mit ELS-Dauer-Logik + (Phase 1 = Mindestdauer). Verantwortung (A) bleibt beim SO. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + + status: "final" + + validierungshinweis: | + ACHTUNG: Zeiträume und Reaktionszeiten sind MVP-ANNAHMEN. + Erforderlich: + - Prüfung der Kompatibilität mit DIGIT-Projektbudget-/Ressourcenlogik + - Bestätigung vor MVP-Start + - Bewertung anhand konkreter Fälle + + # --------------------------------------------------------------------------- + - id: GOV-TR-015 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" + + frage: "Was ist eine 'kritische Störung' im ELS-Kontext?" + + entscheidung: | + Minimaldefinition für ELS-Exit-Bewertung: + + Eine Störung gilt als kritisch, wenn BEIDE Kriterien erfüllt sind: + + (1) Nutzbarkeitseinschränkung: + Service ist für wesentliche Nutzergruppe (>20% oder + geschäftskritisch) nicht oder nur stark eingeschränkt nutzbar. + + (2) Kein Workaround: + Es existiert kein praktikabler Workaround, der die + Einschränkung kompensiert. + + Bei Grenzfällen entscheidet SO und dokumentiert Einschätzung. + + begruendung: | + Operationalisierbar ohne vollständige Severity-Klassifikation. + Vermeidet Abhängigkeit von SSM-Entwicklung. Anschlussfähig an + spätere Severity-Klassifikation (entspricht dort Severity 1-2). + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + - dokument: "SSM Incident Management" + abschnitt: "Severity-Klassifikation" + hinweis: "Konsistenzprüfung bei SSM-Finalisierung erforderlich" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-016 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" + + frage: "Wie wird das ELS-Ende dokumentiert?" + + entscheidung: | + Leichtgewichtiger ELS-Vermerk im Service-Steckbrief. + Kein separater Abschlussbericht erforderlich. + + Pflichtfelder: + - els_start (Datum) + - els_ende (Datum) + - els_dauer_wochen (Zahl) + - kritische_stoerungen_anzahl (Zahl) + - exit_begruendung (Kurztext, max. 500 Zeichen) + + Optionales Feld: + - lessons_learned (Kurztext) + + Erweiterung bei Auffälligkeiten (>6 Wochen ODER >2 krit. Störungen): + - ursachenanalyse (Pflicht) + - massnahmen_fuer_zukunft (Pflicht) + + begruendung: | + Passt zu leichtgewichtiger Governance ("kein formales Gate"). + Vermeidet Artefakt-Inflation durch Integration in Steckbrief. + Stellt Nachweisbarkeit für ersten Service Review sicher. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + - dokument: "spm_schema_service-steckbrief.yaml" + abschnitt: "Neue Felder: els_verlauf" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-017 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" + + frage: "Was passiert bei Überschreitung der ELS-Maximaldauer?" + + entscheidung: | + Automatische Eskalation an SOR bei Überschreitung der Maximaldauer + (8 Wochen). + + Mechanismus: + - SPM überwacht ELS-Dauern + - Bei Überschreitung: Pflicht-Agenda-Punkt in nächster SOR + - SO bereitet Sachstandsbericht vor (Frist: 3 AT vor SOR) + + SOR-Entscheidungsoptionen: + (1) ELS-Verlängerung (max. 4 Wochen, mit neuem Zieldatum) + (2) Rückführung in Transition (neuer Gate-2-Antrag erforderlich) + (3) Zwangs-Exit (mit dokumentierter Risiko-Akzeptanz durch SOR) + (4) Service-Stilllegung (nur in Extremfällen) + + Bei erneuter Überschreitung nach Verlängerung: erneute Eskalation. + + begruendung: | + Überschreitung der Maximaldauer signalisiert Problem, das + SO-Kompetenz übersteigt. SOR als Portfolio-Governance ist + richtiger Adressat. Definierte Optionen geben klaren + Handlungsrahmen und vermeiden Endlos-Schleifen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "ELS-Konzept" + - dokument: "spm_sor-geschaeftsordnung.yaml" + abschnitt: "Standard-Agenda-Punkte" + hinweis: "ELS-Eskalation als möglichen Punkt aufnehmen" + + status: "final" + + - id: GOV-TR-018 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" + + frage: "Was bedeutet 'Zurück an Transition' bei Gate-2-Zurückweisung operativ?" + + entscheidung: | + SO-Verantwortung mit Zeitrahmen: + + 1. Verantwortlichkeit: + - SO verantwortet die Mängelbeseitigung + - SO entscheidet über Wiedervorlage-Zeitpunkt + - SPM überwacht Fristen + + 2. Zeitrahmen: + - Standardfrist: 8 Wochen für Wiedervorlage + - Verlängerung durch SOR möglich (begründeter Antrag) + - Eskalation an SOR nach 10 Wochen ohne Wiedervorlage + + 3. Status: + - Service bleibt in "in_transition" + - Keine formale Statusänderung + + 4. Dokumentation: + - Zurückweisungsgründe im SOR-Protokoll + - Erwartete Wiedervorlage (Datum/KW) + + begruendung: | + Schlanke Variante ohne Bürokratie-Overhead. Nutzt die bestehende + SO-Accountability für den Service-Erfolg. Die Zeitbegrenzung verhindert + "Zombie-Services", die endlos in der Transition-Schleife bleiben. + + Keine formale Statusänderung, da der Service konzeptionell weiterhin + "in Transition" ist – nur mit identifizierten Nachbesserungsbedarfen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Rollback-Szenarien / Gate-2-Zurückweisung" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Protokollierung / Zurückweisungen" + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Verantwortlichkeiten / Nachbesserung" + + status: "final" + + confidence: "75%" + + unsicherheit: | + Die 8-Wochen-Frist ist eine Orientierung. Je nach Art der Mängel + kann mehr oder weniger Zeit erforderlich sein. Die Frist sollte + als Richtwert, nicht als harter Constraint verstanden werden. + + # --------------------------------------------------------------------------- + - id: GOV-TR-019 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" + + frage: "Wer kann während ELS einen Service stoppen, und wie?" + + entscheidung: | + SO-Einzelentscheidung mit Informationspflicht: + + 1. Entscheidungskompetenz: + - SO hat Mandat zur Einzelentscheidung "Service-Stopp" + - Keine vorherige SOR-Abstimmung erforderlich + - Begründung ist erforderlich + + 2. Kommunikationspflichten: + Unverzüglich: + - SPM (koordiniert SOR-Behandlung) + - Support Manager (Nutzer-Kommunikation) + - Operations Manager (technische Deaktivierung) + + Innerhalb 24h: + - SOR (alle Mitglieder) per E-Mail + + 3. Folgezustand: + - Service-Status wird "suspended" + - Katalog zeigt "temporär nicht verfügbar" + + 4. Nächste Schritte: + - SOR-Behandlung innerhalb 5 Werktagen + - SOR entscheidet: Wiederaufnahme / Zurück an Transition / Ablehnung + + begruendung: | + In einer Krisensituation muss jemand handlungsfähig sein – das ist der SO + als Accountable für den Service-Erfolg. Die Informationspflicht stellt + sicher, dass die SOR involviert wird, ohne dass sie zum Bottleneck wird. + + Wichtig: Ein Service-Stopp ist ein Qualitätssicherungsinstrument, keine + Schuldzuweisung. SOs sollten diese Kompetenz bei Bedarf nutzen. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Rollback-Szenarien / ELS-Rollback" + - dokument: "R-SO Rollenbeschreibung" + abschnitt: "Entscheidungsbefugnisse / Service-Stopp" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Außerordentliche Behandlung" + + status: "final" + + confidence: "70%" + + unsicherheit: | + Die Governance allein löst nicht die Frage, ob SOs diese Kompetenz + auch tatsächlich wahrnehmen werden. Es besteht das Risiko, dass SOs + aus Angst vor Gesichtsverlust zu lange warten. Das ist eine kulturelle + Frage, die das Modell nicht allein adressieren kann. + + abgrenzung: | + Ein Service-Stopp ist NICHT die Reaktion auf einzelne Incidents. + Incidents werden über das reguläre Incident Management behandelt. + Ein Service-Stopp ist angezeigt, wenn der Service als Ganzes seinen + Zweck nicht erfüllt und keine kurzfristige Lösung absehbar ist. + + # --------------------------------------------------------------------------- + - id: GOV-TR-020 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" + + frage: "Gibt es eine formale Iterationsgrenze für Zurückweisungen bei Gate 2?" + + entscheidung: | + MVP: Keine formale Grenze – situative SOR-Entscheidung. + + 1. Grundsatz: + - Die SOR entscheidet bei jeder Zurückweisung situativ + - Keine automatischen Trigger für Service-Ablehnung + - Keine feste Anzahl erlaubter Iterationen + + 2. Orientierungshilfe für SOR: + Bei jeder Zurückweisung sollte die SOR prüfen: + - Sind die Probleme grundsätzlich lösbar? + - Sind Ressourcen für weitere Iteration verfügbar? + - Ist die strategische Passung noch gegeben? + - Wie lange ist der Service schon in Transition? + - Wie viele Zurückweisungen gab es bereits? + + 3. Empfehlung: + Ab der dritten Zurückweisung sollte die SOR explizit begründen, + warum eine Fortsetzung noch sinnvoll ist – oder Service-Ablehnung + beschließen. + + begruendung: | + Für den MVP ist eine situative Entscheidung angemessen. Die Praxis wird + zeigen, ob und wann formale Grenzen nötig sind. Zu frühe Formalisierung + könnte entweder zu starr sein (verhindert sinnvolle Fortsetzungen) oder + zu weich (verhindert nötige Abbrüche). + + Das Risiko von "Zombie-Services" ist bekannt und muss von der SOR aktiv + gemanagt werden. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Rollback-Szenarien / Projekt-Termination" + - dokument: "G-SOR Geschäftsordnung" + abschnitt: "Service-Ablehnung" + + status: "final" + + confidence: "65%" + + unsicherheit: | + Ohne formale Grenzen besteht das Risiko von "Zombie-Services", die + endlos in der Transition-Schleife bleiben. Die SOR muss dieses Risiko + aktiv managen. + + evolutionspfad: | + Bei Praxisproblemen (Zombie-Services, Willkür-Vorwürfe, Entscheidungs- + Paralyse) sollte das Modell weiterentwickelt werden zu: + + "Option D: Kombiniertes Modell" + - Nach 2. Zurückweisung: Pflicht-Analyse durch SPM + - Nach 3. Zurückweisung ODER nach 6 Monaten: Default = Ablehnung + - Fortsetzung nur durch expliziten SOR-Beschluss mit Begründung + + Indikatoren für Weiterentwicklung: + - Services länger als 6 Monate in Transition ohne Fortschritt + - SOR-Mitglieder beklagen fehlende Orientierung + - Wahrnehmung von Willkür bei Ablehnungsentscheidungen + - Ressourcenkonflikte durch zu viele parallele Transition-Services + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-06: BEGRIFFLICHE HARMONISIERUNG +# ============================================================================= + +entscheidungen_ap_06: + + # --------------------------------------------------------------------------- + - id: GOV-TR-021 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" + + frage: "Was bedeutet 'Aktivierung' im Service-Transition-Kontext?" + + entscheidung: | + Einheitsmodell: "Aktivierung" ist ein atomarer Akt, der durch die + Go-Live-Freigabe (Gate 2) ausgelöst wird und gleichzeitig bewirkt: + + (1) Statusübergang des Services auf lifecycle_status = "aktiv" + (2) Sichtbarkeit des Services im Service-Katalog + (3) Bestellbarkeit/Nutzbarkeit des Services durch berechtigte Nutzer + + Es gibt KEINE Trennung zwischen "Portfolio-Aufnahme" und + "Katalog-Aktivierung" bei Go-Live. + + begruendung: | + Kein validierter Use Case für eine Trennung bei Aktivierung. + MVP-Prinzip: Komplexität nur bei nachgewiesenem Bedarf. + Die Governance ist klar: SOR entscheidet einmalig, alle Effekte folgen. + + abgrenzung: | + "Aktivierung" bezeichnet nicht: + - Die Gate-2-Entscheidung selbst (diese heißt "Go-Live-Freigabe") + - Die technische Bereitstellung (diese heißt "Deployment" oder "Rollout") + - Die Aufnahme in Governance-Strukturen (implizit durch Gate 2) + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Begriffsklärungen" + - dokument: "service-lifecycle_service-transition.yaml" + abschnitt: "st_04 Begrifflichkeit" + + status: "final" + validierungsstatus: "MVP-Annahme, Workshop-Validierung empfohlen" + + # --------------------------------------------------------------------------- + - id: GOV-TR-022 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" + + frage: "Wie wird der Service-Status modelliert?" + + entscheidung: | + Zwei-Status-Modell: + + (1) Dokumenten-Status (metadata.status): entwurf / freigegeben / archiviert + Beschreibt die Gültigkeit der Service-Definition als Dokument. + + (2) Lifecycle-Status (lifecycle.lifecycle_status): + in_entwicklung / in_transition / aktiv / in_stilllegung / + stillgelegt / abgebrochen + Beschreibt die Phase des Services im Service-Lifecycle. + + Beide Status sind unabhängig, aber es gibt Korrelationsregeln + (z.B. lifecycle_status = "aktiv" erfordert status = "freigegeben"). + + begruendung: | + Die bisherige Vermischung von Dokumenten- und Lifecycle-Status führte + zu semantischer Verwirrung. Das Zwei-Status-Modell trennt sauber: + - Informationsmanagement-Perspektive (Dokument) + - Lifecycle-Management-Perspektive (Service) + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "Neuer Abschnitt 'lifecycle'" + - dokument: "service-lifecycle_service-transition.yaml" + abschnitt: "Status-Referenzen korrigieren" + + status: "final" + schema_patch: "Erforderlich – lifecycle-Abschnitt hinzufügen" + + # --------------------------------------------------------------------------- + - id: GOV-TR-023 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" + + frage: "Wie verhalten sich Service-Portfolio und Service-Katalog zueinander?" + + entscheidung: | + Hierarchisches Modell: Der Katalog ist eine Teilmenge des Portfolios. + + - Service-Portfolio: Gesamtheit aller Services in DIGIT-Verantwortung, + unabhängig vom Lifecycle-Status. Governance-Objekt der SOR. + + - Service-Katalog: Gefilterte Sicht auf das Portfolio mit + lifecycle_status = "aktiv". Für Kunden sichtbar. + + Der Katalog ist kein separates Register, sondern eine View auf das + Portfolio. "Aufnahme ins Portfolio" und "Aktivierung im Katalog" + sind bei Go-Live ein und derselbe Vorgang. + + Portfolio-Struktur: + - Pipeline: lifecycle_status in (in_entwicklung, in_transition) + - Katalog: lifecycle_status = aktiv + - In Stilllegung: lifecycle_status = in_stilllegung + - Retired: lifecycle_status = stillgelegt + + begruendung: | + ITIL4-konforme Trennung wäre konzeptionell richtig, aber für MVP + zu aufwändig. Das hierarchische Modell bietet konzeptionelle Klarheit + bei operativer Einfachheit. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Begriffsklärungen" + - dokument: "spm_practice_service-catalog-management.yaml" + abschnitt: "Katalog-Definition" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-024 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" + + frage: "Werden die ITIL4-Begriffe 'Release' und 'Deployment' übernommen?" + + entscheidung: | + Begriffe übernehmen, aber keine formale Prozess-Trennung im MVP. + + - Release: Versionspaket, das zur Bereitstellung vorbereitet wurde. + Erstellung ist Teil der Service-Entwicklung (SE). + + - Deployment: Technischer Vorgang der Installation in Zielumgebung. + Ist Aktivität in Service Transition (st_02). + + - Rollout: DIGITOM-Alltagsbegriff für die integrative Bereitstellung, + die Release-Übergabe und Deployment umfasst. + + Im MVP werden Release Management und Deployment Management NICHT + als separate Practices modelliert. + + begruendung: | + Die ITIL4-Begriffe sind branchenetabliert – sie zu vermeiden erzeugt + Reibung mit externen Stakeholdern. Eine formale Prozess-Trennung ist + für DIGIT aktuell nicht erforderlich. Bei wachsender Komplexität + kann später differenziert werden. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Begriffsklärungen / Glossar" + + status: "final" + revisionshinweis: | + Bei komplexeren Release-Zyklen (z.B. eigenentwickelte Fachverfahren) + sollte die Entscheidung revidiert werden. + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN AUS AP-07: TRANSITION-ARTEFAKTE +# ============================================================================= +# Zur Integration in: spm_governance-entscheidungen-log.yaml +# Arbeitspaket: AP-07 Transition-Artefakte definieren +# Datum: 2025-12-17 +# ============================================================================= + +entscheidungen_ap_07: + + # --------------------------------------------------------------------------- + - id: GOV-TR-025 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" + + frage: "Wie werden die Transition-Artefakte dokumentiert – verteilt in verschiedenen Dokumenten oder konsolidiert?" + + entscheidung: | + Einführung eines eigenständigen "Transition-Steckbriefs" als + konsolidiertes Prozessdokument. + + Der Transition-Steckbrief: + - Wird bei Übergabe aus Service-Entwicklung angelegt + - Dokumentiert alle Gate-Entscheidungen (Gate 1, Gate 2) + - Enthält Pilot-Entscheidung und -Ergebnisse (falls relevant) + - Dokumentiert den ELS-Verlauf + - Enthält eine Abschluss-Checkliste + - Wird bei ELS-Exit abgeschlossen + + Der Transition-Steckbrief ersetzt die ursprünglich geplanten + Schema-Erweiterungen für den Service-Steckbrief (gate_readiness, + els_verlauf) sowie die separaten Artefakte "Transition-Checkliste", + "Betriebsreife-Nachweis" und "ELS-Vermerk". + + begruendung: | + Ein konsolidiertes Dokument bietet mehrere Vorteile: + + 1. Kohärenz: Alle Transition-Informationen an einem Ort statt + verstreut über Steckbrief-Erweiterungen und Gate-Protokolle + + 2. Nachweisbarkeit: Vollständige Dokumentation des Transition- + Prozesses für Service Review und Audit + + 3. Prozess-Analogie: Konsistent mit dem Bedarfs-Steckbrief im + Demand-Lifecycle, der ebenfalls ein temporäres Prozessdokument + ist und nach Abschluss überführt wird + + 4. Klarheit: Eliminiert Phantom-Artefakte und begriffliche + Unschärfen (z.B. "Betriebsreife-Nachweis" vs. "SO-Readiness") + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Artefakte" + aenderung: "Neuer Abschnitt 'Transition-Steckbrief' mit Verweis auf Schema" + + - dokument: "spm_schema_transition-steckbrief.yaml" + abschnitt: "Gesamtes Dokument" + aenderung: "Neues Schema-Dokument erstellen" + + - dokument: "AP-01 bis AP-06 (TMP-Files)" + abschnitt: "Diverse" + aenderung: "Begriffe werden bei Konsolidierung (AP-09) ersetzt" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-026 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" + + frage: "Was passiert mit dem Transition-Steckbrief nach Abschluss der Transition?" + + entscheidung: | + Nach Abschluss der Transition (ELS-Exit) wird der Transition- + Steckbrief als Anhang in den Service-Steckbrief überführt. + + Überführungsprozess: + 1. SO schließt Transition-Steckbrief ab (Status: "abgeschlossen") + 2. Transition-Steckbrief wird als Anhang an Service-Steckbrief + gehängt (Abschnitt: "transition_historie" oder als verlinktes + Dokument) + 3. Wesentliche Kennzahlen (ELS-Dauer, kritische Störungen) werden + in Service-Steckbrief-Metadaten übernommen + + Der Transition-Steckbrief bleibt als historisches Dokument + erhalten und wird nicht gelöscht. + + begruendung: | + Die Überführung stellt sicher, dass: + + 1. Der Service-Steckbrief das "lebende Dokument" bleibt und nicht + mit Prozess-Details überfrachtet wird + + 2. Die Transition-Historie für Service Review verfügbar ist + + 3. Bei späteren Änderungen (Re-Transition) ein neuer Transition- + Steckbrief angelegt werden kann, ohne den alten zu überschreiben + + Das Muster entspricht dem Bedarfs-Steckbrief → Demand-Steckbrief + Übergang im DPM. + + auswirkung_auf: + - dokument: "spm_schema_service-steckbrief.yaml" + abschnitt: "anhaenge oder transition_historie" + aenderung: "Feld für Transition-Steckbrief-Referenz ergänzen" + + - dokument: "konzept_service-transition.yaml" + abschnitt: "Artefakte > Lifecycle" + aenderung: "Überführungsprozess dokumentieren" + + status: "final" + + # --------------------------------------------------------------------------- + - id: GOV-TR-027 + datum: "2025-12-17" + quelle_modul: "K-TR Rahmenkonzept Service Transition" + quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" + + frage: "Welche bisherigen Artefakt-Begriffe werden durch den Transition-Steckbrief ersetzt?" + + entscheidung: | + Folgende Begriffe werden eliminiert bzw. ersetzt: + + ERSETZT DURCH TRANSITION-STECKBRIEF: + - "Transition-Checkliste" → Transition-Steckbrief.abschluss_checkliste + - "Betriebsreife-Nachweis" → Transition-Steckbrief.gate_2.so_readiness + - "SO-Readiness-Bestätigung" → Transition-Steckbrief.gate_2.so_readiness + - "ELS-Vermerk" → Transition-Steckbrief.els + - "ELS-Abschlussbericht" → Transition-Steckbrief.els + - "Gate-1-Nachweis" → Transition-Steckbrief.gate_1 + - "Pilot-Entscheidung" → Transition-Steckbrief.gate_1.pilot_entscheidung + - "Steckbrief.gate_readiness" → Transition-Steckbrief (separates Dokument) + - "Steckbrief.els_verlauf" → Transition-Steckbrief.els + + BLEIBT UNVERÄNDERT: + - "Go-Live-Protokoll" = Teil des SOR-Protokolls (kein separates Artefakt) + - "Auflagen-Dokumentation" = Teil des jeweiligen Gate-Protokolls + - "Sachstandsbericht" = Nur bei Eskalation, separate SOR-Vorlage + + EXTERNE ARTEFAKTE (nicht K-TR-Scope): + - "Betriebshandbuch" → Input aus Service-Entwicklung + - "Testprotokolle" → Input aus Service-Entwicklung + - "SLA/SLO-Vereinbarung" → Definiert in P-02 SLM + - "Katalog-Eintrag" → Definiert in P-01 SCM + + begruendung: | + Die begriffliche Konsolidierung beseitigt Redundanzen und + Phantom-Artefakte, die in der bisherigen Dokumentation entstanden + sind. Ein klares Mapping erleichtert die Konsolidierung (AP-09) + und verhindert Inkonsistenzen im finalen Konzept. + + auswirkung_auf: + - dokument: "konzept_service-transition.yaml" + abschnitt: "Gesamtes Dokument" + aenderung: "Begriffe bei Konsolidierung ersetzen" + + - dokument: "AP-01 bis AP-06 (TMP-Files)" + abschnitt: "Diverse" + aenderung: "Mappings bei AP-09 berücksichtigen" + + konsolidierungshinweis: | + Bei der YAML-Konsolidierung (AP-09) ist dieses Mapping als + Referenz zu verwenden. Die TMP-Files werden nicht einzeln + gepatcht, sondern die Begriffe werden bei der Überführung in + das finale Konzept ersetzt. + + status: "final" + +# ============================================================================= +# K-SR KONZEPT SERVICE-REVIEW +# ============================================================================= + +entscheidungen_service_review: + + - id: GOV-SR-001 + datum: "2025-12-17" + quelle_modul: "K-SR Konzept Service-Review" + + frage: "Anhand welcher Dimensionen und mit welcher Methodik bewertet der SO den Service-Zustand?" + + entscheidung: | + 4-Dimensionen-Modell mit qualitativer Ampelbewertung: + - SR-D1: Leistungserbringung (Liefert der Service den erwarteten Nutzen?) + - SR-D2: Betriebsstabilitaet (Laeuft der Service stoerungsarm?) + - SR-D3: Nutzerzufriedenheit (Wie bewerten die Nutzer den Service?) + - SR-D4: Zukunftsfaehigkeit (Ist der Service mittelfristig tragfaehig?) + + Bewertungsskala: Gruen (stabil) / Gelb (beobachten) / Rot (Handlungsbedarf) + Keine mathematische Aggregation - SO fasst zu Gesamteinschaetzung zusammen. + + begruendung: | + - Strukturelle Analogie zu SHM (VoC-Cluster D1-D4) schafft Modellkonsistenz + - Qualitative Bewertung realistisch bei fehlender KPI-Infrastruktur + - Ampellogik intuitiv und entscheidungsvorbereitend + - SO kann Verfahren in 30-60 Min/Quartal durchfuehren + - Erweiterbar: Spaetere KPIs koennen als Indikatoren einfliessen + + auswirkung_auf: + - dokument: "spm_schema_service-steckbrief.yaml" + abschnitt: "review_status" + - dokument: "service-lifecycle_service-review.yaml" + abschnitt: "sr_02" + + status: "final" + confidence: "80%" + + # --------------------------------------------------------------------------- + + - id: GOV-SR-002 + datum: "2025-12-17" + quelle_modul: "K-SR Konzept Service-Review" + + frage: "In welchem Rhythmus findet der Service-Review statt und wie verhaelt er sich zu SOR?" + + entscheidung: | + Hybridmodell: + 1. SO fuehrt quartalsweise Selbst-Review durch (eigenstaendig) + 2. SO aktualisiert Service-Definition mit Review-Ergebnis (Abschnitt 'service_review') + 3. SO informiert SPM (alle Review-Berichte, unabhaengig vom Ergebnis) + 4. SOR-Einbeziehung nur bei: + - Mind. eine Dimension "Rot" + - Handlungsempfehlung: IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE + - SO ist unsicher + 5. Anlassbezogener Ad-hoc-Review bei Major Incident, SLA-Verletzung, Eskalation + + begruendung: | + - Skaliert mit Portfolio-Groesse (nicht jeder Service braucht SOR-Zeit) + - SO behaelt Eigenverantwortung (Subsidiaritaetsprinzip) + - SPM hat Portfolio-Uebersicht fuer Aggregation und Muster-Erkennung + - SOR fokussiert auf Ausnahmen (Management by Exception) + - Konsistent mit E2-Quartalsrhythmus im SHM + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "service_review" + - dokument: "rolle_service-owner.yaml" + abschnitt: "verantwortlichkeiten" + - dokument: "spm_rollen.yaml" + abschnitt: "service_portfolio_manager" + + status: "final" + confidence: "85%" + + # --------------------------------------------------------------------------- + + - id: GOV-SR-003 + datum: "2025-12-17" + quelle_modul: "K-SR Konzept Service-Review" + + frage: "Gibt es objektive Schwellenwerte fuer automatische Handlungen oder Eskalation?" + + entscheidung: | + Orientierungskriterien mit Urteilsvorbehalt: + - Kriterien definieren typische Konstellationen fuer jeden Entscheidungspfad + - Keine automatischen Trigger - finales Urteil beim SO + - Bei Abweichung von Orientierung: Begruendungspflicht (2-3 Saetze) + + Typische Konstellationen: + - CONTINUE: Alle Gruen oder max. eine Gelb + - IMPROVEMENT: Eine/mehrere Rot, im Service-Rahmen loesbar + - REDESIGN: Mehrere Rot ueber Quartale, Architektur-Problem + - RETIRE: Kaum genutzt, unverhaeltnismaessiger Aufwand + + begruendung: | + - Konsistent mit SHM-Logik (qualitative Trigger mit Begruendungspflicht) + - Vermeidet Schein-Objektivitaet durch nicht vorhandene Datenbasis + - Erhaelt Flexibilitaet fuer Service-spezifische Kontexte + - Begruendungspflicht bei Abweichung sichert Governance-Qualitaet + + auswirkung_auf: + - dokument: "konzept_service-review.yaml" + abschnitt: "entscheidungspfade" + + status: "final" + confidence: "75%" + + # --------------------------------------------------------------------------- + + - id: GOV-SR-004 + datum: "2025-12-17" + quelle_modul: "K-SR Konzept Service-Review" + + frage: "Wie laeuft die SOR-Behandlung eines Service-Reviews konkret ab?" + + entscheidung: | + Differenziertes Verfahren nach Handlungsempfehlung: + + 1. Kenntnisnahme (keine SOR-Agenda): + - CONTINUE + - IMPROVEMENT (SO-gefuehrt, ressourcenneutral) + -> SO dokumentiert im Steckbrief, informiert SPM + + 2. Operative Entscheidung (SOR-Behandlung): + - IMPROVEMENT (ressourcenrelevant) + -> SO reicht Review-Vorlage ein, SOR entscheidet (Konsens) + + 3. Strategische Entscheidung (SOR-Behandlung): + - REDESIGN, RETIRE + -> SOR entscheidet, bei Freigabe Uebergabe an DPM + -> Bei Dissens/Tragweite: Eskalation an MB + + Vorlage-Anforderungen: Einreichung 3 AT vor Sitzung an SPM + + begruendung: | + - Fokussiert SOR-Zeit auf Entscheidungen, die Governance erfordern + - CONTINUE und kleine IMPROVEMENTs sind SO-Verantwortung (Subsidiaritaet) + - Nur ressourcen-/portfoliorelevante Entscheidungen brauchen Gremiumszeit + + auswirkung_auf: + - dokument: "spm_sor-geschaeftsordnung.yaml" + abschnitt: "entscheidungsgegenstaende" + - dokument: "rolle_service-owner.yaml" + abschnitt: "befugnisse" + + status: "final" + confidence: "80%" + + # --------------------------------------------------------------------------- + + - id: GOV-SR-005 + datum: "2025-12-17" + quelle_modul: "K-SR Konzept Service-Review" + + frage: "Wie wird die Wirksamkeit von Improvement-Massnahmen nachgehalten?" + + entscheidung: | + MVP-Loesung: Service-Definition-Tracking + + 1. Improvement-Massnahmen werden in der Service-Definition dokumentiert + (Abschnitt "laufende_verbesserungen") + 2. Pflichtfelder: ID, Beschreibung, Ziel-Dimension, Verantwortlich, + Termin, Status + 3. Im naechsten Quartals-Review: SO prueft Wirksamkeit + (Hat sich betroffene Dimension verbessert?) + 4. Keine separate CI-Infrastruktur im MVP + + Post-MVP: Dedizierte CI-Practice mit zentralem Improvement-Register + + begruendung: | + - Minimal Viable: Kein neues Tooling/Practice erforderlich + - Governance-Anker: Service-Definition + Review-Zyklus sichert Nachverfolgung + - Erweiterbar: Bei CI-Practice-Etablierung kann migriert werden + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "laufende_verbesserungen" + + status: "final" + confidence: "70%" + + - id: "GOV-CE-001" + datum: "2025-12-17" + quelle_modul: "P-03 Change Enablement" + + frage: "Wie werden Emergency Changes gehandhabt?" + + entscheidung: | + Sofortumsetzung durch Betrieb/Support mit nachträglicher Dokumentation. + Service Owner wird informiert, nicht um Genehmigung gefragt. + + Dokumentation innerhalb 24 Stunden. + + begruendung: | + Bei kritischen Sicherheits- oder Verfügbarkeitsproblemen ist + Geschwindigkeit entscheidend. Ein Genehmigungsprozess würde + Schaden vergrößern. Die nachträgliche Dokumentation stellt + Nachvollziehbarkeit sicher. + + auswirkung_auf: + - dokument: "spm_practice_change-enablement.yaml" + abschnitt: "change_typen.emergency_change" + + status: "final" + + - id: "GOV-CE-002" + datum: "2025-12-17" + quelle_modul: "P-03 Change Enablement" + + frage: "Gilt Change Enablement für Infrastruktur ohne Service-Bezug?" + + entscheidung: | + Nein. Fokus auf Service-Changes. Infrastruktur ohne direkten + Service-Bezug (z.B. Netzwerk-Basis) ist der Produkt-Ebene + zuzuordnen und wird in dieser Phase nicht adressiert. + + begruendung: | + Die aktuelle Projektphase priorisiert die Kunden-/Service-Sicht. + Produkt-Management ist nicht im Fokus. Eine Vermischung würde + den Scope aufblähen ohne Mehrwert für die priorisierten Ziele. + + auswirkung_auf: + - dokument: "spm_practice_change-enablement.yaml" + abschnitt: "einordnung.abgrenzung_produkt" + + vermerk: | + Bei späterer Produkt-Konzeption: Change Enablement für + Produkte/Infrastruktur ergänzen. + + status: "final" + + - id: "GOV-CE-003" + datum: "2025-12-17" + quelle_modul: "P-03 Change Enablement" + + frage: "Wie wird Cross-Service-Impact bei Normal Changes erkannt und behandelt?" + + entscheidung: | + Service Owner ist verantwortlich für Erkennung von Cross-Service-Impact. + SPM wird als "Zweite Augen" einbezogen bei Changes mit potenziellem + Cross-Service-Impact. + + Schwellenwert: SO-Ermessen ("Im Zweifel SPM einbeziehen"). + Keine formalen Schwellenwerte im MVP. + + begruendung: | + Der SO kennt seinen Service und dessen Abhängigkeiten am besten. + SPM bringt die Portfolio-Perspektive ein, ohne den SO zu entmündigen. + Formale Schwellenwerte würden Gaming fördern und Bürokratie erzeugen. + + auswirkung_auf: + - dokument: "spm_practice_change-enablement.yaml" + abschnitt: "change_typen.normal_change.cross_service" + + status: "final" + + # =========================================================================== + # INTERNE SERVICES – bestätigt März 2026 (PENDING-SPM-001) + # =========================================================================== + + - id: "GOV-SPM-I-001" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services" + + frage: "Soll das Kategorienmodell um Interne Services erweitert werden?" + + entscheidung: | + Das Kategorienmodell wird von drei auf vier Werte erweitert: + - A: Basis-Services (Kundenservice, Katalog-sichtbar) + - B: Erweiterte Services (Kundenservice, Katalog-sichtbar) + - C: Spezial-Services (Kundenservice, Katalog-sichtbar) + - I: Interne Services (kein Kundenservice, NICHT im Katalog) + + Interne Services sind vollwertige Governance-Objekte mit eigenem + Service Owner, eigenem SLA-Typ (OLA), eigener Service-Definition + und Teilnahme am Service-Lifecycle. + + begruendung: | + Infrastruktur-Komponenten wie Active Directory oder der Netzwerk-Backbone + sind für die Qualität von Kundenservices kritisch, werden aber bisher + nicht systematisch gesteuert. Kategorie I ermöglicht Governance ohne + Katalog-Überfrachtung. + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "identitaet.service_kategorie" + - dokument: "service-portfolio-management_glossar.yaml" + abschnitt: "Interner Service" + - dokument: "spm_practice_service-catalog-management.yaml" + abschnitt: "kategorien_logik" + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" + pending_referenz: "PENDING-SPM-001, DC-001" + + # --------------------------------------------------------------------------- + + - id: "GOV-SPM-I-002" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services" + + frage: "Welcher SLA-Typ gilt für Interne Services?" + + entscheidung: | + Für Interne Services (Kategorie I) gilt ein Operational Level Agreement + (OLA) anstelle eines SLA. Das OLA-Feld bleibt während der Pilotphase + leer (kein Placeholder-Wert). Die Begründung wird einmalig in der + Pilot-Scope-Dokumentation festgehalten. + + begruendung: | + ITIL4-konforme Terminologie. OLAs sind der etablierte Begriff für + interne Leistungsvereinbarungen zwischen Betriebseinheiten. + Trennung von SLA (extern) und OLA (intern) schafft konzeptionelle + Klarheit ohne Mehraufwand. + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "qualitaet.service_level_referenz" + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "kernkonzepte.dokument_typen" + - dokument: "service-portfolio-management_glossar.yaml" + abschnitt: "OLA" + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" + pending_referenz: "PENDING-SPM-001, DC-002" + + # --------------------------------------------------------------------------- + + - id: "GOV-SPM-I-003" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services" + + frage: "Soll service_sichtbarkeit als eigenständiges Attribut geführt werden?" + + entscheidung: | + Das Attribut service_sichtbarkeit wird nicht eingeführt (bzw. ersatzlos + gestrichen, falls vorhanden). Die Sichtbarkeit ist vollständig aus der + service_kategorie ableitbar: + - Kategorie A, B, C → im Katalog sichtbar + - Kategorie I → NICHT im Katalog (per Definition) + + begruendung: | + Designprinzip "Encode rationale once". Redundante Attribute erhöhen + Pflegeaufwand und schaffen Widerspruchspotenzial. + + auswirkung_auf: + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "identitaet (kein neues Attribut)" + - dokument: "service-portfolio-management_glossar.yaml" + abschnitt: "Service-Sichtbarkeit" + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" + pending_referenz: "PENDING-SPM-001, DC-003" + + # --------------------------------------------------------------------------- + + - id: "GOV-SPM-I-004" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services" + + frage: "Soll ein eigenständiges Produkt-Konzept eingeführt werden?" + + entscheidung: | + Das Konzept "Produkt" als eigenständige Kategorie oder Governance-Objekt + wird nicht eingeführt. Infrastruktur-Komponenten werden entweder als + Interne Services (Kategorie I) oder als passive Service-Komponenten + behandelt. Die Abgrenzung erfolgt gemäß dem Sieben-Fragen-Leitfaden + (GOV-SPM-I-005). + + begruendung: | + Das Produkt-Konzept hätte eine dritte Governance-Ebene (neben Services + und Komponenten) eingeführt ohne klaren Mehrwert gegenüber dem + erweiterten Service-Modell. + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" + pending_referenz: "PENDING-SPM-001, DC-004" + + # --------------------------------------------------------------------------- + + - id: "GOV-SPM-I-005" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services" + + frage: "Wie wird zwischen Internem Service und passiver Komponente abgegrenzt?" + + entscheidung: | + Sieben-Fragen-Orientierungsleitfaden: + 1. Gibt es einen identifizierbaren internen "Kunden"? + 2. Gibt es eine verantwortliche Rolle für Service-Owner-Funktion? + 3. Hat die Komponente eigene, unabhängig definierbare Qualitätsziele? + 4. Kann die Komponente von mehreren Kundenservices genutzt werden? + 5. Gibt es operative Steuerungsnotwendigkeit? + 6. Ist die Komponente für Incident Management eigenständig relevant? + 7. Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen? + + Auswertung: + - 5+ Ja → Interner Service (Kategorie I) + - 3-4 Ja → Grenzfall, Entscheidung durch SPM/SOR + - 0-2 Ja → Passive Service-Komponente + + begruendung: | + Ohne Leitfaden würde die Einordnung zu subjektiv und nicht + reproduzierbar. Der Leitfaden ist Orientierung, kein Automatismus. + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" + pending_referenz: "PENDING-SPM-001, DC-005" + + # --------------------------------------------------------------------------- + + - id: "GOV-SOR-006" + datum: "2026-03-09" + quelle_modul: "SPM – Interne Services / SOR-Governance" + + frage: "Wer hat Stimmrecht bei SOR-Entscheidungen zu Internen Services?" + + entscheidung: | + Bei SOR-Entscheidungen, die Interne Services betreffen, haben + Stimmrecht: + 1. Der Service Owner des betroffenen Kundenservices (primär) + 2. Die Service Owner aller Internen Services, die den Kundenservice + maßgeblich beeinflussen + + Dies gilt für: Go-Live-Freigaben (Gate 2), Stilllegungsentscheidungen, + SLA/OLA-Anpassungen mit Cross-Service-Impact. + + Verfahren: Consent-basiert (Konsent), analog zur bestehenden + SOR-Geschäftsordnung. + + Operationalisierung: Die Aufnahme neuer Interner Services erfordert + keinen formalen Antragsprozess. Ein regulärer Tagesordnungspunkt + im SOR-Meeting ist ausreichend. + + begruendung: | + Interne Services stehen nicht direkt im Kundenverhältnis, aber ihre + Qualität bestimmt maßgeblich die Qualität der abhängigen + Kundenservices. Ohne Stimmrecht wären betroffene Service Owner + von relevanten Entscheidungen ausgeschlossen. + Die Entscheidung für einen Tagesordnungspunkt (statt formalem + Antragsprozess) vermeidet unnötige Bürokratie und nutzt die + bestehende SOR-Meetingstruktur. + + auswirkung_auf: + - dokument: "spm_sor_go.yaml" + abschnitt: "Stimmrecht / Entscheidungsverfahren" + + status: "final" + bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-006" \ No newline at end of file diff --git a/#02_service-portfolio-management/service-portfolio-management_glossar.yaml b/#02_service-portfolio-management/service-portfolio-management_glossar.yaml index 5c09764..c3c93c7 100644 --- a/#02_service-portfolio-management/service-portfolio-management_glossar.yaml +++ b/#02_service-portfolio-management/service-portfolio-management_glossar.yaml @@ -1,215 +1,215 @@ -metadata: - version: "3.7" - datum: "2026-03-09" - quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)" - basis: "ITIL4 / DIGITOM Begriffsüberleitung" - hinweis: > - Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf, - ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu - eins in das DIGIT Service-Management Framework passen (Übernehmen), - ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder - modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext - keinen erkennbaren Mehrwert bieten (Weglassen). - -glossar: - - begriff: "Anforderung" - definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen." - synonyme: ["Requirement", "Vorgabe"] - - - begriff: "Anwender*in" - definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)." - synonyme: ["Nutzer*in", "User"] - - - begriff: "Auftraggeber*in" - definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert." - - - begriff: "Bedarf" - definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient." - - - begriff: "Change" - definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change." - synonyme: ["Änderung"] - - - begriff: "Configuration Item (CI)" - definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt." - - - begriff: "Demand" - definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann." - - - begriff: "Demand-Steckbrief" - definition: | - Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert - den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der - Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben. - abgrenzung: - - "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe" - - "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen" - - - begriff: "Emergency-Change" - definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben." - - - begriff: "Ergebnis" - definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird." - synonyme: ["Outcome"] - - - begriff: "Gewährleistung" - definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")." - synonyme: ["Qualitätszusage", "Warranty"] - - - begriff: "Geschäftskritikalität" - definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement." - synonyme: ["Business Criticality", "Service-Kritikalität"] - - - begriff: "Governance" - definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden." - - - begriff: "Incident" - definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs." - synonyme: ["Vorfall", "Störung"] - - - begriff: "Interner Service" - definition: | - Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen - DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services - sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level - Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner, - eine eigene Service-Definition und nehmen am Service-Lifecycle teil. - Die Abgrenzung zu passiven Service-Komponenten erfolgt über den - Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005). - abgrenzung: - - "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA" - - "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet" - kategorie: "I" - governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005" - - - begriff: "Initiative" - definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht." - synonyme: ["Chance", "Möglichkeit", "Opportunity"] - - - begriff: "Key Performance Indicator (KPI)" - definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten." - - - begriff: "Kontinuierliche Verbesserung" - definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet." - - - begriff: "Kundenservice" - definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit." - - - begriff: "Kund*in" - definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor." - synonyme: ["Service-Konsument"] - - - begriff: "Major-Change" - definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess." - synonyme: ["Wesentliche Änderung"] - - - begriff: "Normal-Change" - definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung." - - - begriff: "Nutzen" - definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")." - synonyme: ["Utility"] - - - begriff: "Problem (engl.)" - definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen." - synonyme: ["Ursache"] - - - begriff: "Produkt" - definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar." - synonyme: ["Leistungsbaustein"] - - - begriff: "Recovery Time Objective (RTO)" - definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität." - synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"] - - - begriff: "Request-Katalog" - definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird." - - - begriff: "Request for Change (RFC)" - definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC." - synonyme: ["Change Request"] - - - begriff: "Ressource" - definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar." - - - begriff: "Service" - definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen." - synonyme: ["Dienstleistung"] - - - begriff: "Service Level" - definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung." - synonyme: ["Service-Qualitätsniveau"] - - - begriff: "Operational Level Agreement (OLA)" - definition: | - Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services - (Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne - Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter, - Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten. - abgrenzung: - - "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)" - - "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)" - governance_referenz: "GOV-SPM-I-002" - - - begriff: "Service-Sichtbarkeit" - definition: | - Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der - Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt. - Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar. - Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und - Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once"). - governance_referenz: "GOV-SPM-I-003" - - - begriff: "Service Level Agreement (SLA)" - definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt." - synonyme: ["Servicevereinbarung"] - - - begriff: "Service Request" - definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung." - synonyme: ["Serviceanfrage"] - - - begriff: "Service-Anbieter" - definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein." - synonyme: ["Dienstleister", "Service Provider"] - - - begriff: "Service-Angebot" - definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird." - synonyme: ["Leistungsangebot"] - - - begriff: "Service-Bereitstellung" - definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden." - synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"] - - - begriff: "Service-Beziehung" - definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management." - - - begriff: "Service-Katalog" - definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services." - - - begriff: "Service-Portfolio" - definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert." - synonyme: ["IT-Service-Portfolio"] - - - begriff: "Sponsor*in" - definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht." - - - begriff: "Stakeholder" - definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung." - synonyme: ["Anspruchsgruppen"] - - - begriff: "Standard Operating Procedures (SOPs)" - definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen." - synonyme: ["Standardvorgehensweise"] - - - begriff: "Standard-Change" - definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist." - - - begriff: "Vital Business Function (VBF)" - definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben." - synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"] - - - begriff: "Wert" - definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen." - - - begriff: "Wissensmanagement" - definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern." +metadata: + version: "3.7" + datum: "2026-03-09" + quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)" + basis: "ITIL4 / DIGITOM Begriffsüberleitung" + hinweis: > + Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf, + ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu + eins in das DIGIT Service-Management Framework passen (Übernehmen), + ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder + modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext + keinen erkennbaren Mehrwert bieten (Weglassen). + +glossar: + - begriff: "Anforderung" + definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen." + synonyme: ["Requirement", "Vorgabe"] + + - begriff: "Anwender*in" + definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)." + synonyme: ["Nutzer*in", "User"] + + - begriff: "Auftraggeber*in" + definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert." + + - begriff: "Bedarf" + definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient." + + - begriff: "Change" + definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change." + synonyme: ["Änderung"] + + - begriff: "Configuration Item (CI)" + definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt." + + - begriff: "Demand" + definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann." + + - begriff: "Demand-Steckbrief" + definition: | + Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert + den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der + Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben. + abgrenzung: + - "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe" + - "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen" + + - begriff: "Emergency-Change" + definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben." + + - begriff: "Ergebnis" + definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird." + synonyme: ["Outcome"] + + - begriff: "Gewährleistung" + definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")." + synonyme: ["Qualitätszusage", "Warranty"] + + - begriff: "Geschäftskritikalität" + definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement." + synonyme: ["Business Criticality", "Service-Kritikalität"] + + - begriff: "Governance" + definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden." + + - begriff: "Incident" + definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs." + synonyme: ["Vorfall", "Störung"] + + - begriff: "Interner Service" + definition: | + Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen + DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services + sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level + Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner, + eine eigene Service-Definition und nehmen am Service-Lifecycle teil. + Die Abgrenzung zu passiven Service-Komponenten erfolgt über den + Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005). + abgrenzung: + - "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA" + - "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet" + kategorie: "I" + governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005" + + - begriff: "Initiative" + definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht." + synonyme: ["Chance", "Möglichkeit", "Opportunity"] + + - begriff: "Key Performance Indicator (KPI)" + definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten." + + - begriff: "Kontinuierliche Verbesserung" + definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet." + + - begriff: "Kundenservice" + definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit." + + - begriff: "Kund*in" + definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor." + synonyme: ["Service-Konsument"] + + - begriff: "Major-Change" + definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess." + synonyme: ["Wesentliche Änderung"] + + - begriff: "Normal-Change" + definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung." + + - begriff: "Nutzen" + definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")." + synonyme: ["Utility"] + + - begriff: "Problem (engl.)" + definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen." + synonyme: ["Ursache"] + + - begriff: "Produkt" + definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar." + synonyme: ["Leistungsbaustein"] + + - begriff: "Recovery Time Objective (RTO)" + definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität." + synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"] + + - begriff: "Request-Katalog" + definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird." + + - begriff: "Request for Change (RFC)" + definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC." + synonyme: ["Change Request"] + + - begriff: "Ressource" + definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar." + + - begriff: "Service" + definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen." + synonyme: ["Dienstleistung"] + + - begriff: "Service Level" + definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung." + synonyme: ["Service-Qualitätsniveau"] + + - begriff: "Operational Level Agreement (OLA)" + definition: | + Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services + (Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne + Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter, + Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten. + abgrenzung: + - "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)" + - "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)" + governance_referenz: "GOV-SPM-I-002" + + - begriff: "Service-Sichtbarkeit" + definition: | + Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der + Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt. + Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar. + Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und + Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once"). + governance_referenz: "GOV-SPM-I-003" + + - begriff: "Service Level Agreement (SLA)" + definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt." + synonyme: ["Servicevereinbarung"] + + - begriff: "Service Request" + definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung." + synonyme: ["Serviceanfrage"] + + - begriff: "Service-Anbieter" + definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein." + synonyme: ["Dienstleister", "Service Provider"] + + - begriff: "Service-Angebot" + definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird." + synonyme: ["Leistungsangebot"] + + - begriff: "Service-Bereitstellung" + definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden." + synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"] + + - begriff: "Service-Beziehung" + definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management." + + - begriff: "Service-Katalog" + definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services." + + - begriff: "Service-Portfolio" + definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert." + synonyme: ["IT-Service-Portfolio"] + + - begriff: "Sponsor*in" + definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht." + + - begriff: "Stakeholder" + definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung." + synonyme: ["Anspruchsgruppen"] + + - begriff: "Standard Operating Procedures (SOPs)" + definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen." + synonyme: ["Standardvorgehensweise"] + + - begriff: "Standard-Change" + definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist." + + - begriff: "Vital Business Function (VBF)" + definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben." + synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"] + + - begriff: "Wert" + definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen." + + - begriff: "Wissensmanagement" + definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern." diff --git a/#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml b/#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml index ccf0526..d5652c3 100644 --- a/#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml +++ b/#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml @@ -1,20 +1,20 @@ -# ======================================== -# Funktionsbeschreibung Stakeholder-Management (SHM) -# ======================================== -# Version: 0.1 (Platzhalter) -# Datum: 2024-12-03 -# Status: Ausstehend -# Entwicklungsphase: 0, 10 -# ======================================== - -# ITIL4-Referenz (falls zutreffend): -# itil4_referenz: -# practice: "" -# relevante_elemente: [] -# adaption_fuer_digitom: "" - -# ======================================== -# INHALT -# ======================================== - -# [Inhalt folgt in Phase 0 und 10] +# ======================================== +# Funktionsbeschreibung Stakeholder-Management (SHM) +# ======================================== +# Version: 0.1 (Platzhalter) +# Datum: 2024-12-03 +# Status: Ausstehend +# Entwicklungsphase: 0, 10 +# ======================================== + +# ITIL4-Referenz (falls zutreffend): +# itil4_referenz: +# practice: "" +# relevante_elemente: [] +# adaption_fuer_digitom: "" + +# ======================================== +# INHALT +# ======================================== + +# [Inhalt folgt in Phase 0 und 10] diff --git a/#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml b/#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml index 34dc77d..7b86725 100644 --- a/#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml +++ b/#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml @@ -1,817 +1,817 @@ -# ============================================================================= -# SHM ROLLENBESCHREIBUNGEN -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Funktion: Rollen -# Version: 1.0 -# Datum: 2025-12-10 -# Status: Entwurf -# Entwicklungsphase: 6 -# ============================================================================= - -meta: - dokument_id: "SHM-R-01" - name: "SHM Rollenbeschreibungen" - - enthaltene_rollen: - - rolle_id: "shm-m" - rolle_name: "Stakeholder-Manager:in" - - rolle_id: "shm-l" - rolle_name: "Leitung Stakeholder Management" - - beziehung_rollen: | - Die Leitung Stakeholder Management ist disziplinarische Führungskraft - der Stakeholder-Manager:innen und gleichzeitig Abteilungsleitung. - - Operative Kundenbetreuung liegt bei den Stakeholder-Manager:innen. - Strategische Steuerung, Reporting und Gremienvertretung auf - Leitungsebene (MB) liegt bei der Leitung. - -# ============================================================================= -# ROLLE 1: STAKEHOLDER-MANAGER:IN -# ============================================================================= - -stakeholder_manager: - - # --------------------------------------------------------------------------- - # META - # --------------------------------------------------------------------------- - - meta: - typ: "rollenbeschreibung" - rolle_id: "shm-m" - rolle_name: "Stakeholder-Manager:in" - aliases: ["SHM-Manager", "Kundenbetreuer:in"] - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Stakeholder-Management" - - status: - inhaltlich_abgenommen_durch: "[SHM-Leitung]" - status: "entwurf" - - kontext_tags: - - "stakeholder-management" - - "kundenbetreuung" - - "bedarfserhebung" - - "relationship-management" - - # --------------------------------------------------------------------------- - # ROLLENZWECK - # --------------------------------------------------------------------------- - - rollenzweck: - - kurz: | - Zentrale Ansprechperson für zugewiesene Stakeholder (Ämter/Einheiten) - und verantwortlich für Beziehungspflege, Bedarfserhebung und - Interessenvertretung gegenüber DIGIT. - - ausfuehrlich: | - Der/die Stakeholder-Manager:in betreut einen definierten Kreis von - Organisationseinheiten (Ämter, Eigenbetriebe, Referate etc.) und ist - deren primäre Schnittstelle zu DIGIT. Die Rolle umfasst proaktive - Beziehungspflege, systematische Bedarfserhebung, qualifiziertes - Routing von Anforderungen sowie die Vertretung der Stakeholder- - Perspektive in internen Gremien. - - Der/die Stakeholder-Manager:in agiert als "Kundenanwalt" – nicht als - neutraler Vermittler, sondern als aktiver Vertreter der - Kundenperspektive innerhalb von DIGIT. - - verantwortung: - ab_wann: "Für alle Interaktionen mit zugewiesenen Stakeholdern" - fuer: "Beziehungsqualität, Bedarfserfassung, Routing-Entscheidung" - bis: "Übergabe qualifizierter Demands an DPM, Changes an SPM bzw. Abschluss Service-Request" - - # --------------------------------------------------------------------------- - # ORGANISATORISCHE EINORDNUNG - # --------------------------------------------------------------------------- - - organisatorische_einordnung: - - zuordnung: - abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance" - abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen - funktion: "Stakeholder-Management (SHM)" - - berichtslinie: - berichtet_an: "Leitung Stakeholder Management" - berichtet_an_rolle_id: "shm-l" - - arbeitsmodell: - typ: "Vollzeitfunktion oder Teilfunktion" - anmerkung: | - Je nach Portfolio-Größe kann die Rolle auf mehrere Personen - verteilt sein. Jede:r Stakeholder-Manager:in betreut einen - definierten Kreis von Ämtern/Einheiten. - vertretung: "Gegenseitige Vertretungsregelung zwischen Stakeholder-Manager:innen" - - # --------------------------------------------------------------------------- - # KERNAUFGABEN - # --------------------------------------------------------------------------- - - kernaufgaben: - - # ------------------------------------------------------------------------- - beziehungspflege: - - name: "Proaktive Beziehungspflege" - - beschreibung: | - Aufbau und Pflege stabiler, vertrauensvoller Beziehungen zu den - zugewiesenen Stakeholdern. Der/die Stakeholder-Manager:in ist - das "Gesicht von DIGIT" für diese Organisationseinheiten. - - aktivitaeten: - - aufgabe: "Turnus-Gespräche durchführen" - frequenz: "Gemäß Betreuungsmodus (monatlich bis jährlich)" - referenz: "shm_engagement-framework.yaml" - - - aufgabe: "Stakeholder-Steckbriefe pflegen" - frequenz: "Laufend, mindestens jährliche Validierung" - referenz: "shm_schema_amtssteckbrief.yaml" - - - aufgabe: "Beziehungsqualität einschätzen und dokumentieren" - frequenz: "Nach jedem Kontakt" - referenz: "shm_stakeholder-portfolio.yaml" - - - aufgabe: "Proaktive Kontaktaufnahme bei Veränderungen" - trigger: "Neue Amtsleitung, Reorganisation, Projektstart" - - ergebnis: | - Stakeholder fühlen sich von DIGIT verstanden und gut betreut. - Beziehungsqualität ist dokumentiert und steuerbar. - - # ------------------------------------------------------------------------- - bedarfserhebung: - - name: "Bedarfserhebung und -qualifizierung" - - beschreibung: | - Systematische Erfassung, Klärung und Dokumentation von - Stakeholder-Bedarfen. Der/die Stakeholder-Manager:in trennt - den eigentlichen Bedarf von vorgeschlagenen Lösungen. - - aktivitaeten: - - aufgabe: "Bedarfe in Turnus-Gesprächen erheben" - methode: "Aktives Zuhören, gezielte Fragen" - - - aufgabe: "Bedarfssteckbrief erstellen" - referenz: "shm_schema_bedarfssteckbrief.yaml" - - - aufgabe: "User Stories erheben (bei komplexeren Bedarfen)" - referenz: "leitfaden_user-stories.yaml" - - - aufgabe: "Rückfragen klären, Nachforderungen einholen" - bei: "Unvollständige oder unklare Bedarfsbeschreibung" - - ergebnis: | - Bedarfe sind verstanden, dokumentiert und für Routing vorbereitet. - - # ------------------------------------------------------------------------- - routing: - - name: "Bedarfs-Routing" - - beschreibung: | - Kernentscheidung E2: Wohin gehört dieser Bedarf? Der/die - Stakeholder-Manager:in ordnet Bedarfe dem richtigen Pfad zu. - - aktivitaeten: - - aufgabe: "Routing-Entscheidung treffen" - pfade: - - "Service-Katalog → Request an Service Desk" - - "Change an bestehendem Service → Service Owner" - - "Neuer Demand → DPM/DSR" - - "Unklare Zuordnung → SOR" - referenz: "shm_bedarfsbewertung.yaml" - - - aufgabe: "Bedarfssteckbrief an Zielfunktion übergeben" - validierung: "Gemäß Validierungsprofil des Routing-Pfads" - - - aufgabe: "Stakeholder über Routing informieren" - inhalt: "Wohin geht der Bedarf, was sind nächste Schritte" - - ergebnis: | - Bedarfe landen an der richtigen Stelle. Stakeholder wissen, - was mit ihrem Anliegen passiert. - - # ------------------------------------------------------------------------- - eskalationsbehandlung: - - name: "Reaktive Bedarfsbehandlung und Eskalation" - - beschreibung: | - Behandlung von Beschwerden, Problemen und eskalierenden - Situationen. Der/die Stakeholder-Manager:in ist Erstanlaufstelle - für Unzufriedenheit. - - aktivitaeten: - - aufgabe: "Beschwerden entgegennehmen und dokumentieren" - haltung: "Sachlich, lösungsorientiert, Kundenperspektive ernst nehmen" - - - aufgabe: "Eskalation an zuständige Funktion weiterleiten" - pfade: - - "Service-Qualität → Service Owner / SPM" - - "Demand-Status → DPM" - - "Projekt-Verzug → PPM" - - - aufgabe: "Nachverfolgung und Statusupdate an Stakeholder" - differenziert_nach: "Stakeholder-Priorität (Key/Aktiv vs. Standard/Basis)" - - ergebnis: | - Stakeholder-Anliegen werden ernst genommen und gelöst. - Muster werden erkannt und aggregiert. - - referenz: "shm_engagement-framework.yaml (Abschnitt Eskalation)" - - # ------------------------------------------------------------------------- - voc_dokumentation: - - name: "Voice of Customer Dokumentation" - - beschreibung: | - Systematische Erfassung von Stakeholder-Feedback als Grundlage - für die VoC-Aggregation durch die Leitung. - - aktivitaeten: - - aufgabe: "Feedback in Turnus-Gesprächen dokumentieren" - dimensionen: - - "Zufriedenheit mit Services" - - "Qualität der Zusammenarbeit" - - "Bedarfserfüllung" - - "Kommunikation" - - - aufgabe: "Highlights identifizieren" - typen: ["Lob", "Kritik", "Risiko", "Chance"] - - - aufgabe: "Signale an Leitung SHM melden" - bei: "Kritische Entwicklungen, eskalierende Unzufriedenheit" - - ergebnis: | - VoC-Datenbasis für Aggregation und Review ist gepflegt. - - referenz: "shm_voice-of-customer.yaml" - - # ------------------------------------------------------------------------- - gremienarbeit: - - name: "Gremienarbeit (DSR)" - - beschreibung: | - Vertretung der Stakeholder-Perspektive in der Demand & - Stakeholder-Runde (DSR). - - aktivitaeten: - - aufgabe: "An DSR-Sitzungen teilnehmen" - rolle: "Kundenanwalt" - - - aufgabe: "Stakeholder-Kontext zu Demands einbringen" - inhalt: "Priorität, Historie, Beziehungsstatus, fachliche Perspektive" - - - aufgabe: "Einwand-Recht ausüben" - bei: "Demands, die gegen fundamentale Stakeholder-Interessen verstoßen" - referenz: "GOV-SHM-021" - - - aufgabe: "Kommunikationsstrategie bei Ablehnung abstimmen" - mit: "DSR-Mitgliedern" - - ergebnis: | - Stakeholder-Perspektive fließt in Demand-Entscheidungen ein. - - referenz: "shm_d2p-integration.yaml" - - # --------------------------------------------------------------------------- - # ENTSCHEIDUNGSBEFUGNISSE - # --------------------------------------------------------------------------- - - entscheidungsbefugnisse: - - eigenstaendig: - - befugnis: "Routing-Entscheidung (E2)" - beschreibung: "Zuordnung Bedarf → Pfad (Katalog/Change/Demand/SOR)" - einschraenkung: "Bei Unklarheit Abstimmung mit Leitung oder SOR" - - - befugnis: "Betreuungsintensität operativ anpassen" - beschreibung: "Zusätzliche Kontakte bei Bedarf, Gesprächsfrequenz erhöhen" - einschraenkung: "Strukturelle Änderung der Priorisierung über Leitung" - - - befugnis: "Eskalationspfad wählen" - beschreibung: "Entscheidung, an welche Funktion eskaliert wird" - - - befugnis: "Einwand in DSR erheben" - beschreibung: "Volles Einwand-Recht als stimmberechtigtes Mitglied" - - in_abstimmung: - - befugnis: "Stakeholder-Priorisierung ändern" - abstimmung_mit: "Leitung SHM" - kontext: "Änderung des Betreuungsmodus (z.B. Standard → Aktiv)" - - - befugnis: "Neue Stakeholder ins Portfolio aufnehmen" - abstimmung_mit: "Leitung SHM" - - - befugnis: "Eskalation an Vision Board" - abstimmung_mit: "Leitung SHM" - kontext: "Nur Leitung eskaliert an VB" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - schnittstellen: - - intern: - - partner: "Leitung SHM" - interaktion: "Berichtslinie, E3-Team-Sync, Eskalation, Abstimmung" - frequenz: "Wöchentlich (E3) + laufend" - - - partner: "DPM (Demand-Portfolio-Manager:in)" - interaktion: "Demand-Übergabe, Klärungsschleifen, DSR-Zusammenarbeit" - frequenz: "Laufend" - referenz: "shm_d2p-integration.yaml" - - - partner: "Service Owner / SPM" - interaktion: "Change-Routing, Service-bezogene Rückfragen" - frequenz: "Bei Bedarf" - - - partner: "Service Desk" - interaktion: "Request-Weiterleitung, Eskalationsempfang" - frequenz: "Laufend" - - extern: - - partner: "Stakeholder (Ämter, Einheiten)" - interaktion: "Turnus-Gespräche, Bedarfserhebung, Statusupdates" - frequenz: "Gemäß Betreuungsmodus" - - - partner: "Amtsleitungen / SLA-Partner" - interaktion: "Strategische Abstimmung, SLA-bezogene Themen" - frequenz: "Bei Bedarf, meist über Turnus-Gespräch" - - # --------------------------------------------------------------------------- - # GREMIENROLLEN - # --------------------------------------------------------------------------- - - gremienrollen: - - - gremium: "DSR (Demand & Stakeholder-Runde)" - rolle: "Stimmberechtigtes Mitglied" - funktion: "Kundenanwalt – Vertretung der Stakeholder-Perspektive" - befugnisse: ["Einwand-Recht", "Kontextinformation einbringen"] - referenz: "DSR-Geschäftsordnung, GOV-SHM-021" - - - gremium: "SOR (Service Operations Review)" - rolle: "Teilnehmer bei Bedarf" - funktion: "Klärung von Routing-Grenzfällen" - referenz: "shm_sor-integration.yaml (Phase 9)" - - - gremium: "Kundenforum (KF-01/02/03)" - rolle: "Teilnehmer / Moderationsunterstützung" - funktion: "Stakeholder-Interaktion in kollektiven Formaten" - referenz: "shm_engagement-framework.yaml" - - # --------------------------------------------------------------------------- - # ANFORDERUNGSPROFIL - # --------------------------------------------------------------------------- - - anforderungsprofil: - - fachlich: - - "Kenntnisse der Verwaltungsstruktur der Stadt Freiburg" - - "Grundverständnis der DIGIT-Services und des Service-Katalogs" - - "Verständnis des DIGITOM (DPM, SPM, SHM-Zusammenspiel)" - - "ITIL4-Grundlagen (wünschenswert)" - - methodisch: - - "Gesprächsführung und aktives Zuhören" - - "Bedarfsanalyse und Anforderungserhebung" - - "Dokumentation und strukturierte Erfassung" - - "Konfliktmanagement und Deeskalation" - - persoenlich: - - "Kundenorientierung und Empathie" - - "Kommunikationsstärke (mündlich und schriftlich)" - - "Verbindlichkeit und Zuverlässigkeit" - - "Fähigkeit, auch unangenehme Botschaften zu vermitteln" - - "Netzwerk-Kompetenz (internes Beziehungsmanagement)" - - # --------------------------------------------------------------------------- - # ABGRENZUNG - # --------------------------------------------------------------------------- - - abgrenzung: - - nicht_aufgabe: - - was: "Operative Problemlösung bei Incidents" - zustaendig: "Service Desk / Service Owner" - klarstellung: "SHM sorgt dafür, dass Probleme an der richtigen Stelle bearbeitet werden, löst sie aber nicht selbst." - - - was: "Demand-Klassifizierung und -Priorisierung" - zustaendig: "DPM" - klarstellung: "SHM entscheidet OB etwas ein Demand ist, DPM WIE er priorisiert wird." - - - was: "SLA-Verhandlung und -Abschluss" - zustaendig: "SPM / Service Owner" - klarstellung: "SHM kann Stakeholder-Perspektive einbringen, aber nicht verhandeln." - - - was: "Strategische Portfolio-Steuerung" - zustaendig: "Leitung SHM" - klarstellung: "Operative Betreuung ja, strategische Weiterentwicklung liegt bei Leitung." - - - was: "Vision Board / MB-Entscheidungen" - zustaendig: "Leitung SHM (MB), Geschäftsführung (VB)" - klarstellung: "Stakeholder-Manager:in bringt sich über DSR ein, nicht direkt in MB/VB." - -# ============================================================================= -# ROLLE 2: LEITUNG STAKEHOLDER MANAGEMENT -# ============================================================================= - -leitung_shm: - - # --------------------------------------------------------------------------- - # META - # --------------------------------------------------------------------------- - - meta: - typ: "rollenbeschreibung" - rolle_id: "shm-l" - rolle_name: "Leitung Stakeholder Management" - aliases: ["SHM-Leitung", "Abteilungsleitung SHM"] - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Stakeholder-Management" - - status: - inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" - status: "entwurf" - - kontext_tags: - - "stakeholder-management" - - "fuehrung" - - "abteilungsleitung" - - "strategie" - - # --------------------------------------------------------------------------- - # ROLLENZWECK - # --------------------------------------------------------------------------- - - rollenzweck: - - kurz: | - Abteilungsleitung und disziplinarische Führungskraft der SHM-Funktion. - Verantwortlich für strategische Steuerung, Qualitätssicherung und - Vertretung der Stakeholder-Perspektive auf Leitungsebene. - - ausfuehrlich: | - Die Leitung Stakeholder Management führt die Abteilung - "Digitale Schulen / QM, Service- und Prozessgovernance" und ist - verantwortlich für die Gesamtperformance der SHM-Funktion. - - Die Rolle umfasst: - - Disziplinarische Führung der Stakeholder-Manager:innen - - Strategische Steuerung des Stakeholder-Portfolios - - Qualitätssicherung der Stakeholder-Beziehungen (VoC-Aggregation) - - Vertretung der Stakeholder-Perspektive im Mission Board - - Reporting an das Vision Board - - Die Leitung agiert als Brücke zwischen operativer Kundenbetreuung - und strategischer DIGIT-Steuerung. - - verantwortung: - fuer: "Gesamtperformance SHM, Stakeholder-Beziehungsqualität, Abteilungsführung" - gegenueber: "DIGIT-Leitung / Vision Board" - - # --------------------------------------------------------------------------- - # ORGANISATORISCHE EINORDNUNG - # --------------------------------------------------------------------------- - - organisatorische_einordnung: - - zuordnung: - abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance" - abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen - position: "Abteilungsleitung" - - berichtslinie: - berichtet_an: "DIGIT-Leitung / Vision Board" - - fuehrt: - - rolle_id: "shm-m" - rolle_name: "Stakeholder-Manager:in" - fuehrungsart: "Disziplinarisch und fachlich" - - # --------------------------------------------------------------------------- - # KERNAUFGABEN - # --------------------------------------------------------------------------- - - kernaufgaben: - - # ------------------------------------------------------------------------- - fuehrung: - - name: "Führung und Teamentwicklung" - - aktivitaeten: - - "Disziplinarische Führung der Stakeholder-Manager:innen" - - "Ressourcenplanung und -allokation" - - "Kompetenzentwicklung im Team" - - "E3-Team-Sync leiten (zweiwöchentlich)" - - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - - # ------------------------------------------------------------------------- - portfolio_steuerung: - - name: "Strategische Portfolio-Steuerung" - - aktivitaeten: - - aufgabe: "Portfolio-Gesamtverantwortung" - beschreibung: "Sicherstellen, dass alle Stakeholder angemessen betreut werden" - - - aufgabe: "Priorisierung validieren und anpassen" - frequenz: "Im Rahmen E2-Review" - - - aufgabe: "Segmentierungslogik weiterentwickeln" - bei: "Strukturelle Änderungen, neue Stakeholder-Typen" - - - aufgabe: "Betreuungszuordnung steuern" - beschreibung: "Welche:r Stakeholder-Manager:in betreut welche Ämter" - - referenz: "shm_stakeholder-portfolio.yaml" - - # ------------------------------------------------------------------------- - voc_aggregation: - - name: "Voice of Customer Aggregation" - - beschreibung: | - Aggregation der VoC-Daten aus dem Team zu einem Gesamtbild. - Identifikation von Mustern, Trends und Handlungsbedarf. - - aktivitaeten: - - aufgabe: "VoC-Cluster-Status bewerten" - frequenz: "Quartalsweise (E2-Review)" - output: "Ampel-Matrix pro Cluster" - - - aufgabe: "Highlights konsolidieren" - frequenz: "Quartalsweise" - output: "Top-Highlights für Quartalsbericht" - - - aufgabe: "Maßnahmen bei Cluster-Rot initiieren" - mit: "Betroffene:r Stakeholder-Manager:in" - - - aufgabe: "Strategische Erkenntnisse ableiten" - frequenz: "Jährlich (E1-Review)" - output: "Input für DIGIT-Strategie" - - referenz: "shm_voice-of-customer.yaml" - - # ------------------------------------------------------------------------- - review_reporting: - - name: "Review und Reporting" - - aktivitaeten: - - aufgabe: "E1-Jahresbericht erstellen" - empfaenger: "Vision Board" - inhalt: "SHM-Jahresbilanz, VoC-Gesamtbild, strategische Empfehlungen" - referenz: "TPL-KSS-01" - - - aufgabe: "E2-Quartals-Reviews leiten" - frequenz: "Quartalsweise" - varianten: ["Standard (Q1/Q3)", "Erweitert mit Retrospektive (Q2/Q4)"] - referenz: "TPL-KSS-02" - - - aufgabe: "E3-Team-Sync leiten" - frequenz: "Zweiwöchentlich" - referenz: "TPL-KSS-03" - - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - - # ------------------------------------------------------------------------- - gremienarbeit: - - name: "Gremienarbeit (MB, DSR, Kundenforum)" - - aktivitaeten: - - aufgabe: "Mission Board Teilnahme" - rolle: "Vollwertiges Mitglied" - funktion: "Stakeholder-Perspektive auf strategisch-taktischer Ebene" - - - aufgabe: "DSR-Teilnahme (optional)" - rolle: "Bei Bedarf, Eskalation, strategische Themen" - anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen" - - - aufgabe: "Kundenforum verantworten" - formate: ["KF-01 Basisservices", "KF-02 Fachverfahren", "KF-03 Basis-Puls-Check"] - rolle: "Gesamtverantwortung, ggf. Moderation" - - referenz: "shm_d2p-integration.yaml, shm_engagement-framework.yaml" - - # ------------------------------------------------------------------------- - qualitaetssicherung: - - name: "Qualitätssicherung SHM" - - aktivitaeten: - - aufgabe: "Beziehungsqualität im Portfolio überwachen" - indikator: "Aggregierte Beziehungsqualitäts-Verteilung" - - - aufgabe: "Methodische Standards sichern" - was: "Turnus-Gespräche, Bedarfssteckbriefe, VoC-Dokumentation" - - - aufgabe: "Eskalationen nachverfolgen" - was: "Kritische Fälle, Muster erkennen" - - - aufgabe: "Verbesserungsmaßnahmen steuern" - quelle: "E2-Erweitert Review (Q2/Q4)" - - # --------------------------------------------------------------------------- - # ENTSCHEIDUNGSBEFUGNISSE - # --------------------------------------------------------------------------- - - entscheidungsbefugnisse: - - eigenstaendig: - - befugnis: "Stakeholder-Priorisierung anpassen" - beschreibung: "Änderung des Betreuungsmodus für einzelne Stakeholder" - - - befugnis: "Betreuungszuordnung ändern" - beschreibung: "Zuweisung Stakeholder → Stakeholder-Manager:in" - - - befugnis: "Ressourcenallokation innerhalb SHM" - beschreibung: "Verteilung der verfügbaren Kapazität" - - - befugnis: "Maßnahmen bei VoC-Cluster-Rot" - beschreibung: "Initiierung von Interventionen" - - - befugnis: "E2-Review-Entscheidungen" - beschreibung: "Anpassungen an SHM-Arbeitsweise, Priorisierung" - - in_abstimmung: - - befugnis: "Strukturelle SHM-Weiterentwicklung" - abstimmung_mit: "Vision Board / DIGIT-Leitung" - - - befugnis: "Ressourcenaufstockung" - abstimmung_mit: "DIGIT-Leitung" - - - befugnis: "Änderung der Segmentierungslogik" - abstimmung_mit: "Vision Board (bei strategischer Relevanz)" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLEN - # --------------------------------------------------------------------------- - - schnittstellen: - - intern: - - partner: "Stakeholder-Manager:innen" - interaktion: "Führung, E3-Sync, Eskalationsempfang, Qualitätssicherung" - frequenz: "Wöchentlich + laufend" - - - partner: "Abteilungsleitung Planung (DPM)" - interaktion: "Abstimmung SHM-DPM-Schnittstelle, DSR-Koordination" - frequenz: "Bei Bedarf" - - - partner: "SPM-Leitung" - interaktion: "Kundenforum-Koordination, SLA-bezogene Themen" - frequenz: "Bei Bedarf" - - - partner: "DIGIT-Leitung" - interaktion: "Berichtslinie, strategische Abstimmung" - frequenz: "Regelmäßig" - - extern: - - partner: "Vision Board" - interaktion: "E1-Jahresbericht, strategische Eskalation" - frequenz: "Jährlich (E1) + bei Bedarf" - - - partner: "Amtsleitungen (bei Eskalation)" - interaktion: "Direkte Klärung kritischer Stakeholder-Situationen" - frequenz: "Bei Bedarf" - - # --------------------------------------------------------------------------- - # GREMIENROLLEN - # --------------------------------------------------------------------------- - - gremienrollen: - - - gremium: "Mission Board" - rolle: "Vollwertiges Mitglied" - funktion: "Vertretung der Stakeholder-Perspektive auf strategisch-taktischer Ebene" - befugnisse: ["Stimmrecht", "Einbringung strategischer Stakeholder-Themen"] - governance_referenz: "GOV-SHM-025" - - - gremium: "DSR (Demand & Stakeholder-Runde)" - rolle: "Optionale Teilnahme" - funktion: "Bei Eskalation, strategischen Themen, Unterstützung" - anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen" - - - gremium: "Kundenforum (KF-01/02/03)" - rolle: "Gesamtverantwortung" - funktion: "Sicherstellung der Durchführung, ggf. Moderation" - - - gremium: "Vision Board" - rolle: "Berichterstatter (kein Mitglied)" - funktion: "E1-Jahresbericht, strategische Eskalation" - - # --------------------------------------------------------------------------- - # ANFORDERUNGSPROFIL - # --------------------------------------------------------------------------- - - anforderungsprofil: - - fachlich: - - "Tiefes Verständnis der Verwaltungsstruktur und -kultur" - - "Umfassendes Verständnis des DIGITOM" - - "Kenntnisse in Service Management / ITIL4" - - "Erfahrung mit Stakeholder-/Kundenmanagement" - - methodisch: - - "Führungskompetenz" - - "Strategisches Denken und Handeln" - - "Reporting und Management-Kommunikation" - - "Qualitätsmanagement" - - "Moderation von Gremien und Workshops" - - persoenlich: - - "Souveränität auf Leitungsebene" - - "Diplomatisches Geschick" - - "Durchsetzungsfähigkeit bei Wahrung der Kundenorientierung" - - "Analytische Stärke (Mustererkennung, Aggregation)" - - # --------------------------------------------------------------------------- - # ABGRENZUNG - # --------------------------------------------------------------------------- - - abgrenzung: - - nicht_aufgabe: - - was: "Operative Stakeholder-Betreuung" - zustaendig: "Stakeholder-Manager:in" - klarstellung: "Leitung steuert, operative Betreuung liegt im Team." - - - was: "DSR-Tagesgeschäft" - zustaendig: "Stakeholder-Manager:in, DPM" - klarstellung: "Leitung nimmt nur bei Bedarf teil." - - - was: "Demand-Entscheidungen" - zustaendig: "DSR, Mission Board" - klarstellung: "Leitung bringt Stakeholder-Perspektive ein, entscheidet nicht über einzelne Demands." - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN (NEU) -# ============================================================================= - -governance_entscheidungen: - - - id: "GOV-SHM-025" - datum: "2025-12-10" - quelle_modul: "Rollenbeschreibungen (Phase 6)" - - frage: | - Ist die Leitung SHM Mitglied im Mission Board? - - entscheidung: | - Ja. Die Leitung Stakeholder Management ist vollwertiges Mitglied - im Mission Board. - - begruendung: | - Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene - vertreten sein. Während die operative DSR-Arbeit bei den - Stakeholder-Manager:innen liegt, braucht das MB eine Person, die: - - den Gesamt-Überblick über das Stakeholder-Portfolio hat - - strategische Stakeholder-Themen einbringen kann - - Entscheidungsauswirkungen auf Stakeholder bewerten kann - - Dies präzisiert GOV-SHM-022: "SHM ist kein ständiges MB-Mitglied" - bezieht sich auf die operative Rolle (Stakeholder-Manager:in), - nicht auf die Leitungsrolle. - - auswirkung_auf: - - dokument: "shm_rollen.yaml" - abschnitt: "leitung_shm.gremienrollen" - - dokument: "shm_d2p-integration.yaml" - abschnitt: "shm_rolle_mission_board" - aenderung: "Präzisierung erforderlich" - - status: "final" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2024-12-03" - autor: "DIGITOM-Projekt" - aenderung: "Platzhalter erstellt" - - - version: "1.0" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: | - Phase 6 abgeschlossen: - - Rollenbeschreibung Stakeholder-Manager:in vollständig - - Rollenbeschreibung Leitung SHM vollständig +# ============================================================================= +# SHM ROLLENBESCHREIBUNGEN +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Funktion: Rollen +# Version: 1.0 +# Datum: 2025-12-10 +# Status: Entwurf +# Entwicklungsphase: 6 +# ============================================================================= + +meta: + dokument_id: "SHM-R-01" + name: "SHM Rollenbeschreibungen" + + enthaltene_rollen: + - rolle_id: "shm-m" + rolle_name: "Stakeholder-Manager:in" + - rolle_id: "shm-l" + rolle_name: "Leitung Stakeholder Management" + + beziehung_rollen: | + Die Leitung Stakeholder Management ist disziplinarische Führungskraft + der Stakeholder-Manager:innen und gleichzeitig Abteilungsleitung. + + Operative Kundenbetreuung liegt bei den Stakeholder-Manager:innen. + Strategische Steuerung, Reporting und Gremienvertretung auf + Leitungsebene (MB) liegt bei der Leitung. + +# ============================================================================= +# ROLLE 1: STAKEHOLDER-MANAGER:IN +# ============================================================================= + +stakeholder_manager: + + # --------------------------------------------------------------------------- + # META + # --------------------------------------------------------------------------- + + meta: + typ: "rollenbeschreibung" + rolle_id: "shm-m" + rolle_name: "Stakeholder-Manager:in" + aliases: ["SHM-Manager", "Kundenbetreuer:in"] + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Stakeholder-Management" + + status: + inhaltlich_abgenommen_durch: "[SHM-Leitung]" + status: "entwurf" + + kontext_tags: + - "stakeholder-management" + - "kundenbetreuung" + - "bedarfserhebung" + - "relationship-management" + + # --------------------------------------------------------------------------- + # ROLLENZWECK + # --------------------------------------------------------------------------- + + rollenzweck: + + kurz: | + Zentrale Ansprechperson für zugewiesene Stakeholder (Ämter/Einheiten) + und verantwortlich für Beziehungspflege, Bedarfserhebung und + Interessenvertretung gegenüber DIGIT. + + ausfuehrlich: | + Der/die Stakeholder-Manager:in betreut einen definierten Kreis von + Organisationseinheiten (Ämter, Eigenbetriebe, Referate etc.) und ist + deren primäre Schnittstelle zu DIGIT. Die Rolle umfasst proaktive + Beziehungspflege, systematische Bedarfserhebung, qualifiziertes + Routing von Anforderungen sowie die Vertretung der Stakeholder- + Perspektive in internen Gremien. + + Der/die Stakeholder-Manager:in agiert als "Kundenanwalt" – nicht als + neutraler Vermittler, sondern als aktiver Vertreter der + Kundenperspektive innerhalb von DIGIT. + + verantwortung: + ab_wann: "Für alle Interaktionen mit zugewiesenen Stakeholdern" + fuer: "Beziehungsqualität, Bedarfserfassung, Routing-Entscheidung" + bis: "Übergabe qualifizierter Demands an DPM, Changes an SPM bzw. Abschluss Service-Request" + + # --------------------------------------------------------------------------- + # ORGANISATORISCHE EINORDNUNG + # --------------------------------------------------------------------------- + + organisatorische_einordnung: + + zuordnung: + abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance" + abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen + funktion: "Stakeholder-Management (SHM)" + + berichtslinie: + berichtet_an: "Leitung Stakeholder Management" + berichtet_an_rolle_id: "shm-l" + + arbeitsmodell: + typ: "Vollzeitfunktion oder Teilfunktion" + anmerkung: | + Je nach Portfolio-Größe kann die Rolle auf mehrere Personen + verteilt sein. Jede:r Stakeholder-Manager:in betreut einen + definierten Kreis von Ämtern/Einheiten. + vertretung: "Gegenseitige Vertretungsregelung zwischen Stakeholder-Manager:innen" + + # --------------------------------------------------------------------------- + # KERNAUFGABEN + # --------------------------------------------------------------------------- + + kernaufgaben: + + # ------------------------------------------------------------------------- + beziehungspflege: + + name: "Proaktive Beziehungspflege" + + beschreibung: | + Aufbau und Pflege stabiler, vertrauensvoller Beziehungen zu den + zugewiesenen Stakeholdern. Der/die Stakeholder-Manager:in ist + das "Gesicht von DIGIT" für diese Organisationseinheiten. + + aktivitaeten: + - aufgabe: "Turnus-Gespräche durchführen" + frequenz: "Gemäß Betreuungsmodus (monatlich bis jährlich)" + referenz: "shm_engagement-framework.yaml" + + - aufgabe: "Stakeholder-Steckbriefe pflegen" + frequenz: "Laufend, mindestens jährliche Validierung" + referenz: "shm_schema_amtssteckbrief.yaml" + + - aufgabe: "Beziehungsqualität einschätzen und dokumentieren" + frequenz: "Nach jedem Kontakt" + referenz: "shm_stakeholder-portfolio.yaml" + + - aufgabe: "Proaktive Kontaktaufnahme bei Veränderungen" + trigger: "Neue Amtsleitung, Reorganisation, Projektstart" + + ergebnis: | + Stakeholder fühlen sich von DIGIT verstanden und gut betreut. + Beziehungsqualität ist dokumentiert und steuerbar. + + # ------------------------------------------------------------------------- + bedarfserhebung: + + name: "Bedarfserhebung und -qualifizierung" + + beschreibung: | + Systematische Erfassung, Klärung und Dokumentation von + Stakeholder-Bedarfen. Der/die Stakeholder-Manager:in trennt + den eigentlichen Bedarf von vorgeschlagenen Lösungen. + + aktivitaeten: + - aufgabe: "Bedarfe in Turnus-Gesprächen erheben" + methode: "Aktives Zuhören, gezielte Fragen" + + - aufgabe: "Bedarfssteckbrief erstellen" + referenz: "shm_schema_bedarfssteckbrief.yaml" + + - aufgabe: "User Stories erheben (bei komplexeren Bedarfen)" + referenz: "leitfaden_user-stories.yaml" + + - aufgabe: "Rückfragen klären, Nachforderungen einholen" + bei: "Unvollständige oder unklare Bedarfsbeschreibung" + + ergebnis: | + Bedarfe sind verstanden, dokumentiert und für Routing vorbereitet. + + # ------------------------------------------------------------------------- + routing: + + name: "Bedarfs-Routing" + + beschreibung: | + Kernentscheidung E2: Wohin gehört dieser Bedarf? Der/die + Stakeholder-Manager:in ordnet Bedarfe dem richtigen Pfad zu. + + aktivitaeten: + - aufgabe: "Routing-Entscheidung treffen" + pfade: + - "Service-Katalog → Request an Service Desk" + - "Change an bestehendem Service → Service Owner" + - "Neuer Demand → DPM/DSR" + - "Unklare Zuordnung → SOR" + referenz: "shm_bedarfsbewertung.yaml" + + - aufgabe: "Bedarfssteckbrief an Zielfunktion übergeben" + validierung: "Gemäß Validierungsprofil des Routing-Pfads" + + - aufgabe: "Stakeholder über Routing informieren" + inhalt: "Wohin geht der Bedarf, was sind nächste Schritte" + + ergebnis: | + Bedarfe landen an der richtigen Stelle. Stakeholder wissen, + was mit ihrem Anliegen passiert. + + # ------------------------------------------------------------------------- + eskalationsbehandlung: + + name: "Reaktive Bedarfsbehandlung und Eskalation" + + beschreibung: | + Behandlung von Beschwerden, Problemen und eskalierenden + Situationen. Der/die Stakeholder-Manager:in ist Erstanlaufstelle + für Unzufriedenheit. + + aktivitaeten: + - aufgabe: "Beschwerden entgegennehmen und dokumentieren" + haltung: "Sachlich, lösungsorientiert, Kundenperspektive ernst nehmen" + + - aufgabe: "Eskalation an zuständige Funktion weiterleiten" + pfade: + - "Service-Qualität → Service Owner / SPM" + - "Demand-Status → DPM" + - "Projekt-Verzug → PPM" + + - aufgabe: "Nachverfolgung und Statusupdate an Stakeholder" + differenziert_nach: "Stakeholder-Priorität (Key/Aktiv vs. Standard/Basis)" + + ergebnis: | + Stakeholder-Anliegen werden ernst genommen und gelöst. + Muster werden erkannt und aggregiert. + + referenz: "shm_engagement-framework.yaml (Abschnitt Eskalation)" + + # ------------------------------------------------------------------------- + voc_dokumentation: + + name: "Voice of Customer Dokumentation" + + beschreibung: | + Systematische Erfassung von Stakeholder-Feedback als Grundlage + für die VoC-Aggregation durch die Leitung. + + aktivitaeten: + - aufgabe: "Feedback in Turnus-Gesprächen dokumentieren" + dimensionen: + - "Zufriedenheit mit Services" + - "Qualität der Zusammenarbeit" + - "Bedarfserfüllung" + - "Kommunikation" + + - aufgabe: "Highlights identifizieren" + typen: ["Lob", "Kritik", "Risiko", "Chance"] + + - aufgabe: "Signale an Leitung SHM melden" + bei: "Kritische Entwicklungen, eskalierende Unzufriedenheit" + + ergebnis: | + VoC-Datenbasis für Aggregation und Review ist gepflegt. + + referenz: "shm_voice-of-customer.yaml" + + # ------------------------------------------------------------------------- + gremienarbeit: + + name: "Gremienarbeit (DSR)" + + beschreibung: | + Vertretung der Stakeholder-Perspektive in der Demand & + Stakeholder-Runde (DSR). + + aktivitaeten: + - aufgabe: "An DSR-Sitzungen teilnehmen" + rolle: "Kundenanwalt" + + - aufgabe: "Stakeholder-Kontext zu Demands einbringen" + inhalt: "Priorität, Historie, Beziehungsstatus, fachliche Perspektive" + + - aufgabe: "Einwand-Recht ausüben" + bei: "Demands, die gegen fundamentale Stakeholder-Interessen verstoßen" + referenz: "GOV-SHM-021" + + - aufgabe: "Kommunikationsstrategie bei Ablehnung abstimmen" + mit: "DSR-Mitgliedern" + + ergebnis: | + Stakeholder-Perspektive fließt in Demand-Entscheidungen ein. + + referenz: "shm_d2p-integration.yaml" + + # --------------------------------------------------------------------------- + # ENTSCHEIDUNGSBEFUGNISSE + # --------------------------------------------------------------------------- + + entscheidungsbefugnisse: + + eigenstaendig: + - befugnis: "Routing-Entscheidung (E2)" + beschreibung: "Zuordnung Bedarf → Pfad (Katalog/Change/Demand/SOR)" + einschraenkung: "Bei Unklarheit Abstimmung mit Leitung oder SOR" + + - befugnis: "Betreuungsintensität operativ anpassen" + beschreibung: "Zusätzliche Kontakte bei Bedarf, Gesprächsfrequenz erhöhen" + einschraenkung: "Strukturelle Änderung der Priorisierung über Leitung" + + - befugnis: "Eskalationspfad wählen" + beschreibung: "Entscheidung, an welche Funktion eskaliert wird" + + - befugnis: "Einwand in DSR erheben" + beschreibung: "Volles Einwand-Recht als stimmberechtigtes Mitglied" + + in_abstimmung: + - befugnis: "Stakeholder-Priorisierung ändern" + abstimmung_mit: "Leitung SHM" + kontext: "Änderung des Betreuungsmodus (z.B. Standard → Aktiv)" + + - befugnis: "Neue Stakeholder ins Portfolio aufnehmen" + abstimmung_mit: "Leitung SHM" + + - befugnis: "Eskalation an Vision Board" + abstimmung_mit: "Leitung SHM" + kontext: "Nur Leitung eskaliert an VB" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + schnittstellen: + + intern: + - partner: "Leitung SHM" + interaktion: "Berichtslinie, E3-Team-Sync, Eskalation, Abstimmung" + frequenz: "Wöchentlich (E3) + laufend" + + - partner: "DPM (Demand-Portfolio-Manager:in)" + interaktion: "Demand-Übergabe, Klärungsschleifen, DSR-Zusammenarbeit" + frequenz: "Laufend" + referenz: "shm_d2p-integration.yaml" + + - partner: "Service Owner / SPM" + interaktion: "Change-Routing, Service-bezogene Rückfragen" + frequenz: "Bei Bedarf" + + - partner: "Service Desk" + interaktion: "Request-Weiterleitung, Eskalationsempfang" + frequenz: "Laufend" + + extern: + - partner: "Stakeholder (Ämter, Einheiten)" + interaktion: "Turnus-Gespräche, Bedarfserhebung, Statusupdates" + frequenz: "Gemäß Betreuungsmodus" + + - partner: "Amtsleitungen / SLA-Partner" + interaktion: "Strategische Abstimmung, SLA-bezogene Themen" + frequenz: "Bei Bedarf, meist über Turnus-Gespräch" + + # --------------------------------------------------------------------------- + # GREMIENROLLEN + # --------------------------------------------------------------------------- + + gremienrollen: + + - gremium: "DSR (Demand & Stakeholder-Runde)" + rolle: "Stimmberechtigtes Mitglied" + funktion: "Kundenanwalt – Vertretung der Stakeholder-Perspektive" + befugnisse: ["Einwand-Recht", "Kontextinformation einbringen"] + referenz: "DSR-Geschäftsordnung, GOV-SHM-021" + + - gremium: "SOR (Service Operations Review)" + rolle: "Teilnehmer bei Bedarf" + funktion: "Klärung von Routing-Grenzfällen" + referenz: "shm_sor-integration.yaml (Phase 9)" + + - gremium: "Kundenforum (KF-01/02/03)" + rolle: "Teilnehmer / Moderationsunterstützung" + funktion: "Stakeholder-Interaktion in kollektiven Formaten" + referenz: "shm_engagement-framework.yaml" + + # --------------------------------------------------------------------------- + # ANFORDERUNGSPROFIL + # --------------------------------------------------------------------------- + + anforderungsprofil: + + fachlich: + - "Kenntnisse der Verwaltungsstruktur der Stadt Freiburg" + - "Grundverständnis der DIGIT-Services und des Service-Katalogs" + - "Verständnis des DIGITOM (DPM, SPM, SHM-Zusammenspiel)" + - "ITIL4-Grundlagen (wünschenswert)" + + methodisch: + - "Gesprächsführung und aktives Zuhören" + - "Bedarfsanalyse und Anforderungserhebung" + - "Dokumentation und strukturierte Erfassung" + - "Konfliktmanagement und Deeskalation" + + persoenlich: + - "Kundenorientierung und Empathie" + - "Kommunikationsstärke (mündlich und schriftlich)" + - "Verbindlichkeit und Zuverlässigkeit" + - "Fähigkeit, auch unangenehme Botschaften zu vermitteln" + - "Netzwerk-Kompetenz (internes Beziehungsmanagement)" + + # --------------------------------------------------------------------------- + # ABGRENZUNG + # --------------------------------------------------------------------------- + + abgrenzung: + + nicht_aufgabe: + - was: "Operative Problemlösung bei Incidents" + zustaendig: "Service Desk / Service Owner" + klarstellung: "SHM sorgt dafür, dass Probleme an der richtigen Stelle bearbeitet werden, löst sie aber nicht selbst." + + - was: "Demand-Klassifizierung und -Priorisierung" + zustaendig: "DPM" + klarstellung: "SHM entscheidet OB etwas ein Demand ist, DPM WIE er priorisiert wird." + + - was: "SLA-Verhandlung und -Abschluss" + zustaendig: "SPM / Service Owner" + klarstellung: "SHM kann Stakeholder-Perspektive einbringen, aber nicht verhandeln." + + - was: "Strategische Portfolio-Steuerung" + zustaendig: "Leitung SHM" + klarstellung: "Operative Betreuung ja, strategische Weiterentwicklung liegt bei Leitung." + + - was: "Vision Board / MB-Entscheidungen" + zustaendig: "Leitung SHM (MB), Geschäftsführung (VB)" + klarstellung: "Stakeholder-Manager:in bringt sich über DSR ein, nicht direkt in MB/VB." + +# ============================================================================= +# ROLLE 2: LEITUNG STAKEHOLDER MANAGEMENT +# ============================================================================= + +leitung_shm: + + # --------------------------------------------------------------------------- + # META + # --------------------------------------------------------------------------- + + meta: + typ: "rollenbeschreibung" + rolle_id: "shm-l" + rolle_name: "Leitung Stakeholder Management" + aliases: ["SHM-Leitung", "Abteilungsleitung SHM"] + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Stakeholder-Management" + + status: + inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" + status: "entwurf" + + kontext_tags: + - "stakeholder-management" + - "fuehrung" + - "abteilungsleitung" + - "strategie" + + # --------------------------------------------------------------------------- + # ROLLENZWECK + # --------------------------------------------------------------------------- + + rollenzweck: + + kurz: | + Abteilungsleitung und disziplinarische Führungskraft der SHM-Funktion. + Verantwortlich für strategische Steuerung, Qualitätssicherung und + Vertretung der Stakeholder-Perspektive auf Leitungsebene. + + ausfuehrlich: | + Die Leitung Stakeholder Management führt die Abteilung + "Digitale Schulen / QM, Service- und Prozessgovernance" und ist + verantwortlich für die Gesamtperformance der SHM-Funktion. + + Die Rolle umfasst: + - Disziplinarische Führung der Stakeholder-Manager:innen + - Strategische Steuerung des Stakeholder-Portfolios + - Qualitätssicherung der Stakeholder-Beziehungen (VoC-Aggregation) + - Vertretung der Stakeholder-Perspektive im Mission Board + - Reporting an das Vision Board + + Die Leitung agiert als Brücke zwischen operativer Kundenbetreuung + und strategischer DIGIT-Steuerung. + + verantwortung: + fuer: "Gesamtperformance SHM, Stakeholder-Beziehungsqualität, Abteilungsführung" + gegenueber: "DIGIT-Leitung / Vision Board" + + # --------------------------------------------------------------------------- + # ORGANISATORISCHE EINORDNUNG + # --------------------------------------------------------------------------- + + organisatorische_einordnung: + + zuordnung: + abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance" + abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen + position: "Abteilungsleitung" + + berichtslinie: + berichtet_an: "DIGIT-Leitung / Vision Board" + + fuehrt: + - rolle_id: "shm-m" + rolle_name: "Stakeholder-Manager:in" + fuehrungsart: "Disziplinarisch und fachlich" + + # --------------------------------------------------------------------------- + # KERNAUFGABEN + # --------------------------------------------------------------------------- + + kernaufgaben: + + # ------------------------------------------------------------------------- + fuehrung: + + name: "Führung und Teamentwicklung" + + aktivitaeten: + - "Disziplinarische Führung der Stakeholder-Manager:innen" + - "Ressourcenplanung und -allokation" + - "Kompetenzentwicklung im Team" + - "E3-Team-Sync leiten (zweiwöchentlich)" + + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + + # ------------------------------------------------------------------------- + portfolio_steuerung: + + name: "Strategische Portfolio-Steuerung" + + aktivitaeten: + - aufgabe: "Portfolio-Gesamtverantwortung" + beschreibung: "Sicherstellen, dass alle Stakeholder angemessen betreut werden" + + - aufgabe: "Priorisierung validieren und anpassen" + frequenz: "Im Rahmen E2-Review" + + - aufgabe: "Segmentierungslogik weiterentwickeln" + bei: "Strukturelle Änderungen, neue Stakeholder-Typen" + + - aufgabe: "Betreuungszuordnung steuern" + beschreibung: "Welche:r Stakeholder-Manager:in betreut welche Ämter" + + referenz: "shm_stakeholder-portfolio.yaml" + + # ------------------------------------------------------------------------- + voc_aggregation: + + name: "Voice of Customer Aggregation" + + beschreibung: | + Aggregation der VoC-Daten aus dem Team zu einem Gesamtbild. + Identifikation von Mustern, Trends und Handlungsbedarf. + + aktivitaeten: + - aufgabe: "VoC-Cluster-Status bewerten" + frequenz: "Quartalsweise (E2-Review)" + output: "Ampel-Matrix pro Cluster" + + - aufgabe: "Highlights konsolidieren" + frequenz: "Quartalsweise" + output: "Top-Highlights für Quartalsbericht" + + - aufgabe: "Maßnahmen bei Cluster-Rot initiieren" + mit: "Betroffene:r Stakeholder-Manager:in" + + - aufgabe: "Strategische Erkenntnisse ableiten" + frequenz: "Jährlich (E1-Review)" + output: "Input für DIGIT-Strategie" + + referenz: "shm_voice-of-customer.yaml" + + # ------------------------------------------------------------------------- + review_reporting: + + name: "Review und Reporting" + + aktivitaeten: + - aufgabe: "E1-Jahresbericht erstellen" + empfaenger: "Vision Board" + inhalt: "SHM-Jahresbilanz, VoC-Gesamtbild, strategische Empfehlungen" + referenz: "TPL-KSS-01" + + - aufgabe: "E2-Quartals-Reviews leiten" + frequenz: "Quartalsweise" + varianten: ["Standard (Q1/Q3)", "Erweitert mit Retrospektive (Q2/Q4)"] + referenz: "TPL-KSS-02" + + - aufgabe: "E3-Team-Sync leiten" + frequenz: "Zweiwöchentlich" + referenz: "TPL-KSS-03" + + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + + # ------------------------------------------------------------------------- + gremienarbeit: + + name: "Gremienarbeit (MB, DSR, Kundenforum)" + + aktivitaeten: + - aufgabe: "Mission Board Teilnahme" + rolle: "Vollwertiges Mitglied" + funktion: "Stakeholder-Perspektive auf strategisch-taktischer Ebene" + + - aufgabe: "DSR-Teilnahme (optional)" + rolle: "Bei Bedarf, Eskalation, strategische Themen" + anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen" + + - aufgabe: "Kundenforum verantworten" + formate: ["KF-01 Basisservices", "KF-02 Fachverfahren", "KF-03 Basis-Puls-Check"] + rolle: "Gesamtverantwortung, ggf. Moderation" + + referenz: "shm_d2p-integration.yaml, shm_engagement-framework.yaml" + + # ------------------------------------------------------------------------- + qualitaetssicherung: + + name: "Qualitätssicherung SHM" + + aktivitaeten: + - aufgabe: "Beziehungsqualität im Portfolio überwachen" + indikator: "Aggregierte Beziehungsqualitäts-Verteilung" + + - aufgabe: "Methodische Standards sichern" + was: "Turnus-Gespräche, Bedarfssteckbriefe, VoC-Dokumentation" + + - aufgabe: "Eskalationen nachverfolgen" + was: "Kritische Fälle, Muster erkennen" + + - aufgabe: "Verbesserungsmaßnahmen steuern" + quelle: "E2-Erweitert Review (Q2/Q4)" + + # --------------------------------------------------------------------------- + # ENTSCHEIDUNGSBEFUGNISSE + # --------------------------------------------------------------------------- + + entscheidungsbefugnisse: + + eigenstaendig: + - befugnis: "Stakeholder-Priorisierung anpassen" + beschreibung: "Änderung des Betreuungsmodus für einzelne Stakeholder" + + - befugnis: "Betreuungszuordnung ändern" + beschreibung: "Zuweisung Stakeholder → Stakeholder-Manager:in" + + - befugnis: "Ressourcenallokation innerhalb SHM" + beschreibung: "Verteilung der verfügbaren Kapazität" + + - befugnis: "Maßnahmen bei VoC-Cluster-Rot" + beschreibung: "Initiierung von Interventionen" + + - befugnis: "E2-Review-Entscheidungen" + beschreibung: "Anpassungen an SHM-Arbeitsweise, Priorisierung" + + in_abstimmung: + - befugnis: "Strukturelle SHM-Weiterentwicklung" + abstimmung_mit: "Vision Board / DIGIT-Leitung" + + - befugnis: "Ressourcenaufstockung" + abstimmung_mit: "DIGIT-Leitung" + + - befugnis: "Änderung der Segmentierungslogik" + abstimmung_mit: "Vision Board (bei strategischer Relevanz)" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLEN + # --------------------------------------------------------------------------- + + schnittstellen: + + intern: + - partner: "Stakeholder-Manager:innen" + interaktion: "Führung, E3-Sync, Eskalationsempfang, Qualitätssicherung" + frequenz: "Wöchentlich + laufend" + + - partner: "Abteilungsleitung Planung (DPM)" + interaktion: "Abstimmung SHM-DPM-Schnittstelle, DSR-Koordination" + frequenz: "Bei Bedarf" + + - partner: "SPM-Leitung" + interaktion: "Kundenforum-Koordination, SLA-bezogene Themen" + frequenz: "Bei Bedarf" + + - partner: "DIGIT-Leitung" + interaktion: "Berichtslinie, strategische Abstimmung" + frequenz: "Regelmäßig" + + extern: + - partner: "Vision Board" + interaktion: "E1-Jahresbericht, strategische Eskalation" + frequenz: "Jährlich (E1) + bei Bedarf" + + - partner: "Amtsleitungen (bei Eskalation)" + interaktion: "Direkte Klärung kritischer Stakeholder-Situationen" + frequenz: "Bei Bedarf" + + # --------------------------------------------------------------------------- + # GREMIENROLLEN + # --------------------------------------------------------------------------- + + gremienrollen: + + - gremium: "Mission Board" + rolle: "Vollwertiges Mitglied" + funktion: "Vertretung der Stakeholder-Perspektive auf strategisch-taktischer Ebene" + befugnisse: ["Stimmrecht", "Einbringung strategischer Stakeholder-Themen"] + governance_referenz: "GOV-SHM-025" + + - gremium: "DSR (Demand & Stakeholder-Runde)" + rolle: "Optionale Teilnahme" + funktion: "Bei Eskalation, strategischen Themen, Unterstützung" + anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen" + + - gremium: "Kundenforum (KF-01/02/03)" + rolle: "Gesamtverantwortung" + funktion: "Sicherstellung der Durchführung, ggf. Moderation" + + - gremium: "Vision Board" + rolle: "Berichterstatter (kein Mitglied)" + funktion: "E1-Jahresbericht, strategische Eskalation" + + # --------------------------------------------------------------------------- + # ANFORDERUNGSPROFIL + # --------------------------------------------------------------------------- + + anforderungsprofil: + + fachlich: + - "Tiefes Verständnis der Verwaltungsstruktur und -kultur" + - "Umfassendes Verständnis des DIGITOM" + - "Kenntnisse in Service Management / ITIL4" + - "Erfahrung mit Stakeholder-/Kundenmanagement" + + methodisch: + - "Führungskompetenz" + - "Strategisches Denken und Handeln" + - "Reporting und Management-Kommunikation" + - "Qualitätsmanagement" + - "Moderation von Gremien und Workshops" + + persoenlich: + - "Souveränität auf Leitungsebene" + - "Diplomatisches Geschick" + - "Durchsetzungsfähigkeit bei Wahrung der Kundenorientierung" + - "Analytische Stärke (Mustererkennung, Aggregation)" + + # --------------------------------------------------------------------------- + # ABGRENZUNG + # --------------------------------------------------------------------------- + + abgrenzung: + + nicht_aufgabe: + - was: "Operative Stakeholder-Betreuung" + zustaendig: "Stakeholder-Manager:in" + klarstellung: "Leitung steuert, operative Betreuung liegt im Team." + + - was: "DSR-Tagesgeschäft" + zustaendig: "Stakeholder-Manager:in, DPM" + klarstellung: "Leitung nimmt nur bei Bedarf teil." + + - was: "Demand-Entscheidungen" + zustaendig: "DSR, Mission Board" + klarstellung: "Leitung bringt Stakeholder-Perspektive ein, entscheidet nicht über einzelne Demands." + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN (NEU) +# ============================================================================= + +governance_entscheidungen: + + - id: "GOV-SHM-025" + datum: "2025-12-10" + quelle_modul: "Rollenbeschreibungen (Phase 6)" + + frage: | + Ist die Leitung SHM Mitglied im Mission Board? + + entscheidung: | + Ja. Die Leitung Stakeholder Management ist vollwertiges Mitglied + im Mission Board. + + begruendung: | + Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene + vertreten sein. Während die operative DSR-Arbeit bei den + Stakeholder-Manager:innen liegt, braucht das MB eine Person, die: + - den Gesamt-Überblick über das Stakeholder-Portfolio hat + - strategische Stakeholder-Themen einbringen kann + - Entscheidungsauswirkungen auf Stakeholder bewerten kann + + Dies präzisiert GOV-SHM-022: "SHM ist kein ständiges MB-Mitglied" + bezieht sich auf die operative Rolle (Stakeholder-Manager:in), + nicht auf die Leitungsrolle. + + auswirkung_auf: + - dokument: "shm_rollen.yaml" + abschnitt: "leitung_shm.gremienrollen" + - dokument: "shm_d2p-integration.yaml" + abschnitt: "shm_rolle_mission_board" + aenderung: "Präzisierung erforderlich" + + status: "final" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2024-12-03" + autor: "DIGITOM-Projekt" + aenderung: "Platzhalter erstellt" + + - version: "1.0" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: | + Phase 6 abgeschlossen: + - Rollenbeschreibung Stakeholder-Manager:in vollständig + - Rollenbeschreibung Leitung SHM vollständig - Governance-Entscheidung GOV-SHM-025 (MB-Mitgliedschaft Leitung) \ No newline at end of file diff --git a/#03_stakeholder-management/#03.2_governance/shm_governance-framework.yaml b/#03_stakeholder-management/#03.2_governance/shm_governance-framework.yaml index e40294b..b549c3b 100644 --- a/#03_stakeholder-management/#03.2_governance/shm_governance-framework.yaml +++ b/#03_stakeholder-management/#03.2_governance/shm_governance-framework.yaml @@ -1,1169 +1,1169 @@ -# ============================================================================= -# SHM GOVERNANCE-FRAMEWORK -# ============================================================================= -# Version: 1.0 -# Datum: 2025-12-10 -# Status: Entwurf -# Quelle: Konsolidierung aus GOV-SHM-001 bis GOV-SHM-025 -# ============================================================================= - -meta: - typ: "governance_framework" - funktion: "Stakeholder Management" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Stakeholder-Management" - - status: - inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" - status: "entwurf" - - kontext_tags: - - "governance" - - "stakeholder-management" - - "entscheidungslogik" - - "eskalation" - - zweck: | - Dieses Dokument konsolidiert die Governance-Entscheidungen, die während - der SHM-Konzeptentwicklung (Phase 1-6) getroffen wurden, zu einem - kohärenten Regelwerk. - - Es definiert: - - Governance-Prinzipien für SHM-Entscheidungen - - Entscheidungsdomänen und deren Regeln - - Eskalationslogik und -pfade - - Entscheidungsmatrix (wer entscheidet was) - - abgrenzung: | - Dieses Framework regelt die SHM-interne Governance und die - Schnittstellen-Governance zu anderen Funktionen. Es ersetzt nicht: - - Die RACI-Matrix (shm_raci.yaml) für operative Verantwortlichkeiten - - Die Koordinations- und Steuerungsstruktur für Review-Prozesse - - Die Rollenbeschreibungen für Aufgabenprofile - - quellen: - - dokument: "readme_shm_governance-entscheidungs-log.yaml" - beschreibung: "Vollständige Dokumentation aller 25 Governance-Entscheidungen" - - dokument: "shm_rollen.yaml" - beschreibung: "Entscheidungsbefugnisse der Rollen" - - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" - beschreibung: "E1/E2/E3 Entscheidungstypen" - -# ============================================================================= -# GOVERNANCE-PRINZIPIEN -# ============================================================================= - -governance_prinzipien: - - beschreibung: | - Die folgenden Prinzipien leiten alle Governance-Entscheidungen im - SHM-Kontext. Sie wurden aus den konkreten Entscheidungen (GOV-SHM-001 - bis GOV-SHM-025) abstrahiert und bilden das normative Fundament. - - prinzipien: - - - id: "GP-SHM-01" - name: "Substanz vor Herkunft" - - beschreibung: | - Die Routing-Entscheidung für einen Bedarf basiert ausschließlich - auf der Natur des Bedarfs ("Was ist es?"), nicht auf Eigenschaften - des einreichenden Stakeholders. - - konsequenzen: - - "Stakeholder-Priorität beeinflusst nicht das Routing" - - "Service-Kategorie (A/B/C) ist informativ, nicht entscheidungsrelevant" - - "Aufwandsschätzung ist informativ, nicht routing-relevant" - - "Ein Demand bleibt ein Demand, unabhängig von wer ihn einreicht" - - governance_referenz: - - "GOV-SHM-016" - - "GOV-SHM-018" - - "GOV-SHM-019" - - - id: "GP-SHM-02" - name: "Unsicherheit legitimiert Eskalation" - - beschreibung: | - Es gibt keine objektiven Schwellenwerte für Eskalationen. Die - qualifizierte Unsicherheit des Stakeholder-Managers ist ein - legitimes und ausreichendes Kriterium für eine SOR-Eskalation. - - begruendung: | - Objektivierte Kriterien würden zu Schein-Objektivität führen. - Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu erkennen - und angemessen zu eskalieren. Das System vertraut auf professionelles - Urteilsvermögen statt auf mechanische Regeln. - - governance_referenz: - - "GOV-SHM-017" - - - id: "GP-SHM-03" - name: "Ergebnis vor Aktivität" - - beschreibung: | - Die SHM-Steuerung fokussiert auf Ergebnis-Indikatoren - (Beziehungsqualität, VoC-Cluster-Status), nicht auf - Prozess-Indikatoren (Anzahl Gespräche, Durchlaufzeiten). - - konsequenzen: - - "Primäre Indikatoren: Beziehungsqualität, VoC-Ampeln, Highlights" - - "Sekundäre Indikatoren (intern): Gesprächsquoten, Routing-Statistik" - - "Review-Templates enthalten narrative Einschätzungen" - - "Keine Prozess-Metriken-Tabellen in formalen Berichten" - - governance_referenz: - - "GOV-SHM-023" - - - id: "GP-SHM-04" - name: "Subsidiarität in der Entscheidung" - - beschreibung: | - Entscheidungen werden auf der niedrigsten Ebene getroffen, die - dafür kompetent ist. Eskalation erfolgt nur, wenn die Ebene - die Entscheidung nicht treffen kann oder darf. - - ebenen: - - ebene: "Operativ" - entscheider: "Stakeholder-Manager:in" - beispiele: - - "Routing-Entscheidung im Regelfall" - - "Bedarfssteckbrief-Erstellung" - - "Turnus-Gespräch durchführen" - - - ebene: "Taktisch" - entscheider: "Leitung SHM" - beispiele: - - "Betreuungsmodus anpassen" - - "Ressourcenallokation innerhalb SHM" - - "E2-Review-Entscheidungen" - - - ebene: "Strategisch" - entscheider: "Mission Board / Vision Board" - beispiele: - - "Strukturelle SHM-Weiterentwicklung" - - "Ressourcenaufstockung" - - "Änderung der Segmentierungslogik" - - governance_referenz: - - "shm_rollen.yaml → entscheidungsbefugnisse" - - - id: "GP-SHM-05" - name: "Klare Verantwortungstrennung" - - beschreibung: | - SHM und SPM haben klar getrennte Verantwortungsbereiche. - Es gibt keine Doppel-Zuständigkeiten, aber definierte - Schnittstellen für den Informationsaustausch. - - verantwortungstrennung: - shm_verantwortet: - - "Beziehungsqualität (VoC-Dimension D1)" - - "Bedarfserfüllung (VoC-Dimension D3)" - - "Strategische Passung (VoC-Dimension D4)" - - "Aggregierte Stakeholder-Sicht (Portfolio-Perspektive)" - - spm_verantwortet: - - "Service-Qualität (VoC-Dimension D2)" - - "SLA-Erfüllung" - - "Einzelne Service-Performance (Service-Perspektive)" - - gemeinsam: - - "Auftraggeber-Forum (integriertes Format)" - - "Eskalationen, die beide Bereiche betreffen" - - governance_referenz: - - "GOV-SHM-024" - -# ============================================================================= -# ENTSCHEIDUNGSDOMÄNEN -# ============================================================================= - -entscheidungsdomaenen: - - beschreibung: | - Die Governance-Entscheidungen sind in vier Domänen gruppiert. - Jede Domäne hat spezifische Regeln und Entscheidungslogiken. - - # --------------------------------------------------------------------------- - # DOMÄNE A: PORTFOLIO-GOVERNANCE - # --------------------------------------------------------------------------- - - portfolio_governance: - - name: "Portfolio-Governance" - beschreibung: | - Regeln für die Struktur, Pflege und Steuerung des - Stakeholder-Portfolios. - - governance_referenzen: - - "GOV-SHM-001 bis GOV-SHM-014" - - teilbereiche: - - # ----------------------------------------------------------------------- - portfolio_struktur: - - name: "Portfolio-Grundstruktur" - - regel: | - Das Stakeholder-Portfolio folgt einem Drei-Ebenen-Modell: - 1. Amts-Steckbrief (Datengrundlage pro Organisationseinheit) - 2. Segmentierung (Clustering nach zwei Dimensionen) - 3. Priorisierung (Bewertung zur Betreuungsallokation) - - scope: | - Alle Einheiten im Dezernatsverteilungsplan: - Ämter, Eigenbetriebe, Referate, Stabsstellen, Projektgruppen - - referenz: "GOV-SHM-001, GOV-SHM-014" - - # ----------------------------------------------------------------------- - segmentierung: - - name: "Segmentierungslogik" - - dimensionen: - - dimension: "Funktion" - beschreibung: "Organisatorische Rolle im Verwaltungsgefüge" - auspraegungen: - - "Kernverwaltung" - - "Bürgerdienste" - - "Fachbehoerde" - - "Eigenbetrieb" - - "Sondereinheit" - - - dimension: "IT-Anforderungsprofil" - beschreibung: "Typische Bedarfskomplexität" - auspraegungen: - - id: "Basis" - beschreibung: "Standardisierte IT-Nutzung" - spm_mapping: "Kategorie A – Basis-Services" - - id: "Erweitert" - beschreibung: "Über Standard hinausgehende Anforderungen" - spm_mapping: "Kategorie B – Erweiterte Services" - - id: "Spezial" - beschreibung: "Hochspezialisierte Anforderungen" - spm_mapping: "Kategorie C – Spezial-Services" - - regel: | - Jedes Amt erhält genau eine Ausprägung pro Dimension - (keine Mehrfachzuordnung, keine Tags). - - referenz: "GOV-SHM-002 bis GOV-SHM-005" - - # ----------------------------------------------------------------------- - priorisierung: - - name: "Priorisierungslogik" - - dimensionen: - - dimension: "Einfluss" - beschreibung: "Politisches Gewicht, Entscheidungsmacht" - skala: "1-3 (niedrig bis hoch)" - stabilitaet: "Hoch (ändert sich selten)" - - - dimension: "Abhängigkeit" - beschreibung: "Grad der IT-Abhängigkeit für Kernaufgaben" - skala: "1-3 (niedrig bis hoch)" - stabilitaet: "Hoch (ändert sich selten)" - - - dimension: "Relevanz" - beschreibung: "Aktuelle strategische Bedeutung" - skala: "1-3 (niedrig bis hoch)" - stabilitaet: "Dynamisch (politische Themen kommen und gehen)" - - aggregation: - methode: "Summe der drei Dimensionen" - skala: "3-9 Punkte" - mapping: - - punktzahl: "7-9" - modus: "Key-Stakeholder" - - punktzahl: "5-6" - modus: "Aktiv" - - punktzahl: "3-4" - modus: "Standard" - - punktzahl: "< 3" - modus: "Basis" - hinweis: "Theoretisch möglich, praktisch unwahrscheinlich" - - review_zyklus: | - Überprüfung im Rahmen der E2-Reviews (quartalsweise). - Insbesondere die Dimension "Relevanz" erfordert regelmäßige - Aktualisierung. - - referenz: "GOV-SHM-006 bis GOV-SHM-012" - - # ----------------------------------------------------------------------- - sla_befugnis: - - name: "SLA-Partner-Befugnis" - - regel: | - Analog zur SPM-Logik (P-02 SLM): - - Primär: Amtsleitung - - Alternativ: Delegierte Person mit dokumentierter - Entscheidungsbefugnis - - Die Delegation muss dokumentiert sein (Amts-Steckbrief). - - begruendung: | - SLA-Partner müssen Entscheidungsbefugnis haben, nicht nur - operative Ansprechpartner sein. Konsistenz mit SPM-Governance. - - referenz: "GOV-SHM-013, SPM GOV-005" - - # --------------------------------------------------------------------------- - # DOMÄNE B: ROUTING-GOVERNANCE - # --------------------------------------------------------------------------- - - routing_governance: - - name: "Routing-Governance" - beschreibung: | - Regeln für die Bedarfsbewertung und das Routing von - Stakeholder-Bedarfen zu den richtigen Empfängern. - - governance_referenzen: - - "GOV-SHM-016 bis GOV-SHM-020" - - teilbereiche: - - # ----------------------------------------------------------------------- - routing_entscheidung: - - name: "Routing-Entscheidungslogik" - - grundprinzip: | - Die Routing-Entscheidung beantwortet: "Was ist dieser Bedarf?" - Sie basiert auf der Natur des Bedarfs, nicht auf: - - Stakeholder-Priorität - - Service-Kategorie (A/B/C) - - Aufwandsschätzung - - routing_pfade: - - id: "ROUTE-REQ" - name: "Service Request" - ziel: "Service Desk / Service Operations" - kriterium: "Bedarf ist im Katalog abbildbar als Request" - steckbrief: "Nicht erforderlich" - - - id: "ROUTE-SPM" - name: "Change an bestehendem Service" - ziel: "SPM / Service Owner" - kriterium: "Bedarf betrifft bestehenden Service, kein neuer Service" - steckbrief: "Reduziert (keine Stakeholder-Freigabe)" - - - id: "ROUTE-SO" - name: "Service-Owner-Klärung" - ziel: "Service Owner (über Service-Portfolio / SPM)" - kriterium: "SM ist unsicher über korrektes Routing; SO entscheidet bilateral" - steckbrief: "Reduziert + SHM-Einschätzung mit konkreter Frage" - hinweis: "Service Owner entscheidet bilateral mit SHM. RUN/Change → SOR; Demand → DPM/DSR" - - - id: "ROUTE-DPM" - name: "Demand" - ziel: "Demand Portfolio Management" - kriterium: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" - steckbrief: "Vollständig (mit Stakeholder-Freigabe)" - - referenz: "GOV-SHM-016, GOV-SHM-018, GOV-SHM-019, GOV-SHM-020" - - # ----------------------------------------------------------------------- - so_routing_klaerung: - - name: "Service-Owner-Routing-Klärungslogik" - - trigger: | - Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. - Es gibt keine quantitativen Schwellenwerte. - - voraussetzung: | - Der Stakeholder-Manager muss die Unsicherheit konkret benennen - können ("Ich bin unsicher, ob X oder Y zutrifft, weil..."). - - begruendung: | - Objektivierte Kriterien würden zu Schein-Objektivität führen. - Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu - erkennen und angemessen zu eskalieren. - - Die bilaterale Klärung mit dem Service Owner ist das geeignete - Verfahren. Der SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. - - referenz: "GOV-SHM-017, GOV-SHM-029" - - # ----------------------------------------------------------------------- - validierungsprofile: - - name: "Bedarfssteckbrief-Validierung" - - regel: | - Die Validierungsanforderungen im Bedarfssteckbrief variieren - je nach Routing-Ziel. - - profile: - - routing: "ROUTE-REQ" - pflichtfelder: "Keine (kein Steckbrief)" - stakeholder_freigabe: "Nein" - - - routing: "ROUTE-SPM" - pflichtfelder: "Basisdaten, Bedarfsbeschreibung, Service-Katalog-Prüfung" - stakeholder_freigabe: "Nein" - - - routing: "ROUTE-SO" - pflichtfelder: "Wie ROUTE-SPM + SHM-Einschätzung mit Frage" - stakeholder_freigabe: "Nein" - hinweis: "Routing-Klärung erfolgt bilateral mit Service Owner" - - - routing: "ROUTE-DPM" - pflichtfelder: "Vollständiger Steckbrief inkl. User Stories" - stakeholder_freigabe: "Ja" - - referenz: "GOV-SHM-020" - - # --------------------------------------------------------------------------- - # DOMÄNE C: GREMIEN-GOVERNANCE - # --------------------------------------------------------------------------- - - gremien_governance: - - name: "Gremien-Governance" - beschreibung: | - Regeln für die Mitwirkung von SHM in den DIGIT-Gremien - und die Koordination mit anderen Funktionen. - - governance_referenzen: - - "GOV-SHM-015, GOV-SHM-021, GOV-SHM-022, GOV-SHM-025" - - teilbereiche: - - # ----------------------------------------------------------------------- - dsr_rolle: - - name: "Rolle in der Demand & Stakeholder-Runde (DSR)" - - teilnehmer: "Stakeholder-Manager:in (für zugeordnete Stakeholder)" - - rolle: "Auftraggeber-Anwalt" - - funktion: | - Vertretung der Stakeholder-Perspektive bei Demand-Entscheidungen. - Sicherstellen, dass Auftraggeber-Interessen angemessen berücksichtigt werden. - - befugnisse: - - "Stimmberechtigtes Mitglied" - - "Einwand-Recht bei Demand-Entscheidungen" - - "Kontextinformation zu Stakeholder-Situation einbringen" - - grenzen: - - "Vertritt Kundenperspektive, aber akzeptiert Gremienentscheidungen" - - "Entscheidet nicht über Demands, sondern bringt Perspektive ein" - - referenz: "GOV-SHM-021" - - # ----------------------------------------------------------------------- - mb_rolle: - - name: "Rolle im Mission Board (MB)" - - teilnehmer: "Leitung SHM" - status: "Vollwertiges Mitglied" - - funktion: | - Vertretung der Stakeholder-Perspektive auf strategisch-taktischer - Ebene. Bewertung von Entscheidungsauswirkungen auf Stakeholder. - - differenzierung: | - Die Aussage "SHM ist kein ständiges MB-Mitglied" (GOV-SHM-022) - bezog sich auf die operative Rolle (Stakeholder-Manager:in). - Die Leitung SHM ist als Abteilungsleitung vollwertiges MB-Mitglied. - - referenz: "GOV-SHM-022, GOV-SHM-025" - - # ----------------------------------------------------------------------- - kundenforum: - - name: "Auftraggeber-Forum-Konzept" - - regel: | - Die SHM-Advisory-Boards und die SLM-Kundenvertretungen werden - zu einem integrierten "Auftraggeber-Forum"-Konzept konsolidiert. - - formate: - - id: "KF-01" - name: "Auftraggeber-Forum Basisservices" - zielgruppe: "Nutzer von Kategorie-A-Services" - verantwortung: "Gemeinsam SHM + SPM" - - - id: "KF-02" - name: "Auftraggeber-Forum Fachverfahren" - zielgruppe: "Nutzer von Kategorie-B/C-Services" - verantwortung: "Gemeinsam SHM + SPM" - - - id: "KF-03" - name: "Basis-Puls-Check" - zielgruppe: "Basis-Stakeholder" - verantwortung: "SHM" - - begruendung: | - Ein Gremium statt paralleler Formate mit denselben Teilnehmern. - Reduziert Aufwand für Ämter und DIGIT, stärkt gemeinsame - Außenwirkung. - - referenz: "GOV-SHM-015, SPM GOV-012" - - # --------------------------------------------------------------------------- - # DOMÄNE D: STEUERUNGS-GOVERNANCE - # --------------------------------------------------------------------------- - - steuerungs_governance: - - name: "Steuerungs-Governance" - beschreibung: | - Regeln für die interne SHM-Steuerung, das Reporting und die - Abgrenzung zu anderen Funktionen. - - governance_referenzen: - - "GOV-SHM-023, GOV-SHM-024" - - teilbereiche: - - # ----------------------------------------------------------------------- - steuerungsfokus: - - name: "Steuerungsfokus" - - regel: | - SHM-Steuerung fokussiert auf Ergebnis-Indikatoren, nicht auf - Prozess-Indikatoren. - - primaere_indikatoren: - - "Beziehungsqualität im Portfolio" - - "VoC-Cluster-Ampeln" - - "Qualitative Highlights" - - sekundaere_indikatoren: - beschreibung: "Für operative Selbstvergewisserung, nicht formal berichtet" - beispiele: - - "Gesprächsquoten" - - "Routing-Statistik" - - "Durchlaufzeiten Bedarfssteckbrief" - - referenz: "GOV-SHM-023" - - # ----------------------------------------------------------------------- - reporting_abgrenzung: - - name: "Reporting-Abgrenzung zu SPM" - - regel: | - SHM und SPM haben getrennte Reporting-Verantwortungen. - Kein Doppel-Reporting, keine widersprüchlichen Bewertungen. - - shm_berichtet: - - "Beziehungsqualität (VoC-D1)" - - "Bedarfserfüllung (VoC-D3)" - - "Strategische Passung (VoC-D4)" - - "Portfolio-Gesamtbild" - - spm_berichtet: - - "Service-Qualität (VoC-D2)" - - "SLA-Erfüllung" - - "Service-Performance" - - schnittstellen: - - schnittstelle: "VoC-Feedback zu D2" - von: "SHM" - an: "SPM / Service Owner" - beschreibung: "SHM erfasst, leitet weiter, berichtet nicht selbst" - - - schnittstelle: "Service-Performance-Daten" - von: "SPM" - an: "SHM (Leserecht)" - beschreibung: "SHM nutzt als Kontext, berichtet nicht selbst" - - referenz: "GOV-SHM-024" - -# ============================================================================= -# ESKALATIONSLOGIK -# ============================================================================= - -eskalationslogik: - - beschreibung: | - Definition der Eskalationspfade für verschiedene Situationen. - Eskalation bedeutet die Weiterleitung einer Entscheidung oder eines - Themas an eine höhere Instanz. - - grundprinzip: | - Eskalation ist kein Zeichen von Versagen, sondern ein legitimes - Instrument zur Sicherstellung angemessener Entscheidungsqualität. - Das System vertraut auf das professionelle Urteil der Beteiligten. - - pfade: - - # ------------------------------------------------------------------------- - - id: "ESK-01" - name: "Routing-Unsicherheit" - - situation: | - Stakeholder-Manager ist unsicher, welcher Routing-Pfad - der richtige ist. - - stufen: - - stufe: 1 - von: "Stakeholder-Manager:in" - an: "Leitung SHM" - modus: "Beratung (informell)" - - - stufe: 2 - von: "Stakeholder-Manager:in" - an: "Service Owner" - modus: "Bilaterale Klärung (ROUTE-SO)" - voraussetzung: "Unsicherheit konkret benannt" - - referenz: "GOV-SHM-017, GOV-SHM-029" - - begruendung_aenderung: | - Routing-Klärungen werden bilateral mit dem Service Owner behandelt. - Der SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. - Siehe GOV-SHM-029. - - # ------------------------------------------------------------------------- - - id: "ESK-02" - name: "Stakeholder-Konflikt" - - situation: | - Konflikt mit Stakeholder, der auf operativer Ebene nicht - lösbar ist. - - stufen: - - stufe: 1 - von: "Stakeholder-Manager:in" - an: "Leitung SHM" - modus: "Eskalation zur Übernahme/Moderation" - - - stufe: 2 - von: "Leitung SHM" - an: "Mission Board" - modus: "Strategische Eskalation" - voraussetzung: "Politische Dimension oder übergreifende Auswirkung" - - - stufe: 3 - von: "Mission Board" - an: "Vision Board" - modus: "Eskalation bei strategischer Relevanz" - - # ------------------------------------------------------------------------- - - id: "ESK-03" - name: "Demand-Ablehnung" - - situation: | - Demand wird abgelehnt und Stakeholder ist unzufrieden. - - stufen: - - stufe: 1 - von: "Stakeholder-Manager:in" - an: "Stakeholder" - modus: "Vermittlung und Erklärung" - differenzierung: - key_aktiv: "Aktive Begleitung bis zur Akzeptanz" - standard_basis: "Sachliche Kommunikation" - - - stufe: 2 - von: "Stakeholder-Manager:in" - an: "Leitung SHM" - modus: "Eskalation bei Nicht-Akzeptanz" - - - stufe: 3 - von: "Leitung SHM" - an: "Mission Board" - modus: "Strategische Eskalation" - voraussetzung: "Beziehungsschaden droht" - - referenz: "GOV-SHM-022" - - # ------------------------------------------------------------------------- - - id: "ESK-04" - name: "VoC-Cluster-Rot" - - situation: | - Ein VoC-Cluster zeigt kritischen Status (Rot). - - stufen: - - stufe: 1 - von: "Stakeholder-Manager:in" - an: "Leitung SHM" - modus: "E3-Team-Sync (Information)" - - - stufe: 2 - von: "Leitung SHM" - an: "Intervention" - modus: "Maßnahmeninitiierung" - entscheidung: "Leitung SHM eigenständig" - - - stufe: 3 - von: "Leitung SHM" - an: "Mission Board / Vision Board" - modus: "Information und Abstimmung" - voraussetzung: "Maßnahmen erfordern übergreifende Ressourcen" - - referenz: "shm_rollen.yaml, shm_voice-of-customer.yaml" - - # ------------------------------------------------------------------------- - - id: "ESK-05" - name: "Strukturelle SHM-Weiterentwicklung" - - situation: | - Bedarf für grundlegende Änderungen an SHM-Strukturen - (Segmentierungslogik, Ressourcen, etc.) - - stufen: - - stufe: 1 - von: "Leitung SHM" - an: "Mission Board" - modus: "Vorschlag und Abstimmung" - - - stufe: 2 - von: "Mission Board" - an: "Vision Board" - modus: "Entscheidung bei strategischer Relevanz" - - referenz: "shm_rollen.yaml → entscheidungsbefugnisse" - -# ============================================================================= -# ENTSCHEIDUNGSMATRIX -# ============================================================================= - -entscheidungsmatrix: - - beschreibung: | - Explizite Definition, wer welche Entscheidungen trifft. - Die Matrix folgt dem Subsidiaritätsprinzip (GP-SHM-04). - - legende: - A: "Accountable – trägt die Entscheidungsverantwortung" - R: "Responsible – führt aus / bereitet vor" - C: "Consulted – wird vor Entscheidung konsultiert" - I: "Informed – wird über Entscheidung informiert" - "-": "Nicht beteiligt" - - rollen: - SM: "Stakeholder-Manager:in" - SHM-L: "Leitung SHM" - DPM: "Demand-Portfolio-Manager:in" - SPM: "Service-Portfolio-Manager" - SO: "Service Owner" - DSR: "Demand & Stakeholder-Runde" - SOR: "Service Operations Runde" - MB: "Mission Board" - VB: "Vision Board" - - # --------------------------------------------------------------------------- - # OPERATIVE ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - operative_entscheidungen: - - name: "Operative Entscheidungen" - beschreibung: "Tagesgeschäft, direkt durch SHM-Rollen entschieden" - - entscheidungen: - - - id: "E-OP-01" - gegenstand: "Routing-Entscheidung (Regelfall)" - SM: "A/R" - SHM-L: "I" - DPM: "I (bei ROUTE-DPM)" - SPM: "I (bei ROUTE-SPM)" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-OP-02" - gegenstand: "Routing-Entscheidung (Grenzfall)" - SM: "R" - SHM-L: "C" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "A" - MB: "-" - VB: "-" - - - id: "E-OP-03" - gegenstand: "Bedarfssteckbrief erstellen" - SM: "A/R" - SHM-L: "-" - DPM: "C (bei Rückfragen)" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-OP-04" - gegenstand: "Turnus-Gespräch durchführen" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-OP-05" - gegenstand: "Beziehungsqualität bewerten (einzelner Stakeholder)" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-OP-06" - gegenstand: "VoC-Highlight dokumentieren" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "I (bei D2)" - SO: "I (bei D2)" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-OP-07" - gegenstand: "DSR-Teilnahme (Auftraggeber-Anwalt-Rolle)" - SM: "A/R" - SHM-L: "I" - DPM: "C" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - # --------------------------------------------------------------------------- - # TAKTISCHE ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - taktische_entscheidungen: - - name: "Taktische Entscheidungen" - beschreibung: "SHM-interne Steuerung, durch Leitung SHM entschieden" - - entscheidungen: - - - id: "E-TA-01" - gegenstand: "Betreuungsmodus anpassen (einzelner Stakeholder)" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-TA-02" - gegenstand: "Betreuungszuordnung ändern (SM ↔ Stakeholder)" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-TA-03" - gegenstand: "Ressourcenallokation innerhalb SHM" - SM: "I" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-TA-04" - gegenstand: "Maßnahmen bei VoC-Cluster-Rot initiieren" - SM: "R" - SHM-L: "A" - DPM: "C (bei Demand-Bezug)" - SPM: "C (bei Service-Bezug)" - SO: "C (bei Service-Bezug)" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - - - id: "E-TA-05" - gegenstand: "Portfolio-Priorisierung validieren" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - - - id: "E-TA-06" - gegenstand: "E2-Review-Entscheidungen (Quartals-Review)" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "I (bei strategischer Relevanz)" - VB: "-" - - - id: "E-TA-07" - gegenstand: "Stakeholder-Konflikt eskalieren" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "I (bei Eskalation)" - VB: "-" - - - id: "E-TA-08" - gegenstand: "Neuen Stakeholder ins Portfolio aufnehmen" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - # --------------------------------------------------------------------------- - # STRATEGISCHE ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - strategische_entscheidungen: - - name: "Strategische Entscheidungen" - beschreibung: "Übergreifende Entscheidungen, durch MB oder VB entschieden" - - entscheidungen: - - - id: "E-ST-01" - gegenstand: "Strukturelle SHM-Weiterentwicklung" - SM: "C" - SHM-L: "R" - DPM: "C" - SPM: "C" - SO: "-" - DSR: "-" - SOR: "-" - MB: "C" - VB: "A" - - - id: "E-ST-02" - gegenstand: "Ressourcenaufstockung SHM" - SM: "-" - SHM-L: "R" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "C" - VB: "A" - - - id: "E-ST-03" - gegenstand: "Änderung der Segmentierungslogik" - SM: "C" - SHM-L: "R" - DPM: "C" - SPM: "C" - SO: "-" - DSR: "-" - SOR: "-" - MB: "C" - VB: "A" - - - id: "E-ST-04" - gegenstand: "E1-Jahresbericht (Auftragserfüllung)" - SM: "R" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "I" - - - id: "E-ST-05" - gegenstand: "Strategische Eskalation an Vision Board" - SM: "-" - SHM-L: "R" - DPM: "-" - SPM: "-" - SO: "-" - DSR: "-" - SOR: "-" - MB: "A" - VB: "I" - - # --------------------------------------------------------------------------- - # SCHNITTSTELLEN-ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - schnittstellen_entscheidungen: - - name: "Schnittstellen-Entscheidungen" - beschreibung: "Entscheidungen an Schnittstellen zu anderen Funktionen" - - entscheidungen: - - - id: "E-SS-01" - gegenstand: "Demand-Annahme/-Ablehnung" - SM: "C (Kundenanwalt)" - SHM-L: "-" - DPM: "R" - SPM: "-" - SO: "-" - DSR: "A" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-SS-02" - gegenstand: "Demand-Priorisierung im Portfolio" - SM: "C" - SHM-L: "-" - DPM: "R" - SPM: "-" - SO: "-" - DSR: "A" - SOR: "-" - MB: "A (bei strategischen Demands)" - VB: "-" - - - id: "E-SS-03" - gegenstand: "Service-Change-Freigabe" - SM: "-" - SHM-L: "-" - DPM: "-" - SPM: "R" - SO: "A/R (je nach Impact)" - DSR: "-" - SOR: "A (bei major)" - MB: "-" - VB: "-" - - - id: "E-SS-04" - gegenstand: "Auftraggeber-Forum-Durchführung" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "R" - SO: "C" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - - - id: "E-SS-05" - gegenstand: "Service-Steckbrief Kundenverständlichkeit prüfen" - SM: "C" - SHM-L: "-" - DPM: "-" - SPM: "A" - SO: "R" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - hinweis: "Im MVP optional, später verbindlich" - -# ============================================================================= -# QUERVERWEIS GOVERNANCE-LOG -# ============================================================================= - -querverweis_governance_log: - - beschreibung: | - Mapping zwischen den Governance-Entscheidungen im Log und den - Abschnitten in diesem Framework. - - dokument: "readme_shm_governance-entscheidungs-log.yaml" - - mapping: - - portfolio_governance: - - "GOV-SHM-001: Portfolio-Grundstruktur" - - "GOV-SHM-002: Segmentierungslogik" - - "GOV-SHM-003: Ausprägungen Funktionsdimension" - - "GOV-SHM-004: Ausprägungen IT-Anforderungsprofil" - - "GOV-SHM-005: Terminologie-Harmonisierung mit SPM" - - "GOV-SHM-006: Priorisierungsdimensionen" - - "GOV-SHM-007: Einfluss-Operationalisierung" - - "GOV-SHM-008: Abhängigkeit-Operationalisierung" - - "GOV-SHM-009: Relevanz-Operationalisierung" - - "GOV-SHM-010: Betreuungsmodi" - - "GOV-SHM-011: Keine automatische Downgrades" - - "GOV-SHM-012: Review-Zyklus" - - "GOV-SHM-013: SLA-Befugnis" - - "GOV-SHM-014: Portfolio-Scope" - - routing_governance: - - "GOV-SHM-016: Stakeholder-Priorität nicht routing-relevant" - - "GOV-SHM-017: SOR-Eskalation bei Unsicherheit" - - "GOV-SHM-018: Service-Kategorie nicht routing-relevant" - - "GOV-SHM-019: Aufwandsschätzung nicht routing-relevant" - - "GOV-SHM-020: Validierungsprofile nach Routing-Pfad" - - gremien_governance: - - "GOV-SHM-015: Auftraggeber-Forum-Konsolidierung" - - "GOV-SHM-021: DSR-Rolle Kundenanwalt" - - "GOV-SHM-022: SHM bei Demand-Ablehnung" - - "GOV-SHM-025: MB-Mitgliedschaft Leitung SHM" - - steuerungs_governance: - - "GOV-SHM-023: Ergebnis- vor Prozess-Indikatoren" - - "GOV-SHM-024: Reporting-Abgrenzung zu SPM" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: | - Initiale Erstellung durch Konsolidierung der - Governance-Entscheidungen GOV-SHM-001 bis GOV-SHM-025. - - Governance-Prinzipien definiert (GP-SHM-01 bis GP-SHM-05) - - Vier Entscheidungsdomänen strukturiert - - Eskalationslogik mit 5 Pfaden +# ============================================================================= +# SHM GOVERNANCE-FRAMEWORK +# ============================================================================= +# Version: 1.0 +# Datum: 2025-12-10 +# Status: Entwurf +# Quelle: Konsolidierung aus GOV-SHM-001 bis GOV-SHM-025 +# ============================================================================= + +meta: + typ: "governance_framework" + funktion: "Stakeholder Management" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Stakeholder-Management" + + status: + inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" + status: "entwurf" + + kontext_tags: + - "governance" + - "stakeholder-management" + - "entscheidungslogik" + - "eskalation" + + zweck: | + Dieses Dokument konsolidiert die Governance-Entscheidungen, die während + der SHM-Konzeptentwicklung (Phase 1-6) getroffen wurden, zu einem + kohärenten Regelwerk. + + Es definiert: + - Governance-Prinzipien für SHM-Entscheidungen + - Entscheidungsdomänen und deren Regeln + - Eskalationslogik und -pfade + - Entscheidungsmatrix (wer entscheidet was) + + abgrenzung: | + Dieses Framework regelt die SHM-interne Governance und die + Schnittstellen-Governance zu anderen Funktionen. Es ersetzt nicht: + - Die RACI-Matrix (shm_raci.yaml) für operative Verantwortlichkeiten + - Die Koordinations- und Steuerungsstruktur für Review-Prozesse + - Die Rollenbeschreibungen für Aufgabenprofile + + quellen: + - dokument: "readme_shm_governance-entscheidungs-log.yaml" + beschreibung: "Vollständige Dokumentation aller 25 Governance-Entscheidungen" + - dokument: "shm_rollen.yaml" + beschreibung: "Entscheidungsbefugnisse der Rollen" + - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" + beschreibung: "E1/E2/E3 Entscheidungstypen" + +# ============================================================================= +# GOVERNANCE-PRINZIPIEN +# ============================================================================= + +governance_prinzipien: + + beschreibung: | + Die folgenden Prinzipien leiten alle Governance-Entscheidungen im + SHM-Kontext. Sie wurden aus den konkreten Entscheidungen (GOV-SHM-001 + bis GOV-SHM-025) abstrahiert und bilden das normative Fundament. + + prinzipien: + + - id: "GP-SHM-01" + name: "Substanz vor Herkunft" + + beschreibung: | + Die Routing-Entscheidung für einen Bedarf basiert ausschließlich + auf der Natur des Bedarfs ("Was ist es?"), nicht auf Eigenschaften + des einreichenden Stakeholders. + + konsequenzen: + - "Stakeholder-Priorität beeinflusst nicht das Routing" + - "Service-Kategorie (A/B/C) ist informativ, nicht entscheidungsrelevant" + - "Aufwandsschätzung ist informativ, nicht routing-relevant" + - "Ein Demand bleibt ein Demand, unabhängig von wer ihn einreicht" + + governance_referenz: + - "GOV-SHM-016" + - "GOV-SHM-018" + - "GOV-SHM-019" + + - id: "GP-SHM-02" + name: "Unsicherheit legitimiert Eskalation" + + beschreibung: | + Es gibt keine objektiven Schwellenwerte für Eskalationen. Die + qualifizierte Unsicherheit des Stakeholder-Managers ist ein + legitimes und ausreichendes Kriterium für eine SOR-Eskalation. + + begruendung: | + Objektivierte Kriterien würden zu Schein-Objektivität führen. + Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu erkennen + und angemessen zu eskalieren. Das System vertraut auf professionelles + Urteilsvermögen statt auf mechanische Regeln. + + governance_referenz: + - "GOV-SHM-017" + + - id: "GP-SHM-03" + name: "Ergebnis vor Aktivität" + + beschreibung: | + Die SHM-Steuerung fokussiert auf Ergebnis-Indikatoren + (Beziehungsqualität, VoC-Cluster-Status), nicht auf + Prozess-Indikatoren (Anzahl Gespräche, Durchlaufzeiten). + + konsequenzen: + - "Primäre Indikatoren: Beziehungsqualität, VoC-Ampeln, Highlights" + - "Sekundäre Indikatoren (intern): Gesprächsquoten, Routing-Statistik" + - "Review-Templates enthalten narrative Einschätzungen" + - "Keine Prozess-Metriken-Tabellen in formalen Berichten" + + governance_referenz: + - "GOV-SHM-023" + + - id: "GP-SHM-04" + name: "Subsidiarität in der Entscheidung" + + beschreibung: | + Entscheidungen werden auf der niedrigsten Ebene getroffen, die + dafür kompetent ist. Eskalation erfolgt nur, wenn die Ebene + die Entscheidung nicht treffen kann oder darf. + + ebenen: + - ebene: "Operativ" + entscheider: "Stakeholder-Manager:in" + beispiele: + - "Routing-Entscheidung im Regelfall" + - "Bedarfssteckbrief-Erstellung" + - "Turnus-Gespräch durchführen" + + - ebene: "Taktisch" + entscheider: "Leitung SHM" + beispiele: + - "Betreuungsmodus anpassen" + - "Ressourcenallokation innerhalb SHM" + - "E2-Review-Entscheidungen" + + - ebene: "Strategisch" + entscheider: "Mission Board / Vision Board" + beispiele: + - "Strukturelle SHM-Weiterentwicklung" + - "Ressourcenaufstockung" + - "Änderung der Segmentierungslogik" + + governance_referenz: + - "shm_rollen.yaml → entscheidungsbefugnisse" + + - id: "GP-SHM-05" + name: "Klare Verantwortungstrennung" + + beschreibung: | + SHM und SPM haben klar getrennte Verantwortungsbereiche. + Es gibt keine Doppel-Zuständigkeiten, aber definierte + Schnittstellen für den Informationsaustausch. + + verantwortungstrennung: + shm_verantwortet: + - "Beziehungsqualität (VoC-Dimension D1)" + - "Bedarfserfüllung (VoC-Dimension D3)" + - "Strategische Passung (VoC-Dimension D4)" + - "Aggregierte Stakeholder-Sicht (Portfolio-Perspektive)" + + spm_verantwortet: + - "Service-Qualität (VoC-Dimension D2)" + - "SLA-Erfüllung" + - "Einzelne Service-Performance (Service-Perspektive)" + + gemeinsam: + - "Auftraggeber-Forum (integriertes Format)" + - "Eskalationen, die beide Bereiche betreffen" + + governance_referenz: + - "GOV-SHM-024" + +# ============================================================================= +# ENTSCHEIDUNGSDOMÄNEN +# ============================================================================= + +entscheidungsdomaenen: + + beschreibung: | + Die Governance-Entscheidungen sind in vier Domänen gruppiert. + Jede Domäne hat spezifische Regeln und Entscheidungslogiken. + + # --------------------------------------------------------------------------- + # DOMÄNE A: PORTFOLIO-GOVERNANCE + # --------------------------------------------------------------------------- + + portfolio_governance: + + name: "Portfolio-Governance" + beschreibung: | + Regeln für die Struktur, Pflege und Steuerung des + Stakeholder-Portfolios. + + governance_referenzen: + - "GOV-SHM-001 bis GOV-SHM-014" + + teilbereiche: + + # ----------------------------------------------------------------------- + portfolio_struktur: + + name: "Portfolio-Grundstruktur" + + regel: | + Das Stakeholder-Portfolio folgt einem Drei-Ebenen-Modell: + 1. Amts-Steckbrief (Datengrundlage pro Organisationseinheit) + 2. Segmentierung (Clustering nach zwei Dimensionen) + 3. Priorisierung (Bewertung zur Betreuungsallokation) + + scope: | + Alle Einheiten im Dezernatsverteilungsplan: + Ämter, Eigenbetriebe, Referate, Stabsstellen, Projektgruppen + + referenz: "GOV-SHM-001, GOV-SHM-014" + + # ----------------------------------------------------------------------- + segmentierung: + + name: "Segmentierungslogik" + + dimensionen: + - dimension: "Funktion" + beschreibung: "Organisatorische Rolle im Verwaltungsgefüge" + auspraegungen: + - "Kernverwaltung" + - "Bürgerdienste" + - "Fachbehoerde" + - "Eigenbetrieb" + - "Sondereinheit" + + - dimension: "IT-Anforderungsprofil" + beschreibung: "Typische Bedarfskomplexität" + auspraegungen: + - id: "Basis" + beschreibung: "Standardisierte IT-Nutzung" + spm_mapping: "Kategorie A – Basis-Services" + - id: "Erweitert" + beschreibung: "Über Standard hinausgehende Anforderungen" + spm_mapping: "Kategorie B – Erweiterte Services" + - id: "Spezial" + beschreibung: "Hochspezialisierte Anforderungen" + spm_mapping: "Kategorie C – Spezial-Services" + + regel: | + Jedes Amt erhält genau eine Ausprägung pro Dimension + (keine Mehrfachzuordnung, keine Tags). + + referenz: "GOV-SHM-002 bis GOV-SHM-005" + + # ----------------------------------------------------------------------- + priorisierung: + + name: "Priorisierungslogik" + + dimensionen: + - dimension: "Einfluss" + beschreibung: "Politisches Gewicht, Entscheidungsmacht" + skala: "1-3 (niedrig bis hoch)" + stabilitaet: "Hoch (ändert sich selten)" + + - dimension: "Abhängigkeit" + beschreibung: "Grad der IT-Abhängigkeit für Kernaufgaben" + skala: "1-3 (niedrig bis hoch)" + stabilitaet: "Hoch (ändert sich selten)" + + - dimension: "Relevanz" + beschreibung: "Aktuelle strategische Bedeutung" + skala: "1-3 (niedrig bis hoch)" + stabilitaet: "Dynamisch (politische Themen kommen und gehen)" + + aggregation: + methode: "Summe der drei Dimensionen" + skala: "3-9 Punkte" + mapping: + - punktzahl: "7-9" + modus: "Key-Stakeholder" + - punktzahl: "5-6" + modus: "Aktiv" + - punktzahl: "3-4" + modus: "Standard" + - punktzahl: "< 3" + modus: "Basis" + hinweis: "Theoretisch möglich, praktisch unwahrscheinlich" + + review_zyklus: | + Überprüfung im Rahmen der E2-Reviews (quartalsweise). + Insbesondere die Dimension "Relevanz" erfordert regelmäßige + Aktualisierung. + + referenz: "GOV-SHM-006 bis GOV-SHM-012" + + # ----------------------------------------------------------------------- + sla_befugnis: + + name: "SLA-Partner-Befugnis" + + regel: | + Analog zur SPM-Logik (P-02 SLM): + - Primär: Amtsleitung + - Alternativ: Delegierte Person mit dokumentierter + Entscheidungsbefugnis + + Die Delegation muss dokumentiert sein (Amts-Steckbrief). + + begruendung: | + SLA-Partner müssen Entscheidungsbefugnis haben, nicht nur + operative Ansprechpartner sein. Konsistenz mit SPM-Governance. + + referenz: "GOV-SHM-013, SPM GOV-005" + + # --------------------------------------------------------------------------- + # DOMÄNE B: ROUTING-GOVERNANCE + # --------------------------------------------------------------------------- + + routing_governance: + + name: "Routing-Governance" + beschreibung: | + Regeln für die Bedarfsbewertung und das Routing von + Stakeholder-Bedarfen zu den richtigen Empfängern. + + governance_referenzen: + - "GOV-SHM-016 bis GOV-SHM-020" + + teilbereiche: + + # ----------------------------------------------------------------------- + routing_entscheidung: + + name: "Routing-Entscheidungslogik" + + grundprinzip: | + Die Routing-Entscheidung beantwortet: "Was ist dieser Bedarf?" + Sie basiert auf der Natur des Bedarfs, nicht auf: + - Stakeholder-Priorität + - Service-Kategorie (A/B/C) + - Aufwandsschätzung + + routing_pfade: + - id: "ROUTE-REQ" + name: "Service Request" + ziel: "Service Desk / Service Operations" + kriterium: "Bedarf ist im Katalog abbildbar als Request" + steckbrief: "Nicht erforderlich" + + - id: "ROUTE-SPM" + name: "Change an bestehendem Service" + ziel: "SPM / Service Owner" + kriterium: "Bedarf betrifft bestehenden Service, kein neuer Service" + steckbrief: "Reduziert (keine Stakeholder-Freigabe)" + + - id: "ROUTE-SO" + name: "Service-Owner-Klärung" + ziel: "Service Owner (über Service-Portfolio / SPM)" + kriterium: "SM ist unsicher über korrektes Routing; SO entscheidet bilateral" + steckbrief: "Reduziert + SHM-Einschätzung mit konkreter Frage" + hinweis: "Service Owner entscheidet bilateral mit SHM. RUN/Change → SOR; Demand → DPM/DSR" + + - id: "ROUTE-DPM" + name: "Demand" + ziel: "Demand Portfolio Management" + kriterium: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" + steckbrief: "Vollständig (mit Stakeholder-Freigabe)" + + referenz: "GOV-SHM-016, GOV-SHM-018, GOV-SHM-019, GOV-SHM-020" + + # ----------------------------------------------------------------------- + so_routing_klaerung: + + name: "Service-Owner-Routing-Klärungslogik" + + trigger: | + Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. + Es gibt keine quantitativen Schwellenwerte. + + voraussetzung: | + Der Stakeholder-Manager muss die Unsicherheit konkret benennen + können ("Ich bin unsicher, ob X oder Y zutrifft, weil..."). + + begruendung: | + Objektivierte Kriterien würden zu Schein-Objektivität führen. + Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu + erkennen und angemessen zu eskalieren. + + Die bilaterale Klärung mit dem Service Owner ist das geeignete + Verfahren. Der SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. + + referenz: "GOV-SHM-017, GOV-SHM-029" + + # ----------------------------------------------------------------------- + validierungsprofile: + + name: "Bedarfssteckbrief-Validierung" + + regel: | + Die Validierungsanforderungen im Bedarfssteckbrief variieren + je nach Routing-Ziel. + + profile: + - routing: "ROUTE-REQ" + pflichtfelder: "Keine (kein Steckbrief)" + stakeholder_freigabe: "Nein" + + - routing: "ROUTE-SPM" + pflichtfelder: "Basisdaten, Bedarfsbeschreibung, Service-Katalog-Prüfung" + stakeholder_freigabe: "Nein" + + - routing: "ROUTE-SO" + pflichtfelder: "Wie ROUTE-SPM + SHM-Einschätzung mit Frage" + stakeholder_freigabe: "Nein" + hinweis: "Routing-Klärung erfolgt bilateral mit Service Owner" + + - routing: "ROUTE-DPM" + pflichtfelder: "Vollständiger Steckbrief inkl. User Stories" + stakeholder_freigabe: "Ja" + + referenz: "GOV-SHM-020" + + # --------------------------------------------------------------------------- + # DOMÄNE C: GREMIEN-GOVERNANCE + # --------------------------------------------------------------------------- + + gremien_governance: + + name: "Gremien-Governance" + beschreibung: | + Regeln für die Mitwirkung von SHM in den DIGIT-Gremien + und die Koordination mit anderen Funktionen. + + governance_referenzen: + - "GOV-SHM-015, GOV-SHM-021, GOV-SHM-022, GOV-SHM-025" + + teilbereiche: + + # ----------------------------------------------------------------------- + dsr_rolle: + + name: "Rolle in der Demand & Stakeholder-Runde (DSR)" + + teilnehmer: "Stakeholder-Manager:in (für zugeordnete Stakeholder)" + + rolle: "Auftraggeber-Anwalt" + + funktion: | + Vertretung der Stakeholder-Perspektive bei Demand-Entscheidungen. + Sicherstellen, dass Auftraggeber-Interessen angemessen berücksichtigt werden. + + befugnisse: + - "Stimmberechtigtes Mitglied" + - "Einwand-Recht bei Demand-Entscheidungen" + - "Kontextinformation zu Stakeholder-Situation einbringen" + + grenzen: + - "Vertritt Kundenperspektive, aber akzeptiert Gremienentscheidungen" + - "Entscheidet nicht über Demands, sondern bringt Perspektive ein" + + referenz: "GOV-SHM-021" + + # ----------------------------------------------------------------------- + mb_rolle: + + name: "Rolle im Mission Board (MB)" + + teilnehmer: "Leitung SHM" + status: "Vollwertiges Mitglied" + + funktion: | + Vertretung der Stakeholder-Perspektive auf strategisch-taktischer + Ebene. Bewertung von Entscheidungsauswirkungen auf Stakeholder. + + differenzierung: | + Die Aussage "SHM ist kein ständiges MB-Mitglied" (GOV-SHM-022) + bezog sich auf die operative Rolle (Stakeholder-Manager:in). + Die Leitung SHM ist als Abteilungsleitung vollwertiges MB-Mitglied. + + referenz: "GOV-SHM-022, GOV-SHM-025" + + # ----------------------------------------------------------------------- + kundenforum: + + name: "Auftraggeber-Forum-Konzept" + + regel: | + Die SHM-Advisory-Boards und die SLM-Kundenvertretungen werden + zu einem integrierten "Auftraggeber-Forum"-Konzept konsolidiert. + + formate: + - id: "KF-01" + name: "Auftraggeber-Forum Basisservices" + zielgruppe: "Nutzer von Kategorie-A-Services" + verantwortung: "Gemeinsam SHM + SPM" + + - id: "KF-02" + name: "Auftraggeber-Forum Fachverfahren" + zielgruppe: "Nutzer von Kategorie-B/C-Services" + verantwortung: "Gemeinsam SHM + SPM" + + - id: "KF-03" + name: "Basis-Puls-Check" + zielgruppe: "Basis-Stakeholder" + verantwortung: "SHM" + + begruendung: | + Ein Gremium statt paralleler Formate mit denselben Teilnehmern. + Reduziert Aufwand für Ämter und DIGIT, stärkt gemeinsame + Außenwirkung. + + referenz: "GOV-SHM-015, SPM GOV-012" + + # --------------------------------------------------------------------------- + # DOMÄNE D: STEUERUNGS-GOVERNANCE + # --------------------------------------------------------------------------- + + steuerungs_governance: + + name: "Steuerungs-Governance" + beschreibung: | + Regeln für die interne SHM-Steuerung, das Reporting und die + Abgrenzung zu anderen Funktionen. + + governance_referenzen: + - "GOV-SHM-023, GOV-SHM-024" + + teilbereiche: + + # ----------------------------------------------------------------------- + steuerungsfokus: + + name: "Steuerungsfokus" + + regel: | + SHM-Steuerung fokussiert auf Ergebnis-Indikatoren, nicht auf + Prozess-Indikatoren. + + primaere_indikatoren: + - "Beziehungsqualität im Portfolio" + - "VoC-Cluster-Ampeln" + - "Qualitative Highlights" + + sekundaere_indikatoren: + beschreibung: "Für operative Selbstvergewisserung, nicht formal berichtet" + beispiele: + - "Gesprächsquoten" + - "Routing-Statistik" + - "Durchlaufzeiten Bedarfssteckbrief" + + referenz: "GOV-SHM-023" + + # ----------------------------------------------------------------------- + reporting_abgrenzung: + + name: "Reporting-Abgrenzung zu SPM" + + regel: | + SHM und SPM haben getrennte Reporting-Verantwortungen. + Kein Doppel-Reporting, keine widersprüchlichen Bewertungen. + + shm_berichtet: + - "Beziehungsqualität (VoC-D1)" + - "Bedarfserfüllung (VoC-D3)" + - "Strategische Passung (VoC-D4)" + - "Portfolio-Gesamtbild" + + spm_berichtet: + - "Service-Qualität (VoC-D2)" + - "SLA-Erfüllung" + - "Service-Performance" + + schnittstellen: + - schnittstelle: "VoC-Feedback zu D2" + von: "SHM" + an: "SPM / Service Owner" + beschreibung: "SHM erfasst, leitet weiter, berichtet nicht selbst" + + - schnittstelle: "Service-Performance-Daten" + von: "SPM" + an: "SHM (Leserecht)" + beschreibung: "SHM nutzt als Kontext, berichtet nicht selbst" + + referenz: "GOV-SHM-024" + +# ============================================================================= +# ESKALATIONSLOGIK +# ============================================================================= + +eskalationslogik: + + beschreibung: | + Definition der Eskalationspfade für verschiedene Situationen. + Eskalation bedeutet die Weiterleitung einer Entscheidung oder eines + Themas an eine höhere Instanz. + + grundprinzip: | + Eskalation ist kein Zeichen von Versagen, sondern ein legitimes + Instrument zur Sicherstellung angemessener Entscheidungsqualität. + Das System vertraut auf das professionelle Urteil der Beteiligten. + + pfade: + + # ------------------------------------------------------------------------- + - id: "ESK-01" + name: "Routing-Unsicherheit" + + situation: | + Stakeholder-Manager ist unsicher, welcher Routing-Pfad + der richtige ist. + + stufen: + - stufe: 1 + von: "Stakeholder-Manager:in" + an: "Leitung SHM" + modus: "Beratung (informell)" + + - stufe: 2 + von: "Stakeholder-Manager:in" + an: "Service Owner" + modus: "Bilaterale Klärung (ROUTE-SO)" + voraussetzung: "Unsicherheit konkret benannt" + + referenz: "GOV-SHM-017, GOV-SHM-029" + + begruendung_aenderung: | + Routing-Klärungen werden bilateral mit dem Service Owner behandelt. + Der SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. + Siehe GOV-SHM-029. + + # ------------------------------------------------------------------------- + - id: "ESK-02" + name: "Stakeholder-Konflikt" + + situation: | + Konflikt mit Stakeholder, der auf operativer Ebene nicht + lösbar ist. + + stufen: + - stufe: 1 + von: "Stakeholder-Manager:in" + an: "Leitung SHM" + modus: "Eskalation zur Übernahme/Moderation" + + - stufe: 2 + von: "Leitung SHM" + an: "Mission Board" + modus: "Strategische Eskalation" + voraussetzung: "Politische Dimension oder übergreifende Auswirkung" + + - stufe: 3 + von: "Mission Board" + an: "Vision Board" + modus: "Eskalation bei strategischer Relevanz" + + # ------------------------------------------------------------------------- + - id: "ESK-03" + name: "Demand-Ablehnung" + + situation: | + Demand wird abgelehnt und Stakeholder ist unzufrieden. + + stufen: + - stufe: 1 + von: "Stakeholder-Manager:in" + an: "Stakeholder" + modus: "Vermittlung und Erklärung" + differenzierung: + key_aktiv: "Aktive Begleitung bis zur Akzeptanz" + standard_basis: "Sachliche Kommunikation" + + - stufe: 2 + von: "Stakeholder-Manager:in" + an: "Leitung SHM" + modus: "Eskalation bei Nicht-Akzeptanz" + + - stufe: 3 + von: "Leitung SHM" + an: "Mission Board" + modus: "Strategische Eskalation" + voraussetzung: "Beziehungsschaden droht" + + referenz: "GOV-SHM-022" + + # ------------------------------------------------------------------------- + - id: "ESK-04" + name: "VoC-Cluster-Rot" + + situation: | + Ein VoC-Cluster zeigt kritischen Status (Rot). + + stufen: + - stufe: 1 + von: "Stakeholder-Manager:in" + an: "Leitung SHM" + modus: "E3-Team-Sync (Information)" + + - stufe: 2 + von: "Leitung SHM" + an: "Intervention" + modus: "Maßnahmeninitiierung" + entscheidung: "Leitung SHM eigenständig" + + - stufe: 3 + von: "Leitung SHM" + an: "Mission Board / Vision Board" + modus: "Information und Abstimmung" + voraussetzung: "Maßnahmen erfordern übergreifende Ressourcen" + + referenz: "shm_rollen.yaml, shm_voice-of-customer.yaml" + + # ------------------------------------------------------------------------- + - id: "ESK-05" + name: "Strukturelle SHM-Weiterentwicklung" + + situation: | + Bedarf für grundlegende Änderungen an SHM-Strukturen + (Segmentierungslogik, Ressourcen, etc.) + + stufen: + - stufe: 1 + von: "Leitung SHM" + an: "Mission Board" + modus: "Vorschlag und Abstimmung" + + - stufe: 2 + von: "Mission Board" + an: "Vision Board" + modus: "Entscheidung bei strategischer Relevanz" + + referenz: "shm_rollen.yaml → entscheidungsbefugnisse" + +# ============================================================================= +# ENTSCHEIDUNGSMATRIX +# ============================================================================= + +entscheidungsmatrix: + + beschreibung: | + Explizite Definition, wer welche Entscheidungen trifft. + Die Matrix folgt dem Subsidiaritätsprinzip (GP-SHM-04). + + legende: + A: "Accountable – trägt die Entscheidungsverantwortung" + R: "Responsible – führt aus / bereitet vor" + C: "Consulted – wird vor Entscheidung konsultiert" + I: "Informed – wird über Entscheidung informiert" + "-": "Nicht beteiligt" + + rollen: + SM: "Stakeholder-Manager:in" + SHM-L: "Leitung SHM" + DPM: "Demand-Portfolio-Manager:in" + SPM: "Service-Portfolio-Manager" + SO: "Service Owner" + DSR: "Demand & Stakeholder-Runde" + SOR: "Service Operations Runde" + MB: "Mission Board" + VB: "Vision Board" + + # --------------------------------------------------------------------------- + # OPERATIVE ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + operative_entscheidungen: + + name: "Operative Entscheidungen" + beschreibung: "Tagesgeschäft, direkt durch SHM-Rollen entschieden" + + entscheidungen: + + - id: "E-OP-01" + gegenstand: "Routing-Entscheidung (Regelfall)" + SM: "A/R" + SHM-L: "I" + DPM: "I (bei ROUTE-DPM)" + SPM: "I (bei ROUTE-SPM)" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-OP-02" + gegenstand: "Routing-Entscheidung (Grenzfall)" + SM: "R" + SHM-L: "C" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "A" + MB: "-" + VB: "-" + + - id: "E-OP-03" + gegenstand: "Bedarfssteckbrief erstellen" + SM: "A/R" + SHM-L: "-" + DPM: "C (bei Rückfragen)" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-OP-04" + gegenstand: "Turnus-Gespräch durchführen" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-OP-05" + gegenstand: "Beziehungsqualität bewerten (einzelner Stakeholder)" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-OP-06" + gegenstand: "VoC-Highlight dokumentieren" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "I (bei D2)" + SO: "I (bei D2)" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-OP-07" + gegenstand: "DSR-Teilnahme (Auftraggeber-Anwalt-Rolle)" + SM: "A/R" + SHM-L: "I" + DPM: "C" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + # --------------------------------------------------------------------------- + # TAKTISCHE ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + taktische_entscheidungen: + + name: "Taktische Entscheidungen" + beschreibung: "SHM-interne Steuerung, durch Leitung SHM entschieden" + + entscheidungen: + + - id: "E-TA-01" + gegenstand: "Betreuungsmodus anpassen (einzelner Stakeholder)" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-TA-02" + gegenstand: "Betreuungszuordnung ändern (SM ↔ Stakeholder)" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-TA-03" + gegenstand: "Ressourcenallokation innerhalb SHM" + SM: "I" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-TA-04" + gegenstand: "Maßnahmen bei VoC-Cluster-Rot initiieren" + SM: "R" + SHM-L: "A" + DPM: "C (bei Demand-Bezug)" + SPM: "C (bei Service-Bezug)" + SO: "C (bei Service-Bezug)" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + + - id: "E-TA-05" + gegenstand: "Portfolio-Priorisierung validieren" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + + - id: "E-TA-06" + gegenstand: "E2-Review-Entscheidungen (Quartals-Review)" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "I (bei strategischer Relevanz)" + VB: "-" + + - id: "E-TA-07" + gegenstand: "Stakeholder-Konflikt eskalieren" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "I (bei Eskalation)" + VB: "-" + + - id: "E-TA-08" + gegenstand: "Neuen Stakeholder ins Portfolio aufnehmen" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + # --------------------------------------------------------------------------- + # STRATEGISCHE ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + strategische_entscheidungen: + + name: "Strategische Entscheidungen" + beschreibung: "Übergreifende Entscheidungen, durch MB oder VB entschieden" + + entscheidungen: + + - id: "E-ST-01" + gegenstand: "Strukturelle SHM-Weiterentwicklung" + SM: "C" + SHM-L: "R" + DPM: "C" + SPM: "C" + SO: "-" + DSR: "-" + SOR: "-" + MB: "C" + VB: "A" + + - id: "E-ST-02" + gegenstand: "Ressourcenaufstockung SHM" + SM: "-" + SHM-L: "R" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "C" + VB: "A" + + - id: "E-ST-03" + gegenstand: "Änderung der Segmentierungslogik" + SM: "C" + SHM-L: "R" + DPM: "C" + SPM: "C" + SO: "-" + DSR: "-" + SOR: "-" + MB: "C" + VB: "A" + + - id: "E-ST-04" + gegenstand: "E1-Jahresbericht (Auftragserfüllung)" + SM: "R" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "I" + + - id: "E-ST-05" + gegenstand: "Strategische Eskalation an Vision Board" + SM: "-" + SHM-L: "R" + DPM: "-" + SPM: "-" + SO: "-" + DSR: "-" + SOR: "-" + MB: "A" + VB: "I" + + # --------------------------------------------------------------------------- + # SCHNITTSTELLEN-ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + schnittstellen_entscheidungen: + + name: "Schnittstellen-Entscheidungen" + beschreibung: "Entscheidungen an Schnittstellen zu anderen Funktionen" + + entscheidungen: + + - id: "E-SS-01" + gegenstand: "Demand-Annahme/-Ablehnung" + SM: "C (Kundenanwalt)" + SHM-L: "-" + DPM: "R" + SPM: "-" + SO: "-" + DSR: "A" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-SS-02" + gegenstand: "Demand-Priorisierung im Portfolio" + SM: "C" + SHM-L: "-" + DPM: "R" + SPM: "-" + SO: "-" + DSR: "A" + SOR: "-" + MB: "A (bei strategischen Demands)" + VB: "-" + + - id: "E-SS-03" + gegenstand: "Service-Change-Freigabe" + SM: "-" + SHM-L: "-" + DPM: "-" + SPM: "R" + SO: "A/R (je nach Impact)" + DSR: "-" + SOR: "A (bei major)" + MB: "-" + VB: "-" + + - id: "E-SS-04" + gegenstand: "Auftraggeber-Forum-Durchführung" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "R" + SO: "C" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + + - id: "E-SS-05" + gegenstand: "Service-Steckbrief Kundenverständlichkeit prüfen" + SM: "C" + SHM-L: "-" + DPM: "-" + SPM: "A" + SO: "R" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + hinweis: "Im MVP optional, später verbindlich" + +# ============================================================================= +# QUERVERWEIS GOVERNANCE-LOG +# ============================================================================= + +querverweis_governance_log: + + beschreibung: | + Mapping zwischen den Governance-Entscheidungen im Log und den + Abschnitten in diesem Framework. + + dokument: "readme_shm_governance-entscheidungs-log.yaml" + + mapping: + + portfolio_governance: + - "GOV-SHM-001: Portfolio-Grundstruktur" + - "GOV-SHM-002: Segmentierungslogik" + - "GOV-SHM-003: Ausprägungen Funktionsdimension" + - "GOV-SHM-004: Ausprägungen IT-Anforderungsprofil" + - "GOV-SHM-005: Terminologie-Harmonisierung mit SPM" + - "GOV-SHM-006: Priorisierungsdimensionen" + - "GOV-SHM-007: Einfluss-Operationalisierung" + - "GOV-SHM-008: Abhängigkeit-Operationalisierung" + - "GOV-SHM-009: Relevanz-Operationalisierung" + - "GOV-SHM-010: Betreuungsmodi" + - "GOV-SHM-011: Keine automatische Downgrades" + - "GOV-SHM-012: Review-Zyklus" + - "GOV-SHM-013: SLA-Befugnis" + - "GOV-SHM-014: Portfolio-Scope" + + routing_governance: + - "GOV-SHM-016: Stakeholder-Priorität nicht routing-relevant" + - "GOV-SHM-017: SOR-Eskalation bei Unsicherheit" + - "GOV-SHM-018: Service-Kategorie nicht routing-relevant" + - "GOV-SHM-019: Aufwandsschätzung nicht routing-relevant" + - "GOV-SHM-020: Validierungsprofile nach Routing-Pfad" + + gremien_governance: + - "GOV-SHM-015: Auftraggeber-Forum-Konsolidierung" + - "GOV-SHM-021: DSR-Rolle Kundenanwalt" + - "GOV-SHM-022: SHM bei Demand-Ablehnung" + - "GOV-SHM-025: MB-Mitgliedschaft Leitung SHM" + + steuerungs_governance: + - "GOV-SHM-023: Ergebnis- vor Prozess-Indikatoren" + - "GOV-SHM-024: Reporting-Abgrenzung zu SPM" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: | + Initiale Erstellung durch Konsolidierung der + Governance-Entscheidungen GOV-SHM-001 bis GOV-SHM-025. + - Governance-Prinzipien definiert (GP-SHM-01 bis GP-SHM-05) + - Vier Entscheidungsdomänen strukturiert + - Eskalationslogik mit 5 Pfaden - Explizite Entscheidungsmatrix mit 20 Entscheidungsgegenständen \ No newline at end of file diff --git a/#03_stakeholder-management/#03.2_governance/shm_raci.yaml b/#03_stakeholder-management/#03.2_governance/shm_raci.yaml index 649495d..846171e 100644 --- a/#03_stakeholder-management/#03.2_governance/shm_raci.yaml +++ b/#03_stakeholder-management/#03.2_governance/shm_raci.yaml @@ -1,1540 +1,1540 @@ -# ======================================== -# RACI-Matrix Stakeholder-Management -# ======================================== -# Version: 0.1 (Platzhalter) -# Datum: 2024-12-03 -# Status: Ausstehend -# Entwicklungsphase: 9 -# ======================================== - -# ITIL4-Referenz (falls zutreffend): -# itil4_referenz: -# practice: "" -# relevante_elemente: [] -# adaption_fuer_digitom: "" - -# ======================================== -# INHALT -# ======================================== - -# [Inhalt folgt in Phase 9] -# ============================================================================= -# SHM RACI-MATRIX -# ============================================================================= -# Version: 1.0 -# Datum: 2025-12-10 -# Status: Entwurf -# Quelle: Ableitung aus SHM-Konzepten und Governance-Framework -# ============================================================================= - -meta: - typ: "raci_matrix" - scope: "Stakeholder Management" - version: "1.0" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Stakeholder-Management" - - status: - inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" - status: "entwurf" - - kontext_tags: - - "verantwortlichkeiten" - - "raci" - - "stakeholder-management" - - "governance" - - zweck: | - Diese RACI-Matrix definiert die Verantwortlichkeiten für alle - SHM-Aktivitäten. Sie operationalisiert das Governance-Framework - (shm_governance-framework.yaml) auf Aktivitätsebene. - - abgrenzung: | - - Das Governance-Framework definiert Entscheidungslogik und -gegenstände - - Diese RACI definiert operative Verantwortlichkeiten pro Aktivität - - Die Rollenbeschreibungen (shm_rollen.yaml) definieren Aufgabenprofile - - Bei Konflikten gilt: Governance-Framework > RACI > Rollenbeschreibungen - -# ============================================================================= -# GOVERNANCE-PRINZIPIEN -# ============================================================================= - -governance_prinzipien: - - beschreibung: | - Analog zu DPM nutzt SHM einen differenzierten RACI-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" - anwendung_shm: - - "Routing-Entscheidung im Regelfall" - - "Bedarfssteckbrief-Erstellung" - - "Turnus-Gespräch durchführen" - - "Beziehungsqualität bewerten" - - - id: "GP2" - name: "Governance-Gates" - regel: "A ≠ R getrennt" - beschreibung: | - Bei Kontrollpunkten und Gremienentscheidungen wird - Ausführung und Verantwortung bewusst getrennt. - begruendung: "Vier-Augen-Prinzip, Checks & Balances" - anwendung_shm: - - "Routing-Entscheidung bei Grenzfällen (SM bereitet vor, SOR entscheidet)" - - "Demand-Annahme (SO routet direkt an DPM, kein DSR-Weg)" - - "Portfolio-Priorisierung validieren (SM bewertet, SHM-L validiert)" - - - id: "GP3" - name: "Klare Übergänge" - regel: "A ≠ R an Schnittstellen" - beschreibung: | - Bei Übergaben zwischen Funktionen erfolgt explizite - Verantwortungsübergabe. - begruendung: "Eindeutige Verantwortungswechsel, Vermeidung von Lücken" - anwendung_shm: - - "Bedarf an DPM übergeben" - - "Change an SPM/SO übergeben" - - "VoC-Feedback an SPM weiterleiten" - -# ============================================================================= -# 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" - regel: "Genau ein A pro Aktivität" - - C: - name: "Consulted" - beschreibung: "Wird vor der Entscheidung/Ausführung konsultiert, gibt fachlichen Input" - - I: - name: "Informed" - beschreibung: "Wird über das Ergebnis informiert" - - "-": - name: "Nicht beteiligt" - beschreibung: "Keine Rolle bei dieser Aktivität" - - kombinationen: - "A/R": "Accountable und Responsible in einer Rolle (GP1)" - "(A)": "Eskalationsinstanz bei Konflikten" - -# ============================================================================= -# ROLLEN -# ============================================================================= - -rollen: - - shm_intern: - - - id: "SM" - name: "Stakeholder-Manager:in" - beschreibung: "Operative Betreuung der zugeordneten Stakeholder" - referenz: "shm_rollen.yaml → stakeholder_manager" - - - id: "SHM-L" - name: "Leitung Stakeholder Management" - beschreibung: "Abteilungsleitung, strategische Steuerung" - referenz: "shm_rollen.yaml → leitung_shm" - - digit_intern: - - - id: "DPM" - name: "Demand-Portfolio-Manager:in" - beschreibung: "Steuerung des Demand-Portfolios" - referenz: "dpm_rollen.yaml" - - - id: "SPM" - name: "Service-Portfolio-Manager" - beschreibung: "Steuerung des Service-Portfolios" - referenz: "spm_rollen.yaml" - - - id: "SO" - name: "Service Owner" - beschreibung: "Fachliche Verantwortung für einen Service" - referenz: "spm_rollen.yaml" - - - id: "SD" - name: "Service Desk" - beschreibung: "First Level Support, Request-Annahme" - referenz: "ssm_rollen.yaml" - - gremien: - - - id: "DSR" - name: "Demand & Stakeholder-Runde" - beschreibung: "Operative Demand-Entscheidungen" - referenz: "dsr-geschaeftsordnung.yaml" - - - id: "SOR" - name: "Service Operations Runde" - beschreibung: "Service-bezogene Entscheidungen, Routing-Klärung" - referenz: "sor-geschaeftsordnung.yaml" - - - id: "MB" - name: "Mission Board" - beschreibung: "Strategisch-taktische Steuerung" - referenz: "mission-board-geschaeftsordnung.yaml" - - - id: "VB" - name: "Vision Board" - beschreibung: "Strategische Gesamtsteuerung DIGIT" - referenz: "vision-board-geschaeftsordnung.yaml" - - extern: - - - id: "SH" - name: "Stakeholder" - beschreibung: "Externe Kunden (Ämter, Einheiten)" - hinweis: "Wird in RACI nur bei direkter Beteiligung aufgeführt" - -# ============================================================================= -# AKTIVITÄTEN: PORTFOLIO-PFLEGE -# ============================================================================= - -aktivitaeten_portfolio_pflege: - - name: "Portfolio-Pflege" - beschreibung: | - Aktivitäten zur Pflege und Steuerung des Stakeholder-Portfolios. - - referenz: "shm_stakeholder-portfolio.yaml" - - aktivitaeten: - - - id: "PF-01" - name: "Amts-Steckbrief erstellen" - beschreibung: "Initiale Erfassung eines neuen Stakeholders" - phase: "Onboarding" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "C" - - - id: "PF-02" - name: "Amts-Steckbrief aktualisieren" - beschreibung: "Laufende Pflege der Stakeholder-Daten" - phase: "Betrieb" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "C" - - - id: "PF-03" - name: "Stakeholder segmentieren" - beschreibung: "Zuordnung zu Funktions- und IT-Profil-Dimension" - phase: "Onboarding / Review" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "C" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "PF-04" - name: "Stakeholder priorisieren" - beschreibung: "Bewertung nach Einfluss/Abhängigkeit/Relevanz" - phase: "Onboarding / Review" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "-" - - - id: "PF-05" - name: "Betreuungsmodus festlegen" - beschreibung: "Ableitung des Betreuungsmodus aus Priorisierung" - phase: "Onboarding / Review" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "PF-06" - name: "Betreuungsmodus anpassen" - beschreibung: "Änderung bei veränderter Situation" - phase: "Betrieb" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "PF-07" - name: "Betreuungszuordnung festlegen" - beschreibung: "Zuweisung Stakeholder zu Stakeholder-Manager:in" - phase: "Onboarding / Reorganisation" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "PF-08" - name: "Neuen Stakeholder ins Portfolio aufnehmen" - beschreibung: "Formale Aufnahme einer neuen Organisationseinheit" - phase: "Onboarding" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "PF-09" - name: "Portfolio-Priorisierung validieren" - beschreibung: "Periodische Überprüfung der Priorisierungen" - phase: "E2-Review" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "-" - - - id: "PF-10" - name: "Segmentierungslogik weiterentwickeln" - beschreibung: "Strukturelle Änderungen am Segmentierungsmodell" - phase: "Strategisch" - SM: "C" - SHM-L: "R" - DPM: "C" - SPM: "C" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "C" - VB: "A" - SH: "-" - -# ============================================================================= -# AKTIVITÄTEN: BEDARFSBEWERTUNG & ROUTING -# ============================================================================= - -aktivitaeten_bedarfsbewertung: - - name: "Bedarfsbewertung & Routing" - beschreibung: | - Aktivitäten zur Bewertung von Stakeholder-Bedarfen und - Weiterleitung an die richtigen Empfänger. - - referenz: "shm_bedarfsbewertung.yaml" - - aktivitaeten: - - - id: "BR-01" - name: "Bedarf entgegennehmen" - beschreibung: "Erstaufnahme eines Stakeholder-Bedarfs" - phase: "Erfassung" - SM: "A/R" - SHM-L: "-" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - - - id: "BR-02" - name: "Bedarfsklärungsgespräch führen" - beschreibung: "Vertiefende Klärung bei komplexen Bedarfen" - phase: "Erfassung" - SM: "A/R" - SHM-L: "-" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - hinweis: "Optional, bei Bedarf" - - - id: "BR-03" - name: "Service-Katalog-Prüfung durchführen" - beschreibung: "Prüfung, ob Bedarf durch bestehenden Service abdeckbar" - phase: "Bewertung" - SM: "A/R" - SHM-L: "-" - DPM: "-" - SPM: "C" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "BR-04" - name: "Routing-Entscheidung treffen (Regelfall)" - beschreibung: "Entscheidung über Routing-Pfad bei klaren Fällen" - phase: "Bewertung" - SM: "A/R" - SHM-L: "I" - DPM: "I (bei ROUTE-DPM)" - SPM: "I (bei ROUTE-SPM)" - SO: "-" - SD: "I (bei ROUTE-REQ)" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "BR-05" - name: "Service-Owner-Klärung einleiten" - beschreibung: "Bilaterale Klärung bei Routing-Unsicherheit mit Service Owner" - phase: "Bewertung" - SM: "R" - SHM-L: "C" - DPM: "I" - SPM: "I" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - referenz: "GOV-SHM-029" - - - id: "BR-06" - name: "Routing-Empfehlung abgeben (Grenzfall)" - beschreibung: "Service Owner gibt Routing-Empfehlung ab bei unklaren Fällen (bilateral); formelle Bestätigung: SOR (Change); Demand direkt an DPM" - phase: "Bewertung" - SM: "R" - SHM-L: "I" - DPM: "C" - SPM: "C/R" - SO: "R" - SD: "-" - DSR: "-" # Demand-Routing entfällt (direkt an DPM) - SOR: "A (bei Changes)" - MB: "-" - VB: "-" - SH: "-" - referenz: "GOV-SHM-029" - hinweis: "SO gibt Empfehlung ab, SOR/DSR bestätigen formal. Weiterbearbeitung erfolgt 'als ob' bereits entschieden." - - - id: "BR-07" - name: "Bedarfssteckbrief erstellen" - beschreibung: "Dokumentation des Bedarfs für Übergabe" - phase: "Dokumentation" - SM: "A/R" - SHM-L: "-" - DPM: "C (bei Rückfragen)" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "C" - - - id: "BR-08" - name: "User Stories erheben" - beschreibung: "Strukturierte Erfassung von Anforderungen" - phase: "Dokumentation" - SM: "A/R" - SHM-L: "-" - DPM: "C" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - referenz: "leitfaden_user-stories.yaml" - - - id: "BR-09" - name: "Stakeholder-Freigabe einholen" - beschreibung: "Formale Freigabe für Demand-Übergabe" - phase: "Dokumentation" - SM: "R" - SHM-L: "-" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "A" - hinweis: "Nur bei ROUTE-DPM erforderlich" - - - id: "BR-10" - name: "Bedarf an Service Desk weiterleiten" - beschreibung: "Übergabe bei ROUTE-REQ" - phase: "Übergabe" - SM: "A/R" - SHM-L: "-" - DPM: "-" - SPM: "-" - SO: "-" - SD: "I" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "I" - - - id: "BR-11" - name: "Bedarf an SPM/SO weiterleiten" - beschreibung: "Übergabe bei ROUTE-SPM" - phase: "Übergabe" - SM: "R" - SHM-L: "-" - DPM: "-" - SPM: "A" - SO: "I" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "I" - - - id: "BR-12" - name: "Demand an DPM übergeben" - beschreibung: "Übergabe bei ROUTE-DPM" - phase: "Übergabe" - SM: "R" - SHM-L: "I" - DPM: "A" - SPM: "-" - SO: "-" - SD: "-" - DSR: "I" - SOR: "-" - MB: "-" - VB: "-" - SH: "I" - -# ============================================================================= -# AKTIVITÄTEN: STAKEHOLDER-INTERAKTION -# ============================================================================= - -aktivitaeten_stakeholder_interaktion: - - name: "Stakeholder-Interaktion" - beschreibung: | - Aktivitäten zur direkten Interaktion mit Stakeholdern - (proaktiv und reaktiv). - - referenz: "shm_engagement-framework.yaml" - - aktivitaeten: - - # ------------------------------------------------------------------------- - # PROAKTIVE FORMATE - # ------------------------------------------------------------------------- - - - id: "SI-01" - name: "Turnus-Gespräch durchführen" - beschreibung: "Regelmäßiger Austausch mit Stakeholder" - phase: "Betrieb" - format: "Proaktiv" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - - - id: "SI-02" - name: "Turnus-Gespräch dokumentieren" - beschreibung: "Protokollierung und Nachverfolgung" - phase: "Betrieb" - format: "Proaktiv" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "SI-03" - name: "Status-Update geben" - beschreibung: "Proaktive Information über laufende Themen" - phase: "Betrieb" - format: "Proaktiv" - SM: "A/R" - SHM-L: "-" - DPM: "C (bei Demand-Status)" - SPM: "C (bei Service-Status)" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "I" - - - id: "SI-04" - name: "Strategisches Orientierungsgespräch führen" - beschreibung: "Jährliches Gespräch mit Key-Stakeholdern" - phase: "Betrieb" - format: "Proaktiv" - SM: "R" - SHM-L: "A/R" - DPM: "C" - SPM: "C" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "R" - hinweis: "Nur für Key-Stakeholder" - - # ------------------------------------------------------------------------- - # REAKTIVE FORMATE - # ------------------------------------------------------------------------- - - - id: "SI-05" - name: "Ad-hoc-Anfrage bearbeiten" - beschreibung: "Reaktion auf ungeplante Stakeholder-Anfragen" - phase: "Betrieb" - format: "Reaktiv" - SM: "A/R" - SHM-L: "-" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - - - id: "SI-06" - name: "Beschwerde entgegennehmen" - beschreibung: "Aufnahme und Erstbewertung einer Beschwerde" - phase: "Eskalation" - format: "Reaktiv" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - - - id: "SI-07" - name: "Beschwerde eskalieren" - beschreibung: "Weiterleitung bei nicht lösbaren Beschwerden" - phase: "Eskalation" - format: "Reaktiv" - SM: "R" - SHM-L: "A" - DPM: "I (bei DPM-Bezug)" - SPM: "I (bei SPM-Bezug)" - SO: "I (bei Service-Bezug)" - SD: "-" - DSR: "-" - SOR: "I (bei SOR-Themen)" - MB: "I (bei strategischer Relevanz)" - VB: "-" - SH: "I" - - - id: "SI-08" - name: "Demand-Ablehnung kommunizieren" - beschreibung: "Vermittlung und Erklärung bei abgelehnten Demands" - phase: "Kommunikation" - format: "Reaktiv" - SM: "A/R" - SHM-L: "C (bei Key/Aktiv)" - DPM: "C" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "I" - - # ------------------------------------------------------------------------- - # KOLLEKTIVE FORMATE - # ------------------------------------------------------------------------- - - - id: "SI-09" - name: "Kundenforum vorbereiten" - beschreibung: "Inhaltliche und organisatorische Vorbereitung" - phase: "Kollektiv" - format: "Kollektiv" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "R" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "SI-10" - name: "Kundenforum durchführen" - beschreibung: "Moderation und Durchführung" - phase: "Kollektiv" - format: "Kollektiv" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "R" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "R" - - - id: "SI-11" - name: "Kundenforum nachbereiten" - beschreibung: "Dokumentation und Follow-up" - phase: "Kollektiv" - format: "Kollektiv" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "R" - SO: "I" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "I" - -# ============================================================================= -# AKTIVITÄTEN: GREMIENARBEIT -# ============================================================================= - -aktivitaeten_gremienarbeit: - - name: "Gremienarbeit" - beschreibung: | - Aktivitäten in den DIGIT-Gremien (DSR, SOR, MB, VB). - - referenz: "shm_d2p-integration.yaml, shm_governance-framework.yaml" - - aktivitaeten: - - # ------------------------------------------------------------------------- - # DSR (DEMAND & STAKEHOLDER-RUNDE) - # ------------------------------------------------------------------------- - - - id: "GA-01" - name: "DSR-Sitzung vorbereiten (SHM-Anteil)" - beschreibung: "Vorbereitung der Stakeholder-Perspektive" - gremium: "DSR" - SM: "A/R" - SHM-L: "-" - DPM: "R" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "GA-02" - name: "DSR-Sitzung teilnehmen (Kundenanwalt)" - beschreibung: "Vertretung der Stakeholder-Perspektive" - gremium: "DSR" - SM: "R" - SHM-L: "-" - DPM: "R" - SPM: "-" - SO: "-" - SD: "-" - DSR: "A" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "GA-03" - name: "Stakeholder-Kontext zu Demand einbringen" - beschreibung: "Information über Stakeholder-Situation" - gremium: "DSR" - SM: "A/R" - SHM-L: "-" - DPM: "I" - SPM: "-" - SO: "-" - SD: "-" - DSR: "I" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "GA-04" - name: "Einwand bei Demand-Entscheidung erheben" - beschreibung: "Formaler Einwand aus Stakeholder-Perspektive" - gremium: "DSR" - SM: "A/R" - SHM-L: "I" - DPM: "I" - SPM: "-" - SO: "-" - SD: "-" - DSR: "I" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - # ------------------------------------------------------------------------- - # SOR (SERVICE OPERATIONS RUNDE) - # ------------------------------------------------------------------------- - - - id: "GA-05" - name: "Service-Owner-Klärung durchführen" - beschreibung: "Bilaterale Klärung zur Abgabe von Routing-Empfehlung bei Routing-Grenzfällen; formelle Bestätigung durch SOR/DSR folgt" - gremium: "Bilateral SHM-SO" - SM: "R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "R" - SD: "-" - DSR: "A (Empfehlung Demand)" - SOR: "A (Empfehlung Change)" - MB: "-" - VB: "-" - SH: "-" - hinweis: "Bei Routing-Unsicherheit (ROUTE-SO); SO gibt Empfehlung ab, SOR/DSR bestätigen formal im nächsten Takt. Weiterbearbeitung erfolgt 'als ob' bereits entschieden." - referenz: "GOV-SHM-029" - - - id: "GA-06" - name: "Service-Owner-Klärung einleiten" - beschreibung: "Bilaterale Klärung mit Service Owner einleiten zur Abgabe von Routing-Empfehlung" - gremium: "Bilateral" - SM: "A/R" - SHM-L: "I" - DPM: "C" - SPM: "C" - SO: "R" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - hinweis: "SO gibt Empfehlung ab; formelle Bestätigung durch SOR (Changes) oder DSR (Demands) folgt im nächsten Takt" - referenz: "GOV-SHM-029" - - # ------------------------------------------------------------------------- - # MISSION BOARD - # ------------------------------------------------------------------------- - - - id: "GA-07" - name: "MB-Sitzung vorbereiten (SHM-Anteil)" - beschreibung: "Vorbereitung der Stakeholder-Perspektive" - gremium: "MB" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "GA-08" - name: "MB-Sitzung teilnehmen" - beschreibung: "Vollwertige Teilnahme als MB-Mitglied" - gremium: "MB" - SM: "-" - SHM-L: "R" - DPM: "R" - SPM: "R" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "A" - VB: "-" - SH: "-" - - - id: "GA-09" - name: "Stakeholder-Auswirkungen bewerten" - beschreibung: "Einschätzung von Entscheidungsauswirkungen" - gremium: "MB" - SM: "C" - SHM-L: "A/R" - DPM: "I" - SPM: "I" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "-" - - # ------------------------------------------------------------------------- - # VISION BOARD - # ------------------------------------------------------------------------- - - - id: "GA-10" - name: "VB-Eskalation vorbereiten" - beschreibung: "Vorbereitung bei strategischer Eskalation" - gremium: "VB" - SM: "C" - SHM-L: "R" - DPM: "C" - SPM: "C" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "A" - VB: "I" - SH: "-" - - - id: "GA-11" - name: "VB-Jahresbericht vorstellen" - beschreibung: "Präsentation des E1-Berichts" - gremium: "VB" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "I" - SH: "-" - -# ============================================================================= -# AKTIVITÄTEN: REVIEW & REPORTING -# ============================================================================= - -aktivitaeten_review_reporting: - - name: "Review & Reporting" - beschreibung: | - Aktivitäten zur internen Steuerung und zum Reporting. - - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - - aktivitaeten: - - # ------------------------------------------------------------------------- - # E3: OPERATIVE KOORDINATION - # ------------------------------------------------------------------------- - - - id: "RR-01" - name: "E3-Team-Sync vorbereiten" - beschreibung: "Sammlung von Themen und Highlights" - ebene: "E3" - frequenz: "2-wöchentlich bis monatlich" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "RR-02" - name: "E3-Team-Sync durchführen" - beschreibung: "Moderation und Durchführung" - ebene: "E3" - frequenz: "2-wöchentlich bis monatlich" - SM: "R" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "RR-03" - name: "E3-Team-Sync dokumentieren" - beschreibung: "Protokoll und Follow-up" - ebene: "E3" - frequenz: "2-wöchentlich bis monatlich" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - referenz: "template_team-sync-protokoll.md" - - # ------------------------------------------------------------------------- - # E2: QUARTALS-REVIEW - # ------------------------------------------------------------------------- - - - id: "RR-04" - name: "E2-Quartals-Review vorbereiten" - beschreibung: "Datensammlung und Analyse" - ebene: "E2" - frequenz: "Quartalsweise" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "RR-05" - name: "E2-Quartals-Review durchführen" - beschreibung: "Review-Sitzung mit Team" - ebene: "E2" - frequenz: "Quartalsweise" - SM: "R" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "RR-06" - name: "E2-Quartalsbericht erstellen" - beschreibung: "Dokumentation der Review-Ergebnisse" - ebene: "E2" - frequenz: "Quartalsweise" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I (bei Relevanz)" - VB: "-" - SH: "-" - referenz: "template_shm-quartalsbericht.md" - - - id: "RR-07" - name: "E2-Erweitert durchführen (Q2/Q4)" - beschreibung: "Retrospektive und Verbesserungsplanung" - ebene: "E2" - frequenz: "Halbjährlich" - SM: "R" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - # ------------------------------------------------------------------------- - # E1: JAHRES-REVIEW - # ------------------------------------------------------------------------- - - - id: "RR-08" - name: "E1-Jahresbericht vorbereiten" - beschreibung: "Datensammlung und Analyse" - ebene: "E1" - frequenz: "Jährlich" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "RR-09" - name: "E1-Jahresbericht erstellen" - beschreibung: "Erstellung des SHM-Jahresberichts" - ebene: "E1" - frequenz: "Jährlich" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "I" - SH: "-" - referenz: "template_shm-jahresbericht.md" - - - id: "RR-10" - name: "E1-Halbjahres-Pulse erstellen" - beschreibung: "Kurzform-Update zur Jahresmitte" - ebene: "E1" - frequenz: "Halbjährlich (Q2)" - SM: "C" - SHM-L: "A/R" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "I" - SH: "-" - - # ------------------------------------------------------------------------- - # ÜBERGREIFENDE DIGIT-REVIEWS - # ------------------------------------------------------------------------- - - - id: "RR-11" - name: "DPM-Portfolio-Review Input liefern" - beschreibung: "SHM-Perspektive für Quartals-Review" - ebene: "Übergreifend" - frequenz: "Quartalsweise" - SM: "R" - SHM-L: "A/R" - DPM: "A" - SPM: "R" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - -# ============================================================================= -# AKTIVITÄTEN: QUALITÄTSSICHERUNG -# ============================================================================= - -aktivitaeten_qualitaetssicherung: - - name: "Qualitätssicherung" - beschreibung: | - Aktivitäten zur Sicherstellung der SHM-Qualität und - kontinuierlichen Verbesserung. - - referenz: "shm_voice-of-customer.yaml, shm_rollen.yaml" - - aktivitaeten: - - # ------------------------------------------------------------------------- - # VOC (VOICE OF CUSTOMER) - # ------------------------------------------------------------------------- - - - id: "QS-01" - name: "Beziehungsqualität bewerten" - beschreibung: "Bewertung der Beziehung zu einzelnem Stakeholder" - bereich: "VoC" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-02" - name: "VoC-Highlight dokumentieren" - beschreibung: "Erfassung relevanter Stakeholder-Äußerungen" - bereich: "VoC" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "I (bei D2)" - SO: "I (bei D2)" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-03" - name: "VoC-Cluster-Status bewerten" - beschreibung: "Aggregierte Bewertung pro VoC-Cluster" - bereich: "VoC" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-04" - name: "VoC-Feedback an SPM weiterleiten" - beschreibung: "Weiterleitung von D2-Feedback (Service-Qualität)" - bereich: "VoC" - SM: "A/R" - SHM-L: "I" - DPM: "-" - SPM: "I" - SO: "I" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-05" - name: "Maßnahmen bei VoC-Cluster-Rot initiieren" - beschreibung: "Intervention bei kritischem Cluster-Status" - bereich: "VoC" - SM: "R" - SHM-L: "A" - DPM: "C (bei Demand-Bezug)" - SPM: "C (bei Service-Bezug)" - SO: "C" - SD: "-" - DSR: "-" - SOR: "-" - MB: "I" - VB: "-" - SH: "-" - - # ------------------------------------------------------------------------- - # METHODISCHE QUALITÄT - # ------------------------------------------------------------------------- - - - id: "QS-06" - name: "Bedarfssteckbrief-Qualität prüfen" - beschreibung: "Validierung vor Übergabe" - bereich: "Methodik" - SM: "A/R" - SHM-L: "-" - DPM: "C (bei Rückfragen)" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-07" - name: "Turnus-Gespräch-Qualität sichern" - beschreibung: "Prüfung auf methodische Standards" - bereich: "Methodik" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-08" - name: "Eskalationen nachverfolgen" - beschreibung: "Tracking kritischer Fälle, Muster erkennen" - bereich: "Methodik" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - # ------------------------------------------------------------------------- - # VERBESSERUNG - # ------------------------------------------------------------------------- - - - id: "QS-09" - name: "Verbesserungsmaßnahmen planen" - beschreibung: "Ableitung von Maßnahmen aus E2-Erweitert" - bereich: "Verbesserung" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-10" - name: "Verbesserungsmaßnahmen umsetzen" - beschreibung: "Umsetzung geplanter Verbesserungen" - bereich: "Verbesserung" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - - - id: "QS-11" - name: "Verbesserungsmaßnahmen evaluieren" - beschreibung: "Bewertung der Wirksamkeit" - bereich: "Verbesserung" - SM: "R" - SHM-L: "A" - DPM: "-" - SPM: "-" - SO: "-" - SD: "-" - DSR: "-" - SOR: "-" - MB: "-" - VB: "-" - SH: "-" - -# ============================================================================= -# ZUSAMMENFASSUNG: ACCOUNTABLE-ZUORDNUNG -# ============================================================================= - -accountable_zusammenfassung: - - beschreibung: | - Übersicht über die Accountable-Zuordnung nach Bereichen. - Diese Kurzreferenz dient der schnellen Orientierung. - - bereiche: - - - bereich: "Portfolio-Pflege (operative Aktivitäten)" - accountable: "Stakeholder-Manager:in" - begruendung: "GP1: Fachexpertise = Verantwortung" - ausnahmen: "Strategische Änderungen → SHM-L / VB" - - - bereich: "Portfolio-Pflege (taktische Steuerung)" - accountable: "Leitung SHM" - begruendung: "Priorisierung, Zuordnung, Modi-Änderungen" - - - bereich: "Bedarfsbewertung (Regelfall)" - accountable: "Stakeholder-Manager:in" - begruendung: "GP1: Fachexpertise = Verantwortung" - - - bereich: "Bedarfsbewertung (Grenzfall)" - accountable: "SOR" - begruendung: "GP2: Governance-Gate bei Unsicherheit" - - - bereich: "Stakeholder-Interaktion (individuell)" - accountable: "Stakeholder-Manager:in" - begruendung: "Operative Kundenbetreuung" - - - bereich: "Stakeholder-Interaktion (kollektiv)" - accountable: "Leitung SHM" - begruendung: "Kundenforum-Gesamtverantwortung" - - - bereich: "Gremienarbeit DSR" - accountable: "DSR (als Gremium)" - begruendung: "SM bringt Perspektive ein, DSR entscheidet" - - - bereich: "Gremienarbeit MB" - accountable: "MB (als Gremium)" - begruendung: "SHM-L ist Mitglied, MB entscheidet" - - - bereich: "Review E1/E2" - accountable: "Leitung SHM" - begruendung: "Abteilungsverantwortung für Reporting" - - - bereich: "Review E3" - accountable: "Leitung SHM" - begruendung: "Team-Koordination" - - - bereich: "Qualitätssicherung VoC" - accountable: "Leitung SHM" - begruendung: "Aggregation und strategische Ableitung" - - - bereich: "Qualitätssicherung Methodik" - accountable: "Leitung SHM" - begruendung: "Methodische Standards sichern" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-RACI-001" - thema: "RACI-Validierung mit DIGIT" - beschreibung: | - Die RACI-Matrix muss mit DIGIT validiert werden, insbesondere - die Schnittstellen-Aktivitäten und Gremienrollen. - prioritaet: "hoch" - status: "Mit DIGIT zu klären" - - - id: "OPEN-RACI-002" - thema: "Service-Steckbrief-QS operationalisieren" - beschreibung: | - Die SHM-Einbindung bei Service-Steckbrief-Prüfung (QS-05 in SCM) - ist im MVP optional. Muss nach SHM-Operationalisierung aktiviert werden. - prioritaet: "mittel" - status: "Abhängig von SHM-Operationalisierung" - referenz: "SPM GOV-009" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: | - Initiale Erstellung der SHM-RACI-Matrix. - - 6 Aktivitätsbereiche definiert - - 54 Aktivitäten dokumentiert - - Governance-Prinzipien GP1/GP2/GP3 angewendet +# ======================================== +# RACI-Matrix Stakeholder-Management +# ======================================== +# Version: 0.1 (Platzhalter) +# Datum: 2024-12-03 +# Status: Ausstehend +# Entwicklungsphase: 9 +# ======================================== + +# ITIL4-Referenz (falls zutreffend): +# itil4_referenz: +# practice: "" +# relevante_elemente: [] +# adaption_fuer_digitom: "" + +# ======================================== +# INHALT +# ======================================== + +# [Inhalt folgt in Phase 9] +# ============================================================================= +# SHM RACI-MATRIX +# ============================================================================= +# Version: 1.0 +# Datum: 2025-12-10 +# Status: Entwurf +# Quelle: Ableitung aus SHM-Konzepten und Governance-Framework +# ============================================================================= + +meta: + typ: "raci_matrix" + scope: "Stakeholder Management" + version: "1.0" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Stakeholder-Management" + + status: + inhaltlich_abgenommen_durch: "[DIGIT-Leitung]" + status: "entwurf" + + kontext_tags: + - "verantwortlichkeiten" + - "raci" + - "stakeholder-management" + - "governance" + + zweck: | + Diese RACI-Matrix definiert die Verantwortlichkeiten für alle + SHM-Aktivitäten. Sie operationalisiert das Governance-Framework + (shm_governance-framework.yaml) auf Aktivitätsebene. + + abgrenzung: | + - Das Governance-Framework definiert Entscheidungslogik und -gegenstände + - Diese RACI definiert operative Verantwortlichkeiten pro Aktivität + - Die Rollenbeschreibungen (shm_rollen.yaml) definieren Aufgabenprofile + + Bei Konflikten gilt: Governance-Framework > RACI > Rollenbeschreibungen + +# ============================================================================= +# GOVERNANCE-PRINZIPIEN +# ============================================================================= + +governance_prinzipien: + + beschreibung: | + Analog zu DPM nutzt SHM einen differenzierten RACI-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" + anwendung_shm: + - "Routing-Entscheidung im Regelfall" + - "Bedarfssteckbrief-Erstellung" + - "Turnus-Gespräch durchführen" + - "Beziehungsqualität bewerten" + + - id: "GP2" + name: "Governance-Gates" + regel: "A ≠ R getrennt" + beschreibung: | + Bei Kontrollpunkten und Gremienentscheidungen wird + Ausführung und Verantwortung bewusst getrennt. + begruendung: "Vier-Augen-Prinzip, Checks & Balances" + anwendung_shm: + - "Routing-Entscheidung bei Grenzfällen (SM bereitet vor, SOR entscheidet)" + - "Demand-Annahme (SO routet direkt an DPM, kein DSR-Weg)" + - "Portfolio-Priorisierung validieren (SM bewertet, SHM-L validiert)" + + - id: "GP3" + name: "Klare Übergänge" + regel: "A ≠ R an Schnittstellen" + beschreibung: | + Bei Übergaben zwischen Funktionen erfolgt explizite + Verantwortungsübergabe. + begruendung: "Eindeutige Verantwortungswechsel, Vermeidung von Lücken" + anwendung_shm: + - "Bedarf an DPM übergeben" + - "Change an SPM/SO übergeben" + - "VoC-Feedback an SPM weiterleiten" + +# ============================================================================= +# 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" + regel: "Genau ein A pro Aktivität" + + C: + name: "Consulted" + beschreibung: "Wird vor der Entscheidung/Ausführung konsultiert, gibt fachlichen Input" + + I: + name: "Informed" + beschreibung: "Wird über das Ergebnis informiert" + + "-": + name: "Nicht beteiligt" + beschreibung: "Keine Rolle bei dieser Aktivität" + + kombinationen: + "A/R": "Accountable und Responsible in einer Rolle (GP1)" + "(A)": "Eskalationsinstanz bei Konflikten" + +# ============================================================================= +# ROLLEN +# ============================================================================= + +rollen: + + shm_intern: + + - id: "SM" + name: "Stakeholder-Manager:in" + beschreibung: "Operative Betreuung der zugeordneten Stakeholder" + referenz: "shm_rollen.yaml → stakeholder_manager" + + - id: "SHM-L" + name: "Leitung Stakeholder Management" + beschreibung: "Abteilungsleitung, strategische Steuerung" + referenz: "shm_rollen.yaml → leitung_shm" + + digit_intern: + + - id: "DPM" + name: "Demand-Portfolio-Manager:in" + beschreibung: "Steuerung des Demand-Portfolios" + referenz: "dpm_rollen.yaml" + + - id: "SPM" + name: "Service-Portfolio-Manager" + beschreibung: "Steuerung des Service-Portfolios" + referenz: "spm_rollen.yaml" + + - id: "SO" + name: "Service Owner" + beschreibung: "Fachliche Verantwortung für einen Service" + referenz: "spm_rollen.yaml" + + - id: "SD" + name: "Service Desk" + beschreibung: "First Level Support, Request-Annahme" + referenz: "ssm_rollen.yaml" + + gremien: + + - id: "DSR" + name: "Demand & Stakeholder-Runde" + beschreibung: "Operative Demand-Entscheidungen" + referenz: "dsr-geschaeftsordnung.yaml" + + - id: "SOR" + name: "Service Operations Runde" + beschreibung: "Service-bezogene Entscheidungen, Routing-Klärung" + referenz: "sor-geschaeftsordnung.yaml" + + - id: "MB" + name: "Mission Board" + beschreibung: "Strategisch-taktische Steuerung" + referenz: "mission-board-geschaeftsordnung.yaml" + + - id: "VB" + name: "Vision Board" + beschreibung: "Strategische Gesamtsteuerung DIGIT" + referenz: "vision-board-geschaeftsordnung.yaml" + + extern: + + - id: "SH" + name: "Stakeholder" + beschreibung: "Externe Kunden (Ämter, Einheiten)" + hinweis: "Wird in RACI nur bei direkter Beteiligung aufgeführt" + +# ============================================================================= +# AKTIVITÄTEN: PORTFOLIO-PFLEGE +# ============================================================================= + +aktivitaeten_portfolio_pflege: + + name: "Portfolio-Pflege" + beschreibung: | + Aktivitäten zur Pflege und Steuerung des Stakeholder-Portfolios. + + referenz: "shm_stakeholder-portfolio.yaml" + + aktivitaeten: + + - id: "PF-01" + name: "Amts-Steckbrief erstellen" + beschreibung: "Initiale Erfassung eines neuen Stakeholders" + phase: "Onboarding" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "C" + + - id: "PF-02" + name: "Amts-Steckbrief aktualisieren" + beschreibung: "Laufende Pflege der Stakeholder-Daten" + phase: "Betrieb" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "C" + + - id: "PF-03" + name: "Stakeholder segmentieren" + beschreibung: "Zuordnung zu Funktions- und IT-Profil-Dimension" + phase: "Onboarding / Review" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "C" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "PF-04" + name: "Stakeholder priorisieren" + beschreibung: "Bewertung nach Einfluss/Abhängigkeit/Relevanz" + phase: "Onboarding / Review" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "-" + + - id: "PF-05" + name: "Betreuungsmodus festlegen" + beschreibung: "Ableitung des Betreuungsmodus aus Priorisierung" + phase: "Onboarding / Review" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "PF-06" + name: "Betreuungsmodus anpassen" + beschreibung: "Änderung bei veränderter Situation" + phase: "Betrieb" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "PF-07" + name: "Betreuungszuordnung festlegen" + beschreibung: "Zuweisung Stakeholder zu Stakeholder-Manager:in" + phase: "Onboarding / Reorganisation" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "PF-08" + name: "Neuen Stakeholder ins Portfolio aufnehmen" + beschreibung: "Formale Aufnahme einer neuen Organisationseinheit" + phase: "Onboarding" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "PF-09" + name: "Portfolio-Priorisierung validieren" + beschreibung: "Periodische Überprüfung der Priorisierungen" + phase: "E2-Review" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "-" + + - id: "PF-10" + name: "Segmentierungslogik weiterentwickeln" + beschreibung: "Strukturelle Änderungen am Segmentierungsmodell" + phase: "Strategisch" + SM: "C" + SHM-L: "R" + DPM: "C" + SPM: "C" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "C" + VB: "A" + SH: "-" + +# ============================================================================= +# AKTIVITÄTEN: BEDARFSBEWERTUNG & ROUTING +# ============================================================================= + +aktivitaeten_bedarfsbewertung: + + name: "Bedarfsbewertung & Routing" + beschreibung: | + Aktivitäten zur Bewertung von Stakeholder-Bedarfen und + Weiterleitung an die richtigen Empfänger. + + referenz: "shm_bedarfsbewertung.yaml" + + aktivitaeten: + + - id: "BR-01" + name: "Bedarf entgegennehmen" + beschreibung: "Erstaufnahme eines Stakeholder-Bedarfs" + phase: "Erfassung" + SM: "A/R" + SHM-L: "-" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + + - id: "BR-02" + name: "Bedarfsklärungsgespräch führen" + beschreibung: "Vertiefende Klärung bei komplexen Bedarfen" + phase: "Erfassung" + SM: "A/R" + SHM-L: "-" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + hinweis: "Optional, bei Bedarf" + + - id: "BR-03" + name: "Service-Katalog-Prüfung durchführen" + beschreibung: "Prüfung, ob Bedarf durch bestehenden Service abdeckbar" + phase: "Bewertung" + SM: "A/R" + SHM-L: "-" + DPM: "-" + SPM: "C" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "BR-04" + name: "Routing-Entscheidung treffen (Regelfall)" + beschreibung: "Entscheidung über Routing-Pfad bei klaren Fällen" + phase: "Bewertung" + SM: "A/R" + SHM-L: "I" + DPM: "I (bei ROUTE-DPM)" + SPM: "I (bei ROUTE-SPM)" + SO: "-" + SD: "I (bei ROUTE-REQ)" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "BR-05" + name: "Service-Owner-Klärung einleiten" + beschreibung: "Bilaterale Klärung bei Routing-Unsicherheit mit Service Owner" + phase: "Bewertung" + SM: "R" + SHM-L: "C" + DPM: "I" + SPM: "I" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + referenz: "GOV-SHM-029" + + - id: "BR-06" + name: "Routing-Empfehlung abgeben (Grenzfall)" + beschreibung: "Service Owner gibt Routing-Empfehlung ab bei unklaren Fällen (bilateral); formelle Bestätigung: SOR (Change); Demand direkt an DPM" + phase: "Bewertung" + SM: "R" + SHM-L: "I" + DPM: "C" + SPM: "C/R" + SO: "R" + SD: "-" + DSR: "-" # Demand-Routing entfällt (direkt an DPM) + SOR: "A (bei Changes)" + MB: "-" + VB: "-" + SH: "-" + referenz: "GOV-SHM-029" + hinweis: "SO gibt Empfehlung ab, SOR/DSR bestätigen formal. Weiterbearbeitung erfolgt 'als ob' bereits entschieden." + + - id: "BR-07" + name: "Bedarfssteckbrief erstellen" + beschreibung: "Dokumentation des Bedarfs für Übergabe" + phase: "Dokumentation" + SM: "A/R" + SHM-L: "-" + DPM: "C (bei Rückfragen)" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "C" + + - id: "BR-08" + name: "User Stories erheben" + beschreibung: "Strukturierte Erfassung von Anforderungen" + phase: "Dokumentation" + SM: "A/R" + SHM-L: "-" + DPM: "C" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + referenz: "leitfaden_user-stories.yaml" + + - id: "BR-09" + name: "Stakeholder-Freigabe einholen" + beschreibung: "Formale Freigabe für Demand-Übergabe" + phase: "Dokumentation" + SM: "R" + SHM-L: "-" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "A" + hinweis: "Nur bei ROUTE-DPM erforderlich" + + - id: "BR-10" + name: "Bedarf an Service Desk weiterleiten" + beschreibung: "Übergabe bei ROUTE-REQ" + phase: "Übergabe" + SM: "A/R" + SHM-L: "-" + DPM: "-" + SPM: "-" + SO: "-" + SD: "I" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "I" + + - id: "BR-11" + name: "Bedarf an SPM/SO weiterleiten" + beschreibung: "Übergabe bei ROUTE-SPM" + phase: "Übergabe" + SM: "R" + SHM-L: "-" + DPM: "-" + SPM: "A" + SO: "I" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "I" + + - id: "BR-12" + name: "Demand an DPM übergeben" + beschreibung: "Übergabe bei ROUTE-DPM" + phase: "Übergabe" + SM: "R" + SHM-L: "I" + DPM: "A" + SPM: "-" + SO: "-" + SD: "-" + DSR: "I" + SOR: "-" + MB: "-" + VB: "-" + SH: "I" + +# ============================================================================= +# AKTIVITÄTEN: STAKEHOLDER-INTERAKTION +# ============================================================================= + +aktivitaeten_stakeholder_interaktion: + + name: "Stakeholder-Interaktion" + beschreibung: | + Aktivitäten zur direkten Interaktion mit Stakeholdern + (proaktiv und reaktiv). + + referenz: "shm_engagement-framework.yaml" + + aktivitaeten: + + # ------------------------------------------------------------------------- + # PROAKTIVE FORMATE + # ------------------------------------------------------------------------- + + - id: "SI-01" + name: "Turnus-Gespräch durchführen" + beschreibung: "Regelmäßiger Austausch mit Stakeholder" + phase: "Betrieb" + format: "Proaktiv" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + + - id: "SI-02" + name: "Turnus-Gespräch dokumentieren" + beschreibung: "Protokollierung und Nachverfolgung" + phase: "Betrieb" + format: "Proaktiv" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "SI-03" + name: "Status-Update geben" + beschreibung: "Proaktive Information über laufende Themen" + phase: "Betrieb" + format: "Proaktiv" + SM: "A/R" + SHM-L: "-" + DPM: "C (bei Demand-Status)" + SPM: "C (bei Service-Status)" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "I" + + - id: "SI-04" + name: "Strategisches Orientierungsgespräch führen" + beschreibung: "Jährliches Gespräch mit Key-Stakeholdern" + phase: "Betrieb" + format: "Proaktiv" + SM: "R" + SHM-L: "A/R" + DPM: "C" + SPM: "C" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "R" + hinweis: "Nur für Key-Stakeholder" + + # ------------------------------------------------------------------------- + # REAKTIVE FORMATE + # ------------------------------------------------------------------------- + + - id: "SI-05" + name: "Ad-hoc-Anfrage bearbeiten" + beschreibung: "Reaktion auf ungeplante Stakeholder-Anfragen" + phase: "Betrieb" + format: "Reaktiv" + SM: "A/R" + SHM-L: "-" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + + - id: "SI-06" + name: "Beschwerde entgegennehmen" + beschreibung: "Aufnahme und Erstbewertung einer Beschwerde" + phase: "Eskalation" + format: "Reaktiv" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + + - id: "SI-07" + name: "Beschwerde eskalieren" + beschreibung: "Weiterleitung bei nicht lösbaren Beschwerden" + phase: "Eskalation" + format: "Reaktiv" + SM: "R" + SHM-L: "A" + DPM: "I (bei DPM-Bezug)" + SPM: "I (bei SPM-Bezug)" + SO: "I (bei Service-Bezug)" + SD: "-" + DSR: "-" + SOR: "I (bei SOR-Themen)" + MB: "I (bei strategischer Relevanz)" + VB: "-" + SH: "I" + + - id: "SI-08" + name: "Demand-Ablehnung kommunizieren" + beschreibung: "Vermittlung und Erklärung bei abgelehnten Demands" + phase: "Kommunikation" + format: "Reaktiv" + SM: "A/R" + SHM-L: "C (bei Key/Aktiv)" + DPM: "C" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "I" + + # ------------------------------------------------------------------------- + # KOLLEKTIVE FORMATE + # ------------------------------------------------------------------------- + + - id: "SI-09" + name: "Kundenforum vorbereiten" + beschreibung: "Inhaltliche und organisatorische Vorbereitung" + phase: "Kollektiv" + format: "Kollektiv" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "R" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "SI-10" + name: "Kundenforum durchführen" + beschreibung: "Moderation und Durchführung" + phase: "Kollektiv" + format: "Kollektiv" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "R" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "R" + + - id: "SI-11" + name: "Kundenforum nachbereiten" + beschreibung: "Dokumentation und Follow-up" + phase: "Kollektiv" + format: "Kollektiv" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "R" + SO: "I" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "I" + +# ============================================================================= +# AKTIVITÄTEN: GREMIENARBEIT +# ============================================================================= + +aktivitaeten_gremienarbeit: + + name: "Gremienarbeit" + beschreibung: | + Aktivitäten in den DIGIT-Gremien (DSR, SOR, MB, VB). + + referenz: "shm_d2p-integration.yaml, shm_governance-framework.yaml" + + aktivitaeten: + + # ------------------------------------------------------------------------- + # DSR (DEMAND & STAKEHOLDER-RUNDE) + # ------------------------------------------------------------------------- + + - id: "GA-01" + name: "DSR-Sitzung vorbereiten (SHM-Anteil)" + beschreibung: "Vorbereitung der Stakeholder-Perspektive" + gremium: "DSR" + SM: "A/R" + SHM-L: "-" + DPM: "R" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "GA-02" + name: "DSR-Sitzung teilnehmen (Kundenanwalt)" + beschreibung: "Vertretung der Stakeholder-Perspektive" + gremium: "DSR" + SM: "R" + SHM-L: "-" + DPM: "R" + SPM: "-" + SO: "-" + SD: "-" + DSR: "A" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "GA-03" + name: "Stakeholder-Kontext zu Demand einbringen" + beschreibung: "Information über Stakeholder-Situation" + gremium: "DSR" + SM: "A/R" + SHM-L: "-" + DPM: "I" + SPM: "-" + SO: "-" + SD: "-" + DSR: "I" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "GA-04" + name: "Einwand bei Demand-Entscheidung erheben" + beschreibung: "Formaler Einwand aus Stakeholder-Perspektive" + gremium: "DSR" + SM: "A/R" + SHM-L: "I" + DPM: "I" + SPM: "-" + SO: "-" + SD: "-" + DSR: "I" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + # ------------------------------------------------------------------------- + # SOR (SERVICE OPERATIONS RUNDE) + # ------------------------------------------------------------------------- + + - id: "GA-05" + name: "Service-Owner-Klärung durchführen" + beschreibung: "Bilaterale Klärung zur Abgabe von Routing-Empfehlung bei Routing-Grenzfällen; formelle Bestätigung durch SOR/DSR folgt" + gremium: "Bilateral SHM-SO" + SM: "R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "R" + SD: "-" + DSR: "A (Empfehlung Demand)" + SOR: "A (Empfehlung Change)" + MB: "-" + VB: "-" + SH: "-" + hinweis: "Bei Routing-Unsicherheit (ROUTE-SO); SO gibt Empfehlung ab, SOR/DSR bestätigen formal im nächsten Takt. Weiterbearbeitung erfolgt 'als ob' bereits entschieden." + referenz: "GOV-SHM-029" + + - id: "GA-06" + name: "Service-Owner-Klärung einleiten" + beschreibung: "Bilaterale Klärung mit Service Owner einleiten zur Abgabe von Routing-Empfehlung" + gremium: "Bilateral" + SM: "A/R" + SHM-L: "I" + DPM: "C" + SPM: "C" + SO: "R" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + hinweis: "SO gibt Empfehlung ab; formelle Bestätigung durch SOR (Changes) oder DSR (Demands) folgt im nächsten Takt" + referenz: "GOV-SHM-029" + + # ------------------------------------------------------------------------- + # MISSION BOARD + # ------------------------------------------------------------------------- + + - id: "GA-07" + name: "MB-Sitzung vorbereiten (SHM-Anteil)" + beschreibung: "Vorbereitung der Stakeholder-Perspektive" + gremium: "MB" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "GA-08" + name: "MB-Sitzung teilnehmen" + beschreibung: "Vollwertige Teilnahme als MB-Mitglied" + gremium: "MB" + SM: "-" + SHM-L: "R" + DPM: "R" + SPM: "R" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "A" + VB: "-" + SH: "-" + + - id: "GA-09" + name: "Stakeholder-Auswirkungen bewerten" + beschreibung: "Einschätzung von Entscheidungsauswirkungen" + gremium: "MB" + SM: "C" + SHM-L: "A/R" + DPM: "I" + SPM: "I" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "-" + + # ------------------------------------------------------------------------- + # VISION BOARD + # ------------------------------------------------------------------------- + + - id: "GA-10" + name: "VB-Eskalation vorbereiten" + beschreibung: "Vorbereitung bei strategischer Eskalation" + gremium: "VB" + SM: "C" + SHM-L: "R" + DPM: "C" + SPM: "C" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "A" + VB: "I" + SH: "-" + + - id: "GA-11" + name: "VB-Jahresbericht vorstellen" + beschreibung: "Präsentation des E1-Berichts" + gremium: "VB" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "I" + SH: "-" + +# ============================================================================= +# AKTIVITÄTEN: REVIEW & REPORTING +# ============================================================================= + +aktivitaeten_review_reporting: + + name: "Review & Reporting" + beschreibung: | + Aktivitäten zur internen Steuerung und zum Reporting. + + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + + aktivitaeten: + + # ------------------------------------------------------------------------- + # E3: OPERATIVE KOORDINATION + # ------------------------------------------------------------------------- + + - id: "RR-01" + name: "E3-Team-Sync vorbereiten" + beschreibung: "Sammlung von Themen und Highlights" + ebene: "E3" + frequenz: "2-wöchentlich bis monatlich" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "RR-02" + name: "E3-Team-Sync durchführen" + beschreibung: "Moderation und Durchführung" + ebene: "E3" + frequenz: "2-wöchentlich bis monatlich" + SM: "R" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "RR-03" + name: "E3-Team-Sync dokumentieren" + beschreibung: "Protokoll und Follow-up" + ebene: "E3" + frequenz: "2-wöchentlich bis monatlich" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + referenz: "template_team-sync-protokoll.md" + + # ------------------------------------------------------------------------- + # E2: QUARTALS-REVIEW + # ------------------------------------------------------------------------- + + - id: "RR-04" + name: "E2-Quartals-Review vorbereiten" + beschreibung: "Datensammlung und Analyse" + ebene: "E2" + frequenz: "Quartalsweise" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "RR-05" + name: "E2-Quartals-Review durchführen" + beschreibung: "Review-Sitzung mit Team" + ebene: "E2" + frequenz: "Quartalsweise" + SM: "R" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "RR-06" + name: "E2-Quartalsbericht erstellen" + beschreibung: "Dokumentation der Review-Ergebnisse" + ebene: "E2" + frequenz: "Quartalsweise" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I (bei Relevanz)" + VB: "-" + SH: "-" + referenz: "template_shm-quartalsbericht.md" + + - id: "RR-07" + name: "E2-Erweitert durchführen (Q2/Q4)" + beschreibung: "Retrospektive und Verbesserungsplanung" + ebene: "E2" + frequenz: "Halbjährlich" + SM: "R" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + # ------------------------------------------------------------------------- + # E1: JAHRES-REVIEW + # ------------------------------------------------------------------------- + + - id: "RR-08" + name: "E1-Jahresbericht vorbereiten" + beschreibung: "Datensammlung und Analyse" + ebene: "E1" + frequenz: "Jährlich" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "RR-09" + name: "E1-Jahresbericht erstellen" + beschreibung: "Erstellung des SHM-Jahresberichts" + ebene: "E1" + frequenz: "Jährlich" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "I" + SH: "-" + referenz: "template_shm-jahresbericht.md" + + - id: "RR-10" + name: "E1-Halbjahres-Pulse erstellen" + beschreibung: "Kurzform-Update zur Jahresmitte" + ebene: "E1" + frequenz: "Halbjährlich (Q2)" + SM: "C" + SHM-L: "A/R" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "I" + SH: "-" + + # ------------------------------------------------------------------------- + # ÜBERGREIFENDE DIGIT-REVIEWS + # ------------------------------------------------------------------------- + + - id: "RR-11" + name: "DPM-Portfolio-Review Input liefern" + beschreibung: "SHM-Perspektive für Quartals-Review" + ebene: "Übergreifend" + frequenz: "Quartalsweise" + SM: "R" + SHM-L: "A/R" + DPM: "A" + SPM: "R" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + +# ============================================================================= +# AKTIVITÄTEN: QUALITÄTSSICHERUNG +# ============================================================================= + +aktivitaeten_qualitaetssicherung: + + name: "Qualitätssicherung" + beschreibung: | + Aktivitäten zur Sicherstellung der SHM-Qualität und + kontinuierlichen Verbesserung. + + referenz: "shm_voice-of-customer.yaml, shm_rollen.yaml" + + aktivitaeten: + + # ------------------------------------------------------------------------- + # VOC (VOICE OF CUSTOMER) + # ------------------------------------------------------------------------- + + - id: "QS-01" + name: "Beziehungsqualität bewerten" + beschreibung: "Bewertung der Beziehung zu einzelnem Stakeholder" + bereich: "VoC" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-02" + name: "VoC-Highlight dokumentieren" + beschreibung: "Erfassung relevanter Stakeholder-Äußerungen" + bereich: "VoC" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "I (bei D2)" + SO: "I (bei D2)" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-03" + name: "VoC-Cluster-Status bewerten" + beschreibung: "Aggregierte Bewertung pro VoC-Cluster" + bereich: "VoC" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-04" + name: "VoC-Feedback an SPM weiterleiten" + beschreibung: "Weiterleitung von D2-Feedback (Service-Qualität)" + bereich: "VoC" + SM: "A/R" + SHM-L: "I" + DPM: "-" + SPM: "I" + SO: "I" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-05" + name: "Maßnahmen bei VoC-Cluster-Rot initiieren" + beschreibung: "Intervention bei kritischem Cluster-Status" + bereich: "VoC" + SM: "R" + SHM-L: "A" + DPM: "C (bei Demand-Bezug)" + SPM: "C (bei Service-Bezug)" + SO: "C" + SD: "-" + DSR: "-" + SOR: "-" + MB: "I" + VB: "-" + SH: "-" + + # ------------------------------------------------------------------------- + # METHODISCHE QUALITÄT + # ------------------------------------------------------------------------- + + - id: "QS-06" + name: "Bedarfssteckbrief-Qualität prüfen" + beschreibung: "Validierung vor Übergabe" + bereich: "Methodik" + SM: "A/R" + SHM-L: "-" + DPM: "C (bei Rückfragen)" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-07" + name: "Turnus-Gespräch-Qualität sichern" + beschreibung: "Prüfung auf methodische Standards" + bereich: "Methodik" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-08" + name: "Eskalationen nachverfolgen" + beschreibung: "Tracking kritischer Fälle, Muster erkennen" + bereich: "Methodik" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + # ------------------------------------------------------------------------- + # VERBESSERUNG + # ------------------------------------------------------------------------- + + - id: "QS-09" + name: "Verbesserungsmaßnahmen planen" + beschreibung: "Ableitung von Maßnahmen aus E2-Erweitert" + bereich: "Verbesserung" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-10" + name: "Verbesserungsmaßnahmen umsetzen" + beschreibung: "Umsetzung geplanter Verbesserungen" + bereich: "Verbesserung" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + + - id: "QS-11" + name: "Verbesserungsmaßnahmen evaluieren" + beschreibung: "Bewertung der Wirksamkeit" + bereich: "Verbesserung" + SM: "R" + SHM-L: "A" + DPM: "-" + SPM: "-" + SO: "-" + SD: "-" + DSR: "-" + SOR: "-" + MB: "-" + VB: "-" + SH: "-" + +# ============================================================================= +# ZUSAMMENFASSUNG: ACCOUNTABLE-ZUORDNUNG +# ============================================================================= + +accountable_zusammenfassung: + + beschreibung: | + Übersicht über die Accountable-Zuordnung nach Bereichen. + Diese Kurzreferenz dient der schnellen Orientierung. + + bereiche: + + - bereich: "Portfolio-Pflege (operative Aktivitäten)" + accountable: "Stakeholder-Manager:in" + begruendung: "GP1: Fachexpertise = Verantwortung" + ausnahmen: "Strategische Änderungen → SHM-L / VB" + + - bereich: "Portfolio-Pflege (taktische Steuerung)" + accountable: "Leitung SHM" + begruendung: "Priorisierung, Zuordnung, Modi-Änderungen" + + - bereich: "Bedarfsbewertung (Regelfall)" + accountable: "Stakeholder-Manager:in" + begruendung: "GP1: Fachexpertise = Verantwortung" + + - bereich: "Bedarfsbewertung (Grenzfall)" + accountable: "SOR" + begruendung: "GP2: Governance-Gate bei Unsicherheit" + + - bereich: "Stakeholder-Interaktion (individuell)" + accountable: "Stakeholder-Manager:in" + begruendung: "Operative Kundenbetreuung" + + - bereich: "Stakeholder-Interaktion (kollektiv)" + accountable: "Leitung SHM" + begruendung: "Kundenforum-Gesamtverantwortung" + + - bereich: "Gremienarbeit DSR" + accountable: "DSR (als Gremium)" + begruendung: "SM bringt Perspektive ein, DSR entscheidet" + + - bereich: "Gremienarbeit MB" + accountable: "MB (als Gremium)" + begruendung: "SHM-L ist Mitglied, MB entscheidet" + + - bereich: "Review E1/E2" + accountable: "Leitung SHM" + begruendung: "Abteilungsverantwortung für Reporting" + + - bereich: "Review E3" + accountable: "Leitung SHM" + begruendung: "Team-Koordination" + + - bereich: "Qualitätssicherung VoC" + accountable: "Leitung SHM" + begruendung: "Aggregation und strategische Ableitung" + + - bereich: "Qualitätssicherung Methodik" + accountable: "Leitung SHM" + begruendung: "Methodische Standards sichern" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-RACI-001" + thema: "RACI-Validierung mit DIGIT" + beschreibung: | + Die RACI-Matrix muss mit DIGIT validiert werden, insbesondere + die Schnittstellen-Aktivitäten und Gremienrollen. + prioritaet: "hoch" + status: "Mit DIGIT zu klären" + + - id: "OPEN-RACI-002" + thema: "Service-Steckbrief-QS operationalisieren" + beschreibung: | + Die SHM-Einbindung bei Service-Steckbrief-Prüfung (QS-05 in SCM) + ist im MVP optional. Muss nach SHM-Operationalisierung aktiviert werden. + prioritaet: "mittel" + status: "Abhängig von SHM-Operationalisierung" + referenz: "SPM GOV-009" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: | + Initiale Erstellung der SHM-RACI-Matrix. + - 6 Aktivitätsbereiche definiert + - 54 Aktivitäten dokumentiert + - Governance-Prinzipien GP1/GP2/GP3 angewendet - Accountable-Zusammenfassung erstellt \ No newline at end of file diff --git a/#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml b/#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml index 87d89b2..b32a286 100644 --- a/#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml +++ b/#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml @@ -1,1807 +1,1807 @@ -# ============================================================================= -# SHM ENGAGEMENT-FRAMEWORK: ARBEITSSTAND -# ============================================================================= -# Version: 0.5 (Entwurf) -# Datum: 2025-12-10 -# Status: In Entwicklung -# Kontext: Entwicklung Phase 2 -# ============================================================================= - -meta: - dokument_typ: "arbeitsstand" - modul: "shm_engagement-framework" - phase: 2 - - zweck: | - Das Engagement-Framework operationalisiert die Betreuungsmodi aus dem - Stakeholder-Portfolio. Es definiert Interaktionsformate, - Frequenzen und Reaktionslogiken für die Auftraggeber-Betreuung. - - design_prinzipien: - - prinzip: "Zweckorientierung" - beschreibung: "Jedes Format verfolgt einen definierten Zweck" - - prinzip: "Differenzierung nach Betreuungsmodus" - beschreibung: "Key-Stakeholder erhalten qualitativ andere Betreuung, nicht nur häufigere" - - prinzip: "Bidirektionaler Wertfluss" - beschreibung: "Strategische Formate liefern Input für DIGIT-Strategie" - - prinzip: "Prozessgesteuerte Eskalation" - beschreibung: "Eskalationswege sind strukturiert, nicht personengebunden" - - annahmen: - - id: "ANNAHME-EF-001" - thema: "Frequenz-Richtwerte" - beschreibung: | - Die angegebenen Frequenzen sind Empfehlungen, keine verbindlichen Vorgaben. - Die finalen Frequenzen werden im Rahmen der Pilotierung festgelegt und - müssen verprobt werden. - status: "Im Pilotierung zu validieren" - - - id: "ANNAHME-EF-002" - thema: "Cluster-basierte Kollektivformate" - beschreibung: | - Kollektive Formate werden primär nach Segmentierungs-Clustern organisiert. - Thematische Formate ergänzen dies für clusterübergreifende Bedarfe. - status: "Designentscheidung" - - - id: "ANNAHME-EF-003" - thema: "Integriertes Auftraggeber-Forum" - beschreibung: | - Die Auftraggeber-Vertretungen (SLM) und Advisory Boards (SHM) werden - zu einem integrierten Auftraggeber-Forum konsolidiert. Diese Entscheidung - reduziert Gremien-Redundanz und stärkt die gemeinsame Außenwirkung. - status: "Designentscheidung" - governance_referenz: "GOV-SHM-015" - - schnittstellen: - - schnittstelle: "DIGIT-Strategieprozess" - richtung: "SHM → Strategie" - beschreibung: | - Strategische Formate liefern Erkenntnisse zu Bedarfstrends und - Entwicklungspotenzialen, die in die DIGIT-Strategie einfließen. - status: "Strategieprozess noch nicht modelliert – Verweis auf Schnittstelle" - - - schnittstelle: "Voice-of-Customer (VoC)" - richtung: "Engagement-Framework → VoC → Koordinations- und Steuerungsstruktur" - beschreibung: | - Das Engagement-Framework liefert Inputs für das VoC-Konzept - (Beziehungsqualität, Eskalationen, Interaktionsqualität). - VoC aggregiert diese zu übergreifenden Erkenntnissen, die in die - REV-1/REV-2 Review-Zyklen einfließen. - status: "Aktiv (Phase 5 abgeschlossen)" - referenz: "shm_voice-of-customer.yaml" - -# ============================================================================= -# FUNKTIONALE HERLEITUNG -# ============================================================================= - -funktionale_herleitung: - - leitfrage: | - Welche Entscheidungen und Handlungen soll das Engagement-Framework - unterstützen? - - kernentscheidungen: - - - id: EKE-1 - name: "Interaktionsplanung" - leitfrage: "Wann interagiere ich mit wem in welchem Format?" - kontext: | - Ein Stakeholder-Manager betreut mehrere Ämter mit unterschiedlichen - Betreuungsmodi. Das Framework muss helfen, Zeitressourcen systematisch - zu allokieren – planbar, nicht ad-hoc. - unterstuetzt_durch: - - "Interaktionsformat-Katalog" - - "Frequenz-Matrix" - - - id: EKE-2 - name: "Reaktionssteuerung" - leitfrage: "Wie reagiere ich auf eingehende Anfragen, Beschwerden, Eskalationen?" - kontext: | - Nicht alle Interaktionen sind geplant. Das Framework muss Regeln liefern, - wann SHM reagiert, wann weitergeleitet wird, und wie eskaliert wird. - unterstuetzt_durch: - - "Reaktionslogik" - - "Eskalationspfade" - - - id: EKE-3 - name: "Beziehungsqualitätssicherung" - leitfrage: "Woran erkenne ich Beziehungsprobleme, wann interveniere ich?" - kontext: | - Beziehungen können erodieren ohne explizite Beschwerden. Das Framework - sollte Indikatoren und Review-Mechanismen liefern. - unterstuetzt_durch: - - "Review-Mechanismus" - - "Interventions-Trigger" - - - id: EKE-4 - name: "Strategische Wertschöpfung" - leitfrage: "Wie schaffe ich bei Key-Stakeholdern aktiven Mehrwert?" - kontext: | - Bei priorisierten Stakeholdern ist SHM nicht nur reaktiver Aufnehmer, - sondern proaktiver Berater. Das Framework muss Formate definieren, - die strategische Beratung und bidirektionalen Wertfluss ermöglichen. - unterstuetzt_durch: - - "Strategische Formate" - - "Output-Kanal Richtung DIGIT-Strategie" - -# ============================================================================= -# FORMAT-TAXONOMIE: ÜBERSICHT -# ============================================================================= - -format_taxonomie: - - beschreibung: | - Das Engagement-Framework unterscheidet fünf Format-Kategorien, die - unterschiedliche Zwecke erfüllen und sich in Planbarkeit, Teilnehmerkreis - und Interaktionstiefe unterscheiden. - - kategorien: - - - kategorie: "Turnus-Formate" - kuerzel: "TF" - charakter: "Geplant, wiederkehrend, 1:1" - primaerer_zweck: "Regelmäßiger Austausch, Beziehungspflege, Früherkennung" - betreuungsmodi: ["Key", "Aktiv"] - - - kategorie: "Strategische Formate" - kuerzel: "SF" - charakter: "Geplant, anlassbezogen, 1:1 oder Kleingruppe" - primaerer_zweck: "Aktive Digitalberatung, strategische Bedarfsentwicklung" - betreuungsmodi: ["Key"] - - - kategorie: "Kollektive Formate" - kuerzel: "KF" - charakter: "Geplant, wiederkehrend, Gruppe" - primaerer_zweck: "Effiziente Abdeckung mehrerer Stakeholder, Informationsaustausch" - betreuungsmodi: ["Standard", "Basis"] - - - kategorie: "Thematische Formate" - kuerzel: "ThF" - charakter: "Anlassbezogen, Gruppe" - primaerer_zweck: "Bedarfskonsolidierung über Cluster-Grenzen" - betreuungsmodi: ["Alle (bedarfsgetrieben)"] - - - kategorie: "Reaktive Formate" - kuerzel: "RF" - charakter: "Ungeplant, anlassbezogen" - primaerer_zweck: "Umgang mit Eskalationen, Beschwerden, Ad-hoc-Anfragen" - betreuungsmodi: ["Alle"] - -# ============================================================================= -# TURNUS-FORMATE (TF) -# ============================================================================= - -turnus_formate: - - beschreibung: | - Turnus-Formate bilden das Rückgrat der regelmäßigen Stakeholder-Betreuung. - Sie sind geplant, wiederkehrend und finden im 1:1-Setting zwischen - Stakeholder-Manager und Kundenvertreter statt. - - formate: - - # ------------------------------------------------------------------------- - # TF-01: Strategisches Turnus-Gespräch (Key) - # ------------------------------------------------------------------------- - - - id: "TF-01" - name: "Strategisches Turnus-Gespräch" - - zweck: | - Tiefgehender Austausch mit Key-Stakeholdern zu strategischen Themen, - laufenden Vorhaben und Beziehungsqualität. Geht über Statusabfrage - hinaus – aktive Beratungskomponente. - - zielgruppe: - betreuungsmodus: "Key (Proaktiv/Dediziert)" - teilnehmer_auftraggeber: "Amtsleitung oder delegierte SLA-Befugnis" - teilnehmer_shm: "Zugeordneter Stakeholder-Manager" - - frequenz: - empfehlung: "Quartalsweise" - flexibilitaet: | - Kann bei Bedarf häufiger stattfinden. Minimum: halbjährlich. - referenz_annahme: "ANNAHME-EF-001" - - typische_inhalte: - - block: "Beziehungs-Check" - beschreibung: "Wie läuft die Zusammenarbeit? Gibt es Irritationen?" - dauer_anteil: "10%" - - block: "Laufende Vorhaben" - beschreibung: "Status relevanter Projekte, Demands, Service-Themen" - dauer_anteil: "30%" - - block: "Strategischer Ausblick" - beschreibung: "Welche Themen stehen beim Amt an? Digitalisierungsbedarfe?" - dauer_anteil: "40%" - - block: "Offene Punkte / Vereinbarungen" - beschreibung: "Konkrete nächste Schritte, Verantwortlichkeiten" - dauer_anteil: "20%" - - voraussetzungen: - informationen: - - "Aktueller Projektstatus zu Vorhaben des Amtes" - - "Service-Performance-Daten (SLA-Einhaltung, offene Tickets)" - - "Offene Bedarfe und Demands im System" - vorbereitung: - - "Agenda vorab abstimmen" - - "Relevante Statusberichte sichten" - - output: - dokumentation: "Gesprächsprotokoll im SIMS (Stakeholder-Informations-Management-System)" - follow_up: "Vereinbarte Maßnahmen mit Verantwortlichkeit und Termin" - strategie_input: | - Erkenntnisse zu strategischen Bedarfstrends werden aggregiert und - fließen in DIGIT-Strategieprozess ein. - [Verweis: Strategieprozess noch nicht modelliert] - - template_bedarf: - - "Agenda-Vorlage Strategisches Turnus-Gespräch" - - "Protokoll-Vorlage" - - abgrenzung: | - Unterscheidet sich vom operativen Turnus-Gespräch (TF-02) durch - strategische Tiefe und Beratungskomponente. - - # ------------------------------------------------------------------------- - # TF-02: Operatives Turnus-Gespräch (Aktiv) - # ------------------------------------------------------------------------- - - - id: "TF-02" - name: "Operatives Turnus-Gespräch" - - zweck: | - Regelmäßiger Austausch mit Aktiv-Stakeholdern zu laufenden Themen - und Service-Zufriedenheit. Fokus auf Beziehungspflege und - Früherkennung von Problemen. - - zielgruppe: - betreuungsmodus: "Aktiv (Regelmäßig)" - teilnehmer_auftraggeber: "Amtsleitung oder operative Ansprechperson" - teilnehmer_shm: "Zugeordneter Stakeholder-Manager" - - frequenz: - empfehlung: "Halbjährlich" - flexibilitaet: | - Kann bei konkretem Anlass (laufendes Projekt, bekannte Probleme) - auf quartalsweise erhöht werden. - referenz_annahme: "ANNAHME-EF-001" - - typische_inhalte: - - block: "Zufriedenheits-Check" - beschreibung: "Wie zufrieden ist das Amt mit den IT-Services?" - dauer_anteil: "20%" - - block: "Laufende Themen" - beschreibung: "Offene Tickets, Bedarfe, bekannte Probleme" - dauer_anteil: "40%" - - block: "Ausblick" - beschreibung: "Anstehende Veränderungen beim Amt, absehbare Bedarfe" - dauer_anteil: "30%" - - block: "Vereinbarungen" - beschreibung: "Nächste Schritte, offene Punkte" - dauer_anteil: "10%" - - voraussetzungen: - informationen: - - "Offene Tickets des Amtes" - - "Bekannte Service-Probleme" - vorbereitung: - - "Kurze Agenda vorab" - - output: - dokumentation: "Kurzprotokoll im SIMS" - follow_up: "Offene Punkte mit Verantwortlichkeit" - - template_bedarf: - - "Agenda-Vorlage Operatives Turnus-Gespräch" - - abgrenzung: | - Weniger strategische Tiefe als TF-01. Fokus auf operative - Beziehungspflege, nicht auf aktive Beratung. - -# ============================================================================= -# STRATEGISCHE FORMATE (SF) -# ============================================================================= - -strategische_formate: - - beschreibung: | - Strategische Formate gehen über regelmäßige Turnus-Gespräche hinaus. - Sie dienen der aktiven Digitalberatung und strategischen - Bedarfsentwicklung bei Key-Stakeholdern. Der Wertfluss ist - bidirektional: SHM berät den Kunden, gewinnt aber auch strategische - Erkenntnisse für die DIGIT-Weiterentwicklung. - - formate: - - # ------------------------------------------------------------------------- - # SF-01: Digitalisierungs-Strategie-Workshop - # ------------------------------------------------------------------------- - - - id: "SF-01" - name: "Digitalisierungs-Strategie-Workshop" - - zweck: | - Strukturierte Erarbeitung der Digitalisierungsperspektive eines - Key-Stakeholders. Identifikation strategischer Bedarfe, Priorisierung, - Ableitung einer gemeinsamen Roadmap. - - zielgruppe: - betreuungsmodus: "Key (Proaktiv/Dediziert)" - teilnehmer_auftraggeber: | - Amtsleitung + relevante Führungskräfte/Fachexperten des Amtes - (typisch 3-6 Personen) - teilnehmer_shm: "Stakeholder-Manager, ggf. weitere DIGIT-Expertise" - - anlass: - - "Initiale Strategieerarbeitung bei neuem Key-Stakeholder" - - "Periodische Aktualisierung (z.B. alle 2 Jahre)" - - "Wesentliche Veränderung beim Amt (Reorganisation, neue Aufgaben)" - - frequenz: - empfehlung: "Anlassbezogen, typisch alle 1-2 Jahre" - hinweis: "Kein fester Turnus, aber proaktiv durch SHM angestoßen" - - typische_inhalte: - - block: "Ist-Analyse" - beschreibung: | - Aktuelle IT-Landschaft des Amtes, genutzte Services, - bekannte Schmerzpunkte - - block: "Strategische Ziele des Amtes" - beschreibung: | - Wohin entwickelt sich das Amt? Welche Aufgaben werden wichtiger/unwichtiger? - - block: "Digitalisierungspotenziale" - beschreibung: | - Wo kann Digitalisierung unterstützen? Welche Bedarfe zeichnen sich ab? - - block: "Priorisierung und Roadmap" - beschreibung: | - Gemeinsame Bewertung der Potenziale, Ableitung priorisierter - Handlungsfelder und grober Zeitrahmen - - voraussetzungen: - informationen: - - "Service-Nutzung des Amtes (aus Service-Katalog)" - - "Laufende und geplante Projekte" - - "Bekannte Bedarfe und Demands" - - "Strategische Dokumente des Amtes (falls verfügbar)" - vorbereitung: - - "Vorgespräch mit Amtsleitung zur Erwartungsklärung" - - "Analyse der Ist-Situation" - - "Workshop-Design und Methodik vorbereiten" - - output: - dokumentation: | - Ergebnisdokumentation mit: - - Identifizierte Digitalisierungsbedarfe - - Priorisierte Handlungsfelder - - Roadmap-Entwurf - follow_up: | - - Konkrete Bedarfe werden in Bedarfssteckbriefe überführt - - Roadmap wird Grundlage für Turnus-Gespräche - strategie_input: | - Aggregierte Erkenntnisse zu Bedarfstrends und Entwicklungsrichtungen - fließen in DIGIT-Strategieprozess ein. - [Verweis: Strategieprozess noch nicht modelliert] - - template_bedarf: - - "Workshop-Leitfaden Digitalisierungs-Strategie" - - "Canvas: Digitalisierungspotenziale" - - "Ergebnisdokumentation-Vorlage" - - ressourcen_hinweis: | - Ressourcenintensives Format (Vorbereitung + Durchführung: 1-2 Personentage). - Daher nur für Key-Stakeholder und anlassbezogen. - - # ------------------------------------------------------------------------- - # SF-02: Bedarfs-Vertiefungs-Workshop - # ------------------------------------------------------------------------- - - - id: "SF-02" - name: "Bedarfs-Vertiefungs-Workshop" - - zweck: | - Vertiefende Bedarfsanalyse für komplexe oder strategisch bedeutsame - Bedarfe eines Key-Stakeholders. Geht über den Bedarfssteckbrief hinaus - und erarbeitet ein fundiertes Problemverständnis. - - zielgruppe: - betreuungsmodus: "Key (Proaktiv/Dediziert)" - teilnehmer_auftraggeber: | - Amtsleitung oder delegierte Entscheider + Fachexperten für - den spezifischen Bedarf - teilnehmer_shm: "Stakeholder-Manager" - - anlass: - - "Komplexer Bedarf, der nicht im Turnus-Gespräch vollständig erfasst werden kann" - - "Strategisch bedeutsamer Bedarf mit hohem Investitionsvolumen" - - "Bedarf mit unklarem Problemkern (Symptom vs. Ursache)" - - frequenz: - empfehlung: "Anlassbezogen" - - typische_inhalte: - - block: "Problemverständnis" - beschreibung: "Was ist das eigentliche Problem? Symptome vs. Ursachen" - - block: "Kontext und Auswirkungen" - beschreibung: "Wer ist betroffen? Was sind die Konsequenzen?" - - block: "Zielbild" - beschreibung: "Wie sieht der gewünschte Zielzustand aus?" - - block: "Lösungsoptionen (grob)" - beschreibung: | - Welche Lösungsrichtungen sieht der Kunde? - (Hinweis: SHM bewertet nicht technisch, nimmt aber auf) - - block: "Nächste Schritte" - beschreibung: "Routing-Empfehlung, weitere Klärungsbedarfe" - - output: - dokumentation: "Erweiterter Bedarfssteckbrief" - follow_up: "Routing an DSR (Change vs. Demand)" - - template_bedarf: - - "Workshop-Leitfaden Bedarfs-Vertiefung" - - "Erweiterter Bedarfssteckbrief (Vorlage)" - - abgrenzung: | - Unterscheidet sich von SF-01 durch Fokus auf einen konkreten Bedarf - statt auf die Gesamtstrategie des Amtes. - -# ============================================================================= -# KOLLEKTIVE FORMATE (KF) -# ============================================================================= - -kollektive_formate: - - beschreibung: | - Kollektive Formate adressieren mehrere Stakeholder gleichzeitig. - Sie sind ressourceneffizient und ermöglichen Informationsaustausch - zwischen Ämtern. - - DESIGNENTSCHEIDUNG: Die kollektiven Formate des SHM sind mit den - Auftraggeber-Vertretungen des SLM (P-02) zu einem integrierten - "Auftraggeber-Forum"-Konzept konsolidiert. Dies vermeidet Gremien-Redundanz - und stärkt die "One DIGIT"-Wahrnehmung. - - governance_referenz: "GOV-SHM-015" - - integriertes_auftraggeber_forum: - - beschreibung: | - Das Auftraggeber-Forum ist das zentrale kollektive Interaktionsformat - zwischen DIGIT und seinen Auftraggebern. Es vereint die Funktionen der - ehemaligen SHM-Advisory-Boards und der SLM-Auftraggeber-Vertretungen. - - formate: - - # ----------------------------------------------------------------------- - # KF-01: Auftraggeber-Forum Basisservices - # ----------------------------------------------------------------------- - - - id: "KF-01" - name: "Auftraggeber-Forum Basisservices" - - zweck: | - Integriertes Forum für Ämter zur Abstimmung von Basis-Services - (Kategorie A), Informationsaustausch, Feedback-Sammlung und - Bedarfsidentifikation. Kombiniert SLA-Review-Funktion (SLM) - mit Beziehungspflege-Funktion (SHM). - - zielgruppe: - betreuungsmodus: "Standard, Basis (primär), Aktiv (optional)" - teilnehmer_auftraggeber: | - - Pflichtvertreter: Amtsleitungen strategischer Querschnittsämter - - Weitere Vertreter: Rotation/Wahl aus Fachämtern - - Alle Teilnehmer müssen Entscheidungsbefugnis haben oder - diese dokumentiert delegiert bekommen haben - teilnehmer_digit: - - rolle: "Service Owner (Basis-Services)" - verantwortung: "SLA-bezogene Themen, Service-Performance" - - rolle: "Stakeholder-Manager" - verantwortung: "Beziehungsthemen, Feedback-Moderation, Bedarfssammlung" - - rolle: "SPM (optional)" - verantwortung: "Governance-Konformität, Portfolio-Perspektive" - - frequenz: - empfehlung: "Jährlich" - hinweis: | - Die Frequenz ist im Rahmen der Pilotierung zu validieren - und zu verproben. Bei Bedarf kann auf halbjährlich erhöht werden. - referenz_annahme: "ANNAHME-EF-001" - - typische_inhalte: - - block: "SLA-Review Basis-Services" - verantwortung: "Service Owner" - beschreibung: | - Performance-Bericht, Zielerreichung, geplante Änderungen - dauer_anteil: "30%" - - block: "DIGIT-Update" - verantwortung: "Stakeholder-Manager / SPM" - beschreibung: | - Strategische Entwicklungen, neue Services, Roadmap - dauer_anteil: "20%" - - block: "Feedback-Runde" - verantwortung: "Stakeholder-Manager" - beschreibung: | - Strukturierte Sammlung: Was läuft gut? Wo gibt es Probleme? - dauer_anteil: "25%" - - block: "Bedarfs-Sammlung" - verantwortung: "Stakeholder-Manager" - beschreibung: | - Gemeinsame Bedarfe? Themen für mehrere Ämter? - dauer_anteil: "15%" - - block: "Ausblick / Vereinbarungen" - verantwortung: "Gemeinsam" - beschreibung: "Nächste Schritte, offene Punkte" - dauer_anteil: "10%" - - voraussetzungen: - informationen: - - "SLA-Performance-Daten der Basis-Services" - - "Service-Portfolio-Update" - - "Bekannte Probleme/Feedback" - vorbereitung: - - "Einladung mit Agenda mind. 4 Wochen vorher" - - "Möglichkeit zur Themenanmeldung durch Teilnehmer" - - "Abstimmung SO/SHM zur Agenda-Aufteilung" - - output: - dokumentation: "Protokoll mit SLA-Review-Ergebnis, Feedback, Bedarfen" - follow_up: - - "SLA-Änderungen werden in SLM-Prozess überführt" - - "Feedback wird an relevante Stellen weitergeleitet (SO, SPM)" - - "Gemeinsame Bedarfe werden ggf. in Thematisches Format überführt" - - governance_hinweis: | - Das Auftraggeber-Forum hat für SLA-Themen Entscheidungskompetenz - (Konsensprinzip, bei Dissens qualifizierte Mehrheit). - Für Bedarfe gilt: Beratende Funktion, Entscheidung über - etablierte Governance (SOR, DSR, MB). - - template_bedarf: - - "Einladungs-Vorlage Auftraggeber-Forum" - - "Agenda-Vorlage (integriert SLA + SHM)" - - "Protokoll-Vorlage" - - schnittstelle_slm: | - Das Auftraggeber-Forum erfüllt die Funktion der "Auftraggeber-Vertretung - Basisservices" gemäß P-02 Service Level Management. - Die SLA-Review-Aktivität (slm_09) wird im Rahmen des - Auftraggeber-Forums durchgeführt. - - # ----------------------------------------------------------------------- - # KF-02: Auftraggeber-Forum [Service] (für Kategorie B) - # ----------------------------------------------------------------------- - - - id: "KF-02" - name: "Auftraggeber-Forum [Servicename]" - - zweck: | - Service-spezifisches Forum für Nutzer eines Kategorie-B-Services. - Primär SLA-Review und Service-Roadmap, ergänzt um Bedarfssammlung. - - zielgruppe: - betreuungsmodus: "Alle nutzenden Ämter des Services" - teilnehmer_auftraggeber: | - Amtsleitungen der nutzenden Ämter oder delegierte Vertreter - mit dokumentierter Entscheidungsbefugnis - teilnehmer_digit: - - rolle: "Service Owner" - verantwortung: "Leitung, SLA-Themen, Roadmap" - - rolle: "Stakeholder-Manager (optional)" - verantwortung: "Bei Beziehungsthemen oder komplexen Bedarfen" - - frequenz: - empfehlung: "Jährlich (SLA-Review) + bei Bedarf" - referenz_annahme: "ANNAHME-EF-001" - - typische_inhalte: - - block: "SLA-Review" - beschreibung: "Performance, Zielerreichung, Anpassungsbedarf" - - block: "Service-Roadmap" - beschreibung: "Geplante Änderungen, Erweiterungen" - - block: "Bedarfssammlung" - beschreibung: "Wünsche, Anforderungen der Nutzer" - - output: - dokumentation: "Protokoll mit SLA-Review, Roadmap-Feedback, Bedarfen" - - schnittstelle_slm: | - Erfüllt die Funktion der "Auftraggeber-Vertretung [Servicename]" - gemäß P-02 Service Level Management. - - shm_beteiligung: | - SHM-Beteiligung ist optional und erfolgt bei: - - Beziehungsproblemen mit nutzenden Ämtern - - Komplexen übergreifenden Bedarfen - - Key-Stakeholdern unter den Nutzern - - # --------------------------------------------------------------------------- - # KF-03: Basis-Puls-Check (NEU) - # --------------------------------------------------------------------------- - - basis_puls_check: - - id: "KF-03" - name: "Basis-Puls-Check" - - zweck: | - Minimal-invasives proaktives Format für Basis-Stakeholder, die - keine individuelle Betreuung erhalten und ggf. nicht am Auftraggeber-Forum - teilnehmen. Verhindert "Silent Churn" – das unbemerkte Abdriften - von Stakeholdern ohne explizite Beschwerden. - - zielgruppe: - betreuungsmodus: "Basis (Reaktiv)" - adressaten: "Alle Basis-Stakeholder, die nicht am Auftraggeber-Forum teilnehmen" - - frequenz: - empfehlung: "Jährlich" - zeitpunkt: "Versetzt zum Auftraggeber-Forum (z.B. 6 Monate danach)" - referenz_annahme: "ANNAHME-EF-001" - - format: - typ: "Automatisierte Kurzumfrage / strukturiertes Mailing" - aufwand_shm: "Minimal (Versand + Auswertung)" - aufwand_kunde: "5-10 Minuten" - - inhalte: - - frage: "Allgemeine Zufriedenheit" - typ: "Skala 1-5" - beschreibung: "Wie zufrieden sind Sie insgesamt mit den IT-Services?" - - frage: "Größte Herausforderung" - typ: "Freitext (optional)" - beschreibung: "Was ist aktuell Ihre größte IT-bezogene Herausforderung?" - - frage: "Bedarfsmeldung" - typ: "Ja/Nein + Freitext" - beschreibung: "Gibt es Bedarfe, die Sie uns mitteilen möchten?" - - frage: "Gesprächswunsch" - typ: "Ja/Nein" - beschreibung: "Wünschen Sie ein persönliches Gespräch mit uns?" - - auswertung: - verantwortung: "Stakeholder-Manager" - vorgehen: - - "Aggregierte Auswertung der Zufriedenheitswerte" - - "Identifikation von Ämtern mit niedriger Zufriedenheit" - - "Priorisierung von Gesprächswünschen" - - "Sammlung und Kategorisierung von Bedarfen" - - trigger_fuer_intervention: - - bedingung: "Zufriedenheit ≤ 2" - aktion: "Proaktive Kontaktaufnahme durch SHM" - - bedingung: "Gesprächswunsch = Ja" - aktion: "Terminvereinbarung innerhalb 2 Wochen" - - bedingung: "Konkreter Bedarf genannt" - aktion: "Bedarfssteckbrief erstellen, Routing prüfen" - - output: - dokumentation: "Aggregierter Puls-Check-Bericht" - berichterstattung: "Zusammenfassung im SHM-Performance-Review" - - template_bedarf: - - "Puls-Check Fragebogen (digital)" - - "Auswertungs-Template" - - "Anschreiben-Vorlage" - - abgrenzung: | - Der Puls-Check ersetzt keine individuelle Betreuung. Er ist ein - "Frühwarnsystem" für Basis-Stakeholder und ermöglicht es, - Probleme zu erkennen, bevor sie eskalieren. - -# ============================================================================= -# THEMATISCHE FORMATE (ThF) -# ============================================================================= - -thematische_formate: - - beschreibung: | - Thematische Formate sind anlassbezogen und adressieren übergreifende - Bedarfe, die mehrere Ämter unabhängig von ihrer Cluster-Zugehörigkeit - betreffen. Sie dienen der Bedarfskonsolidierung vor DPM-Übergabe. - - formate: - - # ------------------------------------------------------------------------- - # ThF-01: Bedarfs-Konsolidierungs-Workshop - # ------------------------------------------------------------------------- - - - id: "ThF-01" - name: "Bedarfs-Konsolidierungs-Workshop" - - zweck: | - Zusammenführung von Ämtern mit ähnlichem Bedarf zur gemeinsamen - Bedarfsdefinition. Stellt Demand auf breitere Basis, erhöht - Priorisierungschancen und vermeidet Parallelentwicklungen. - - zielgruppe: - betreuungsmodus: "Alle (bedarfsgetrieben)" - teilnehmer_auftraggeber: | - Vertreter der Ämter mit gleichem/ähnlichem Bedarf. - Typisch 3-8 Teilnehmer. - teilnehmer_shm: "Stakeholder-Manager (Moderation)" - - anlass: - - "SHM erkennt gleichartigen Bedarf bei mehreren Ämtern" - - "Amt meldet Bedarf, der vermutlich auch andere betrifft" - - "Proaktive Identifikation durch Cluster-Advisory-Board" - - frequenz: - empfehlung: "Anlassbezogen" - hinweis: "Wird durch SHM initiiert, wenn Konsolidierungspotenzial erkannt wird" - - typische_inhalte: - - block: "Bedarfs-Vorstellung" - beschreibung: "Jedes Amt stellt seinen Bedarf/sein Problem vor" - - block: "Gemeinsamkeiten und Unterschiede" - beschreibung: "Was ist der gemeinsame Kern? Wo gibt es Spezifika?" - - block: "Konsolidierter Bedarf" - beschreibung: "Erarbeitung einer gemeinsamen Bedarfsbeschreibung" - - block: "Governance und nächste Schritte" - beschreibung: | - Wer vertritt den konsolidierten Bedarf? - Wie geht es weiter (SOR, DPM)? - - output: - dokumentation: "Konsolidierter Bedarfssteckbrief" - follow_up: | - - Routing an SOR mit Hinweis auf Bedarfs-Gemeinschaft - - Benennung eines Sprechers für die Bedarfs-Gemeinschaft - - template_bedarf: - - "Workshop-Leitfaden Bedarfs-Konsolidierung" - - "Bedarfssteckbrief (erweitert um Bedarfs-Gemeinschaft)" - - schnittstelle_dpm: | - Der konsolidierte Bedarf wird mit Information zur Bedarfs-Gemeinschaft - an DPM übergeben. Details zur Übergabe werden in Phase 5 - (D2P-Integration) spezifiziert. - -# ============================================================================= -# REAKTIVE FORMATE (RF) – PLACEHOLDER -# ============================================================================= - -reaktive_formate: - - beschreibung: | - Reaktive Formate regeln den Umgang mit ungeplanten Interaktionen: - Anfragen, Beschwerden, Eskalationen. Sie definieren, wann SHM - selbst reagiert, wann weitergeleitet wird, und wie eskaliert wird. - - Grundprinzip: SHM agiert als "Auftraggeber-Anwalt" – bei Key-Stakeholdern - bleibt SHM auch nach Weiterleitung aktiv involviert bis zur Lösung. - - # =========================================================================== - # TRIAGE - # =========================================================================== - - triage: - - verantwortung: "Stakeholder-Manager" - - beschreibung: | - Jede eingehende Eskalation wird durch den Stakeholder-Manager - initial kategorisiert (Triage). Die Kategorie bestimmt den - Eskalationspfad. - - ablauf: - - schritt: 1 - aktion: "Eingang erfassen" - beschreibung: "Eskalation wird dokumentiert (Absender, Thema, Dringlichkeit)" - - schritt: 2 - aktion: "Stakeholder-Priorität prüfen" - beschreibung: "Key / Aktiv / Standard / Basis – beeinflusst Pfad und Reaktionszeit" - - schritt: 3 - aktion: "Trigger-Kategorie bestimmen" - beschreibung: "Zuordnung zu Kategorie A-E" - - schritt: 4 - aktion: "Pfad einleiten" - beschreibung: "Weiterleitung oder Eigenbearbeitung gemäß Pfad-Definition" - - # =========================================================================== - # TRIGGER-KATEGORIEN - # =========================================================================== - - trigger_kategorien: - - - id: "TRIG-A" - name: "Service-bezogene Beschwerde" - beschreibung: | - Kunde ist unzufrieden mit einem konkreten Service, meldet - wiederholte Probleme oder SLA-Verletzungen. - beispiele: - - "E-Mail-System funktioniert seit Tagen nicht richtig" - - "Zugesagte Reaktionszeit wird nie eingehalten" - - "Software XY stürzt ständig ab" - primaer_zustaendig: "Service Owner" - shm_rolle: "Weiterleitung, bei Key-Stakeholdern aktive Begleitung" - - - id: "TRIG-B" - name: "Prozess-bezogene Beschwerde" - beschreibung: | - Bedarf/Demand wird nicht bearbeitet, Entscheidung ist unklar, - Prozess dauert zu lange. - beispiele: - - "Unser Demand liegt seit 6 Monaten ohne Rückmeldung" - - "Warum wurde unser Antrag abgelehnt?" - - "Niemand fühlt sich zuständig" - primaer_zustaendig: "DPM oder SPM (je nach Thema)" - shm_rolle: "Weiterleitung mit Nachverfolgung, Kundeninteresse vertreten" - - - id: "TRIG-C" - name: "Beziehungs-bezogene Beschwerde" - beschreibung: | - Allgemeine Unzufriedenheit, Vertrauensverlust, - Kommunikationsprobleme, Konflikte mit DIGIT-Mitarbeitern. - beispiele: - - "Wir fühlen uns von DIGIT nicht ernst genommen" - - "Die Kommunikation ist katastrophal" - - "Mit Herrn X kann man nicht zusammenarbeiten" - primaer_zustaendig: "SHM" - shm_rolle: "Eigenbearbeitung, Mediation, Beziehungsklärung" - - - id: "TRIG-D" - name: "Governance-Konflikt" - beschreibung: | - Kunde akzeptiert Gremienentscheidung nicht, Priorisierungskonflikt, - Zuständigkeitskonflikt. - beispiele: - - "Warum wurde das Amt X priorisiert und wir nicht?" - - "Die DSR-Entscheidung ist nicht nachvollziehbar" - - "Wer ist eigentlich für dieses Thema verantwortlich?" - primaer_zustaendig: "SOR / DSR / MB (je nach Thema)" - shm_rolle: "Vorbereitung Gremienweg, Kundenposition vertreten" - - - id: "TRIG-E" - name: "Politische/Strategische Eskalation" - beschreibung: | - Kunde droht mit politischer Eskalation, Thema hat politische - Brisanz, Reputationsrisiko für DIGIT. - beispiele: - - "Ich werde das dem Dezernenten melden" - - "Das wird im Gemeinderat Thema werden" - - "Die Presse wird sich dafür interessieren" - primaer_zustaendig: "Mission Board" - shm_rolle: "Direkte Eskalation an MB, ggf. vorab Abstimmung mit DIGIT-Amtsleitung" - - # =========================================================================== - # ESKALATIONSPFADE - # =========================================================================== - - eskalationspfade: - - beschreibung: | - Jede Trigger-Kategorie hat einen definierten Eskalationspfad. - Der Pfad wird durch die Stakeholder-Priorität modifiziert: - - Key-Stakeholder: Schnellerer Pfad, SHM bleibt aktiv involviert - - Andere: Standard-Pfad, SHM leitet weiter und verfolgt nach - - # ------------------------------------------------------------------------- - # PFAD A: Service-bezogene Beschwerde - # ------------------------------------------------------------------------- - - pfad_a: - trigger: "TRIG-A" - name: "Service-Eskalationspfad" - - standard_ablauf: - - stufe: 1 - akteur: "Service Owner" - aktion: | - SHM leitet Beschwerde an zuständigen Service Owner weiter. - SO klärt mit Kunde und behebt Problem. - eskalation_wenn: "SO kann nicht lösen oder Kunde bleibt unzufrieden" - - - stufe: 2 - akteur: "SPM (Funktion)" - aktion: | - SPM prüft systemische Ursachen, ggf. Service-Review. - eskalation_wenn: "Grundsätzliches Service-Problem oder Governance-Frage" - - - stufe: 3 - akteur: "Mission Board" - aktion: | - MB entscheidet über grundsätzliche Maßnahmen - (Service-Änderung, Ressourcen, Priorisierung). - - modifikation_key_stakeholder: - beschreibung: | - Bei Key-Stakeholdern bleibt SHM aktiv involviert: - - SHM informiert SO über Stakeholder-Priorität - - SHM bleibt in Kommunikation mit Kunde (nicht nur SO) - - SHM eskaliert proaktiv, wenn Lösung nicht zeitnah erfolgt - schnellerer_pfad: | - Bei anhaltender Unzufriedenheit kann SHM direkt Stufe 2 - einschalten, ohne auf SO-Rückmeldung zu warten. - - # ------------------------------------------------------------------------- - # PFAD B: Prozess-bezogene Beschwerde - # ------------------------------------------------------------------------- - - pfad_b: - trigger: "TRIG-B" - name: "Prozess-Eskalationspfad" - - differenzierung: - - wenn: "Beschwerde betrifft Demand-Prozess" - dann: "Weiterleitung an DPM" - - wenn: "Beschwerde betrifft Service-Änderung/Change" - dann: "Weiterleitung an SPM / Service Owner" - - wenn: "Unklar" - dann: "SOR zur Klärung" - - standard_ablauf: - - stufe: 1 - akteur: "DPM oder SPM (je nach Thema)" - aktion: | - Zuständige Funktion prüft Status, klärt mit Kunde, - gibt Rückmeldung zu Zeitrahmen/Entscheidung. - eskalation_wenn: "Kunde akzeptiert Erklärung nicht oder Prozess ist blockiert" - - - stufe: 2 - akteur: "DSR (bei Demand) oder SOR (bei Service)" - aktion: | - Gremium prüft Priorisierung, ggf. Neubewertung. - eskalation_wenn: "Grundsätzlicher Priorisierungskonflikt" - - - stufe: 3 - akteur: "Mission Board" - aktion: | - MB entscheidet über Ressourcenallokation oder - grundsätzliche Prozessanpassung. - - modifikation_key_stakeholder: - beschreibung: | - SHM vertritt Kundeninteresse aktiv im Prozess: - - SHM fragt proaktiv Status nach - - SHM bereitet ggf. Gremienvorlage mit vor - - SHM kommuniziert Zwischenstände an Kunde - - # ------------------------------------------------------------------------- - # PFAD C: Beziehungs-bezogene Beschwerde - # ------------------------------------------------------------------------- - - pfad_c: - trigger: "TRIG-C" - name: "Beziehungs-Eskalationspfad" - - beschreibung: | - Beziehungsthemen werden primär durch SHM selbst bearbeitet. - SHM agiert als Mediator und Beziehungsmanager. - - standard_ablauf: - - stufe: 1 - akteur: "Stakeholder-Manager" - aktion: | - SHM führt klärendes Gespräch mit Kunde. - Ursachenanalyse: Was ist der Kern der Unzufriedenheit? - Ggf. Vermittlung zwischen Kunde und DIGIT-Mitarbeiter. - eskalation_wenn: "Konflikt nicht lösbar oder strukturelles Problem" - - - stufe: 2 - akteur: "SHM + DIGIT-Amtsleitung" - aktion: | - SHM stimmt sich mit DIGIT-Amtsleitung ab. - Ggf. gemeinsames Gespräch mit Kunde auf Leitungsebene. - eskalation_wenn: "Amtsleiter-Gespräch löst nicht oder strategische Dimension" - - - stufe: 3 - akteur: "Mission Board" - aktion: | - MB wird informiert, entscheidet über weitere Maßnahmen. - - modifikation_key_stakeholder: - beschreibung: | - Bei Key-Stakeholdern höhere Aufmerksamkeit: - - Schnellere Reaktion - - Frühzeitige Einbindung DIGIT-Amtsleitung - - Proaktive Nachverfolgung der Beziehungsqualität - - # ------------------------------------------------------------------------- - # PFAD D: Governance-Konflikt - # ------------------------------------------------------------------------- - - pfad_d: - trigger: "TRIG-D" - name: "Governance-Eskalationspfad" - - differenzierung: - - wenn: "Konflikt betrifft Service/Demand-Routing" - dann: "SOR" - - wenn: "Konflikt betrifft Demand-Priorisierung" - dann: "DSR" - - wenn: "Konflikt betrifft übergreifende Governance" - dann: "Mission Board" - - standard_ablauf: - - stufe: 1 - akteur: "Zuständiges Gremium (SOR/DSR)" - aktion: | - SHM bringt Konflikt ins zuständige Gremium ein. - Gremium prüft und entscheidet. - eskalation_wenn: "Gremium kann nicht entscheiden oder Kunde akzeptiert nicht" - - - stufe: 2 - akteur: "Mission Board" - aktion: | - MB als höchste Eskalationsstufe entscheidet final. - - shm_rolle: | - SHM bereitet Gremienvorlage vor, vertritt Kundenperspektive - im Gremium, kommuniziert Entscheidung und Begründung an Kunden. - - # ------------------------------------------------------------------------- - # PFAD E: Politische/Strategische Eskalation - # ------------------------------------------------------------------------- - - pfad_e: - trigger: "TRIG-E" - name: "Politischer Eskalationspfad" - - beschreibung: | - Bei politischer Brisanz wird direkt an höchste Ebene eskaliert. - Keine Zwischenstufen – Zeit- und Reputationsrisiko zu hoch. - - ablauf: - - stufe: 1 - akteur: "SHM + DIGIT-Amtsleitung" - aktion: | - SHM informiert umgehend DIGIT-Amtsleitung. - Gemeinsame Lageeinschätzung: Wie ernst ist die Drohung? - Abstimmung der Reaktionsstrategie. - zeitrahmen: "Innerhalb von Stunden, nicht Tagen" - - - stufe: 2 - akteur: "Mission Board (ggf. ad-hoc)" - aktion: | - MB wird informiert, ggf. ad-hoc-Sitzung. - Entscheidung über Reaktion und Kommunikation. - - hinweis: | - Bei politischen Eskalationen ist die Stakeholder-Priorität - sekundär – die Brisanz des Themas bestimmt den Pfad. - - # =========================================================================== - # REAKTIONSZEITEN (QUALITATIV) - # =========================================================================== - - reaktionszeiten: - - beschreibung: | - Reaktionszeiten sind qualitativ definiert und differenzieren - nach Stakeholder-Priorität und Trigger-Kategorie. - Konkrete SLA-Zeiten werden im Rahmen der Pilotierung festgelegt. - - referenz_annahme: "ANNAHME-EF-001" - - matrix: - - - trigger: "TRIG-E (Politisch)" - stakeholder_alle: - erstreaktion: "Sofort (innerhalb Stunden)" - beschreibung: "Priorität übersteuert alle anderen Kategorien" - - - trigger: "TRIG-A bis TRIG-D" - stakeholder_key: - erstreaktion: "Zeitnah (innerhalb 1 Arbeitstag)" - nachverfolgung: "Aktiv, proaktive Updates an Kunde" - beschreibung: "Höchste Priorität nach politischen Eskalationen" - - stakeholder_aktiv: - erstreaktion: "Kurzfristig (innerhalb 2 Arbeitstage)" - nachverfolgung: "Regelmäßig, auf Anfrage" - beschreibung: "Priorisierte Bearbeitung" - - stakeholder_standard: - erstreaktion: "Normal (innerhalb 1 Woche)" - nachverfolgung: "Nach Abschluss relevanter Schritte" - beschreibung: "Standardbearbeitung" - - stakeholder_basis: - erstreaktion: "Normal (innerhalb 1 Woche)" - nachverfolgung: "Nur bei expliziter Nachfrage" - beschreibung: "Reaktive Bearbeitung" - - # =========================================================================== - # SHM-ROLLENVERSTÄNDNIS BEI ESKALATIONEN - # =========================================================================== - - shm_rollenverstaendnis: - - grundprinzip: "Auftraggeber-Anwalt" - - beschreibung: | - SHM agiert bei Eskalationen als "Anwalt des Auftraggebers" – nicht als - neutraler Vermittler, sondern als Vertreter der Auftraggeber-Perspektive - innerhalb von DIGIT. Dabei bleibt SHM sachlich und lösungsorientiert. - - differenzierung_nach_prioritaet: - - key_stakeholder: - involvierung: "Aktiv durchgängig" - beschreibung: | - SHM bleibt bis zur Lösung aktiv involviert, auch wenn - das Thema an andere Funktionen weitergeleitet wurde. - SHM kommuniziert proaktiv mit dem Auftraggeber. - - aktiv_stakeholder: - involvierung: "Begleitend" - beschreibung: | - SHM leitet weiter, verfolgt nach und ist Ansprechpartner - für den Kunden bei Rückfragen. - - standard_basis_stakeholder: - involvierung: "Punktuell" - beschreibung: | - SHM leitet weiter und dokumentiert. Weitere Involvierung - nur bei expliziter Kundenanfrage oder wenn Thema eskaliert. - - grenzen: - - | - SHM vertritt Kundenperspektive, aber akzeptiert Gremienentscheidungen. - SHM erklärt dem Auftraggeber die Entscheidung, auch wenn sie nicht im - Kundensinne ist. - - | - SHM übernimmt keine operative Problemlösung (das ist SO/Service Desk). - SHM sorgt dafür, dass das Problem an der richtigen Stelle bearbeitet wird. - - # =========================================================================== - # DOKUMENTATION UND NACHVERFOLGUNG - # =========================================================================== - - dokumentation: - - beschreibung: | - Jede Eskalation wird dokumentiert, um Nachverfolgung zu ermöglichen - und Muster zu erkennen. - - zu_dokumentieren: - - "Datum und Eingangskanal" - - "Absender (Amt, Person)" - - "Stakeholder-Priorität" - - "Trigger-Kategorie" - - "Kurzbeschreibung des Themas" - - "Eingeleiteter Pfad" - - "Status und Verlauf" - - "Abschluss und Ergebnis" - - ablageort: "SIMS (Stakeholder-Informations-Management-System)" - - auswertung: | - Aggregierte Auswertung der Eskalationen (Häufigkeit, Kategorien, - Durchlaufzeiten) fließt in die Koordinations- und Steuerungsstruktur - (shm_koordinations-und-steuerungsstruktur.yaml) ein. - -# ============================================================================= -# FREQUENZ-MATRIX: BETREUUNGSMODUS → FORMATE -# ============================================================================= - -frequenz_matrix: - - beschreibung: | - Übersicht, welche Formate für welchen Betreuungsmodus vorgesehen sind - und in welcher Frequenz. - - referenz_annahme: "ANNAHME-EF-001" - - matrix: - - - betreuungsmodus: "Key (Proaktiv/Dediziert)" - turnus_formate: - - format: "TF-01 Strategisches Turnus-Gespräch" - frequenz: "Quartalsweise" - strategische_formate: - - format: "SF-01 Digitalisierungs-Strategie-Workshop" - frequenz: "Alle 1-2 Jahre (anlassbezogen)" - - format: "SF-02 Bedarfs-Vertiefungs-Workshop" - frequenz: "Anlassbezogen" - kollektive_formate: - - format: "KF-01 Auftraggeber-Forum Basisservices" - frequenz: "Optional (primär für Standard/Basis)" - - format: "KF-02 Auftraggeber-Forum [Service]" - frequenz: "Bei Nutzung von Kat-B-Services" - thematische_formate: - - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" - frequenz: "Anlassbezogen" - reaktive_formate: "Ja (Details s. RF)" - - - betreuungsmodus: "Aktiv (Regelmäßig)" - turnus_formate: - - format: "TF-02 Operatives Turnus-Gespräch" - frequenz: "Halbjährlich" - strategische_formate: "Nicht vorgesehen (bei Bedarf Upgrade auf Key prüfen)" - kollektive_formate: - - format: "KF-01 Auftraggeber-Forum Basisservices" - frequenz: "Optional, zusätzlich zu Turnus" - - format: "KF-02 Auftraggeber-Forum [Service]" - frequenz: "Bei Nutzung von Kat-B-Services" - thematische_formate: - - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" - frequenz: "Anlassbezogen" - reaktive_formate: "Ja (Details s. RF)" - - - betreuungsmodus: "Standard (Eingebunden)" - turnus_formate: "Nicht vorgesehen" - strategische_formate: "Nicht vorgesehen" - kollektive_formate: - - format: "KF-01 Auftraggeber-Forum Basisservices" - frequenz: "Jährlich" - thematische_formate: - - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" - frequenz: "Anlassbezogen" - proaktive_formate: - - format: "KF-03 Basis-Puls-Check" - frequenz: "Nicht vorgesehen (Puls-Check nur für Basis)" - reaktive_formate: "Ja (Details s. RF)" - - - betreuungsmodus: "Basis (Reaktiv)" - turnus_formate: "Nicht vorgesehen" - strategische_formate: "Nicht vorgesehen" - kollektive_formate: - - format: "KF-01 Auftraggeber-Forum Basisservices" - frequenz: "Jährlich (Einladung, Teilnahme optional)" - thematische_formate: - - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" - frequenz: "Anlassbezogen (wenn Bedarf erkannt)" - proaktive_formate: - - format: "KF-03 Basis-Puls-Check" - frequenz: "Jährlich" - reaktive_formate: "Ja (Details s. RF)" - -# ============================================================================= -# BEZIEHUNGSQUALITÄTSSICHERUNG -# ============================================================================= - -beziehungsqualitaetssicherung: - - beschreibung: | - Die Beziehungsqualitätssicherung ermöglicht die systematische Erfassung - und Bewertung der Kundenbeziehungen sowie die frühzeitige Erkennung - von Problemen. Sie unterstützt die Kernentscheidung EF-E3: - "Woran erkenne ich Beziehungsprobleme, wann interveniere ich?" - - grundprinzip: | - SHM gibt eine Einschätzung für alle Ämter im Portfolio – nicht nur - für aktiv betreute. Die Erfassungstiefe und -frequenz variiert - nach Betreuungsmodus. - - # =========================================================================== - # BEWERTUNGSSKALA - # =========================================================================== - - bewertungsskala: - - beschreibung: | - Die Beziehungsqualität wird auf einer 4-Stufen-Skala bewertet. - Die Stufen sind qualitativ definiert und ermöglichen eine - differenzierte Einschätzung ohne Pseudo-Präzision. - - stufen: - - - stufe: "Exzellent" - kuerzel: "EX" - beschreibung: | - Vertrauensvolle, partnerschaftliche Beziehung. Kunde ist - sehr zufrieden, kommuniziert offen, bringt sich aktiv ein. - Keine offenen Konflikte oder Irritationen. - indikatoren: - - "Kunde äußert aktiv Zufriedenheit" - - "Konstruktive, offene Kommunikation" - - "Kunde empfiehlt DIGIT-Leistungen weiter" - - "Proaktive Beteiligung an Formaten" - - - stufe: "Gut" - kuerzel: "GU" - beschreibung: | - Stabile, funktionale Beziehung. Kunde ist grundsätzlich - zufrieden, Zusammenarbeit läuft ohne größere Probleme. - Punktuelle Kritik wird konstruktiv geäußert. - indikatoren: - - "Regelkommunikation funktioniert" - - "Kritik wird sachlich vorgebracht" - - "Termine werden eingehalten" - - "Keine Eskalationen" - - - stufe: "Angespannt" - kuerzel: "AN" - beschreibung: | - Beziehung zeigt Belastungszeichen. Kunde äußert Unzufriedenheit, - Kommunikation ist erschwert, es gibt offene Themen oder - ungelöste Konflikte. Intervention empfohlen. - indikatoren: - - "Wiederholte Kritik oder Beschwerden" - - "Kommunikation wird förmlicher oder distanzierter" - - "Termine werden verschoben oder abgesagt" - - "Offene Konflikte oder ungelöste Themen" - - - stufe: "Kritisch" - kuerzel: "KR" - beschreibung: | - Beziehung ist ernsthaft gefährdet. Massiver Vertrauensverlust, - Kommunikationsabbruch, Eskalationsdrohungen. - Sofortige Intervention erforderlich. - indikatoren: - - "Kunde verweigert Kommunikation oder Kooperation" - - "Eskalation an höhere Ebenen (Dezernent, Politik)" - - "Öffentliche Kritik oder Beschwerden" - - "Grundsätzliche Infragestellung der Zusammenarbeit" - - # =========================================================================== - # INDIKATOR-KATEGORIEN - # =========================================================================== - - indikator_kategorien: - - beschreibung: | - Die Bewertung der Beziehungsqualität speist sich aus drei - Indikator-Kategorien, die je nach Betreuungsmodus unterschiedlich - gewichtet werden. - - kategorien: - - - id: "IND-1" - name: "Direkte Einschätzung" - typ: "Subjektiv, durch SHM" - beschreibung: | - Der Stakeholder-Manager schätzt die Beziehungsqualität auf - Basis seiner Interaktionen und Wahrnehmungen ein. - basis: - - "Gesprächseindrücke (Tonalität, Offenheit)" - - "Kooperationsbereitschaft" - - "Allgemeine Stimmung in der Zusammenarbeit" - anwendung: "Alle Betreuungsmodi" - erfassung: "Nach Interaktionen, mindestens jährlich" - - - id: "IND-2" - name: "Interaktions-Signale" - typ: "Beobachtbar, prozessbasiert" - beschreibung: | - Objektiv beobachtbare Signale aus den Interaktionen und - Prozessen, die auf Beziehungsqualität hinweisen. - signale: - - signal: "Eskalationen" - positiv: "Keine Eskalationen" - negativ: "Häufige oder wiederkehrende Eskalationen" - - signal: "Beschwerden" - positiv: "Keine oder konstruktive Kritik" - negativ: "Beziehungs-bezogene Beschwerden (TRIG-C)" - - signal: "Teilnahme" - positiv: "Regelmäßige Teilnahme an Formaten" - negativ: "Wiederholtes Absagen oder Fernbleiben" - - signal: "Reaktionsverhalten" - positiv: "Zeitnahe Antworten, Termintreue" - negativ: "Keine Reaktion, verschobene Termine" - anwendung: "Alle Betreuungsmodi (soweit Daten anfallen)" - erfassung: "Kontinuierlich, bei Auftreten" - - - id: "IND-3" - name: "Strukturiertes Feedback" - typ: "Explizit erhoben" - beschreibung: | - Gezielte Abfrage der Kundenzufriedenheit und - Beziehungswahrnehmung beim Kunden selbst. - methoden: - - "Zufriedenheits-Check im Turnus-Gespräch" - - "Strukturierte Feedback-Fragen" - - "Ggf. kurze schriftliche Abfrage" - anwendung: "Key-Stakeholder" - erfassung: "Jährlich (im Rahmen eines Turnus-Gesprächs)" - - # =========================================================================== - # ERFASSUNG NACH BETREUUNGSMODUS - # =========================================================================== - - erfassung_nach_betreuungsmodus: - - beschreibung: | - Die Erfassungstiefe und -frequenz variiert nach Betreuungsmodus. - Für alle Ämter wird mindestens jährlich eine Einschätzung abgegeben. - - matrix: - - - betreuungsmodus: "Key (Proaktiv/Dediziert)" - indikator_kategorien: - - kategorie: "IND-1 (Direkte Einschätzung)" - anwendung: "Ja" - frequenz: "Nach jedem Turnus-Gespräch (quartalsweise)" - - kategorie: "IND-2 (Interaktions-Signale)" - anwendung: "Ja" - frequenz: "Kontinuierlich, systematische Auswertung" - - kategorie: "IND-3 (Strukturiertes Feedback)" - anwendung: "Ja" - frequenz: "Jährlich" - gesamtbewertung: "Quartalsweise aktualisiert" - trigger_sensitivitaet: "Hoch – niedrige Schwellen" - - - betreuungsmodus: "Aktiv (Regelmäßig)" - indikator_kategorien: - - kategorie: "IND-1 (Direkte Einschätzung)" - anwendung: "Ja" - frequenz: "Nach jedem Turnus-Gespräch (halbjährlich)" - - kategorie: "IND-2 (Interaktions-Signale)" - anwendung: "Ja" - frequenz: "Kontinuierlich, bei Auftreten" - - kategorie: "IND-3 (Strukturiertes Feedback)" - anwendung: "Optional" - frequenz: "Bei Bedarf" - gesamtbewertung: "Halbjährlich aktualisiert" - trigger_sensitivitaet: "Mittel" - - - betreuungsmodus: "Standard (Eingebunden)" - indikator_kategorien: - - kategorie: "IND-1 (Direkte Einschätzung)" - anwendung: "Ja" - frequenz: "Nach Advisory Board oder bei Kontakt, mind. jährlich" - - kategorie: "IND-2 (Interaktions-Signale)" - anwendung: "Ja, soweit Daten anfallen" - frequenz: "Bei Auftreten" - - kategorie: "IND-3 (Strukturiertes Feedback)" - anwendung: "Nein" - frequenz: "–" - gesamtbewertung: "Jährlich aktualisiert" - trigger_sensitivitaet: "Normal" - - - betreuungsmodus: "Basis (Reaktiv)" - indikator_kategorien: - - kategorie: "IND-1 (Direkte Einschätzung)" - anwendung: "Ja" - frequenz: "Bei Kontakt, mind. jährlich (Schätzung)" - - kategorie: "IND-2 (Interaktions-Signale)" - anwendung: "Ja, soweit Daten anfallen" - frequenz: "Bei Auftreten" - - kategorie: "IND-3 (Strukturiertes Feedback)" - anwendung: "Nein" - frequenz: "–" - gesamtbewertung: "Jährlich aktualisiert" - trigger_sensitivitaet: "Nur bei expliziten Signalen" - - # =========================================================================== - # INTERVENTIONS-TRIGGER - # =========================================================================== - - interventions_trigger: - - beschreibung: | - Interventions-Trigger sind definierte Schwellen oder Muster, - die eine proaktive Intervention durch SHM auslösen. - Die Trigger-Sensitivität variiert nach Betreuungsmodus. - - trigger: - - - id: "INTTRIG-01" - name: "Bewertungsverschlechterung" - beschreibung: | - Die SHM-Einschätzung der Beziehungsqualität verschlechtert - sich um mindestens eine Stufe. - schwelle: - key_stakeholder: "Jede Verschlechterung" - aktiv_stakeholder: "Jede Verschlechterung" - standard_basis: "Verschlechterung auf 'Angespannt' oder 'Kritisch'" - intervention: "Klärungsgespräch" - - - id: "INTTRIG-02" - name: "Kritische Bewertung" - beschreibung: | - Die Beziehungsqualität wird als 'Kritisch' eingestuft. - schwelle: "Alle Betreuungsmodi" - intervention: "Sofortige Intervention (Klärungsgespräch mit Amtsleitung)" - - - id: "INTTRIG-03" - name: "Beziehungs-Beschwerde" - beschreibung: | - Eine Beschwerde der Kategorie TRIG-C (Beziehungs-bezogen) - geht ein. - schwelle: "Alle Betreuungsmodi – jede Beschwerde ist ein Trigger" - intervention: "Klärungsgespräch" - verweis: "Eskalationspfad C" - - - id: "INTTRIG-04" - name: "Eskalationshäufung" - beschreibung: | - Mehrere Eskalationen (beliebiger Kategorie) innerhalb - eines definierten Zeitraums. - schwelle: - key_stakeholder: "2+ Eskalationen in 6 Monaten" - aktiv_stakeholder: "3+ Eskalationen in 12 Monaten" - standard_basis: "3+ Eskalationen in 12 Monaten" - intervention: "Klärungsgespräch, Ursachenanalyse" - - - id: "INTTRIG-05" - name: "Teilnahme-Rückzug" - beschreibung: | - Kunde sagt wiederholt Termine ab oder erscheint nicht - zu vereinbarten Formaten. - schwelle: - key_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows" - aktiv_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows" - standard_basis: "Nicht anwendbar (keine festen Termine)" - intervention: "Telefonische Nachfrage, ggf. Klärungsgespräch" - - - id: "INTTRIG-06" - name: "Kommunikationsabbruch" - beschreibung: | - Kunde reagiert nicht mehr auf Kontaktversuche. - schwelle: - key_stakeholder: "Keine Reaktion auf 2 Kontaktversuche" - aktiv_stakeholder: "Keine Reaktion auf 3 Kontaktversuche" - standard_basis: "Keine Reaktion auf 3 Kontaktversuche" - intervention: "Eskalation an Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung einbinden" - - # =========================================================================== - # INTERVENTIONS-REPERTOIRE - # =========================================================================== - - interventions_repertoire: - - beschreibung: | - Bei Auslösung eines Interventions-Triggers stehen folgende - Interventionen zur Verfügung. Die Wahl der Intervention - richtet sich nach Schwere und Kontext. - - interventionen: - - - id: "INTV-01" - name: "Klärungsgespräch" - beschreibung: | - Persönliches Gespräch zwischen SHM und Kundenvertreter - zur Klärung der Situation und Ursachenanalyse. - ziel: "Verständnis der Ursachen, Wiederherstellung des Dialogs" - teilnehmer: "SHM + Kundenvertreter (operative Ebene)" - eskalation_zu: "Klärungsgespräch mit Amtsleitung" - typische_trigger: ["INTTRIG-01", "INTTRIG-03", "INTTRIG-04", "INTTRIG-05"] - - - id: "INTV-02" - name: "Klärungsgespräch mit Amtsleitung" - beschreibung: | - Gespräch auf Leitungsebene, wenn operative Klärung nicht - ausreicht oder die Beziehung kritisch ist. - ziel: "Verbindliche Klärung auf Entscheidungsebene" - teilnehmer: "SHM + Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung" - voraussetzung: | - Operative Klärung war nicht erfolgreich ODER - Bewertung ist 'Kritisch' ODER - Thema erfordert Leitungsentscheidung - typische_trigger: ["INTTRIG-02", "INTTRIG-06"] - - - id: "INTV-03" - name: "Maßnahmenplan" - beschreibung: | - Strukturierter Plan mit konkreten Maßnahmen zur - Verbesserung der Beziehungsqualität. - ziel: "Nachvollziehbare, terminierte Maßnahmen mit Verantwortlichkeiten" - inhalt: - - "Identifizierte Ursachen" - - "Vereinbarte Maßnahmen" - - "Verantwortlichkeiten (DIGIT-seitig und Kunden-seitig)" - - "Termine / Meilensteine" - - "Review-Termin" - typische_massnahmen: - - "Erhöhte Kontaktfrequenz" - - "Dedizierter Ansprechpartner für offene Themen" - - "Priorisierung offener Bedarfe/Tickets" - - "Regelmäßige Status-Updates" - - "Gemeinsamer Workshop zur Neuausrichtung" - anwendung: | - Bei 'Angespannt' oder 'Kritisch', wenn einzelnes - Klärungsgespräch nicht ausreicht. - - eskalation_bei_misserfolg: | - Wenn Interventionen nicht zur Verbesserung führen, wird das - Thema ins Mission Board eingebracht (analog Eskalationspfad C, Stufe 3). - - # =========================================================================== - # DOKUMENTATION - # =========================================================================== - - dokumentation: - - beschreibung: | - Die Beziehungsqualität wird im Amts-Steckbrief (SIMS) dokumentiert - und historisch nachvollziehbar geführt. - - zu_dokumentieren: - - attribut: "beziehungsqualitaet_aktuell" - beschreibung: "Aktuelle Bewertung (EX/GU/AN/KR)" - aktualisierung: "Gemäß Erfassungsfrequenz" - - attribut: "beziehungsqualitaet_historie" - beschreibung: "Verlauf der Bewertungen mit Datum" - zweck: "Trends erkennen" - - attribut: "interventionen" - beschreibung: "Durchgeführte Interventionen mit Datum und Ergebnis" - zweck: "Nachvollziehbarkeit, Lernen" - - attribut: "massnahmenplan" - beschreibung: "Aktiver Maßnahmenplan (falls vorhanden)" - zweck: "Nachverfolgung" - - ablageort: "SIMS (Stakeholder-Informations-Management-System)" - - verweis_schema: | - Attribute sind im shm_schema_amtssteckbrief.yaml zu ergänzen - (Kategorie: Betreuung). - - # =========================================================================== - # REVIEW UND REPORTING - # =========================================================================== - - review_und_reporting: - - beschreibung: | - Die aggregierten Beziehungsqualitätsdaten fließen in die - Koordinations- und Steuerungsstruktur - (shm_koordinations-und-steuerungsstruktur.yaml) ein. - - aggregierte_auswertungen: - - "Verteilung der Bewertungen über alle Stakeholder" - - "Veränderungen gegenüber Vorperiode" - - "Anzahl aktiver Interventionen/Maßnahmenpläne" - - "Korrelation mit Eskalationshäufigkeit" - - berichtsrhythmus: "Quartalsweise (für Management-Reporting)" - - strategischer_input: | - Systematische Beziehungsprobleme (z.B. häufige Kritik an - bestimmten Services oder Prozessen) werden als Input für - DIGIT-Strategieprozess aufbereitet. - [Verweis: Strategieprozess noch nicht modelliert] - -# ============================================================================= -# TEMPLATE-BEDARFE (Übersicht für Phase 11) -# ============================================================================= - -template_bedarfe: - - beschreibung: | - Übersicht der identifizierten Template-Bedarfe. - Ausarbeitung erfolgt in Phase 11 (Arbeitsmaterialien). - - templates: - - - id: "TPL-EF-01" - name: "Agenda-Vorlage Strategisches Turnus-Gespräch" - format_referenz: "TF-01" - - - id: "TPL-EF-02" - name: "Protokoll-Vorlage Turnus-Gespräch" - format_referenz: "TF-01, TF-02" - - - id: "TPL-EF-03" - name: "Agenda-Vorlage Operatives Turnus-Gespräch" - format_referenz: "TF-02" - - - id: "TPL-EF-04" - name: "Workshop-Leitfaden Digitalisierungs-Strategie" - format_referenz: "SF-01" - - - id: "TPL-EF-05" - name: "Canvas: Digitalisierungspotenziale" - format_referenz: "SF-01" - - - id: "TPL-EF-06" - name: "Ergebnisdokumentation Strategie-Workshop" - format_referenz: "SF-01" - - - id: "TPL-EF-07" - name: "Workshop-Leitfaden Bedarfs-Vertiefung" - format_referenz: "SF-02" - - - id: "TPL-EF-08" - name: "Erweiterter Bedarfssteckbrief" - format_referenz: "SF-02" - - - id: "TPL-EF-09" - name: "Einladungs-Vorlage Advisory Board" - format_referenz: "KF-01" - - - id: "TPL-EF-10" - name: "Agenda-Vorlage Advisory Board" - format_referenz: "KF-01" - - - id: "TPL-EF-11" - name: "Protokoll-Vorlage Advisory Board" - format_referenz: "KF-01" - - - id: "TPL-EF-12" - name: "Workshop-Leitfaden Bedarfs-Konsolidierung" - format_referenz: "ThF-01" - - - id: "TPL-EF-13" - name: "Eskalations-Erfassungsbogen" - beschreibung: "Strukturierte Erfassung eingehender Eskalationen" - - - id: "TPL-EF-14" - name: "Eskalations-Statusbericht" - beschreibung: "Vorlage für Statusupdates bei laufenden Eskalationen" - - - id: "TPL-EF-15" - name: "Gremienvorlage Eskalation" - beschreibung: "Vorlage für Eskalationen an SOR/DSR/MB" - - - id: "TPL-EF-16" - name: "Feedback-Fragen Key-Stakeholder" - beschreibung: "Strukturierte Fragen für jährliches Feedback-Gespräch" - - - id: "TPL-EF-17" - name: "Maßnahmenplan Beziehungsqualität" - beschreibung: "Vorlage für strukturierten Maßnahmenplan" - - - id: "TPL-EF-18" - name: "Interventions-Dokumentation" - beschreibung: "Vorlage zur Dokumentation durchgeführter Interventionen" - - - id: "TPL-EF-19" - name: "Einladungs-Vorlage Auftraggeber-Forum" - format_referenz: "KF-01" - - - id: "TPL-EF-20" - name: "Agenda-Vorlage Auftraggeber-Forum (integriert)" - format_referenz: "KF-01" - beschreibung: "Kombinierte Agenda für SLA-Review und SHM-Themen" - - - id: "TPL-EF-21" - name: "Protokoll-Vorlage Auftraggeber-Forum" - format_referenz: "KF-01" - - - id: "TPL-EF-22" - name: "Basis-Puls-Check Fragebogen" - format_referenz: "KF-03" - - - id: "TPL-EF-23" - name: "Basis-Puls-Check Auswertungs-Template" - format_referenz: "KF-03" - - - id: "TPL-EF-24" - name: "Basis-Puls-Check Anschreiben" - format_referenz: "KF-03" - - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-EF-003" - thema: "Ressourcen-Implikationen" - beschreibung: | - Die Formate haben unterschiedlichen Ressourcenbedarf. - Eine Überschlagsrechnung (wie viele Key-Stakeholder kann ein - Stakeholder-Manager betreuen?) fehlt noch. - prioritaet: "niedrig" - naechster_schritt: "Nach Pilotierung evaluieren" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-09" - autor: "Chat-Session Phase 2" - aenderung: "Initiale Erstellung als Arbeitsstand" - - - version: "0.2" - datum: "2025-12-09" - autor: "Chat-Session Phase 2" - aenderung: "Eskalationslogik in reaktive Formate integriert" - - - version: "0.3" - datum: "2025-12-09" - autor: "Chat-Session Phase 2" - aenderung: "Beziehungsqualitätssicherung als neuer Abschnitt ergänzt" - - - version: "0.4" - datum: "2025-12-09" - autor: "Review-Feedback Integration" - aenderung: | - - Kollektive Formate: Integration mit SLM-Auftraggeber-Vertretungen - zu einheitlichem Auftraggeber-Forum-Konzept - - Frequenz Auftraggeber-Forum auf jährlich angepasst (Pilotierungs-Vorbehalt) - - Neues Format KF-03 "Basis-Puls-Check" für Basis-Stakeholder - - Template-Bedarfe ergänzt - - - version: "0.5" - datum: "2025-12-10" - autor: "Cross-Check Phase 5" - aenderung: | - - Veraltete Phase-7-Referenzen aktualisiert auf - shm_koordinations-und-steuerungsstruktur.yaml - - VoC-Schnittstelle in Meta-Sektion ergänzt - - Querverweise zu Koordinations- und Steuerungsstruktur harmonisiert - +# ============================================================================= +# SHM ENGAGEMENT-FRAMEWORK: ARBEITSSTAND +# ============================================================================= +# Version: 0.5 (Entwurf) +# Datum: 2025-12-10 +# Status: In Entwicklung +# Kontext: Entwicklung Phase 2 +# ============================================================================= + +meta: + dokument_typ: "arbeitsstand" + modul: "shm_engagement-framework" + phase: 2 + + zweck: | + Das Engagement-Framework operationalisiert die Betreuungsmodi aus dem + Stakeholder-Portfolio. Es definiert Interaktionsformate, + Frequenzen und Reaktionslogiken für die Auftraggeber-Betreuung. + + design_prinzipien: + - prinzip: "Zweckorientierung" + beschreibung: "Jedes Format verfolgt einen definierten Zweck" + - prinzip: "Differenzierung nach Betreuungsmodus" + beschreibung: "Key-Stakeholder erhalten qualitativ andere Betreuung, nicht nur häufigere" + - prinzip: "Bidirektionaler Wertfluss" + beschreibung: "Strategische Formate liefern Input für DIGIT-Strategie" + - prinzip: "Prozessgesteuerte Eskalation" + beschreibung: "Eskalationswege sind strukturiert, nicht personengebunden" + + annahmen: + - id: "ANNAHME-EF-001" + thema: "Frequenz-Richtwerte" + beschreibung: | + Die angegebenen Frequenzen sind Empfehlungen, keine verbindlichen Vorgaben. + Die finalen Frequenzen werden im Rahmen der Pilotierung festgelegt und + müssen verprobt werden. + status: "Im Pilotierung zu validieren" + + - id: "ANNAHME-EF-002" + thema: "Cluster-basierte Kollektivformate" + beschreibung: | + Kollektive Formate werden primär nach Segmentierungs-Clustern organisiert. + Thematische Formate ergänzen dies für clusterübergreifende Bedarfe. + status: "Designentscheidung" + + - id: "ANNAHME-EF-003" + thema: "Integriertes Auftraggeber-Forum" + beschreibung: | + Die Auftraggeber-Vertretungen (SLM) und Advisory Boards (SHM) werden + zu einem integrierten Auftraggeber-Forum konsolidiert. Diese Entscheidung + reduziert Gremien-Redundanz und stärkt die gemeinsame Außenwirkung. + status: "Designentscheidung" + governance_referenz: "GOV-SHM-015" + + schnittstellen: + - schnittstelle: "DIGIT-Strategieprozess" + richtung: "SHM → Strategie" + beschreibung: | + Strategische Formate liefern Erkenntnisse zu Bedarfstrends und + Entwicklungspotenzialen, die in die DIGIT-Strategie einfließen. + status: "Strategieprozess noch nicht modelliert – Verweis auf Schnittstelle" + + - schnittstelle: "Voice-of-Customer (VoC)" + richtung: "Engagement-Framework → VoC → Koordinations- und Steuerungsstruktur" + beschreibung: | + Das Engagement-Framework liefert Inputs für das VoC-Konzept + (Beziehungsqualität, Eskalationen, Interaktionsqualität). + VoC aggregiert diese zu übergreifenden Erkenntnissen, die in die + REV-1/REV-2 Review-Zyklen einfließen. + status: "Aktiv (Phase 5 abgeschlossen)" + referenz: "shm_voice-of-customer.yaml" + +# ============================================================================= +# FUNKTIONALE HERLEITUNG +# ============================================================================= + +funktionale_herleitung: + + leitfrage: | + Welche Entscheidungen und Handlungen soll das Engagement-Framework + unterstützen? + + kernentscheidungen: + + - id: EKE-1 + name: "Interaktionsplanung" + leitfrage: "Wann interagiere ich mit wem in welchem Format?" + kontext: | + Ein Stakeholder-Manager betreut mehrere Ämter mit unterschiedlichen + Betreuungsmodi. Das Framework muss helfen, Zeitressourcen systematisch + zu allokieren – planbar, nicht ad-hoc. + unterstuetzt_durch: + - "Interaktionsformat-Katalog" + - "Frequenz-Matrix" + + - id: EKE-2 + name: "Reaktionssteuerung" + leitfrage: "Wie reagiere ich auf eingehende Anfragen, Beschwerden, Eskalationen?" + kontext: | + Nicht alle Interaktionen sind geplant. Das Framework muss Regeln liefern, + wann SHM reagiert, wann weitergeleitet wird, und wie eskaliert wird. + unterstuetzt_durch: + - "Reaktionslogik" + - "Eskalationspfade" + + - id: EKE-3 + name: "Beziehungsqualitätssicherung" + leitfrage: "Woran erkenne ich Beziehungsprobleme, wann interveniere ich?" + kontext: | + Beziehungen können erodieren ohne explizite Beschwerden. Das Framework + sollte Indikatoren und Review-Mechanismen liefern. + unterstuetzt_durch: + - "Review-Mechanismus" + - "Interventions-Trigger" + + - id: EKE-4 + name: "Strategische Wertschöpfung" + leitfrage: "Wie schaffe ich bei Key-Stakeholdern aktiven Mehrwert?" + kontext: | + Bei priorisierten Stakeholdern ist SHM nicht nur reaktiver Aufnehmer, + sondern proaktiver Berater. Das Framework muss Formate definieren, + die strategische Beratung und bidirektionalen Wertfluss ermöglichen. + unterstuetzt_durch: + - "Strategische Formate" + - "Output-Kanal Richtung DIGIT-Strategie" + +# ============================================================================= +# FORMAT-TAXONOMIE: ÜBERSICHT +# ============================================================================= + +format_taxonomie: + + beschreibung: | + Das Engagement-Framework unterscheidet fünf Format-Kategorien, die + unterschiedliche Zwecke erfüllen und sich in Planbarkeit, Teilnehmerkreis + und Interaktionstiefe unterscheiden. + + kategorien: + + - kategorie: "Turnus-Formate" + kuerzel: "TF" + charakter: "Geplant, wiederkehrend, 1:1" + primaerer_zweck: "Regelmäßiger Austausch, Beziehungspflege, Früherkennung" + betreuungsmodi: ["Key", "Aktiv"] + + - kategorie: "Strategische Formate" + kuerzel: "SF" + charakter: "Geplant, anlassbezogen, 1:1 oder Kleingruppe" + primaerer_zweck: "Aktive Digitalberatung, strategische Bedarfsentwicklung" + betreuungsmodi: ["Key"] + + - kategorie: "Kollektive Formate" + kuerzel: "KF" + charakter: "Geplant, wiederkehrend, Gruppe" + primaerer_zweck: "Effiziente Abdeckung mehrerer Stakeholder, Informationsaustausch" + betreuungsmodi: ["Standard", "Basis"] + + - kategorie: "Thematische Formate" + kuerzel: "ThF" + charakter: "Anlassbezogen, Gruppe" + primaerer_zweck: "Bedarfskonsolidierung über Cluster-Grenzen" + betreuungsmodi: ["Alle (bedarfsgetrieben)"] + + - kategorie: "Reaktive Formate" + kuerzel: "RF" + charakter: "Ungeplant, anlassbezogen" + primaerer_zweck: "Umgang mit Eskalationen, Beschwerden, Ad-hoc-Anfragen" + betreuungsmodi: ["Alle"] + +# ============================================================================= +# TURNUS-FORMATE (TF) +# ============================================================================= + +turnus_formate: + + beschreibung: | + Turnus-Formate bilden das Rückgrat der regelmäßigen Stakeholder-Betreuung. + Sie sind geplant, wiederkehrend und finden im 1:1-Setting zwischen + Stakeholder-Manager und Kundenvertreter statt. + + formate: + + # ------------------------------------------------------------------------- + # TF-01: Strategisches Turnus-Gespräch (Key) + # ------------------------------------------------------------------------- + + - id: "TF-01" + name: "Strategisches Turnus-Gespräch" + + zweck: | + Tiefgehender Austausch mit Key-Stakeholdern zu strategischen Themen, + laufenden Vorhaben und Beziehungsqualität. Geht über Statusabfrage + hinaus – aktive Beratungskomponente. + + zielgruppe: + betreuungsmodus: "Key (Proaktiv/Dediziert)" + teilnehmer_auftraggeber: "Amtsleitung oder delegierte SLA-Befugnis" + teilnehmer_shm: "Zugeordneter Stakeholder-Manager" + + frequenz: + empfehlung: "Quartalsweise" + flexibilitaet: | + Kann bei Bedarf häufiger stattfinden. Minimum: halbjährlich. + referenz_annahme: "ANNAHME-EF-001" + + typische_inhalte: + - block: "Beziehungs-Check" + beschreibung: "Wie läuft die Zusammenarbeit? Gibt es Irritationen?" + dauer_anteil: "10%" + - block: "Laufende Vorhaben" + beschreibung: "Status relevanter Projekte, Demands, Service-Themen" + dauer_anteil: "30%" + - block: "Strategischer Ausblick" + beschreibung: "Welche Themen stehen beim Amt an? Digitalisierungsbedarfe?" + dauer_anteil: "40%" + - block: "Offene Punkte / Vereinbarungen" + beschreibung: "Konkrete nächste Schritte, Verantwortlichkeiten" + dauer_anteil: "20%" + + voraussetzungen: + informationen: + - "Aktueller Projektstatus zu Vorhaben des Amtes" + - "Service-Performance-Daten (SLA-Einhaltung, offene Tickets)" + - "Offene Bedarfe und Demands im System" + vorbereitung: + - "Agenda vorab abstimmen" + - "Relevante Statusberichte sichten" + + output: + dokumentation: "Gesprächsprotokoll im SIMS (Stakeholder-Informations-Management-System)" + follow_up: "Vereinbarte Maßnahmen mit Verantwortlichkeit und Termin" + strategie_input: | + Erkenntnisse zu strategischen Bedarfstrends werden aggregiert und + fließen in DIGIT-Strategieprozess ein. + [Verweis: Strategieprozess noch nicht modelliert] + + template_bedarf: + - "Agenda-Vorlage Strategisches Turnus-Gespräch" + - "Protokoll-Vorlage" + + abgrenzung: | + Unterscheidet sich vom operativen Turnus-Gespräch (TF-02) durch + strategische Tiefe und Beratungskomponente. + + # ------------------------------------------------------------------------- + # TF-02: Operatives Turnus-Gespräch (Aktiv) + # ------------------------------------------------------------------------- + + - id: "TF-02" + name: "Operatives Turnus-Gespräch" + + zweck: | + Regelmäßiger Austausch mit Aktiv-Stakeholdern zu laufenden Themen + und Service-Zufriedenheit. Fokus auf Beziehungspflege und + Früherkennung von Problemen. + + zielgruppe: + betreuungsmodus: "Aktiv (Regelmäßig)" + teilnehmer_auftraggeber: "Amtsleitung oder operative Ansprechperson" + teilnehmer_shm: "Zugeordneter Stakeholder-Manager" + + frequenz: + empfehlung: "Halbjährlich" + flexibilitaet: | + Kann bei konkretem Anlass (laufendes Projekt, bekannte Probleme) + auf quartalsweise erhöht werden. + referenz_annahme: "ANNAHME-EF-001" + + typische_inhalte: + - block: "Zufriedenheits-Check" + beschreibung: "Wie zufrieden ist das Amt mit den IT-Services?" + dauer_anteil: "20%" + - block: "Laufende Themen" + beschreibung: "Offene Tickets, Bedarfe, bekannte Probleme" + dauer_anteil: "40%" + - block: "Ausblick" + beschreibung: "Anstehende Veränderungen beim Amt, absehbare Bedarfe" + dauer_anteil: "30%" + - block: "Vereinbarungen" + beschreibung: "Nächste Schritte, offene Punkte" + dauer_anteil: "10%" + + voraussetzungen: + informationen: + - "Offene Tickets des Amtes" + - "Bekannte Service-Probleme" + vorbereitung: + - "Kurze Agenda vorab" + + output: + dokumentation: "Kurzprotokoll im SIMS" + follow_up: "Offene Punkte mit Verantwortlichkeit" + + template_bedarf: + - "Agenda-Vorlage Operatives Turnus-Gespräch" + + abgrenzung: | + Weniger strategische Tiefe als TF-01. Fokus auf operative + Beziehungspflege, nicht auf aktive Beratung. + +# ============================================================================= +# STRATEGISCHE FORMATE (SF) +# ============================================================================= + +strategische_formate: + + beschreibung: | + Strategische Formate gehen über regelmäßige Turnus-Gespräche hinaus. + Sie dienen der aktiven Digitalberatung und strategischen + Bedarfsentwicklung bei Key-Stakeholdern. Der Wertfluss ist + bidirektional: SHM berät den Kunden, gewinnt aber auch strategische + Erkenntnisse für die DIGIT-Weiterentwicklung. + + formate: + + # ------------------------------------------------------------------------- + # SF-01: Digitalisierungs-Strategie-Workshop + # ------------------------------------------------------------------------- + + - id: "SF-01" + name: "Digitalisierungs-Strategie-Workshop" + + zweck: | + Strukturierte Erarbeitung der Digitalisierungsperspektive eines + Key-Stakeholders. Identifikation strategischer Bedarfe, Priorisierung, + Ableitung einer gemeinsamen Roadmap. + + zielgruppe: + betreuungsmodus: "Key (Proaktiv/Dediziert)" + teilnehmer_auftraggeber: | + Amtsleitung + relevante Führungskräfte/Fachexperten des Amtes + (typisch 3-6 Personen) + teilnehmer_shm: "Stakeholder-Manager, ggf. weitere DIGIT-Expertise" + + anlass: + - "Initiale Strategieerarbeitung bei neuem Key-Stakeholder" + - "Periodische Aktualisierung (z.B. alle 2 Jahre)" + - "Wesentliche Veränderung beim Amt (Reorganisation, neue Aufgaben)" + + frequenz: + empfehlung: "Anlassbezogen, typisch alle 1-2 Jahre" + hinweis: "Kein fester Turnus, aber proaktiv durch SHM angestoßen" + + typische_inhalte: + - block: "Ist-Analyse" + beschreibung: | + Aktuelle IT-Landschaft des Amtes, genutzte Services, + bekannte Schmerzpunkte + - block: "Strategische Ziele des Amtes" + beschreibung: | + Wohin entwickelt sich das Amt? Welche Aufgaben werden wichtiger/unwichtiger? + - block: "Digitalisierungspotenziale" + beschreibung: | + Wo kann Digitalisierung unterstützen? Welche Bedarfe zeichnen sich ab? + - block: "Priorisierung und Roadmap" + beschreibung: | + Gemeinsame Bewertung der Potenziale, Ableitung priorisierter + Handlungsfelder und grober Zeitrahmen + + voraussetzungen: + informationen: + - "Service-Nutzung des Amtes (aus Service-Katalog)" + - "Laufende und geplante Projekte" + - "Bekannte Bedarfe und Demands" + - "Strategische Dokumente des Amtes (falls verfügbar)" + vorbereitung: + - "Vorgespräch mit Amtsleitung zur Erwartungsklärung" + - "Analyse der Ist-Situation" + - "Workshop-Design und Methodik vorbereiten" + + output: + dokumentation: | + Ergebnisdokumentation mit: + - Identifizierte Digitalisierungsbedarfe + - Priorisierte Handlungsfelder + - Roadmap-Entwurf + follow_up: | + - Konkrete Bedarfe werden in Bedarfssteckbriefe überführt + - Roadmap wird Grundlage für Turnus-Gespräche + strategie_input: | + Aggregierte Erkenntnisse zu Bedarfstrends und Entwicklungsrichtungen + fließen in DIGIT-Strategieprozess ein. + [Verweis: Strategieprozess noch nicht modelliert] + + template_bedarf: + - "Workshop-Leitfaden Digitalisierungs-Strategie" + - "Canvas: Digitalisierungspotenziale" + - "Ergebnisdokumentation-Vorlage" + + ressourcen_hinweis: | + Ressourcenintensives Format (Vorbereitung + Durchführung: 1-2 Personentage). + Daher nur für Key-Stakeholder und anlassbezogen. + + # ------------------------------------------------------------------------- + # SF-02: Bedarfs-Vertiefungs-Workshop + # ------------------------------------------------------------------------- + + - id: "SF-02" + name: "Bedarfs-Vertiefungs-Workshop" + + zweck: | + Vertiefende Bedarfsanalyse für komplexe oder strategisch bedeutsame + Bedarfe eines Key-Stakeholders. Geht über den Bedarfssteckbrief hinaus + und erarbeitet ein fundiertes Problemverständnis. + + zielgruppe: + betreuungsmodus: "Key (Proaktiv/Dediziert)" + teilnehmer_auftraggeber: | + Amtsleitung oder delegierte Entscheider + Fachexperten für + den spezifischen Bedarf + teilnehmer_shm: "Stakeholder-Manager" + + anlass: + - "Komplexer Bedarf, der nicht im Turnus-Gespräch vollständig erfasst werden kann" + - "Strategisch bedeutsamer Bedarf mit hohem Investitionsvolumen" + - "Bedarf mit unklarem Problemkern (Symptom vs. Ursache)" + + frequenz: + empfehlung: "Anlassbezogen" + + typische_inhalte: + - block: "Problemverständnis" + beschreibung: "Was ist das eigentliche Problem? Symptome vs. Ursachen" + - block: "Kontext und Auswirkungen" + beschreibung: "Wer ist betroffen? Was sind die Konsequenzen?" + - block: "Zielbild" + beschreibung: "Wie sieht der gewünschte Zielzustand aus?" + - block: "Lösungsoptionen (grob)" + beschreibung: | + Welche Lösungsrichtungen sieht der Kunde? + (Hinweis: SHM bewertet nicht technisch, nimmt aber auf) + - block: "Nächste Schritte" + beschreibung: "Routing-Empfehlung, weitere Klärungsbedarfe" + + output: + dokumentation: "Erweiterter Bedarfssteckbrief" + follow_up: "Routing an DSR (Change vs. Demand)" + + template_bedarf: + - "Workshop-Leitfaden Bedarfs-Vertiefung" + - "Erweiterter Bedarfssteckbrief (Vorlage)" + + abgrenzung: | + Unterscheidet sich von SF-01 durch Fokus auf einen konkreten Bedarf + statt auf die Gesamtstrategie des Amtes. + +# ============================================================================= +# KOLLEKTIVE FORMATE (KF) +# ============================================================================= + +kollektive_formate: + + beschreibung: | + Kollektive Formate adressieren mehrere Stakeholder gleichzeitig. + Sie sind ressourceneffizient und ermöglichen Informationsaustausch + zwischen Ämtern. + + DESIGNENTSCHEIDUNG: Die kollektiven Formate des SHM sind mit den + Auftraggeber-Vertretungen des SLM (P-02) zu einem integrierten + "Auftraggeber-Forum"-Konzept konsolidiert. Dies vermeidet Gremien-Redundanz + und stärkt die "One DIGIT"-Wahrnehmung. + + governance_referenz: "GOV-SHM-015" + + integriertes_auftraggeber_forum: + + beschreibung: | + Das Auftraggeber-Forum ist das zentrale kollektive Interaktionsformat + zwischen DIGIT und seinen Auftraggebern. Es vereint die Funktionen der + ehemaligen SHM-Advisory-Boards und der SLM-Auftraggeber-Vertretungen. + + formate: + + # ----------------------------------------------------------------------- + # KF-01: Auftraggeber-Forum Basisservices + # ----------------------------------------------------------------------- + + - id: "KF-01" + name: "Auftraggeber-Forum Basisservices" + + zweck: | + Integriertes Forum für Ämter zur Abstimmung von Basis-Services + (Kategorie A), Informationsaustausch, Feedback-Sammlung und + Bedarfsidentifikation. Kombiniert SLA-Review-Funktion (SLM) + mit Beziehungspflege-Funktion (SHM). + + zielgruppe: + betreuungsmodus: "Standard, Basis (primär), Aktiv (optional)" + teilnehmer_auftraggeber: | + - Pflichtvertreter: Amtsleitungen strategischer Querschnittsämter + - Weitere Vertreter: Rotation/Wahl aus Fachämtern + - Alle Teilnehmer müssen Entscheidungsbefugnis haben oder + diese dokumentiert delegiert bekommen haben + teilnehmer_digit: + - rolle: "Service Owner (Basis-Services)" + verantwortung: "SLA-bezogene Themen, Service-Performance" + - rolle: "Stakeholder-Manager" + verantwortung: "Beziehungsthemen, Feedback-Moderation, Bedarfssammlung" + - rolle: "SPM (optional)" + verantwortung: "Governance-Konformität, Portfolio-Perspektive" + + frequenz: + empfehlung: "Jährlich" + hinweis: | + Die Frequenz ist im Rahmen der Pilotierung zu validieren + und zu verproben. Bei Bedarf kann auf halbjährlich erhöht werden. + referenz_annahme: "ANNAHME-EF-001" + + typische_inhalte: + - block: "SLA-Review Basis-Services" + verantwortung: "Service Owner" + beschreibung: | + Performance-Bericht, Zielerreichung, geplante Änderungen + dauer_anteil: "30%" + - block: "DIGIT-Update" + verantwortung: "Stakeholder-Manager / SPM" + beschreibung: | + Strategische Entwicklungen, neue Services, Roadmap + dauer_anteil: "20%" + - block: "Feedback-Runde" + verantwortung: "Stakeholder-Manager" + beschreibung: | + Strukturierte Sammlung: Was läuft gut? Wo gibt es Probleme? + dauer_anteil: "25%" + - block: "Bedarfs-Sammlung" + verantwortung: "Stakeholder-Manager" + beschreibung: | + Gemeinsame Bedarfe? Themen für mehrere Ämter? + dauer_anteil: "15%" + - block: "Ausblick / Vereinbarungen" + verantwortung: "Gemeinsam" + beschreibung: "Nächste Schritte, offene Punkte" + dauer_anteil: "10%" + + voraussetzungen: + informationen: + - "SLA-Performance-Daten der Basis-Services" + - "Service-Portfolio-Update" + - "Bekannte Probleme/Feedback" + vorbereitung: + - "Einladung mit Agenda mind. 4 Wochen vorher" + - "Möglichkeit zur Themenanmeldung durch Teilnehmer" + - "Abstimmung SO/SHM zur Agenda-Aufteilung" + + output: + dokumentation: "Protokoll mit SLA-Review-Ergebnis, Feedback, Bedarfen" + follow_up: + - "SLA-Änderungen werden in SLM-Prozess überführt" + - "Feedback wird an relevante Stellen weitergeleitet (SO, SPM)" + - "Gemeinsame Bedarfe werden ggf. in Thematisches Format überführt" + + governance_hinweis: | + Das Auftraggeber-Forum hat für SLA-Themen Entscheidungskompetenz + (Konsensprinzip, bei Dissens qualifizierte Mehrheit). + Für Bedarfe gilt: Beratende Funktion, Entscheidung über + etablierte Governance (SOR, DSR, MB). + + template_bedarf: + - "Einladungs-Vorlage Auftraggeber-Forum" + - "Agenda-Vorlage (integriert SLA + SHM)" + - "Protokoll-Vorlage" + + schnittstelle_slm: | + Das Auftraggeber-Forum erfüllt die Funktion der "Auftraggeber-Vertretung + Basisservices" gemäß P-02 Service Level Management. + Die SLA-Review-Aktivität (slm_09) wird im Rahmen des + Auftraggeber-Forums durchgeführt. + + # ----------------------------------------------------------------------- + # KF-02: Auftraggeber-Forum [Service] (für Kategorie B) + # ----------------------------------------------------------------------- + + - id: "KF-02" + name: "Auftraggeber-Forum [Servicename]" + + zweck: | + Service-spezifisches Forum für Nutzer eines Kategorie-B-Services. + Primär SLA-Review und Service-Roadmap, ergänzt um Bedarfssammlung. + + zielgruppe: + betreuungsmodus: "Alle nutzenden Ämter des Services" + teilnehmer_auftraggeber: | + Amtsleitungen der nutzenden Ämter oder delegierte Vertreter + mit dokumentierter Entscheidungsbefugnis + teilnehmer_digit: + - rolle: "Service Owner" + verantwortung: "Leitung, SLA-Themen, Roadmap" + - rolle: "Stakeholder-Manager (optional)" + verantwortung: "Bei Beziehungsthemen oder komplexen Bedarfen" + + frequenz: + empfehlung: "Jährlich (SLA-Review) + bei Bedarf" + referenz_annahme: "ANNAHME-EF-001" + + typische_inhalte: + - block: "SLA-Review" + beschreibung: "Performance, Zielerreichung, Anpassungsbedarf" + - block: "Service-Roadmap" + beschreibung: "Geplante Änderungen, Erweiterungen" + - block: "Bedarfssammlung" + beschreibung: "Wünsche, Anforderungen der Nutzer" + + output: + dokumentation: "Protokoll mit SLA-Review, Roadmap-Feedback, Bedarfen" + + schnittstelle_slm: | + Erfüllt die Funktion der "Auftraggeber-Vertretung [Servicename]" + gemäß P-02 Service Level Management. + + shm_beteiligung: | + SHM-Beteiligung ist optional und erfolgt bei: + - Beziehungsproblemen mit nutzenden Ämtern + - Komplexen übergreifenden Bedarfen + - Key-Stakeholdern unter den Nutzern + + # --------------------------------------------------------------------------- + # KF-03: Basis-Puls-Check (NEU) + # --------------------------------------------------------------------------- + + basis_puls_check: + + id: "KF-03" + name: "Basis-Puls-Check" + + zweck: | + Minimal-invasives proaktives Format für Basis-Stakeholder, die + keine individuelle Betreuung erhalten und ggf. nicht am Auftraggeber-Forum + teilnehmen. Verhindert "Silent Churn" – das unbemerkte Abdriften + von Stakeholdern ohne explizite Beschwerden. + + zielgruppe: + betreuungsmodus: "Basis (Reaktiv)" + adressaten: "Alle Basis-Stakeholder, die nicht am Auftraggeber-Forum teilnehmen" + + frequenz: + empfehlung: "Jährlich" + zeitpunkt: "Versetzt zum Auftraggeber-Forum (z.B. 6 Monate danach)" + referenz_annahme: "ANNAHME-EF-001" + + format: + typ: "Automatisierte Kurzumfrage / strukturiertes Mailing" + aufwand_shm: "Minimal (Versand + Auswertung)" + aufwand_kunde: "5-10 Minuten" + + inhalte: + - frage: "Allgemeine Zufriedenheit" + typ: "Skala 1-5" + beschreibung: "Wie zufrieden sind Sie insgesamt mit den IT-Services?" + - frage: "Größte Herausforderung" + typ: "Freitext (optional)" + beschreibung: "Was ist aktuell Ihre größte IT-bezogene Herausforderung?" + - frage: "Bedarfsmeldung" + typ: "Ja/Nein + Freitext" + beschreibung: "Gibt es Bedarfe, die Sie uns mitteilen möchten?" + - frage: "Gesprächswunsch" + typ: "Ja/Nein" + beschreibung: "Wünschen Sie ein persönliches Gespräch mit uns?" + + auswertung: + verantwortung: "Stakeholder-Manager" + vorgehen: + - "Aggregierte Auswertung der Zufriedenheitswerte" + - "Identifikation von Ämtern mit niedriger Zufriedenheit" + - "Priorisierung von Gesprächswünschen" + - "Sammlung und Kategorisierung von Bedarfen" + + trigger_fuer_intervention: + - bedingung: "Zufriedenheit ≤ 2" + aktion: "Proaktive Kontaktaufnahme durch SHM" + - bedingung: "Gesprächswunsch = Ja" + aktion: "Terminvereinbarung innerhalb 2 Wochen" + - bedingung: "Konkreter Bedarf genannt" + aktion: "Bedarfssteckbrief erstellen, Routing prüfen" + + output: + dokumentation: "Aggregierter Puls-Check-Bericht" + berichterstattung: "Zusammenfassung im SHM-Performance-Review" + + template_bedarf: + - "Puls-Check Fragebogen (digital)" + - "Auswertungs-Template" + - "Anschreiben-Vorlage" + + abgrenzung: | + Der Puls-Check ersetzt keine individuelle Betreuung. Er ist ein + "Frühwarnsystem" für Basis-Stakeholder und ermöglicht es, + Probleme zu erkennen, bevor sie eskalieren. + +# ============================================================================= +# THEMATISCHE FORMATE (ThF) +# ============================================================================= + +thematische_formate: + + beschreibung: | + Thematische Formate sind anlassbezogen und adressieren übergreifende + Bedarfe, die mehrere Ämter unabhängig von ihrer Cluster-Zugehörigkeit + betreffen. Sie dienen der Bedarfskonsolidierung vor DPM-Übergabe. + + formate: + + # ------------------------------------------------------------------------- + # ThF-01: Bedarfs-Konsolidierungs-Workshop + # ------------------------------------------------------------------------- + + - id: "ThF-01" + name: "Bedarfs-Konsolidierungs-Workshop" + + zweck: | + Zusammenführung von Ämtern mit ähnlichem Bedarf zur gemeinsamen + Bedarfsdefinition. Stellt Demand auf breitere Basis, erhöht + Priorisierungschancen und vermeidet Parallelentwicklungen. + + zielgruppe: + betreuungsmodus: "Alle (bedarfsgetrieben)" + teilnehmer_auftraggeber: | + Vertreter der Ämter mit gleichem/ähnlichem Bedarf. + Typisch 3-8 Teilnehmer. + teilnehmer_shm: "Stakeholder-Manager (Moderation)" + + anlass: + - "SHM erkennt gleichartigen Bedarf bei mehreren Ämtern" + - "Amt meldet Bedarf, der vermutlich auch andere betrifft" + - "Proaktive Identifikation durch Cluster-Advisory-Board" + + frequenz: + empfehlung: "Anlassbezogen" + hinweis: "Wird durch SHM initiiert, wenn Konsolidierungspotenzial erkannt wird" + + typische_inhalte: + - block: "Bedarfs-Vorstellung" + beschreibung: "Jedes Amt stellt seinen Bedarf/sein Problem vor" + - block: "Gemeinsamkeiten und Unterschiede" + beschreibung: "Was ist der gemeinsame Kern? Wo gibt es Spezifika?" + - block: "Konsolidierter Bedarf" + beschreibung: "Erarbeitung einer gemeinsamen Bedarfsbeschreibung" + - block: "Governance und nächste Schritte" + beschreibung: | + Wer vertritt den konsolidierten Bedarf? + Wie geht es weiter (SOR, DPM)? + + output: + dokumentation: "Konsolidierter Bedarfssteckbrief" + follow_up: | + - Routing an SOR mit Hinweis auf Bedarfs-Gemeinschaft + - Benennung eines Sprechers für die Bedarfs-Gemeinschaft + + template_bedarf: + - "Workshop-Leitfaden Bedarfs-Konsolidierung" + - "Bedarfssteckbrief (erweitert um Bedarfs-Gemeinschaft)" + + schnittstelle_dpm: | + Der konsolidierte Bedarf wird mit Information zur Bedarfs-Gemeinschaft + an DPM übergeben. Details zur Übergabe werden in Phase 5 + (D2P-Integration) spezifiziert. + +# ============================================================================= +# REAKTIVE FORMATE (RF) – PLACEHOLDER +# ============================================================================= + +reaktive_formate: + + beschreibung: | + Reaktive Formate regeln den Umgang mit ungeplanten Interaktionen: + Anfragen, Beschwerden, Eskalationen. Sie definieren, wann SHM + selbst reagiert, wann weitergeleitet wird, und wie eskaliert wird. + + Grundprinzip: SHM agiert als "Auftraggeber-Anwalt" – bei Key-Stakeholdern + bleibt SHM auch nach Weiterleitung aktiv involviert bis zur Lösung. + + # =========================================================================== + # TRIAGE + # =========================================================================== + + triage: + + verantwortung: "Stakeholder-Manager" + + beschreibung: | + Jede eingehende Eskalation wird durch den Stakeholder-Manager + initial kategorisiert (Triage). Die Kategorie bestimmt den + Eskalationspfad. + + ablauf: + - schritt: 1 + aktion: "Eingang erfassen" + beschreibung: "Eskalation wird dokumentiert (Absender, Thema, Dringlichkeit)" + - schritt: 2 + aktion: "Stakeholder-Priorität prüfen" + beschreibung: "Key / Aktiv / Standard / Basis – beeinflusst Pfad und Reaktionszeit" + - schritt: 3 + aktion: "Trigger-Kategorie bestimmen" + beschreibung: "Zuordnung zu Kategorie A-E" + - schritt: 4 + aktion: "Pfad einleiten" + beschreibung: "Weiterleitung oder Eigenbearbeitung gemäß Pfad-Definition" + + # =========================================================================== + # TRIGGER-KATEGORIEN + # =========================================================================== + + trigger_kategorien: + + - id: "TRIG-A" + name: "Service-bezogene Beschwerde" + beschreibung: | + Kunde ist unzufrieden mit einem konkreten Service, meldet + wiederholte Probleme oder SLA-Verletzungen. + beispiele: + - "E-Mail-System funktioniert seit Tagen nicht richtig" + - "Zugesagte Reaktionszeit wird nie eingehalten" + - "Software XY stürzt ständig ab" + primaer_zustaendig: "Service Owner" + shm_rolle: "Weiterleitung, bei Key-Stakeholdern aktive Begleitung" + + - id: "TRIG-B" + name: "Prozess-bezogene Beschwerde" + beschreibung: | + Bedarf/Demand wird nicht bearbeitet, Entscheidung ist unklar, + Prozess dauert zu lange. + beispiele: + - "Unser Demand liegt seit 6 Monaten ohne Rückmeldung" + - "Warum wurde unser Antrag abgelehnt?" + - "Niemand fühlt sich zuständig" + primaer_zustaendig: "DPM oder SPM (je nach Thema)" + shm_rolle: "Weiterleitung mit Nachverfolgung, Kundeninteresse vertreten" + + - id: "TRIG-C" + name: "Beziehungs-bezogene Beschwerde" + beschreibung: | + Allgemeine Unzufriedenheit, Vertrauensverlust, + Kommunikationsprobleme, Konflikte mit DIGIT-Mitarbeitern. + beispiele: + - "Wir fühlen uns von DIGIT nicht ernst genommen" + - "Die Kommunikation ist katastrophal" + - "Mit Herrn X kann man nicht zusammenarbeiten" + primaer_zustaendig: "SHM" + shm_rolle: "Eigenbearbeitung, Mediation, Beziehungsklärung" + + - id: "TRIG-D" + name: "Governance-Konflikt" + beschreibung: | + Kunde akzeptiert Gremienentscheidung nicht, Priorisierungskonflikt, + Zuständigkeitskonflikt. + beispiele: + - "Warum wurde das Amt X priorisiert und wir nicht?" + - "Die DSR-Entscheidung ist nicht nachvollziehbar" + - "Wer ist eigentlich für dieses Thema verantwortlich?" + primaer_zustaendig: "SOR / DSR / MB (je nach Thema)" + shm_rolle: "Vorbereitung Gremienweg, Kundenposition vertreten" + + - id: "TRIG-E" + name: "Politische/Strategische Eskalation" + beschreibung: | + Kunde droht mit politischer Eskalation, Thema hat politische + Brisanz, Reputationsrisiko für DIGIT. + beispiele: + - "Ich werde das dem Dezernenten melden" + - "Das wird im Gemeinderat Thema werden" + - "Die Presse wird sich dafür interessieren" + primaer_zustaendig: "Mission Board" + shm_rolle: "Direkte Eskalation an MB, ggf. vorab Abstimmung mit DIGIT-Amtsleitung" + + # =========================================================================== + # ESKALATIONSPFADE + # =========================================================================== + + eskalationspfade: + + beschreibung: | + Jede Trigger-Kategorie hat einen definierten Eskalationspfad. + Der Pfad wird durch die Stakeholder-Priorität modifiziert: + - Key-Stakeholder: Schnellerer Pfad, SHM bleibt aktiv involviert + - Andere: Standard-Pfad, SHM leitet weiter und verfolgt nach + + # ------------------------------------------------------------------------- + # PFAD A: Service-bezogene Beschwerde + # ------------------------------------------------------------------------- + + pfad_a: + trigger: "TRIG-A" + name: "Service-Eskalationspfad" + + standard_ablauf: + - stufe: 1 + akteur: "Service Owner" + aktion: | + SHM leitet Beschwerde an zuständigen Service Owner weiter. + SO klärt mit Kunde und behebt Problem. + eskalation_wenn: "SO kann nicht lösen oder Kunde bleibt unzufrieden" + + - stufe: 2 + akteur: "SPM (Funktion)" + aktion: | + SPM prüft systemische Ursachen, ggf. Service-Review. + eskalation_wenn: "Grundsätzliches Service-Problem oder Governance-Frage" + + - stufe: 3 + akteur: "Mission Board" + aktion: | + MB entscheidet über grundsätzliche Maßnahmen + (Service-Änderung, Ressourcen, Priorisierung). + + modifikation_key_stakeholder: + beschreibung: | + Bei Key-Stakeholdern bleibt SHM aktiv involviert: + - SHM informiert SO über Stakeholder-Priorität + - SHM bleibt in Kommunikation mit Kunde (nicht nur SO) + - SHM eskaliert proaktiv, wenn Lösung nicht zeitnah erfolgt + schnellerer_pfad: | + Bei anhaltender Unzufriedenheit kann SHM direkt Stufe 2 + einschalten, ohne auf SO-Rückmeldung zu warten. + + # ------------------------------------------------------------------------- + # PFAD B: Prozess-bezogene Beschwerde + # ------------------------------------------------------------------------- + + pfad_b: + trigger: "TRIG-B" + name: "Prozess-Eskalationspfad" + + differenzierung: + - wenn: "Beschwerde betrifft Demand-Prozess" + dann: "Weiterleitung an DPM" + - wenn: "Beschwerde betrifft Service-Änderung/Change" + dann: "Weiterleitung an SPM / Service Owner" + - wenn: "Unklar" + dann: "SOR zur Klärung" + + standard_ablauf: + - stufe: 1 + akteur: "DPM oder SPM (je nach Thema)" + aktion: | + Zuständige Funktion prüft Status, klärt mit Kunde, + gibt Rückmeldung zu Zeitrahmen/Entscheidung. + eskalation_wenn: "Kunde akzeptiert Erklärung nicht oder Prozess ist blockiert" + + - stufe: 2 + akteur: "DSR (bei Demand) oder SOR (bei Service)" + aktion: | + Gremium prüft Priorisierung, ggf. Neubewertung. + eskalation_wenn: "Grundsätzlicher Priorisierungskonflikt" + + - stufe: 3 + akteur: "Mission Board" + aktion: | + MB entscheidet über Ressourcenallokation oder + grundsätzliche Prozessanpassung. + + modifikation_key_stakeholder: + beschreibung: | + SHM vertritt Kundeninteresse aktiv im Prozess: + - SHM fragt proaktiv Status nach + - SHM bereitet ggf. Gremienvorlage mit vor + - SHM kommuniziert Zwischenstände an Kunde + + # ------------------------------------------------------------------------- + # PFAD C: Beziehungs-bezogene Beschwerde + # ------------------------------------------------------------------------- + + pfad_c: + trigger: "TRIG-C" + name: "Beziehungs-Eskalationspfad" + + beschreibung: | + Beziehungsthemen werden primär durch SHM selbst bearbeitet. + SHM agiert als Mediator und Beziehungsmanager. + + standard_ablauf: + - stufe: 1 + akteur: "Stakeholder-Manager" + aktion: | + SHM führt klärendes Gespräch mit Kunde. + Ursachenanalyse: Was ist der Kern der Unzufriedenheit? + Ggf. Vermittlung zwischen Kunde und DIGIT-Mitarbeiter. + eskalation_wenn: "Konflikt nicht lösbar oder strukturelles Problem" + + - stufe: 2 + akteur: "SHM + DIGIT-Amtsleitung" + aktion: | + SHM stimmt sich mit DIGIT-Amtsleitung ab. + Ggf. gemeinsames Gespräch mit Kunde auf Leitungsebene. + eskalation_wenn: "Amtsleiter-Gespräch löst nicht oder strategische Dimension" + + - stufe: 3 + akteur: "Mission Board" + aktion: | + MB wird informiert, entscheidet über weitere Maßnahmen. + + modifikation_key_stakeholder: + beschreibung: | + Bei Key-Stakeholdern höhere Aufmerksamkeit: + - Schnellere Reaktion + - Frühzeitige Einbindung DIGIT-Amtsleitung + - Proaktive Nachverfolgung der Beziehungsqualität + + # ------------------------------------------------------------------------- + # PFAD D: Governance-Konflikt + # ------------------------------------------------------------------------- + + pfad_d: + trigger: "TRIG-D" + name: "Governance-Eskalationspfad" + + differenzierung: + - wenn: "Konflikt betrifft Service/Demand-Routing" + dann: "SOR" + - wenn: "Konflikt betrifft Demand-Priorisierung" + dann: "DSR" + - wenn: "Konflikt betrifft übergreifende Governance" + dann: "Mission Board" + + standard_ablauf: + - stufe: 1 + akteur: "Zuständiges Gremium (SOR/DSR)" + aktion: | + SHM bringt Konflikt ins zuständige Gremium ein. + Gremium prüft und entscheidet. + eskalation_wenn: "Gremium kann nicht entscheiden oder Kunde akzeptiert nicht" + + - stufe: 2 + akteur: "Mission Board" + aktion: | + MB als höchste Eskalationsstufe entscheidet final. + + shm_rolle: | + SHM bereitet Gremienvorlage vor, vertritt Kundenperspektive + im Gremium, kommuniziert Entscheidung und Begründung an Kunden. + + # ------------------------------------------------------------------------- + # PFAD E: Politische/Strategische Eskalation + # ------------------------------------------------------------------------- + + pfad_e: + trigger: "TRIG-E" + name: "Politischer Eskalationspfad" + + beschreibung: | + Bei politischer Brisanz wird direkt an höchste Ebene eskaliert. + Keine Zwischenstufen – Zeit- und Reputationsrisiko zu hoch. + + ablauf: + - stufe: 1 + akteur: "SHM + DIGIT-Amtsleitung" + aktion: | + SHM informiert umgehend DIGIT-Amtsleitung. + Gemeinsame Lageeinschätzung: Wie ernst ist die Drohung? + Abstimmung der Reaktionsstrategie. + zeitrahmen: "Innerhalb von Stunden, nicht Tagen" + + - stufe: 2 + akteur: "Mission Board (ggf. ad-hoc)" + aktion: | + MB wird informiert, ggf. ad-hoc-Sitzung. + Entscheidung über Reaktion und Kommunikation. + + hinweis: | + Bei politischen Eskalationen ist die Stakeholder-Priorität + sekundär – die Brisanz des Themas bestimmt den Pfad. + + # =========================================================================== + # REAKTIONSZEITEN (QUALITATIV) + # =========================================================================== + + reaktionszeiten: + + beschreibung: | + Reaktionszeiten sind qualitativ definiert und differenzieren + nach Stakeholder-Priorität und Trigger-Kategorie. + Konkrete SLA-Zeiten werden im Rahmen der Pilotierung festgelegt. + + referenz_annahme: "ANNAHME-EF-001" + + matrix: + + - trigger: "TRIG-E (Politisch)" + stakeholder_alle: + erstreaktion: "Sofort (innerhalb Stunden)" + beschreibung: "Priorität übersteuert alle anderen Kategorien" + + - trigger: "TRIG-A bis TRIG-D" + stakeholder_key: + erstreaktion: "Zeitnah (innerhalb 1 Arbeitstag)" + nachverfolgung: "Aktiv, proaktive Updates an Kunde" + beschreibung: "Höchste Priorität nach politischen Eskalationen" + + stakeholder_aktiv: + erstreaktion: "Kurzfristig (innerhalb 2 Arbeitstage)" + nachverfolgung: "Regelmäßig, auf Anfrage" + beschreibung: "Priorisierte Bearbeitung" + + stakeholder_standard: + erstreaktion: "Normal (innerhalb 1 Woche)" + nachverfolgung: "Nach Abschluss relevanter Schritte" + beschreibung: "Standardbearbeitung" + + stakeholder_basis: + erstreaktion: "Normal (innerhalb 1 Woche)" + nachverfolgung: "Nur bei expliziter Nachfrage" + beschreibung: "Reaktive Bearbeitung" + + # =========================================================================== + # SHM-ROLLENVERSTÄNDNIS BEI ESKALATIONEN + # =========================================================================== + + shm_rollenverstaendnis: + + grundprinzip: "Auftraggeber-Anwalt" + + beschreibung: | + SHM agiert bei Eskalationen als "Anwalt des Auftraggebers" – nicht als + neutraler Vermittler, sondern als Vertreter der Auftraggeber-Perspektive + innerhalb von DIGIT. Dabei bleibt SHM sachlich und lösungsorientiert. + + differenzierung_nach_prioritaet: + + key_stakeholder: + involvierung: "Aktiv durchgängig" + beschreibung: | + SHM bleibt bis zur Lösung aktiv involviert, auch wenn + das Thema an andere Funktionen weitergeleitet wurde. + SHM kommuniziert proaktiv mit dem Auftraggeber. + + aktiv_stakeholder: + involvierung: "Begleitend" + beschreibung: | + SHM leitet weiter, verfolgt nach und ist Ansprechpartner + für den Kunden bei Rückfragen. + + standard_basis_stakeholder: + involvierung: "Punktuell" + beschreibung: | + SHM leitet weiter und dokumentiert. Weitere Involvierung + nur bei expliziter Kundenanfrage oder wenn Thema eskaliert. + + grenzen: + - | + SHM vertritt Kundenperspektive, aber akzeptiert Gremienentscheidungen. + SHM erklärt dem Auftraggeber die Entscheidung, auch wenn sie nicht im + Kundensinne ist. + - | + SHM übernimmt keine operative Problemlösung (das ist SO/Service Desk). + SHM sorgt dafür, dass das Problem an der richtigen Stelle bearbeitet wird. + + # =========================================================================== + # DOKUMENTATION UND NACHVERFOLGUNG + # =========================================================================== + + dokumentation: + + beschreibung: | + Jede Eskalation wird dokumentiert, um Nachverfolgung zu ermöglichen + und Muster zu erkennen. + + zu_dokumentieren: + - "Datum und Eingangskanal" + - "Absender (Amt, Person)" + - "Stakeholder-Priorität" + - "Trigger-Kategorie" + - "Kurzbeschreibung des Themas" + - "Eingeleiteter Pfad" + - "Status und Verlauf" + - "Abschluss und Ergebnis" + + ablageort: "SIMS (Stakeholder-Informations-Management-System)" + + auswertung: | + Aggregierte Auswertung der Eskalationen (Häufigkeit, Kategorien, + Durchlaufzeiten) fließt in die Koordinations- und Steuerungsstruktur + (shm_koordinations-und-steuerungsstruktur.yaml) ein. + +# ============================================================================= +# FREQUENZ-MATRIX: BETREUUNGSMODUS → FORMATE +# ============================================================================= + +frequenz_matrix: + + beschreibung: | + Übersicht, welche Formate für welchen Betreuungsmodus vorgesehen sind + und in welcher Frequenz. + + referenz_annahme: "ANNAHME-EF-001" + + matrix: + + - betreuungsmodus: "Key (Proaktiv/Dediziert)" + turnus_formate: + - format: "TF-01 Strategisches Turnus-Gespräch" + frequenz: "Quartalsweise" + strategische_formate: + - format: "SF-01 Digitalisierungs-Strategie-Workshop" + frequenz: "Alle 1-2 Jahre (anlassbezogen)" + - format: "SF-02 Bedarfs-Vertiefungs-Workshop" + frequenz: "Anlassbezogen" + kollektive_formate: + - format: "KF-01 Auftraggeber-Forum Basisservices" + frequenz: "Optional (primär für Standard/Basis)" + - format: "KF-02 Auftraggeber-Forum [Service]" + frequenz: "Bei Nutzung von Kat-B-Services" + thematische_formate: + - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" + frequenz: "Anlassbezogen" + reaktive_formate: "Ja (Details s. RF)" + + - betreuungsmodus: "Aktiv (Regelmäßig)" + turnus_formate: + - format: "TF-02 Operatives Turnus-Gespräch" + frequenz: "Halbjährlich" + strategische_formate: "Nicht vorgesehen (bei Bedarf Upgrade auf Key prüfen)" + kollektive_formate: + - format: "KF-01 Auftraggeber-Forum Basisservices" + frequenz: "Optional, zusätzlich zu Turnus" + - format: "KF-02 Auftraggeber-Forum [Service]" + frequenz: "Bei Nutzung von Kat-B-Services" + thematische_formate: + - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" + frequenz: "Anlassbezogen" + reaktive_formate: "Ja (Details s. RF)" + + - betreuungsmodus: "Standard (Eingebunden)" + turnus_formate: "Nicht vorgesehen" + strategische_formate: "Nicht vorgesehen" + kollektive_formate: + - format: "KF-01 Auftraggeber-Forum Basisservices" + frequenz: "Jährlich" + thematische_formate: + - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" + frequenz: "Anlassbezogen" + proaktive_formate: + - format: "KF-03 Basis-Puls-Check" + frequenz: "Nicht vorgesehen (Puls-Check nur für Basis)" + reaktive_formate: "Ja (Details s. RF)" + + - betreuungsmodus: "Basis (Reaktiv)" + turnus_formate: "Nicht vorgesehen" + strategische_formate: "Nicht vorgesehen" + kollektive_formate: + - format: "KF-01 Auftraggeber-Forum Basisservices" + frequenz: "Jährlich (Einladung, Teilnahme optional)" + thematische_formate: + - format: "ThF-01 Bedarfs-Konsolidierungs-Workshop" + frequenz: "Anlassbezogen (wenn Bedarf erkannt)" + proaktive_formate: + - format: "KF-03 Basis-Puls-Check" + frequenz: "Jährlich" + reaktive_formate: "Ja (Details s. RF)" + +# ============================================================================= +# BEZIEHUNGSQUALITÄTSSICHERUNG +# ============================================================================= + +beziehungsqualitaetssicherung: + + beschreibung: | + Die Beziehungsqualitätssicherung ermöglicht die systematische Erfassung + und Bewertung der Kundenbeziehungen sowie die frühzeitige Erkennung + von Problemen. Sie unterstützt die Kernentscheidung EF-E3: + "Woran erkenne ich Beziehungsprobleme, wann interveniere ich?" + + grundprinzip: | + SHM gibt eine Einschätzung für alle Ämter im Portfolio – nicht nur + für aktiv betreute. Die Erfassungstiefe und -frequenz variiert + nach Betreuungsmodus. + + # =========================================================================== + # BEWERTUNGSSKALA + # =========================================================================== + + bewertungsskala: + + beschreibung: | + Die Beziehungsqualität wird auf einer 4-Stufen-Skala bewertet. + Die Stufen sind qualitativ definiert und ermöglichen eine + differenzierte Einschätzung ohne Pseudo-Präzision. + + stufen: + + - stufe: "Exzellent" + kuerzel: "EX" + beschreibung: | + Vertrauensvolle, partnerschaftliche Beziehung. Kunde ist + sehr zufrieden, kommuniziert offen, bringt sich aktiv ein. + Keine offenen Konflikte oder Irritationen. + indikatoren: + - "Kunde äußert aktiv Zufriedenheit" + - "Konstruktive, offene Kommunikation" + - "Kunde empfiehlt DIGIT-Leistungen weiter" + - "Proaktive Beteiligung an Formaten" + + - stufe: "Gut" + kuerzel: "GU" + beschreibung: | + Stabile, funktionale Beziehung. Kunde ist grundsätzlich + zufrieden, Zusammenarbeit läuft ohne größere Probleme. + Punktuelle Kritik wird konstruktiv geäußert. + indikatoren: + - "Regelkommunikation funktioniert" + - "Kritik wird sachlich vorgebracht" + - "Termine werden eingehalten" + - "Keine Eskalationen" + + - stufe: "Angespannt" + kuerzel: "AN" + beschreibung: | + Beziehung zeigt Belastungszeichen. Kunde äußert Unzufriedenheit, + Kommunikation ist erschwert, es gibt offene Themen oder + ungelöste Konflikte. Intervention empfohlen. + indikatoren: + - "Wiederholte Kritik oder Beschwerden" + - "Kommunikation wird förmlicher oder distanzierter" + - "Termine werden verschoben oder abgesagt" + - "Offene Konflikte oder ungelöste Themen" + + - stufe: "Kritisch" + kuerzel: "KR" + beschreibung: | + Beziehung ist ernsthaft gefährdet. Massiver Vertrauensverlust, + Kommunikationsabbruch, Eskalationsdrohungen. + Sofortige Intervention erforderlich. + indikatoren: + - "Kunde verweigert Kommunikation oder Kooperation" + - "Eskalation an höhere Ebenen (Dezernent, Politik)" + - "Öffentliche Kritik oder Beschwerden" + - "Grundsätzliche Infragestellung der Zusammenarbeit" + + # =========================================================================== + # INDIKATOR-KATEGORIEN + # =========================================================================== + + indikator_kategorien: + + beschreibung: | + Die Bewertung der Beziehungsqualität speist sich aus drei + Indikator-Kategorien, die je nach Betreuungsmodus unterschiedlich + gewichtet werden. + + kategorien: + + - id: "IND-1" + name: "Direkte Einschätzung" + typ: "Subjektiv, durch SHM" + beschreibung: | + Der Stakeholder-Manager schätzt die Beziehungsqualität auf + Basis seiner Interaktionen und Wahrnehmungen ein. + basis: + - "Gesprächseindrücke (Tonalität, Offenheit)" + - "Kooperationsbereitschaft" + - "Allgemeine Stimmung in der Zusammenarbeit" + anwendung: "Alle Betreuungsmodi" + erfassung: "Nach Interaktionen, mindestens jährlich" + + - id: "IND-2" + name: "Interaktions-Signale" + typ: "Beobachtbar, prozessbasiert" + beschreibung: | + Objektiv beobachtbare Signale aus den Interaktionen und + Prozessen, die auf Beziehungsqualität hinweisen. + signale: + - signal: "Eskalationen" + positiv: "Keine Eskalationen" + negativ: "Häufige oder wiederkehrende Eskalationen" + - signal: "Beschwerden" + positiv: "Keine oder konstruktive Kritik" + negativ: "Beziehungs-bezogene Beschwerden (TRIG-C)" + - signal: "Teilnahme" + positiv: "Regelmäßige Teilnahme an Formaten" + negativ: "Wiederholtes Absagen oder Fernbleiben" + - signal: "Reaktionsverhalten" + positiv: "Zeitnahe Antworten, Termintreue" + negativ: "Keine Reaktion, verschobene Termine" + anwendung: "Alle Betreuungsmodi (soweit Daten anfallen)" + erfassung: "Kontinuierlich, bei Auftreten" + + - id: "IND-3" + name: "Strukturiertes Feedback" + typ: "Explizit erhoben" + beschreibung: | + Gezielte Abfrage der Kundenzufriedenheit und + Beziehungswahrnehmung beim Kunden selbst. + methoden: + - "Zufriedenheits-Check im Turnus-Gespräch" + - "Strukturierte Feedback-Fragen" + - "Ggf. kurze schriftliche Abfrage" + anwendung: "Key-Stakeholder" + erfassung: "Jährlich (im Rahmen eines Turnus-Gesprächs)" + + # =========================================================================== + # ERFASSUNG NACH BETREUUNGSMODUS + # =========================================================================== + + erfassung_nach_betreuungsmodus: + + beschreibung: | + Die Erfassungstiefe und -frequenz variiert nach Betreuungsmodus. + Für alle Ämter wird mindestens jährlich eine Einschätzung abgegeben. + + matrix: + + - betreuungsmodus: "Key (Proaktiv/Dediziert)" + indikator_kategorien: + - kategorie: "IND-1 (Direkte Einschätzung)" + anwendung: "Ja" + frequenz: "Nach jedem Turnus-Gespräch (quartalsweise)" + - kategorie: "IND-2 (Interaktions-Signale)" + anwendung: "Ja" + frequenz: "Kontinuierlich, systematische Auswertung" + - kategorie: "IND-3 (Strukturiertes Feedback)" + anwendung: "Ja" + frequenz: "Jährlich" + gesamtbewertung: "Quartalsweise aktualisiert" + trigger_sensitivitaet: "Hoch – niedrige Schwellen" + + - betreuungsmodus: "Aktiv (Regelmäßig)" + indikator_kategorien: + - kategorie: "IND-1 (Direkte Einschätzung)" + anwendung: "Ja" + frequenz: "Nach jedem Turnus-Gespräch (halbjährlich)" + - kategorie: "IND-2 (Interaktions-Signale)" + anwendung: "Ja" + frequenz: "Kontinuierlich, bei Auftreten" + - kategorie: "IND-3 (Strukturiertes Feedback)" + anwendung: "Optional" + frequenz: "Bei Bedarf" + gesamtbewertung: "Halbjährlich aktualisiert" + trigger_sensitivitaet: "Mittel" + + - betreuungsmodus: "Standard (Eingebunden)" + indikator_kategorien: + - kategorie: "IND-1 (Direkte Einschätzung)" + anwendung: "Ja" + frequenz: "Nach Advisory Board oder bei Kontakt, mind. jährlich" + - kategorie: "IND-2 (Interaktions-Signale)" + anwendung: "Ja, soweit Daten anfallen" + frequenz: "Bei Auftreten" + - kategorie: "IND-3 (Strukturiertes Feedback)" + anwendung: "Nein" + frequenz: "–" + gesamtbewertung: "Jährlich aktualisiert" + trigger_sensitivitaet: "Normal" + + - betreuungsmodus: "Basis (Reaktiv)" + indikator_kategorien: + - kategorie: "IND-1 (Direkte Einschätzung)" + anwendung: "Ja" + frequenz: "Bei Kontakt, mind. jährlich (Schätzung)" + - kategorie: "IND-2 (Interaktions-Signale)" + anwendung: "Ja, soweit Daten anfallen" + frequenz: "Bei Auftreten" + - kategorie: "IND-3 (Strukturiertes Feedback)" + anwendung: "Nein" + frequenz: "–" + gesamtbewertung: "Jährlich aktualisiert" + trigger_sensitivitaet: "Nur bei expliziten Signalen" + + # =========================================================================== + # INTERVENTIONS-TRIGGER + # =========================================================================== + + interventions_trigger: + + beschreibung: | + Interventions-Trigger sind definierte Schwellen oder Muster, + die eine proaktive Intervention durch SHM auslösen. + Die Trigger-Sensitivität variiert nach Betreuungsmodus. + + trigger: + + - id: "INTTRIG-01" + name: "Bewertungsverschlechterung" + beschreibung: | + Die SHM-Einschätzung der Beziehungsqualität verschlechtert + sich um mindestens eine Stufe. + schwelle: + key_stakeholder: "Jede Verschlechterung" + aktiv_stakeholder: "Jede Verschlechterung" + standard_basis: "Verschlechterung auf 'Angespannt' oder 'Kritisch'" + intervention: "Klärungsgespräch" + + - id: "INTTRIG-02" + name: "Kritische Bewertung" + beschreibung: | + Die Beziehungsqualität wird als 'Kritisch' eingestuft. + schwelle: "Alle Betreuungsmodi" + intervention: "Sofortige Intervention (Klärungsgespräch mit Amtsleitung)" + + - id: "INTTRIG-03" + name: "Beziehungs-Beschwerde" + beschreibung: | + Eine Beschwerde der Kategorie TRIG-C (Beziehungs-bezogen) + geht ein. + schwelle: "Alle Betreuungsmodi – jede Beschwerde ist ein Trigger" + intervention: "Klärungsgespräch" + verweis: "Eskalationspfad C" + + - id: "INTTRIG-04" + name: "Eskalationshäufung" + beschreibung: | + Mehrere Eskalationen (beliebiger Kategorie) innerhalb + eines definierten Zeitraums. + schwelle: + key_stakeholder: "2+ Eskalationen in 6 Monaten" + aktiv_stakeholder: "3+ Eskalationen in 12 Monaten" + standard_basis: "3+ Eskalationen in 12 Monaten" + intervention: "Klärungsgespräch, Ursachenanalyse" + + - id: "INTTRIG-05" + name: "Teilnahme-Rückzug" + beschreibung: | + Kunde sagt wiederholt Termine ab oder erscheint nicht + zu vereinbarten Formaten. + schwelle: + key_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows" + aktiv_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows" + standard_basis: "Nicht anwendbar (keine festen Termine)" + intervention: "Telefonische Nachfrage, ggf. Klärungsgespräch" + + - id: "INTTRIG-06" + name: "Kommunikationsabbruch" + beschreibung: | + Kunde reagiert nicht mehr auf Kontaktversuche. + schwelle: + key_stakeholder: "Keine Reaktion auf 2 Kontaktversuche" + aktiv_stakeholder: "Keine Reaktion auf 3 Kontaktversuche" + standard_basis: "Keine Reaktion auf 3 Kontaktversuche" + intervention: "Eskalation an Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung einbinden" + + # =========================================================================== + # INTERVENTIONS-REPERTOIRE + # =========================================================================== + + interventions_repertoire: + + beschreibung: | + Bei Auslösung eines Interventions-Triggers stehen folgende + Interventionen zur Verfügung. Die Wahl der Intervention + richtet sich nach Schwere und Kontext. + + interventionen: + + - id: "INTV-01" + name: "Klärungsgespräch" + beschreibung: | + Persönliches Gespräch zwischen SHM und Kundenvertreter + zur Klärung der Situation und Ursachenanalyse. + ziel: "Verständnis der Ursachen, Wiederherstellung des Dialogs" + teilnehmer: "SHM + Kundenvertreter (operative Ebene)" + eskalation_zu: "Klärungsgespräch mit Amtsleitung" + typische_trigger: ["INTTRIG-01", "INTTRIG-03", "INTTRIG-04", "INTTRIG-05"] + + - id: "INTV-02" + name: "Klärungsgespräch mit Amtsleitung" + beschreibung: | + Gespräch auf Leitungsebene, wenn operative Klärung nicht + ausreicht oder die Beziehung kritisch ist. + ziel: "Verbindliche Klärung auf Entscheidungsebene" + teilnehmer: "SHM + Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung" + voraussetzung: | + Operative Klärung war nicht erfolgreich ODER + Bewertung ist 'Kritisch' ODER + Thema erfordert Leitungsentscheidung + typische_trigger: ["INTTRIG-02", "INTTRIG-06"] + + - id: "INTV-03" + name: "Maßnahmenplan" + beschreibung: | + Strukturierter Plan mit konkreten Maßnahmen zur + Verbesserung der Beziehungsqualität. + ziel: "Nachvollziehbare, terminierte Maßnahmen mit Verantwortlichkeiten" + inhalt: + - "Identifizierte Ursachen" + - "Vereinbarte Maßnahmen" + - "Verantwortlichkeiten (DIGIT-seitig und Kunden-seitig)" + - "Termine / Meilensteine" + - "Review-Termin" + typische_massnahmen: + - "Erhöhte Kontaktfrequenz" + - "Dedizierter Ansprechpartner für offene Themen" + - "Priorisierung offener Bedarfe/Tickets" + - "Regelmäßige Status-Updates" + - "Gemeinsamer Workshop zur Neuausrichtung" + anwendung: | + Bei 'Angespannt' oder 'Kritisch', wenn einzelnes + Klärungsgespräch nicht ausreicht. + + eskalation_bei_misserfolg: | + Wenn Interventionen nicht zur Verbesserung führen, wird das + Thema ins Mission Board eingebracht (analog Eskalationspfad C, Stufe 3). + + # =========================================================================== + # DOKUMENTATION + # =========================================================================== + + dokumentation: + + beschreibung: | + Die Beziehungsqualität wird im Amts-Steckbrief (SIMS) dokumentiert + und historisch nachvollziehbar geführt. + + zu_dokumentieren: + - attribut: "beziehungsqualitaet_aktuell" + beschreibung: "Aktuelle Bewertung (EX/GU/AN/KR)" + aktualisierung: "Gemäß Erfassungsfrequenz" + - attribut: "beziehungsqualitaet_historie" + beschreibung: "Verlauf der Bewertungen mit Datum" + zweck: "Trends erkennen" + - attribut: "interventionen" + beschreibung: "Durchgeführte Interventionen mit Datum und Ergebnis" + zweck: "Nachvollziehbarkeit, Lernen" + - attribut: "massnahmenplan" + beschreibung: "Aktiver Maßnahmenplan (falls vorhanden)" + zweck: "Nachverfolgung" + + ablageort: "SIMS (Stakeholder-Informations-Management-System)" + + verweis_schema: | + Attribute sind im shm_schema_amtssteckbrief.yaml zu ergänzen + (Kategorie: Betreuung). + + # =========================================================================== + # REVIEW UND REPORTING + # =========================================================================== + + review_und_reporting: + + beschreibung: | + Die aggregierten Beziehungsqualitätsdaten fließen in die + Koordinations- und Steuerungsstruktur + (shm_koordinations-und-steuerungsstruktur.yaml) ein. + + aggregierte_auswertungen: + - "Verteilung der Bewertungen über alle Stakeholder" + - "Veränderungen gegenüber Vorperiode" + - "Anzahl aktiver Interventionen/Maßnahmenpläne" + - "Korrelation mit Eskalationshäufigkeit" + + berichtsrhythmus: "Quartalsweise (für Management-Reporting)" + + strategischer_input: | + Systematische Beziehungsprobleme (z.B. häufige Kritik an + bestimmten Services oder Prozessen) werden als Input für + DIGIT-Strategieprozess aufbereitet. + [Verweis: Strategieprozess noch nicht modelliert] + +# ============================================================================= +# TEMPLATE-BEDARFE (Übersicht für Phase 11) +# ============================================================================= + +template_bedarfe: + + beschreibung: | + Übersicht der identifizierten Template-Bedarfe. + Ausarbeitung erfolgt in Phase 11 (Arbeitsmaterialien). + + templates: + + - id: "TPL-EF-01" + name: "Agenda-Vorlage Strategisches Turnus-Gespräch" + format_referenz: "TF-01" + + - id: "TPL-EF-02" + name: "Protokoll-Vorlage Turnus-Gespräch" + format_referenz: "TF-01, TF-02" + + - id: "TPL-EF-03" + name: "Agenda-Vorlage Operatives Turnus-Gespräch" + format_referenz: "TF-02" + + - id: "TPL-EF-04" + name: "Workshop-Leitfaden Digitalisierungs-Strategie" + format_referenz: "SF-01" + + - id: "TPL-EF-05" + name: "Canvas: Digitalisierungspotenziale" + format_referenz: "SF-01" + + - id: "TPL-EF-06" + name: "Ergebnisdokumentation Strategie-Workshop" + format_referenz: "SF-01" + + - id: "TPL-EF-07" + name: "Workshop-Leitfaden Bedarfs-Vertiefung" + format_referenz: "SF-02" + + - id: "TPL-EF-08" + name: "Erweiterter Bedarfssteckbrief" + format_referenz: "SF-02" + + - id: "TPL-EF-09" + name: "Einladungs-Vorlage Advisory Board" + format_referenz: "KF-01" + + - id: "TPL-EF-10" + name: "Agenda-Vorlage Advisory Board" + format_referenz: "KF-01" + + - id: "TPL-EF-11" + name: "Protokoll-Vorlage Advisory Board" + format_referenz: "KF-01" + + - id: "TPL-EF-12" + name: "Workshop-Leitfaden Bedarfs-Konsolidierung" + format_referenz: "ThF-01" + + - id: "TPL-EF-13" + name: "Eskalations-Erfassungsbogen" + beschreibung: "Strukturierte Erfassung eingehender Eskalationen" + + - id: "TPL-EF-14" + name: "Eskalations-Statusbericht" + beschreibung: "Vorlage für Statusupdates bei laufenden Eskalationen" + + - id: "TPL-EF-15" + name: "Gremienvorlage Eskalation" + beschreibung: "Vorlage für Eskalationen an SOR/DSR/MB" + + - id: "TPL-EF-16" + name: "Feedback-Fragen Key-Stakeholder" + beschreibung: "Strukturierte Fragen für jährliches Feedback-Gespräch" + + - id: "TPL-EF-17" + name: "Maßnahmenplan Beziehungsqualität" + beschreibung: "Vorlage für strukturierten Maßnahmenplan" + + - id: "TPL-EF-18" + name: "Interventions-Dokumentation" + beschreibung: "Vorlage zur Dokumentation durchgeführter Interventionen" + + - id: "TPL-EF-19" + name: "Einladungs-Vorlage Auftraggeber-Forum" + format_referenz: "KF-01" + + - id: "TPL-EF-20" + name: "Agenda-Vorlage Auftraggeber-Forum (integriert)" + format_referenz: "KF-01" + beschreibung: "Kombinierte Agenda für SLA-Review und SHM-Themen" + + - id: "TPL-EF-21" + name: "Protokoll-Vorlage Auftraggeber-Forum" + format_referenz: "KF-01" + + - id: "TPL-EF-22" + name: "Basis-Puls-Check Fragebogen" + format_referenz: "KF-03" + + - id: "TPL-EF-23" + name: "Basis-Puls-Check Auswertungs-Template" + format_referenz: "KF-03" + + - id: "TPL-EF-24" + name: "Basis-Puls-Check Anschreiben" + format_referenz: "KF-03" + + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-EF-003" + thema: "Ressourcen-Implikationen" + beschreibung: | + Die Formate haben unterschiedlichen Ressourcenbedarf. + Eine Überschlagsrechnung (wie viele Key-Stakeholder kann ein + Stakeholder-Manager betreuen?) fehlt noch. + prioritaet: "niedrig" + naechster_schritt: "Nach Pilotierung evaluieren" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-12-09" + autor: "Chat-Session Phase 2" + aenderung: "Initiale Erstellung als Arbeitsstand" + + - version: "0.2" + datum: "2025-12-09" + autor: "Chat-Session Phase 2" + aenderung: "Eskalationslogik in reaktive Formate integriert" + + - version: "0.3" + datum: "2025-12-09" + autor: "Chat-Session Phase 2" + aenderung: "Beziehungsqualitätssicherung als neuer Abschnitt ergänzt" + + - version: "0.4" + datum: "2025-12-09" + autor: "Review-Feedback Integration" + aenderung: | + - Kollektive Formate: Integration mit SLM-Auftraggeber-Vertretungen + zu einheitlichem Auftraggeber-Forum-Konzept + - Frequenz Auftraggeber-Forum auf jährlich angepasst (Pilotierungs-Vorbehalt) + - Neues Format KF-03 "Basis-Puls-Check" für Basis-Stakeholder + - Template-Bedarfe ergänzt + + - version: "0.5" + datum: "2025-12-10" + autor: "Cross-Check Phase 5" + aenderung: | + - Veraltete Phase-7-Referenzen aktualisiert auf + shm_koordinations-und-steuerungsstruktur.yaml + - VoC-Schnittstelle in Meta-Sektion ergänzt + - Querverweise zu Koordinations- und Steuerungsstruktur harmonisiert + diff --git a/#03_stakeholder-management/#03.3_konzepte/shm_lifecycle-blueprint.yaml b/#03_stakeholder-management/#03.3_konzepte/shm_lifecycle-blueprint.yaml index 3ae3d3c..63887e6 100644 --- a/#03_stakeholder-management/#03.3_konzepte/shm_lifecycle-blueprint.yaml +++ b/#03_stakeholder-management/#03.3_konzepte/shm_lifecycle-blueprint.yaml @@ -1,20 +1,20 @@ -# ======================================== -# SHM Lifecycle Blueprint -# ======================================== -# Version: 0.1 (Platzhalter) -# Datum: 2024-12-03 -# Status: Ausstehend -# Entwicklungsphase: 3 -# ======================================== - -# ITIL4-Referenz (falls zutreffend): -# itil4_referenz: -# practice: "Customer Journey (DSV)" -# relevante_elemente: [] -# adaption_fuer_digitom: "" - -# ======================================== -# INHALT -# ======================================== - -# [Inhalt folgt in Phase 3] +# ======================================== +# SHM Lifecycle Blueprint +# ======================================== +# Version: 0.1 (Platzhalter) +# Datum: 2024-12-03 +# Status: Ausstehend +# Entwicklungsphase: 3 +# ======================================== + +# ITIL4-Referenz (falls zutreffend): +# itil4_referenz: +# practice: "Customer Journey (DSV)" +# relevante_elemente: [] +# adaption_fuer_digitom: "" + +# ======================================== +# INHALT +# ======================================== + +# [Inhalt folgt in Phase 3] diff --git a/#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml b/#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml index a948dd2..ff61f68 100644 --- a/#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml +++ b/#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml @@ -1,700 +1,700 @@ -# ============================================================================= -# STAKEHOLDER-INFORMATIONS-MANAGEMENT-SYSTEM (SIMS) -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Typ: Konzept (Informationsmanagement) -# Version: 1.0 -# Datum: 2025-12-11 -# Status: Entwurf -# Entwicklungsphase: 10 -# ============================================================================= - -meta: - modul_id: "SHM-K-05" - name: "Stakeholder-Informations-Management-System (SIMS)" - typ: "Konzept" - - zweck: | - Das SIMS ist das zentrale Informationssystem für die SHM-Funktion. - Es dient der strukturierten Erfassung, Pflege und Auswertung aller - stakeholderbezogenen Informationen, die für die Betreuung und - Steuerung des Stakeholder-Portfolios erforderlich sind. - - abgrenzung: - was_sims_ist: - - "Zentraler Ablageort für Stakeholder-Stammdaten" - - "Dokumentationssystem für Interaktionen und Bedarfe" - - "Grundlage für operative Steuerung und Reporting" - - was_sims_nicht_ist: - - "Kein Ticket-System (bleibt beim Service Desk)" - - "Kein Demand-Management-Tool (bleibt bei DPM)" - - "Kein CRM im vertrieblichen Sinne" - - design_prinzipien: - - - id: "DP-01" - name: "Entscheidungsorientierung" - beschreibung: | - Jedes erfasste Attribut muss mindestens eine der SHM-Kernentscheidungen - unterstützen (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung). - Daten ohne Entscheidungsbezug werden nicht erfasst. - - - id: "DP-02" - name: "Single Source of Truth" - beschreibung: | - SIMS ist die führende Quelle für Stakeholder-Stammdaten innerhalb - der SHM-Funktion. Redundante Datenhaltung ist zu vermeiden. - - - id: "DP-03" - name: "Minimale Komplexität" - beschreibung: | - Die Struktur wird so einfach wie möglich gehalten. Komplexität - wird nur dort zugelassen, wo sie nachweislich Mehrwert schafft. - - - id: "DP-04" - name: "Plattformunabhängigkeit" - beschreibung: | - Das Konzept beschreibt fachliche Anforderungen, nicht technische - Umsetzung. Die Wahl des Werkzeugs erfolgt separat. - - konzept_referenzen: - - dokument: "shm_schema_amtssteckbrief.yaml" - beschreibung: "Attribut-Schema für Stakeholder-Stammdaten" - - dokument: "shm_schema_bedarfssteckbrief.yaml" - beschreibung: "Attribut-Schema für Bedarfsdokumentation" - - dokument: "shm_engagement-framework.yaml" - beschreibung: "Interaktionsformate und Dokumentationsanforderungen" - - dokument: "shm_voice-of-customer.yaml" - beschreibung: "Feedback-Dimensionen und Aggregationslogik" - - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" - beschreibung: "Review-Artefakte und Reporting-Anforderungen" - -# ============================================================================= -# INFORMATIONSOBJEKTE -# ============================================================================= - -informationsobjekte: - - beschreibung: | - Die folgenden Informationsobjekte bilden den Kern des SIMS. - Sie stehen in definierten Beziehungen zueinander. - - objekte: - - # ------------------------------------------------------------------------- - # AMTS-STECKBRIEF (Kernobjekt) - # ------------------------------------------------------------------------- - - - id: "IO-01" - name: "Amts-Steckbrief" - - beschreibung: | - Zentrales Datenobjekt pro Stakeholder (Amt/Organisationseinheit). - Enthält Stammdaten, Segmentierung, Priorisierung und Betreuungsstatus. - - schema_referenz: "shm_schema_amtssteckbrief.yaml" - - charakter: "Persistentes Stammdatenobjekt" - - lebenszyklus: - anlage: "Bei Aufnahme ins Portfolio" - pflege: "Laufend durch zugeordneten Stakeholder-Manager" - abschluss: "Bei Herauslösung aus Portfolio (selten)" - - untergeordnete_elemente: - - "Gesprächsprotokolle (als Anhänge/Untereinträge)" - - "Interventionsdokumentation" - - "VoC-Feedback-Einträge" - - # ------------------------------------------------------------------------- - # BEDARFSSTECKBRIEF - # ------------------------------------------------------------------------- - - - id: "IO-02" - name: "Bedarfssteckbrief" - - beschreibung: | - Dokumentation eines konkreten Stakeholder-Bedarfs. Entsteht aus - der Bedarfsbewertung und dient als Übergabedokument an nachgelagerte - Funktionen (Service Desk, SPM, DPM). - - schema_referenz: "shm_schema_bedarfssteckbrief.yaml" - - charakter: "Transaktionsobjekt mit Lebenszyklus" - - lebenszyklus: - anlage: "Bei Bedarfserfassung durch SHM" - pflege: "Status-Updates bei Bearbeitung" - abschluss: "Bei Erledigung oder Ablehnung" - - beziehung_zu_amt: | - Jeder Bedarfssteckbrief ist genau einem Amt zugeordnet. - Ein Amt kann mehrere Bedarfssteckbriefe haben. - - # ------------------------------------------------------------------------- - # GESPRÄCHSPROTOKOLL - # ------------------------------------------------------------------------- - - - id: "IO-03" - name: "Gesprächsprotokoll" - - beschreibung: | - Dokumentation von Turnus-Gesprächen, Workshops und anderen - Interaktionsformaten. Wird dem jeweiligen Amt zugeordnet. - - charakter: "Anhang/Untereintrag zum Amts-Steckbrief" - - mindestattribute: - - attribut: "datum" - beschreibung: "Datum des Gesprächs" - - attribut: "format" - beschreibung: "Art des Formats (TF-01, TF-02, SF-01, etc.)" - referenz: "shm_engagement-framework.yaml" - - attribut: "teilnehmer" - beschreibung: "Teilnehmer (DIGIT-seitig und Kundenseite)" - - attribut: "themen" - beschreibung: "Besprochene Themen (Stichworte)" - - attribut: "vereinbarungen" - beschreibung: "Konkrete Vereinbarungen mit Verantwortung/Termin" - - attribut: "feedback_notizen" - beschreibung: "VoC-relevante Aussagen (für Aggregation)" - referenz: "shm_voice-of-customer.yaml" - - aufbewahrung: | - Protokolle bleiben dauerhaft dem Amt zugeordnet und ermöglichen - die Nachvollziehbarkeit der Betreuungshistorie. - - # ------------------------------------------------------------------------- - # INTERVENTIONSDOKUMENTATION - # ------------------------------------------------------------------------- - - - id: "IO-04" - name: "Interventionsdokumentation" - - beschreibung: | - Dokumentation von Interventionen bei angespannter oder kritischer - Beziehungsqualität. Enthält Ursachenanalyse, Maßnahmenplan und - Verlauf. - - charakter: "Anhang/Untereintrag zum Amts-Steckbrief" - - mindestattribute: - - attribut: "anlass" - beschreibung: "Auslöser der Intervention" - - attribut: "beziehungsqualitaet_start" - beschreibung: "Bewertung bei Interventionsbeginn" - - attribut: "ursachenanalyse" - beschreibung: "Identifizierte Ursachen" - - attribut: "massnahmen" - beschreibung: "Vereinbarte Maßnahmen mit Verantwortung/Termin" - - attribut: "status" - beschreibung: "Aktiv / Abgeschlossen / Abgebrochen" - - attribut: "ergebnis" - beschreibung: "Bewertung bei Abschluss" - - referenz: "shm_engagement-framework.yaml → beziehungsqualitaet" - - # ------------------------------------------------------------------------- - # VOC-FEEDBACK-EINTRAG - # ------------------------------------------------------------------------- - - - id: "IO-05" - name: "VoC-Feedback-Eintrag" - - beschreibung: | - Einzelnes Feedback-Element aus Stakeholder-Interaktionen. - Wird aggregiert für Cluster-Analyse und Reporting. - - charakter: "Anhang/Untereintrag zum Amts-Steckbrief oder eigenständig" - - mindestattribute: - - attribut: "quelle" - beschreibung: "Feedback-Quelle (Q-01 bis Q-06)" - referenz: "shm_voice-of-customer.yaml" - - attribut: "datum" - beschreibung: "Erfassungsdatum" - - attribut: "dimension" - beschreibung: "Zuordnung zu D1-D4" - - attribut: "subdimension" - beschreibung: "Konkrete Subdimension" - - attribut: "tendenz" - beschreibung: "Positiv / Neutral / Negativ" - - attribut: "kernaussage" - beschreibung: "Zusammenfassung in 1-2 Sätzen" - - aggregationslogik: | - Einzelne Einträge werden gemäß shm_voice-of-customer.yaml - zu Clustern aggregiert und in die Review-Struktur eingespeist. - -# ============================================================================= -# STRUKTURKONZEPT -# ============================================================================= - -strukturkonzept: - - beschreibung: | - Das SIMS gliedert sich in logische Bereiche, die unterschiedliche - Informationstypen und Nutzungskontexte adressieren. - - bereiche: - - - id: "B-01" - name: "Stakeholder-Portfolio" - beschreibung: | - Zentrale Ablage aller Amts-Steckbriefe mit zugeordneten - Untereinträgen (Protokolle, Interventionen, Feedback). - inhalt: - - "Amts-Steckbriefe (IO-01)" - - "Gesprächsprotokolle (IO-03)" - - "Interventionsdokumentation (IO-04)" - - "VoC-Feedback-Einträge (IO-05)" - primaere_nutzer: "Stakeholder-Manager (operativ)" - - - id: "B-02" - name: "Bedarfsdokumentation" - beschreibung: | - Ablage aller Bedarfssteckbriefe mit Verlinkung zum - zugehörigen Amt. - inhalt: - - "Bedarfssteckbriefe (IO-02)" - primaere_nutzer: "Stakeholder-Manager, DPM (bei Übergabe)" - - - id: "B-03" - name: "Auswertungen und Reports" - beschreibung: | - Bereich für aggregierte Sichten, Dashboards und - vorbereitete Reports (E1, E2). - inhalt: - - "Views (siehe Abschnitt views)" - - "Report-Vorlagen" - primaere_nutzer: "SHM-Leitung, Stakeholder-Manager" - - - id: "B-04" - name: "Arbeitsmaterialien" - beschreibung: | - Ablage für Templates, Leitfäden und Checklisten, - die im SHM-Alltag verwendet werden. - inhalt: - - "Gesprächsvorlagen" - - "Checklisten" - - "Leitfäden" - primaere_nutzer: "Stakeholder-Manager" - referenz: "#03.7_arbeitsmaterialien/" - - beziehungen: - - beschreibung: | - Die Informationsobjekte stehen in folgenden Beziehungen zueinander. - - beziehungsmodell: | - - ┌─────────────────────────────────────────────────────────────┐ - │ AMTS-STECKBRIEF │ - │ (IO-01) │ - │ │ - │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ - │ │ Gesprächs- │ │Interventions│ │ VoC-Feedback- │ │ - │ │ protokolle │ │dokumentation│ │ Einträge │ │ - │ │ (IO-03) │ │ (IO-04) │ │ (IO-05) │ │ - │ │ [0..*] │ │ [0..*] │ │ [0..*] │ │ - │ └─────────────┘ └─────────────┘ └─────────────────────┘ │ - └───────────────────────────┬─────────────────────────────────┘ - │ - │ 1:n - ▼ - ┌─────────────────────────────┐ - │ BEDARFSSTECKBRIEF │ - │ (IO-02) │ - │ [0..*] │ - └─────────────────────────────┘ - - kardinalitaeten: - - "Amt 1 : n Bedarfssteckbrief" - - "Amt 1 : n Gesprächsprotokoll" - - "Amt 1 : n Interventionsdokumentation" - - "Amt 1 : n VoC-Feedback-Eintrag" - -# ============================================================================= -# VIEWS (AUSWERTUNGSPERSPEKTIVEN) -# ============================================================================= - -views: - - beschreibung: | - Views sind vordefinierte Auswertungsperspektiven auf die SIMS-Daten. - Sie unterstützen die operative Arbeit und das Management-Reporting. - - hinweis: | - Die folgenden Views sind ein initialer Vorschlag basierend auf den - identifizierten Nutzungsszenarien. Sie sind im Rahmen der Einführung - zu validieren und nach Praxiserprobung anzupassen. - - kategorien: - - # ------------------------------------------------------------------------- - # PORTFOLIO-MANAGEMENT - # ------------------------------------------------------------------------- - - - kategorie: "Portfolio-Management" - beschreibung: "Überblick und Steuerung des Stakeholder-Portfolios" - - views: - - - id: "V-PF-01" - name: "Stakeholder nach Prio-Stufe" - zweck: "Überblick Portfolioverteilung" - filterkriterien: "Gruppierung nach Prio-Stufe (Key/Aktiv/Standard/Basis)" - primaerer_nutzer: "SHM-Leitung" - - - id: "V-PF-02" - name: "Meine Stakeholder" - zweck: "Persönliche Arbeitsliste" - filterkriterien: "Filter: Betreuungszuordnung = aktueller Nutzer" - primaerer_nutzer: "Stakeholder-Manager" - - - id: "V-PF-03" - name: "Stakeholder nach Dezernat" - zweck: "Organisatorische Cluster-Sicht" - filterkriterien: "Gruppierung nach Dezernat" - primaerer_nutzer: "SHM-Leitung" - - - id: "V-PF-04" - name: "Neuzugänge" - zweck: "Onboarding-Pipeline" - filterkriterien: "Filter: Anlage < 90 Tage oder Status = Neu" - primaerer_nutzer: "Stakeholder-Manager" - - # ------------------------------------------------------------------------- - # BEZIEHUNGSQUALITÄT - # ------------------------------------------------------------------------- - - - kategorie: "Beziehungsqualität" - beschreibung: "Monitoring der Beziehungsqualität und Interventionen" - - views: - - - id: "V-BQ-01" - name: "Beziehungs-Ampel" - zweck: "Gesamtübersicht Beziehungsqualität" - filterkriterien: "Alle Stakeholder mit Spalte Beziehungsqualität" - primaerer_nutzer: "SHM-Leitung" - - - id: "V-BQ-02" - name: "Interventionsbedarf" - zweck: "Fokus auf Problemfälle" - filterkriterien: "Filter: Beziehungsqualität = Angespannt ODER Kritisch" - primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager" - - - id: "V-BQ-03" - name: "Aktive Maßnahmenpläne" - zweck: "Nachverfolgung laufender Interventionen" - filterkriterien: "Filter: Interventionsdokumentation.Status = Aktiv" - primaerer_nutzer: "SHM-Leitung" - - # ------------------------------------------------------------------------- - # ENGAGEMENT / TURNUS - # ------------------------------------------------------------------------- - - - kategorie: "Engagement und Turnus" - beschreibung: "Planung und Nachverfolgung von Stakeholder-Interaktionen" - - views: - - - id: "V-EN-01" - name: "Anstehende Turnus-Termine" - zweck: "Terminplanung" - filterkriterien: "Filter: Nächster Turnus ≤ 30 Tage" - primaerer_nutzer: "Stakeholder-Manager" - - - id: "V-EN-02" - name: "Überfällige Kontakte" - zweck: "Eskalations-Früherkennung" - filterkriterien: "Filter: Letzter Kontakt > Soll-Frequenz (abgeleitet aus Betreuungsmodus)" - primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager" - - - id: "V-EN-03" - name: "Key-Stakeholder Jahresübersicht" - zweck: "Strategische Betreuungsplanung" - filterkriterien: "Filter: Prio = Key; Anzeige: alle geplanten Termine" - primaerer_nutzer: "SHM-Leitung" - - # ------------------------------------------------------------------------- - # BEDARFSDOKUMENTATION - # ------------------------------------------------------------------------- - - - kategorie: "Bedarfsdokumentation" - beschreibung: "Überblick und Nachverfolgung von Stakeholder-Bedarfen" - - views: - - - id: "V-BD-01" - name: "Offene Bedarfe pro Stakeholder" - zweck: "Gesprächsvorbereitung" - filterkriterien: "Gruppierung nach Amt; Filter: Status ≠ Abgeschlossen" - primaerer_nutzer: "Stakeholder-Manager" - - - id: "V-BD-02" - name: "Bedarfe nach Routing-Pfad" - zweck: "Prozess-Monitoring" - filterkriterien: "Gruppierung nach Routing (REQ/SPM/DPM/SOR)" - primaerer_nutzer: "SHM-Leitung" - - - id: "V-BD-03" - name: "Bedarfe in Wartestellung" - zweck: "Follow-up-Liste" - filterkriterien: "Filter: Status = Übergeben, wartend" - primaerer_nutzer: "Stakeholder-Manager" - - # ------------------------------------------------------------------------- - # REVIEW / REPORTING - # ------------------------------------------------------------------------- - - - kategorie: "Review und Reporting" - beschreibung: "Aggregierte Sichten für E1/E2-Reviews" - - views: - - - id: "V-RV-01" - name: "E2-Quartalsdaten" - zweck: "Vorbereitung Quartalsbericht" - filterkriterien: "Aggregation: Kontakte, Bedarfe, Interventionen im Quartal" - primaerer_nutzer: "SHM-Leitung" - referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e2_quartals_review" - - - id: "V-RV-02" - name: "VoC-Cluster-Übersicht" - zweck: "Feedback-Aggregation" - filterkriterien: "Gruppierung nach Cluster; Anzeige: Ampel-Status" - primaerer_nutzer: "SHM-Leitung" - referenz: "shm_voice-of-customer.yaml → cluster" - - - id: "V-RV-03" - name: "E1-Jahresübersicht" - zweck: "Vorbereitung Jahresbericht" - filterkriterien: "Aggregation aller relevanten Metriken auf Jahresebene" - primaerer_nutzer: "SHM-Leitung" - referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e1_jahres_review" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - beschreibung: | - SIMS steht nicht isoliert, sondern hat konzeptionelle Schnittstellen - zu anderen Informationssystemen und Funktionen. Diese Schnittstellen - sind zunächst als Informationsflüsse zu verstehen, nicht als - technische Integrationen. - - schnittstellen: - - - id: "SS-01" - name: "DPM (Demand-Portfolio-Management)" - - richtung: "SIMS → DPM" - - beschreibung: | - Bei Routing-Entscheidung ROUTE-DPM wird der Bedarfssteckbrief - an DPM übergeben. DPM übernimmt dann die weitere Bearbeitung - im Demand-Lifecycle. - - uebergabeobjekt: "Bedarfssteckbrief (IO-02)" - - informationsfluss: - von_sims: - - "Bedarfssteckbrief mit Stakeholder-Kontext" - - "User Stories (falls erhoben)" - von_dpm: - - "Status-Updates zum Demand" - - "Entscheidungen (DSR/MB)" - - governance_referenz: "shm_d2p-integration.yaml" - - - id: "SS-02" - name: "SPM (Service-Portfolio-Management)" - - richtung: "Bidirektional" - - beschreibung: | - SPM liefert Service-Performance-Daten, die für Turnus-Gespräche - und Beziehungsqualitäts-Bewertung relevant sind. SHM liefert - Kundenfeedback und Bedarfe im Service-Kontext. - - informationsfluss: - von_spm: - - "SLA-Einhaltung pro Amt/Service" - - "Bekannte Service-Probleme" - - "Service-Änderungen (für proaktive Kommunikation)" - von_sims: - - "VoC-Feedback zu Services" - - "Bedarfssteckbriefe (bei ROUTE-SPM)" - - hinweis: | - Der Informationsfluss erfolgt im MVP manuell (Abfrage vor - Turnus-Gespräch). Eine technische Integration ist optional. - - - id: "SS-03" - name: "Ticket-System (Service Desk)" - - richtung: "Ticket-System → SIMS (lesend)" - - beschreibung: | - Für Turnus-Gespräche und Beziehungsqualitäts-Bewertung sind - Informationen zu offenen Tickets pro Amt relevant. - - informationsfluss: - von_ticketsystem: - - "Anzahl offener Tickets pro Amt" - - "Eskalierte Tickets" - - "Wiederkehrende Probleme" - von_sims: - - "(kein direkter Rückfluss)" - - hinweis: | - Im MVP erfolgt die Abfrage manuell. Eine automatisierte - Einspielung ist bei entsprechendem Tooling möglich. - -# ============================================================================= -# GOVERNANCE -# ============================================================================= - -governance: - - beschreibung: | - Regeln für Datenpflege, Qualitätssicherung und Verantwortlichkeiten - im SIMS. - - datenpflege: - - prinzip: | - Jeder Datensatz hat genau einen Verantwortlichen für die Pflege. - Die Verantwortung folgt der Betreuungszuordnung. - - verantwortlichkeiten: - - - objekt: "Amts-Steckbrief" - verantwortlich: "Zugeordneter Stakeholder-Manager" - aktualisierung: "Laufend, mindestens bei Turnus-Gespräch" - - - objekt: "Bedarfssteckbrief" - verantwortlich: "Erfassender Stakeholder-Manager" - aktualisierung: "Bei Status-Änderungen" - - - objekt: "Gesprächsprotokoll" - verantwortlich: "Durchführender Stakeholder-Manager" - aktualisierung: "Innerhalb von 5 Arbeitstagen nach Gespräch" - - - objekt: "Interventionsdokumentation" - verantwortlich: "Zugeordneter Stakeholder-Manager" - aktualisierung: "Laufend während Intervention" - - - objekt: "VoC-Feedback-Eintrag" - verantwortlich: "Erfassender Stakeholder-Manager" - aktualisierung: "Bei Erfassung (einmalig)" - - qualitaetssicherung: - - - id: "QS-01" - name: "Vollständigkeitsprüfung Stammdaten" - beschreibung: "Prüfung auf vollständige Pflichtfelder im Amts-Steckbrief" - frequenz: "Quartalsweise (im Rahmen E2)" - verantwortlich: "SHM-Leitung" - referenz: "shm_schema_amtssteckbrief.yaml → validierung" - - - id: "QS-02" - name: "Aktualitätsprüfung" - beschreibung: "Identifikation von Datensätzen ohne Aktualisierung > 12 Monate" - frequenz: "Halbjährlich" - verantwortlich: "SHM-Leitung" - - - id: "QS-03" - name: "Konsistenzprüfung Prio/Betreuungsmodus" - beschreibung: "Prüfung, ob Betreuungsmodus zur Prio-Stufe passt" - frequenz: "Quartalsweise (im Rahmen E2)" - verantwortlich: "SHM-Leitung" - referenz: "shm_schema_amtssteckbrief.yaml → validierung VAL-003" - - archivierung: - - prinzip: | - Abgeschlossene Objekte (erledigte Bedarfe, beendete Interventionen) - werden nicht gelöscht, sondern archiviert. Sie bleiben für - Nachvollziehbarkeit und Trendanalysen zugänglich. - - aufbewahrungsfristen: - - objekt: "Amts-Steckbrief" - frist: "Dauerhaft (solange Amt im Portfolio)" - - objekt: "Bedarfssteckbrief" - frist: "5 Jahre nach Abschluss" - - objekt: "Gesprächsprotokoll" - frist: "5 Jahre" - - objekt: "Interventionsdokumentation" - frist: "5 Jahre nach Abschluss" - - objekt: "VoC-Feedback-Eintrag" - frist: "3 Jahre" - - hinweis: | - Die Fristen sind initiale Vorschläge und ggf. an organisatorische - oder rechtliche Vorgaben anzupassen. - -# ============================================================================= -# EINFÜHRUNGSHINWEISE -# ============================================================================= - -einfuehrung: - - beschreibung: | - Hinweise für die Einführung des SIMS in den operativen Betrieb. - - empfohlenes_vorgehen: - - - phase: "1. Toolauswahl" - beschreibung: | - Auswahl eines geeigneten Werkzeugs basierend auf den - fachlichen Anforderungen dieses Konzepts. - kriterien: - - "Unterstützung strukturierter Datenerfassung" - - "Flexible View-/Filtermöglichkeiten" - - "Verlinkung zwischen Objekten" - - "Zugänglichkeit für alle SHM-Mitarbeitenden" - - - phase: "2. Pilotierung" - beschreibung: | - Erprobung mit einer Teilmenge des Portfolios (z.B. ein Dezernat) - vor vollständigem Rollout. - ziel: "Validierung der Struktur und Views" - - - phase: "3. Initiale Befüllung" - beschreibung: | - Migration/Erfassung der Bestandsdaten für alle Stakeholder. - hinweis: "Qualität vor Vollständigkeit bei der Erstbefüllung" - - - phase: "4. Schulung" - beschreibung: | - Einweisung aller Stakeholder-Manager in Struktur und Nutzung. - - - phase: "5. Review und Anpassung" - beschreibung: | - Nach 6 Monaten Betrieb: Review der Views und Struktur, - Anpassung basierend auf Praxiserfahrung. - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-11" - autor: "Konzept-Sprint Phase 10" - aenderung: | - Initiale Erstellung: - - Meta-Informationen und Design-Prinzipien - - Informationsobjekte IO-01 bis IO-05 definiert - - Strukturkonzept mit 4 Bereichen - - 16 Views in 5 Kategorien (als Vorschlag) - - Konzeptionelle Schnittstellen zu DPM, SPM, Ticket-System - - Governance (Datenpflege, QS, Archivierung) +# ============================================================================= +# STAKEHOLDER-INFORMATIONS-MANAGEMENT-SYSTEM (SIMS) +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Typ: Konzept (Informationsmanagement) +# Version: 1.0 +# Datum: 2025-12-11 +# Status: Entwurf +# Entwicklungsphase: 10 +# ============================================================================= + +meta: + modul_id: "SHM-K-05" + name: "Stakeholder-Informations-Management-System (SIMS)" + typ: "Konzept" + + zweck: | + Das SIMS ist das zentrale Informationssystem für die SHM-Funktion. + Es dient der strukturierten Erfassung, Pflege und Auswertung aller + stakeholderbezogenen Informationen, die für die Betreuung und + Steuerung des Stakeholder-Portfolios erforderlich sind. + + abgrenzung: + was_sims_ist: + - "Zentraler Ablageort für Stakeholder-Stammdaten" + - "Dokumentationssystem für Interaktionen und Bedarfe" + - "Grundlage für operative Steuerung und Reporting" + + was_sims_nicht_ist: + - "Kein Ticket-System (bleibt beim Service Desk)" + - "Kein Demand-Management-Tool (bleibt bei DPM)" + - "Kein CRM im vertrieblichen Sinne" + + design_prinzipien: + + - id: "DP-01" + name: "Entscheidungsorientierung" + beschreibung: | + Jedes erfasste Attribut muss mindestens eine der SHM-Kernentscheidungen + unterstützen (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung). + Daten ohne Entscheidungsbezug werden nicht erfasst. + + - id: "DP-02" + name: "Single Source of Truth" + beschreibung: | + SIMS ist die führende Quelle für Stakeholder-Stammdaten innerhalb + der SHM-Funktion. Redundante Datenhaltung ist zu vermeiden. + + - id: "DP-03" + name: "Minimale Komplexität" + beschreibung: | + Die Struktur wird so einfach wie möglich gehalten. Komplexität + wird nur dort zugelassen, wo sie nachweislich Mehrwert schafft. + + - id: "DP-04" + name: "Plattformunabhängigkeit" + beschreibung: | + Das Konzept beschreibt fachliche Anforderungen, nicht technische + Umsetzung. Die Wahl des Werkzeugs erfolgt separat. + + konzept_referenzen: + - dokument: "shm_schema_amtssteckbrief.yaml" + beschreibung: "Attribut-Schema für Stakeholder-Stammdaten" + - dokument: "shm_schema_bedarfssteckbrief.yaml" + beschreibung: "Attribut-Schema für Bedarfsdokumentation" + - dokument: "shm_engagement-framework.yaml" + beschreibung: "Interaktionsformate und Dokumentationsanforderungen" + - dokument: "shm_voice-of-customer.yaml" + beschreibung: "Feedback-Dimensionen und Aggregationslogik" + - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" + beschreibung: "Review-Artefakte und Reporting-Anforderungen" + +# ============================================================================= +# INFORMATIONSOBJEKTE +# ============================================================================= + +informationsobjekte: + + beschreibung: | + Die folgenden Informationsobjekte bilden den Kern des SIMS. + Sie stehen in definierten Beziehungen zueinander. + + objekte: + + # ------------------------------------------------------------------------- + # AMTS-STECKBRIEF (Kernobjekt) + # ------------------------------------------------------------------------- + + - id: "IO-01" + name: "Amts-Steckbrief" + + beschreibung: | + Zentrales Datenobjekt pro Stakeholder (Amt/Organisationseinheit). + Enthält Stammdaten, Segmentierung, Priorisierung und Betreuungsstatus. + + schema_referenz: "shm_schema_amtssteckbrief.yaml" + + charakter: "Persistentes Stammdatenobjekt" + + lebenszyklus: + anlage: "Bei Aufnahme ins Portfolio" + pflege: "Laufend durch zugeordneten Stakeholder-Manager" + abschluss: "Bei Herauslösung aus Portfolio (selten)" + + untergeordnete_elemente: + - "Gesprächsprotokolle (als Anhänge/Untereinträge)" + - "Interventionsdokumentation" + - "VoC-Feedback-Einträge" + + # ------------------------------------------------------------------------- + # BEDARFSSTECKBRIEF + # ------------------------------------------------------------------------- + + - id: "IO-02" + name: "Bedarfssteckbrief" + + beschreibung: | + Dokumentation eines konkreten Stakeholder-Bedarfs. Entsteht aus + der Bedarfsbewertung und dient als Übergabedokument an nachgelagerte + Funktionen (Service Desk, SPM, DPM). + + schema_referenz: "shm_schema_bedarfssteckbrief.yaml" + + charakter: "Transaktionsobjekt mit Lebenszyklus" + + lebenszyklus: + anlage: "Bei Bedarfserfassung durch SHM" + pflege: "Status-Updates bei Bearbeitung" + abschluss: "Bei Erledigung oder Ablehnung" + + beziehung_zu_amt: | + Jeder Bedarfssteckbrief ist genau einem Amt zugeordnet. + Ein Amt kann mehrere Bedarfssteckbriefe haben. + + # ------------------------------------------------------------------------- + # GESPRÄCHSPROTOKOLL + # ------------------------------------------------------------------------- + + - id: "IO-03" + name: "Gesprächsprotokoll" + + beschreibung: | + Dokumentation von Turnus-Gesprächen, Workshops und anderen + Interaktionsformaten. Wird dem jeweiligen Amt zugeordnet. + + charakter: "Anhang/Untereintrag zum Amts-Steckbrief" + + mindestattribute: + - attribut: "datum" + beschreibung: "Datum des Gesprächs" + - attribut: "format" + beschreibung: "Art des Formats (TF-01, TF-02, SF-01, etc.)" + referenz: "shm_engagement-framework.yaml" + - attribut: "teilnehmer" + beschreibung: "Teilnehmer (DIGIT-seitig und Kundenseite)" + - attribut: "themen" + beschreibung: "Besprochene Themen (Stichworte)" + - attribut: "vereinbarungen" + beschreibung: "Konkrete Vereinbarungen mit Verantwortung/Termin" + - attribut: "feedback_notizen" + beschreibung: "VoC-relevante Aussagen (für Aggregation)" + referenz: "shm_voice-of-customer.yaml" + + aufbewahrung: | + Protokolle bleiben dauerhaft dem Amt zugeordnet und ermöglichen + die Nachvollziehbarkeit der Betreuungshistorie. + + # ------------------------------------------------------------------------- + # INTERVENTIONSDOKUMENTATION + # ------------------------------------------------------------------------- + + - id: "IO-04" + name: "Interventionsdokumentation" + + beschreibung: | + Dokumentation von Interventionen bei angespannter oder kritischer + Beziehungsqualität. Enthält Ursachenanalyse, Maßnahmenplan und + Verlauf. + + charakter: "Anhang/Untereintrag zum Amts-Steckbrief" + + mindestattribute: + - attribut: "anlass" + beschreibung: "Auslöser der Intervention" + - attribut: "beziehungsqualitaet_start" + beschreibung: "Bewertung bei Interventionsbeginn" + - attribut: "ursachenanalyse" + beschreibung: "Identifizierte Ursachen" + - attribut: "massnahmen" + beschreibung: "Vereinbarte Maßnahmen mit Verantwortung/Termin" + - attribut: "status" + beschreibung: "Aktiv / Abgeschlossen / Abgebrochen" + - attribut: "ergebnis" + beschreibung: "Bewertung bei Abschluss" + + referenz: "shm_engagement-framework.yaml → beziehungsqualitaet" + + # ------------------------------------------------------------------------- + # VOC-FEEDBACK-EINTRAG + # ------------------------------------------------------------------------- + + - id: "IO-05" + name: "VoC-Feedback-Eintrag" + + beschreibung: | + Einzelnes Feedback-Element aus Stakeholder-Interaktionen. + Wird aggregiert für Cluster-Analyse und Reporting. + + charakter: "Anhang/Untereintrag zum Amts-Steckbrief oder eigenständig" + + mindestattribute: + - attribut: "quelle" + beschreibung: "Feedback-Quelle (Q-01 bis Q-06)" + referenz: "shm_voice-of-customer.yaml" + - attribut: "datum" + beschreibung: "Erfassungsdatum" + - attribut: "dimension" + beschreibung: "Zuordnung zu D1-D4" + - attribut: "subdimension" + beschreibung: "Konkrete Subdimension" + - attribut: "tendenz" + beschreibung: "Positiv / Neutral / Negativ" + - attribut: "kernaussage" + beschreibung: "Zusammenfassung in 1-2 Sätzen" + + aggregationslogik: | + Einzelne Einträge werden gemäß shm_voice-of-customer.yaml + zu Clustern aggregiert und in die Review-Struktur eingespeist. + +# ============================================================================= +# STRUKTURKONZEPT +# ============================================================================= + +strukturkonzept: + + beschreibung: | + Das SIMS gliedert sich in logische Bereiche, die unterschiedliche + Informationstypen und Nutzungskontexte adressieren. + + bereiche: + + - id: "B-01" + name: "Stakeholder-Portfolio" + beschreibung: | + Zentrale Ablage aller Amts-Steckbriefe mit zugeordneten + Untereinträgen (Protokolle, Interventionen, Feedback). + inhalt: + - "Amts-Steckbriefe (IO-01)" + - "Gesprächsprotokolle (IO-03)" + - "Interventionsdokumentation (IO-04)" + - "VoC-Feedback-Einträge (IO-05)" + primaere_nutzer: "Stakeholder-Manager (operativ)" + + - id: "B-02" + name: "Bedarfsdokumentation" + beschreibung: | + Ablage aller Bedarfssteckbriefe mit Verlinkung zum + zugehörigen Amt. + inhalt: + - "Bedarfssteckbriefe (IO-02)" + primaere_nutzer: "Stakeholder-Manager, DPM (bei Übergabe)" + + - id: "B-03" + name: "Auswertungen und Reports" + beschreibung: | + Bereich für aggregierte Sichten, Dashboards und + vorbereitete Reports (E1, E2). + inhalt: + - "Views (siehe Abschnitt views)" + - "Report-Vorlagen" + primaere_nutzer: "SHM-Leitung, Stakeholder-Manager" + + - id: "B-04" + name: "Arbeitsmaterialien" + beschreibung: | + Ablage für Templates, Leitfäden und Checklisten, + die im SHM-Alltag verwendet werden. + inhalt: + - "Gesprächsvorlagen" + - "Checklisten" + - "Leitfäden" + primaere_nutzer: "Stakeholder-Manager" + referenz: "#03.7_arbeitsmaterialien/" + + beziehungen: + + beschreibung: | + Die Informationsobjekte stehen in folgenden Beziehungen zueinander. + + beziehungsmodell: | + + ┌─────────────────────────────────────────────────────────────┐ + │ AMTS-STECKBRIEF │ + │ (IO-01) │ + │ │ + │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ + │ │ Gesprächs- │ │Interventions│ │ VoC-Feedback- │ │ + │ │ protokolle │ │dokumentation│ │ Einträge │ │ + │ │ (IO-03) │ │ (IO-04) │ │ (IO-05) │ │ + │ │ [0..*] │ │ [0..*] │ │ [0..*] │ │ + │ └─────────────┘ └─────────────┘ └─────────────────────┘ │ + └───────────────────────────┬─────────────────────────────────┘ + │ + │ 1:n + ▼ + ┌─────────────────────────────┐ + │ BEDARFSSTECKBRIEF │ + │ (IO-02) │ + │ [0..*] │ + └─────────────────────────────┘ + + kardinalitaeten: + - "Amt 1 : n Bedarfssteckbrief" + - "Amt 1 : n Gesprächsprotokoll" + - "Amt 1 : n Interventionsdokumentation" + - "Amt 1 : n VoC-Feedback-Eintrag" + +# ============================================================================= +# VIEWS (AUSWERTUNGSPERSPEKTIVEN) +# ============================================================================= + +views: + + beschreibung: | + Views sind vordefinierte Auswertungsperspektiven auf die SIMS-Daten. + Sie unterstützen die operative Arbeit und das Management-Reporting. + + hinweis: | + Die folgenden Views sind ein initialer Vorschlag basierend auf den + identifizierten Nutzungsszenarien. Sie sind im Rahmen der Einführung + zu validieren und nach Praxiserprobung anzupassen. + + kategorien: + + # ------------------------------------------------------------------------- + # PORTFOLIO-MANAGEMENT + # ------------------------------------------------------------------------- + + - kategorie: "Portfolio-Management" + beschreibung: "Überblick und Steuerung des Stakeholder-Portfolios" + + views: + + - id: "V-PF-01" + name: "Stakeholder nach Prio-Stufe" + zweck: "Überblick Portfolioverteilung" + filterkriterien: "Gruppierung nach Prio-Stufe (Key/Aktiv/Standard/Basis)" + primaerer_nutzer: "SHM-Leitung" + + - id: "V-PF-02" + name: "Meine Stakeholder" + zweck: "Persönliche Arbeitsliste" + filterkriterien: "Filter: Betreuungszuordnung = aktueller Nutzer" + primaerer_nutzer: "Stakeholder-Manager" + + - id: "V-PF-03" + name: "Stakeholder nach Dezernat" + zweck: "Organisatorische Cluster-Sicht" + filterkriterien: "Gruppierung nach Dezernat" + primaerer_nutzer: "SHM-Leitung" + + - id: "V-PF-04" + name: "Neuzugänge" + zweck: "Onboarding-Pipeline" + filterkriterien: "Filter: Anlage < 90 Tage oder Status = Neu" + primaerer_nutzer: "Stakeholder-Manager" + + # ------------------------------------------------------------------------- + # BEZIEHUNGSQUALITÄT + # ------------------------------------------------------------------------- + + - kategorie: "Beziehungsqualität" + beschreibung: "Monitoring der Beziehungsqualität und Interventionen" + + views: + + - id: "V-BQ-01" + name: "Beziehungs-Ampel" + zweck: "Gesamtübersicht Beziehungsqualität" + filterkriterien: "Alle Stakeholder mit Spalte Beziehungsqualität" + primaerer_nutzer: "SHM-Leitung" + + - id: "V-BQ-02" + name: "Interventionsbedarf" + zweck: "Fokus auf Problemfälle" + filterkriterien: "Filter: Beziehungsqualität = Angespannt ODER Kritisch" + primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager" + + - id: "V-BQ-03" + name: "Aktive Maßnahmenpläne" + zweck: "Nachverfolgung laufender Interventionen" + filterkriterien: "Filter: Interventionsdokumentation.Status = Aktiv" + primaerer_nutzer: "SHM-Leitung" + + # ------------------------------------------------------------------------- + # ENGAGEMENT / TURNUS + # ------------------------------------------------------------------------- + + - kategorie: "Engagement und Turnus" + beschreibung: "Planung und Nachverfolgung von Stakeholder-Interaktionen" + + views: + + - id: "V-EN-01" + name: "Anstehende Turnus-Termine" + zweck: "Terminplanung" + filterkriterien: "Filter: Nächster Turnus ≤ 30 Tage" + primaerer_nutzer: "Stakeholder-Manager" + + - id: "V-EN-02" + name: "Überfällige Kontakte" + zweck: "Eskalations-Früherkennung" + filterkriterien: "Filter: Letzter Kontakt > Soll-Frequenz (abgeleitet aus Betreuungsmodus)" + primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager" + + - id: "V-EN-03" + name: "Key-Stakeholder Jahresübersicht" + zweck: "Strategische Betreuungsplanung" + filterkriterien: "Filter: Prio = Key; Anzeige: alle geplanten Termine" + primaerer_nutzer: "SHM-Leitung" + + # ------------------------------------------------------------------------- + # BEDARFSDOKUMENTATION + # ------------------------------------------------------------------------- + + - kategorie: "Bedarfsdokumentation" + beschreibung: "Überblick und Nachverfolgung von Stakeholder-Bedarfen" + + views: + + - id: "V-BD-01" + name: "Offene Bedarfe pro Stakeholder" + zweck: "Gesprächsvorbereitung" + filterkriterien: "Gruppierung nach Amt; Filter: Status ≠ Abgeschlossen" + primaerer_nutzer: "Stakeholder-Manager" + + - id: "V-BD-02" + name: "Bedarfe nach Routing-Pfad" + zweck: "Prozess-Monitoring" + filterkriterien: "Gruppierung nach Routing (REQ/SPM/DPM/SOR)" + primaerer_nutzer: "SHM-Leitung" + + - id: "V-BD-03" + name: "Bedarfe in Wartestellung" + zweck: "Follow-up-Liste" + filterkriterien: "Filter: Status = Übergeben, wartend" + primaerer_nutzer: "Stakeholder-Manager" + + # ------------------------------------------------------------------------- + # REVIEW / REPORTING + # ------------------------------------------------------------------------- + + - kategorie: "Review und Reporting" + beschreibung: "Aggregierte Sichten für E1/E2-Reviews" + + views: + + - id: "V-RV-01" + name: "E2-Quartalsdaten" + zweck: "Vorbereitung Quartalsbericht" + filterkriterien: "Aggregation: Kontakte, Bedarfe, Interventionen im Quartal" + primaerer_nutzer: "SHM-Leitung" + referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e2_quartals_review" + + - id: "V-RV-02" + name: "VoC-Cluster-Übersicht" + zweck: "Feedback-Aggregation" + filterkriterien: "Gruppierung nach Cluster; Anzeige: Ampel-Status" + primaerer_nutzer: "SHM-Leitung" + referenz: "shm_voice-of-customer.yaml → cluster" + + - id: "V-RV-03" + name: "E1-Jahresübersicht" + zweck: "Vorbereitung Jahresbericht" + filterkriterien: "Aggregation aller relevanten Metriken auf Jahresebene" + primaerer_nutzer: "SHM-Leitung" + referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e1_jahres_review" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + beschreibung: | + SIMS steht nicht isoliert, sondern hat konzeptionelle Schnittstellen + zu anderen Informationssystemen und Funktionen. Diese Schnittstellen + sind zunächst als Informationsflüsse zu verstehen, nicht als + technische Integrationen. + + schnittstellen: + + - id: "SS-01" + name: "DPM (Demand-Portfolio-Management)" + + richtung: "SIMS → DPM" + + beschreibung: | + Bei Routing-Entscheidung ROUTE-DPM wird der Bedarfssteckbrief + an DPM übergeben. DPM übernimmt dann die weitere Bearbeitung + im Demand-Lifecycle. + + uebergabeobjekt: "Bedarfssteckbrief (IO-02)" + + informationsfluss: + von_sims: + - "Bedarfssteckbrief mit Stakeholder-Kontext" + - "User Stories (falls erhoben)" + von_dpm: + - "Status-Updates zum Demand" + - "Entscheidungen (DSR/MB)" + + governance_referenz: "shm_d2p-integration.yaml" + + - id: "SS-02" + name: "SPM (Service-Portfolio-Management)" + + richtung: "Bidirektional" + + beschreibung: | + SPM liefert Service-Performance-Daten, die für Turnus-Gespräche + und Beziehungsqualitäts-Bewertung relevant sind. SHM liefert + Kundenfeedback und Bedarfe im Service-Kontext. + + informationsfluss: + von_spm: + - "SLA-Einhaltung pro Amt/Service" + - "Bekannte Service-Probleme" + - "Service-Änderungen (für proaktive Kommunikation)" + von_sims: + - "VoC-Feedback zu Services" + - "Bedarfssteckbriefe (bei ROUTE-SPM)" + + hinweis: | + Der Informationsfluss erfolgt im MVP manuell (Abfrage vor + Turnus-Gespräch). Eine technische Integration ist optional. + + - id: "SS-03" + name: "Ticket-System (Service Desk)" + + richtung: "Ticket-System → SIMS (lesend)" + + beschreibung: | + Für Turnus-Gespräche und Beziehungsqualitäts-Bewertung sind + Informationen zu offenen Tickets pro Amt relevant. + + informationsfluss: + von_ticketsystem: + - "Anzahl offener Tickets pro Amt" + - "Eskalierte Tickets" + - "Wiederkehrende Probleme" + von_sims: + - "(kein direkter Rückfluss)" + + hinweis: | + Im MVP erfolgt die Abfrage manuell. Eine automatisierte + Einspielung ist bei entsprechendem Tooling möglich. + +# ============================================================================= +# GOVERNANCE +# ============================================================================= + +governance: + + beschreibung: | + Regeln für Datenpflege, Qualitätssicherung und Verantwortlichkeiten + im SIMS. + + datenpflege: + + prinzip: | + Jeder Datensatz hat genau einen Verantwortlichen für die Pflege. + Die Verantwortung folgt der Betreuungszuordnung. + + verantwortlichkeiten: + + - objekt: "Amts-Steckbrief" + verantwortlich: "Zugeordneter Stakeholder-Manager" + aktualisierung: "Laufend, mindestens bei Turnus-Gespräch" + + - objekt: "Bedarfssteckbrief" + verantwortlich: "Erfassender Stakeholder-Manager" + aktualisierung: "Bei Status-Änderungen" + + - objekt: "Gesprächsprotokoll" + verantwortlich: "Durchführender Stakeholder-Manager" + aktualisierung: "Innerhalb von 5 Arbeitstagen nach Gespräch" + + - objekt: "Interventionsdokumentation" + verantwortlich: "Zugeordneter Stakeholder-Manager" + aktualisierung: "Laufend während Intervention" + + - objekt: "VoC-Feedback-Eintrag" + verantwortlich: "Erfassender Stakeholder-Manager" + aktualisierung: "Bei Erfassung (einmalig)" + + qualitaetssicherung: + + - id: "QS-01" + name: "Vollständigkeitsprüfung Stammdaten" + beschreibung: "Prüfung auf vollständige Pflichtfelder im Amts-Steckbrief" + frequenz: "Quartalsweise (im Rahmen E2)" + verantwortlich: "SHM-Leitung" + referenz: "shm_schema_amtssteckbrief.yaml → validierung" + + - id: "QS-02" + name: "Aktualitätsprüfung" + beschreibung: "Identifikation von Datensätzen ohne Aktualisierung > 12 Monate" + frequenz: "Halbjährlich" + verantwortlich: "SHM-Leitung" + + - id: "QS-03" + name: "Konsistenzprüfung Prio/Betreuungsmodus" + beschreibung: "Prüfung, ob Betreuungsmodus zur Prio-Stufe passt" + frequenz: "Quartalsweise (im Rahmen E2)" + verantwortlich: "SHM-Leitung" + referenz: "shm_schema_amtssteckbrief.yaml → validierung VAL-003" + + archivierung: + + prinzip: | + Abgeschlossene Objekte (erledigte Bedarfe, beendete Interventionen) + werden nicht gelöscht, sondern archiviert. Sie bleiben für + Nachvollziehbarkeit und Trendanalysen zugänglich. + + aufbewahrungsfristen: + - objekt: "Amts-Steckbrief" + frist: "Dauerhaft (solange Amt im Portfolio)" + - objekt: "Bedarfssteckbrief" + frist: "5 Jahre nach Abschluss" + - objekt: "Gesprächsprotokoll" + frist: "5 Jahre" + - objekt: "Interventionsdokumentation" + frist: "5 Jahre nach Abschluss" + - objekt: "VoC-Feedback-Eintrag" + frist: "3 Jahre" + + hinweis: | + Die Fristen sind initiale Vorschläge und ggf. an organisatorische + oder rechtliche Vorgaben anzupassen. + +# ============================================================================= +# EINFÜHRUNGSHINWEISE +# ============================================================================= + +einfuehrung: + + beschreibung: | + Hinweise für die Einführung des SIMS in den operativen Betrieb. + + empfohlenes_vorgehen: + + - phase: "1. Toolauswahl" + beschreibung: | + Auswahl eines geeigneten Werkzeugs basierend auf den + fachlichen Anforderungen dieses Konzepts. + kriterien: + - "Unterstützung strukturierter Datenerfassung" + - "Flexible View-/Filtermöglichkeiten" + - "Verlinkung zwischen Objekten" + - "Zugänglichkeit für alle SHM-Mitarbeitenden" + + - phase: "2. Pilotierung" + beschreibung: | + Erprobung mit einer Teilmenge des Portfolios (z.B. ein Dezernat) + vor vollständigem Rollout. + ziel: "Validierung der Struktur und Views" + + - phase: "3. Initiale Befüllung" + beschreibung: | + Migration/Erfassung der Bestandsdaten für alle Stakeholder. + hinweis: "Qualität vor Vollständigkeit bei der Erstbefüllung" + + - phase: "4. Schulung" + beschreibung: | + Einweisung aller Stakeholder-Manager in Struktur und Nutzung. + + - phase: "5. Review und Anpassung" + beschreibung: | + Nach 6 Monaten Betrieb: Review der Views und Struktur, + Anpassung basierend auf Praxiserfahrung. + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-11" + autor: "Konzept-Sprint Phase 10" + aenderung: | + Initiale Erstellung: + - Meta-Informationen und Design-Prinzipien + - Informationsobjekte IO-01 bis IO-05 definiert + - Strukturkonzept mit 4 Bereichen + - 16 Views in 5 Kategorien (als Vorschlag) + - Konzeptionelle Schnittstellen zu DPM, SPM, Ticket-System + - Governance (Datenpflege, QS, Archivierung) - Einführungshinweise \ No newline at end of file diff --git a/#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml b/#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml index 30889a0..21217d9 100644 --- a/#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml +++ b/#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml @@ -1,950 +1,950 @@ -# ============================================================================= -# SHM STAKEHOLDER-PORTFOLIO: KONZEPT -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Funktion: Konzepte -# Version: 1.3 -# Datum: 2026-01-23 -# Status: Final -# ============================================================================= - -meta: - modul_id: "SHM-K-01" - name: "Stakeholder-Portfolio" - typ: "Konzept" - - zweck: | - Das Stakeholder-Portfolio ist das zentrale Steuerungsinstrument des - Stakeholder-Managements. Es erfasst alle Organisationseinheiten im - Kundenkreis von DIGIT, segmentiert sie nach relevanten Dimensionen - und priorisiert sie für die Ressourcenallokation. - - Das Portfolio ist kein Selbstzweck, sondern ein Entscheidungsinstrument. - Seine Struktur folgt aus den Entscheidungen, die es unterstützen soll. - - scope: | - Alle Organisationseinheiten im Dezernatsverteilungsplan der Stadt: - - Ämter - - Eigenbetriebe - - Referate - - Stabsstellen - - Projektgruppen - - governance_referenzen: - - "GOV-SHM-001 bis GOV-SHM-014" - - "readme_shm_governance-entscheidungs-log.yaml" - - schema_referenz: - dokument: "shm_schema_amtssteckbrief.yaml" - beschreibung: "Technisches Attribut-Schema für die Datenerfassung pro Amt" - -# ============================================================================= -# FUNKTIONALE HERLEITUNG -# ============================================================================= - -funktionale_herleitung: - - leitfrage: | - Welche Entscheidungen soll das Stakeholder-Portfolio ermöglichen? - - kernentscheidungen: - - - id: PKE-1 - name: "Betreuungsallokation" - leitfrage: "Wer wird wie intensiv betreut?" - kontext: | - Ressourcenknappheit erfordert Priorisierung. Nicht alle Ämter - können gleich intensiv betreut werden. Das Portfolio muss helfen, - die Betreuungsintensität systematisch zu differenzieren. - unterstuetzt_durch: - - "Priorisierung (Ebene 3)" - - "Betreuungsmodus-Ableitung" - - - id: PKE-2 - name: "Bedarfsrouting" - leitfrage: "Wohin gehört dieser Bedarf?" - kontext: | - Wenn ein Bedarf eingeht, muss SHM entscheiden: Ist das ein - Service-Request (→ Katalog), ein Change an bestehendem Service - (→ Service Owner), oder ein neuer Demand (→ DPM)? Das Wissen - über den Stakeholder und sein typisches Bedarfsprofil beeinflusst - diese Einordnung. - unterstuetzt_durch: - - "Segmentierung (Ebene 2)" - - "Funktion + IT-Anforderungsprofil" - - - id: PKE-3 - name: "Governance-Zuordnung" - leitfrage: "Wer sitzt in welchem Gremium?" - kontext: | - Für SLAs (Kundenvertretungen), für Bedarfspriorisierung (DSR), - für strategische Abstimmung braucht es Zuordnungslogiken. - Das IT-Anforderungsprofil korrespondiert mit den SPM-Service- - Kategorien und damit mit der Gremienstruktur. - unterstuetzt_durch: - - "IT-Anforderungsprofil → SPM-Kategorie-Mapping" - - "SLA-Befugnis im Amts-Steckbrief" - -# ============================================================================= -# DREI-EBENEN-MODELL -# ============================================================================= - -drei_ebenen_modell: - - beschreibung: | - Das Portfolio ist in drei Ebenen strukturiert, die aufeinander aufbauen: - - 1. Amts-Steckbrief – Datengrundlage pro Organisationseinheit - 2. Segmentierung – Clustering nach zwei unabhängigen Dimensionen - 3. Priorisierung – Bewertung zur Ableitung des Betreuungsmodus - - Ergänzend: Der Betreuungsstatus (Stammdaten) dokumentiert, ob eine - Zusammenarbeit mit dem Amt überhaupt möglich ist – unabhängig von - dessen Wichtigkeit (Priorisierung). - - governance_referenz: "GOV-SHM-001" - -# ============================================================================= -# BETREUUNGSSTATUS-KONZEPT -# ============================================================================= - -betreuungsstatus_konzept: - - beschreibung: | - Der Betreuungsstatus ist ein Stammdatum (nicht Teil der Priorisierung), - das dokumentiert, ob eine Zusammenarbeit mit einem Amt möglich ist. - - Hintergrund: - Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) - beantworten die Frage "Wie wichtig ist das Amt?". Sie beantworten - nicht "Können wir mit dem Amt zusammenarbeiten?" - - Beispiele für eingeschränkte Zusammenarbeit: - - Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung - - Amt X: Schwierige Beziehung, Zugang erschwert - - Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit), - aber die Betreuungslogik muss die Realität abbilden. - - governance_referenz: "GOV-SHM-028" - schema_referenz: "shm_schema_amtssteckbrief.yaml → stammdaten.betreuungsstatus" - - auspraegungen: - - - id: "AKTIV" - name: "Aktiv" - beschreibung: | - Zusammenarbeit möglich. Normale Priorisierung greift, - Betreuungsmodus wird direkt aus Prio-Stufe abgeleitet. - konsequenz: "effektiver_betreuungsmodus = betreuungsmodus (aus Prio-Stufe)" - - - id: "EINGESCHRAENKT" - name: "Eingeschränkt" - beschreibung: | - Zusammenarbeit nur punktuell möglich. Priorisierung greift, - aber Betreuungsmodus wird auf individuell festgelegtes - Maximum gedeckelt. - konsequenz: | - effektiver_betreuungsmodus = MIN(betreuungsmodus, max_betreuungsmodus) - Beispiel: Key-Stakeholder mit max_betreuungsmodus REGELMAESSIG - → effektiver_betreuungsmodus = REGELMAESSIG (nicht PROAKTIV_DEDIZIERT) - pflichtfelder: - - "begruendung (min. 30 Zeichen)" - - "max_betreuungsmodus" - - "entschieden_von" - - "entschieden_am" - - - id: "RUHEND" - name: "Ruhend" - beschreibung: | - Aktuell keine Zusammenarbeit möglich. Amt bleibt im - Portfolio dokumentiert, aber außerhalb aktiver Betreuung. - Priorisierung wird trotzdem erfasst (für Reaktivierung). - konsequenz: "effektiver_betreuungsmodus = KEINE_AKTIVE_BETREUUNG" - pflichtfelder: - - "begruendung (min. 30 Zeichen)" - - "entschieden_von" - - "entschieden_am" - - vorteile: - - "Vollständigkeit: Alle Ämter bleiben im Portfolio dokumentiert" - - "Flexibilität: Bei Statusänderung einfache Umstellung" - - "Saubere Priorisierung: Nur Wichtigkeit, nicht Machbarkeit" - - "Reporting: Filter nach 'aktiv betreute Ämter' vs. 'Gesamtportfolio'" - - "Transparenz: Gründe für eingeschränkte Zusammenarbeit dokumentiert" - - entscheidungsbefugnis: - rolle: "Leitung SHM" - begruendung: | - Die Entscheidung, ein Amt als 'ruhend' oder 'eingeschränkt' zu - klassifizieren, hat strategische Konsequenzen und sollte nicht - willkürlich getroffen werden. Die Leitung SHM hat den Gesamtüberblick - über das Portfolio und kann die Entscheidung im Kontext bewerten. - dokumentation: | - Jede Entscheidung muss dokumentiert werden: - - Wer hat entschieden (entschieden_von) - - Wann wurde entschieden (entschieden_am) - - Warum (begruendung) - - Wann wird der Status überprüft (naechste_pruefung, empfohlen) - - review: - zyklus: "Im Portfolio-Review (E2-Standard/Erweitert)" - inhalt: | - Bei jedem Portfolio-Review wird geprüft: - - Sind EINGESCHRÄNKT- und RUHEND-Status noch aktuell? - - Haben sich Rahmenbedingungen geändert? - - Sollten Ämter reaktiviert werden? - -# ============================================================================= -# EBENE 1: AMTS-STECKBRIEF -# ============================================================================= - -ebene_1_amtssteckbrief: - - beschreibung: | - Jede Organisationseinheit im Scope erhält einen Amts-Steckbrief. - Dieser enthält alle Informationen, die für die drei Kernentscheidungen - (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung) benötigt - werden. - - herleitung: | - Die Attribute des Steckbriefs sind nicht willkürlich gewählt, sondern - leiten sich aus den Kernentscheidungen ab. Jedes Attribut muss - mindestens eine der drei Entscheidungen unterstützen. Attribute ohne - klaren Entscheidungsbezug werden nicht erfasst. - - attribut_kategorien: - - - kategorie: "Stammdaten" - zweck: "Identifikation und organisatorische Einordnung" - entscheidungsbezug: "Alle (PKE-1, PKE-2, PKE-3)" - beispiele: - - "Amt/Organisationseinheit" - - "Dezernat" - - "Amtsleitung" - - "SLA-Befugnis (wer hat Entscheidungsbefugnis)" - - - kategorie: "Segmentierung" - zweck: "Einordnung in die zweidimensionale Matrix" - entscheidungsbezug: "PKE-2 Bedarfsrouting, PKE-3 Governance" - beispiele: - - "Funktion (Sondereinheit/Querschnitt/Bürgerservice/Fachamt)" - - "IT-Anforderungsprofil (Basis/Erweitert/Spezial)" - - - kategorie: "Priorisierung" - zweck: "Bewertung für Betreuungsallokation" - entscheidungsbezug: "PKE-1 Betreuungsallokation" - beispiele: - - "Einfluss (boolean)" - - "Abhängigkeit (boolean)" - - "Relevanz (boolean)" - - "Prio-Stufe (abgeleitet)" - - "Betreuungsmodus (abgeleitet)" - - - kategorie: "Governance" - zweck: "Gremien-Zuordnung und Vertretungslogik" - entscheidungsbezug: "PKE-3 Governance-Zuordnung" - beispiele: - - "Gremien-Mitgliedschaften" - - - kategorie: "Betreuung" - zweck: "Operative Beziehungspflege" - entscheidungsbezug: "E1 Betreuungsallokation" - beispiele: - - "Zugeordneter Stakeholder-Manager" - - "Beziehungsqualität" - - "Aktive Themen" - - schema_verweis: | - Das vollständige Attribut-Schema mit Datentypen, Wertelisten und - Validierungsregeln ist in shm_schema_amtssteckbrief.yaml dokumentiert. - -# ============================================================================= -# EBENE 2: SEGMENTIERUNG -# ============================================================================= - -ebene_2_segmentierung: - - beschreibung: | - Die Segmentierung erfolgt zweidimensional. Beide Dimensionen sind - unabhängig voneinander. Jedes Amt erhält genau eine Ausprägung pro - Dimension (keine Mehrfachzuordnung, keine Tags). - - governance_referenz: "GOV-SHM-002" - - # --------------------------------------------------------------------------- - # DIMENSION 1: FUNKTION - # --------------------------------------------------------------------------- - - dimension_1_funktion: - - name: "Funktion" - beschreibung: "Organisatorische Rolle des Amtes in der Stadtverwaltung" - - governance_referenz: "GOV-SHM-003" - - auspraegungen: - - - id: "SONDER" - name: "Sondereinheit" - charakteristik: | - Organisatorisch eigenständig, eigene Rechtsform oder - Sonderstatus (Eigenbetriebe, Stabsstellen, Projektgruppen) - beispiele: - - "Eigenbetrieb Stadtentwässerung" - - "Eigenbetrieb Theater" - - "Stabsstelle Digitalisierung" - - - id: "QUER" - name: "Querschnittsamt" - charakteristik: | - Erbringt interne Dienstleistungen für andere Ämter, - hat Multiplikator-Wirkung - beispiele: - - "Haupt- und Personalamt" - - "Stadtkämmerei" - - "Rechtsamt" - - - id: "BUERGER" - name: "Bürgerservice" - charakteristik: | - Direkter Bürgerkontakt als Kernaufgabe, - hohe externe Sichtbarkeit - beispiele: - - "Amt für Bürgerservice" - - "Standesamt" - - "Amt für Soziales" - - - id: "FACH" - name: "Fachamt" - charakteristik: | - Spezialisierte Fachaufgaben, oft technisch geprägt, - geringerer direkter Bürgerkontakt - beispiele: - - "Stadtplanungsamt" - - "Garten- und Tiefbauamt" - - "Umweltschutzamt" - - zuordnungslogik: - - grundprinzip: | - Die Funktionszuordnung unterscheidet zwischen Primärfunktion - (steuernd) und Sekundärfunktion (informierend). - - - Primärfunktion: Bestimmt Bedarfsrouting und Governance-Zuordnung - - Sekundärfunktion: Dokumentiert Kontext für differenzierte Betrachtung - - Nicht jedes Amt hat eine Sekundärfunktion. Sie wird nur vergeben, - wenn ein Amt deutlich erkennbare Charakteristika einer zweiten - Funktionskategorie aufweist. - - governance_referenz: "GOV-SHM-027" - - # ----------------------------------------------------------------------- - # PRIMÄRFUNKTIONSBESTIMMUNG - # ----------------------------------------------------------------------- - - primaerfunktion: - - beschreibung: | - Die Primärfunktion wird durch einen Entscheidungsbaum bestimmt. - Die erste zutreffende Kategorie gewinnt (Dominanzprinzip). - - entscheidungsbaum: - - schritt_1: - frage: "Ist das Amt organisatorisch eigenständig?" - indikatoren: - - "Eigene Rechtsform (Eigenbetrieb)" - - "Sonderstatus (Stabsstelle, Projektgruppe)" - - "Nicht in regulärer Amtsstruktur eingegliedert" - ja: "SONDER (Sondereinheit)" - nein: "weiter zu Schritt 2" - - schritt_2: - frage: "Erbringt das Amt primär interne Dienstleistungen für andere Ämter?" - indikatoren: - - "Hauptaufgabe ist Unterstützung anderer Ämter" - - "Querschnittsfunktion (Personal, Finanzen, Recht, IT, Organisation)" - - "Multiplikator-Wirkung auf andere Ämter" - ja: "QUER (Querschnittsamt)" - nein: "weiter zu Schritt 3" - - schritt_3: - frage: "Hat das Amt direkten Bürgerkontakt als Kernaufgabe?" - indikatoren: - - "Publikumsverkehr ist zentrale Aufgabe" - - "Bürger:innen sind primäre Zielgruppe" - - "Hohe externe Sichtbarkeit durch Bürger-Interaktion" - ja: "BUERGER (Bürgerservice)" - nein: "FACH (Fachamt)" - - entscheidungshilfe_bei_mehrdeutigkeit: | - Wenn ein Amt mehrere Charakteristika erfüllt, gilt: - - 1. Dominanzprinzip anwenden: Die erste zutreffende Kategorie - im Entscheidungsbaum bestimmt die Primärfunktion. - - 2. Hauptaufgabe identifizieren: Was ist der Kern-Auftrag des Amtes - laut Dezernatsverteilungsplan oder Geschäftsverteilungsplan? - - 3. Ressourcenallokation prüfen: Wohin fließen die meisten Ressourcen - (Personal, Budget, Zeit)? - - 4. Selbstverständnis einbeziehen: Wie beschreibt das Amt selbst - seine Hauptaufgabe? - - Beispiel Stadtkämmerei: - - Erfüllt Querschnitts-Kriterien (Finanzdienstleistungen für alle Ämter) - - Hat auch Fachamt-Charakteristika (spezialisierte Haushaltsführung) - → Primärfunktion: QUER (Querschnittsamt), da interne Dienstleistung - die Kernaufgabe ist - - # ----------------------------------------------------------------------- - # SEKUNDÄRFUNKTIONSBESTIMMUNG - # ----------------------------------------------------------------------- - - sekundaerfunktion: - - beschreibung: | - Die Sekundärfunktion dokumentiert eine zusätzliche Funktions- - charakteristik, die für Kontext und differenzierte Betrachtung - relevant ist. - - vergabe_kriterien: | - Eine Sekundärfunktion wird vergeben, wenn: - - 1. Das Amt deutlich erkennbare Charakteristika einer zweiten - Funktionskategorie aufweist (nicht nur marginal) - - 2. Diese zweite Funktion für Bedarfsrouting oder Governance - relevant sein kann (z.B. Bedarfe, die eher zur Sekundär- - funktion passen) - - 3. Die Zuordnung nachvollziehbar begründet werden kann - - nicht_vergeben_wenn: | - Keine Sekundärfunktion, wenn: - - - Das Amt klar einer einzigen Kategorie zuzuordnen ist - - Die zweite Charakteristik nur marginal ausgeprägt ist - - Kein praktischer Nutzen für Routing oder Governance erkennbar ist - - moegliche_kombinationen: - - - primaer: "QUER" - sekundaer: "FACH" - typisch: true - beispiel: "Stadtkämmerei (Querschnitt + spezialisierte Haushaltsführung)" - - - primaer: "QUER" - sekundaer: "BUERGER" - typisch: false - beispiel: "Haupt- und Personalamt mit Bürgerbüro-Funktion" - - - primaer: "BUERGER" - sekundaer: "FACH" - typisch: true - beispiel: "Amt für Soziales (Bürgerservice + spezialisierte Sozialarbeit)" - - - primaer: "FACH" - sekundaer: "BUERGER" - typisch: true - beispiel: "Baurechtsamt (Fachamt + Bauberatung für Bürger:innen)" - - - primaer: "FACH" - sekundaer: "QUER" - typisch: false - beispiel: "IT-Amt mit internen Dienstleistungen (eher selten)" - - - primaer: "SONDER" - sekundaer: "beliebig" - typisch: true - beispiel: "Eigenbetrieb mit Bürgerservice-Anteil" - - ausgeschlossene_kombinationen: - - kombination: "gleiche Primär- und Sekundärfunktion" - grund: "Logisch unmöglich" - - # ----------------------------------------------------------------------- - # OPERATIVE ANWENDUNG - # ----------------------------------------------------------------------- - - operative_anwendung: - - verwendung_primaerfunktion: - - "Bedarfsrouting (PKE-2): Bestimmt typisches Bedarfsprofil" - - "Governance-Zuordnung (PKE-3): Bestimmt Gremien-Mitgliedschaften" - - "Betreuungsallokation (PKE-1): Kontextinformation für Priorisierung" - - verwendung_sekundaerfunktion: - - "Bedarfsrouting: Differenzierte Betrachtung bei Bedarfen, die eher - zur Sekundärfunktion passen" - - "Governance: Optionale Einbindung in Gremien der Sekundärkategorie" - - "Bedarfsvorhersage: Vollständigeres Bild des typischen Bedarfsprofils" - - "Transparenz: Dokumentation für Nachvollziehbarkeit" - - steuerungsprinzip: | - Primärfunktion steuert, Sekundärfunktion informiert. - - Bei Entscheidungen (Routing, Governance) ist die Primärfunktion - maßgeblich. Die Sekundärfunktion kann bei begründeten Ausnahmen - herangezogen werden, überschreibt aber nie die Primärfunktion. - - dokumentationspflicht: | - Bei Vergabe einer Sekundärfunktion muss im Amts-Steckbrief eine - Begründung dokumentiert werden, die erklärt: - - Warum das Amt Charakteristika der Sekundärkategorie aufweist - - Welche praktische Relevanz die Sekundärfunktion hat - - # --------------------------------------------------------------------------- - # DIMENSION 2: IT-ANFORDERUNGSPROFIL - # --------------------------------------------------------------------------- - - dimension_2_it_profil: - - name: "IT-Anforderungsprofil" - beschreibung: | - Komplexität der IT-Bedarfe des Amtes. Die Dimension ist - bedarfsorientiert (nicht nutzungsorientiert), um zukünftige - Bedarfe vorherzusagen, nicht nur den Status quo abzubilden. - - governance_referenz: "GOV-SHM-004" - - auspraegungen: - - - id: "BASIS" - name: "Basis" - charakteristik: | - Standardbedarf, Grundausstattung reicht aus, - geringe IT-Komplexität - spm_korrespondenz: "Kategorie A – Basis-Services" - typische_services: - - "Standard-Arbeitsplatz (Büro-PC, Office-Anwendungen)" - - "E-Mail und Kalender" - - "Zugang zu zentralen Verwaltungssystemen" - beispiele: - - "Rechtsamt" - - "Rechnungsprüfungsamt" - - "Standesamt" - - - id: "ERWEITERT" - name: "Erweitert" - charakteristik: | - Fachspezifische Bedarfe über Standard hinaus, - mittlere IT-Komplexität. Häufig: Benötigt Zugriff auf - Daten im Außendienst – erbringt einen erheblichen Teil - der Arbeit außerhalb des Bürostandorts und benötigt dabei - Zugriff auf städtische oder weitere relevante Daten - (Baupläne, Elektropläne, Meldedaten, KFZ-Daten etc.). - spm_korrespondenz: "Kategorie B – Erweiterte Services" - typische_services: - - "Mobile Hardware (VPN-Notebook, EC-Cash-Gerät etc.)" - - "Zugriffe auf interne Daten außerhalb vom Bürostandort" - - "Fachverfahren mit erweitertem Funktionsumfang" - - "DMS, Terminbuchung, Workflow-Systeme" - beispiele: - - "Haupt- und Personalamt" - - "Amt für Bürgerservice" - - "Umweltschutzamt" - - - id: "SPEZIAL" - name: "Spezial" - charakteristik: | - Individuelle Bedarfe, die nur für dieses Amt gelten, - hohe IT-Komplexität, Spezialsoftware, bilaterale SLAs. - Arbeiten aus dem Homeoffice oft nur durch besondere - Lösungen möglich (Standard-Homeoffice-Lösungen greifen nicht). - spm_korrespondenz: "Kategorie C – Spezial-Services" - typische_services: - - "Exklusive Fachsoftware (CAD, GIS, Spezialsysteme)" - - "Spezialhardware (Plotter, Messgeräte, Spezialdrucker)" - - "Individuelle Schnittstellenlösungen" - - "Besondere Homeoffice-/Remote-Lösungen" - beispiele: - - "Stadtplanungsamt (CAD, GIS)" - - "Garten- und Tiefbauamt" - - "Immobilienmanagement (Eigenbetrieb)" - - zuordnungslogik: | - Entscheidungsbaum: - - 1. Hat das Amt individuelle IT-Bedarfe, die NUR für dieses Amt - gelten? (exklusive Fachsoftware, Spezialhardware, bilaterale SLAs) - → JA: Spezial - → NEIN: weiter zu 2. - - 2. Hat das Amt fachspezifische IT-Bedarfe über die Grundausstattung - hinaus? (DMS, Fachverfahren, Terminbuchung, Workflow-Systeme) - → JA: Erweitert - → NEIN: Basis - - # --------------------------------------------------------------------------- - # MATRIX - # --------------------------------------------------------------------------- - - matrix: - - beschreibung: | - Die Kombination der beiden Dimensionen ergibt eine 4×3-Matrix. - Jedes Amt wird genau einem Feld zugeordnet. Nicht alle - Kombinationen sind gleich häufig oder wahrscheinlich. - - governance_referenz: "GOV-SHM-006" - - hinweis_sondereinheiten: | - Sondereinheiten sind eine Funktionskategorie, keine Ausnahme - von der zweidimensionalen Logik. Sie haben wie alle anderen - Ämter ein IT-Anforderungsprofil. - - unwahrscheinliche_kombinationen: - - kombination: "Querschnitt + Spezial" - begruendung: | - Querschnittsämter erbringen standardisierte interne Services. - Hochspezialisierte IT-Bedarfe sind untypisch. - - kombination: "Bürgerservice + Spezial" - begruendung: | - Bürgerservice-Ämter nutzen typischerweise standardisierte - Bürger-Fachverfahren, keine exklusiven Spezial-Lösungen. - - # --------------------------------------------------------------------------- - # VERKNÜPFUNG ZU ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - verknuepfung_entscheidungen: - - bedarfsrouting_PKE2: - relevante_dimensionen: "Funktion + IT-Profil" - logik: | - Die Kombination hilft, typische Bedarfe vorherzusagen: - - Bürgerservice + Erweitert → Terminbuchung, Aufrufsysteme, DMS - - Fachamt + Spezial → CAD, GIS, Spezialhardware - - Querschnitt + Erweitert → Personalverwaltung, Finanz-Systeme - - governance_zuordnung_PKE3: - relevante_dimension: "IT-Anforderungsprofil" - logik: | - Das IT-Profil korrespondiert mit SPM-Kategorien und damit - mit der SLA-Governance: - - Basis-Profil → primär in Kundenvertretung Basisservices (Kat. A) - - Erweitert-Profil → in servicespezifischen Kundenvertretungen (Kat. B) - - Spezial-Profil → bilaterale SLAs (Kat. C) - -# ============================================================================= -# EBENE 3: PRIORISIERUNG -# ============================================================================= - -ebene_3_priorisierung: - - beschreibung: | - Die Priorisierung identifiziert innerhalb der Segmente die - Key-Stakeholder und leitet den Betreuungsmodus ab. Sie basiert - auf drei Dimensionen, die binär (ja/nein) bewertet werden. - - # --------------------------------------------------------------------------- - # DIMENSIONEN - # --------------------------------------------------------------------------- - - dimensionen: - - governance_referenz: "GOV-SHM-007" - - bewertungslogik: | - Jede Dimension wird binär bewertet (ja/nein). Die Bewertung - erfolgt durch den Stakeholder-Manager mit dokumentierter - Begründung. Die Begründung macht die Einschätzung - nachvollziehbar und überprüfbar. - - dimension_1_einfluss: - - id: "E" - name: "Einfluss" - leitfrage: "Kann das Amt DIGIT-relevante Entscheidungen beeinflussen?" - - indikatoren: - - "Entscheidungsbefugnis über IT-Budgets oder IT-Standards" - - "Multiplikator-Rolle durch Größe oder Querschnittsfunktion" - - "Politisches Gewicht in Verwaltungsgremien" - - beispiele_ja: - - "Haupt- und Personalamt (IT-Standards für alle)" - - "Stadtkämmerei (IT-Budget-Allokation)" - - beispiele_nein: - - "Standesamt (kein übergreifender Einfluss)" - - dimension_2_abhaengigkeit: - - id: "A" - name: "Abhängigkeit" - leitfrage: "Steht das Amt ohne IT still?" - - indikatoren: - - "Kernprozesse sind IT-abhängig" - - "Externe Schnittstellen setzen funktionierende IT voraus" - - "IT-Ausfall führt zu unmittelbarem Leistungsausfall" - - beispiele_ja: - - "Amt für Bürgerservice (alle Prozesse IT-basiert)" - - "Stadtkasse (Zahlungsverkehr)" - - beispiele_nein: - - "Kulturamt (kann temporär analog arbeiten)" - - dimension_3_relevanz: - - id: "R" - name: "Relevanz" - leitfrage: "Ist das Amt gerade besonders wichtig für die Gesamtverwaltung?" - - indikatoren: - - "Hohe politische oder öffentliche Sichtbarkeit" - - "Beteiligung an strategischen Projekten" - - "Aktuelle Krisensituation oder Transformationsphase" - - charakteristik: | - Diese Dimension ist dynamisch und kann sich über Zeit ändern. - Sie erfordert regelmäßige Überprüfung im Portfolio-Review. - - beispiele_ja: - - "Amt für Digitalisierung (strategisches Projekt)" - - "Amt für öffentliche Ordnung (bei Großveranstaltungen)" - - beispiele_nein: - - "Forstamt (stabile Situation, geringe Sichtbarkeit)" - - # --------------------------------------------------------------------------- - # GEWICHTUNG - # --------------------------------------------------------------------------- - - gewichtung: - - governance_referenz: "GOV-SHM-008" - - logik: | - Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt - beeinflussen können – sei es durch Budget-Entscheidungen, - Standard-Setzung oder politisches Gewicht. - - Gewichtung: Einfluss > Abhängigkeit = Relevanz - - begruendung: | - Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen - von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist - strategisch wichtiger als zu Ämtern, die "nur" abhängig sind. - - # --------------------------------------------------------------------------- - # KOMBINATIONSLOGIK - # --------------------------------------------------------------------------- - - kombinationslogik: - - governance_referenz: "GOV-SHM-009" - - prio_stufen: - - - stufe: "Key" - kombination: "Alle drei ODER Einfluss + eine weitere" - beschreibung: "Strategisch wichtigste Stakeholder" - - - stufe: "Aktiv" - kombination: "Zwei (ohne Einfluss) ODER nur Einfluss" - beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung" - - - stufe: "Standard" - kombination: "Eine (Abhängigkeit oder Relevanz)" - beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf" - - - stufe: "Basis" - kombination: "Keine Dimension erfüllt" - beschreibung: "Stakeholder mit reaktiver Betreuung" - - kombinationstabelle: | - - │ E │ A │ R │ Prio-Stufe │ - ├───┼───┼───┼────────────┤ - │ ✓ │ ✓ │ ✓ │ Key │ - │ ✓ │ ✓ │ – │ Key │ - │ ✓ │ – │ ✓ │ Key │ - │ – │ ✓ │ ✓ │ Aktiv │ - │ ✓ │ – │ – │ Aktiv │ - │ – │ ✓ │ – │ Standard │ - │ – │ – │ ✓ │ Standard │ - │ – │ – │ – │ Basis │ - - Legende: E = Einfluss, A = Abhängigkeit, R = Relevanz - - # --------------------------------------------------------------------------- - # BETREUUNGSMODUS - # --------------------------------------------------------------------------- - - betreuungsmodus: - - governance_referenz: "GOV-SHM-010" - - beschreibung: | - Der Betreuungsmodus wird aus der Prio-Stufe abgeleitet und - definiert die Art und Intensität der Stakeholder-Betreuung. - - modi: - - - prio_stufe: "Key" - modus: "Proaktiv/Dediziert" - beschreibung: | - Regelmäßige Turnusgespräche (z.B. halbjährlich), - dedizierter Stakeholder-Manager, - aktive Bedarfserhebung, - Einladung zu strategischen Abstimmungen - - - prio_stufe: "Aktiv" - modus: "Regelmäßig" - beschreibung: | - Teilnahme am Cluster-Advisory-Board, - anlassbezogene Gespräche, - Einladung zu relevanten Themen - - - prio_stufe: "Standard" - modus: "Eingebunden" - beschreibung: | - Teilnahme am Cluster-Advisory-Board, - reaktive Betreuung bei Anfragen - - - prio_stufe: "Basis" - modus: "Reaktiv" - beschreibung: | - Keine proaktive Betreuung, - nur bei eingehenden Anfragen, - Information über allgemeine Kanäle - - # --------------------------------------------------------------------------- - # ÜBERPRÜFUNG - # --------------------------------------------------------------------------- - - ueberpruefung: - - governance_referenz: "GOV-SHM-012" - - beschreibung: | - Die Priorisierung wird periodisch überprüft, insbesondere - die Dimension "Relevanz", die sich über Zeit ändern kann. - - zyklus: | - Im Rahmen der Koordinations- und Steuerungsstruktur - (shm_koordinations-und-steuerungsstruktur.yaml): - - REV-2-Standard (Q1/Q3): Portfolio-Analyse - - REV-2-Erweitert (Q2/Q4): Portfolio-Analyse + Verbesserungsplanung - - voc_integration: | - Die Portfolio-Überprüfung nutzt VoC-Erkenntnisse (shm_voice-of-customer.yaml) - zu Beziehungsqualität, Zufriedenheit und Bedarfsentwicklung, um - Priorisierungen und Betreuungsmodi anzupassen. - - stabilität_der_dimensionen: - einfluss: "Relativ stabil (Organisationsstruktur)" - abhaengigkeit: "Relativ stabil (Prozessstruktur)" - relevanz: "Dynamisch (politische Themen, strategische Projekte)" - -# ============================================================================= -# VERKNÜPFUNG SPM -# ============================================================================= - -verknuepfung_spm: - - beschreibung: | - Das SHM-Stakeholder-Portfolio ist mit dem SPM-Service-Portfolio - über harmonisierte Terminologie und Governance-Brücken verknüpft. - - governance_referenz: "GOV-SHM-005" - - terminologie_mapping: - - beschreibung: | - Die IT-Anforderungsprofile im SHM korrespondieren mit den - Service-Kategorien im SPM. Die Terminologie wurde bewusst - harmonisiert. - - mapping: - - shm_profil: "Basis" - spm_kategorie: "A – Basis-Services" - - shm_profil: "Erweitert" - spm_kategorie: "B – Erweiterte Services" - - shm_profil: "Spezial" - spm_kategorie: "C – Spezial-Services" - - governance_bruecke: | - Die Verknüpfung ermöglicht eine systematische Governance-Zuordnung: - - SHM: Amt hat Profil "Erweitert" - ↓ - SPM: Amt nutzt wahrscheinlich Kategorie-B-Services - ↓ - Governance: Amt ist potenziell in Kundenvertretungen für B-Services - - sla_befugnis: | - Die SLA-Befugnis im Amts-Steckbrief folgt der gleichen Logik wie - im SPM (P-02 SLM): Primär Amtsleitung, alternativ delegierte Person - mit dokumentierter Entscheidungsbefugnis. - - Governance-Referenz: GOV-SHM-013 - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2025-12-03" - autor: "DIGITOM-Projekt" - aenderung: "Initiale Erstellung basierend auf Phase-1-Konzeptentwicklung" - governance_basis: "GOV-SHM-001 bis GOV-SHM-014" - - - version: "1.1" - datum: "2025-12-10" - autor: "Cross-Check Phase 5" - aenderung: | - - Überprüfungs-Abschnitt erweitert: - - Veraltete Phase-7-Referenz aktualisiert auf - shm_koordinations-und-steuerungsstruktur.yaml - - VoC-Integration ergänzt (Nutzung von VoC-Erkenntnissen für - Portfolio-Überprüfung) - - Zyklus präzisiert (E2-Standard und E2-Erweitert) - - - version: "1.2" - datum: "2026-01-23" - autor: "DIGITOM-Projekt" - aenderung: | - - Dimension 1 (Funktion) erweitert um Primär-/Sekundärfunktionslogik: - - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung - - Entscheidungshilfe bei Mehrdeutigkeit - - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien - - Dokumentation möglicher und ausgeschlossener Kombinationen - - Operative Anwendung mit Steuerungsprinzip - - Dokumentationspflicht bei Sekundärfunktion - governance_referenz: "GOV-SHM-027" - - - version: "1.3" - datum: "2026-01-23" - autor: "DIGITOM-Projekt" - aenderung: | - Betreuungsstatus-Konzept (GOV-SHM-028): - - Neuer Abschnitt 'betreuungsstatus_konzept' eingefügt - - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND - - Dokumentation der Deckelungslogik für effektiven Betreuungsmodus - - Entscheidungsbefugnis bei Leitung SHM - - Review im Portfolio-Review (E2-Standard/Erweitert) - - Ergänzung im Drei-Ebenen-Modell - governance_referenz: "GOV-SHM-028" - - - version: "1.4" - datum: "2026-01-26" - autor: "DIGITOM-Projekt" - aenderung: | - IT-Anforderungsprofil präzisiert (dimension_2_it_profil): - - Neues Attribut 'typische_services' bei allen drei Profilen ergänzt - - BASIS: Standard-Arbeitsplatz, E-Mail/Kalender, zentrale Systeme - - ERWEITERT: Mobile Hardware (VPN-Notebook, EC-Cash), Außendienst- - Zugriffe, Fachverfahren, DMS/Workflow - - SPEZIAL: Exklusive Fachsoftware, Spezialhardware, individuelle - Schnittstellen, besondere Homeoffice-Lösungen - - Charakteristik ERWEITERT ergänzt um Außendienst-Beschreibung +# ============================================================================= +# SHM STAKEHOLDER-PORTFOLIO: KONZEPT +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Funktion: Konzepte +# Version: 1.3 +# Datum: 2026-01-23 +# Status: Final +# ============================================================================= + +meta: + modul_id: "SHM-K-01" + name: "Stakeholder-Portfolio" + typ: "Konzept" + + zweck: | + Das Stakeholder-Portfolio ist das zentrale Steuerungsinstrument des + Stakeholder-Managements. Es erfasst alle Organisationseinheiten im + Kundenkreis von DIGIT, segmentiert sie nach relevanten Dimensionen + und priorisiert sie für die Ressourcenallokation. + + Das Portfolio ist kein Selbstzweck, sondern ein Entscheidungsinstrument. + Seine Struktur folgt aus den Entscheidungen, die es unterstützen soll. + + scope: | + Alle Organisationseinheiten im Dezernatsverteilungsplan der Stadt: + - Ämter + - Eigenbetriebe + - Referate + - Stabsstellen + - Projektgruppen + + governance_referenzen: + - "GOV-SHM-001 bis GOV-SHM-014" + - "readme_shm_governance-entscheidungs-log.yaml" + + schema_referenz: + dokument: "shm_schema_amtssteckbrief.yaml" + beschreibung: "Technisches Attribut-Schema für die Datenerfassung pro Amt" + +# ============================================================================= +# FUNKTIONALE HERLEITUNG +# ============================================================================= + +funktionale_herleitung: + + leitfrage: | + Welche Entscheidungen soll das Stakeholder-Portfolio ermöglichen? + + kernentscheidungen: + + - id: PKE-1 + name: "Betreuungsallokation" + leitfrage: "Wer wird wie intensiv betreut?" + kontext: | + Ressourcenknappheit erfordert Priorisierung. Nicht alle Ämter + können gleich intensiv betreut werden. Das Portfolio muss helfen, + die Betreuungsintensität systematisch zu differenzieren. + unterstuetzt_durch: + - "Priorisierung (Ebene 3)" + - "Betreuungsmodus-Ableitung" + + - id: PKE-2 + name: "Bedarfsrouting" + leitfrage: "Wohin gehört dieser Bedarf?" + kontext: | + Wenn ein Bedarf eingeht, muss SHM entscheiden: Ist das ein + Service-Request (→ Katalog), ein Change an bestehendem Service + (→ Service Owner), oder ein neuer Demand (→ DPM)? Das Wissen + über den Stakeholder und sein typisches Bedarfsprofil beeinflusst + diese Einordnung. + unterstuetzt_durch: + - "Segmentierung (Ebene 2)" + - "Funktion + IT-Anforderungsprofil" + + - id: PKE-3 + name: "Governance-Zuordnung" + leitfrage: "Wer sitzt in welchem Gremium?" + kontext: | + Für SLAs (Kundenvertretungen), für Bedarfspriorisierung (DSR), + für strategische Abstimmung braucht es Zuordnungslogiken. + Das IT-Anforderungsprofil korrespondiert mit den SPM-Service- + Kategorien und damit mit der Gremienstruktur. + unterstuetzt_durch: + - "IT-Anforderungsprofil → SPM-Kategorie-Mapping" + - "SLA-Befugnis im Amts-Steckbrief" + +# ============================================================================= +# DREI-EBENEN-MODELL +# ============================================================================= + +drei_ebenen_modell: + + beschreibung: | + Das Portfolio ist in drei Ebenen strukturiert, die aufeinander aufbauen: + + 1. Amts-Steckbrief – Datengrundlage pro Organisationseinheit + 2. Segmentierung – Clustering nach zwei unabhängigen Dimensionen + 3. Priorisierung – Bewertung zur Ableitung des Betreuungsmodus + + Ergänzend: Der Betreuungsstatus (Stammdaten) dokumentiert, ob eine + Zusammenarbeit mit dem Amt überhaupt möglich ist – unabhängig von + dessen Wichtigkeit (Priorisierung). + + governance_referenz: "GOV-SHM-001" + +# ============================================================================= +# BETREUUNGSSTATUS-KONZEPT +# ============================================================================= + +betreuungsstatus_konzept: + + beschreibung: | + Der Betreuungsstatus ist ein Stammdatum (nicht Teil der Priorisierung), + das dokumentiert, ob eine Zusammenarbeit mit einem Amt möglich ist. + + Hintergrund: + Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) + beantworten die Frage "Wie wichtig ist das Amt?". Sie beantworten + nicht "Können wir mit dem Amt zusammenarbeiten?" + + Beispiele für eingeschränkte Zusammenarbeit: + - Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung + - Amt X: Schwierige Beziehung, Zugang erschwert + + Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit), + aber die Betreuungslogik muss die Realität abbilden. + + governance_referenz: "GOV-SHM-028" + schema_referenz: "shm_schema_amtssteckbrief.yaml → stammdaten.betreuungsstatus" + + auspraegungen: + + - id: "AKTIV" + name: "Aktiv" + beschreibung: | + Zusammenarbeit möglich. Normale Priorisierung greift, + Betreuungsmodus wird direkt aus Prio-Stufe abgeleitet. + konsequenz: "effektiver_betreuungsmodus = betreuungsmodus (aus Prio-Stufe)" + + - id: "EINGESCHRAENKT" + name: "Eingeschränkt" + beschreibung: | + Zusammenarbeit nur punktuell möglich. Priorisierung greift, + aber Betreuungsmodus wird auf individuell festgelegtes + Maximum gedeckelt. + konsequenz: | + effektiver_betreuungsmodus = MIN(betreuungsmodus, max_betreuungsmodus) + Beispiel: Key-Stakeholder mit max_betreuungsmodus REGELMAESSIG + → effektiver_betreuungsmodus = REGELMAESSIG (nicht PROAKTIV_DEDIZIERT) + pflichtfelder: + - "begruendung (min. 30 Zeichen)" + - "max_betreuungsmodus" + - "entschieden_von" + - "entschieden_am" + + - id: "RUHEND" + name: "Ruhend" + beschreibung: | + Aktuell keine Zusammenarbeit möglich. Amt bleibt im + Portfolio dokumentiert, aber außerhalb aktiver Betreuung. + Priorisierung wird trotzdem erfasst (für Reaktivierung). + konsequenz: "effektiver_betreuungsmodus = KEINE_AKTIVE_BETREUUNG" + pflichtfelder: + - "begruendung (min. 30 Zeichen)" + - "entschieden_von" + - "entschieden_am" + + vorteile: + - "Vollständigkeit: Alle Ämter bleiben im Portfolio dokumentiert" + - "Flexibilität: Bei Statusänderung einfache Umstellung" + - "Saubere Priorisierung: Nur Wichtigkeit, nicht Machbarkeit" + - "Reporting: Filter nach 'aktiv betreute Ämter' vs. 'Gesamtportfolio'" + - "Transparenz: Gründe für eingeschränkte Zusammenarbeit dokumentiert" + + entscheidungsbefugnis: + rolle: "Leitung SHM" + begruendung: | + Die Entscheidung, ein Amt als 'ruhend' oder 'eingeschränkt' zu + klassifizieren, hat strategische Konsequenzen und sollte nicht + willkürlich getroffen werden. Die Leitung SHM hat den Gesamtüberblick + über das Portfolio und kann die Entscheidung im Kontext bewerten. + dokumentation: | + Jede Entscheidung muss dokumentiert werden: + - Wer hat entschieden (entschieden_von) + - Wann wurde entschieden (entschieden_am) + - Warum (begruendung) + - Wann wird der Status überprüft (naechste_pruefung, empfohlen) + + review: + zyklus: "Im Portfolio-Review (E2-Standard/Erweitert)" + inhalt: | + Bei jedem Portfolio-Review wird geprüft: + - Sind EINGESCHRÄNKT- und RUHEND-Status noch aktuell? + - Haben sich Rahmenbedingungen geändert? + - Sollten Ämter reaktiviert werden? + +# ============================================================================= +# EBENE 1: AMTS-STECKBRIEF +# ============================================================================= + +ebene_1_amtssteckbrief: + + beschreibung: | + Jede Organisationseinheit im Scope erhält einen Amts-Steckbrief. + Dieser enthält alle Informationen, die für die drei Kernentscheidungen + (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung) benötigt + werden. + + herleitung: | + Die Attribute des Steckbriefs sind nicht willkürlich gewählt, sondern + leiten sich aus den Kernentscheidungen ab. Jedes Attribut muss + mindestens eine der drei Entscheidungen unterstützen. Attribute ohne + klaren Entscheidungsbezug werden nicht erfasst. + + attribut_kategorien: + + - kategorie: "Stammdaten" + zweck: "Identifikation und organisatorische Einordnung" + entscheidungsbezug: "Alle (PKE-1, PKE-2, PKE-3)" + beispiele: + - "Amt/Organisationseinheit" + - "Dezernat" + - "Amtsleitung" + - "SLA-Befugnis (wer hat Entscheidungsbefugnis)" + + - kategorie: "Segmentierung" + zweck: "Einordnung in die zweidimensionale Matrix" + entscheidungsbezug: "PKE-2 Bedarfsrouting, PKE-3 Governance" + beispiele: + - "Funktion (Sondereinheit/Querschnitt/Bürgerservice/Fachamt)" + - "IT-Anforderungsprofil (Basis/Erweitert/Spezial)" + + - kategorie: "Priorisierung" + zweck: "Bewertung für Betreuungsallokation" + entscheidungsbezug: "PKE-1 Betreuungsallokation" + beispiele: + - "Einfluss (boolean)" + - "Abhängigkeit (boolean)" + - "Relevanz (boolean)" + - "Prio-Stufe (abgeleitet)" + - "Betreuungsmodus (abgeleitet)" + + - kategorie: "Governance" + zweck: "Gremien-Zuordnung und Vertretungslogik" + entscheidungsbezug: "PKE-3 Governance-Zuordnung" + beispiele: + - "Gremien-Mitgliedschaften" + + - kategorie: "Betreuung" + zweck: "Operative Beziehungspflege" + entscheidungsbezug: "E1 Betreuungsallokation" + beispiele: + - "Zugeordneter Stakeholder-Manager" + - "Beziehungsqualität" + - "Aktive Themen" + + schema_verweis: | + Das vollständige Attribut-Schema mit Datentypen, Wertelisten und + Validierungsregeln ist in shm_schema_amtssteckbrief.yaml dokumentiert. + +# ============================================================================= +# EBENE 2: SEGMENTIERUNG +# ============================================================================= + +ebene_2_segmentierung: + + beschreibung: | + Die Segmentierung erfolgt zweidimensional. Beide Dimensionen sind + unabhängig voneinander. Jedes Amt erhält genau eine Ausprägung pro + Dimension (keine Mehrfachzuordnung, keine Tags). + + governance_referenz: "GOV-SHM-002" + + # --------------------------------------------------------------------------- + # DIMENSION 1: FUNKTION + # --------------------------------------------------------------------------- + + dimension_1_funktion: + + name: "Funktion" + beschreibung: "Organisatorische Rolle des Amtes in der Stadtverwaltung" + + governance_referenz: "GOV-SHM-003" + + auspraegungen: + + - id: "SONDER" + name: "Sondereinheit" + charakteristik: | + Organisatorisch eigenständig, eigene Rechtsform oder + Sonderstatus (Eigenbetriebe, Stabsstellen, Projektgruppen) + beispiele: + - "Eigenbetrieb Stadtentwässerung" + - "Eigenbetrieb Theater" + - "Stabsstelle Digitalisierung" + + - id: "QUER" + name: "Querschnittsamt" + charakteristik: | + Erbringt interne Dienstleistungen für andere Ämter, + hat Multiplikator-Wirkung + beispiele: + - "Haupt- und Personalamt" + - "Stadtkämmerei" + - "Rechtsamt" + + - id: "BUERGER" + name: "Bürgerservice" + charakteristik: | + Direkter Bürgerkontakt als Kernaufgabe, + hohe externe Sichtbarkeit + beispiele: + - "Amt für Bürgerservice" + - "Standesamt" + - "Amt für Soziales" + + - id: "FACH" + name: "Fachamt" + charakteristik: | + Spezialisierte Fachaufgaben, oft technisch geprägt, + geringerer direkter Bürgerkontakt + beispiele: + - "Stadtplanungsamt" + - "Garten- und Tiefbauamt" + - "Umweltschutzamt" + + zuordnungslogik: + + grundprinzip: | + Die Funktionszuordnung unterscheidet zwischen Primärfunktion + (steuernd) und Sekundärfunktion (informierend). + + - Primärfunktion: Bestimmt Bedarfsrouting und Governance-Zuordnung + - Sekundärfunktion: Dokumentiert Kontext für differenzierte Betrachtung + + Nicht jedes Amt hat eine Sekundärfunktion. Sie wird nur vergeben, + wenn ein Amt deutlich erkennbare Charakteristika einer zweiten + Funktionskategorie aufweist. + + governance_referenz: "GOV-SHM-027" + + # ----------------------------------------------------------------------- + # PRIMÄRFUNKTIONSBESTIMMUNG + # ----------------------------------------------------------------------- + + primaerfunktion: + + beschreibung: | + Die Primärfunktion wird durch einen Entscheidungsbaum bestimmt. + Die erste zutreffende Kategorie gewinnt (Dominanzprinzip). + + entscheidungsbaum: + + schritt_1: + frage: "Ist das Amt organisatorisch eigenständig?" + indikatoren: + - "Eigene Rechtsform (Eigenbetrieb)" + - "Sonderstatus (Stabsstelle, Projektgruppe)" + - "Nicht in regulärer Amtsstruktur eingegliedert" + ja: "SONDER (Sondereinheit)" + nein: "weiter zu Schritt 2" + + schritt_2: + frage: "Erbringt das Amt primär interne Dienstleistungen für andere Ämter?" + indikatoren: + - "Hauptaufgabe ist Unterstützung anderer Ämter" + - "Querschnittsfunktion (Personal, Finanzen, Recht, IT, Organisation)" + - "Multiplikator-Wirkung auf andere Ämter" + ja: "QUER (Querschnittsamt)" + nein: "weiter zu Schritt 3" + + schritt_3: + frage: "Hat das Amt direkten Bürgerkontakt als Kernaufgabe?" + indikatoren: + - "Publikumsverkehr ist zentrale Aufgabe" + - "Bürger:innen sind primäre Zielgruppe" + - "Hohe externe Sichtbarkeit durch Bürger-Interaktion" + ja: "BUERGER (Bürgerservice)" + nein: "FACH (Fachamt)" + + entscheidungshilfe_bei_mehrdeutigkeit: | + Wenn ein Amt mehrere Charakteristika erfüllt, gilt: + + 1. Dominanzprinzip anwenden: Die erste zutreffende Kategorie + im Entscheidungsbaum bestimmt die Primärfunktion. + + 2. Hauptaufgabe identifizieren: Was ist der Kern-Auftrag des Amtes + laut Dezernatsverteilungsplan oder Geschäftsverteilungsplan? + + 3. Ressourcenallokation prüfen: Wohin fließen die meisten Ressourcen + (Personal, Budget, Zeit)? + + 4. Selbstverständnis einbeziehen: Wie beschreibt das Amt selbst + seine Hauptaufgabe? + + Beispiel Stadtkämmerei: + - Erfüllt Querschnitts-Kriterien (Finanzdienstleistungen für alle Ämter) + - Hat auch Fachamt-Charakteristika (spezialisierte Haushaltsführung) + → Primärfunktion: QUER (Querschnittsamt), da interne Dienstleistung + die Kernaufgabe ist + + # ----------------------------------------------------------------------- + # SEKUNDÄRFUNKTIONSBESTIMMUNG + # ----------------------------------------------------------------------- + + sekundaerfunktion: + + beschreibung: | + Die Sekundärfunktion dokumentiert eine zusätzliche Funktions- + charakteristik, die für Kontext und differenzierte Betrachtung + relevant ist. + + vergabe_kriterien: | + Eine Sekundärfunktion wird vergeben, wenn: + + 1. Das Amt deutlich erkennbare Charakteristika einer zweiten + Funktionskategorie aufweist (nicht nur marginal) + + 2. Diese zweite Funktion für Bedarfsrouting oder Governance + relevant sein kann (z.B. Bedarfe, die eher zur Sekundär- + funktion passen) + + 3. Die Zuordnung nachvollziehbar begründet werden kann + + nicht_vergeben_wenn: | + Keine Sekundärfunktion, wenn: + + - Das Amt klar einer einzigen Kategorie zuzuordnen ist + - Die zweite Charakteristik nur marginal ausgeprägt ist + - Kein praktischer Nutzen für Routing oder Governance erkennbar ist + + moegliche_kombinationen: + + - primaer: "QUER" + sekundaer: "FACH" + typisch: true + beispiel: "Stadtkämmerei (Querschnitt + spezialisierte Haushaltsführung)" + + - primaer: "QUER" + sekundaer: "BUERGER" + typisch: false + beispiel: "Haupt- und Personalamt mit Bürgerbüro-Funktion" + + - primaer: "BUERGER" + sekundaer: "FACH" + typisch: true + beispiel: "Amt für Soziales (Bürgerservice + spezialisierte Sozialarbeit)" + + - primaer: "FACH" + sekundaer: "BUERGER" + typisch: true + beispiel: "Baurechtsamt (Fachamt + Bauberatung für Bürger:innen)" + + - primaer: "FACH" + sekundaer: "QUER" + typisch: false + beispiel: "IT-Amt mit internen Dienstleistungen (eher selten)" + + - primaer: "SONDER" + sekundaer: "beliebig" + typisch: true + beispiel: "Eigenbetrieb mit Bürgerservice-Anteil" + + ausgeschlossene_kombinationen: + - kombination: "gleiche Primär- und Sekundärfunktion" + grund: "Logisch unmöglich" + + # ----------------------------------------------------------------------- + # OPERATIVE ANWENDUNG + # ----------------------------------------------------------------------- + + operative_anwendung: + + verwendung_primaerfunktion: + - "Bedarfsrouting (PKE-2): Bestimmt typisches Bedarfsprofil" + - "Governance-Zuordnung (PKE-3): Bestimmt Gremien-Mitgliedschaften" + - "Betreuungsallokation (PKE-1): Kontextinformation für Priorisierung" + + verwendung_sekundaerfunktion: + - "Bedarfsrouting: Differenzierte Betrachtung bei Bedarfen, die eher + zur Sekundärfunktion passen" + - "Governance: Optionale Einbindung in Gremien der Sekundärkategorie" + - "Bedarfsvorhersage: Vollständigeres Bild des typischen Bedarfsprofils" + - "Transparenz: Dokumentation für Nachvollziehbarkeit" + + steuerungsprinzip: | + Primärfunktion steuert, Sekundärfunktion informiert. + + Bei Entscheidungen (Routing, Governance) ist die Primärfunktion + maßgeblich. Die Sekundärfunktion kann bei begründeten Ausnahmen + herangezogen werden, überschreibt aber nie die Primärfunktion. + + dokumentationspflicht: | + Bei Vergabe einer Sekundärfunktion muss im Amts-Steckbrief eine + Begründung dokumentiert werden, die erklärt: + - Warum das Amt Charakteristika der Sekundärkategorie aufweist + - Welche praktische Relevanz die Sekundärfunktion hat + + # --------------------------------------------------------------------------- + # DIMENSION 2: IT-ANFORDERUNGSPROFIL + # --------------------------------------------------------------------------- + + dimension_2_it_profil: + + name: "IT-Anforderungsprofil" + beschreibung: | + Komplexität der IT-Bedarfe des Amtes. Die Dimension ist + bedarfsorientiert (nicht nutzungsorientiert), um zukünftige + Bedarfe vorherzusagen, nicht nur den Status quo abzubilden. + + governance_referenz: "GOV-SHM-004" + + auspraegungen: + + - id: "BASIS" + name: "Basis" + charakteristik: | + Standardbedarf, Grundausstattung reicht aus, + geringe IT-Komplexität + spm_korrespondenz: "Kategorie A – Basis-Services" + typische_services: + - "Standard-Arbeitsplatz (Büro-PC, Office-Anwendungen)" + - "E-Mail und Kalender" + - "Zugang zu zentralen Verwaltungssystemen" + beispiele: + - "Rechtsamt" + - "Rechnungsprüfungsamt" + - "Standesamt" + + - id: "ERWEITERT" + name: "Erweitert" + charakteristik: | + Fachspezifische Bedarfe über Standard hinaus, + mittlere IT-Komplexität. Häufig: Benötigt Zugriff auf + Daten im Außendienst – erbringt einen erheblichen Teil + der Arbeit außerhalb des Bürostandorts und benötigt dabei + Zugriff auf städtische oder weitere relevante Daten + (Baupläne, Elektropläne, Meldedaten, KFZ-Daten etc.). + spm_korrespondenz: "Kategorie B – Erweiterte Services" + typische_services: + - "Mobile Hardware (VPN-Notebook, EC-Cash-Gerät etc.)" + - "Zugriffe auf interne Daten außerhalb vom Bürostandort" + - "Fachverfahren mit erweitertem Funktionsumfang" + - "DMS, Terminbuchung, Workflow-Systeme" + beispiele: + - "Haupt- und Personalamt" + - "Amt für Bürgerservice" + - "Umweltschutzamt" + + - id: "SPEZIAL" + name: "Spezial" + charakteristik: | + Individuelle Bedarfe, die nur für dieses Amt gelten, + hohe IT-Komplexität, Spezialsoftware, bilaterale SLAs. + Arbeiten aus dem Homeoffice oft nur durch besondere + Lösungen möglich (Standard-Homeoffice-Lösungen greifen nicht). + spm_korrespondenz: "Kategorie C – Spezial-Services" + typische_services: + - "Exklusive Fachsoftware (CAD, GIS, Spezialsysteme)" + - "Spezialhardware (Plotter, Messgeräte, Spezialdrucker)" + - "Individuelle Schnittstellenlösungen" + - "Besondere Homeoffice-/Remote-Lösungen" + beispiele: + - "Stadtplanungsamt (CAD, GIS)" + - "Garten- und Tiefbauamt" + - "Immobilienmanagement (Eigenbetrieb)" + + zuordnungslogik: | + Entscheidungsbaum: + + 1. Hat das Amt individuelle IT-Bedarfe, die NUR für dieses Amt + gelten? (exklusive Fachsoftware, Spezialhardware, bilaterale SLAs) + → JA: Spezial + → NEIN: weiter zu 2. + + 2. Hat das Amt fachspezifische IT-Bedarfe über die Grundausstattung + hinaus? (DMS, Fachverfahren, Terminbuchung, Workflow-Systeme) + → JA: Erweitert + → NEIN: Basis + + # --------------------------------------------------------------------------- + # MATRIX + # --------------------------------------------------------------------------- + + matrix: + + beschreibung: | + Die Kombination der beiden Dimensionen ergibt eine 4×3-Matrix. + Jedes Amt wird genau einem Feld zugeordnet. Nicht alle + Kombinationen sind gleich häufig oder wahrscheinlich. + + governance_referenz: "GOV-SHM-006" + + hinweis_sondereinheiten: | + Sondereinheiten sind eine Funktionskategorie, keine Ausnahme + von der zweidimensionalen Logik. Sie haben wie alle anderen + Ämter ein IT-Anforderungsprofil. + + unwahrscheinliche_kombinationen: + - kombination: "Querschnitt + Spezial" + begruendung: | + Querschnittsämter erbringen standardisierte interne Services. + Hochspezialisierte IT-Bedarfe sind untypisch. + - kombination: "Bürgerservice + Spezial" + begruendung: | + Bürgerservice-Ämter nutzen typischerweise standardisierte + Bürger-Fachverfahren, keine exklusiven Spezial-Lösungen. + + # --------------------------------------------------------------------------- + # VERKNÜPFUNG ZU ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + verknuepfung_entscheidungen: + + bedarfsrouting_PKE2: + relevante_dimensionen: "Funktion + IT-Profil" + logik: | + Die Kombination hilft, typische Bedarfe vorherzusagen: + - Bürgerservice + Erweitert → Terminbuchung, Aufrufsysteme, DMS + - Fachamt + Spezial → CAD, GIS, Spezialhardware + - Querschnitt + Erweitert → Personalverwaltung, Finanz-Systeme + + governance_zuordnung_PKE3: + relevante_dimension: "IT-Anforderungsprofil" + logik: | + Das IT-Profil korrespondiert mit SPM-Kategorien und damit + mit der SLA-Governance: + - Basis-Profil → primär in Kundenvertretung Basisservices (Kat. A) + - Erweitert-Profil → in servicespezifischen Kundenvertretungen (Kat. B) + - Spezial-Profil → bilaterale SLAs (Kat. C) + +# ============================================================================= +# EBENE 3: PRIORISIERUNG +# ============================================================================= + +ebene_3_priorisierung: + + beschreibung: | + Die Priorisierung identifiziert innerhalb der Segmente die + Key-Stakeholder und leitet den Betreuungsmodus ab. Sie basiert + auf drei Dimensionen, die binär (ja/nein) bewertet werden. + + # --------------------------------------------------------------------------- + # DIMENSIONEN + # --------------------------------------------------------------------------- + + dimensionen: + + governance_referenz: "GOV-SHM-007" + + bewertungslogik: | + Jede Dimension wird binär bewertet (ja/nein). Die Bewertung + erfolgt durch den Stakeholder-Manager mit dokumentierter + Begründung. Die Begründung macht die Einschätzung + nachvollziehbar und überprüfbar. + + dimension_1_einfluss: + + id: "E" + name: "Einfluss" + leitfrage: "Kann das Amt DIGIT-relevante Entscheidungen beeinflussen?" + + indikatoren: + - "Entscheidungsbefugnis über IT-Budgets oder IT-Standards" + - "Multiplikator-Rolle durch Größe oder Querschnittsfunktion" + - "Politisches Gewicht in Verwaltungsgremien" + + beispiele_ja: + - "Haupt- und Personalamt (IT-Standards für alle)" + - "Stadtkämmerei (IT-Budget-Allokation)" + + beispiele_nein: + - "Standesamt (kein übergreifender Einfluss)" + + dimension_2_abhaengigkeit: + + id: "A" + name: "Abhängigkeit" + leitfrage: "Steht das Amt ohne IT still?" + + indikatoren: + - "Kernprozesse sind IT-abhängig" + - "Externe Schnittstellen setzen funktionierende IT voraus" + - "IT-Ausfall führt zu unmittelbarem Leistungsausfall" + + beispiele_ja: + - "Amt für Bürgerservice (alle Prozesse IT-basiert)" + - "Stadtkasse (Zahlungsverkehr)" + + beispiele_nein: + - "Kulturamt (kann temporär analog arbeiten)" + + dimension_3_relevanz: + + id: "R" + name: "Relevanz" + leitfrage: "Ist das Amt gerade besonders wichtig für die Gesamtverwaltung?" + + indikatoren: + - "Hohe politische oder öffentliche Sichtbarkeit" + - "Beteiligung an strategischen Projekten" + - "Aktuelle Krisensituation oder Transformationsphase" + + charakteristik: | + Diese Dimension ist dynamisch und kann sich über Zeit ändern. + Sie erfordert regelmäßige Überprüfung im Portfolio-Review. + + beispiele_ja: + - "Amt für Digitalisierung (strategisches Projekt)" + - "Amt für öffentliche Ordnung (bei Großveranstaltungen)" + + beispiele_nein: + - "Forstamt (stabile Situation, geringe Sichtbarkeit)" + + # --------------------------------------------------------------------------- + # GEWICHTUNG + # --------------------------------------------------------------------------- + + gewichtung: + + governance_referenz: "GOV-SHM-008" + + logik: | + Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt + beeinflussen können – sei es durch Budget-Entscheidungen, + Standard-Setzung oder politisches Gewicht. + + Gewichtung: Einfluss > Abhängigkeit = Relevanz + + begruendung: | + Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen + von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist + strategisch wichtiger als zu Ämtern, die "nur" abhängig sind. + + # --------------------------------------------------------------------------- + # KOMBINATIONSLOGIK + # --------------------------------------------------------------------------- + + kombinationslogik: + + governance_referenz: "GOV-SHM-009" + + prio_stufen: + + - stufe: "Key" + kombination: "Alle drei ODER Einfluss + eine weitere" + beschreibung: "Strategisch wichtigste Stakeholder" + + - stufe: "Aktiv" + kombination: "Zwei (ohne Einfluss) ODER nur Einfluss" + beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung" + + - stufe: "Standard" + kombination: "Eine (Abhängigkeit oder Relevanz)" + beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf" + + - stufe: "Basis" + kombination: "Keine Dimension erfüllt" + beschreibung: "Stakeholder mit reaktiver Betreuung" + + kombinationstabelle: | + + │ E │ A │ R │ Prio-Stufe │ + ├───┼───┼───┼────────────┤ + │ ✓ │ ✓ │ ✓ │ Key │ + │ ✓ │ ✓ │ – │ Key │ + │ ✓ │ – │ ✓ │ Key │ + │ – │ ✓ │ ✓ │ Aktiv │ + │ ✓ │ – │ – │ Aktiv │ + │ – │ ✓ │ – │ Standard │ + │ – │ – │ ✓ │ Standard │ + │ – │ – │ – │ Basis │ + + Legende: E = Einfluss, A = Abhängigkeit, R = Relevanz + + # --------------------------------------------------------------------------- + # BETREUUNGSMODUS + # --------------------------------------------------------------------------- + + betreuungsmodus: + + governance_referenz: "GOV-SHM-010" + + beschreibung: | + Der Betreuungsmodus wird aus der Prio-Stufe abgeleitet und + definiert die Art und Intensität der Stakeholder-Betreuung. + + modi: + + - prio_stufe: "Key" + modus: "Proaktiv/Dediziert" + beschreibung: | + Regelmäßige Turnusgespräche (z.B. halbjährlich), + dedizierter Stakeholder-Manager, + aktive Bedarfserhebung, + Einladung zu strategischen Abstimmungen + + - prio_stufe: "Aktiv" + modus: "Regelmäßig" + beschreibung: | + Teilnahme am Cluster-Advisory-Board, + anlassbezogene Gespräche, + Einladung zu relevanten Themen + + - prio_stufe: "Standard" + modus: "Eingebunden" + beschreibung: | + Teilnahme am Cluster-Advisory-Board, + reaktive Betreuung bei Anfragen + + - prio_stufe: "Basis" + modus: "Reaktiv" + beschreibung: | + Keine proaktive Betreuung, + nur bei eingehenden Anfragen, + Information über allgemeine Kanäle + + # --------------------------------------------------------------------------- + # ÜBERPRÜFUNG + # --------------------------------------------------------------------------- + + ueberpruefung: + + governance_referenz: "GOV-SHM-012" + + beschreibung: | + Die Priorisierung wird periodisch überprüft, insbesondere + die Dimension "Relevanz", die sich über Zeit ändern kann. + + zyklus: | + Im Rahmen der Koordinations- und Steuerungsstruktur + (shm_koordinations-und-steuerungsstruktur.yaml): + - REV-2-Standard (Q1/Q3): Portfolio-Analyse + - REV-2-Erweitert (Q2/Q4): Portfolio-Analyse + Verbesserungsplanung + + voc_integration: | + Die Portfolio-Überprüfung nutzt VoC-Erkenntnisse (shm_voice-of-customer.yaml) + zu Beziehungsqualität, Zufriedenheit und Bedarfsentwicklung, um + Priorisierungen und Betreuungsmodi anzupassen. + + stabilität_der_dimensionen: + einfluss: "Relativ stabil (Organisationsstruktur)" + abhaengigkeit: "Relativ stabil (Prozessstruktur)" + relevanz: "Dynamisch (politische Themen, strategische Projekte)" + +# ============================================================================= +# VERKNÜPFUNG SPM +# ============================================================================= + +verknuepfung_spm: + + beschreibung: | + Das SHM-Stakeholder-Portfolio ist mit dem SPM-Service-Portfolio + über harmonisierte Terminologie und Governance-Brücken verknüpft. + + governance_referenz: "GOV-SHM-005" + + terminologie_mapping: + + beschreibung: | + Die IT-Anforderungsprofile im SHM korrespondieren mit den + Service-Kategorien im SPM. Die Terminologie wurde bewusst + harmonisiert. + + mapping: + - shm_profil: "Basis" + spm_kategorie: "A – Basis-Services" + - shm_profil: "Erweitert" + spm_kategorie: "B – Erweiterte Services" + - shm_profil: "Spezial" + spm_kategorie: "C – Spezial-Services" + + governance_bruecke: | + Die Verknüpfung ermöglicht eine systematische Governance-Zuordnung: + + SHM: Amt hat Profil "Erweitert" + ↓ + SPM: Amt nutzt wahrscheinlich Kategorie-B-Services + ↓ + Governance: Amt ist potenziell in Kundenvertretungen für B-Services + + sla_befugnis: | + Die SLA-Befugnis im Amts-Steckbrief folgt der gleichen Logik wie + im SPM (P-02 SLM): Primär Amtsleitung, alternativ delegierte Person + mit dokumentierter Entscheidungsbefugnis. + + Governance-Referenz: GOV-SHM-013 + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2025-12-03" + autor: "DIGITOM-Projekt" + aenderung: "Initiale Erstellung basierend auf Phase-1-Konzeptentwicklung" + governance_basis: "GOV-SHM-001 bis GOV-SHM-014" + + - version: "1.1" + datum: "2025-12-10" + autor: "Cross-Check Phase 5" + aenderung: | + - Überprüfungs-Abschnitt erweitert: + - Veraltete Phase-7-Referenz aktualisiert auf + shm_koordinations-und-steuerungsstruktur.yaml + - VoC-Integration ergänzt (Nutzung von VoC-Erkenntnissen für + Portfolio-Überprüfung) + - Zyklus präzisiert (E2-Standard und E2-Erweitert) + + - version: "1.2" + datum: "2026-01-23" + autor: "DIGITOM-Projekt" + aenderung: | + - Dimension 1 (Funktion) erweitert um Primär-/Sekundärfunktionslogik: + - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung + - Entscheidungshilfe bei Mehrdeutigkeit + - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien + - Dokumentation möglicher und ausgeschlossener Kombinationen + - Operative Anwendung mit Steuerungsprinzip + - Dokumentationspflicht bei Sekundärfunktion + governance_referenz: "GOV-SHM-027" + + - version: "1.3" + datum: "2026-01-23" + autor: "DIGITOM-Projekt" + aenderung: | + Betreuungsstatus-Konzept (GOV-SHM-028): + - Neuer Abschnitt 'betreuungsstatus_konzept' eingefügt + - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND + - Dokumentation der Deckelungslogik für effektiven Betreuungsmodus + - Entscheidungsbefugnis bei Leitung SHM + - Review im Portfolio-Review (E2-Standard/Erweitert) + - Ergänzung im Drei-Ebenen-Modell + governance_referenz: "GOV-SHM-028" + + - version: "1.4" + datum: "2026-01-26" + autor: "DIGITOM-Projekt" + aenderung: | + IT-Anforderungsprofil präzisiert (dimension_2_it_profil): + - Neues Attribut 'typische_services' bei allen drei Profilen ergänzt + - BASIS: Standard-Arbeitsplatz, E-Mail/Kalender, zentrale Systeme + - ERWEITERT: Mobile Hardware (VPN-Notebook, EC-Cash), Außendienst- + Zugriffe, Fachverfahren, DMS/Workflow + - SPEZIAL: Exklusive Fachsoftware, Spezialhardware, individuelle + Schnittstellen, besondere Homeoffice-Lösungen + - Charakteristik ERWEITERT ergänzt um Außendienst-Beschreibung - Charakteristik SPEZIAL ergänzt um Homeoffice-Einschränkung \ No newline at end of file diff --git a/#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml b/#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml index 6f32921..06d27e1 100644 --- a/#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml +++ b/#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml @@ -1,1071 +1,1071 @@ -# ============================================================================= -# SHM VOICE OF CUSTOMER (VoC) - KONZEPT -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Typ: Konzept -# Version: 1.0 -# Datum: 2025-12-10 -# Status: Final (Phase 5) -# ============================================================================= - -meta: - modul_id: "SHM-K-04" - name: "Voice of Customer" - typ: "Konzept" - - zweck: | - Das Voice-of-Customer-Konzept (VoC) systematisiert die Erfassung, - Verarbeitung und Nutzung von Stakeholder-Feedback innerhalb der - SHM-Funktion. Es macht die Stakeholder-Stimme als zentralen - Erfolgsindikator nutzbar. - - VoC ist kein isoliertes Erfassungssystem, sondern integraler - Bestandteil der SHM Koordinations- und Steuerungsstruktur. - - itil4_referenz: - konzept: "Voice of Customer" - quelle: "ITIL 4 Drive Stakeholder Value (DSV)" - adaption: | - Das ITIL4-VoC-Konzept wurde für den kommunalen Verwaltungskontext - adaptiert. Insbesondere die Unterscheidung Customer/User wurde - auf die DIGIT-Stakeholder-Landschaft übertragen. - - entwicklungsprinzip: | - Das VoC-Konzept folgt dem Prinzip "Start simple, dann nachziehen": - Die Erfassung wird so niedrigschwellig wie möglich gestaltet. - Komplexität wird nur dort ergänzt, wo sich in der Praxis zeigt, - dass sie notwendig ist. - - governance_referenzen: - - id: "GOV-SHM-023" - thema: "Fokus auf Ergebnis-Indikatoren" - - id: "GOV-SHM-024" - thema: "Abgrenzung SHM/SPM im Reporting" - - konzept_referenzen: - - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" - beschreibung: "Integration in Review-Struktur (REV-1, REV-2, REV-3)" - - dokument: "shm_engagement-framework.yaml" - beschreibung: "Feedback-Quellen (Turnus-Gespräche, Auftraggeber-Forum)" - - dokument: "shm_stakeholder-portfolio.yaml" - beschreibung: "Beziehungsqualität als VoC-Indikator" - -# ============================================================================= -# ZWECK UND FUNKTION -# ============================================================================= - -zweck_und_funktion: - - beschreibung: | - VoC erfüllt drei primäre Funktionen für SHM. Die Reihenfolge - reflektiert die Priorität: Steuerung und Lernen stehen vor - Legitimation. - - primaere_funktionen: - - - id: "VOC-F-01" - name: "Steuerung" - beschreibung: | - VoC liefert Signale für Handlungsbedarf. Wenn Stakeholder - unzufrieden sind oder Probleme melden, muss SHM reagieren. - VoC ermöglicht proaktives Handeln statt reaktiver Krisenbewältigung. - leitfrage: "Wo müssen wir nachsteuern?" - output: "Interventionsbedarf, Maßnahmenableitung" - - - id: "VOC-F-02" - name: "Lernen" - beschreibung: | - VoC hilft zu verstehen, was Stakeholder brauchen, wie sie - DIGIT wahrnehmen und wo Erwartungslücken bestehen. Dieses - Verständnis verbessert die Betreuungsqualität kontinuierlich. - leitfrage: "Was lernen wir über unsere Stakeholder?" - output: "Muster, Erkenntnisse, Anpassungsbedarf" - - - id: "VOC-F-03" - name: "Strategie-Input" - beschreibung: | - SHM fungiert als "Ohr an der Kundschaft" für DIGIT. Aggregierte - VoC-Erkenntnisse fließen in die strategische Planung ein und - helfen, das DIGIT-Angebot an den Bedürfnissen auszurichten. - leitfrage: "Was sagt uns das über die Gesamtentwicklung?" - output: "Strategische Impulse, Priorisierungs-Input" - - nachgelagerte_funktion: - - - id: "VOC-F-04" - name: "Legitimation" - beschreibung: | - VoC kann auch zur Rechtfertigung des SHM-Aufwands dienen - ("Die Stakeholder bestätigen den Wert der Betreuung"). - Dies ist ein Nebeneffekt, nicht der Hauptzweck. - leitfrage: "Können wir zeigen, dass SHM wirkt?" - output: "Erfolgsnachweise für E1-Review" - anmerkung: | - Bewusst nachgelagert, um zu vermeiden, dass VoC zur - Rechtfertigungs-Übung wird. - -# ============================================================================= -# VERANTWORTUNGSABGRENZUNG: CUSTOMER VS. USER -# ============================================================================= - -verantwortungsabgrenzung: - - grundsatz: | - SHM verantwortet die Customer-Stimme (Amtsleitungen, SLA-Partner). - Die User-Stimme wird durch Support/Service Desk erfasst und - steht SHM als Kontext-Information zur Verfügung. - - customer_stimme: - - definition: | - Feedback von Entscheidern, die Services beauftragen und - strategische Bedarfe formulieren (SLA-Partner, Amtsleitungen, - IT-Koordinatoren mit Entscheidungsbefugnis). - - verantwortung: "SHM" - - primaere_kanaele: - - "Turnus-Gespräche (TF-01, TF-02)" - - "Auftraggeber-Forum Basisservices (KF-01)" - - "SLA-Reviews (slm_09)" - - "Strategische Formate" - - charakteristik: | - Customer-Feedback ist typischerweise strategischer, - beziehungsorientierter und weniger transaktional als - User-Feedback. - - user_stimme: - - definition: | - Feedback von Endanwendern, die Services täglich nutzen - (Sachbearbeiter, Mitarbeitende in den Ämtern). - - verantwortung: "Support / Service Desk" - - nutzung_durch_shm: | - Als Kontext-Information, nicht als Primärquelle. - User-Feedback kann Hinweise auf Service-Probleme geben, - die die Beziehungsqualität belasten. - - primaere_kanaele: - - "Service Desk Tickets" - - "Zufriedenheitsabfragen nach Incidents" - - "Self-Service-Bewertungen" - - status: "Bestätigt" - datum: "2025-12-10" - -# ============================================================================= -# FEEDBACK-DIMENSIONEN -# ============================================================================= - -feedback_dimensionen: - - beschreibung: | - VoC unterscheidet vier inhaltliche Dimensionen, die unterschiedliche - Aspekte der Stakeholder-Wahrnehmung erfassen. Die Dimensionen sind - trennscharf, können aber im Einzelfall zusammenhängen. - - dimensionen: - - # ------------------------------------------------------------------------- - # D1: BEZIEHUNGSQUALITÄT - # ------------------------------------------------------------------------- - - - id: "D1" - name: "Beziehungsqualität" - - kernfrage: "Wie wird die Zusammenarbeit mit SHM/DIGIT wahrgenommen?" - - beispiel_aussagen: - positiv: - - "Wir fühlen uns gut betreut" - - "DIGIT versteht unsere Situation" - - "Die Kommunikation ist offen und ehrlich" - negativ: - - "Die Kommunikation ist schwierig" - - "Wir werden nicht ernst genommen" - - "Absprachen werden nicht eingehalten" - - shm_verantwortung: "Direkt" - - anmerkung: | - Kernauftrag von SHM. Hier liegt die unmittelbare - Einflussmöglichkeit und Verantwortung. - - cluster_referenz: "cluster_d1_beziehungsqualitaet" - - # ------------------------------------------------------------------------- - # D2: SERVICE-QUALITÄT - # ------------------------------------------------------------------------- - - - id: "D2" - name: "Service-Qualität" - - kernfrage: "Wie werden die IT-Services bewertet?" - - beispiel_aussagen: - positiv: - - "Das System läuft stabil" - - "Der Support reagiert schnell" - - "Die Performance hat sich verbessert" - negativ: - - "Die Performance ist schlecht" - - "Häufige Ausfälle" - - "Der Support ist nicht erreichbar" - - shm_verantwortung: "Indirekt (Kontext)" - - anmerkung: | - Primär SPM/Service Owner-Verantwortung. SHM erfasst - D2-Feedback als Kontext, berichtet es aber nicht - eigenständig, sondern leitet es weiter. - - weiterleitung_an: "SPM / Service Owner" - - cluster_referenz: "cluster_d2_servicequalitaet" - - # ------------------------------------------------------------------------- - # D3: BEDARFSERFÜLLUNG - # ------------------------------------------------------------------------- - - - id: "D3" - name: "Bedarfserfüllung" - - kernfrage: "Werden die Anforderungen des Amtes erfüllt?" - - beispiel_aussagen: - positiv: - - "Unsere Digitalisierungsprojekte kommen voran" - - "Unsere Prioritäten werden berücksichtigt" - - "Wir bekommen zeitnah Rückmeldung" - negativ: - - "Wir warten seit Monaten auf Rückmeldung" - - "Unsere Anforderungen verschwinden im Nichts" - - "Andere werden bevorzugt" - - shm_verantwortung: "Geteilt" - - anmerkung: | - SHM verantwortet Bedarfserkennung und -qualifizierung. - DPM/SPM verantworten Umsetzung und Priorisierung. - - cluster_referenz: "cluster_d3_bedarfserfuellung" - - # ------------------------------------------------------------------------- - # D4: STRATEGISCHE PASSUNG - # ------------------------------------------------------------------------- - - - id: "D4" - name: "Strategische Eignung" - - kernfrage: "Passt das DIGIT-Angebot zur Amtsstrategie?" - - beispiel_aussagen: - positiv: - - "DIGIT versteht unsere Richtung" - - "Wir bekommen proaktive Impulse" - - "Die IT-Strategie passt zu unseren Zielen" - negativ: - - "Die Prioritäten passen nicht zu unserer Entwicklung" - - "DIGIT denkt nicht mit uns mit" - - "Wir werden von Entwicklungen überrascht" - - shm_verantwortung: "Direkt (bei Key-Stakeholdern)" - - anmerkung: | - Teil der strategischen Beratungsfunktion bei Key-Stakeholdern. - Bei Standard/Basis-Stakeholdern weniger relevant. - - cluster_referenz: "cluster_d4_strategische_passung" - -# ============================================================================= -# FEEDBACK-QUELLEN -# ============================================================================= - -feedback_quellen: - - beschreibung: | - Die folgenden Quellen liefern Feedback für das VoC-System. - Sie unterscheiden sich in Erhebungsart, Reichweite und - Strukturierungsgrad. - - quellen: - - - id: "Q-01" - name: "Turnus-Gespräch (TF-01/02)" - - typ: "Aktiv erhoben" - reichweite: "Key, Aktiv" - dimensionen: ["D1", "D3", "D4"] - strukturierungsgrad: "Gering (narrativ)" - frequenz: "Quartalsweise (Key) / Halbjährlich (Aktiv)" - - quelle_dokument: "shm_engagement-framework.yaml" - template_referenz: "TPL-EF-01, TPL-EF-02, TPL-EF-03" - - erfassungshinweis: | - Feedback wird als Bestandteil des Gesprächsprotokolls erfasst. - Kein separater Erfassungsaufwand erforderlich. - - - id: "Q-02" - name: "Auftraggeber-Forum Basisservices (KF-01)" - - typ: "Aktiv erhoben" - reichweite: "Standard, Basis" - dimensionen: ["D1", "D2"] - strukturierungsgrad: "Gering (narrativ)" - frequenz: "Jährlich" - - quelle_dokument: "shm_engagement-framework.yaml" - - erfassungshinweis: | - Feedback aus Diskussionen und Q&A-Runden wird im - Veranstaltungsprotokoll dokumentiert. - - - id: "Q-03" - name: "Externer SLA-Review (slm_09)" - - typ: "Aktiv erhoben" - reichweite: "Alle mit SLA" - dimensionen: ["D2"] - strukturierungsgrad: "Mittel (strukturiert)" - frequenz: "Jährlich" - - quelle_dokument: "spm_practice_service-level-management.yaml" - - erfassungshinweis: | - D2-Feedback aus SLA-Reviews wird von SPM erfasst und - an SHM als Kontext weitergegeben. - - - id: "Q-04" - name: "Strukturiertes Feedback (IND-3)" - - typ: "Aktiv erhoben" - reichweite: "Key" - dimensionen: ["D1"] - strukturierungsgrad: "Mittel (Skala + Kommentar)" - frequenz: "Jährlich" - - quelle_dokument: "shm_engagement-framework.yaml" - - erfassungshinweis: | - Kurze strukturierte Abfrage (3-5 Fragen) zur - Beziehungsqualität im Rahmen eines Turnus-Gesprächs. - - - id: "Q-05" - name: "Beschwerden (TRIG-C)" - - typ: "Passiv eingehend" - reichweite: "Alle" - dimensionen: ["D1", "D2", "D3"] - strukturierungsgrad: "Gering (unstrukturiert)" - frequenz: "Anlassbezogen" - - quelle_dokument: "shm_engagement-framework.yaml" - - erfassungshinweis: | - Beschwerden werden im Ticketsystem erfasst und - automatisch als VoC-relevant markiert. - - - id: "Q-06" - name: "Service Desk Tickets" - - typ: "Passiv eingehend" - reichweite: "User-Ebene" - dimensionen: ["D2"] - strukturierungsgrad: "Hoch (kategorisiert)" - frequenz: "Kontinuierlich" - - quelle_dokument: "spm_practice_service-support-management.yaml" - - anmerkung: | - Kontext-Information, nicht Primärquelle für SHM. - Aggregierte Ticket-Daten können Hinweise auf - Service-Probleme geben, die Beziehungen belasten. - - template_implikation: | - Die Templates für Turnus-Gespräche (TPL-EF-01 bis 03) werden - so gestaltet, dass VoC-relevante Informationen ohne zusätzlichen - Aufwand erfasst werden. Ein Abschnitt "Feedback-Notizen" mit - den Mindestattributen wird integriert. - -# ============================================================================= -# AGGREGATIONSLOGIK -# ============================================================================= - -aggregationslogik: - - beschreibung: | - Das Feedback durchläuft drei Verdichtungsstufen, von der - Einzelerfassung bis zur strategischen Verdichtung. - - designprinzip: | - Die Erfassung (Stufe 1) ist bewusst niedrigschwellig gestaltet. - Komplexität entsteht erst in der Verdichtung (Stufe 2-3), die - zentral und periodisch erfolgt. - - # --------------------------------------------------------------------------- - # STUFE 1: ERFASSUNG - # --------------------------------------------------------------------------- - - stufe_1_erfassung: - - name: "Erfassung" - ort: "Am Entstehungsort (Gespräch, Ticket, Forum)" - verantwortung: "Stakeholder-Manager / Protokollant" - frequenz: "Laufend / anlassbezogen" - - beschreibung: | - Feedback wird dort erfasst, wo es entsteht – als Teil des - normalen Arbeitsprozesses. Kein separates "VoC-Erfassungs- - System" im MVP. - - mindestattribute: - - - attribut: "datum" - beschreibung: "Wann wurde das Feedback gegeben?" - pflicht: true - erfassung: "Automatisch (Protokolldatum)" - - - attribut: "quelle" - beschreibung: "Woher stammt das Feedback?" - pflicht: true - erfassung: "Automatisch (Dokumenttyp)" - werteliste: ["Q-01", "Q-02", "Q-03", "Q-04", "Q-05", "Q-06"] - - - attribut: "stakeholder" - beschreibung: "Wer hat das Feedback gegeben?" - pflicht: true - erfassung: "Automatisch (Gesprächspartner)" - - - attribut: "kernaussage" - beschreibung: "Was wurde gesagt? (Paraphrase oder Zitat)" - pflicht: true - erfassung: "Manuell" - - - attribut: "tonalitaet" - beschreibung: "Wie war der Grundton?" - pflicht: false - erfassung: "Bei Sichtung ergänzt" - werteliste: ["positiv", "neutral", "kritisch"] - - - attribut: "dimension" - beschreibung: "Welche VoC-Dimension betrifft es?" - pflicht: false - erfassung: "Bei Sichtung ergänzt" - werteliste: ["D1", "D2", "D3", "D4"] - - erfassungsprinzip: | - Tonalität und Dimension werden bei der Sichtung (Stufe 2) - ergänzt, nicht bei der Erfassung. So bleibt die Erfassung - maximal einfach. - - # --------------------------------------------------------------------------- - # STUFE 2: CLUSTERUNG & BEWERTUNG - # --------------------------------------------------------------------------- - - stufe_2_clusterung: - - name: "Clusterung & Bewertung" - ort: "SHM-intern" - verantwortung: "SHM-Leitung / designierter VoC-Verantwortlicher" - frequenz: "Laufend (Sichtung) / Quartalsweise (Konsolidierung)" - - beschreibung: | - Erfasste Feedbacks werden thematisch gruppiert, mit einer - Kritikalitäts-Ampel bewertet und besonders relevante Aussagen - als Highlights extrahiert. - - # ......................................................................... - # KRITIKALITÄTS-AMPEL - # ......................................................................... - - kritikalitaets_ampel: - - beschreibung: | - Die Ampel ist eine qualitative Einschätzung, keine - mathematische Aggregation. Sie basiert auf dem Gesamteindruck - unter Berücksichtigung der Bewertungskriterien. - - stufen: - - - stufe: "gruen" - label: "Grün" - bedeutung: "Überwiegend positives Feedback, kein Handlungsbedarf" - handlungsimplikation: "Weiter beobachten, positive Aspekte verstärken" - - - stufe: "gelb" - label: "Gelb" - bedeutung: "Gemischtes Feedback, Aufmerksamkeit erforderlich" - handlungsimplikation: "Ursachen verstehen, präventiv handeln" - - - stufe: "rot" - label: "Rot" - bedeutung: "Überwiegend negatives Feedback, akuter Handlungsbedarf" - handlungsimplikation: "Sofortige Analyse, Maßnahmenplanung" - - - stufe: "grau" - label: "Grau" - bedeutung: "Keine oder unzureichende Datenbasis" - handlungsimplikation: "Datenerhebung intensivieren" - - bewertungskriterien: - - - kriterium: "Stakeholder-Priorität" - beschreibung: "Feedback von Key-Stakeholdern wiegt schwerer" - - - kriterium: "Konsistenz" - beschreibung: "Wiederholte Kritik ist ernster als Einzelfall" - - - kriterium: "Trend" - beschreibung: "Verschlechterung ist kritischer als stabiles Niveau" - - - kriterium: "Handlungsrelevanz" - beschreibung: "Feedback zu beeinflussbaren Themen ist relevanter" - - # ......................................................................... - # HIGHLIGHT-EXTRAKTION - # ......................................................................... - - highlight_extraktion: - - beschreibung: | - Besonders relevante Einzelaussagen werden als "Highlights" - markiert und in die Verdichtung übernommen. - - highlight_typen: - - - typ: "positiv" - kriterium: "Besonders lobende Aussage, Best Practice" - verwendung: "Erfolgsnachweis, Motivation" - - - typ: "kritik" - kriterium: "Scharfe Kritik, Eskalationsrisiko" - verwendung: "Handlungsbedarf, Priorisierung" - - - typ: "insight" - kriterium: "Überraschende Erkenntnis, neuer Blickwinkel" - verwendung: "Lernen, Strategieentwicklung" - - - typ: "trend" - kriterium: "Hinweis auf größere Entwicklung" - verwendung: "Früherkennung, Prävention" - - dokumentation: | - Highlights werden mit Quelle dokumentiert, um Rückfragen - zu ermöglichen und Kontext zu bewahren. - - # --------------------------------------------------------------------------- - # STUFE 3: VERDICHTUNG FÜR ADRESSATEN - # --------------------------------------------------------------------------- - - stufe_3_verdichtung: - - name: "Verdichtung für Adressaten" - ort: "SHM-Leitung" - verantwortung: "SHM-Leitung" - frequenz: "Quartalsweise (E2) / Jährlich (E1)" - - beschreibung: | - Die geclusterten und bewerteten Feedbacks werden für - unterschiedliche Adressaten verdichtet. - - verdichtungen: - - - adressat: "E2 (Quartals-Review)" - inhalt: - - "Cluster-Übersicht mit Ampel-Status" - - "Veränderungen gegenüber Vorquartal" - - "Highlights (alle Typen)" - - "Identifizierte Handlungsbedarfe" - format: "Abschnitt im SHM-Quartalsbericht" - - - adressat: "E1 (Jahres-Review)" - inhalt: - - "VoC-Gesamtbild des Jahres" - - "Dimension-Überblick (D1-D4)" - - "Jahrestrend je Cluster" - - "Strategische Erkenntnisse" - format: "Kapitel im SHM-Jahresbericht" - - - adressat: "DIGIT-Strategie" - inhalt: - - "Übergreifende Themenfelder" - - "Strategische Impulse aus Stakeholder-Sicht" - - "Priorisierungs-Input" - format: "Input-Dokument für Strategieprozess" - schnittstelle_status: "Platzhalter – Strategieprozess noch nicht modelliert" - -# ============================================================================= -# THEMATISCHE CLUSTER -# ============================================================================= - -thematische_cluster: - - status: "Annahme für Startpunkt – Validierung mit SHM-Team erforderlich" - - entwicklungshinweis: | - Die folgenden Cluster sind ein initialer Vorschlag basierend auf - typischen Feedback-Themen. Sie müssen mit dem SHM-Team validiert - und in der Praxis verprobt werden. Anpassungen (Ergänzung, - Zusammenlegung, Umbenennung) sind explizit vorgesehen. - - # --------------------------------------------------------------------------- - # D1: BEZIEHUNGSQUALITÄT - # --------------------------------------------------------------------------- - - cluster_d1_beziehungsqualitaet: - - dimension: "D1" - dimension_name: "Beziehungsqualität" - - cluster: - - - id: "D1-C1" - name: "Erreichbarkeit & Reaktionszeit" - typische_aussagen: - - "Schnelle Rückmeldung" - - "Schwer erreichbar" - - "Muss lange auf Antwort warten" - - - id: "D1-C2" - name: "Kommunikationsqualität" - typische_aussagen: - - "Verständliche Erklärungen" - - "Zu technisch" - - "Gute Gesprächsatmosphäre" - - - id: "D1-C3" - name: "Verbindlichkeit & Verlässlichkeit" - typische_aussagen: - - "Zusagen werden eingehalten" - - "Termine platzen" - - "Kann mich auf Absprachen verlassen" - - - id: "D1-C4" - name: "Partnerschaftlichkeit" - typische_aussagen: - - "Fühlen uns ernst genommen" - - "Werden übergangen" - - "Begegnung auf Augenhöhe" - - # --------------------------------------------------------------------------- - # D2: SERVICE-QUALITÄT - # --------------------------------------------------------------------------- - - cluster_d2_servicequalitaet: - - dimension: "D2" - dimension_name: "Service-Qualität" - - anmerkung: | - D2-Cluster werden primär durch SPM/SLM bearbeitet. - SHM erfasst sie als Kontext für die Beziehungsqualität. - - cluster: - - - id: "D2-C1" - name: "Verfügbarkeit & Stabilität" - typische_aussagen: - - "Läuft stabil" - - "Häufige Ausfälle" - - "System ist zuverlässig" - - - id: "D2-C2" - name: "Performance" - typische_aussagen: - - "Schnelle Reaktionszeiten" - - "System ist langsam" - - "Ladezeiten sind akzeptabel" - - - id: "D2-C3" - name: "Support-Qualität" - typische_aussagen: - - "Kompetente Hilfe" - - "Tickets dauern zu lange" - - "Problem wurde schnell gelöst" - - - id: "D2-C4" - name: "Funktionalität" - typische_aussagen: - - "Deckt unsere Anforderungen ab" - - "Wichtige Funktionen fehlen" - - "Gute Weiterentwicklung" - - # --------------------------------------------------------------------------- - # D3: BEDARFSERFÜLLUNG - # --------------------------------------------------------------------------- - - cluster_d3_bedarfserfuellung: - - dimension: "D3" - dimension_name: "Bedarfserfüllung" - - cluster: - - - id: "D3-C1" - name: "Bedarfserkennung" - typische_aussagen: - - "Unsere Anforderungen werden verstanden" - - "Müssen uns wiederholen" - - "Gute Beratung bei der Bedarfsklärung" - - - id: "D3-C2" - name: "Umsetzungsgeschwindigkeit" - typische_aussagen: - - "Projekte kommen voran" - - "Dauert alles ewig" - - "Gute Fortschritte" - - - id: "D3-C3" - name: "Priorisierung" - typische_aussagen: - - "Unsere Prioritäten werden berücksichtigt" - - "Andere werden bevorzugt" - - "Faire Ressourcenverteilung" - - - id: "D3-C4" - name: "Transparenz" - typische_aussagen: - - "Wissen immer, woran wir sind" - - "Anforderungen verschwinden" - - "Gute Status-Updates" - - # --------------------------------------------------------------------------- - # D4: STRATEGISCHE PASSUNG - # --------------------------------------------------------------------------- - - cluster_d4_strategische_passung: - - dimension: "D4" - dimension_name: "Strategische Passung" - - anmerkung: | - D4-Cluster sind primär für Key-Stakeholder relevant. - Bei Standard/Basis-Stakeholdern werden sie selten erhoben. - - cluster: - - - id: "D4-C1" - name: "Strategisches Verständnis" - typische_aussagen: - - "DIGIT versteht unsere Richtung" - - "Kennen unsere Strategie nicht" - - "Gutes Verständnis unserer Ziele" - - - id: "D4-C2" - name: "Zukunftsorientierung" - typische_aussagen: - - "Bekommen proaktive Impulse" - - "Nur reaktiv" - - "Denken mit uns voraus" - - - id: "D4-C3" - name: "Strategische Abstimmung" - typische_aussagen: - - "IT-Strategie passt zu unseren Zielen" - - "Prioritäten passen nicht" - - "Gute strategische Zusammenarbeit" - -# ============================================================================= -# RÜCKFLUSS-MECHANISMUS -# ============================================================================= - -rueckfluss_mechanismus: - - beschreibung: | - VoC ist kein Einweg-System. Die Erkenntnisse müssen zurück zu - den Stakeholdern fließen und in konkrete Maßnahmen münden. - - # --------------------------------------------------------------------------- - # RÜCKSPIELUNG AN STAKEHOLDER - # --------------------------------------------------------------------------- - - rueckspielung_stakeholder: - - grundsatz: | - Stakeholder sollen erfahren, dass ihr Feedback gehört wurde - und welche Konsequenzen es hatte. - - mechanismen: - - - kanal: "Turnus-Gespräch" - beschreibung: | - Zu Beginn jedes Turnus-Gesprächs Rückbezug auf frühere - Rückmeldungen: "Beim letzten Mal hatten Sie X angemerkt. - Wir haben Y unternommen." - frequenz: "Bei jedem Gespräch" - verantwortung: "Stakeholder-Manager" - - - kanal: "Auftraggeber-Forum" - beschreibung: | - Jährliche Zusammenfassung: "Was haben wir aufgrund Ihres - Feedbacks verändert?" als fester Agenda-Punkt. - frequenz: "Jährlich" - verantwortung: "SHM-Leitung" - - - kanal: "Direkte Rückmeldung" - beschreibung: | - Bei Kritik-Highlights proaktive Information über - eingeleitete Maßnahmen, ohne auf den nächsten Turnus - zu warten. - frequenz: "Anlassbezogen" - verantwortung: "Stakeholder-Manager" - - # --------------------------------------------------------------------------- - # MASSNAHMENABLEITUNG - # --------------------------------------------------------------------------- - - massnahmenableitung: - - grundsatz: | - Nicht jedes Feedback erfordert eine Maßnahme. Die Ableitung - erfolgt auf Basis der Cluster-Bewertung und Highlights. - - ableitungslogik: - - - ausloeser: "Einzelnes Kritik-Highlight" - massnahme: "Intervention" - verantwortung: "Stakeholder-Manager" - zeithorizont: "Kurzfristig (Tage/Wochen)" - - - ausloeser: "Cluster Gelb" - massnahme: "Beobachtung verstärken" - verantwortung: "SHM-Leitung (E2-Review)" - zeithorizont: "Mittelfristig (Quartal)" - - - ausloeser: "Cluster Rot" - massnahme: "Maßnahmenplanung" - verantwortung: "SHM-Leitung (E2-Review)" - zeithorizont: "Mittelfristig (Quartal)" - - - ausloeser: "Systematisches Muster" - massnahme: "Strukturelle Verbesserung" - verantwortung: "Erweiterter E2-Review (Q2/Q4)" - zeithorizont: "Langfristig (Halbjahr)" - - - ausloeser: "Strategie-relevante Erkenntnis" - massnahme: "Weiterleitung an Strategieprozess" - verantwortung: "SHM-Leitung" - zeithorizont: "Strategiezyklus" - - # --------------------------------------------------------------------------- - # WIRKSAMKEITSVALIDIERUNG - # --------------------------------------------------------------------------- - - wirksamkeitsvalidierung: - - grundsatz: | - Maßnahmen müssen auf ihre Wirksamkeit überprüft werden. - Die Validierung erfolgt über das VoC-System selbst – - der Kreis schließt sich. - - validierungsmechanismen: - - - mechanismus: "Cluster-Entwicklung" - beschreibung: | - Beobachtung der Ampel-Entwicklung im Folgequartal. - Hat sich ein Rot-Cluster nach Maßnahmenumsetzung - auf Gelb oder Grün verbessert? - pruefung_durch: "SHM-Leitung im E2-Review" - dokumentation: "Trend-Kommentar in Cluster-Übersicht" - - - mechanismus: "Stakeholder-Rückmeldung" - beschreibung: | - Direkte Bestätigung durch den betroffenen Stakeholder - im nächsten Turnus-Gespräch: "Hat sich aus Ihrer Sicht - etwas verbessert?" - pruefung_durch: "Stakeholder-Manager" - dokumentation: "Notiz im Gesprächsprotokoll" - - - mechanismus: "Highlight-Tracking" - beschreibung: | - Beobachtung, ob ein Kritik-Highlight in Folgeperioden - erneut auftaucht. Wiederholtes Auftauchen = Maßnahme - nicht wirksam. - pruefung_durch: "SHM-Leitung" - dokumentation: "Verweis auf frühere Highlights in E2-Review" - - - mechanismus: "Maßnahmen-Review" - beschreibung: | - Explizite Überprüfung offener Maßnahmen im E2-Review: - Status, Wirkung, ggf. Nachjustierung. - pruefung_durch: "SHM-Leitung" - dokumentation: "Maßnahmen-Status in E2-Protokoll" - - eskalation_bei_unwirksamkeit: | - Wenn eine Maßnahme nach zwei Quartalen keine erkennbare - Wirkung zeigt, wird das Thema im erweiterten E2-Review (Q2/Q4) - als strukturelles Verbesserungsthema behandelt. - -# ============================================================================= -# UMGANG MIT WIDERSPRÜCHLICHEM FEEDBACK -# ============================================================================= - -umgang_mit_widerspruechen: - - grundsatz: | - Widersprüche sind Informationsquelle, nicht Problem. Sie werden - nicht eliminiert oder geglättet, sondern als Hinweis auf - unterschiedliche Perspektiven oder Kontexte interpretiert. - - situationen: - - - situation: "Gleicher Sachverhalt, unterschiedliche Bewertung" - beispiel: "Amt A findet Support schnell, Amt B findet ihn langsam" - interpretation: "Unterschiedliche Erwartungen oder Kontexte" - handlung: "Erwartungsklärung, ggf. Segmentierung der Ansprache" - - - situation: "Unterschiedliche Sachverhalte" - beispiel: "Lob für Service X, Kritik an Service Y" - interpretation: "Kein echter Widerspruch" - handlung: "Getrennt behandeln" - - - situation: "Feedback vs. Selbstwahrnehmung SHM" - beispiel: "Stakeholder kritisiert Erreichbarkeit, SHM sieht kein Problem" - interpretation: "Möglicher blinder Fleck bei SHM" - handlung: "Ernstnehmen, reflektieren, ggf. externe Perspektive einholen" - - - situation: "Feedback von verschiedenen Ebenen" - beispiel: "Amtsleitung zufrieden, Sachbearbeiter kritisch" - interpretation: "Unterschiedliche Perspektiven auf gleiche Realität" - handlung: "Beide dokumentieren, nicht gegeneinander ausspielen" - -# ============================================================================= -# INTEGRATION IN STEUERUNGSSTRUKTUR -# ============================================================================= - -integration_steuerungsstruktur: - - beschreibung: | - VoC ist kein isoliertes Erfassungssystem, sondern integraler - Bestandteil der SHM Koordinations- und Steuerungsstruktur. - Die folgende Zuordnung zeigt, wie VoC in die Entscheidungstypen - einfließt. - - zuordnung: - - - entscheidungstyp: "E1 (Auftragserfüllung)" - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - voc_beitrag: | - VoC liefert die aggregierte Stakeholder-Stimme als zentralen - Erfolgsindikator. Die Frage "Erfüllen wir unseren Auftrag?" - wird wesentlich durch "Was sagen die Stakeholder?" beantwortet. - voc_output: "Verdichtung E1 (Jahres-Review)" - - - entscheidungstyp: "E2 (Portfolio-Qualität, Lernen & Verbesserung)" - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - voc_beitrag: | - VoC informiert sowohl die Portfolio-Betrachtung als auch die - Verbesserungsplanung: - - Portfolio: Welche Beziehungen sind belastet? Welche Muster? - - CI: Systematische Muster, die auf Prozessprobleme hindeuten - voc_output: "Verdichtung E2 (Quartals-Review)" - - - entscheidungstyp: "E3 (Operative Koordination)" - referenz: "shm_koordinations-und-steuerungsstruktur.yaml" - voc_beitrag: | - Aktuelle Highlights (insbesondere Kritik-Highlights) fließen - in die Team-Koordination ein. Interventionsfälle werden auf - Basis von VoC-Signalen identifiziert. - voc_output: "Highlights (laufend)" - -# ============================================================================= -# VISUALISIERUNG -# ============================================================================= - -visualisierung: - - beschreibung: | - Die Cluster-Ampel-Matrix bietet eine kompakte Übersicht über - den VoC-Status. Sie wird im Quartals-Review (E2) verwendet. - - beispiel_darstellung: | - VoC Cluster-Status Q1/2025 - ═══════════════════════════════════════════════════════════ - - │ Grün │ Gelb │ Rot │ Grau │ - ────────────────────────┼──────┼──────┼─────┼──────┤ - D1 Beziehungsqualität │ │ │ │ │ - ├─ Erreichbarkeit │ ● │ │ │ │ - ├─ Kommunikation │ ● │ │ │ │ - ├─ Verbindlichkeit │ │ ● │ │ │ - └─ Partnerschaftl. │ ● │ │ │ │ - ────────────────────────┼──────┼──────┼─────┼──────┤ - D2 Service-Qualität │ │ │ │ │ - ├─ Verfügbarkeit │ ● │ │ │ │ - ├─ Performance │ │ ● │ │ │ - ├─ Support │ │ │ ● │ │ - └─ Funktionalität │ │ ● │ │ │ - ────────────────────────┼──────┼──────┼─────┼──────┤ - D3 Bedarfserfüllung │ │ │ │ │ - ├─ Bedarfserkennung │ ● │ │ │ │ - ├─ Umsetzungsgeschw. │ │ │ ● │ │ - ├─ Priorisierung │ │ ● │ │ │ - └─ Transparenz │ │ ● │ │ │ - ────────────────────────┼──────┼──────┼─────┼──────┤ - D4 Strateg. Passung │ │ │ │ │ - ├─ Verständnis │ ● │ │ │ │ - ├─ Zukunftsorient. │ │ ● │ │ │ - └─ Abstimmung │ ● │ │ │ │ - ═══════════════════════════════════════════════════════════ - - Legende: ● = aktuelle Bewertung - - Trend-Indikatoren (optional): - ▲ = Verbesserung ggü. Vorquartal - ▼ = Verschlechterung ggü. Vorquartal - ─ = Unverändert - - anwendungshinweis: | - Die Matrix dient der schnellen Orientierung. Details zu einzelnen - Clustern (Highlights, Handlungsbedarf) werden im Fließtext des - Quartalsberichts erläutert. - -# ============================================================================= -# SCHEMA-HINWEIS -# ============================================================================= - -schema_hinweis: - - id: "VOC-MOD-02" - - status: "Informelles Schema ausreichend für MVP" - - beschreibung: | - Für den MVP-Start ist kein formales Datenbank-Schema erforderlich. - Die Mindestattribute (siehe Aggregationslogik Stufe 1) definieren - die erwartete Struktur hinreichend. - - bei_tool_einfuehrung: | - Wenn ein dediziertes VoC-Tool oder eine SIMS-Integration eingeführt - wird, ist ein formales Schema zu entwickeln. Dieses sollte auf den - hier definierten Mindestattributen aufbauen. - - referenz_arbeitsmaterialien: | - Die Template-Anpassungen (Feedback-Notizen-Abschnitt in Turnus- - Gespräch-Templates) werden in Phase 10 umgesetzt. - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-10" - autor: "Konzept-Sprint Phase 5" - aenderung: | - Initiale Erstellung basierend auf Working Document: - - Zweck und Funktion definiert - - Verantwortungsabgrenzung Customer/User dokumentiert - - Feedback-Dimensionen D1-D4 spezifiziert - - Feedback-Quellen Q-01 bis Q-06 inventarisiert - - Dreistufige Aggregationslogik entwickelt - - Thematische Cluster als Annahmen dokumentiert - - Kritikalitäts-Ampel mit Bewertungskriterien definiert - - Rückfluss-Mechanismus konzipiert - - Integration in Steuerungsstruktur beschrieben +# ============================================================================= +# SHM VOICE OF CUSTOMER (VoC) - KONZEPT +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Typ: Konzept +# Version: 1.0 +# Datum: 2025-12-10 +# Status: Final (Phase 5) +# ============================================================================= + +meta: + modul_id: "SHM-K-04" + name: "Voice of Customer" + typ: "Konzept" + + zweck: | + Das Voice-of-Customer-Konzept (VoC) systematisiert die Erfassung, + Verarbeitung und Nutzung von Stakeholder-Feedback innerhalb der + SHM-Funktion. Es macht die Stakeholder-Stimme als zentralen + Erfolgsindikator nutzbar. + + VoC ist kein isoliertes Erfassungssystem, sondern integraler + Bestandteil der SHM Koordinations- und Steuerungsstruktur. + + itil4_referenz: + konzept: "Voice of Customer" + quelle: "ITIL 4 Drive Stakeholder Value (DSV)" + adaption: | + Das ITIL4-VoC-Konzept wurde für den kommunalen Verwaltungskontext + adaptiert. Insbesondere die Unterscheidung Customer/User wurde + auf die DIGIT-Stakeholder-Landschaft übertragen. + + entwicklungsprinzip: | + Das VoC-Konzept folgt dem Prinzip "Start simple, dann nachziehen": + Die Erfassung wird so niedrigschwellig wie möglich gestaltet. + Komplexität wird nur dort ergänzt, wo sich in der Praxis zeigt, + dass sie notwendig ist. + + governance_referenzen: + - id: "GOV-SHM-023" + thema: "Fokus auf Ergebnis-Indikatoren" + - id: "GOV-SHM-024" + thema: "Abgrenzung SHM/SPM im Reporting" + + konzept_referenzen: + - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" + beschreibung: "Integration in Review-Struktur (REV-1, REV-2, REV-3)" + - dokument: "shm_engagement-framework.yaml" + beschreibung: "Feedback-Quellen (Turnus-Gespräche, Auftraggeber-Forum)" + - dokument: "shm_stakeholder-portfolio.yaml" + beschreibung: "Beziehungsqualität als VoC-Indikator" + +# ============================================================================= +# ZWECK UND FUNKTION +# ============================================================================= + +zweck_und_funktion: + + beschreibung: | + VoC erfüllt drei primäre Funktionen für SHM. Die Reihenfolge + reflektiert die Priorität: Steuerung und Lernen stehen vor + Legitimation. + + primaere_funktionen: + + - id: "VOC-F-01" + name: "Steuerung" + beschreibung: | + VoC liefert Signale für Handlungsbedarf. Wenn Stakeholder + unzufrieden sind oder Probleme melden, muss SHM reagieren. + VoC ermöglicht proaktives Handeln statt reaktiver Krisenbewältigung. + leitfrage: "Wo müssen wir nachsteuern?" + output: "Interventionsbedarf, Maßnahmenableitung" + + - id: "VOC-F-02" + name: "Lernen" + beschreibung: | + VoC hilft zu verstehen, was Stakeholder brauchen, wie sie + DIGIT wahrnehmen und wo Erwartungslücken bestehen. Dieses + Verständnis verbessert die Betreuungsqualität kontinuierlich. + leitfrage: "Was lernen wir über unsere Stakeholder?" + output: "Muster, Erkenntnisse, Anpassungsbedarf" + + - id: "VOC-F-03" + name: "Strategie-Input" + beschreibung: | + SHM fungiert als "Ohr an der Kundschaft" für DIGIT. Aggregierte + VoC-Erkenntnisse fließen in die strategische Planung ein und + helfen, das DIGIT-Angebot an den Bedürfnissen auszurichten. + leitfrage: "Was sagt uns das über die Gesamtentwicklung?" + output: "Strategische Impulse, Priorisierungs-Input" + + nachgelagerte_funktion: + + - id: "VOC-F-04" + name: "Legitimation" + beschreibung: | + VoC kann auch zur Rechtfertigung des SHM-Aufwands dienen + ("Die Stakeholder bestätigen den Wert der Betreuung"). + Dies ist ein Nebeneffekt, nicht der Hauptzweck. + leitfrage: "Können wir zeigen, dass SHM wirkt?" + output: "Erfolgsnachweise für E1-Review" + anmerkung: | + Bewusst nachgelagert, um zu vermeiden, dass VoC zur + Rechtfertigungs-Übung wird. + +# ============================================================================= +# VERANTWORTUNGSABGRENZUNG: CUSTOMER VS. USER +# ============================================================================= + +verantwortungsabgrenzung: + + grundsatz: | + SHM verantwortet die Customer-Stimme (Amtsleitungen, SLA-Partner). + Die User-Stimme wird durch Support/Service Desk erfasst und + steht SHM als Kontext-Information zur Verfügung. + + customer_stimme: + + definition: | + Feedback von Entscheidern, die Services beauftragen und + strategische Bedarfe formulieren (SLA-Partner, Amtsleitungen, + IT-Koordinatoren mit Entscheidungsbefugnis). + + verantwortung: "SHM" + + primaere_kanaele: + - "Turnus-Gespräche (TF-01, TF-02)" + - "Auftraggeber-Forum Basisservices (KF-01)" + - "SLA-Reviews (slm_09)" + - "Strategische Formate" + + charakteristik: | + Customer-Feedback ist typischerweise strategischer, + beziehungsorientierter und weniger transaktional als + User-Feedback. + + user_stimme: + + definition: | + Feedback von Endanwendern, die Services täglich nutzen + (Sachbearbeiter, Mitarbeitende in den Ämtern). + + verantwortung: "Support / Service Desk" + + nutzung_durch_shm: | + Als Kontext-Information, nicht als Primärquelle. + User-Feedback kann Hinweise auf Service-Probleme geben, + die die Beziehungsqualität belasten. + + primaere_kanaele: + - "Service Desk Tickets" + - "Zufriedenheitsabfragen nach Incidents" + - "Self-Service-Bewertungen" + + status: "Bestätigt" + datum: "2025-12-10" + +# ============================================================================= +# FEEDBACK-DIMENSIONEN +# ============================================================================= + +feedback_dimensionen: + + beschreibung: | + VoC unterscheidet vier inhaltliche Dimensionen, die unterschiedliche + Aspekte der Stakeholder-Wahrnehmung erfassen. Die Dimensionen sind + trennscharf, können aber im Einzelfall zusammenhängen. + + dimensionen: + + # ------------------------------------------------------------------------- + # D1: BEZIEHUNGSQUALITÄT + # ------------------------------------------------------------------------- + + - id: "D1" + name: "Beziehungsqualität" + + kernfrage: "Wie wird die Zusammenarbeit mit SHM/DIGIT wahrgenommen?" + + beispiel_aussagen: + positiv: + - "Wir fühlen uns gut betreut" + - "DIGIT versteht unsere Situation" + - "Die Kommunikation ist offen und ehrlich" + negativ: + - "Die Kommunikation ist schwierig" + - "Wir werden nicht ernst genommen" + - "Absprachen werden nicht eingehalten" + + shm_verantwortung: "Direkt" + + anmerkung: | + Kernauftrag von SHM. Hier liegt die unmittelbare + Einflussmöglichkeit und Verantwortung. + + cluster_referenz: "cluster_d1_beziehungsqualitaet" + + # ------------------------------------------------------------------------- + # D2: SERVICE-QUALITÄT + # ------------------------------------------------------------------------- + + - id: "D2" + name: "Service-Qualität" + + kernfrage: "Wie werden die IT-Services bewertet?" + + beispiel_aussagen: + positiv: + - "Das System läuft stabil" + - "Der Support reagiert schnell" + - "Die Performance hat sich verbessert" + negativ: + - "Die Performance ist schlecht" + - "Häufige Ausfälle" + - "Der Support ist nicht erreichbar" + + shm_verantwortung: "Indirekt (Kontext)" + + anmerkung: | + Primär SPM/Service Owner-Verantwortung. SHM erfasst + D2-Feedback als Kontext, berichtet es aber nicht + eigenständig, sondern leitet es weiter. + + weiterleitung_an: "SPM / Service Owner" + + cluster_referenz: "cluster_d2_servicequalitaet" + + # ------------------------------------------------------------------------- + # D3: BEDARFSERFÜLLUNG + # ------------------------------------------------------------------------- + + - id: "D3" + name: "Bedarfserfüllung" + + kernfrage: "Werden die Anforderungen des Amtes erfüllt?" + + beispiel_aussagen: + positiv: + - "Unsere Digitalisierungsprojekte kommen voran" + - "Unsere Prioritäten werden berücksichtigt" + - "Wir bekommen zeitnah Rückmeldung" + negativ: + - "Wir warten seit Monaten auf Rückmeldung" + - "Unsere Anforderungen verschwinden im Nichts" + - "Andere werden bevorzugt" + + shm_verantwortung: "Geteilt" + + anmerkung: | + SHM verantwortet Bedarfserkennung und -qualifizierung. + DPM/SPM verantworten Umsetzung und Priorisierung. + + cluster_referenz: "cluster_d3_bedarfserfuellung" + + # ------------------------------------------------------------------------- + # D4: STRATEGISCHE PASSUNG + # ------------------------------------------------------------------------- + + - id: "D4" + name: "Strategische Eignung" + + kernfrage: "Passt das DIGIT-Angebot zur Amtsstrategie?" + + beispiel_aussagen: + positiv: + - "DIGIT versteht unsere Richtung" + - "Wir bekommen proaktive Impulse" + - "Die IT-Strategie passt zu unseren Zielen" + negativ: + - "Die Prioritäten passen nicht zu unserer Entwicklung" + - "DIGIT denkt nicht mit uns mit" + - "Wir werden von Entwicklungen überrascht" + + shm_verantwortung: "Direkt (bei Key-Stakeholdern)" + + anmerkung: | + Teil der strategischen Beratungsfunktion bei Key-Stakeholdern. + Bei Standard/Basis-Stakeholdern weniger relevant. + + cluster_referenz: "cluster_d4_strategische_passung" + +# ============================================================================= +# FEEDBACK-QUELLEN +# ============================================================================= + +feedback_quellen: + + beschreibung: | + Die folgenden Quellen liefern Feedback für das VoC-System. + Sie unterscheiden sich in Erhebungsart, Reichweite und + Strukturierungsgrad. + + quellen: + + - id: "Q-01" + name: "Turnus-Gespräch (TF-01/02)" + + typ: "Aktiv erhoben" + reichweite: "Key, Aktiv" + dimensionen: ["D1", "D3", "D4"] + strukturierungsgrad: "Gering (narrativ)" + frequenz: "Quartalsweise (Key) / Halbjährlich (Aktiv)" + + quelle_dokument: "shm_engagement-framework.yaml" + template_referenz: "TPL-EF-01, TPL-EF-02, TPL-EF-03" + + erfassungshinweis: | + Feedback wird als Bestandteil des Gesprächsprotokolls erfasst. + Kein separater Erfassungsaufwand erforderlich. + + - id: "Q-02" + name: "Auftraggeber-Forum Basisservices (KF-01)" + + typ: "Aktiv erhoben" + reichweite: "Standard, Basis" + dimensionen: ["D1", "D2"] + strukturierungsgrad: "Gering (narrativ)" + frequenz: "Jährlich" + + quelle_dokument: "shm_engagement-framework.yaml" + + erfassungshinweis: | + Feedback aus Diskussionen und Q&A-Runden wird im + Veranstaltungsprotokoll dokumentiert. + + - id: "Q-03" + name: "Externer SLA-Review (slm_09)" + + typ: "Aktiv erhoben" + reichweite: "Alle mit SLA" + dimensionen: ["D2"] + strukturierungsgrad: "Mittel (strukturiert)" + frequenz: "Jährlich" + + quelle_dokument: "spm_practice_service-level-management.yaml" + + erfassungshinweis: | + D2-Feedback aus SLA-Reviews wird von SPM erfasst und + an SHM als Kontext weitergegeben. + + - id: "Q-04" + name: "Strukturiertes Feedback (IND-3)" + + typ: "Aktiv erhoben" + reichweite: "Key" + dimensionen: ["D1"] + strukturierungsgrad: "Mittel (Skala + Kommentar)" + frequenz: "Jährlich" + + quelle_dokument: "shm_engagement-framework.yaml" + + erfassungshinweis: | + Kurze strukturierte Abfrage (3-5 Fragen) zur + Beziehungsqualität im Rahmen eines Turnus-Gesprächs. + + - id: "Q-05" + name: "Beschwerden (TRIG-C)" + + typ: "Passiv eingehend" + reichweite: "Alle" + dimensionen: ["D1", "D2", "D3"] + strukturierungsgrad: "Gering (unstrukturiert)" + frequenz: "Anlassbezogen" + + quelle_dokument: "shm_engagement-framework.yaml" + + erfassungshinweis: | + Beschwerden werden im Ticketsystem erfasst und + automatisch als VoC-relevant markiert. + + - id: "Q-06" + name: "Service Desk Tickets" + + typ: "Passiv eingehend" + reichweite: "User-Ebene" + dimensionen: ["D2"] + strukturierungsgrad: "Hoch (kategorisiert)" + frequenz: "Kontinuierlich" + + quelle_dokument: "spm_practice_service-support-management.yaml" + + anmerkung: | + Kontext-Information, nicht Primärquelle für SHM. + Aggregierte Ticket-Daten können Hinweise auf + Service-Probleme geben, die Beziehungen belasten. + + template_implikation: | + Die Templates für Turnus-Gespräche (TPL-EF-01 bis 03) werden + so gestaltet, dass VoC-relevante Informationen ohne zusätzlichen + Aufwand erfasst werden. Ein Abschnitt "Feedback-Notizen" mit + den Mindestattributen wird integriert. + +# ============================================================================= +# AGGREGATIONSLOGIK +# ============================================================================= + +aggregationslogik: + + beschreibung: | + Das Feedback durchläuft drei Verdichtungsstufen, von der + Einzelerfassung bis zur strategischen Verdichtung. + + designprinzip: | + Die Erfassung (Stufe 1) ist bewusst niedrigschwellig gestaltet. + Komplexität entsteht erst in der Verdichtung (Stufe 2-3), die + zentral und periodisch erfolgt. + + # --------------------------------------------------------------------------- + # STUFE 1: ERFASSUNG + # --------------------------------------------------------------------------- + + stufe_1_erfassung: + + name: "Erfassung" + ort: "Am Entstehungsort (Gespräch, Ticket, Forum)" + verantwortung: "Stakeholder-Manager / Protokollant" + frequenz: "Laufend / anlassbezogen" + + beschreibung: | + Feedback wird dort erfasst, wo es entsteht – als Teil des + normalen Arbeitsprozesses. Kein separates "VoC-Erfassungs- + System" im MVP. + + mindestattribute: + + - attribut: "datum" + beschreibung: "Wann wurde das Feedback gegeben?" + pflicht: true + erfassung: "Automatisch (Protokolldatum)" + + - attribut: "quelle" + beschreibung: "Woher stammt das Feedback?" + pflicht: true + erfassung: "Automatisch (Dokumenttyp)" + werteliste: ["Q-01", "Q-02", "Q-03", "Q-04", "Q-05", "Q-06"] + + - attribut: "stakeholder" + beschreibung: "Wer hat das Feedback gegeben?" + pflicht: true + erfassung: "Automatisch (Gesprächspartner)" + + - attribut: "kernaussage" + beschreibung: "Was wurde gesagt? (Paraphrase oder Zitat)" + pflicht: true + erfassung: "Manuell" + + - attribut: "tonalitaet" + beschreibung: "Wie war der Grundton?" + pflicht: false + erfassung: "Bei Sichtung ergänzt" + werteliste: ["positiv", "neutral", "kritisch"] + + - attribut: "dimension" + beschreibung: "Welche VoC-Dimension betrifft es?" + pflicht: false + erfassung: "Bei Sichtung ergänzt" + werteliste: ["D1", "D2", "D3", "D4"] + + erfassungsprinzip: | + Tonalität und Dimension werden bei der Sichtung (Stufe 2) + ergänzt, nicht bei der Erfassung. So bleibt die Erfassung + maximal einfach. + + # --------------------------------------------------------------------------- + # STUFE 2: CLUSTERUNG & BEWERTUNG + # --------------------------------------------------------------------------- + + stufe_2_clusterung: + + name: "Clusterung & Bewertung" + ort: "SHM-intern" + verantwortung: "SHM-Leitung / designierter VoC-Verantwortlicher" + frequenz: "Laufend (Sichtung) / Quartalsweise (Konsolidierung)" + + beschreibung: | + Erfasste Feedbacks werden thematisch gruppiert, mit einer + Kritikalitäts-Ampel bewertet und besonders relevante Aussagen + als Highlights extrahiert. + + # ......................................................................... + # KRITIKALITÄTS-AMPEL + # ......................................................................... + + kritikalitaets_ampel: + + beschreibung: | + Die Ampel ist eine qualitative Einschätzung, keine + mathematische Aggregation. Sie basiert auf dem Gesamteindruck + unter Berücksichtigung der Bewertungskriterien. + + stufen: + + - stufe: "gruen" + label: "Grün" + bedeutung: "Überwiegend positives Feedback, kein Handlungsbedarf" + handlungsimplikation: "Weiter beobachten, positive Aspekte verstärken" + + - stufe: "gelb" + label: "Gelb" + bedeutung: "Gemischtes Feedback, Aufmerksamkeit erforderlich" + handlungsimplikation: "Ursachen verstehen, präventiv handeln" + + - stufe: "rot" + label: "Rot" + bedeutung: "Überwiegend negatives Feedback, akuter Handlungsbedarf" + handlungsimplikation: "Sofortige Analyse, Maßnahmenplanung" + + - stufe: "grau" + label: "Grau" + bedeutung: "Keine oder unzureichende Datenbasis" + handlungsimplikation: "Datenerhebung intensivieren" + + bewertungskriterien: + + - kriterium: "Stakeholder-Priorität" + beschreibung: "Feedback von Key-Stakeholdern wiegt schwerer" + + - kriterium: "Konsistenz" + beschreibung: "Wiederholte Kritik ist ernster als Einzelfall" + + - kriterium: "Trend" + beschreibung: "Verschlechterung ist kritischer als stabiles Niveau" + + - kriterium: "Handlungsrelevanz" + beschreibung: "Feedback zu beeinflussbaren Themen ist relevanter" + + # ......................................................................... + # HIGHLIGHT-EXTRAKTION + # ......................................................................... + + highlight_extraktion: + + beschreibung: | + Besonders relevante Einzelaussagen werden als "Highlights" + markiert und in die Verdichtung übernommen. + + highlight_typen: + + - typ: "positiv" + kriterium: "Besonders lobende Aussage, Best Practice" + verwendung: "Erfolgsnachweis, Motivation" + + - typ: "kritik" + kriterium: "Scharfe Kritik, Eskalationsrisiko" + verwendung: "Handlungsbedarf, Priorisierung" + + - typ: "insight" + kriterium: "Überraschende Erkenntnis, neuer Blickwinkel" + verwendung: "Lernen, Strategieentwicklung" + + - typ: "trend" + kriterium: "Hinweis auf größere Entwicklung" + verwendung: "Früherkennung, Prävention" + + dokumentation: | + Highlights werden mit Quelle dokumentiert, um Rückfragen + zu ermöglichen und Kontext zu bewahren. + + # --------------------------------------------------------------------------- + # STUFE 3: VERDICHTUNG FÜR ADRESSATEN + # --------------------------------------------------------------------------- + + stufe_3_verdichtung: + + name: "Verdichtung für Adressaten" + ort: "SHM-Leitung" + verantwortung: "SHM-Leitung" + frequenz: "Quartalsweise (E2) / Jährlich (E1)" + + beschreibung: | + Die geclusterten und bewerteten Feedbacks werden für + unterschiedliche Adressaten verdichtet. + + verdichtungen: + + - adressat: "E2 (Quartals-Review)" + inhalt: + - "Cluster-Übersicht mit Ampel-Status" + - "Veränderungen gegenüber Vorquartal" + - "Highlights (alle Typen)" + - "Identifizierte Handlungsbedarfe" + format: "Abschnitt im SHM-Quartalsbericht" + + - adressat: "E1 (Jahres-Review)" + inhalt: + - "VoC-Gesamtbild des Jahres" + - "Dimension-Überblick (D1-D4)" + - "Jahrestrend je Cluster" + - "Strategische Erkenntnisse" + format: "Kapitel im SHM-Jahresbericht" + + - adressat: "DIGIT-Strategie" + inhalt: + - "Übergreifende Themenfelder" + - "Strategische Impulse aus Stakeholder-Sicht" + - "Priorisierungs-Input" + format: "Input-Dokument für Strategieprozess" + schnittstelle_status: "Platzhalter – Strategieprozess noch nicht modelliert" + +# ============================================================================= +# THEMATISCHE CLUSTER +# ============================================================================= + +thematische_cluster: + + status: "Annahme für Startpunkt – Validierung mit SHM-Team erforderlich" + + entwicklungshinweis: | + Die folgenden Cluster sind ein initialer Vorschlag basierend auf + typischen Feedback-Themen. Sie müssen mit dem SHM-Team validiert + und in der Praxis verprobt werden. Anpassungen (Ergänzung, + Zusammenlegung, Umbenennung) sind explizit vorgesehen. + + # --------------------------------------------------------------------------- + # D1: BEZIEHUNGSQUALITÄT + # --------------------------------------------------------------------------- + + cluster_d1_beziehungsqualitaet: + + dimension: "D1" + dimension_name: "Beziehungsqualität" + + cluster: + + - id: "D1-C1" + name: "Erreichbarkeit & Reaktionszeit" + typische_aussagen: + - "Schnelle Rückmeldung" + - "Schwer erreichbar" + - "Muss lange auf Antwort warten" + + - id: "D1-C2" + name: "Kommunikationsqualität" + typische_aussagen: + - "Verständliche Erklärungen" + - "Zu technisch" + - "Gute Gesprächsatmosphäre" + + - id: "D1-C3" + name: "Verbindlichkeit & Verlässlichkeit" + typische_aussagen: + - "Zusagen werden eingehalten" + - "Termine platzen" + - "Kann mich auf Absprachen verlassen" + + - id: "D1-C4" + name: "Partnerschaftlichkeit" + typische_aussagen: + - "Fühlen uns ernst genommen" + - "Werden übergangen" + - "Begegnung auf Augenhöhe" + + # --------------------------------------------------------------------------- + # D2: SERVICE-QUALITÄT + # --------------------------------------------------------------------------- + + cluster_d2_servicequalitaet: + + dimension: "D2" + dimension_name: "Service-Qualität" + + anmerkung: | + D2-Cluster werden primär durch SPM/SLM bearbeitet. + SHM erfasst sie als Kontext für die Beziehungsqualität. + + cluster: + + - id: "D2-C1" + name: "Verfügbarkeit & Stabilität" + typische_aussagen: + - "Läuft stabil" + - "Häufige Ausfälle" + - "System ist zuverlässig" + + - id: "D2-C2" + name: "Performance" + typische_aussagen: + - "Schnelle Reaktionszeiten" + - "System ist langsam" + - "Ladezeiten sind akzeptabel" + + - id: "D2-C3" + name: "Support-Qualität" + typische_aussagen: + - "Kompetente Hilfe" + - "Tickets dauern zu lange" + - "Problem wurde schnell gelöst" + + - id: "D2-C4" + name: "Funktionalität" + typische_aussagen: + - "Deckt unsere Anforderungen ab" + - "Wichtige Funktionen fehlen" + - "Gute Weiterentwicklung" + + # --------------------------------------------------------------------------- + # D3: BEDARFSERFÜLLUNG + # --------------------------------------------------------------------------- + + cluster_d3_bedarfserfuellung: + + dimension: "D3" + dimension_name: "Bedarfserfüllung" + + cluster: + + - id: "D3-C1" + name: "Bedarfserkennung" + typische_aussagen: + - "Unsere Anforderungen werden verstanden" + - "Müssen uns wiederholen" + - "Gute Beratung bei der Bedarfsklärung" + + - id: "D3-C2" + name: "Umsetzungsgeschwindigkeit" + typische_aussagen: + - "Projekte kommen voran" + - "Dauert alles ewig" + - "Gute Fortschritte" + + - id: "D3-C3" + name: "Priorisierung" + typische_aussagen: + - "Unsere Prioritäten werden berücksichtigt" + - "Andere werden bevorzugt" + - "Faire Ressourcenverteilung" + + - id: "D3-C4" + name: "Transparenz" + typische_aussagen: + - "Wissen immer, woran wir sind" + - "Anforderungen verschwinden" + - "Gute Status-Updates" + + # --------------------------------------------------------------------------- + # D4: STRATEGISCHE PASSUNG + # --------------------------------------------------------------------------- + + cluster_d4_strategische_passung: + + dimension: "D4" + dimension_name: "Strategische Passung" + + anmerkung: | + D4-Cluster sind primär für Key-Stakeholder relevant. + Bei Standard/Basis-Stakeholdern werden sie selten erhoben. + + cluster: + + - id: "D4-C1" + name: "Strategisches Verständnis" + typische_aussagen: + - "DIGIT versteht unsere Richtung" + - "Kennen unsere Strategie nicht" + - "Gutes Verständnis unserer Ziele" + + - id: "D4-C2" + name: "Zukunftsorientierung" + typische_aussagen: + - "Bekommen proaktive Impulse" + - "Nur reaktiv" + - "Denken mit uns voraus" + + - id: "D4-C3" + name: "Strategische Abstimmung" + typische_aussagen: + - "IT-Strategie passt zu unseren Zielen" + - "Prioritäten passen nicht" + - "Gute strategische Zusammenarbeit" + +# ============================================================================= +# RÜCKFLUSS-MECHANISMUS +# ============================================================================= + +rueckfluss_mechanismus: + + beschreibung: | + VoC ist kein Einweg-System. Die Erkenntnisse müssen zurück zu + den Stakeholdern fließen und in konkrete Maßnahmen münden. + + # --------------------------------------------------------------------------- + # RÜCKSPIELUNG AN STAKEHOLDER + # --------------------------------------------------------------------------- + + rueckspielung_stakeholder: + + grundsatz: | + Stakeholder sollen erfahren, dass ihr Feedback gehört wurde + und welche Konsequenzen es hatte. + + mechanismen: + + - kanal: "Turnus-Gespräch" + beschreibung: | + Zu Beginn jedes Turnus-Gesprächs Rückbezug auf frühere + Rückmeldungen: "Beim letzten Mal hatten Sie X angemerkt. + Wir haben Y unternommen." + frequenz: "Bei jedem Gespräch" + verantwortung: "Stakeholder-Manager" + + - kanal: "Auftraggeber-Forum" + beschreibung: | + Jährliche Zusammenfassung: "Was haben wir aufgrund Ihres + Feedbacks verändert?" als fester Agenda-Punkt. + frequenz: "Jährlich" + verantwortung: "SHM-Leitung" + + - kanal: "Direkte Rückmeldung" + beschreibung: | + Bei Kritik-Highlights proaktive Information über + eingeleitete Maßnahmen, ohne auf den nächsten Turnus + zu warten. + frequenz: "Anlassbezogen" + verantwortung: "Stakeholder-Manager" + + # --------------------------------------------------------------------------- + # MASSNAHMENABLEITUNG + # --------------------------------------------------------------------------- + + massnahmenableitung: + + grundsatz: | + Nicht jedes Feedback erfordert eine Maßnahme. Die Ableitung + erfolgt auf Basis der Cluster-Bewertung und Highlights. + + ableitungslogik: + + - ausloeser: "Einzelnes Kritik-Highlight" + massnahme: "Intervention" + verantwortung: "Stakeholder-Manager" + zeithorizont: "Kurzfristig (Tage/Wochen)" + + - ausloeser: "Cluster Gelb" + massnahme: "Beobachtung verstärken" + verantwortung: "SHM-Leitung (E2-Review)" + zeithorizont: "Mittelfristig (Quartal)" + + - ausloeser: "Cluster Rot" + massnahme: "Maßnahmenplanung" + verantwortung: "SHM-Leitung (E2-Review)" + zeithorizont: "Mittelfristig (Quartal)" + + - ausloeser: "Systematisches Muster" + massnahme: "Strukturelle Verbesserung" + verantwortung: "Erweiterter E2-Review (Q2/Q4)" + zeithorizont: "Langfristig (Halbjahr)" + + - ausloeser: "Strategie-relevante Erkenntnis" + massnahme: "Weiterleitung an Strategieprozess" + verantwortung: "SHM-Leitung" + zeithorizont: "Strategiezyklus" + + # --------------------------------------------------------------------------- + # WIRKSAMKEITSVALIDIERUNG + # --------------------------------------------------------------------------- + + wirksamkeitsvalidierung: + + grundsatz: | + Maßnahmen müssen auf ihre Wirksamkeit überprüft werden. + Die Validierung erfolgt über das VoC-System selbst – + der Kreis schließt sich. + + validierungsmechanismen: + + - mechanismus: "Cluster-Entwicklung" + beschreibung: | + Beobachtung der Ampel-Entwicklung im Folgequartal. + Hat sich ein Rot-Cluster nach Maßnahmenumsetzung + auf Gelb oder Grün verbessert? + pruefung_durch: "SHM-Leitung im E2-Review" + dokumentation: "Trend-Kommentar in Cluster-Übersicht" + + - mechanismus: "Stakeholder-Rückmeldung" + beschreibung: | + Direkte Bestätigung durch den betroffenen Stakeholder + im nächsten Turnus-Gespräch: "Hat sich aus Ihrer Sicht + etwas verbessert?" + pruefung_durch: "Stakeholder-Manager" + dokumentation: "Notiz im Gesprächsprotokoll" + + - mechanismus: "Highlight-Tracking" + beschreibung: | + Beobachtung, ob ein Kritik-Highlight in Folgeperioden + erneut auftaucht. Wiederholtes Auftauchen = Maßnahme + nicht wirksam. + pruefung_durch: "SHM-Leitung" + dokumentation: "Verweis auf frühere Highlights in E2-Review" + + - mechanismus: "Maßnahmen-Review" + beschreibung: | + Explizite Überprüfung offener Maßnahmen im E2-Review: + Status, Wirkung, ggf. Nachjustierung. + pruefung_durch: "SHM-Leitung" + dokumentation: "Maßnahmen-Status in E2-Protokoll" + + eskalation_bei_unwirksamkeit: | + Wenn eine Maßnahme nach zwei Quartalen keine erkennbare + Wirkung zeigt, wird das Thema im erweiterten E2-Review (Q2/Q4) + als strukturelles Verbesserungsthema behandelt. + +# ============================================================================= +# UMGANG MIT WIDERSPRÜCHLICHEM FEEDBACK +# ============================================================================= + +umgang_mit_widerspruechen: + + grundsatz: | + Widersprüche sind Informationsquelle, nicht Problem. Sie werden + nicht eliminiert oder geglättet, sondern als Hinweis auf + unterschiedliche Perspektiven oder Kontexte interpretiert. + + situationen: + + - situation: "Gleicher Sachverhalt, unterschiedliche Bewertung" + beispiel: "Amt A findet Support schnell, Amt B findet ihn langsam" + interpretation: "Unterschiedliche Erwartungen oder Kontexte" + handlung: "Erwartungsklärung, ggf. Segmentierung der Ansprache" + + - situation: "Unterschiedliche Sachverhalte" + beispiel: "Lob für Service X, Kritik an Service Y" + interpretation: "Kein echter Widerspruch" + handlung: "Getrennt behandeln" + + - situation: "Feedback vs. Selbstwahrnehmung SHM" + beispiel: "Stakeholder kritisiert Erreichbarkeit, SHM sieht kein Problem" + interpretation: "Möglicher blinder Fleck bei SHM" + handlung: "Ernstnehmen, reflektieren, ggf. externe Perspektive einholen" + + - situation: "Feedback von verschiedenen Ebenen" + beispiel: "Amtsleitung zufrieden, Sachbearbeiter kritisch" + interpretation: "Unterschiedliche Perspektiven auf gleiche Realität" + handlung: "Beide dokumentieren, nicht gegeneinander ausspielen" + +# ============================================================================= +# INTEGRATION IN STEUERUNGSSTRUKTUR +# ============================================================================= + +integration_steuerungsstruktur: + + beschreibung: | + VoC ist kein isoliertes Erfassungssystem, sondern integraler + Bestandteil der SHM Koordinations- und Steuerungsstruktur. + Die folgende Zuordnung zeigt, wie VoC in die Entscheidungstypen + einfließt. + + zuordnung: + + - entscheidungstyp: "E1 (Auftragserfüllung)" + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + voc_beitrag: | + VoC liefert die aggregierte Stakeholder-Stimme als zentralen + Erfolgsindikator. Die Frage "Erfüllen wir unseren Auftrag?" + wird wesentlich durch "Was sagen die Stakeholder?" beantwortet. + voc_output: "Verdichtung E1 (Jahres-Review)" + + - entscheidungstyp: "E2 (Portfolio-Qualität, Lernen & Verbesserung)" + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + voc_beitrag: | + VoC informiert sowohl die Portfolio-Betrachtung als auch die + Verbesserungsplanung: + - Portfolio: Welche Beziehungen sind belastet? Welche Muster? + - CI: Systematische Muster, die auf Prozessprobleme hindeuten + voc_output: "Verdichtung E2 (Quartals-Review)" + + - entscheidungstyp: "E3 (Operative Koordination)" + referenz: "shm_koordinations-und-steuerungsstruktur.yaml" + voc_beitrag: | + Aktuelle Highlights (insbesondere Kritik-Highlights) fließen + in die Team-Koordination ein. Interventionsfälle werden auf + Basis von VoC-Signalen identifiziert. + voc_output: "Highlights (laufend)" + +# ============================================================================= +# VISUALISIERUNG +# ============================================================================= + +visualisierung: + + beschreibung: | + Die Cluster-Ampel-Matrix bietet eine kompakte Übersicht über + den VoC-Status. Sie wird im Quartals-Review (E2) verwendet. + + beispiel_darstellung: | + VoC Cluster-Status Q1/2025 + ═══════════════════════════════════════════════════════════ + + │ Grün │ Gelb │ Rot │ Grau │ + ────────────────────────┼──────┼──────┼─────┼──────┤ + D1 Beziehungsqualität │ │ │ │ │ + ├─ Erreichbarkeit │ ● │ │ │ │ + ├─ Kommunikation │ ● │ │ │ │ + ├─ Verbindlichkeit │ │ ● │ │ │ + └─ Partnerschaftl. │ ● │ │ │ │ + ────────────────────────┼──────┼──────┼─────┼──────┤ + D2 Service-Qualität │ │ │ │ │ + ├─ Verfügbarkeit │ ● │ │ │ │ + ├─ Performance │ │ ● │ │ │ + ├─ Support │ │ │ ● │ │ + └─ Funktionalität │ │ ● │ │ │ + ────────────────────────┼──────┼──────┼─────┼──────┤ + D3 Bedarfserfüllung │ │ │ │ │ + ├─ Bedarfserkennung │ ● │ │ │ │ + ├─ Umsetzungsgeschw. │ │ │ ● │ │ + ├─ Priorisierung │ │ ● │ │ │ + └─ Transparenz │ │ ● │ │ │ + ────────────────────────┼──────┼──────┼─────┼──────┤ + D4 Strateg. Passung │ │ │ │ │ + ├─ Verständnis │ ● │ │ │ │ + ├─ Zukunftsorient. │ │ ● │ │ │ + └─ Abstimmung │ ● │ │ │ │ + ═══════════════════════════════════════════════════════════ + + Legende: ● = aktuelle Bewertung + + Trend-Indikatoren (optional): + ▲ = Verbesserung ggü. Vorquartal + ▼ = Verschlechterung ggü. Vorquartal + ─ = Unverändert + + anwendungshinweis: | + Die Matrix dient der schnellen Orientierung. Details zu einzelnen + Clustern (Highlights, Handlungsbedarf) werden im Fließtext des + Quartalsberichts erläutert. + +# ============================================================================= +# SCHEMA-HINWEIS +# ============================================================================= + +schema_hinweis: + + id: "VOC-MOD-02" + + status: "Informelles Schema ausreichend für MVP" + + beschreibung: | + Für den MVP-Start ist kein formales Datenbank-Schema erforderlich. + Die Mindestattribute (siehe Aggregationslogik Stufe 1) definieren + die erwartete Struktur hinreichend. + + bei_tool_einfuehrung: | + Wenn ein dediziertes VoC-Tool oder eine SIMS-Integration eingeführt + wird, ist ein formales Schema zu entwickeln. Dieses sollte auf den + hier definierten Mindestattributen aufbauen. + + referenz_arbeitsmaterialien: | + Die Template-Anpassungen (Feedback-Notizen-Abschnitt in Turnus- + Gespräch-Templates) werden in Phase 10 umgesetzt. + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-10" + autor: "Konzept-Sprint Phase 5" + aenderung: | + Initiale Erstellung basierend auf Working Document: + - Zweck und Funktion definiert + - Verantwortungsabgrenzung Customer/User dokumentiert + - Feedback-Dimensionen D1-D4 spezifiziert + - Feedback-Quellen Q-01 bis Q-06 inventarisiert + - Dreistufige Aggregationslogik entwickelt + - Thematische Cluster als Annahmen dokumentiert + - Kritikalitäts-Ampel mit Bewertungskriterien definiert + - Rückfluss-Mechanismus konzipiert + - Integration in Steuerungsstruktur beschrieben - Visualisierung (Cluster-Ampel-Matrix) beispielhaft dargestellt \ No newline at end of file diff --git a/#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml b/#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml index d43a3b9..2822cd0 100644 --- a/#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml +++ b/#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml @@ -1,1179 +1,1179 @@ -# ============================================================================= -# SHM BEDARFSBEWERTUNG: METHODIK -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Funktion: Methodik -# Version: 1.3 -# Datum: 2025-01-29 -# Status: Entwurf -# Entwicklungsphase: 3 -# ============================================================================= - -meta: - modul_id: "SHM-M-01" - name: "Bedarfsbewertung" - typ: "Methodik" - - zweck: | - Die Bedarfsbewertung ist die methodische Handlungsanleitung für den - Stakeholder-Manager zur Beantwortung der Kernfrage: - - "Wohin gehört dieser Bedarf?" - - Sie operationalisiert die Routing-Entscheidung (E2) aus dem - Stakeholder-Portfolio und definiert, wie der Stakeholder-Manager - von einem eingehenden Bedarf zu einer qualifizierten Übergabe kommt. - - abgrenzung: - bedarfssteckbrief_schema: | - Das Schema (shm_schema_bedarfssteckbrief.yaml) definiert WAS dokumentiert - wird. Diese Methodik definiert WIE entschieden wird. - - dpm_klassifizierung: | - Die DPM-Klassifizierung (dpm_demand-klassifizierung.yaml) greift NACH - der SHM-Bewertung. SHM entscheidet OB etwas ein Demand ist, DPM - klassifiziert WIE der Demand priorisiert und bearbeitet wird. - - service_desk: | - Der Service Desk (L1) bearbeitet Standard-Requests und -Incidents. - Bedarfe, die nicht über L1 lösbar sind oder komplexere Anforderungen - darstellen, werden an SHM eskaliert. - - referenzen: - - dokument: "shm_schema_bedarfssteckbrief.yaml" - beschreibung: "Datenstruktur für die Bedarfsdokumentation" - - dokument: "shm_stakeholder-portfolio.yaml" - beschreibung: "Kernentscheidung E2 (Bedarfsrouting)" - - dokument: "shm_engagement-framework.yaml" - beschreibung: "Formate für Bedarfserhebung" - - dokument: "dpm_demand-klassifizierung.yaml" - beschreibung: "Nachgelagerte Demand-Klassifizierung im DPM" - - dokument: "shm_interne-bedarfe-routing.yaml" - beschreibung: "Routing und SHM-Rolle bei internen DIGIT-Bedarfen" - pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" - - itil4_referenz: - practice: "Business Analysis" - relevante_elemente: - - "Requirement Gathering" - - "Stakeholder Analysis" - - "Solution Evaluation" - adaption_fuer_digitom: | - Die ITIL4-Business-Analysis-Practice liefert methodischen Input für - die Bedarfserhebung (Schritt 0). Die Routing-Logik ist DIGITOM-spezifisch - und bildet die Schnittstellen zwischen SHM, SPM und DPM ab. - -# ============================================================================= -# FUNKTIONALE HERLEITUNG -# ============================================================================= - -funktionale_herleitung: - - kernfrage: "Wohin gehört dieser Bedarf?" - - geltungsbereich: | - Diese Bedarfsbewertung unterscheidet drei Bedarfstypen mit unterschiedlichen - Prozesswegen: - - **1. Externe Stakeholder-Bedarfe (Regelweg)** - Bedarfe von Ämtern und Dienststellen außerhalb von DIGIT durchlaufen die - vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3). Dies ist der - Hauptanwendungsfall dieser Methodik. - - **2. Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track)** - Bedarfe von DIGIT-Mitarbeitern als Nutzer (z.B. Personalabteilung DIGIT, - Sekretariat, Sachbearbeiter) durchlaufen einen vereinfachten Fast Track - Prozess (10-15 Minuten). Siehe Abschnitt "Fast Track für interne Bedarfe". - - **3. Service-Lifecycle-Bedarfe (Bypass)** - Bedarfe aus dem Service-Lifecycle (Service Owner identifiziert Redesign, - ISB fordert Sicherheitsänderung, strategische Initiative) durchlaufen - die SHM-Triage nicht, sondern treten direkt in den Demand-Lifecycle ein. - SHM wird bei Stakeholder-Auswirkungen informiert. - - Siehe: shm_interne-bedarfe-routing.yaml (Arbeitsmaterial) - Siehe: shm_d2p-integration.yaml#abgrenzung_bedarfsquellen (GOV-SHM-026) - - kontext: | - Wenn ein Bedarf beim Stakeholder-Manager eingeht, muss dieser zwei - Aufgaben erfüllen: - - 1. Den tatsächlichen Bedarf verstehen (nicht die vorgeschlagene Lösung) - 2. Den Bedarf an die richtige Stelle im DIGIT-System routen - - Die Bewertung ist keine technische Analyse – diese erfolgt beim Empfänger. - Die Bewertung ist eine Triage: Schnell, strukturiert, nachvollziehbar. - - routing_pfade: - - - id: "ROUTE-REQ" - name: "Request Fulfilment" - empfaenger: "Service Desk / Service Owner" - trigger: "Bedarf ist durch bestehenden Katalog abbildbar" - status_im_steckbrief: "n/a (kein Bedarfssteckbrief erforderlich)" - beschreibung: | - Standard-Anfragen, die über den Service-Katalog bedient werden können. - Diese verlassen den SHM-Scope direkt und werden als Request behandelt. - - - id: "ROUTE-SPM" - name: "Service Portfolio Management" - empfaenger: "Service Owner (via SPM)" - trigger: "Bedarf betrifft Änderung an bestehendem Service" - status_im_steckbrief: "an_spm_uebergeben" - beschreibung: | - Changes an bestehenden Services, die vom zuständigen Service Owner - bearbeitet werden. Der Bedarfssteckbrief wird an SPM übergeben. - - - id: "ROUTE-DPM" - name: "Demand Portfolio Management" - empfaenger: "DPM (Demand-to-Product-Prozess)" - trigger: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" - status_im_steckbrief: "an_dpm_uebergeben" - beschreibung: | - Neue Bedarfe mit Projektcharakter, die den Demand-to-Product-Prozess - durchlaufen. Der qualifizierte Bedarf wird zum Demand. - - - id: "ROUTE-SO" - name: "Service-Owner-Klärung" - empfaenger: "Service Owner (über Service-Portfolio / SPM)" - trigger: "Routing unklar – Klärung über Service Owner erforderlich" - status_im_steckbrief: "in_so_klaerung" - beschreibung: | - Der SO gibt eine Routing-Empfehlung ab. Die formelle Entscheidung erfolgt - in der SOR (Change); Demand geht direkt an DPM (nicht über DSR). - - Pfad A – SO identifizierbar: SHM prüft das Service-Portfolio und - kontaktiert den identifizierten Service Owner direkt. Der SO - prüft und gibt eine Empfehlung ab, ob der Bedarf als Change im RUN - umsetzbar ist oder ob es sich um einen Demand handelt. - - Pfad B – Kein SO identifizierbar: SHM kontaktiert SPM zur - Unterstützung bei der Service-Identifikation. SPM hilft, den - betroffenen Service und zuständigen SO zu finden. Danach - gibt der SO eine Empfehlung wie in Pfad A ab. - - Nach SO-Empfehlung (als ob-Weiterbearbeitung): - - RUN/Change → Der Bedarf wird bereits bearbeitet; formelle Bestätigung in SOR - - Demand → Der Bedarf wird bereits bearbeitet; direkte Übergabe an DPM (ohne DSR) - - Kleine Changes können vom SO direkt ohne SOR umgesetzt werden. - Eskalation: Mission Board, falls Gremium die SO-Empfehlung überstimmt - und diese Übersteuerung nicht formal begründet ist. - referenz: "GOV-SHM-029" - - - id: "ROUTE-DPM-INTERN" - name: "DPM (Interner Fast Track)" - empfaenger: "DPM (Demand-to-Product-Prozess)" - trigger: "Interner DIGIT-Bedarf erfordert neuen Service" - status_im_steckbrief: "an_dpm_uebergeben_intern" - beschreibung: | - Interne Bedarfe von DIGIT-Mitarbeitern, die einen neuen Service - erfordern, werden mit reduziertem Bedarfssteckbrief an DPM übergeben. - DPM kann bei Bedarf Informationen nachfordern. - validierungsprofil: "ROUTE-DPM-INTERN" - -# ============================================================================= -# PROZESSABLAUF -# ============================================================================= - -prozessablauf: - - beschreibung: | - Der Prozess besteht aus einem vorgelagerten Schritt (Bedarfserhebung) - und drei sequentiellen Prüfungen. Jede Prüfung führt entweder zu einem - Routing-Ergebnis oder zur nächsten Prüfung. - - **Hinweis:** Für interne DIGIT-Mitarbeiter-Bedarfe gilt der vereinfachte - Fast Track Prozess (siehe Abschnitt schritt_0a_fast_track_intern). - - # --------------------------------------------------------------------------- - # SCHRITT 0a: FAST TRACK FÜR INTERNE DIGIT-BEDARFE - # --------------------------------------------------------------------------- - - schritt_0a_fast_track_intern: - name: "Fast Track für interne DIGIT-Bedarfe" - leitfrage: "Ist der Bedarf durch einen bestehenden Service abdeckbar?" - - beschreibung: | - Interne DIGIT-Mitarbeiter (z.B. Personalabteilung, Sekretariat, - Sachbearbeiter in DIGIT) haben Bedarfe als Nutzer von IT-Services. - Diese durchlaufen einen vereinfachten 3-Schritte-Prozess (10-15 Minuten), - um SHM nicht unnötig zu belasten. - - **Abgrenzung:** Dieser Fast Track gilt für DIGIT-Mitarbeiter als *Nutzer*. - Service Owner, die Bedarfe für ihren eigenen Service haben, nutzen die - Service-Lifecycle-Wege (siehe shm_interne-bedarfe-routing.yaml). - - anwendungsbereich: - gilt_fuer: - - "DIGIT-Personalabteilung" - - "DIGIT-Sekretariat" - - "DIGIT-Sachbearbeiter (als Nutzer, nicht als SO)" - - "Andere DIGIT-interne Organisationseinheiten" - gilt_nicht_fuer: - - "Service Owner (für eigenen Service) → Service-Lifecycle" - - "ISB/Compliance → Sicherheits-/Compliance-Prozess" - - "Externe Ämter → Regelweg (Schritt 0, Prüfungen 1-3)" - - eingangskanal: - primaer: "Self-Service-Portal (ITSM-Tool)" - mvp: "E-Mail-Template an SHM" - pflichtfelder: - - "Titel / Kurzbeschreibung" - - "Kontaktperson und Abteilung" - - "Problemstellung (2-3 Sätze)" - - "Zielbild (1-2 Sätze)" - - "Betroffene Systeme (falls bekannt)" - - "Dringlichkeit (S/M/L)" - - prozess: - - schritt_1: - name: "Basistriage" - dauer: "3-5 Minuten" - leitfrage: "Ist es ein valider Bedarf?" - pruefungen: - - "Ist der Bedarf verständlich formuliert?" - - "Liegt er im Scope von DIGIT?" - - "Ist die Kontaktperson erreichbar?" - ergebnisse: - - ergebnis: "valide" - aktion: "Weiter zu Schritt 2" - - ergebnis: "unklar" - aktion: "Rückfrage an Einreichenden" - status: "in_klaerung_intern" - - ergebnis: "out_of_scope" - aktion: "Ablehnung mit Begründung" - - schritt_2: - name: "Routing-Entscheidung" - dauer: "5-7 Minuten" - leitfrage: "Wohin gehört der Bedarf?" - pruefungen: - - frage: "Gibt es einen bestehenden Service, der den Bedarf adressiert?" - ja: "Direkt an Service Owner (kein Steckbrief)" - nein: "Weiter prüfen" - - frage: "Ist ein neuer Service oder grundlegende Änderung erforderlich?" - ja: "ROUTE-DPM-INTERN (mit Minimaldoku)" - nein: "Weiter prüfen" - - frage: "Ist das Routing unklar?" - ja: "ROUTE-SO (Service-Owner-Klärung)" - ergebnisse: - - ergebnis: "bestehender_service" - routing: "Direkt an Service Owner" - steckbrief_erforderlich: false - beschreibung: "SO klärt: Change oder Ablehnung" - - ergebnis: "neuer_service" - routing: "ROUTE-DPM-INTERN" - steckbrief_erforderlich: true - profil: "ROUTE-DPM-INTERN (reduziert)" - - ergebnis: "unklar" - routing: "ROUTE-SO" - steckbrief_erforderlich: true - beschreibung: "Service-Owner-Klärung (bilateral)" - - schritt_3: - name: "Minimaldokumentation" - dauer: "3-5 Minuten" - bedingung: "Nur bei ROUTE-DPM-INTERN" - beschreibung: | - SHM ergänzt eine kurze Einschätzung (2-3 Sätze) und übergibt - an DPM. Der Bedarfssteckbrief ist reduziert (Profil ROUTE-DPM-INTERN). - shm_einschaetzung_template: | - - Quelle: Interner Bedarf aus Abt. [X] - - Thema: [Kurzbeschreibung] - - Service-Katalog: [Kein Service / Teilweise abgedeckt durch ...] - - Größeneinschätzung: [S / M / L] - - Besonderheiten: [Optional] - - validierungsprofil_route_dpm_intern: - beschreibung: | - Reduziertes Validierungsprofil für interne Bedarfe. DPM kann über - die Rückkopplungsschleife Nachforderungen stellen. - erforderlich: - - "Basisdaten (vollständig)" - - "Stakeholder-Kontext (automatisch: 'intern')" - - "Bedarfsbeschreibung (Kernproblem + Zielbild)" - - "Größeneinschätzung (S/M/L)" - - "SHM-Einschätzung (2-3 Sätze)" - - "Service-Katalog-Prüfung" - nicht_erforderlich: - - "User Stories (DPM fordert bei Bedarf nach)" - - "Stakeholder-Freigabe (interner Mitarbeiter)" - - "Detaillierte Abhängigkeiten (DPM fordert bei Bedarf nach)" - - "Rahmenbedingungen (optional)" - - zeitrahmen: - erstreaktion: "Innerhalb von 24-48 Stunden" - gesamtdauer: "10-15 Minuten pro Bedarf" - - beispiele: - - - titel: "Personalabteilung DIGIT möchte neue Personalsoftware" - situation: | - Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue - Software zur Zeiterfassung, da das aktuelle System nicht mehr - den Anforderungen entspricht. - fast_track_ablauf: - schritt_1: "Valide – Bedarf verständlich, im Scope" - schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN" - schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M" - ergebnis: "An DPM mit reduziertem Steckbrief" - - - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" - situation: | - Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang - für kollaborative Workshops. - fast_track_ablauf: - schritt_1: "Valide – Bedarf verständlich" - schritt_2: "Bestehender Service: Conceptboard → Direkt an SO" - schritt_3: "Nicht erforderlich" - ergebnis: | - Direkt an Service Owner Conceptboard. SO klärt: Reicht Conceptboard - aus oder fehlt eine Funktion (dann ggf. Change)? - - - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" - situation: | - Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung - mit externen Besuchern. - fast_track_ablauf: - schritt_1: "Valide – Bedarf verständlich, im Scope" - schritt_2: "Prüfung: Gibt es bereits ein Kalendertool mit Buchungsfunktion?" - schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" - ergebnis: "Abhängig von Service-Katalog-Prüfung" - - governance_referenz: "PATCH_NOTES_interne_bedarfe_v1.1.md" - - # --------------------------------------------------------------------------- - # SCHRITT 0: BEDARFSERHEBUNG (REGELWEG FÜR EXTERNE STAKEHOLDER) - # --------------------------------------------------------------------------- - - schritt_0: - name: "Bedarfserhebung" - leitfrage: "Was ist der tatsächliche Bedarf?" - - beschreibung: | - Bevor geroutet werden kann, muss der Stakeholder-Manager den - tatsächlichen Bedarf verstehen. Stakeholder formulieren oft - Lösungen ("Wir brauchen eine Datenbank") statt Bedarfe - ("Wir müssen Anträge zentral verwalten"). - - Die Kernaufgabe ist der Perspektivwechsel: Vom "Cheeseburger" - zum "Hunger". - - methode: "User-Story-Erhebung" - - user_story_format: - schema: "Als [Rolle] möchte ich [Funktionalität], um [Nutzen]" - beispiel: - rolle: "Sachbearbeiterin im Bauamt" - funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen" - nutzen: "zusammenhängende Anträge schnell identifizieren" - - leitfragen: - - "Was möchten Sie in Ihrer täglichen Arbeit erreichen?" - - "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt." - - "Was würde Ihnen die Arbeit erleichtern?" - - "Wobei verlieren Sie die meiste Zeit?" - - typische_uebersetzungen: - - stakeholder_sagt: "Wir brauchen eine Datenbank" - shm_fragt: "Was möchten Sie damit tun?" - bedarf_wird: "Anträge zentral verwalten" - - - stakeholder_sagt: "Das System ist zu langsam" - shm_fragt: "Wobei genau verlieren Sie Zeit?" - bedarf_wird: "Suchergebnisse in unter 3 Sekunden erhalten" - - - stakeholder_sagt: "Wir wollen alles digitalisieren" - shm_fragt: "Was genau soll digital werden?" - bedarf_wird: "Anträge online einreichen können" - - output: "Qualifizierter Bedarf mit mindestens einer User Story" - - qualitaetskriterien: - - "Rolle spezifisch identifiziert (nicht 'Nutzer')" - - "Funktionalität klar beschrieben (keine Lösungsvorgabe)" - - "Nutzen explizit gemacht" - - "Mit Stakeholder validiert" - - arbeitsmaterial: - dokument: "leitfaden_user-stories.md" - pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" - status: "zu erstellen" - - # --------------------------------------------------------------------------- - # PRÜFUNG 1: SERVICE-KATALOG-CHECK - # --------------------------------------------------------------------------- - - pruefung_1: - name: "Service-Katalog-Check" - leitfrage: "Lässt sich der Bedarf mit dem bestehenden Katalog bedienen?" - - beschreibung: | - Erste Triage: Ist der Bedarf bereits durch existierende Services - abdeckbar? Diese Prüfung erfolgt auf Basis des Service-Katalogs - und der dort definierten Leistungen. - - prueffragen: - - id: "P1-Q1" - frage: "Existiert ein Service im Katalog, der diesen Bedarf adressiert?" - ja_bedeutet: "Potenziell abbildbar" - nein_bedeutet: "Weiter zu P1-Q4" - - - id: "P1-Q2" - frage: "Kann der Bedarf durch eine Standardleistung (Request) erfüllt werden?" - ja_bedeutet: "Abbildbar → ROUTE-REQ" - nein_bedeutet: "Weiter zu P1-Q3" - - - id: "P1-Q3" - frage: "Liegt der Bedarf innerhalb der definierten Service-Parameter?" - ja_bedeutet: "Teilweise abbildbar → Prüfung 2" - nein_bedeutet: "Weiter zu P1-Q4" - - - id: "P1-Q4" - frage: "Ist der Bedarf grundsätzlich neuartig für DIGIT?" - ja_bedeutet: "Nicht abbildbar → Prüfung 3" - nein_bedeutet: "Unklar → SOR-Eskalation erwägen" - - ergebnisse: - - ergebnis: "abbildbar" - routing: "ROUTE-REQ" - aktion: "Weiterleitung an Service Desk / Request Fulfilment" - steckbrief_erforderlich: false - - - ergebnis: "teilweise_abbildbar" - routing: "Prüfung 2" - aktion: "Change-Qualifizierung durchführen" - steckbrief_erforderlich: true - - - ergebnis: "nicht_abbildbar" - routing: "Prüfung 3" - aktion: "Demand-Indikation prüfen" - steckbrief_erforderlich: true - - dokumentation_im_steckbrief: - feld: "servicekatalog_pruefung.pruefergebnis" - begruendung_erforderlich_bei: "nicht_abbildbar" - service_referenz_erforderlich_bei: ["abbildbar", "teilweise_abbildbar"] - - # --------------------------------------------------------------------------- - # PRÜFUNG 2: CHANGE-QUALIFIZIERUNG - # --------------------------------------------------------------------------- - - pruefung_2: - name: "Change-Qualifizierung" - leitfrage: "Ist ein bestehender Service betroffen und veränderbar?" - - vorbedingung: "Prüfung 1 ergab 'teilweise_abbildbar'" - - beschreibung: | - Wenn ein bestehender Service den Bedarf teilweise adressiert, - prüft der Stakeholder-Manager, ob es sich um einen Change an - diesem Service handelt, der vom Service Owner bearbeitet werden kann. - - prueffragen: - - id: "P2-Q1" - frage: "Ist ein konkreter bestehender Service betroffen?" - ja_bedeutet: "Weiter zu P2-Q2" - nein_bedeutet: "Unklar → SOR" - - - id: "P2-Q2" - frage: "Handelt es sich um eine Erweiterung/Anpassung innerhalb des Service-Scopes?" - ja_bedeutet: "Weiter zu P2-Q3" - nein_bedeutet: "Grundlegende Neugestaltung → Prüfung 3" - - - id: "P2-Q3" - frage: "Ist der zuständige Service Owner identifizierbar?" - ja_bedeutet: "Change → ROUTE-SPM" - nein_bedeutet: "Unklar → Service-Owner-Klärung (ROUTE-SO)" - - ergebnisse: - - ergebnis: "change_identifiziert" - routing: "ROUTE-SPM" - aktion: "Übergabe an Service Owner" - status: "an_spm_uebergeben" - - - ergebnis: "kein_change" - routing: "Prüfung 3" - aktion: "Demand-Indikation prüfen" - - - ergebnis: "unklar" - routing: "ROUTE-SO" - aktion: "Service-Owner-Klärung einleiten (bilateral)" - status: "in_so_klaerung" - - hinweis_abgrenzung: | - Die Frage, ob der Change im Rahmen des Service Owners umsetzbar ist - oder Projektcharakter hat, wird NICHT durch SHM bewertet. Diese - Einschätzung trifft der Service Owner nach Übergabe. - - # --------------------------------------------------------------------------- - # PRÜFUNG 3: DEMAND-INDIKATION - # --------------------------------------------------------------------------- - - pruefung_3: - name: "Demand-Indikation" - leitfrage: "Handelt es sich um einen neuen Bedarf mit Projektcharakter?" - - vorbedingung: "Prüfung 1 ergab 'nicht_abbildbar' ODER Prüfung 2 ergab 'kein_change'" - - beschreibung: | - Wenn der Bedarf weder über den Katalog noch als Change abbildbar ist, - prüft der Stakeholder-Manager, ob die Voraussetzungen für eine - Übergabe an DPM erfüllt sind. - - prueffragen: - - id: "P3-Q1" - frage: "Erfordert der Bedarf einen neuen Service oder eine grundlegende Neugestaltung?" - ja_bedeutet: "Demand-Indikator positiv" - nein_bedeutet: "Nochmal Prüfung 1/2 durchgehen oder ROUTE-SO" - - - id: "P3-Q2" - frage: "Hat der Bedarf Projektcharakter (Einmaligkeit, definierter Scope)?" - ja_bedeutet: "Demand-Indikator positiv" - nein_bedeutet: "Möglicherweise wiederkehrender Prozess → ROUTE-SO" - - - id: "P3-Q3" - frage: "Ist der Bedarfssteckbrief hinreichend befüllt für DPM-Übergabe?" - ja_bedeutet: "Bereit für Übergabe → ROUTE-DPM" - nein_bedeutet: "Nachqualifizierung erforderlich" - - demand_indikatoren: - - "Neuer Service erforderlich (nicht im Katalog)" - - "Grundlegende Neugestaltung eines bestehenden Service" - - "Service-übergreifende Anforderung" - - "Erheblicher Ressourcenbedarf (Projektcharakter)" - - "Externe Abhängigkeiten (andere Behörden, Regulatorik)" - - ergebnisse: - - ergebnis: "demand_bestaetigt" - routing: "ROUTE-DPM" - aktion: "Übergabe an DPM mit vollständigem Bedarfssteckbrief" - status: "an_dpm_uebergeben" - - - ergebnis: "nachqualifizierung" - routing: "Zurück zu Schritt 0" - aktion: "Weitere Bedarfserhebung mit Stakeholder" - - - ergebnis: "unklar" - routing: "ROUTE-SO" - aktion: "Service-Owner-Klärung einleiten (bilateral)" - status: "in_so_klaerung" - -# ============================================================================= -# ROUTING-ENTSCHEIDUNGSBAUM (ÜBERSICHT) -# ============================================================================= - -routing_entscheidungsbaum: - - visualisierung: | - - BEDARF GEHT EIN (roh) - │ - ▼ - ┌─────────────────────────────────────┐ - │ SCHRITT 0: Bedarfserhebung │ - │ "Was ist der tatsächliche Bedarf?" │ - │ → User Stories erarbeiten │ - └─────────────────────────────────────┘ - │ - ▼ - QUALIFIZIERTER BEDARF - │ - ▼ - ┌─────────────────────────────────────┐ - │ PRÜFUNG 1: Service-Katalog-Check │ - │ "Lässt sich der Bedarf mit dem │ - │ bestehenden Katalog bedienen?" │ - └─────────────────────────────────────┘ - │ - ├── JA (abbildbar) ──────────────────► REQUEST FULFILMENT - │ (Out of SHM Scope) - │ - ├── TEILWEISE ───────────────────────► PRÜFUNG 2 - │ - └── NEIN (nicht abbildbar) ──────────► PRÜFUNG 3 - - - ┌─────────────────────────────────────┐ - │ PRÜFUNG 2: Change-Qualifizierung │ - │ "Ist ein bestehender Service │ - │ betroffen und veränderbar?" │ - └─────────────────────────────────────┘ - │ - ├── JA + Service Owner klar ─────────► SERVICE OWNER (SPM) - │ Status: an_spm_uebergeben - │ - ├── NEIN (kein Change) ──────────────► PRÜFUNG 3 - │ - └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG - Status: in_so_klaerung - (Pfad A: SO identifizierbar → direkt) - (Pfad B: kein SO → SPM hilft → dann SO) - │ - SO-EMPFEHLUNG (keine Entscheidung) - │ - ├── RUN/Change ────► Parallel-Bearbeitung - │ + formelle SOR-Bestätigung - │ - └── Demand ────────► Parallel-Bearbeitung - + direkte DPM-Übergabe (kein DSR) - - - ┌─────────────────────────────────────┐ - │ PRÜFUNG 3: Demand-Indikation │ - │ "Handelt es sich um einen neuen │ - │ Bedarf mit Projektcharakter?" │ - └─────────────────────────────────────┘ - │ - ├── JA + Steckbrief vollständig ─────► DPM - │ Status: an_dpm_uebergeben - │ - ├── JA + Steckbrief unvollständig ───► NACHQUALIFIZIERUNG - │ (zurück zu Schritt 0) - │ - └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG - Status: in_so_klaerung - -# ============================================================================= -# SERVICE-OWNER-ROUTING-KLÄRUNG (ersetzt DSR-ROUTING-KLÄRUNG seit GOV-SHM-029) -# ============================================================================= - -so_routing_klaerung: - - beschreibung: | - Bei Routing-Unsicherheit erfolgt die Klärung bilateral über den - zuständigen Service Owner. Der Service Owner gibt eine Empfehlung ab, - ob der Bedarf als Change im bestehenden Service (RUN) umsetzbar ist - oder ob es sich um einen neuen Demand handelt. - - Die SO-Empfehlung führt zu einer "als ob"-Weiterbearbeitung: Der Bedarf - wird sofort und parallel bearbeitet, während die formelle Bestätigung - in der nächsten SOR-Sitzung (Change) erfolgt; Demands gehen direkt an DPM. Dies gewährleistet - Geschwindigkeit ohne Verzögerung durch Gremien-Rhythmen. - - Diese bilaterale Klärung ersetzt die bisherige direkte Eskalation - direkt an den DPM und stellt sicher, dass die - Service-Expertise frühzeitig eingebunden wird. - - referenz: "GOV-SHM-029" - - trigger_kriterien: - - beschreibung: | - Service-Owner-Klärung ist angemessen, wenn der Stakeholder-Manager nach - Durchlaufen der Prüfungen unsicher ist. Die Unsicherheit muss nicht - objektiviert werden – das Urteil des Stakeholder-Managers reicht. - - typische_situationen: - - "Service-Zuordnung nicht eindeutig (mehrere Services betroffen)" - - "Unklar, ob Change oder neuer Demand" - - "Bedarf liegt an Schnittstelle SPM/DPM" - - "Stakeholder und SHM sind sich über Routing uneinig" - - ablauf: - - pfad_a: - name: "Service Owner identifizierbar" - beschreibung: | - SHM prüft das Service-Portfolio und identifiziert einen zuständigen - Service Owner. SHM kontaktiert den SO direkt und schildert den - Bedarf. Der SO prüft und entscheidet. - schritte: - - schritt: 1 - akteur: "SHM" - aktion: "Service-Portfolio prüfen, zuständigen SO identifizieren" - - schritt: 2 - akteur: "SHM" - aktion: "SO kontaktieren mit Bedarfsbeschreibung" - - schritt: 3 - akteur: "SO" - aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" - - pfad_b: - name: "Kein Service Owner identifizierbar" - beschreibung: | - SHM kann im Service-Portfolio keinen eindeutigen SO zuordnen. - SHM kontaktiert SPM, um den betroffenen Service und den zuständigen - SO zu identifizieren. Anschließend wird der SO einbezogen. - schritte: - - schritt: 1 - akteur: "SHM" - aktion: "SPM kontaktieren zur Service-Identifikation" - - schritt: 2 - akteur: "SPM" - aktion: "Service identifizieren, zuständigen SO benennen" - - schritt: 3 - akteur: "SHM + SO" - aktion: "SO einbeziehen, Bedarf besprechen" - - schritt: 4 - akteur: "SO" - aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" - fallback: | - Wenn auch SPM keinen passenden Service identifizieren kann, ist dies - ein starker Indikator für einen neuen Demand (ROUTE-DPM), da kein - bestehender Service den Bedarf abdeckt. - - so_empfehlung: - prozessmodell: | - Die SO-Empfehlung folgt einem Drei-Schritt-Modell: - 1. SO gibt Empfehlung ab (RUN/Change oder Demand) - 2. Bedarf wird sofort "als ob" weiterbearbeitet (parallel-Bearbeitung) - 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM - - Dies ermöglicht schnelle Weiterbearbeitung ohne Warten auf Gremium. - - optionen: - - ergebnis: "RUN/Change" - beschreibung: "Bedarf ist als Change im bestehenden Service umsetzbar" - routing: "ROUTE-SPM" - empfaenger: "SOR (Service Operations Runde) für Implementierung" - status: "an_spm_uebergeben" - als_ob_bearbeitung: "Der Change wird sofort im RUN-Prozess bearbeitet; formelle SOR-Bestätigung folgt" - - ergebnis: "Demand" - beschreibung: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" - routing: "ROUTE-DPM" - empfaenger: "DPM nimmt Demand direkt entgegen (kein DSR-Weg)" - status: "an_dpm_uebergeben" - als_ob_bearbeitung: "Der Demand wird sofort im DPM-Prozess bearbeitet; keine DSR-Bestätigung nötig" - - ergebnis: "Kleine Changes (SO-direkt)" - beschreibung: "Bedarf ist als kleine Change direkt umsetzbar (kein SOR nötig)" - routing: "ROUTE-SO-DIREKT" - empfaenger: "SO führt Change selbständig durch" - status: "in_so_umsetzung" - als_ob_bearbeitung: "SO umsetzt die kleine Change direkt; nachträgliche Dokumentation in nächster SOR" - - ergebnis: "Rückgabe" - beschreibung: "SO benötigt weitere Informationen" - routing: "Zurück zu SHM" - empfaenger: "SHM zur Nachqualifizierung" - status: "in_qualifizierung" - - dokumentation: | - Die SO-Routing-Empfehlung wird im Bedarfssteckbrief dokumentiert - (Feld: so_routing_empfehlung) mit Angabe des SO, Datum, - Empfehlung (RUN/Change oder Demand) und Begründung. - - formelle_bestaetigung: | - Die formelle Bestätigung erfolgt in der nächsten zuständigen Gremium-Sitzung: - - RUN/Change: SOR (Service Operations Runde) unter Vorsitz SPM - - Demand: Direkt an DPM (kein DSR-Routing). DSR nur für Portfolio-Governance - - Das Gremium kann: - - Die SO-Empfehlung bestätigen → Weiterbearbeitung wird formalisiert - - Die SO-Empfehlung ablehnen → MUSS mit formal begründeten Argumenten erfolgen - (kein "Bauchgefühl"), z.B. Ressourcen, Strategie, Abhängigkeiten - - Bei Ablehnung durch Gremium: SO oder SHM können zur Mission Board eskalieren - und die Übersteuerung hinterfragen. - - eskalation: - stufe_1: - beschreibung: "SO und SHM können sich nicht einigen" - aktion: "Einbindung der Leitung SHM und SPM" - stufe_2: - beschreibung: "Gremium (SOR) überstimmt SO-Empfehlung" - aktion: | - Übersteuerung MUSS formal begründet werden. Zulässige Begründungen: - - Ressourcen-Constraints (z.B. SOR: Change passt zeitlich nicht) - - Strategische Neugewichtung (z.B. DPM: andere Demands prioritärer) - - Abhängigkeiten (z.B. andere Services betroffen) - - Governance-Gründe (z.B. Eskalation im DPM erforderlich) - - NICHT zulässig: "Bauchgefühl", "war immer so", ohne Argumentation - - fallback: | - Wenn Gremium-Ablehnung nicht begründet ist, oder wenn SO/SHM - die Begründung nicht akzeptieren, können sie zur Mission Board eskalieren - und die Übersteuerung anfechten. - referenz: "GOV-MB-001" - stufe_3: - beschreibung: "Mission Board muss Gremium-Übersteuerung bewerten" - aktion: "Eskalation an Mission Board" - referenz: "GOV-MB-001" - -# ============================================================================= -# STAKEHOLDER-KONTEXT -# ============================================================================= - -stakeholder_kontext: - - beschreibung: | - Der Stakeholder-Kontext aus dem Stakeholder-Portfolio liefert - Hintergrundinformationen für die Bedarfsbewertung. Er beeinflusst - NICHT das Routing, aber die Bearbeitungspriorität. - - relevante_attribute: - - - attribut: "stakeholder_prioritaet" - quelle: "Amts-Steckbrief (automatisch)" - werte: ["Key", "Aktiv", "Standard", "Basis"] - routing_relevant: false - priorisierung_relevant: true - verwendung: | - Die Priorität bestimmt, wie schnell der Bedarf bearbeitet wird - und wie intensiv SHM im weiteren Prozess involviert bleibt - (vgl. Engagement-Framework, Eskalationspfade). - - - attribut: "it_anforderungsprofil" - quelle: "Amts-Steckbrief (automatisch)" - werte: ["Basis", "Erweitert", "Spezial"] - routing_relevant: false - priorisierung_relevant: false - verwendung: | - Das IT-Anforderungsprofil gibt Kontext zur typischen - Bedarfskomplexität des Stakeholders. Ein "Spezial"-Amt hat - erwartbar komplexere Bedarfe als ein "Basis"-Amt. - - ergaenzung_bedarfssteckbrief: - hinweis: | - Diese Attribute sollten im Bedarfssteckbrief-Schema ergänzt werden - (Abschnitt: Stakeholder-Kontext). Sie werden automatisch aus dem - Amts-Steckbrief übernommen. - - schema_ergaenzung: - - feld: "stakeholder_prioritaet" - datentyp: "enum" - quelle: "automatisch aus Amts-Steckbrief" - - feld: "it_anforderungsprofil" - datentyp: "enum" - quelle: "automatisch aus Amts-Steckbrief" - -# ============================================================================= -# PROZESSINTEGRATION -# ============================================================================= - -prozessintegration: - - # --------------------------------------------------------------------------- - # EINGANGSKANÄLE - # --------------------------------------------------------------------------- - - eingangskanäle: - - beschreibung: | - Die Bedarfsbewertung ist kanal-agnostisch. Der Prozess ist identisch, - unabhängig davon, wie der Bedarf eingeht. - - kanäle: - - kanal: "Turnusgespräch" - typ: "proaktiv" - beschreibung: "SHM erhebt Bedarfe aktiv im Rahmen der Regelkommunikation" - - - kanal: "Anfrage per E-Mail/Telefon" - typ: "reaktiv" - beschreibung: "Stakeholder meldet sich direkt beim Stakeholder-Manager" - - - kanal: "Weiterleitung vom Service Desk" - typ: "eskaliert" - beschreibung: "L1 kann Bedarf nicht lösen, eskaliert an SHM" - - - kanal: "Auftraggeber-Forum / Advisory Board" - typ: "proaktiv" - beschreibung: "Bedarfe werden in Cluster-Formaten identifiziert" - - eingangserfassung: | - Unabhängig vom Kanal wird der Bedarf initial im Ticketsystem erfasst - und erhält eine Bedarfs-ID. Der Bedarfssteckbrief wird angelegt. - - # --------------------------------------------------------------------------- - # ZEITRAHMEN - # --------------------------------------------------------------------------- - - zeitrahmen: - - beschreibung: | - Es gibt keine harten SLA-Zeiten für die Bedarfsbewertung. Die - Bearbeitungsgeschwindigkeit orientiert sich an der Stakeholder-Priorität. - - orientierungswerte: - key_stakeholder: "Erstreaktion innerhalb 1 Arbeitstag" - aktiv_stakeholder: "Erstreaktion innerhalb 2 Arbeitstagen" - standard_basis_stakeholder: "Erstreaktion innerhalb 1 Woche" - - hinweis: | - Diese Werte sind Orientierung, keine verbindlichen SLAs. - Verbindliche Zeiten werden ggf. im Performance-Review (Phase 6) - auf Basis empirischer Daten definiert. - - # --------------------------------------------------------------------------- - # DOKUMENTATIONSPFLICHTEN - # --------------------------------------------------------------------------- - - dokumentationspflichten: - - waehrend_bedarfserhebung: - - "User Stories im Bedarfssteckbrief dokumentieren" - - "Gesprächsprotokolle verlinken" - - "Stakeholder-Validierung einholen" - - bei_routing_entscheidung: - - "Prüfergebnis dokumentieren (Katalog-Check)" - - "Begründung bei 'nicht_abbildbar'" - - "Service-Referenz bei 'abbildbar' oder 'teilweise_abbildbar'" - - "SHM-Einschätzung bei DPM-Übergabe" - - bei_so_routing_klaerung: - - "Eigene Einschätzung dokumentieren" - - "Service-Portfolio-Prüfung dokumentieren (SO identifiziert / nicht identifiziert)" - - "SO-Routing-Entscheidung nachträglich eintragen (RUN vs. Demand)" - - "Bei SPM-Einbindung (Pfad B): SPM-Rückmeldung dokumentieren" - -# ============================================================================= -# ABGRENZUNG ZU ANDEREN FUNKTIONEN -# ============================================================================= - -abgrenzung: - - service_desk: - beschreibung: | - Der Service Desk (L1) ist die erste Anlaufstelle für Standard-Anfragen. - Er prüft, ob ein Request/Incident über den Katalog lösbar ist. - - schnittstelle: | - Wenn der Service Desk einen Bedarf nicht lösen kann und dieser - über einen einfachen Request hinausgeht, eskaliert er an SHM. - - abgrenzung: | - Service Desk: "Kann ich das aus dem Katalog bedienen?" - SHM: "Ist das ein Change, ein Demand, oder unklar?" - - service_owner: - beschreibung: | - Der Service Owner ist verantwortlich für einen konkreten Service. - Er bearbeitet Changes an seinem Service. - - schnittstelle: | - SHM übergibt Changes mit dem Bedarfssteckbrief an den Service Owner. - Die technische Bewertung (Machbarkeit, Aufwand) erfolgt beim SO. - - abgrenzung: | - SHM entscheidet: "Geht das zum Service Owner?" - SO gibt Empfehlung ab: "Kann/will ich das umsetzen? (RUN/Change oder Demand?)" - Formelle Entscheidung: SOR (RUN/Change); Demand direkt an DPM - - dpm: - beschreibung: | - Das Demand Portfolio Management bearbeitet qualifizierte Demands - im Demand-to-Product-Prozess. - - schnittstelle: | - SHM übergibt Demands mit vollständigem Bedarfssteckbrief. - DPM klassifiziert und priorisiert den Demand intern. - - abgrenzung: | - SHM entscheidet: "Ist das ein Demand?" - DPM entscheidet: "Wie wird der Demand priorisiert und bearbeitet?" - - spm: - beschreibung: | - Das Service Portfolio Management steuert das Service-Portfolio. - Es ist nicht operativ in die Bedarfsbewertung involviert. - - schnittstelle: | - SPM stellt den Service-Katalog bereit, gegen den SHM prüft. - Bei SOR-Eskalationen ist SPM im Gremium vertreten. - - abgrenzung: | - SPM: "Welche Services gibt es?" - SHM: "Passt dieser Bedarf zu einem Service?" - -# ============================================================================= -# GOVERNANCE-ENTSCHEIDUNGEN -# ============================================================================= - -governance_entscheidungen: - - beschreibung: | - Die folgenden Governance-Entscheidungen wurden während der Entwicklung - dieser Methodik getroffen und werden ins Governance-Entscheidungs-Log - übertragen. - - entscheidungen: - - - id: GOV-SHM-016 - datum: 2025-12-09 - frage: "Beeinflusst die Stakeholder-Priorität das Routing?" - entscheidung: | - Nein. Das Routing basiert ausschließlich auf der Sachfrage - "Was ist der Bedarf?". Die Stakeholder-Priorität beeinflusst - die Bearbeitungsgeschwindigkeit, nicht das Ziel. - begruendung: | - Routing muss sachlogisch nachvollziehbar sein. Ein Demand bleibt - ein Demand, unabhängig davon, wer ihn einreicht. - status: final - - - id: GOV-SHM-017 - datum: 2025-12-09 - frage: "Welche Kriterien triggern eine Routing-Klärung?" - entscheidung: | - Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. - Es gibt keine quantitativen Schwellenwerte. - begruendung: | - Objektivierte Kriterien würden zu Schein-Objektivität führen. - Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu - erkennen und angemessen zu eskalieren. - status: final - nachtrag: - datum: "2025-12-17" - hinweis: | - Demand-Routing erfolgt direkt an DPM (GOV-SHM-029). - Seit GOV-SHM-029 (2026-03-04) erfolgt die Routing-Klärung - bilateral über den Service Owner (ROUTE-SO). - nachtrag_2: - datum: "2026-03-04" - hinweis: | - Routing-Klärung erfolgt jetzt bilateral über den Service Owner - (nicht mehr über DSR). Siehe GOV-SHM-029. - - - id: GOV-SHM-029 - datum: 2026-03-04 - frage: "Wie wird bei Routing-Unsicherheit (Change vs. Demand) vorgegangen?" - entscheidung: | - Bei Routing-Unsicherheit prüft SHM zunächst das Service-Portfolio - auf einen zuständigen Service Owner (SO). - - Pfad A: Wenn ein SO identifizierbar ist, wird dieser direkt - kontaktiert. Der SO entscheidet, ob der Bedarf als Change im - RUN umsetzbar ist oder als Demand weitergeleitet wird. - - Pfad B: Wenn kein SO identifizierbar ist, wird SPM eingebunden, - um den betroffenen Service und den zuständigen SO zu finden. - Anschließend entscheidet der SO wie in Pfad A. - - Nach SO-Entscheidung: - - RUN/Change: SOR ist zuständig für die Implementierung. - - Demand: DPM nimmt direkt entgegen (kein DSR-Umweg). - - Eskalation: Mission Board, falls DPM den Demand nicht akzeptiert. - begruendung: | - Die bisherige direkte Eskalation an die DSR (ROUTE-DSR) wurde - als zu formalisiert bewertet. Der Service Owner hat die fachliche - Expertise, um die Routing-Entscheidung zu treffen. Die bilaterale - Klärung ist schneller und nutzt die vorhandene Service-Kompetenz. - SPM dient als Brücke zum SO, wenn die Zuordnung nicht direkt - möglich ist. - ersetzt: "ROUTE-DSR (DSR als Routing-Klärungsgremium)" - status: final - quelle: "Workshop Bedarfsrouting-Klärung, 2026-03-04" - - - id: GOV-SHM-018 - datum: 2025-12-09 - frage: "Prüft SHM die Service-Kategorie (A/B/C) bei der Bewertung?" - entscheidung: | - Nein. Die Service-Kategorie ist informativ (aus Amts-Steckbrief), - aber nicht entscheidungsrelevant für das Routing. - begruendung: | - Die konkrete Service-Kategorie-Zuordnung ist Aufgabe von SPM/SO. - SHM prüft nur: "Ist der Bedarf katalog-abbildbar?" - status: final - - - id: GOV-SHM-019 - datum: 2025-12-09 - frage: "Ist eine Aufwandsschätzung routing-relevant?" - entscheidung: | - Nein. Die Aufwandsschätzung im Bedarfssteckbrief ist informativ - für den Empfänger, aber nicht entscheidungsrelevant für das Routing. - begruendung: | - Die Frage "Was ist es?" ist unabhängig von "Wie groß ist es?". - Ein kleiner Demand bleibt ein Demand. - status: final - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-BEW-003" - beschreibung: "Checkliste Bedarfsbewertung aus Prüffragen ableiten" - prioritaet: "mittel" - ziel_pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/checkliste_bedarfsbewertung.md" - - - id: "OPEN-BEW-004" - beschreibung: "Integration mit DSR-Prozess für Routing-Klärung" - prioritaet: "erledigt" - erledigt_am: "2025-12-17" - ergebnis: | - Routing-Klärungen erfolgten zunächst über ROUTE-DSR (GOV-SOR-001). - Seit 2026-03-04 ersetzt durch ROUTE-SO (Service-Owner-Klärung). - Siehe GOV-SHM-029. - nachtrag: - datum: "2026-03-04" - hinweis: "ROUTE-DSR durch ROUTE-SO ersetzt (GOV-SHM-029)" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-09" - aenderung: "Initiale Erstellung" - autor: "DIGITOM-Projekt" - quelle: "Chat-Session SHM Phase 3" - - - version: "1.1" - datum: "2025-01-29" - aenderung: | - Geltungsbereich explizit gemacht (GOV-SHM-026): - - Klarstellung: Bedarfsbewertung gilt für Stakeholder-initiierte Bedarfe - - Querverweis auf shm_d2p-integration.yaml#abgrenzung_bedarfsquellen - autor: "DIGITOM-Projekt" - quelle: "Chat-Session Konzeptprüfung" - - - version: "1.2" - datum: "2025-01-29" - aenderung: | - Ergänzung Klarstellung für Service Owner im Geltungsbereich: - - Expliziter Hinweis: Service Owner mit eigenem Change-/Redesign-Bedarf - nutzen interne Wege (SOR, DPM), nicht SHM-Bedarfsbewertung - - SHM wird bei Stakeholder-Auswirkungen informiert - autor: "DIGITOM-Projekt" - quelle: "Chat-Session Konzeptprüfung" - - - version: "1.3" - datum: "2025-01-29" - aenderung: | - Fast Track für interne DIGIT-Bedarfe implementiert: - - Geltungsbereich: Drei Bedarfstypen unterschieden (extern, intern-Nutzer, Service-Lifecycle) - - Neuer Abschnitt: schritt_0a_fast_track_intern (10-15 min Prozess) - - Neuer Routing-Pfad: ROUTE-DPM-INTERN mit reduziertem Validierungsprofil - - Neue Status-Werte: in_klaerung_intern, an_dpm_uebergeben_intern - - Beispiele: Personalabteilung DIGIT, Stabsstelle Digital (Miro/Conceptboard) - - Referenz: PATCH_NOTES_interne_bedarfe_v1.1.md - autor: "DIGITOM-Projekt" - quelle: "Chat-Session Konzeptprüfung" - - - version: "2.0" - datum: "2026-03-05" - aenderung: | - Routing-Klärung bei Unsicherheit grundlegend überarbeitet (GOV-SHM-029): - KONZEPTUELLE REFINEMENT: SO gibt Routing-EMPFEHLUNG, nicht finale Entscheidung - - - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) ersetzt - - Neuer bilateraler Klärungsprozess über Service Owner: - Pfad A: SO identifizierbar → direkt kontaktieren → SO gibt Empfehlung - Pfad B: Kein SO identifizierbar → SPM einbinden → SO identifizieren → SO gibt Empfehlung - - - Drei-Schritt-Modell: - 1. SO gibt Routing-Empfehlung ab (RUN/Change oder Demand) - 2. Bedarf wird "als ob" sofort weiterbearbeitet (Parallel-Prozess) - 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM - - - Formelle Entscheidung erfolgt in Gremien: - RUN/Change → SOR (Service Operations Runde, Vorsitz SPM) - Demand → DSR (Demand Screening Runde, Vorsitz DPM) - - - Kleine Changes können vom SO direkt ohne SOR durchgeführt werden - - Gremium-Übersteuerung der SO-Empfehlung ist nur mit formal begründeten Argumenten zulässig - - Eskalation: Mission Board bei nicht begründeter Gremium-Ablehnung oder bei Unstimmigkeiten - - - Status "bereit_fuer_dsr" durch "in_so_klaerung" ersetzt - - Sektion "so_entscheidung" in "so_empfehlung" umbenannt - - Neue Subsektionen: formelle_bestaetigung, erweiterte Eskalations-Stufen - - GOV-SOR-001 wird durch GOV-SHM-029 ersetzt/ergänzt - - Dokumentationspflichten angepasst - autor: "DIGITOM-Projekt" +# ============================================================================= +# SHM BEDARFSBEWERTUNG: METHODIK +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Funktion: Methodik +# Version: 1.3 +# Datum: 2025-01-29 +# Status: Entwurf +# Entwicklungsphase: 3 +# ============================================================================= + +meta: + modul_id: "SHM-M-01" + name: "Bedarfsbewertung" + typ: "Methodik" + + zweck: | + Die Bedarfsbewertung ist die methodische Handlungsanleitung für den + Stakeholder-Manager zur Beantwortung der Kernfrage: + + "Wohin gehört dieser Bedarf?" + + Sie operationalisiert die Routing-Entscheidung (E2) aus dem + Stakeholder-Portfolio und definiert, wie der Stakeholder-Manager + von einem eingehenden Bedarf zu einer qualifizierten Übergabe kommt. + + abgrenzung: + bedarfssteckbrief_schema: | + Das Schema (shm_schema_bedarfssteckbrief.yaml) definiert WAS dokumentiert + wird. Diese Methodik definiert WIE entschieden wird. + + dpm_klassifizierung: | + Die DPM-Klassifizierung (dpm_demand-klassifizierung.yaml) greift NACH + der SHM-Bewertung. SHM entscheidet OB etwas ein Demand ist, DPM + klassifiziert WIE der Demand priorisiert und bearbeitet wird. + + service_desk: | + Der Service Desk (L1) bearbeitet Standard-Requests und -Incidents. + Bedarfe, die nicht über L1 lösbar sind oder komplexere Anforderungen + darstellen, werden an SHM eskaliert. + + referenzen: + - dokument: "shm_schema_bedarfssteckbrief.yaml" + beschreibung: "Datenstruktur für die Bedarfsdokumentation" + - dokument: "shm_stakeholder-portfolio.yaml" + beschreibung: "Kernentscheidung E2 (Bedarfsrouting)" + - dokument: "shm_engagement-framework.yaml" + beschreibung: "Formate für Bedarfserhebung" + - dokument: "dpm_demand-klassifizierung.yaml" + beschreibung: "Nachgelagerte Demand-Klassifizierung im DPM" + - dokument: "shm_interne-bedarfe-routing.yaml" + beschreibung: "Routing und SHM-Rolle bei internen DIGIT-Bedarfen" + pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" + + itil4_referenz: + practice: "Business Analysis" + relevante_elemente: + - "Requirement Gathering" + - "Stakeholder Analysis" + - "Solution Evaluation" + adaption_fuer_digitom: | + Die ITIL4-Business-Analysis-Practice liefert methodischen Input für + die Bedarfserhebung (Schritt 0). Die Routing-Logik ist DIGITOM-spezifisch + und bildet die Schnittstellen zwischen SHM, SPM und DPM ab. + +# ============================================================================= +# FUNKTIONALE HERLEITUNG +# ============================================================================= + +funktionale_herleitung: + + kernfrage: "Wohin gehört dieser Bedarf?" + + geltungsbereich: | + Diese Bedarfsbewertung unterscheidet drei Bedarfstypen mit unterschiedlichen + Prozesswegen: + + **1. Externe Stakeholder-Bedarfe (Regelweg)** + Bedarfe von Ämtern und Dienststellen außerhalb von DIGIT durchlaufen die + vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3). Dies ist der + Hauptanwendungsfall dieser Methodik. + + **2. Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track)** + Bedarfe von DIGIT-Mitarbeitern als Nutzer (z.B. Personalabteilung DIGIT, + Sekretariat, Sachbearbeiter) durchlaufen einen vereinfachten Fast Track + Prozess (10-15 Minuten). Siehe Abschnitt "Fast Track für interne Bedarfe". + + **3. Service-Lifecycle-Bedarfe (Bypass)** + Bedarfe aus dem Service-Lifecycle (Service Owner identifiziert Redesign, + ISB fordert Sicherheitsänderung, strategische Initiative) durchlaufen + die SHM-Triage nicht, sondern treten direkt in den Demand-Lifecycle ein. + SHM wird bei Stakeholder-Auswirkungen informiert. + + Siehe: shm_interne-bedarfe-routing.yaml (Arbeitsmaterial) + Siehe: shm_d2p-integration.yaml#abgrenzung_bedarfsquellen (GOV-SHM-026) + + kontext: | + Wenn ein Bedarf beim Stakeholder-Manager eingeht, muss dieser zwei + Aufgaben erfüllen: + + 1. Den tatsächlichen Bedarf verstehen (nicht die vorgeschlagene Lösung) + 2. Den Bedarf an die richtige Stelle im DIGIT-System routen + + Die Bewertung ist keine technische Analyse – diese erfolgt beim Empfänger. + Die Bewertung ist eine Triage: Schnell, strukturiert, nachvollziehbar. + + routing_pfade: + + - id: "ROUTE-REQ" + name: "Request Fulfilment" + empfaenger: "Service Desk / Service Owner" + trigger: "Bedarf ist durch bestehenden Katalog abbildbar" + status_im_steckbrief: "n/a (kein Bedarfssteckbrief erforderlich)" + beschreibung: | + Standard-Anfragen, die über den Service-Katalog bedient werden können. + Diese verlassen den SHM-Scope direkt und werden als Request behandelt. + + - id: "ROUTE-SPM" + name: "Service Portfolio Management" + empfaenger: "Service Owner (via SPM)" + trigger: "Bedarf betrifft Änderung an bestehendem Service" + status_im_steckbrief: "an_spm_uebergeben" + beschreibung: | + Changes an bestehenden Services, die vom zuständigen Service Owner + bearbeitet werden. Der Bedarfssteckbrief wird an SPM übergeben. + + - id: "ROUTE-DPM" + name: "Demand Portfolio Management" + empfaenger: "DPM (Demand-to-Product-Prozess)" + trigger: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" + status_im_steckbrief: "an_dpm_uebergeben" + beschreibung: | + Neue Bedarfe mit Projektcharakter, die den Demand-to-Product-Prozess + durchlaufen. Der qualifizierte Bedarf wird zum Demand. + + - id: "ROUTE-SO" + name: "Service-Owner-Klärung" + empfaenger: "Service Owner (über Service-Portfolio / SPM)" + trigger: "Routing unklar – Klärung über Service Owner erforderlich" + status_im_steckbrief: "in_so_klaerung" + beschreibung: | + Der SO gibt eine Routing-Empfehlung ab. Die formelle Entscheidung erfolgt + in der SOR (Change); Demand geht direkt an DPM (nicht über DSR). + + Pfad A – SO identifizierbar: SHM prüft das Service-Portfolio und + kontaktiert den identifizierten Service Owner direkt. Der SO + prüft und gibt eine Empfehlung ab, ob der Bedarf als Change im RUN + umsetzbar ist oder ob es sich um einen Demand handelt. + + Pfad B – Kein SO identifizierbar: SHM kontaktiert SPM zur + Unterstützung bei der Service-Identifikation. SPM hilft, den + betroffenen Service und zuständigen SO zu finden. Danach + gibt der SO eine Empfehlung wie in Pfad A ab. + + Nach SO-Empfehlung (als ob-Weiterbearbeitung): + - RUN/Change → Der Bedarf wird bereits bearbeitet; formelle Bestätigung in SOR + - Demand → Der Bedarf wird bereits bearbeitet; direkte Übergabe an DPM (ohne DSR) + + Kleine Changes können vom SO direkt ohne SOR umgesetzt werden. + Eskalation: Mission Board, falls Gremium die SO-Empfehlung überstimmt + und diese Übersteuerung nicht formal begründet ist. + referenz: "GOV-SHM-029" + + - id: "ROUTE-DPM-INTERN" + name: "DPM (Interner Fast Track)" + empfaenger: "DPM (Demand-to-Product-Prozess)" + trigger: "Interner DIGIT-Bedarf erfordert neuen Service" + status_im_steckbrief: "an_dpm_uebergeben_intern" + beschreibung: | + Interne Bedarfe von DIGIT-Mitarbeitern, die einen neuen Service + erfordern, werden mit reduziertem Bedarfssteckbrief an DPM übergeben. + DPM kann bei Bedarf Informationen nachfordern. + validierungsprofil: "ROUTE-DPM-INTERN" + +# ============================================================================= +# PROZESSABLAUF +# ============================================================================= + +prozessablauf: + + beschreibung: | + Der Prozess besteht aus einem vorgelagerten Schritt (Bedarfserhebung) + und drei sequentiellen Prüfungen. Jede Prüfung führt entweder zu einem + Routing-Ergebnis oder zur nächsten Prüfung. + + **Hinweis:** Für interne DIGIT-Mitarbeiter-Bedarfe gilt der vereinfachte + Fast Track Prozess (siehe Abschnitt schritt_0a_fast_track_intern). + + # --------------------------------------------------------------------------- + # SCHRITT 0a: FAST TRACK FÜR INTERNE DIGIT-BEDARFE + # --------------------------------------------------------------------------- + + schritt_0a_fast_track_intern: + name: "Fast Track für interne DIGIT-Bedarfe" + leitfrage: "Ist der Bedarf durch einen bestehenden Service abdeckbar?" + + beschreibung: | + Interne DIGIT-Mitarbeiter (z.B. Personalabteilung, Sekretariat, + Sachbearbeiter in DIGIT) haben Bedarfe als Nutzer von IT-Services. + Diese durchlaufen einen vereinfachten 3-Schritte-Prozess (10-15 Minuten), + um SHM nicht unnötig zu belasten. + + **Abgrenzung:** Dieser Fast Track gilt für DIGIT-Mitarbeiter als *Nutzer*. + Service Owner, die Bedarfe für ihren eigenen Service haben, nutzen die + Service-Lifecycle-Wege (siehe shm_interne-bedarfe-routing.yaml). + + anwendungsbereich: + gilt_fuer: + - "DIGIT-Personalabteilung" + - "DIGIT-Sekretariat" + - "DIGIT-Sachbearbeiter (als Nutzer, nicht als SO)" + - "Andere DIGIT-interne Organisationseinheiten" + gilt_nicht_fuer: + - "Service Owner (für eigenen Service) → Service-Lifecycle" + - "ISB/Compliance → Sicherheits-/Compliance-Prozess" + - "Externe Ämter → Regelweg (Schritt 0, Prüfungen 1-3)" + + eingangskanal: + primaer: "Self-Service-Portal (ITSM-Tool)" + mvp: "E-Mail-Template an SHM" + pflichtfelder: + - "Titel / Kurzbeschreibung" + - "Kontaktperson und Abteilung" + - "Problemstellung (2-3 Sätze)" + - "Zielbild (1-2 Sätze)" + - "Betroffene Systeme (falls bekannt)" + - "Dringlichkeit (S/M/L)" + + prozess: + + schritt_1: + name: "Basistriage" + dauer: "3-5 Minuten" + leitfrage: "Ist es ein valider Bedarf?" + pruefungen: + - "Ist der Bedarf verständlich formuliert?" + - "Liegt er im Scope von DIGIT?" + - "Ist die Kontaktperson erreichbar?" + ergebnisse: + - ergebnis: "valide" + aktion: "Weiter zu Schritt 2" + - ergebnis: "unklar" + aktion: "Rückfrage an Einreichenden" + status: "in_klaerung_intern" + - ergebnis: "out_of_scope" + aktion: "Ablehnung mit Begründung" + + schritt_2: + name: "Routing-Entscheidung" + dauer: "5-7 Minuten" + leitfrage: "Wohin gehört der Bedarf?" + pruefungen: + - frage: "Gibt es einen bestehenden Service, der den Bedarf adressiert?" + ja: "Direkt an Service Owner (kein Steckbrief)" + nein: "Weiter prüfen" + - frage: "Ist ein neuer Service oder grundlegende Änderung erforderlich?" + ja: "ROUTE-DPM-INTERN (mit Minimaldoku)" + nein: "Weiter prüfen" + - frage: "Ist das Routing unklar?" + ja: "ROUTE-SO (Service-Owner-Klärung)" + ergebnisse: + - ergebnis: "bestehender_service" + routing: "Direkt an Service Owner" + steckbrief_erforderlich: false + beschreibung: "SO klärt: Change oder Ablehnung" + - ergebnis: "neuer_service" + routing: "ROUTE-DPM-INTERN" + steckbrief_erforderlich: true + profil: "ROUTE-DPM-INTERN (reduziert)" + - ergebnis: "unklar" + routing: "ROUTE-SO" + steckbrief_erforderlich: true + beschreibung: "Service-Owner-Klärung (bilateral)" + + schritt_3: + name: "Minimaldokumentation" + dauer: "3-5 Minuten" + bedingung: "Nur bei ROUTE-DPM-INTERN" + beschreibung: | + SHM ergänzt eine kurze Einschätzung (2-3 Sätze) und übergibt + an DPM. Der Bedarfssteckbrief ist reduziert (Profil ROUTE-DPM-INTERN). + shm_einschaetzung_template: | + - Quelle: Interner Bedarf aus Abt. [X] + - Thema: [Kurzbeschreibung] + - Service-Katalog: [Kein Service / Teilweise abgedeckt durch ...] + - Größeneinschätzung: [S / M / L] + - Besonderheiten: [Optional] + + validierungsprofil_route_dpm_intern: + beschreibung: | + Reduziertes Validierungsprofil für interne Bedarfe. DPM kann über + die Rückkopplungsschleife Nachforderungen stellen. + erforderlich: + - "Basisdaten (vollständig)" + - "Stakeholder-Kontext (automatisch: 'intern')" + - "Bedarfsbeschreibung (Kernproblem + Zielbild)" + - "Größeneinschätzung (S/M/L)" + - "SHM-Einschätzung (2-3 Sätze)" + - "Service-Katalog-Prüfung" + nicht_erforderlich: + - "User Stories (DPM fordert bei Bedarf nach)" + - "Stakeholder-Freigabe (interner Mitarbeiter)" + - "Detaillierte Abhängigkeiten (DPM fordert bei Bedarf nach)" + - "Rahmenbedingungen (optional)" + + zeitrahmen: + erstreaktion: "Innerhalb von 24-48 Stunden" + gesamtdauer: "10-15 Minuten pro Bedarf" + + beispiele: + + - titel: "Personalabteilung DIGIT möchte neue Personalsoftware" + situation: | + Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue + Software zur Zeiterfassung, da das aktuelle System nicht mehr + den Anforderungen entspricht. + fast_track_ablauf: + schritt_1: "Valide – Bedarf verständlich, im Scope" + schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN" + schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M" + ergebnis: "An DPM mit reduziertem Steckbrief" + + - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" + situation: | + Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang + für kollaborative Workshops. + fast_track_ablauf: + schritt_1: "Valide – Bedarf verständlich" + schritt_2: "Bestehender Service: Conceptboard → Direkt an SO" + schritt_3: "Nicht erforderlich" + ergebnis: | + Direkt an Service Owner Conceptboard. SO klärt: Reicht Conceptboard + aus oder fehlt eine Funktion (dann ggf. Change)? + + - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" + situation: | + Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung + mit externen Besuchern. + fast_track_ablauf: + schritt_1: "Valide – Bedarf verständlich, im Scope" + schritt_2: "Prüfung: Gibt es bereits ein Kalendertool mit Buchungsfunktion?" + schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" + ergebnis: "Abhängig von Service-Katalog-Prüfung" + + governance_referenz: "PATCH_NOTES_interne_bedarfe_v1.1.md" + + # --------------------------------------------------------------------------- + # SCHRITT 0: BEDARFSERHEBUNG (REGELWEG FÜR EXTERNE STAKEHOLDER) + # --------------------------------------------------------------------------- + + schritt_0: + name: "Bedarfserhebung" + leitfrage: "Was ist der tatsächliche Bedarf?" + + beschreibung: | + Bevor geroutet werden kann, muss der Stakeholder-Manager den + tatsächlichen Bedarf verstehen. Stakeholder formulieren oft + Lösungen ("Wir brauchen eine Datenbank") statt Bedarfe + ("Wir müssen Anträge zentral verwalten"). + + Die Kernaufgabe ist der Perspektivwechsel: Vom "Cheeseburger" + zum "Hunger". + + methode: "User-Story-Erhebung" + + user_story_format: + schema: "Als [Rolle] möchte ich [Funktionalität], um [Nutzen]" + beispiel: + rolle: "Sachbearbeiterin im Bauamt" + funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen" + nutzen: "zusammenhängende Anträge schnell identifizieren" + + leitfragen: + - "Was möchten Sie in Ihrer täglichen Arbeit erreichen?" + - "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt." + - "Was würde Ihnen die Arbeit erleichtern?" + - "Wobei verlieren Sie die meiste Zeit?" + + typische_uebersetzungen: + - stakeholder_sagt: "Wir brauchen eine Datenbank" + shm_fragt: "Was möchten Sie damit tun?" + bedarf_wird: "Anträge zentral verwalten" + + - stakeholder_sagt: "Das System ist zu langsam" + shm_fragt: "Wobei genau verlieren Sie Zeit?" + bedarf_wird: "Suchergebnisse in unter 3 Sekunden erhalten" + + - stakeholder_sagt: "Wir wollen alles digitalisieren" + shm_fragt: "Was genau soll digital werden?" + bedarf_wird: "Anträge online einreichen können" + + output: "Qualifizierter Bedarf mit mindestens einer User Story" + + qualitaetskriterien: + - "Rolle spezifisch identifiziert (nicht 'Nutzer')" + - "Funktionalität klar beschrieben (keine Lösungsvorgabe)" + - "Nutzen explizit gemacht" + - "Mit Stakeholder validiert" + + arbeitsmaterial: + dokument: "leitfaden_user-stories.md" + pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" + status: "zu erstellen" + + # --------------------------------------------------------------------------- + # PRÜFUNG 1: SERVICE-KATALOG-CHECK + # --------------------------------------------------------------------------- + + pruefung_1: + name: "Service-Katalog-Check" + leitfrage: "Lässt sich der Bedarf mit dem bestehenden Katalog bedienen?" + + beschreibung: | + Erste Triage: Ist der Bedarf bereits durch existierende Services + abdeckbar? Diese Prüfung erfolgt auf Basis des Service-Katalogs + und der dort definierten Leistungen. + + prueffragen: + - id: "P1-Q1" + frage: "Existiert ein Service im Katalog, der diesen Bedarf adressiert?" + ja_bedeutet: "Potenziell abbildbar" + nein_bedeutet: "Weiter zu P1-Q4" + + - id: "P1-Q2" + frage: "Kann der Bedarf durch eine Standardleistung (Request) erfüllt werden?" + ja_bedeutet: "Abbildbar → ROUTE-REQ" + nein_bedeutet: "Weiter zu P1-Q3" + + - id: "P1-Q3" + frage: "Liegt der Bedarf innerhalb der definierten Service-Parameter?" + ja_bedeutet: "Teilweise abbildbar → Prüfung 2" + nein_bedeutet: "Weiter zu P1-Q4" + + - id: "P1-Q4" + frage: "Ist der Bedarf grundsätzlich neuartig für DIGIT?" + ja_bedeutet: "Nicht abbildbar → Prüfung 3" + nein_bedeutet: "Unklar → SOR-Eskalation erwägen" + + ergebnisse: + - ergebnis: "abbildbar" + routing: "ROUTE-REQ" + aktion: "Weiterleitung an Service Desk / Request Fulfilment" + steckbrief_erforderlich: false + + - ergebnis: "teilweise_abbildbar" + routing: "Prüfung 2" + aktion: "Change-Qualifizierung durchführen" + steckbrief_erforderlich: true + + - ergebnis: "nicht_abbildbar" + routing: "Prüfung 3" + aktion: "Demand-Indikation prüfen" + steckbrief_erforderlich: true + + dokumentation_im_steckbrief: + feld: "servicekatalog_pruefung.pruefergebnis" + begruendung_erforderlich_bei: "nicht_abbildbar" + service_referenz_erforderlich_bei: ["abbildbar", "teilweise_abbildbar"] + + # --------------------------------------------------------------------------- + # PRÜFUNG 2: CHANGE-QUALIFIZIERUNG + # --------------------------------------------------------------------------- + + pruefung_2: + name: "Change-Qualifizierung" + leitfrage: "Ist ein bestehender Service betroffen und veränderbar?" + + vorbedingung: "Prüfung 1 ergab 'teilweise_abbildbar'" + + beschreibung: | + Wenn ein bestehender Service den Bedarf teilweise adressiert, + prüft der Stakeholder-Manager, ob es sich um einen Change an + diesem Service handelt, der vom Service Owner bearbeitet werden kann. + + prueffragen: + - id: "P2-Q1" + frage: "Ist ein konkreter bestehender Service betroffen?" + ja_bedeutet: "Weiter zu P2-Q2" + nein_bedeutet: "Unklar → SOR" + + - id: "P2-Q2" + frage: "Handelt es sich um eine Erweiterung/Anpassung innerhalb des Service-Scopes?" + ja_bedeutet: "Weiter zu P2-Q3" + nein_bedeutet: "Grundlegende Neugestaltung → Prüfung 3" + + - id: "P2-Q3" + frage: "Ist der zuständige Service Owner identifizierbar?" + ja_bedeutet: "Change → ROUTE-SPM" + nein_bedeutet: "Unklar → Service-Owner-Klärung (ROUTE-SO)" + + ergebnisse: + - ergebnis: "change_identifiziert" + routing: "ROUTE-SPM" + aktion: "Übergabe an Service Owner" + status: "an_spm_uebergeben" + + - ergebnis: "kein_change" + routing: "Prüfung 3" + aktion: "Demand-Indikation prüfen" + + - ergebnis: "unklar" + routing: "ROUTE-SO" + aktion: "Service-Owner-Klärung einleiten (bilateral)" + status: "in_so_klaerung" + + hinweis_abgrenzung: | + Die Frage, ob der Change im Rahmen des Service Owners umsetzbar ist + oder Projektcharakter hat, wird NICHT durch SHM bewertet. Diese + Einschätzung trifft der Service Owner nach Übergabe. + + # --------------------------------------------------------------------------- + # PRÜFUNG 3: DEMAND-INDIKATION + # --------------------------------------------------------------------------- + + pruefung_3: + name: "Demand-Indikation" + leitfrage: "Handelt es sich um einen neuen Bedarf mit Projektcharakter?" + + vorbedingung: "Prüfung 1 ergab 'nicht_abbildbar' ODER Prüfung 2 ergab 'kein_change'" + + beschreibung: | + Wenn der Bedarf weder über den Katalog noch als Change abbildbar ist, + prüft der Stakeholder-Manager, ob die Voraussetzungen für eine + Übergabe an DPM erfüllt sind. + + prueffragen: + - id: "P3-Q1" + frage: "Erfordert der Bedarf einen neuen Service oder eine grundlegende Neugestaltung?" + ja_bedeutet: "Demand-Indikator positiv" + nein_bedeutet: "Nochmal Prüfung 1/2 durchgehen oder ROUTE-SO" + + - id: "P3-Q2" + frage: "Hat der Bedarf Projektcharakter (Einmaligkeit, definierter Scope)?" + ja_bedeutet: "Demand-Indikator positiv" + nein_bedeutet: "Möglicherweise wiederkehrender Prozess → ROUTE-SO" + + - id: "P3-Q3" + frage: "Ist der Bedarfssteckbrief hinreichend befüllt für DPM-Übergabe?" + ja_bedeutet: "Bereit für Übergabe → ROUTE-DPM" + nein_bedeutet: "Nachqualifizierung erforderlich" + + demand_indikatoren: + - "Neuer Service erforderlich (nicht im Katalog)" + - "Grundlegende Neugestaltung eines bestehenden Service" + - "Service-übergreifende Anforderung" + - "Erheblicher Ressourcenbedarf (Projektcharakter)" + - "Externe Abhängigkeiten (andere Behörden, Regulatorik)" + + ergebnisse: + - ergebnis: "demand_bestaetigt" + routing: "ROUTE-DPM" + aktion: "Übergabe an DPM mit vollständigem Bedarfssteckbrief" + status: "an_dpm_uebergeben" + + - ergebnis: "nachqualifizierung" + routing: "Zurück zu Schritt 0" + aktion: "Weitere Bedarfserhebung mit Stakeholder" + + - ergebnis: "unklar" + routing: "ROUTE-SO" + aktion: "Service-Owner-Klärung einleiten (bilateral)" + status: "in_so_klaerung" + +# ============================================================================= +# ROUTING-ENTSCHEIDUNGSBAUM (ÜBERSICHT) +# ============================================================================= + +routing_entscheidungsbaum: + + visualisierung: | + + BEDARF GEHT EIN (roh) + │ + ▼ + ┌─────────────────────────────────────┐ + │ SCHRITT 0: Bedarfserhebung │ + │ "Was ist der tatsächliche Bedarf?" │ + │ → User Stories erarbeiten │ + └─────────────────────────────────────┘ + │ + ▼ + QUALIFIZIERTER BEDARF + │ + ▼ + ┌─────────────────────────────────────┐ + │ PRÜFUNG 1: Service-Katalog-Check │ + │ "Lässt sich der Bedarf mit dem │ + │ bestehenden Katalog bedienen?" │ + └─────────────────────────────────────┘ + │ + ├── JA (abbildbar) ──────────────────► REQUEST FULFILMENT + │ (Out of SHM Scope) + │ + ├── TEILWEISE ───────────────────────► PRÜFUNG 2 + │ + └── NEIN (nicht abbildbar) ──────────► PRÜFUNG 3 + + + ┌─────────────────────────────────────┐ + │ PRÜFUNG 2: Change-Qualifizierung │ + │ "Ist ein bestehender Service │ + │ betroffen und veränderbar?" │ + └─────────────────────────────────────┘ + │ + ├── JA + Service Owner klar ─────────► SERVICE OWNER (SPM) + │ Status: an_spm_uebergeben + │ + ├── NEIN (kein Change) ──────────────► PRÜFUNG 3 + │ + └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG + Status: in_so_klaerung + (Pfad A: SO identifizierbar → direkt) + (Pfad B: kein SO → SPM hilft → dann SO) + │ + SO-EMPFEHLUNG (keine Entscheidung) + │ + ├── RUN/Change ────► Parallel-Bearbeitung + │ + formelle SOR-Bestätigung + │ + └── Demand ────────► Parallel-Bearbeitung + + direkte DPM-Übergabe (kein DSR) + + + ┌─────────────────────────────────────┐ + │ PRÜFUNG 3: Demand-Indikation │ + │ "Handelt es sich um einen neuen │ + │ Bedarf mit Projektcharakter?" │ + └─────────────────────────────────────┘ + │ + ├── JA + Steckbrief vollständig ─────► DPM + │ Status: an_dpm_uebergeben + │ + ├── JA + Steckbrief unvollständig ───► NACHQUALIFIZIERUNG + │ (zurück zu Schritt 0) + │ + └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG + Status: in_so_klaerung + +# ============================================================================= +# SERVICE-OWNER-ROUTING-KLÄRUNG (ersetzt DSR-ROUTING-KLÄRUNG seit GOV-SHM-029) +# ============================================================================= + +so_routing_klaerung: + + beschreibung: | + Bei Routing-Unsicherheit erfolgt die Klärung bilateral über den + zuständigen Service Owner. Der Service Owner gibt eine Empfehlung ab, + ob der Bedarf als Change im bestehenden Service (RUN) umsetzbar ist + oder ob es sich um einen neuen Demand handelt. + + Die SO-Empfehlung führt zu einer "als ob"-Weiterbearbeitung: Der Bedarf + wird sofort und parallel bearbeitet, während die formelle Bestätigung + in der nächsten SOR-Sitzung (Change) erfolgt; Demands gehen direkt an DPM. Dies gewährleistet + Geschwindigkeit ohne Verzögerung durch Gremien-Rhythmen. + + Diese bilaterale Klärung ersetzt die bisherige direkte Eskalation + direkt an den DPM und stellt sicher, dass die + Service-Expertise frühzeitig eingebunden wird. + + referenz: "GOV-SHM-029" + + trigger_kriterien: + + beschreibung: | + Service-Owner-Klärung ist angemessen, wenn der Stakeholder-Manager nach + Durchlaufen der Prüfungen unsicher ist. Die Unsicherheit muss nicht + objektiviert werden – das Urteil des Stakeholder-Managers reicht. + + typische_situationen: + - "Service-Zuordnung nicht eindeutig (mehrere Services betroffen)" + - "Unklar, ob Change oder neuer Demand" + - "Bedarf liegt an Schnittstelle SPM/DPM" + - "Stakeholder und SHM sind sich über Routing uneinig" + + ablauf: + + pfad_a: + name: "Service Owner identifizierbar" + beschreibung: | + SHM prüft das Service-Portfolio und identifiziert einen zuständigen + Service Owner. SHM kontaktiert den SO direkt und schildert den + Bedarf. Der SO prüft und entscheidet. + schritte: + - schritt: 1 + akteur: "SHM" + aktion: "Service-Portfolio prüfen, zuständigen SO identifizieren" + - schritt: 2 + akteur: "SHM" + aktion: "SO kontaktieren mit Bedarfsbeschreibung" + - schritt: 3 + akteur: "SO" + aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" + + pfad_b: + name: "Kein Service Owner identifizierbar" + beschreibung: | + SHM kann im Service-Portfolio keinen eindeutigen SO zuordnen. + SHM kontaktiert SPM, um den betroffenen Service und den zuständigen + SO zu identifizieren. Anschließend wird der SO einbezogen. + schritte: + - schritt: 1 + akteur: "SHM" + aktion: "SPM kontaktieren zur Service-Identifikation" + - schritt: 2 + akteur: "SPM" + aktion: "Service identifizieren, zuständigen SO benennen" + - schritt: 3 + akteur: "SHM + SO" + aktion: "SO einbeziehen, Bedarf besprechen" + - schritt: 4 + akteur: "SO" + aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" + fallback: | + Wenn auch SPM keinen passenden Service identifizieren kann, ist dies + ein starker Indikator für einen neuen Demand (ROUTE-DPM), da kein + bestehender Service den Bedarf abdeckt. + + so_empfehlung: + prozessmodell: | + Die SO-Empfehlung folgt einem Drei-Schritt-Modell: + 1. SO gibt Empfehlung ab (RUN/Change oder Demand) + 2. Bedarf wird sofort "als ob" weiterbearbeitet (parallel-Bearbeitung) + 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM + + Dies ermöglicht schnelle Weiterbearbeitung ohne Warten auf Gremium. + + optionen: + - ergebnis: "RUN/Change" + beschreibung: "Bedarf ist als Change im bestehenden Service umsetzbar" + routing: "ROUTE-SPM" + empfaenger: "SOR (Service Operations Runde) für Implementierung" + status: "an_spm_uebergeben" + als_ob_bearbeitung: "Der Change wird sofort im RUN-Prozess bearbeitet; formelle SOR-Bestätigung folgt" + - ergebnis: "Demand" + beschreibung: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" + routing: "ROUTE-DPM" + empfaenger: "DPM nimmt Demand direkt entgegen (kein DSR-Weg)" + status: "an_dpm_uebergeben" + als_ob_bearbeitung: "Der Demand wird sofort im DPM-Prozess bearbeitet; keine DSR-Bestätigung nötig" + - ergebnis: "Kleine Changes (SO-direkt)" + beschreibung: "Bedarf ist als kleine Change direkt umsetzbar (kein SOR nötig)" + routing: "ROUTE-SO-DIREKT" + empfaenger: "SO führt Change selbständig durch" + status: "in_so_umsetzung" + als_ob_bearbeitung: "SO umsetzt die kleine Change direkt; nachträgliche Dokumentation in nächster SOR" + - ergebnis: "Rückgabe" + beschreibung: "SO benötigt weitere Informationen" + routing: "Zurück zu SHM" + empfaenger: "SHM zur Nachqualifizierung" + status: "in_qualifizierung" + + dokumentation: | + Die SO-Routing-Empfehlung wird im Bedarfssteckbrief dokumentiert + (Feld: so_routing_empfehlung) mit Angabe des SO, Datum, + Empfehlung (RUN/Change oder Demand) und Begründung. + + formelle_bestaetigung: | + Die formelle Bestätigung erfolgt in der nächsten zuständigen Gremium-Sitzung: + - RUN/Change: SOR (Service Operations Runde) unter Vorsitz SPM + - Demand: Direkt an DPM (kein DSR-Routing). DSR nur für Portfolio-Governance + + Das Gremium kann: + - Die SO-Empfehlung bestätigen → Weiterbearbeitung wird formalisiert + - Die SO-Empfehlung ablehnen → MUSS mit formal begründeten Argumenten erfolgen + (kein "Bauchgefühl"), z.B. Ressourcen, Strategie, Abhängigkeiten + + Bei Ablehnung durch Gremium: SO oder SHM können zur Mission Board eskalieren + und die Übersteuerung hinterfragen. + + eskalation: + stufe_1: + beschreibung: "SO und SHM können sich nicht einigen" + aktion: "Einbindung der Leitung SHM und SPM" + stufe_2: + beschreibung: "Gremium (SOR) überstimmt SO-Empfehlung" + aktion: | + Übersteuerung MUSS formal begründet werden. Zulässige Begründungen: + - Ressourcen-Constraints (z.B. SOR: Change passt zeitlich nicht) + - Strategische Neugewichtung (z.B. DPM: andere Demands prioritärer) + - Abhängigkeiten (z.B. andere Services betroffen) + - Governance-Gründe (z.B. Eskalation im DPM erforderlich) + + NICHT zulässig: "Bauchgefühl", "war immer so", ohne Argumentation + + fallback: | + Wenn Gremium-Ablehnung nicht begründet ist, oder wenn SO/SHM + die Begründung nicht akzeptieren, können sie zur Mission Board eskalieren + und die Übersteuerung anfechten. + referenz: "GOV-MB-001" + stufe_3: + beschreibung: "Mission Board muss Gremium-Übersteuerung bewerten" + aktion: "Eskalation an Mission Board" + referenz: "GOV-MB-001" + +# ============================================================================= +# STAKEHOLDER-KONTEXT +# ============================================================================= + +stakeholder_kontext: + + beschreibung: | + Der Stakeholder-Kontext aus dem Stakeholder-Portfolio liefert + Hintergrundinformationen für die Bedarfsbewertung. Er beeinflusst + NICHT das Routing, aber die Bearbeitungspriorität. + + relevante_attribute: + + - attribut: "stakeholder_prioritaet" + quelle: "Amts-Steckbrief (automatisch)" + werte: ["Key", "Aktiv", "Standard", "Basis"] + routing_relevant: false + priorisierung_relevant: true + verwendung: | + Die Priorität bestimmt, wie schnell der Bedarf bearbeitet wird + und wie intensiv SHM im weiteren Prozess involviert bleibt + (vgl. Engagement-Framework, Eskalationspfade). + + - attribut: "it_anforderungsprofil" + quelle: "Amts-Steckbrief (automatisch)" + werte: ["Basis", "Erweitert", "Spezial"] + routing_relevant: false + priorisierung_relevant: false + verwendung: | + Das IT-Anforderungsprofil gibt Kontext zur typischen + Bedarfskomplexität des Stakeholders. Ein "Spezial"-Amt hat + erwartbar komplexere Bedarfe als ein "Basis"-Amt. + + ergaenzung_bedarfssteckbrief: + hinweis: | + Diese Attribute sollten im Bedarfssteckbrief-Schema ergänzt werden + (Abschnitt: Stakeholder-Kontext). Sie werden automatisch aus dem + Amts-Steckbrief übernommen. + + schema_ergaenzung: + - feld: "stakeholder_prioritaet" + datentyp: "enum" + quelle: "automatisch aus Amts-Steckbrief" + - feld: "it_anforderungsprofil" + datentyp: "enum" + quelle: "automatisch aus Amts-Steckbrief" + +# ============================================================================= +# PROZESSINTEGRATION +# ============================================================================= + +prozessintegration: + + # --------------------------------------------------------------------------- + # EINGANGSKANÄLE + # --------------------------------------------------------------------------- + + eingangskanäle: + + beschreibung: | + Die Bedarfsbewertung ist kanal-agnostisch. Der Prozess ist identisch, + unabhängig davon, wie der Bedarf eingeht. + + kanäle: + - kanal: "Turnusgespräch" + typ: "proaktiv" + beschreibung: "SHM erhebt Bedarfe aktiv im Rahmen der Regelkommunikation" + + - kanal: "Anfrage per E-Mail/Telefon" + typ: "reaktiv" + beschreibung: "Stakeholder meldet sich direkt beim Stakeholder-Manager" + + - kanal: "Weiterleitung vom Service Desk" + typ: "eskaliert" + beschreibung: "L1 kann Bedarf nicht lösen, eskaliert an SHM" + + - kanal: "Auftraggeber-Forum / Advisory Board" + typ: "proaktiv" + beschreibung: "Bedarfe werden in Cluster-Formaten identifiziert" + + eingangserfassung: | + Unabhängig vom Kanal wird der Bedarf initial im Ticketsystem erfasst + und erhält eine Bedarfs-ID. Der Bedarfssteckbrief wird angelegt. + + # --------------------------------------------------------------------------- + # ZEITRAHMEN + # --------------------------------------------------------------------------- + + zeitrahmen: + + beschreibung: | + Es gibt keine harten SLA-Zeiten für die Bedarfsbewertung. Die + Bearbeitungsgeschwindigkeit orientiert sich an der Stakeholder-Priorität. + + orientierungswerte: + key_stakeholder: "Erstreaktion innerhalb 1 Arbeitstag" + aktiv_stakeholder: "Erstreaktion innerhalb 2 Arbeitstagen" + standard_basis_stakeholder: "Erstreaktion innerhalb 1 Woche" + + hinweis: | + Diese Werte sind Orientierung, keine verbindlichen SLAs. + Verbindliche Zeiten werden ggf. im Performance-Review (Phase 6) + auf Basis empirischer Daten definiert. + + # --------------------------------------------------------------------------- + # DOKUMENTATIONSPFLICHTEN + # --------------------------------------------------------------------------- + + dokumentationspflichten: + + waehrend_bedarfserhebung: + - "User Stories im Bedarfssteckbrief dokumentieren" + - "Gesprächsprotokolle verlinken" + - "Stakeholder-Validierung einholen" + + bei_routing_entscheidung: + - "Prüfergebnis dokumentieren (Katalog-Check)" + - "Begründung bei 'nicht_abbildbar'" + - "Service-Referenz bei 'abbildbar' oder 'teilweise_abbildbar'" + - "SHM-Einschätzung bei DPM-Übergabe" + + bei_so_routing_klaerung: + - "Eigene Einschätzung dokumentieren" + - "Service-Portfolio-Prüfung dokumentieren (SO identifiziert / nicht identifiziert)" + - "SO-Routing-Entscheidung nachträglich eintragen (RUN vs. Demand)" + - "Bei SPM-Einbindung (Pfad B): SPM-Rückmeldung dokumentieren" + +# ============================================================================= +# ABGRENZUNG ZU ANDEREN FUNKTIONEN +# ============================================================================= + +abgrenzung: + + service_desk: + beschreibung: | + Der Service Desk (L1) ist die erste Anlaufstelle für Standard-Anfragen. + Er prüft, ob ein Request/Incident über den Katalog lösbar ist. + + schnittstelle: | + Wenn der Service Desk einen Bedarf nicht lösen kann und dieser + über einen einfachen Request hinausgeht, eskaliert er an SHM. + + abgrenzung: | + Service Desk: "Kann ich das aus dem Katalog bedienen?" + SHM: "Ist das ein Change, ein Demand, oder unklar?" + + service_owner: + beschreibung: | + Der Service Owner ist verantwortlich für einen konkreten Service. + Er bearbeitet Changes an seinem Service. + + schnittstelle: | + SHM übergibt Changes mit dem Bedarfssteckbrief an den Service Owner. + Die technische Bewertung (Machbarkeit, Aufwand) erfolgt beim SO. + + abgrenzung: | + SHM entscheidet: "Geht das zum Service Owner?" + SO gibt Empfehlung ab: "Kann/will ich das umsetzen? (RUN/Change oder Demand?)" + Formelle Entscheidung: SOR (RUN/Change); Demand direkt an DPM + + dpm: + beschreibung: | + Das Demand Portfolio Management bearbeitet qualifizierte Demands + im Demand-to-Product-Prozess. + + schnittstelle: | + SHM übergibt Demands mit vollständigem Bedarfssteckbrief. + DPM klassifiziert und priorisiert den Demand intern. + + abgrenzung: | + SHM entscheidet: "Ist das ein Demand?" + DPM entscheidet: "Wie wird der Demand priorisiert und bearbeitet?" + + spm: + beschreibung: | + Das Service Portfolio Management steuert das Service-Portfolio. + Es ist nicht operativ in die Bedarfsbewertung involviert. + + schnittstelle: | + SPM stellt den Service-Katalog bereit, gegen den SHM prüft. + Bei SOR-Eskalationen ist SPM im Gremium vertreten. + + abgrenzung: | + SPM: "Welche Services gibt es?" + SHM: "Passt dieser Bedarf zu einem Service?" + +# ============================================================================= +# GOVERNANCE-ENTSCHEIDUNGEN +# ============================================================================= + +governance_entscheidungen: + + beschreibung: | + Die folgenden Governance-Entscheidungen wurden während der Entwicklung + dieser Methodik getroffen und werden ins Governance-Entscheidungs-Log + übertragen. + + entscheidungen: + + - id: GOV-SHM-016 + datum: 2025-12-09 + frage: "Beeinflusst die Stakeholder-Priorität das Routing?" + entscheidung: | + Nein. Das Routing basiert ausschließlich auf der Sachfrage + "Was ist der Bedarf?". Die Stakeholder-Priorität beeinflusst + die Bearbeitungsgeschwindigkeit, nicht das Ziel. + begruendung: | + Routing muss sachlogisch nachvollziehbar sein. Ein Demand bleibt + ein Demand, unabhängig davon, wer ihn einreicht. + status: final + + - id: GOV-SHM-017 + datum: 2025-12-09 + frage: "Welche Kriterien triggern eine Routing-Klärung?" + entscheidung: | + Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. + Es gibt keine quantitativen Schwellenwerte. + begruendung: | + Objektivierte Kriterien würden zu Schein-Objektivität führen. + Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu + erkennen und angemessen zu eskalieren. + status: final + nachtrag: + datum: "2025-12-17" + hinweis: | + Demand-Routing erfolgt direkt an DPM (GOV-SHM-029). + Seit GOV-SHM-029 (2026-03-04) erfolgt die Routing-Klärung + bilateral über den Service Owner (ROUTE-SO). + nachtrag_2: + datum: "2026-03-04" + hinweis: | + Routing-Klärung erfolgt jetzt bilateral über den Service Owner + (nicht mehr über DSR). Siehe GOV-SHM-029. + + - id: GOV-SHM-029 + datum: 2026-03-04 + frage: "Wie wird bei Routing-Unsicherheit (Change vs. Demand) vorgegangen?" + entscheidung: | + Bei Routing-Unsicherheit prüft SHM zunächst das Service-Portfolio + auf einen zuständigen Service Owner (SO). + + Pfad A: Wenn ein SO identifizierbar ist, wird dieser direkt + kontaktiert. Der SO entscheidet, ob der Bedarf als Change im + RUN umsetzbar ist oder als Demand weitergeleitet wird. + + Pfad B: Wenn kein SO identifizierbar ist, wird SPM eingebunden, + um den betroffenen Service und den zuständigen SO zu finden. + Anschließend entscheidet der SO wie in Pfad A. + + Nach SO-Entscheidung: + - RUN/Change: SOR ist zuständig für die Implementierung. + - Demand: DPM nimmt direkt entgegen (kein DSR-Umweg). + + Eskalation: Mission Board, falls DPM den Demand nicht akzeptiert. + begruendung: | + Die bisherige direkte Eskalation an die DSR (ROUTE-DSR) wurde + als zu formalisiert bewertet. Der Service Owner hat die fachliche + Expertise, um die Routing-Entscheidung zu treffen. Die bilaterale + Klärung ist schneller und nutzt die vorhandene Service-Kompetenz. + SPM dient als Brücke zum SO, wenn die Zuordnung nicht direkt + möglich ist. + ersetzt: "ROUTE-DSR (DSR als Routing-Klärungsgremium)" + status: final + quelle: "Workshop Bedarfsrouting-Klärung, 2026-03-04" + + - id: GOV-SHM-018 + datum: 2025-12-09 + frage: "Prüft SHM die Service-Kategorie (A/B/C) bei der Bewertung?" + entscheidung: | + Nein. Die Service-Kategorie ist informativ (aus Amts-Steckbrief), + aber nicht entscheidungsrelevant für das Routing. + begruendung: | + Die konkrete Service-Kategorie-Zuordnung ist Aufgabe von SPM/SO. + SHM prüft nur: "Ist der Bedarf katalog-abbildbar?" + status: final + + - id: GOV-SHM-019 + datum: 2025-12-09 + frage: "Ist eine Aufwandsschätzung routing-relevant?" + entscheidung: | + Nein. Die Aufwandsschätzung im Bedarfssteckbrief ist informativ + für den Empfänger, aber nicht entscheidungsrelevant für das Routing. + begruendung: | + Die Frage "Was ist es?" ist unabhängig von "Wie groß ist es?". + Ein kleiner Demand bleibt ein Demand. + status: final + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-BEW-003" + beschreibung: "Checkliste Bedarfsbewertung aus Prüffragen ableiten" + prioritaet: "mittel" + ziel_pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/checkliste_bedarfsbewertung.md" + + - id: "OPEN-BEW-004" + beschreibung: "Integration mit DSR-Prozess für Routing-Klärung" + prioritaet: "erledigt" + erledigt_am: "2025-12-17" + ergebnis: | + Routing-Klärungen erfolgten zunächst über ROUTE-DSR (GOV-SOR-001). + Seit 2026-03-04 ersetzt durch ROUTE-SO (Service-Owner-Klärung). + Siehe GOV-SHM-029. + nachtrag: + datum: "2026-03-04" + hinweis: "ROUTE-DSR durch ROUTE-SO ersetzt (GOV-SHM-029)" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-09" + aenderung: "Initiale Erstellung" + autor: "DIGITOM-Projekt" + quelle: "Chat-Session SHM Phase 3" + + - version: "1.1" + datum: "2025-01-29" + aenderung: | + Geltungsbereich explizit gemacht (GOV-SHM-026): + - Klarstellung: Bedarfsbewertung gilt für Stakeholder-initiierte Bedarfe + - Querverweis auf shm_d2p-integration.yaml#abgrenzung_bedarfsquellen + autor: "DIGITOM-Projekt" + quelle: "Chat-Session Konzeptprüfung" + + - version: "1.2" + datum: "2025-01-29" + aenderung: | + Ergänzung Klarstellung für Service Owner im Geltungsbereich: + - Expliziter Hinweis: Service Owner mit eigenem Change-/Redesign-Bedarf + nutzen interne Wege (SOR, DPM), nicht SHM-Bedarfsbewertung + - SHM wird bei Stakeholder-Auswirkungen informiert + autor: "DIGITOM-Projekt" + quelle: "Chat-Session Konzeptprüfung" + + - version: "1.3" + datum: "2025-01-29" + aenderung: | + Fast Track für interne DIGIT-Bedarfe implementiert: + - Geltungsbereich: Drei Bedarfstypen unterschieden (extern, intern-Nutzer, Service-Lifecycle) + - Neuer Abschnitt: schritt_0a_fast_track_intern (10-15 min Prozess) + - Neuer Routing-Pfad: ROUTE-DPM-INTERN mit reduziertem Validierungsprofil + - Neue Status-Werte: in_klaerung_intern, an_dpm_uebergeben_intern + - Beispiele: Personalabteilung DIGIT, Stabsstelle Digital (Miro/Conceptboard) + - Referenz: PATCH_NOTES_interne_bedarfe_v1.1.md + autor: "DIGITOM-Projekt" + quelle: "Chat-Session Konzeptprüfung" + + - version: "2.0" + datum: "2026-03-05" + aenderung: | + Routing-Klärung bei Unsicherheit grundlegend überarbeitet (GOV-SHM-029): + KONZEPTUELLE REFINEMENT: SO gibt Routing-EMPFEHLUNG, nicht finale Entscheidung + + - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) ersetzt + - Neuer bilateraler Klärungsprozess über Service Owner: + Pfad A: SO identifizierbar → direkt kontaktieren → SO gibt Empfehlung + Pfad B: Kein SO identifizierbar → SPM einbinden → SO identifizieren → SO gibt Empfehlung + + - Drei-Schritt-Modell: + 1. SO gibt Routing-Empfehlung ab (RUN/Change oder Demand) + 2. Bedarf wird "als ob" sofort weiterbearbeitet (Parallel-Prozess) + 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM + + - Formelle Entscheidung erfolgt in Gremien: + RUN/Change → SOR (Service Operations Runde, Vorsitz SPM) + Demand → DSR (Demand Screening Runde, Vorsitz DPM) + + - Kleine Changes können vom SO direkt ohne SOR durchgeführt werden + - Gremium-Übersteuerung der SO-Empfehlung ist nur mit formal begründeten Argumenten zulässig + - Eskalation: Mission Board bei nicht begründeter Gremium-Ablehnung oder bei Unstimmigkeiten + + - Status "bereit_fuer_dsr" durch "in_so_klaerung" ersetzt + - Sektion "so_entscheidung" in "so_empfehlung" umbenannt + - Neue Subsektionen: formelle_bestaetigung, erweiterte Eskalations-Stufen + - GOV-SOR-001 wird durch GOV-SHM-029 ersetzt/ergänzt + - Dokumentationspflichten angepasst + autor: "DIGITOM-Projekt" quelle: "Workshop Bedarfsrouting-Klärung, 2026-03-05" \ No newline at end of file diff --git a/#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml b/#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml index 2220a9d..3dafbc7 100644 --- a/#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml +++ b/#03_stakeholder-management/#03.4_methodik/shm_koordinations-und-steuerungsstruktur.yaml @@ -1,854 +1,854 @@ -# ============================================================================= -# SHM KOORDINATIONS- UND STEUERUNGSSTRUKTUR -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Typ: Methodik -# Version: 1.0 -# Datum: 2025-12-10 -# Status: Final (Phase 5) -# ============================================================================= - -meta: - modul_id: "SHM-M-02" - name: "Koordinations- und Steuerungsstruktur" - typ: "Methodik" - - vorheriger_name: "Performance & Review" - - begruendung_umbenennung: | - Der ursprüngliche Name "Performance & Review" war zu stark durch eine - betriebswirtschaftliche Steuerungslogik geprägt (Effizienz, Kontrolle, - quantifizierte KPIs). Für SHM im Verwaltungskontext ist das nicht passend. - - Der neue Name "Koordinations- und Steuerungsstruktur" betont: - - Koordination als zentralen Modus (nicht Kontrolle) - - Steuerung als legitimer Verwaltungsbegriff - - Struktur statt Framework (weniger technisch) - - Die Integration von REV-3 (Operative Koordination) wird dadurch - konzeptionell stimmig. - - zweck: | - Die Koordinations- und Steuerungsstruktur definiert, wie SHM seine - Arbeit reflektiert, koordiniert und kontinuierlich verbessert. Sie - verbindet operative Abstimmung mit taktischer Steuerung und - strategischer Rechenschaft. - - itil4_referenz: - practice: "Continual Improvement" - ergaenzende_konzepte: - - konzept: "Voice of Customer" - quelle: "ITIL 4 Drive Stakeholder Value (DSV)" - - konzept: "Measurement and Reporting" - quelle: "ITIL 4 Direct Plan Improve (DPI)" - - governance_referenzen: - - id: "GOV-SHM-023" - thema: "Fokus auf Ergebnis-Indikatoren" - dokument: "readme_shm_governance-entscheidungs-log.yaml" - - id: "GOV-SHM-024" - thema: "Abgrenzung SHM/SPM im Reporting" - dokument: "readme_shm_governance-entscheidungs-log.yaml" - - konzept_referenzen: - - dokument: "shm_voice-of-customer.yaml" - beschreibung: "VoC als zentraler Steuerungsindikator" - - dokument: "shm_engagement-framework.yaml" - beschreibung: "Interaktionsformate, die VoC-Quellen liefern" - - dokument: "shm_stakeholder-portfolio.yaml" - beschreibung: "Beziehungsqualität als Steuerungsindikator" - -# ============================================================================= -# GRUNDPRINZIPIEN -# ============================================================================= - -grundprinzipien: - - beschreibung: | - Die folgenden Prinzipien leiten die Gestaltung der Koordinations- und - Steuerungsstruktur. Sie reflektieren den Charakter von SHM als - beziehungsorientierte Funktion im Verwaltungskontext. - - prinzipien: - - - id: "PRIN-01" - name: "Qualität vor Effizienz" - beschreibung: | - Die zentrale Frage ist nicht "Wie viel?" oder "Wie schnell?", - sondern "Wie gut?". Die Qualität der Stakeholder-Beziehungen - und die Wirksamkeit der Betreuung stehen im Vordergrund. - implikation: | - Review-Fragen fokussieren auf Beziehungsqualität und - Stakeholder-Wahrnehmung, nicht auf Durchsatzzahlen. - - - id: "PRIN-02" - name: "Koordination vor Kontrolle" - beschreibung: | - SHM arbeitet mit Abstimmung, Austausch und gemeinsamer - Problemlösung – nicht mit hierarchischer Überwachung. - Die Steuerungsstruktur ermöglicht Koordination, nicht Kontrolle. - implikation: | - REV-3 (Team-Sync) ist ein Koordinationsformat, kein - Kontroll-Meeting. Keine Rechenschaftspflicht nach oben. - - - id: "PRIN-03" - name: "Lernen vor Messen" - beschreibung: | - Ziel ist Erkenntnisgewinn und kontinuierliche Verbesserung, - nicht das Erfüllen von Kennzahlen. Metriken dienen dem Lernen, - nicht der Rechtfertigung. - implikation: | - Keine KPI-Dashboards mit Zielerreichungsquoten. Stattdessen - qualitative Reflexion und Musteranalyse. - - - id: "PRIN-04" - name: "Qualitative Einschätzungen vor quantifizierten Kennzahlen" - beschreibung: | - Beziehungen sind mehrdimensional, kontextabhängig und dynamisch. - Ihre Qualität lässt sich nicht sinnvoll auf eine Zahl reduzieren. - Quantifizierung suggeriert eine Präzision, die bei Beziehungsarbeit - nicht existiert – und erzeugt perverse Anreize: Was gemessen wird, - wird optimiert, nicht notwendigerweise verbessert. - implikation: | - Berichte enthalten narrative Einschätzungen mit Kontext und - Ursachenbezug. Zahlen werden nur dort verwendet, wo sie echten - Informationsgewinn bieten (z.B. Verteilungen im Portfolio), - nicht als Selbstzweck. - beispiel: - statt: "78% der Turnus-Gespräche durchgeführt" - besser: | - Turnus-Gespräche finden regelmäßig statt. Bei zwei Key-Stakeholdern - kam es zu Verschiebungen wegen Personalwechsel auf Fachbereichsseite. - abgrenzung: | - Dies ist kein Plädoyer gegen jede Form von Strukturierung. Die - Ampel-Matrix (VoC-Cluster) ist eine qualitative Verdichtung mit - visuellem Ordnungsschema – keine Quantifizierung. - - - id: "PRIN-05" - name: "Stakeholder-Stimme als Kompass" - beschreibung: | - Die Wahrnehmung und das Feedback der Stakeholder sind der - zentrale Gradmesser für den Erfolg von SHM. Das Voice-of-Customer- - Konzept wird strukturell verankert. - implikation: | - VoC-Erkenntnisse sind Kernelement aller Review-Formate. - Keine Bewertung ohne Stakeholder-Perspektive. - referenz: "shm_voice-of-customer.yaml" - -# ============================================================================= -# STEUERUNGSINDIKATOREN -# ============================================================================= - -steuerungsindikatoren: - - beschreibung: | - Basierend auf GOV-SHM-023 fokussiert die SHM-Steuerung auf - Ergebnis-Indikatoren (Wirkung), nicht auf Prozess-Indikatoren - (Aktivitäten). - - primaere_indikatoren: - - beschreibung: | - Diese Indikatoren werden in den Reviews (REV-1, REV-2) systematisch - betrachtet und berichtet. - - indikatoren: - - - id: "IND-P-01" - name: "Beziehungsqualität" - quelle: "shm_stakeholder-portfolio.yaml" - beschreibung: | - Verteilung der Beziehungsqualitäts-Stufen (Exzellent, Gut, - Angespannt, Kritisch) im Portfolio. - betrachtung: "Verteilung und Veränderung" - - - id: "IND-P-02" - name: "VoC-Cluster-Ampeln" - quelle: "shm_voice-of-customer.yaml" - beschreibung: | - Kritikalitätsbewertung der thematischen Cluster (D1-D4) - in der Ampel-Matrix. - betrachtung: "Status und Trend" - - - id: "IND-P-03" - name: "VoC-Highlights" - quelle: "shm_voice-of-customer.yaml" - beschreibung: | - Qualitative Erkenntnisse aus dem Stakeholder-Feedback - (positiv, kritisch, insight, trend). - betrachtung: "Narrative Auswertung" - - sekundaere_indikatoren: - - beschreibung: | - Diese Indikatoren werden nicht im Review berichtet, können aber - bei operativen Problemen intern herangezogen werden. - - indikatoren: - - - id: "IND-S-01" - name: "Turnus-Gespräche Durchführungsquote" - verwendung: "Nur bei Verdacht auf systematische Lücken" - - - id: "IND-S-02" - name: "Routing-Statistik" - verwendung: "Nur bei Analyse von Bedarfsmustern" - - - id: "IND-S-03" - name: "Durchlaufzeiten Bedarfssteckbrief" - verwendung: "Nur bei Engpass-Analyse" - -# ============================================================================= -# ENTSCHEIDUNGSTYPEN -# ============================================================================= - -entscheidungstypen: - - beschreibung: | - Die Koordinations- und Steuerungsstruktur unterstützt drei - Entscheidungstypen auf unterschiedlichen Ebenen. Diese bilden - das funktionale Fundament der Struktur. - - Hinweis: Die ursprünglich separaten Typen (Portfolio-Qualität - und Funktions-Weiterentwicklung) wurden zu einem konsolidierten - REV-2-Format zusammengeführt (analog DPM-Portfolio-Review). - - uebersicht: - - - id: "REV-1" - name: "Auftragserfüllung" - ebene: "Strategisch" - frequenz: "Jährlich + Halbjahres-Pulse" - adressat: "Vision Board" - - - id: "REV-2" - name: "Portfolio-Qualität, Lernen & Verbesserung" - ebene: "Taktisch" - frequenz: "Quartalsweise" - adressat: "SHM-Leitung, SHM-Team" - - - id: "REV-3" - name: "Operative Koordination" - ebene: "Operativ" - frequenz: "2-wöchentlich bis monatlich" - adressat: "SHM-Leitung, SHM-Team" - - typen: - - # ------------------------------------------------------------------------- - # REV-1: AUFTRAGSERFÜLLUNG - # ------------------------------------------------------------------------- - - - id: "REV-1" - name: "Auftragserfüllung" - - kernfrage: "Leistet SHM, wofür es da ist?" - - beschreibung: | - Strategische Bewertung, ob die Funktion SHM ihren Zweck im - DIGITOM-Gesamtkontext erfüllt. Die Stakeholder-Stimme (Voice - of Customer) ist hier ein zentraler Input. - - adressat: "DIGIT-Leitung, Vision Board" - - charakter: "Strategisch-legitimatorisch" - - frequenz: "Jährlich" - - zusaetzlich: - name: "Pulse-Update" - frequenz: "Halbjährlich (Q2)" - umfang: "Kurzform (max. 2 Seiten)" - zweck: "Standortbestimmung zwischen Jahresberichten" - - betrachtungsweise: | - Qualitative Gesamteinschätzung mit narrativer Begründung. - Keine Scorecard, sondern strukturierter Bericht mit - Einordnung und Handlungsempfehlungen. - - typische_fragestellungen: - - "Werden die Stakeholder-Beziehungen professionell gepflegt?" - - "Funktioniert die Bedarfserkennung und -weiterleitung?" - - "Wie nehmen die Ämter DIGIT als Partner wahr?" - - "Trägt SHM zur strategischen Ausrichtung von DIGIT bei?" - - voc_relevanz: | - REV-1 integriert die aggregierte Stakeholder-Stimme als - zentralen Erfolgsindikator. Die Frage "Erfüllen wir unseren - Auftrag?" wird wesentlich durch "Was sagen die Stakeholder?" - beantwortet. - - voc_output: "Verdichtung REV-1 (Jahres-Review)" - - # ------------------------------------------------------------------------- - # REV-2: PORTFOLIO-QUALITÄT, LERNEN & VERBESSERUNG - # ------------------------------------------------------------------------- - - - id: "REV-2" - name: "Portfolio-Qualität, Lernen & Verbesserung" - - kernfrage: | - Wie steht es um unsere Stakeholder-Beziehungen, was lernen wir - daraus, und was müssen wir verbessern? - - beschreibung: | - Kombiniertes Format für Portfolio-Analyse und kontinuierliche - Verbesserung. Quartalsweise Betrachtung des Stakeholder-Portfolios - mit integrierter CI-Komponente. In Q2 und Q4 erweitertes Format - mit Retrospektive und Verbesserungsplanung. - - Diese Konsolidierung folgt dem bewährten Ansatz des DPM-Portfolio- - Reviews, das Portfolio-Analyse und Prozessverbesserung ebenfalls - in einem Format verbindet. - - adressat: "SHM-Leitung, SHM-Team" - - charakter: "Taktisch-reflexiv" - - frequenz: "Quartalsweise" - - varianten: - - - variante: "Standard (Q1, Q3)" - dauer: "60-90 Minuten" - fokus: "Portfolio-Analyse, VoC-Status, Maßnahmen-Tracking" - ci_anteil: "Kurz (15 Min): Status offener Maßnahmen, neue Themen sammeln" - - - variante: "Erweitert (Q2, Q4)" - dauer: "2-3 Stunden" - fokus: "Portfolio-Analyse + Retrospektive + Verbesserungsplanung" - ci_anteil: "Deep-Dive: Was lief gut/schlecht? Strukturelle Verbesserungen" - zusatz_q4: "Vorbereitung REV-1-Jahresbericht" - - inhaltliche_dimensionen: - - portfolio_analyse: - - dimension: "Beziehungsqualitäts-Verteilung" - beschreibung: "Verteilung EX/GU/AN/KR im Portfolio" - - dimension: "VoC-Cluster-Status" - beschreibung: "Ampel-Matrix D1-D4" - - dimension: "Veränderungen" - beschreibung: "Entwicklung gegenüber Vorquartal" - - dimension: "Highlights" - beschreibung: "Relevante Einzelerkenntnisse" - - dimension: "Interventionen" - beschreibung: "Laufende und neue Interventionsfälle" - - ci_komponente: - - dimension: "Maßnahmen-Status" - beschreibung: "Review offener Verbesserungsmaßnahmen" - - dimension: "Wirksamkeit" - beschreibung: "Wurden umgesetzte Maßnahmen wirksam?" - - dimension: "Neue Themen" - beschreibung: "Erkannte Verbesserungspotenziale" - - dimension: "Retrospektive (nur Q2/Q4)" - beschreibung: "Was lief gut? Was war schwierig?" - - dimension: "Schnittstellen-Feedback (nur Q2/Q4)" - beschreibung: "Rückmeldungen von DPM, SPM, Service Desk" - - output: - - "SHM-Quartalsbericht (inkl. Maßnahmen-Status)" - - "Bei Q2/Q4: Aktualisierter Verbesserungsplan" - - "Input für DPM-Portfolio-Review" - - "Bei Q4: Vorarbeit für REV-1-Jahresbericht" - - voc_relevanz: | - VoC informiert sowohl die Portfolio-Betrachtung als auch die - Verbesserungsplanung: - - Portfolio: Welche Beziehungen sind belastet? Welche Muster? - - CI: Systematische Muster, die auf Prozessprobleme hindeuten - - voc_output: "Verdichtung REV-2 (Quartals-Review)" - - konsolidierungshinweis: | - Dieses Format ersetzt die ursprünglich separaten Entscheidungstypen - (vormals E2 für Portfolio-Qualität & Lernen und E4 für Funktions-Weiterentwicklung). - Die Zusammenlegung reduziert Overhead und ist konsistent mit dem - DPM-Portfolio-Review-Ansatz. - - # ------------------------------------------------------------------------- - # REV-3: OPERATIVE KOORDINATION - # ------------------------------------------------------------------------- - - - id: "REV-3" - name: "Operative Koordination" - - kernfrage: "Welche laufenden Themen müssen wir im Team abstimmen?" - - beschreibung: | - Regelmäßiger Austausch im SHM-Team zu laufenden Stakeholder- - Themen. Fokus auf kollegiale Beratung, Wissenstransfer und - gemeinsame Problemlösung. - - adressat: "SHM-Team (Stakeholder-Manager untereinander)" - - charakter: "Operativ-koordinierend" - - frequenz: "2-wöchentlich oder monatlich" - - betrachtungsweise: | - Fall-basiert und anlassbezogen. Kein formaler Review, - sondern Arbeits-Meeting mit Koordinationsfunktion. - - typische_inhalte: - - "Aktuelle Interventionsfälle (Angespannt/Kritisch)" - - "Komplexe Bedarfssituationen" - - "Übergaben bei Zuständigkeitswechsel" - - "Erkenntnisse aus Gesprächen, die für andere relevant sind" - - "Status-Updates zu laufenden Demands/Projekten bei Key-Stakeholdern" - - abgrenzung: | - REV-3 ist kein Review im klassischen Sinne, sondern ein - Koordinationsmechanismus. Die Integration in die Steuerungs- - struktur stellt sicher, dass operative Erkenntnisse in die - taktische (REV-2) und strategische (REV-1) Ebene einfließen. - - format: - name: "SHM Team-Sync" - dauer: "45-60 Minuten" - moderation: "Rotierend oder SHM-Leitung" - dokumentation: "Kurzprotokoll mit Entscheidungen und Follow-ups" - - voc_relevanz: | - Aktuelle Highlights (insbesondere Kritik-Highlights) fließen - in die Team-Koordination ein. Interventionsfälle werden auf - Basis von VoC-Signalen identifiziert. - - voc_output: "Highlights (laufend)" - -# ============================================================================= -# EINBETTUNG IN DIGIT-ZYKLEN -# ============================================================================= - -einbettung_digit_zyklen: - - beschreibung: | - Die SHM-Reviews sind nicht isoliert, sondern in die übergreifenden - DIGIT-Governance-Zyklen eingebettet. - - ebenen: - - strategische_ebene: - gremium: "Vision Board" - rhythmus: "Quartalsweise" - funktion: "Definiert Strategie und jährliche strategische Fokusthemen" - shm_einbettung: | - REV-1 (Auftragserfüllung) wird im Vision Board verankert: - - Jährlich: Vollständiger SHM-Jahresbericht als Input für Strategieplanung - - Halbjährlich: Pulse-Update (Kurzform) zur Standortbestimmung - - taktische_ebene: - gremium: "SHM-Leitung / SOR bei Bedarf" - rhythmus: "Quartalsweise (REV-2)" - shm_einbettung: | - REV-2 (Portfolio-Qualität, Lernen & Verbesserung) liegt auf der - taktischen Ebene und wird durch SHM-Leitung verantwortet. - - operative_ebene: - gremium: "SHM-Team" - rhythmus: "2-wöchentlich bis monatlich (REV-3)" - shm_einbettung: | - REV-3 (Operative Koordination) ist ein internes Team-Format. - -# ============================================================================= -# EINBETTUNG IN ÜBERGREIFENDE DIGIT-REVIEWS -# ============================================================================= - -einbettung_digit_reviews: - - beschreibung: | - SHM ist Teilnehmer an übergreifenden DIGIT-Review-Formaten und - liefert dort Input aus seiner Perspektive. - - dpm_portfolio_review: - - name: "Demand-Portfolio Review" - charakter: "DIGIT-übergreifendes Quartals-Review" - frequenz: "Quartalsweise" - zeitpunkt: "Erste Monatshälfte nach Quartalsende (ca. T+10 bis T+14)" - teilnehmer: "AL Planung (Leitung), DPM, PPM, SPM, SHM" - - shm_rolle: | - SHM ist Teilnehmer und Input-Lieferant. Der SHM-Beitrag umfasst: - - Stakeholder-Trends (VoC-Cluster-Entwicklung) - - Bedarfsmuster (Erkenntnisse aus D3, Routing-Erfahrungen) - - Kommunikations-Feedback (Highlights, Beziehungsqualität) - - shm_input_quelle: "REV-2 (SHM Quartals-Review)" - - sequenzierung: | - REV-2 muss vor dem DPM-Portfolio-Review stattfinden, damit SHM - vorbereitet ist und konsolidierten Input liefern kann. - - Empfohlene Sequenz: - - REV-2: Erste Woche nach Quartalsende - - DPM-Portfolio-Review: Zweite Woche nach Quartalsende - - referenz_dokument: "Konzept_DPM – Demand-Portfolio Review Framework" - -# ============================================================================= -# KASKADIERUNGSLOGIK -# ============================================================================= - -kaskadierungslogik: - - beschreibung: | - Informationen und Erkenntnisse fließen zwischen den Ebenen in - beide Richtungen. - - aufwaertsfluss: - - - von: "REV-3 (Team-Sync)" - nach: "REV-2 (Quartals-Review)" - inhalt: - - "Interventionsfälle, die eskaliert oder dokumentiert werden müssen" - - "Erkenntnisse aus Einzelgesprächen" - - "Muster, die im Tagesgeschäft auffallen" - - - von: "REV-2 (Quartals-Review)" - nach: "REV-1 (Jahres-Review)" - inhalt: - - "Quartals-Status und Trends" - - "Konsolidierte VoC-Erkenntnisse" - - "Handlungsbedarfe mit strategischer Relevanz" - - - von: "REV-2 (Quartals-Review)" - nach: "REV-2 erweitert (Q2/Q4)" - inhalt: - - "Muster, die auf strukturelle Probleme hindeuten" - - "Wiederkehrende Themen aus mehreren Quartalen" - - abwaertsfluss: - - - von: "REV-1 / Vision Board" - nach: "REV-2 / REV-3" - inhalt: - - "Strategische Prioritäten" - - "Fokusthemen für die Stakeholder-Betreuung" - - "Ressourcenentscheidungen" - - - von: "REV-2 erweitert (Q2/Q4)" - nach: "REV-3 (Team-Sync)" - inhalt: - - "Angepasste Prozesse oder Vorgehensweisen" - - "Maßnahmen aus Verbesserungsplanung" - - "Veränderte Prioritäten" - -# ============================================================================= -# REVIEW-FORMATE IM DETAIL -# ============================================================================= - -review_formate: - - # --------------------------------------------------------------------------- - # REV-1: JAHRES-REVIEW - # --------------------------------------------------------------------------- - - rev1_jahres_review: - - name: "SHM Jahres-Review" - entscheidungstyp_referenz: "REV-1" - zweck: "Strategische Bewertung der SHM-Funktion" - frequenz: "Jährlich" - zeitpunkt: "Q4 (vor Vision-Board-Strategieplanung)" - - zusaetzlich_pulse_update: - frequenz: "Halbjährlich" - zeitpunkt: "Q2" - umfang: "Kurzform (max. 2 Seiten)" - - verantwortlichkeiten: - erstellt: "SHM-Leitung" - empfaengt: "Vision Board" - - artefakt: - name: "SHM-Jahresbericht" - umfang: "Ca. 5-10 Seiten" - gliederung: - - abschnitt: "1. Management Summary" - inhalt: "Kernaussagen, Gesamtbewertung" - - abschnitt: "2. Stakeholder-Portfolio im Überblick" - inhalt: "Bestandsübersicht, Beziehungsqualitäts-Verteilung" - - abschnitt: "3. Voice of Customer – Gesamtbild" - inhalt: "VoC-Cluster-Jahresübersicht, zentrale Erkenntnisse" - - abschnitt: "4. Highlights des Jahres" - inhalt: "Erfolge, Herausforderungen, besondere Fälle" - - abschnitt: "5. Strategische Erkenntnisse" - inhalt: "Implikationen für DIGIT-Strategie, Handlungsempfehlungen" - - abschnitt: "6. Ausblick und Empfehlungen" - inhalt: "Fokusthemen, Ressourcenbedarf, Risiken" - - template_bedarf: - id: "TPL-KSS-01" - name: "Vorlage SHM-Jahresbericht" - status: "Zu entwickeln in Phase 10" - prioritaet: "Hoch" - - # --------------------------------------------------------------------------- - # REV-2: QUARTALS-REVIEW - # --------------------------------------------------------------------------- - - rev2_quartals_review: - - name: "SHM Quartals-Review" - entscheidungstyp_referenz: "REV-2" - zweck: "Portfolio-Analyse + Kontinuierliche Verbesserung" - frequenz: "Quartalsweise" - zeitpunkt: "Erste Woche nach Quartalsende (vor DPM-Portfolio-Review)" - - varianten: - - standard_q1_q3: - - name: "Standard-Review" - anwendung: "Q1, Q3" - dauer: "60-90 Minuten" - teilnehmer: "SHM-Leitung + Stakeholder-Manager" - - artefakt: - name: "SHM-Quartalsbericht" - umfang: "Ca. 2-4 Seiten" - gliederung: - - "1. VoC-Cluster-Status (Ampel-Matrix)" - - "2. Veränderungen ggü. Vorquartal" - - "3. Highlights" - - "4. Interventionen" - - "5. Maßnahmen-Status" - - "6. Handlungsbedarf" - - erweitert_q2_q4: - - name: "Erweiterter Review" - anwendung: "Q2, Q4" - dauer: "2-3 Stunden" - teilnehmer: "SHM-Leitung + Stakeholder-Manager" - charakter: "Workshop mit Retrospektive" - - artefakt: - name: "SHM-Quartalsbericht erweitert" - umfang: "Ca. 4-6 Seiten" - zusaetzliche_abschnitte: - - "7. Retrospektive (Was lief gut/schlecht?)" - - "8. Schnittstellen-Feedback" - - "9. Verbesserungsplan (aktualisiert)" - - "10. Bei Q4: Vorarbeit REV-1" - - template_bedarf: - id: "TPL-KSS-02" - name: "Vorlage SHM-Quartalsbericht" - status: "Zu entwickeln in Phase 10" - prioritaet: "Hoch" - anforderungen: - - "Modulare Struktur (Standard + Erweiterungs-Abschnitte)" - - "VoC-Cluster-Matrix als visuelles Kernelement" - - "Integrierter Maßnahmen-Tracker" - - # --------------------------------------------------------------------------- - # REV-3: TEAM-SYNC - # --------------------------------------------------------------------------- - - rev3_team_sync: - - name: "SHM Team-Sync" - entscheidungstyp_referenz: "REV-3" - zweck: "Operative Koordination im Team" - frequenz: "2-wöchentlich oder monatlich" - dauer: "45-60 Minuten" - - verantwortlichkeiten: - moderation: "Rotierend oder SHM-Leitung" - teilnehmer: "Alle Stakeholder-Manager" - - typische_agenda: - - punkt: "Check-in" - dauer: "5 Min" - beschreibung: "Kurze Runde: Wie geht's?" - - punkt: "Interventionsfälle" - dauer: "15-20 Min" - beschreibung: "Akute Situationen, kollegiale Beratung" - - punkt: "Komplexe Bedarfssituationen" - dauer: "15-20 Min" - beschreibung: "Routing-Fragen, Abstimmungsbedarf" - - punkt: "Wissenstransfer" - dauer: "10 Min" - beschreibung: "Erkenntnisse teilen, Best Practices" - - punkt: "Kurz-Updates" - dauer: "5 Min" - beschreibung: "Termine, Ankündigungen" - - artefakt: - name: "Team-Sync-Protokoll" - umfang: "Max. 1 Seite" - inhalt: - - "Datum, Teilnehmer" - - "Besprochene Fälle (Stichworte)" - - "Entscheidungen / Verabredungen" - - "Follow-ups mit Verantwortung" - - template_bedarf: - id: "TPL-KSS-03" - name: "Vorlage Team-Sync-Protokoll" - status: "Zu entwickeln in Phase 10" - prioritaet: "Mittel" - -# ============================================================================= -# TEMPLATE-ÜBERSICHT -# ============================================================================= - -template_uebersicht: - - beschreibung: | - Die folgenden Templates werden für die Review-Struktur benötigt. - Entwicklung erfolgt in Phase 10 (Arbeitsmaterialien). - - templates: - - - id: "TPL-KSS-01" - name: "Vorlage SHM-Jahresbericht" - fuer_format: "REV-1" - prioritaet: "Hoch" - ziel_ordner: "#03.7_arbeitsmaterialien/" - - - id: "TPL-KSS-02" - name: "Vorlage SHM-Quartalsbericht" - fuer_format: "REV-2" - prioritaet: "Hoch" - hinweis: "Modulare Struktur für Standard + Erweitert" - ziel_ordner: "#03.7_arbeitsmaterialien/" - - - id: "TPL-KSS-03" - name: "Vorlage Team-Sync-Protokoll" - fuer_format: "REV-3" - prioritaet: "Mittel" - ziel_ordner: "#03.7_arbeitsmaterialien/" - -# ============================================================================= -# JAHRESKALENDER -# ============================================================================= - -jahreskalender: - - beschreibung: | - Übersicht der Review-Formate im Jahresverlauf. - - quartale: - - quartal_1: - zeitraum: "Januar - März" - formate: - - "REV-2 Standard (Q4 Vorjahr auswerten)" - - "REV-3 Team-Sync (laufend)" - besonderheit: "Erster Review nach Jahreswechsel" - - quartal_2: - zeitraum: "April - Juni" - formate: - - "REV-2 Erweitert (Q1 + Retrospektive)" - - "REV-1 Pulse-Update" - - "REV-3 Team-Sync (laufend)" - besonderheit: "Halbjahres-Standortbestimmung" - - quartal_3: - zeitraum: "Juli - September" - formate: - - "REV-2 Standard (Q2 auswerten)" - - "REV-3 Team-Sync (laufend)" - besonderheit: "-" - - quartal_4: - zeitraum: "Oktober - Dezember" - formate: - - "REV-2 Erweitert (Q3 + Retrospektive + REV-1-Vorbereitung)" - - "REV-1 Jahres-Review" - - "REV-3 Team-Sync (laufend)" - besonderheit: "Jahresabschluss, Vorbereitung Strategieplanung" - - visualisierung: | - - ┌─────────┬──────────────────────────────────────────────────────────┐ - │ Quartal │ Formate │ - ├─────────┼──────────────────────────────────────────────────────────┤ - │ Q1 │ REV-2 Standard ──── REV-3 laufend ───────────────── │ - │ │ │ - │ Q2 │ REV-2 Erweitert ─ REV-1 Pulse ─ REV-3 laufend ───── │ - │ │ │ - │ Q3 │ REV-2 Standard ──── REV-3 laufend ───────────────── │ - │ │ │ - │ Q4 │ REV-2 Erweitert ─ REV-1 Jahres ─ REV-3 laufend ───── │ - └─────────┴──────────────────────────────────────────────────────────┘ - -# ============================================================================= -# ABGRENZUNG SHM / SPM IM REPORTING -# ============================================================================= - -abgrenzung_spm: - - beschreibung: | - Basierend auf GOV-SHM-024 erfolgt eine klare Verantwortungstrennung - zwischen SHM- und SPM-Reporting. - - referenz: "readme_shm_governance-entscheidungs-log.yaml (GOV-SHM-024)" - - shm_verantwortet: - - dimension: "D1 – Beziehungsqualität" - frage: "Wie läuft die Zusammenarbeit?" - - dimension: "D3 – Bedarfserfüllung" - frage: "Werden Anforderungen erkannt und bearbeitet?" - - dimension: "D4 – Strategische Passung" - frage: "Passt DIGIT zur Amtsstrategie?" - - perspektive: "Portfolio-Perspektive" - beschreibung: "Aggregierte Stakeholder-Sicht" - - spm_verantwortet: - - dimension: "D2 – Service-Qualität" - frage: "Wie gut sind die Services?" - - metrik: "SLA-Erfüllung" - frage: "Werden vereinbarte Levels eingehalten?" - - perspektive: "Service-Perspektive" - beschreibung: "Einzelne Service-Performance" - - gemeinsame_verantwortung: - - format: "Auftraggeber-Forum" - beschreibung: "Integriertes Format mit SHM- und SPM-Themen" - - thema: "Eskalationen" - beschreibung: "Wenn beide Bereiche betroffen sind" - - schnittstellenregelung: - - - schnittstelle: "VoC-Feedback zu D2" - von: "SHM" - an: "SPM / Service Owner" - mechanismus: | - SHM leitet D2-Feedback (Service-Qualität) an den zuständigen - Service Owner weiter. Format: Kurz-Info mit Quelle und Kontext. - - - schnittstelle: "Service-Performance-Daten" - von: "SPM" - an: "SHM" - mechanismus: | - SHM erhält Zugriff auf Service-Performance-Daten als Kontext - für Stakeholder-Gespräche. Kein formaler Report, sondern - Leserecht auf SLM-Dashboards/Berichte. - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-10" - autor: "Konzept-Sprint Phase 5" - aenderung: | - Initiale Erstellung basierend auf Working Document: - - Modulname festgelegt (Koordinations- und Steuerungsstruktur) - - Grundprinzipien definiert (PRIN-01 bis PRIN-05) - - Steuerungsindikatoren spezifiziert (primär/sekundär) - - Entscheidungstypen REV-1, REV-2, REV-3 modelliert - - Ursprüngliche E2 und E4 zu konsolidiertem REV-2-Format zusammengeführt - - Review-Struktur vollständig dokumentiert - - Einbettung in DIGIT-Zyklen und DPM-Portfolio-Review ergänzt - - Kaskadierungslogik definiert - - Template-Übersicht für Phase 10 erstellt - - Jahreskalender hinzugefügt +# ============================================================================= +# SHM KOORDINATIONS- UND STEUERUNGSSTRUKTUR +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Typ: Methodik +# Version: 1.0 +# Datum: 2025-12-10 +# Status: Final (Phase 5) +# ============================================================================= + +meta: + modul_id: "SHM-M-02" + name: "Koordinations- und Steuerungsstruktur" + typ: "Methodik" + + vorheriger_name: "Performance & Review" + + begruendung_umbenennung: | + Der ursprüngliche Name "Performance & Review" war zu stark durch eine + betriebswirtschaftliche Steuerungslogik geprägt (Effizienz, Kontrolle, + quantifizierte KPIs). Für SHM im Verwaltungskontext ist das nicht passend. + + Der neue Name "Koordinations- und Steuerungsstruktur" betont: + - Koordination als zentralen Modus (nicht Kontrolle) + - Steuerung als legitimer Verwaltungsbegriff + - Struktur statt Framework (weniger technisch) + + Die Integration von REV-3 (Operative Koordination) wird dadurch + konzeptionell stimmig. + + zweck: | + Die Koordinations- und Steuerungsstruktur definiert, wie SHM seine + Arbeit reflektiert, koordiniert und kontinuierlich verbessert. Sie + verbindet operative Abstimmung mit taktischer Steuerung und + strategischer Rechenschaft. + + itil4_referenz: + practice: "Continual Improvement" + ergaenzende_konzepte: + - konzept: "Voice of Customer" + quelle: "ITIL 4 Drive Stakeholder Value (DSV)" + - konzept: "Measurement and Reporting" + quelle: "ITIL 4 Direct Plan Improve (DPI)" + + governance_referenzen: + - id: "GOV-SHM-023" + thema: "Fokus auf Ergebnis-Indikatoren" + dokument: "readme_shm_governance-entscheidungs-log.yaml" + - id: "GOV-SHM-024" + thema: "Abgrenzung SHM/SPM im Reporting" + dokument: "readme_shm_governance-entscheidungs-log.yaml" + + konzept_referenzen: + - dokument: "shm_voice-of-customer.yaml" + beschreibung: "VoC als zentraler Steuerungsindikator" + - dokument: "shm_engagement-framework.yaml" + beschreibung: "Interaktionsformate, die VoC-Quellen liefern" + - dokument: "shm_stakeholder-portfolio.yaml" + beschreibung: "Beziehungsqualität als Steuerungsindikator" + +# ============================================================================= +# GRUNDPRINZIPIEN +# ============================================================================= + +grundprinzipien: + + beschreibung: | + Die folgenden Prinzipien leiten die Gestaltung der Koordinations- und + Steuerungsstruktur. Sie reflektieren den Charakter von SHM als + beziehungsorientierte Funktion im Verwaltungskontext. + + prinzipien: + + - id: "PRIN-01" + name: "Qualität vor Effizienz" + beschreibung: | + Die zentrale Frage ist nicht "Wie viel?" oder "Wie schnell?", + sondern "Wie gut?". Die Qualität der Stakeholder-Beziehungen + und die Wirksamkeit der Betreuung stehen im Vordergrund. + implikation: | + Review-Fragen fokussieren auf Beziehungsqualität und + Stakeholder-Wahrnehmung, nicht auf Durchsatzzahlen. + + - id: "PRIN-02" + name: "Koordination vor Kontrolle" + beschreibung: | + SHM arbeitet mit Abstimmung, Austausch und gemeinsamer + Problemlösung – nicht mit hierarchischer Überwachung. + Die Steuerungsstruktur ermöglicht Koordination, nicht Kontrolle. + implikation: | + REV-3 (Team-Sync) ist ein Koordinationsformat, kein + Kontroll-Meeting. Keine Rechenschaftspflicht nach oben. + + - id: "PRIN-03" + name: "Lernen vor Messen" + beschreibung: | + Ziel ist Erkenntnisgewinn und kontinuierliche Verbesserung, + nicht das Erfüllen von Kennzahlen. Metriken dienen dem Lernen, + nicht der Rechtfertigung. + implikation: | + Keine KPI-Dashboards mit Zielerreichungsquoten. Stattdessen + qualitative Reflexion und Musteranalyse. + + - id: "PRIN-04" + name: "Qualitative Einschätzungen vor quantifizierten Kennzahlen" + beschreibung: | + Beziehungen sind mehrdimensional, kontextabhängig und dynamisch. + Ihre Qualität lässt sich nicht sinnvoll auf eine Zahl reduzieren. + Quantifizierung suggeriert eine Präzision, die bei Beziehungsarbeit + nicht existiert – und erzeugt perverse Anreize: Was gemessen wird, + wird optimiert, nicht notwendigerweise verbessert. + implikation: | + Berichte enthalten narrative Einschätzungen mit Kontext und + Ursachenbezug. Zahlen werden nur dort verwendet, wo sie echten + Informationsgewinn bieten (z.B. Verteilungen im Portfolio), + nicht als Selbstzweck. + beispiel: + statt: "78% der Turnus-Gespräche durchgeführt" + besser: | + Turnus-Gespräche finden regelmäßig statt. Bei zwei Key-Stakeholdern + kam es zu Verschiebungen wegen Personalwechsel auf Fachbereichsseite. + abgrenzung: | + Dies ist kein Plädoyer gegen jede Form von Strukturierung. Die + Ampel-Matrix (VoC-Cluster) ist eine qualitative Verdichtung mit + visuellem Ordnungsschema – keine Quantifizierung. + + - id: "PRIN-05" + name: "Stakeholder-Stimme als Kompass" + beschreibung: | + Die Wahrnehmung und das Feedback der Stakeholder sind der + zentrale Gradmesser für den Erfolg von SHM. Das Voice-of-Customer- + Konzept wird strukturell verankert. + implikation: | + VoC-Erkenntnisse sind Kernelement aller Review-Formate. + Keine Bewertung ohne Stakeholder-Perspektive. + referenz: "shm_voice-of-customer.yaml" + +# ============================================================================= +# STEUERUNGSINDIKATOREN +# ============================================================================= + +steuerungsindikatoren: + + beschreibung: | + Basierend auf GOV-SHM-023 fokussiert die SHM-Steuerung auf + Ergebnis-Indikatoren (Wirkung), nicht auf Prozess-Indikatoren + (Aktivitäten). + + primaere_indikatoren: + + beschreibung: | + Diese Indikatoren werden in den Reviews (REV-1, REV-2) systematisch + betrachtet und berichtet. + + indikatoren: + + - id: "IND-P-01" + name: "Beziehungsqualität" + quelle: "shm_stakeholder-portfolio.yaml" + beschreibung: | + Verteilung der Beziehungsqualitäts-Stufen (Exzellent, Gut, + Angespannt, Kritisch) im Portfolio. + betrachtung: "Verteilung und Veränderung" + + - id: "IND-P-02" + name: "VoC-Cluster-Ampeln" + quelle: "shm_voice-of-customer.yaml" + beschreibung: | + Kritikalitätsbewertung der thematischen Cluster (D1-D4) + in der Ampel-Matrix. + betrachtung: "Status und Trend" + + - id: "IND-P-03" + name: "VoC-Highlights" + quelle: "shm_voice-of-customer.yaml" + beschreibung: | + Qualitative Erkenntnisse aus dem Stakeholder-Feedback + (positiv, kritisch, insight, trend). + betrachtung: "Narrative Auswertung" + + sekundaere_indikatoren: + + beschreibung: | + Diese Indikatoren werden nicht im Review berichtet, können aber + bei operativen Problemen intern herangezogen werden. + + indikatoren: + + - id: "IND-S-01" + name: "Turnus-Gespräche Durchführungsquote" + verwendung: "Nur bei Verdacht auf systematische Lücken" + + - id: "IND-S-02" + name: "Routing-Statistik" + verwendung: "Nur bei Analyse von Bedarfsmustern" + + - id: "IND-S-03" + name: "Durchlaufzeiten Bedarfssteckbrief" + verwendung: "Nur bei Engpass-Analyse" + +# ============================================================================= +# ENTSCHEIDUNGSTYPEN +# ============================================================================= + +entscheidungstypen: + + beschreibung: | + Die Koordinations- und Steuerungsstruktur unterstützt drei + Entscheidungstypen auf unterschiedlichen Ebenen. Diese bilden + das funktionale Fundament der Struktur. + + Hinweis: Die ursprünglich separaten Typen (Portfolio-Qualität + und Funktions-Weiterentwicklung) wurden zu einem konsolidierten + REV-2-Format zusammengeführt (analog DPM-Portfolio-Review). + + uebersicht: + + - id: "REV-1" + name: "Auftragserfüllung" + ebene: "Strategisch" + frequenz: "Jährlich + Halbjahres-Pulse" + adressat: "Vision Board" + + - id: "REV-2" + name: "Portfolio-Qualität, Lernen & Verbesserung" + ebene: "Taktisch" + frequenz: "Quartalsweise" + adressat: "SHM-Leitung, SHM-Team" + + - id: "REV-3" + name: "Operative Koordination" + ebene: "Operativ" + frequenz: "2-wöchentlich bis monatlich" + adressat: "SHM-Leitung, SHM-Team" + + typen: + + # ------------------------------------------------------------------------- + # REV-1: AUFTRAGSERFÜLLUNG + # ------------------------------------------------------------------------- + + - id: "REV-1" + name: "Auftragserfüllung" + + kernfrage: "Leistet SHM, wofür es da ist?" + + beschreibung: | + Strategische Bewertung, ob die Funktion SHM ihren Zweck im + DIGITOM-Gesamtkontext erfüllt. Die Stakeholder-Stimme (Voice + of Customer) ist hier ein zentraler Input. + + adressat: "DIGIT-Leitung, Vision Board" + + charakter: "Strategisch-legitimatorisch" + + frequenz: "Jährlich" + + zusaetzlich: + name: "Pulse-Update" + frequenz: "Halbjährlich (Q2)" + umfang: "Kurzform (max. 2 Seiten)" + zweck: "Standortbestimmung zwischen Jahresberichten" + + betrachtungsweise: | + Qualitative Gesamteinschätzung mit narrativer Begründung. + Keine Scorecard, sondern strukturierter Bericht mit + Einordnung und Handlungsempfehlungen. + + typische_fragestellungen: + - "Werden die Stakeholder-Beziehungen professionell gepflegt?" + - "Funktioniert die Bedarfserkennung und -weiterleitung?" + - "Wie nehmen die Ämter DIGIT als Partner wahr?" + - "Trägt SHM zur strategischen Ausrichtung von DIGIT bei?" + + voc_relevanz: | + REV-1 integriert die aggregierte Stakeholder-Stimme als + zentralen Erfolgsindikator. Die Frage "Erfüllen wir unseren + Auftrag?" wird wesentlich durch "Was sagen die Stakeholder?" + beantwortet. + + voc_output: "Verdichtung REV-1 (Jahres-Review)" + + # ------------------------------------------------------------------------- + # REV-2: PORTFOLIO-QUALITÄT, LERNEN & VERBESSERUNG + # ------------------------------------------------------------------------- + + - id: "REV-2" + name: "Portfolio-Qualität, Lernen & Verbesserung" + + kernfrage: | + Wie steht es um unsere Stakeholder-Beziehungen, was lernen wir + daraus, und was müssen wir verbessern? + + beschreibung: | + Kombiniertes Format für Portfolio-Analyse und kontinuierliche + Verbesserung. Quartalsweise Betrachtung des Stakeholder-Portfolios + mit integrierter CI-Komponente. In Q2 und Q4 erweitertes Format + mit Retrospektive und Verbesserungsplanung. + + Diese Konsolidierung folgt dem bewährten Ansatz des DPM-Portfolio- + Reviews, das Portfolio-Analyse und Prozessverbesserung ebenfalls + in einem Format verbindet. + + adressat: "SHM-Leitung, SHM-Team" + + charakter: "Taktisch-reflexiv" + + frequenz: "Quartalsweise" + + varianten: + + - variante: "Standard (Q1, Q3)" + dauer: "60-90 Minuten" + fokus: "Portfolio-Analyse, VoC-Status, Maßnahmen-Tracking" + ci_anteil: "Kurz (15 Min): Status offener Maßnahmen, neue Themen sammeln" + + - variante: "Erweitert (Q2, Q4)" + dauer: "2-3 Stunden" + fokus: "Portfolio-Analyse + Retrospektive + Verbesserungsplanung" + ci_anteil: "Deep-Dive: Was lief gut/schlecht? Strukturelle Verbesserungen" + zusatz_q4: "Vorbereitung REV-1-Jahresbericht" + + inhaltliche_dimensionen: + + portfolio_analyse: + - dimension: "Beziehungsqualitäts-Verteilung" + beschreibung: "Verteilung EX/GU/AN/KR im Portfolio" + - dimension: "VoC-Cluster-Status" + beschreibung: "Ampel-Matrix D1-D4" + - dimension: "Veränderungen" + beschreibung: "Entwicklung gegenüber Vorquartal" + - dimension: "Highlights" + beschreibung: "Relevante Einzelerkenntnisse" + - dimension: "Interventionen" + beschreibung: "Laufende und neue Interventionsfälle" + + ci_komponente: + - dimension: "Maßnahmen-Status" + beschreibung: "Review offener Verbesserungsmaßnahmen" + - dimension: "Wirksamkeit" + beschreibung: "Wurden umgesetzte Maßnahmen wirksam?" + - dimension: "Neue Themen" + beschreibung: "Erkannte Verbesserungspotenziale" + - dimension: "Retrospektive (nur Q2/Q4)" + beschreibung: "Was lief gut? Was war schwierig?" + - dimension: "Schnittstellen-Feedback (nur Q2/Q4)" + beschreibung: "Rückmeldungen von DPM, SPM, Service Desk" + + output: + - "SHM-Quartalsbericht (inkl. Maßnahmen-Status)" + - "Bei Q2/Q4: Aktualisierter Verbesserungsplan" + - "Input für DPM-Portfolio-Review" + - "Bei Q4: Vorarbeit für REV-1-Jahresbericht" + + voc_relevanz: | + VoC informiert sowohl die Portfolio-Betrachtung als auch die + Verbesserungsplanung: + - Portfolio: Welche Beziehungen sind belastet? Welche Muster? + - CI: Systematische Muster, die auf Prozessprobleme hindeuten + + voc_output: "Verdichtung REV-2 (Quartals-Review)" + + konsolidierungshinweis: | + Dieses Format ersetzt die ursprünglich separaten Entscheidungstypen + (vormals E2 für Portfolio-Qualität & Lernen und E4 für Funktions-Weiterentwicklung). + Die Zusammenlegung reduziert Overhead und ist konsistent mit dem + DPM-Portfolio-Review-Ansatz. + + # ------------------------------------------------------------------------- + # REV-3: OPERATIVE KOORDINATION + # ------------------------------------------------------------------------- + + - id: "REV-3" + name: "Operative Koordination" + + kernfrage: "Welche laufenden Themen müssen wir im Team abstimmen?" + + beschreibung: | + Regelmäßiger Austausch im SHM-Team zu laufenden Stakeholder- + Themen. Fokus auf kollegiale Beratung, Wissenstransfer und + gemeinsame Problemlösung. + + adressat: "SHM-Team (Stakeholder-Manager untereinander)" + + charakter: "Operativ-koordinierend" + + frequenz: "2-wöchentlich oder monatlich" + + betrachtungsweise: | + Fall-basiert und anlassbezogen. Kein formaler Review, + sondern Arbeits-Meeting mit Koordinationsfunktion. + + typische_inhalte: + - "Aktuelle Interventionsfälle (Angespannt/Kritisch)" + - "Komplexe Bedarfssituationen" + - "Übergaben bei Zuständigkeitswechsel" + - "Erkenntnisse aus Gesprächen, die für andere relevant sind" + - "Status-Updates zu laufenden Demands/Projekten bei Key-Stakeholdern" + + abgrenzung: | + REV-3 ist kein Review im klassischen Sinne, sondern ein + Koordinationsmechanismus. Die Integration in die Steuerungs- + struktur stellt sicher, dass operative Erkenntnisse in die + taktische (REV-2) und strategische (REV-1) Ebene einfließen. + + format: + name: "SHM Team-Sync" + dauer: "45-60 Minuten" + moderation: "Rotierend oder SHM-Leitung" + dokumentation: "Kurzprotokoll mit Entscheidungen und Follow-ups" + + voc_relevanz: | + Aktuelle Highlights (insbesondere Kritik-Highlights) fließen + in die Team-Koordination ein. Interventionsfälle werden auf + Basis von VoC-Signalen identifiziert. + + voc_output: "Highlights (laufend)" + +# ============================================================================= +# EINBETTUNG IN DIGIT-ZYKLEN +# ============================================================================= + +einbettung_digit_zyklen: + + beschreibung: | + Die SHM-Reviews sind nicht isoliert, sondern in die übergreifenden + DIGIT-Governance-Zyklen eingebettet. + + ebenen: + + strategische_ebene: + gremium: "Vision Board" + rhythmus: "Quartalsweise" + funktion: "Definiert Strategie und jährliche strategische Fokusthemen" + shm_einbettung: | + REV-1 (Auftragserfüllung) wird im Vision Board verankert: + - Jährlich: Vollständiger SHM-Jahresbericht als Input für Strategieplanung + - Halbjährlich: Pulse-Update (Kurzform) zur Standortbestimmung + + taktische_ebene: + gremium: "SHM-Leitung / SOR bei Bedarf" + rhythmus: "Quartalsweise (REV-2)" + shm_einbettung: | + REV-2 (Portfolio-Qualität, Lernen & Verbesserung) liegt auf der + taktischen Ebene und wird durch SHM-Leitung verantwortet. + + operative_ebene: + gremium: "SHM-Team" + rhythmus: "2-wöchentlich bis monatlich (REV-3)" + shm_einbettung: | + REV-3 (Operative Koordination) ist ein internes Team-Format. + +# ============================================================================= +# EINBETTUNG IN ÜBERGREIFENDE DIGIT-REVIEWS +# ============================================================================= + +einbettung_digit_reviews: + + beschreibung: | + SHM ist Teilnehmer an übergreifenden DIGIT-Review-Formaten und + liefert dort Input aus seiner Perspektive. + + dpm_portfolio_review: + + name: "Demand-Portfolio Review" + charakter: "DIGIT-übergreifendes Quartals-Review" + frequenz: "Quartalsweise" + zeitpunkt: "Erste Monatshälfte nach Quartalsende (ca. T+10 bis T+14)" + teilnehmer: "AL Planung (Leitung), DPM, PPM, SPM, SHM" + + shm_rolle: | + SHM ist Teilnehmer und Input-Lieferant. Der SHM-Beitrag umfasst: + - Stakeholder-Trends (VoC-Cluster-Entwicklung) + - Bedarfsmuster (Erkenntnisse aus D3, Routing-Erfahrungen) + - Kommunikations-Feedback (Highlights, Beziehungsqualität) + + shm_input_quelle: "REV-2 (SHM Quartals-Review)" + + sequenzierung: | + REV-2 muss vor dem DPM-Portfolio-Review stattfinden, damit SHM + vorbereitet ist und konsolidierten Input liefern kann. + + Empfohlene Sequenz: + - REV-2: Erste Woche nach Quartalsende + - DPM-Portfolio-Review: Zweite Woche nach Quartalsende + + referenz_dokument: "Konzept_DPM – Demand-Portfolio Review Framework" + +# ============================================================================= +# KASKADIERUNGSLOGIK +# ============================================================================= + +kaskadierungslogik: + + beschreibung: | + Informationen und Erkenntnisse fließen zwischen den Ebenen in + beide Richtungen. + + aufwaertsfluss: + + - von: "REV-3 (Team-Sync)" + nach: "REV-2 (Quartals-Review)" + inhalt: + - "Interventionsfälle, die eskaliert oder dokumentiert werden müssen" + - "Erkenntnisse aus Einzelgesprächen" + - "Muster, die im Tagesgeschäft auffallen" + + - von: "REV-2 (Quartals-Review)" + nach: "REV-1 (Jahres-Review)" + inhalt: + - "Quartals-Status und Trends" + - "Konsolidierte VoC-Erkenntnisse" + - "Handlungsbedarfe mit strategischer Relevanz" + + - von: "REV-2 (Quartals-Review)" + nach: "REV-2 erweitert (Q2/Q4)" + inhalt: + - "Muster, die auf strukturelle Probleme hindeuten" + - "Wiederkehrende Themen aus mehreren Quartalen" + + abwaertsfluss: + + - von: "REV-1 / Vision Board" + nach: "REV-2 / REV-3" + inhalt: + - "Strategische Prioritäten" + - "Fokusthemen für die Stakeholder-Betreuung" + - "Ressourcenentscheidungen" + + - von: "REV-2 erweitert (Q2/Q4)" + nach: "REV-3 (Team-Sync)" + inhalt: + - "Angepasste Prozesse oder Vorgehensweisen" + - "Maßnahmen aus Verbesserungsplanung" + - "Veränderte Prioritäten" + +# ============================================================================= +# REVIEW-FORMATE IM DETAIL +# ============================================================================= + +review_formate: + + # --------------------------------------------------------------------------- + # REV-1: JAHRES-REVIEW + # --------------------------------------------------------------------------- + + rev1_jahres_review: + + name: "SHM Jahres-Review" + entscheidungstyp_referenz: "REV-1" + zweck: "Strategische Bewertung der SHM-Funktion" + frequenz: "Jährlich" + zeitpunkt: "Q4 (vor Vision-Board-Strategieplanung)" + + zusaetzlich_pulse_update: + frequenz: "Halbjährlich" + zeitpunkt: "Q2" + umfang: "Kurzform (max. 2 Seiten)" + + verantwortlichkeiten: + erstellt: "SHM-Leitung" + empfaengt: "Vision Board" + + artefakt: + name: "SHM-Jahresbericht" + umfang: "Ca. 5-10 Seiten" + gliederung: + - abschnitt: "1. Management Summary" + inhalt: "Kernaussagen, Gesamtbewertung" + - abschnitt: "2. Stakeholder-Portfolio im Überblick" + inhalt: "Bestandsübersicht, Beziehungsqualitäts-Verteilung" + - abschnitt: "3. Voice of Customer – Gesamtbild" + inhalt: "VoC-Cluster-Jahresübersicht, zentrale Erkenntnisse" + - abschnitt: "4. Highlights des Jahres" + inhalt: "Erfolge, Herausforderungen, besondere Fälle" + - abschnitt: "5. Strategische Erkenntnisse" + inhalt: "Implikationen für DIGIT-Strategie, Handlungsempfehlungen" + - abschnitt: "6. Ausblick und Empfehlungen" + inhalt: "Fokusthemen, Ressourcenbedarf, Risiken" + + template_bedarf: + id: "TPL-KSS-01" + name: "Vorlage SHM-Jahresbericht" + status: "Zu entwickeln in Phase 10" + prioritaet: "Hoch" + + # --------------------------------------------------------------------------- + # REV-2: QUARTALS-REVIEW + # --------------------------------------------------------------------------- + + rev2_quartals_review: + + name: "SHM Quartals-Review" + entscheidungstyp_referenz: "REV-2" + zweck: "Portfolio-Analyse + Kontinuierliche Verbesserung" + frequenz: "Quartalsweise" + zeitpunkt: "Erste Woche nach Quartalsende (vor DPM-Portfolio-Review)" + + varianten: + + standard_q1_q3: + + name: "Standard-Review" + anwendung: "Q1, Q3" + dauer: "60-90 Minuten" + teilnehmer: "SHM-Leitung + Stakeholder-Manager" + + artefakt: + name: "SHM-Quartalsbericht" + umfang: "Ca. 2-4 Seiten" + gliederung: + - "1. VoC-Cluster-Status (Ampel-Matrix)" + - "2. Veränderungen ggü. Vorquartal" + - "3. Highlights" + - "4. Interventionen" + - "5. Maßnahmen-Status" + - "6. Handlungsbedarf" + + erweitert_q2_q4: + + name: "Erweiterter Review" + anwendung: "Q2, Q4" + dauer: "2-3 Stunden" + teilnehmer: "SHM-Leitung + Stakeholder-Manager" + charakter: "Workshop mit Retrospektive" + + artefakt: + name: "SHM-Quartalsbericht erweitert" + umfang: "Ca. 4-6 Seiten" + zusaetzliche_abschnitte: + - "7. Retrospektive (Was lief gut/schlecht?)" + - "8. Schnittstellen-Feedback" + - "9. Verbesserungsplan (aktualisiert)" + - "10. Bei Q4: Vorarbeit REV-1" + + template_bedarf: + id: "TPL-KSS-02" + name: "Vorlage SHM-Quartalsbericht" + status: "Zu entwickeln in Phase 10" + prioritaet: "Hoch" + anforderungen: + - "Modulare Struktur (Standard + Erweiterungs-Abschnitte)" + - "VoC-Cluster-Matrix als visuelles Kernelement" + - "Integrierter Maßnahmen-Tracker" + + # --------------------------------------------------------------------------- + # REV-3: TEAM-SYNC + # --------------------------------------------------------------------------- + + rev3_team_sync: + + name: "SHM Team-Sync" + entscheidungstyp_referenz: "REV-3" + zweck: "Operative Koordination im Team" + frequenz: "2-wöchentlich oder monatlich" + dauer: "45-60 Minuten" + + verantwortlichkeiten: + moderation: "Rotierend oder SHM-Leitung" + teilnehmer: "Alle Stakeholder-Manager" + + typische_agenda: + - punkt: "Check-in" + dauer: "5 Min" + beschreibung: "Kurze Runde: Wie geht's?" + - punkt: "Interventionsfälle" + dauer: "15-20 Min" + beschreibung: "Akute Situationen, kollegiale Beratung" + - punkt: "Komplexe Bedarfssituationen" + dauer: "15-20 Min" + beschreibung: "Routing-Fragen, Abstimmungsbedarf" + - punkt: "Wissenstransfer" + dauer: "10 Min" + beschreibung: "Erkenntnisse teilen, Best Practices" + - punkt: "Kurz-Updates" + dauer: "5 Min" + beschreibung: "Termine, Ankündigungen" + + artefakt: + name: "Team-Sync-Protokoll" + umfang: "Max. 1 Seite" + inhalt: + - "Datum, Teilnehmer" + - "Besprochene Fälle (Stichworte)" + - "Entscheidungen / Verabredungen" + - "Follow-ups mit Verantwortung" + + template_bedarf: + id: "TPL-KSS-03" + name: "Vorlage Team-Sync-Protokoll" + status: "Zu entwickeln in Phase 10" + prioritaet: "Mittel" + +# ============================================================================= +# TEMPLATE-ÜBERSICHT +# ============================================================================= + +template_uebersicht: + + beschreibung: | + Die folgenden Templates werden für die Review-Struktur benötigt. + Entwicklung erfolgt in Phase 10 (Arbeitsmaterialien). + + templates: + + - id: "TPL-KSS-01" + name: "Vorlage SHM-Jahresbericht" + fuer_format: "REV-1" + prioritaet: "Hoch" + ziel_ordner: "#03.7_arbeitsmaterialien/" + + - id: "TPL-KSS-02" + name: "Vorlage SHM-Quartalsbericht" + fuer_format: "REV-2" + prioritaet: "Hoch" + hinweis: "Modulare Struktur für Standard + Erweitert" + ziel_ordner: "#03.7_arbeitsmaterialien/" + + - id: "TPL-KSS-03" + name: "Vorlage Team-Sync-Protokoll" + fuer_format: "REV-3" + prioritaet: "Mittel" + ziel_ordner: "#03.7_arbeitsmaterialien/" + +# ============================================================================= +# JAHRESKALENDER +# ============================================================================= + +jahreskalender: + + beschreibung: | + Übersicht der Review-Formate im Jahresverlauf. + + quartale: + + quartal_1: + zeitraum: "Januar - März" + formate: + - "REV-2 Standard (Q4 Vorjahr auswerten)" + - "REV-3 Team-Sync (laufend)" + besonderheit: "Erster Review nach Jahreswechsel" + + quartal_2: + zeitraum: "April - Juni" + formate: + - "REV-2 Erweitert (Q1 + Retrospektive)" + - "REV-1 Pulse-Update" + - "REV-3 Team-Sync (laufend)" + besonderheit: "Halbjahres-Standortbestimmung" + + quartal_3: + zeitraum: "Juli - September" + formate: + - "REV-2 Standard (Q2 auswerten)" + - "REV-3 Team-Sync (laufend)" + besonderheit: "-" + + quartal_4: + zeitraum: "Oktober - Dezember" + formate: + - "REV-2 Erweitert (Q3 + Retrospektive + REV-1-Vorbereitung)" + - "REV-1 Jahres-Review" + - "REV-3 Team-Sync (laufend)" + besonderheit: "Jahresabschluss, Vorbereitung Strategieplanung" + + visualisierung: | + + ┌─────────┬──────────────────────────────────────────────────────────┐ + │ Quartal │ Formate │ + ├─────────┼──────────────────────────────────────────────────────────┤ + │ Q1 │ REV-2 Standard ──── REV-3 laufend ───────────────── │ + │ │ │ + │ Q2 │ REV-2 Erweitert ─ REV-1 Pulse ─ REV-3 laufend ───── │ + │ │ │ + │ Q3 │ REV-2 Standard ──── REV-3 laufend ───────────────── │ + │ │ │ + │ Q4 │ REV-2 Erweitert ─ REV-1 Jahres ─ REV-3 laufend ───── │ + └─────────┴──────────────────────────────────────────────────────────┘ + +# ============================================================================= +# ABGRENZUNG SHM / SPM IM REPORTING +# ============================================================================= + +abgrenzung_spm: + + beschreibung: | + Basierend auf GOV-SHM-024 erfolgt eine klare Verantwortungstrennung + zwischen SHM- und SPM-Reporting. + + referenz: "readme_shm_governance-entscheidungs-log.yaml (GOV-SHM-024)" + + shm_verantwortet: + - dimension: "D1 – Beziehungsqualität" + frage: "Wie läuft die Zusammenarbeit?" + - dimension: "D3 – Bedarfserfüllung" + frage: "Werden Anforderungen erkannt und bearbeitet?" + - dimension: "D4 – Strategische Passung" + frage: "Passt DIGIT zur Amtsstrategie?" + - perspektive: "Portfolio-Perspektive" + beschreibung: "Aggregierte Stakeholder-Sicht" + + spm_verantwortet: + - dimension: "D2 – Service-Qualität" + frage: "Wie gut sind die Services?" + - metrik: "SLA-Erfüllung" + frage: "Werden vereinbarte Levels eingehalten?" + - perspektive: "Service-Perspektive" + beschreibung: "Einzelne Service-Performance" + + gemeinsame_verantwortung: + - format: "Auftraggeber-Forum" + beschreibung: "Integriertes Format mit SHM- und SPM-Themen" + - thema: "Eskalationen" + beschreibung: "Wenn beide Bereiche betroffen sind" + + schnittstellenregelung: + + - schnittstelle: "VoC-Feedback zu D2" + von: "SHM" + an: "SPM / Service Owner" + mechanismus: | + SHM leitet D2-Feedback (Service-Qualität) an den zuständigen + Service Owner weiter. Format: Kurz-Info mit Quelle und Kontext. + + - schnittstelle: "Service-Performance-Daten" + von: "SPM" + an: "SHM" + mechanismus: | + SHM erhält Zugriff auf Service-Performance-Daten als Kontext + für Stakeholder-Gespräche. Kein formaler Report, sondern + Leserecht auf SLM-Dashboards/Berichte. + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-10" + autor: "Konzept-Sprint Phase 5" + aenderung: | + Initiale Erstellung basierend auf Working Document: + - Modulname festgelegt (Koordinations- und Steuerungsstruktur) + - Grundprinzipien definiert (PRIN-01 bis PRIN-05) + - Steuerungsindikatoren spezifiziert (primär/sekundär) + - Entscheidungstypen REV-1, REV-2, REV-3 modelliert + - Ursprüngliche E2 und E4 zu konsolidiertem REV-2-Format zusammengeführt + - Review-Struktur vollständig dokumentiert + - Einbettung in DIGIT-Zyklen und DPM-Portfolio-Review ergänzt + - Kaskadierungslogik definiert + - Template-Übersicht für Phase 10 erstellt + - Jahreskalender hinzugefügt - Abgrenzung SHM/SPM dokumentiert \ No newline at end of file diff --git a/#03_stakeholder-management/#03.4_methodik/shm_voice-of-customer.yaml b/#03_stakeholder-management/#03.4_methodik/shm_voice-of-customer.yaml deleted file mode 100644 index 40bacb9..0000000 --- a/#03_stakeholder-management/#03.4_methodik/shm_voice-of-customer.yaml +++ /dev/null @@ -1,66 +0,0 @@ -# ============================================================================= -# SHM VOICE-OF-CUSTOMER (VoC) KONZEPT -# ============================================================================= -# -# Voice-of-Customer Methodik im Stakeholder-Management. -# Status: Placeholder mit SPM-Schnittstelle -# ============================================================================= - -metadata: - name: "Voice-of-Customer (VoC) Konzept" - version: "0.1" - status: "placeholder" - erstellt: "2025-12-17" - projekt: "DIGITOM" - organisation: "Stadt Freiburg / DIGIT" - - beschreibung: > - Voice-of-Customer Methodik zur systematischen Erfassung und - Aufbereitung von Kundenrueckmeldungen. Dieses Dokument ist ein - Placeholder und enthaelt vorerst nur die SPM-Schnittstelle. - - referenzen: - service_review_konzept: "02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml" - governance_entscheidungen: "GOV-SR-001" - -# ============================================================================= -# SCHNITTSTELLE ZU SPM SERVICE-REVIEW -# ============================================================================= - -spm_schnittstelle: - - beschreibung: | - Der VoC-Cluster D2 (Service-Qualitaet) liefert Input fuer die - Service-Review-Dimension "Nutzerzufriedenheit" (SR-D3). - - referenz: "spm_konzept_service-review.yaml -> bewertungsschema.dimensionen.SR-D3" - governance_referenz: "GOV-SR-001" - - nutzung_im_service_review: - input_fuer_dimension: "SR-D3 Nutzerzufriedenheit" - datenquelle: "VoC-Erkenntnisse aus SHM E2-Reports (Cluster D2)" - verantwortlich: "SO bezieht SHM-Erkenntnisse in Review ein" - - indikatoren_aus_shm: - - "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)" - - "Beschwerden und Eskalationen" - - "VoC-Signale aus Stakeholder-Gespraechen" - - "Informelle Rueckmeldungen via SM" - - synchronisation: - beschreibung: | - SHM E2-Review liefert VoC-Erkenntnisse als Input fuer den - quartalsweisen Service-Review. - sequenz: "SHM E2-Review -> VoC-Erkenntnisse -> Service-Review nutzt D2-Cluster" - -# ============================================================================= -# AENDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-17" - aenderung: | - - Placeholder erstellt mit SPM-Schnittstelle fuer Service-Review (GOV-SR-001) - autor: "DIGITOM-Projekt" - referenz: "spm_konzept_service-review.yaml" diff --git a/#03_stakeholder-management/#03.5_schnittstellen/shm_sor-integration.yaml b/#03_stakeholder-management/#03.5_schnittstellen/shm_sor-integration.yaml index e1ba280..e79e637 100644 --- a/#03_stakeholder-management/#03.5_schnittstellen/shm_sor-integration.yaml +++ b/#03_stakeholder-management/#03.5_schnittstellen/shm_sor-integration.yaml @@ -1,20 +1,20 @@ -# ======================================== -# SHM-Integration in der Service-Operation-Runde -# ======================================== -# Version: 0.1 (Platzhalter) -# Datum: 2024-12-03 -# Status: Ausstehend -# Entwicklungsphase: 6 -# ======================================== - -# ITIL4-Referenz (falls zutreffend): -# itil4_referenz: -# practice: "" -# relevante_elemente: [] -# adaption_fuer_digitom: "" - -# ======================================== -# INHALT -# ======================================== - -# [Inhalt folgt in Phase 6] +# ======================================== +# SHM-Integration in der Service-Operation-Runde +# ======================================== +# Version: 0.1 (Platzhalter) +# Datum: 2024-12-03 +# Status: Ausstehend +# Entwicklungsphase: 6 +# ======================================== + +# ITIL4-Referenz (falls zutreffend): +# itil4_referenz: +# practice: "" +# relevante_elemente: [] +# adaption_fuer_digitom: "" + +# ======================================== +# INHALT +# ======================================== + +# [Inhalt folgt in Phase 6] diff --git a/#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml b/#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml index 18207b7..d6387e4 100644 --- a/#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml +++ b/#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml @@ -1,1136 +1,1136 @@ -# ============================================================================= -# SCHEMA: BEDARFS-STECKBRIEF -# ============================================================================= -# -# Dieses Schema definiert die Struktur eines Bedarfs-Steckbriefs. -# Der Bedarfs-Steckbrief dokumentiert den qualifizierten Bedarf zum -# Übergabezeitpunkt von SHM an DPM (oder SOR für Service-Routing). -# -# Verantwortung: -# - Erstellung: Stakeholder-Management (SHM) -# - Validierung: Stakeholder -# - Empfänger: DPM (nach SOR-Entscheidung) oder SPM (bei Service-Routing) -# -# Abgrenzung: -# - Bedarfs-Steckbrief = SHM-Verantwortung (Vorqualifizierung) -# - Demand-Entscheidungsvorlage = DPM-Verantwortung (Qualifizierung) -# -# Quelle: Konzept_DPM_Abnahme20230925, Seiten 106-112 -# ============================================================================= - -schema: - name: "Bedarfs-Steckbrief" - version: "1.3" - status: "abgenommen" - gueltig_ab: "[Datum]" - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status_dokument: - ueberprueft_durch: "DPM-Teammitglied" - ueberprueft_durch_shm: true - feedback_eingeholt: - - "stichprobenartig in Betrieb" - - "in Abt. Planung" - abgestimmt_zwischen: ["human", "DPM-Teammitglied"] - inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] - abnahmedatum: "17.09.2025" - - zweck: | - Dieser Steckbrief dokumentiert den qualifizierten Bedarf zum - Übergabezeitpunkt. Die detaillierte Analyse erfolgt im DPM-Prozess. - - verantwortung: - erstellung: "Stakeholder-Management (SHM)" - qualitaetssicherung: "Stakeholder-Manager:in" - validierung: "Stakeholder" - freigabe: "Stakeholder + SHM" - - lifecycle_kontext: - phase: "Phase 1 - Initiierung und Erfassung" - erstellt_in: "Schritt 1.5 - Bedarfsklärungsgespräch" - finalisiert_in: "Schritt 1.6 - User Story Erstellung" - uebergabe_in: "Schritt 1.7 - Demand-Übergabe (Quality Gate 1)" - referenz: "demand-lifecycle-blueprint_phase-1.yaml" - -# ============================================================================= -# ABSCHNITT 1: BASISDATEN -# ============================================================================= - -abschnitte: - - basisdaten: - name: "Basisdaten" - beschreibung: "Identifikation und Metadaten des Bedarfs" - - felder: - - id: "bedarfs_id" - name: "Bedarfs-ID" - datentyp: "string" - pflicht: true - quelle: "automatisiert aus Ticketsystem" - beispiel: "BED-2025-0042" - hinweis: "Optimalerweise automatisiert vergeben" - - - id: "bedarfs_titel" - name: "Bedarfs-Titel" - datentyp: "string" - pflicht: true - max_laenge: 100 - beispiel: "Digitalisierung Baugenehmigungsverfahren" - - - id: "kurzbeschreibung" - name: "Kurzbeschreibung des Bedarfs" - datentyp: "text" - pflicht: true - max_laenge: 500 - hinweis: "Prägnante Zusammenfassung in 2-3 Sätzen" - - - id: "eingereicht_von" - name: "Eingereicht von (Stakeholder)" - datentyp: "object" - pflicht: true - struktur: - - feld: "name" - datentyp: "string" - pflicht: true - - feld: "amt" - datentyp: "string" - pflicht: true - - feld: "abteilung" - datentyp: "string" - pflicht: false - - - id: "eingangsdatum" - name: "Eingangsdatum" - datentyp: "date" - format: "tt.mm.jjjj" - pflicht: true - - - id: "bearbeitender_shm" - name: "Bearbeitende:r Stakeholdermanager:in" - datentyp: "string" - pflicht: true - referenz: "shm_rolle" - - - id: "ticket_referenz" - name: "Ticket-Referenz" - datentyp: "url" - pflicht: true - hinweis: "Link zu Ticketsystem" - - - id: "status" - name: "Status" - datentyp: "enum" - pflicht: true - werteliste: - - wert: "in_qualifizierung" - label: "in Qualifizierung" - beschreibung: "SHM arbeitet am Steckbrief" - - wert: "in_so_klaerung" - label: "in Service-Owner-Klärung" - beschreibung: "Routing-Entscheidung Change vs. Demand steht aus – Service Owner klärt bilateral" - - wert: "an_spm_uebergeben" - label: "an Service-Portfolio-Management übergeben" - beschreibung: "Change-Routing entschieden (SO oder direkt SHM)" - - wert: "an_dpm_uebergeben" - label: "an Demand-Portfolio-Management übergeben" - beschreibung: "DSR hat Demand-Routing entschieden" - default: "in_qualifizierung" - - - id: "shm_einschaetzung" - name: "Stakeholdermanagement-Einschätzung / -Anmerkung" - datentyp: "text" - pflicht: true - pflicht_bedingung: "status = 'an_dpm_uebergeben'" - hinweis: "Kurze qualitative Einschätzung: Besonderheiten, Risiken und Empfehlung für DPM" - max_laenge: 1000 - -# ============================================================================= -# ABSCHNITT 1b: STAKEHOLDER-KONTEXT -# ============================================================================= - - stakeholder_kontext: - name: "Stakeholder-Kontext" - beschreibung: "Informationen aus dem Stakeholder-Portfolio (automatisch übernommen)" - - referenz: "shm_schema_amtssteckbrief.yaml" - - felder: - - id: "stakeholder_prioritaet" - name: "Stakeholder-Priorität" - datentyp: "enum" - pflicht: true - quelle: "automatisch aus Amts-Steckbrief" - werteliste: - - wert: "key" - label: "Key" - beschreibung: "Strategisch wichtigste Stakeholder" - - wert: "aktiv" - label: "Aktiv" - beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung" - - wert: "standard" - label: "Standard" - beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf" - - wert: "basis" - label: "Basis" - beschreibung: "Stakeholder mit reaktiver Betreuung" - routing_relevant: false - priorisierung_relevant: true - hinweis: "Beeinflusst Bearbeitungsgeschwindigkeit, nicht Routing-Ziel" - - - id: "it_anforderungsprofil" - name: "IT-Anforderungsprofil" - datentyp: "enum" - pflicht: true - quelle: "automatisch aus Amts-Steckbrief" - werteliste: - - wert: "basis" - label: "Basis" - beschreibung: "Standardbedarf, Grundausstattung reicht" - spm_korrespondenz: "Kategorie A" - - wert: "erweitert" - label: "Erweitert" - beschreibung: "Fachspezifische Bedarfe über Standard hinaus" - spm_korrespondenz: "Kategorie B" - - wert: "spezial" - label: "Spezial" - beschreibung: "Individuelle Bedarfe nur für dieses Amt" - spm_korrespondenz: "Kategorie C" - routing_relevant: false - hinweis: "Gibt Kontext zur typischen Bedarfskomplexität des Stakeholders" - -# ============================================================================= -# ABSCHNITT 2: BEDARFSBESCHREIBUNG -# ============================================================================= - - bedarfsbeschreibung: - name: "Bedarfsbeschreibung" - beschreibung: "Situationsanalyse und Problemdefinition" - - unterabschnitte: - - situationsanalyse: - name: "Situationsanalyse" - - felder: - - id: "ausgangssituation" - name: "Ausgangssituation" - datentyp: "text" - pflicht: true - leitfragen: - - "Wie ist der aktuelle Zustand?" - - "Um was geht es?" - - "Wie funktioniert es heute?" - - - id: "kernproblem" - name: "Kernproblem" - datentyp: "text" - pflicht: true - leitfragen: - - "Was genau funktioniert nicht oder fehlt?" - - "Worin besteht die Herausforderung?" - - - id: "auswirkungen" - name: "Auswirkungen" - datentyp: "text" - pflicht: true - leitfragen: - - "Welche konkreten negativen Effekte entstehen durch das Problem?" - - - id: "zielbild" - name: "Zielbild" - datentyp: "text" - pflicht: true - hinweis: "Kurzfassung: Wie soll die Situation nach der Lösung aussehen?" - -# ============================================================================= -# ABSCHNITT 3: NUTZEN -# ============================================================================= - - nutzen: - name: "Nutzen / Erwarteter Mehrwert / Public Value" - beschreibung: "Erwartete Wertbeiträge des Bedarfs" - - felder: - - id: "primaernutzen" - name: "Primärnutzen" - datentyp: "text" - pflicht: true - beschreibung: "Hauptnutzen für die anfragende Stelle" - - - id: "sekundaernutzen" - name: "Sekundärnutzen" - datentyp: "text" - pflicht: false - beschreibung: "Weitere positive Effekte oder andere Profiteure" - beispiele: - - "Auswirkung auf Mitarbeiterzufriedenheit" - - "Effizienzgewinne in anderen Bereichen" - - - id: "public_value" - name: "Public Value" - datentyp: "text" - pflicht: false - beschreibung: "Nutzen für Bürger:innen oder Gemeinwohl" - hinweis: "Falls relevant" - - - id: "innovationsbeitrag" - name: "Innovationsbeitrag" - datentyp: "object" - pflicht: false - struktur: - - feld: "vorhanden" - datentyp: "boolean" - - feld: "beschreibung" - datentyp: "text" - pflicht_bedingung: "vorhanden = true" - leitfrage: "Welche neuen Möglichkeiten ergeben sich?" - -# ============================================================================= -# ABSCHNITT 4: USER STORIES -# ============================================================================= - - user_stories: - name: "User Stories" - beschreibung: "Dokumentation der Bedarfe aus Nutzerperspektive" - - referenz_leitfaden: - titel: "Leitfaden: User Stories im DIGIT aufnehmen" - pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" - - felder: - - id: "stories" - name: "User Stories" - datentyp: "array" - pflicht: true - min_eintraege: 1 - - element_struktur: - - feld: "rolle" - name: "Als" - datentyp: "string" - pflicht: true - beschreibung: "Rolle/Bereich des Nutzers" - beispiel: "Sachbearbeiter:in Bauamt" - - - feld: "funktionalitaet" - name: "möchte ich" - datentyp: "string" - pflicht: true - beschreibung: "Gewünschte Funktionalität/Lösung" - beispiel: "Bauanträge digital einreichen können" - - - feld: "nutzen" - name: "um" - datentyp: "string" - pflicht: true - beschreibung: "Nutzen/Ziel zu erreichen" - beispiel: "Bearbeitungszeiten zu reduzieren" - -# ============================================================================= -# ABSCHNITT 5: RAHMENBEDINGUNGEN -# ============================================================================= - - rahmenbedingungen: - name: "Rahmenbedingungen" - beschreibung: "Zeitliche und organisatorische Randbedingungen" - - unterabschnitte: - - zeitliche_aspekte: - name: "Zeitliche Aspekte" - - felder: - - id: "harte_deadline" - name: "Harte Deadline" - datentyp: "object" - pflicht: false - struktur: - - feld: "datum" - datentyp: "date" - format: "tt.mm.jjjj" - - feld: "begruendung" - datentyp: "text" - pflicht: true - hinweis: "Erläuterung / Begründung der Deadline" - - - id: "gewuenschter_termin" - name: "Gewünschter Termin" - datentyp: "object" - pflicht: false - struktur: - - feld: "datum" - datentyp: "date" - format: "tt.mm.jjjj" - - feld: "begruendung" - datentyp: "text" - hinweis: "Erläuterung / Begründung" - - - id: "zeitliche_begruendung" - name: "Begründung" - datentyp: "text" - pflicht: false - leitfrage: "Warum diese Einschätzung?" - -# ============================================================================= -# ABSCHNITT 6: ABHÄNGIGKEITEN & CONSTRAINTS -# ============================================================================= - - abhaengigkeiten: - name: "Abhängigkeiten & Constraints/Auflagen" - beschreibung: "Interne und externe Abhängigkeiten, betroffene Systeme" - - unterabschnitte: - - interne_beteiligte: - name: "Interne Beteiligte / Abhängigkeiten" - - felder: - - id: "dx_office_abstimmung" - name: "Abstimmung mit DX-Office erforderlich" - datentyp: "boolean" - pflicht: true - default: false - - - id: "digit_intern_beteiligte" - name: "DIGIT-intern beteiligte/r Bereich/Funktionen" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "bereich" - name: "Name des Bereichs / der Funktion" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Beteiligung / Abhängigkeit" - datentyp: "text" - pflicht: true - - externe_beteiligte: - name: "Externe Beteiligte / externe Abhängigkeiten" - - felder: - - id: "datenschutz_beteiligung" - name: "Beteiligung Datenschutz erforderlich" - datentyp: "boolean" - pflicht: true - default: false - - - id: "stadtkaemmerei_beteiligung" - name: "Beteiligung Stadtkämmerei erforderlich" - datentyp: "boolean" - pflicht: true - default: false - - - id: "digit_externe_aemter" - name: "DIGIT-externe Ämter/Funktionen" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "amt" - name: "Name des Amts / der Funktion" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Beteiligung / Abhängigkeit" - datentyp: "text" - pflicht: true - - - id: "andere_behoerden" - name: "Andere Behörden" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "behoerde" - name: "Name der Behörde" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Beteiligung / Abhängigkeit" - datentyp: "text" - pflicht: true - - - id: "regulatorisch" - name: "Regulatorisch" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "vorgabe" - name: "Bezeichnung der Regulatorischen Vorgabe / Abhängigkeit" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Abhängigkeit / Frist / Vorgabe" - datentyp: "text" - pflicht: true - - - id: "externe_dienstleister" - name: "Externe Dienstleister / Lieferanten" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "dienstleister" - name: "Name des Dienstleisters / Lieferanten" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Beteiligung / Abhängigkeit" - datentyp: "text" - pflicht: true - - - id: "weitere_externe" - name: "Weitere" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "bezeichnung" - name: "Bezeichnung des Beteiligten / der Abhängigkeit" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Beteiligung / Abhängigkeit" - datentyp: "text" - pflicht: true - - betroffene_systeme: - name: "Betroffene Systeme" - - felder: - - id: "systeme" - name: "System / Komponente" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "system" - name: "Name des Systems / der Komponente" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Abhängigkeit / des Zusammenhangs" - datentyp: "text" - pflicht: true - - thematische_abhaengigkeiten: - name: "Thematische Abhängigkeiten" - - felder: - - id: "projekte_themen" - name: "Projekte / Themen" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "projekt" - name: "Name des Projekts / Themas" - datentyp: "string" - pflicht: true - - feld: "erlaeuterung" - name: "Erläuterung der Abhängigkeit / des Zusammenhangs" - datentyp: "text" - pflicht: true - -# ============================================================================= -# ABSCHNITT 7: ERSTE GRÖßENEINSCHÄTZUNG -# ============================================================================= - - groesseneinschaetzung: - name: "Erste Größeneinschätzung" - beschreibung: "Initiale Aufwandsschätzung durch SHM" - - felder: - - id: "geschaetzter_aufwand" - name: "Geschätzter Aufwand" - datentyp: "enum" - pflicht: true - werteliste: - - wert: "gering" - label: "GERING" - beschreibung: "< 20 Personentage" - pt_range: [0, 20] - - wert: "mittel" - label: "MITTEL" - beschreibung: "20-50 Personentage" - pt_range: [20, 50] - - wert: "hoch" - label: "HOCH" - beschreibung: "> 50 Personentage" - pt_range: [50, null] - - wert: "analyse_erforderlich" - label: "Analyse erforderlich" - beschreibung: "Keine belastbare Schätzung möglich" - icon: "?" - - - id: "begruendung_einschaetzung" - name: "Begründung der Einschätzung" - datentyp: "text" - pflicht: true - hinweis: "Kurze Erläuterung der Annahmen" - -# ============================================================================= -# ABSCHNITT 8: LÖSUNGSDISKUSSION -# ============================================================================= - - loesungsdiskussion: - name: "Lösungsdiskussion" - beschreibung: "Dokumentation der Lösungsideen (nicht Bewertung durch SHM)" - - hinweis: | - SHM nimmt Lösungsvorschläge des Stakeholders auf, bewertet aber - nicht technisch. Die technische Bewertung erfolgt durch DPM/SPM. - - felder: - - id: "stakeholder_loesung" - name: "Vom Stakeholder initial vorgeschlagene Lösung" - datentyp: "text" - pflicht: false - hinweis: "Falls eine spezifische Lösung gewünscht wurde" - - - id: "diskutierte_alternativen" - name: "Diskutierte Alternativen" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "alternative" - name: "Beschreibung" - datentyp: "text" - pflicht: true - - feld: "bewertung" - name: "Bewertung" - datentyp: "text" - pflicht: true - hinweis: "Warum (nicht) geeignet?" - - - id: "praeferierte_loesungsrichtung" - name: "Präferierte Lösungsrichtung" - datentyp: "text" - pflicht: false - leitfrage: "Welche Richtung erscheint nach Diskussion am sinnvollsten?" - -# ============================================================================= -# ABSCHNITT 9: FREIGABE ZUR DEMAND-TRANSFORMATION -# ============================================================================= - - freigabe: - name: "Freigabe zur Demand-Transformation" - beschreibung: "Validierung und Freigabe durch Stakeholder" - - unterabschnitte: - - stakeholder_validierung: - name: "Stakeholder-Validierung" - - felder: - - id: "besprochen_am" - name: "Steckbrief mit Stakeholder besprochen am" - datentyp: "date" - format: "tt.mm.jjjj" - pflicht: true - - - id: "aenderungswuensche_eingearbeitet" - name: "Änderungswünsche eingearbeitet" - datentyp: "boolean" - pflicht: true - - - id: "freigabe_erteilt" - name: "Freigabe durch Stakeholder erteilt" - datentyp: "boolean" - pflicht: true - validierung: "Muss 'true' sein für Status-Übergang zu 'bereit_fuer_sor'" - -# ============================================================================= -# ABSCHNITT 10: SERVICE-KATALOG-PRÜFUNG -# ============================================================================= - - service_katalog_pruefung: - name: "Service-Katalog-Prüfung" - beschreibung: "Abgleich mit bestehendem Service-Katalog" - - verantwortung: "SHM mit Unterstützung SPM" - referenz: "demand-lifecycle-blueprint_phase-1.yaml, Schritt 1.4" - - felder: - - id: "pruefergebnis" - name: "Prüfergebnis" - datentyp: "enum" - pflicht: true - werteliste: - - wert: "nicht_abbildbar" - label: "nicht abbildbar durch aktuellen Servicekatalog" - erfordert: "begruendung" - - wert: "teilweise_abbildbar" - label: "teilweise abbildbar durch aktuellen Servicekatalog" - erfordert: "service_referenz" - - wert: "abbildbar" - label: "abbildbar durch aktuellen Servicekatalog" - erfordert: "service_referenz" - hinweis: "Routing in Request Fulfilment (Out of Demand Scope)" - - - id: "begruendung" - name: "Begründung" - datentyp: "text" - pflicht: true - pflicht_bedingung: "pruefergebnis = 'nicht_abbildbar'" - hinweis: "Prägnante Ausformulierung" - - - id: "service_referenz" - name: "Service-Referenz" - datentyp: "string" - pflicht: true - pflicht_bedingung: "pruefergebnis IN ('teilweise_abbildbar', 'abbildbar')" - format: "Service-ID" - beispiel: "SVC-CORE-042" - -# ============================================================================= -# ABSCHNITT 11: ANLAGEN -# ============================================================================= - - anlagen: - name: "Anlagen" - beschreibung: "Ergänzende Dokumente und Materialien" - - felder: - - id: "unterstuetzende_dokumente" - name: "Link zu unterstützenden Dokumenten" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "titel" - datentyp: "string" - - feld: "url" - datentyp: "url" - - - id: "gespraechsprotokolle" - name: "Gesprächsprotokolle" - datentyp: "array" - pflicht: false - element_struktur: - - feld: "titel" - datentyp: "string" - - feld: "datum" - datentyp: "date" - - feld: "url" - datentyp: "url" - - - id: "skizzen_mockups" - name: "Skizzen/Mockups" - datentyp: "array" - pflicht: false - hinweis: "Falls vorhanden" - element_struktur: - - feld: "titel" - datentyp: "string" - - feld: "url" - datentyp: "url" - -# ============================================================================= -# VALIDIERUNGSREGELN -# ============================================================================= - -validierung: - - regeln: - - id: "VAL-BED-001" - name: "Pflichtfelder Basisdaten" - beschreibung: "Alle Pflichtfelder in Basisdaten müssen gefüllt sein" - typ: "formal" - pruefung: "bedarfs_id, bedarfs_titel, kurzbeschreibung, eingereicht_von, eingangsdatum, bearbeitender_shm, ticket_referenz, status sind gefüllt" - - - id: "VAL-BED-002" - name: "SHM-Einschätzung bei DPM-Übergabe" - beschreibung: "Bei Status 'an_dpm_uebergeben' muss SHM-Einschätzung vorhanden sein" - typ: "bedingt" - pruefung: "WENN status = 'an_dpm_uebergeben' DANN shm_einschaetzung ist gefüllt" - - - id: "VAL-BED-003" - name: "Mindestens eine User Story" - beschreibung: "Es muss mindestens eine User Story dokumentiert sein" - typ: "formal" - pruefung: "user_stories.stories.length >= 1" - - - id: "VAL-BED-004" - name: "Stakeholder-Freigabe vor Statuswechsel" - beschreibung: "Freigabe muss erteilt sein für DPM-Übergabe" - typ: "workflow" - pruefung: "WENN status = 'an_dpm_uebergeben' DANN freigabe.freigabe_erteilt = true" - hinweis: | - Freigabe ist nur für DPM-Routing (Quality Gate 1) erforderlich. - Für SOR-Eskalation und SPM-Routing ist keine formale Freigabe nötig. - - - id: "VAL-BED-005" - name: "Service-Katalog-Prüfung vollständig" - beschreibung: "Prüfergebnis muss mit passenden Detailfeldern dokumentiert sein" - typ: "bedingt" - pruefung: | - WENN pruefergebnis = 'nicht_abbildbar' DANN begruendung ist gefüllt - WENN pruefergebnis IN ('teilweise_abbildbar', 'abbildbar') DANN service_referenz ist gefüllt - - - id: "VAL-BED-006" - name: "Aufwandsschätzung mit Begründung" - beschreibung: "Jede Aufwandsschätzung muss begründet werden" - typ: "formal" - pruefung: "geschaetzter_aufwand ist gefüllt UND begruendung_einschaetzung ist gefüllt" - - qualitaetskriterien: - beschreibung: "Qualitative Kriterien für Übergabereife" - - kriterien: - - "Problemverständnis: Kernproblem ist klar vom Symptom getrennt" - - "Stakeholder-Validierung: Steckbrief wurde mit Stakeholder besprochen" - - "User Stories: Mindestens eine User Story nach Standard-Format" - - "Vollständigkeit: Alle relevanten Abhängigkeiten identifiziert" - - "Konsistenz: Zielbild passt zu Problemstellung" - -# ============================================================================= -# VALIDIERUNGSPROFILE NACH ROUTING-PFAD -# ============================================================================= - -validierungsprofile: - - beschreibung: | - Die Pflichtfelder im Bedarfssteckbrief variieren je nach Routing-Ziel. - Nicht jeder Routing-Pfad erfordert einen vollständig ausgefüllten Steckbrief. - - Diese Profile definieren, welche Abschnitte für welchen Routing-Pfad - erforderlich sind. Sie ergänzen die allgemeinen Validierungsregeln. - - referenz: "shm_bedarfsbewertung.yaml" - - profile: - - - routing_id: "ROUTE-REQ" - name: "Request Fulfilment" - status: null - steckbrief_erforderlich: false - beschreibung: | - Bedarf ist durch bestehenden Katalog abbildbar. - Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung - an Service Desk / Request Fulfilment. - - - routing_id: "ROUTE-SPM" - name: "Service Portfolio Management (Change)" - status: "an_spm_uebergeben" - steckbrief_erforderlich: true - beschreibung: | - Bedarf betrifft Änderung an bestehendem Service. - Reduzierter Steckbrief ausreichend. - - erforderliche_abschnitte: - - abschnitt: "basisdaten" - vollstaendig: true - - abschnitt: "stakeholder_kontext" - vollstaendig: true - - abschnitt: "bedarfsbeschreibung" - vollstaendig: false - erforderliche_felder: - - "ausgangssituation" - - "kernproblem" - - abschnitt: "service_katalog_pruefung" - vollstaendig: true - hinweis: "Service-Referenz muss gefüllt sein" - - optionale_abschnitte: - - "user_stories" - - "rahmenbedingungen" - - "abhaengigkeiten" - - "groesseneinschaetzung" - - "loesungsdiskussion" - - "freigabe" - - anzuwendende_validierungsregeln: - - "VAL-BED-001" - - "VAL-BED-005" - - - routing_id: "ROUTE-SO" - name: "Service-Owner-Klärung" - status: "in_so_klaerung" - steckbrief_erforderlich: true - beschreibung: | - Routing unklar – Service Owner klärt bilateral über Zuordnung. - Wenn SO identifizierbar: direkte Klärung. Wenn nicht: SPM hilft - bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. - Steckbrief soweit wie möglich befüllen, aber Vollständigkeit keine Voraussetzung. - referenz: "GOV-SHM-029" - - erforderliche_abschnitte: - - abschnitt: "basisdaten" - vollstaendig: true - zusatz: "shm_einschaetzung muss eigene Einschätzung + Service-Portfolio-Prüfung dokumentieren" - - abschnitt: "stakeholder_kontext" - vollstaendig: true - - abschnitt: "bedarfsbeschreibung" - vollstaendig: false - erforderliche_felder: - - "ausgangssituation" - - "kernproblem" - - abschnitt: "service_katalog_pruefung" - vollstaendig: true - - optionale_abschnitte: - - "user_stories" - - "rahmenbedingungen" - - "abhaengigkeiten" - - "groesseneinschaetzung" - - "loesungsdiskussion" - - "freigabe" - - anzuwendende_validierungsregeln: - - "VAL-BED-001" - - "VAL-BED-005" - - besonderheit: | - Stakeholder-Freigabe (VAL-BED-004) ist für SO-Klärung - NICHT erforderlich – SO kann auch ohne Stakeholder-Freigabe - bilateral angerufen werden, wenn Klärungsbedarf besteht. - - - routing_id: "ROUTE-DPM-INTERN" - name: "Demand Portfolio Management (Intern)" - status: "an_dpm_uebergeben_intern" - steckbrief_erforderlich: true - beschreibung: | - Bedarf von internem DIGIT-Mitarbeiter für neuen Service. - Reduzierter Steckbrief ausreichend (Fast Track). DPM kann bei Bedarf - Nachforderungen über Rückkopplungsschleife stellen. - - erforderliche_abschnitte: - - abschnitt: "basisdaten" - vollstaendig: true - - abschnitt: "stakeholder_kontext" - vollstaendig: false - erforderliche_felder: - - "stakeholder_prioritaet: 'intern'" - hinweis: "Quelle ist intern, daher automatisch mit 'intern' befüllt" - - abschnitt: "bedarfsbeschreibung" - vollstaendig: false - erforderliche_felder: - - "kernproblem" - - "zielbild" - hinweis: "Ausgangssituation und Auswirkungen sind optional" - - abschnitt: "groesseneinschaetzung" - vollstaendig: true - - abschnitt: "shm_einschaetzung" - vollstaendig: true - hinweis: "2-3 Sätze ausreichend. Siehe shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern" - - abschnitt: "service_katalog_pruefung" - vollstaendig: true - - optionale_abschnitte: - - "user_stories" - - "nutzen" - - "rahmenbedingungen" - - "abhaengigkeiten" - - "loesungsdiskussion" - - "freigabe" - - "anlagen" - - anzuwendende_validierungsregeln: - - "VAL-BED-001" - - "VAL-BED-005" - - besonderheit: | - Stakeholder-Freigabe (VAL-BED-004) ist für interne Demands NICHT - erforderlich. DPM kann über Rückkopplungsschleife (shm_d2p-integration.yaml) - Nachforderungen stellen, wenn für Klassifizierung zusätzliche - Informationen benötigt werden. - - qualitaetssicherung: | - SHM Fast Track Validation (10-15min) ist Quality Gate 1. - DPM Quality Gate 2 prüft Klassifizierbarkeit und kann bei Bedarf - zurückweisen. - - - routing_id: "ROUTE-DPM" - name: "Demand Portfolio Management (Extern)" - status: "an_dpm_uebergeben" - steckbrief_erforderlich: true - beschreibung: | - Bedarf von externem Stakeholder (anderes Amt, Bürger, Politik) - erfordert neuen Service oder grundlegende Neugestaltung. - Vollständiger Steckbrief erforderlich für Quality Gate 1. - - erforderliche_abschnitte: - - abschnitt: "basisdaten" - vollstaendig: true - - abschnitt: "stakeholder_kontext" - vollstaendig: true - - abschnitt: "bedarfsbeschreibung" - vollstaendig: true - - abschnitt: "user_stories" - vollstaendig: true - hinweis: "Mindestens eine User Story nach Standard-Format" - - abschnitt: "rahmenbedingungen" - vollstaendig: false - erforderliche_felder: [] - hinweis: "Harte Deadline oder gewünschter Termin falls relevant" - - abschnitt: "abhaengigkeiten" - vollstaendig: true - - abschnitt: "groesseneinschaetzung" - vollstaendig: true - - abschnitt: "service_katalog_pruefung" - vollstaendig: true - - abschnitt: "freigabe" - vollstaendig: true - hinweis: "Stakeholder-Freigabe erforderlich" - - optionale_abschnitte: - - "loesungsdiskussion" - - "anlagen" - - anzuwendende_validierungsregeln: - - "VAL-BED-001" - - "VAL-BED-002" - - "VAL-BED-003" - - "VAL-BED-004" - - "VAL-BED-005" - - "VAL-BED-006" - -# ============================================================================= -# SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - - eingang: - beschreibung: "Quellen für die Steckbrief-Erstellung" - quellen: - - quelle: "Stakeholder" - artefakt: "Bedarfsmeldung (unqualifiziert)" - kanal: "Ticketsystem / direkte Ansprache" - - - quelle: "Bedarfsklärungsgespräch" - artefakt: "Protokollierte Anforderungen" - - ausgang: - beschreibung: "Übergabe des finalen Steckbriefs" - ziele: - - ziel: "Service Owner (SO)" - artefakt: "Bedarfs-Steckbrief (Final)" - zweck: "Routing-Entscheidung Change vs. Demand" - status_nach_uebergabe: "in_so_klaerung" - - - ziel: "DPM (externer Bedarf)" - artefakt: "Bedarfs-Steckbrief (Final)" - zweck: "Demand-Qualifizierung" - status_nach_uebergabe: "an_dpm_uebergeben" - bedingung: "Externer Stakeholder-Bedarf, Routing-Entscheidung = ROUTE-DPM" - - - ziel: "DPM (interner Fast-Track-Bedarf)" - artefakt: "Bedarfs-Steckbrief (Reduziert, Profil ROUTE-DPM-INTERN)" - zweck: "Demand-Qualifizierung interner Bedarf" - status_nach_uebergabe: "an_dpm_uebergeben_intern" - bedingung: "DIGIT-Mitarbeiter als Nutzer, Routing-Entscheidung = ROUTE-DPM-INTERN" - hinweis: "Reduzierter Steckbrief, DPM kann über Rückkopplungsschleife nachfordern" - - - ziel: "SPM" - artefakt: "Bedarfs-Steckbrief (Final)" - zweck: "Change an bestehendem Service" - status_nach_uebergabe: "an_spm_uebergeben" - bedingung: "DSR-Entscheidung = Change" - -# ============================================================================= -# REFERENZEN -# ============================================================================= - -referenzen: - - prozess_kontext: - - titel: "Demand-Lifecycle-Blueprint Phase 1" - pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml" - relevanz: "Prozesskontext für Steckbrief-Erstellung" - - - titel: "SHM Engagement-Framework" - pfad: "#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml" - relevanz: "Formate für Bedarfserhebung" - - verwandte_schemas: - - titel: "Amts-Steckbrief Schema" - pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_amtssteckbrief.yaml" - relevanz: "Stakeholder-Stammdaten" - - - titel: "Service-Steckbrief Schema" - pfad: "#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml" - relevanz: "Analoges Schema im SPM-Kontext" - - arbeitsmaterialien: - - titel: "Leitfaden User Stories" - pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" - hinweis: "Referenziert im PDF auf Seite 108" - - - titel: "Template Bedarfs-Steckbrief" - pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_template_bedarfssteckbrief.md" - status: "abzuleiten aus diesem Schema" - - methodik_referenz: - - dokument: "shm_bedarfsbewertung.yaml" - pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" - beschreibung: "Routing-Logik und Entscheidungsbaum für Bedarfsbewertung" - - dokument: "shm_stakeholder-portfolio.yaml" - pfad: "#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml" - beschreibung: "Stakeholder-Priorisierung und IT-Anforderungsprofil" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-BED-001" - beschreibung: "Template (Markdown) aus Schema ableiten" - prioritaet: "hoch" - ziel_ordner: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" - - - id: "OPEN-BED-002" - beschreibung: "Leitfaden User Stories erstellen" - prioritaet: "mittel" - referenz: "PDF Seite 108" - - - id: "OPEN-BED-003" - beschreibung: "ITSM-Tool-Mapping definieren" - prioritaet: "niedrig" - hinweis: "Wie wird der Steckbrief im Ticketsystem abgebildet?" - - - id: "OPEN-BED-004" - beschreibung: "Abstimmung SOR-Integration" - prioritaet: "mittel" - hinweis: "SOR-Prozess noch nicht vollständig modelliert" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.1" - datum: "2025-12-09" - aenderung: | - - Neuer Abschnitt: stakeholder_kontext (Integration Stakeholder-Portfolio) - - Neuer Abschnitt: validierungsprofile (Routing-basierte Pflichtfelder) - - Update: referenz_leitfaden auf YAML-Pfad - - Update: VAL-BED-004 präzisiert (nur DPM erfordert Freigabe) - - Neue Methodik-Referenzen ergänzt - autor: "DIGITOM-Projekt" - quelle: "SHM Phase 3 – Bedarfsbewertung" - - - version: "1.3" - datum: "2026-03-07" - aenderung: | - - Schnittstellen.ausgang: DPM-Eintrag aufgeteilt in zwei Ziele - (externer Bedarf ROUTE-DPM / interner Fast-Track ROUTE-DPM-INTERN) - - Status "an_dpm_uebergeben_intern" in Ausgangs-Übersicht ergänzt - - Bedingungsformulierung bei DPM-extern auf ROUTE-DPM-Terminologie präzisiert - autor: "DIGITOM-Projekt" - quelle: "Lückenanalyse Bedarfsrouting 2026-03-07" - - - version: "1.2" - datum: "2026-01-22" - aenderung: | - - Neues Validierungsprofil: ROUTE-DPM-INTERN - - Reduzierte Pflichtfelder für interne DIGIT-Bedarfe - - Status: "an_dpm_uebergeben_intern" - - Hinweis auf DPM Rückkopplungsschleife bei Nachforderungen - - Umbenennung bestehendes Profil: ROUTE-DPM → ROUTE-DPM (Extern) zur Klarheit - autor: "DIGITOM-Projekt" - quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe" - - - version: "1.0" - datum: "2025-12-09" - aenderung: "Initiale Schema-Erstellung aus PDF-Template" - autor: "DIGITOM-Projekt" +# ============================================================================= +# SCHEMA: BEDARFS-STECKBRIEF +# ============================================================================= +# +# Dieses Schema definiert die Struktur eines Bedarfs-Steckbriefs. +# Der Bedarfs-Steckbrief dokumentiert den qualifizierten Bedarf zum +# Übergabezeitpunkt von SHM an DPM (oder SOR für Service-Routing). +# +# Verantwortung: +# - Erstellung: Stakeholder-Management (SHM) +# - Validierung: Stakeholder +# - Empfänger: DPM (nach SOR-Entscheidung) oder SPM (bei Service-Routing) +# +# Abgrenzung: +# - Bedarfs-Steckbrief = SHM-Verantwortung (Vorqualifizierung) +# - Demand-Entscheidungsvorlage = DPM-Verantwortung (Qualifizierung) +# +# Quelle: Konzept_DPM_Abnahme20230925, Seiten 106-112 +# ============================================================================= + +schema: + name: "Bedarfs-Steckbrief" + version: "1.3" + status: "abgenommen" + gueltig_ab: "[Datum]" + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status_dokument: + ueberprueft_durch: "DPM-Teammitglied" + ueberprueft_durch_shm: true + feedback_eingeholt: + - "stichprobenartig in Betrieb" + - "in Abt. Planung" + abgestimmt_zwischen: ["human", "DPM-Teammitglied"] + inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] + abnahmedatum: "17.09.2025" + + zweck: | + Dieser Steckbrief dokumentiert den qualifizierten Bedarf zum + Übergabezeitpunkt. Die detaillierte Analyse erfolgt im DPM-Prozess. + + verantwortung: + erstellung: "Stakeholder-Management (SHM)" + qualitaetssicherung: "Stakeholder-Manager:in" + validierung: "Stakeholder" + freigabe: "Stakeholder + SHM" + + lifecycle_kontext: + phase: "Phase 1 - Initiierung und Erfassung" + erstellt_in: "Schritt 1.5 - Bedarfsklärungsgespräch" + finalisiert_in: "Schritt 1.6 - User Story Erstellung" + uebergabe_in: "Schritt 1.7 - Demand-Übergabe (Quality Gate 1)" + referenz: "demand-lifecycle-blueprint_phase-1.yaml" + +# ============================================================================= +# ABSCHNITT 1: BASISDATEN +# ============================================================================= + +abschnitte: + + basisdaten: + name: "Basisdaten" + beschreibung: "Identifikation und Metadaten des Bedarfs" + + felder: + - id: "bedarfs_id" + name: "Bedarfs-ID" + datentyp: "string" + pflicht: true + quelle: "automatisiert aus Ticketsystem" + beispiel: "BED-2025-0042" + hinweis: "Optimalerweise automatisiert vergeben" + + - id: "bedarfs_titel" + name: "Bedarfs-Titel" + datentyp: "string" + pflicht: true + max_laenge: 100 + beispiel: "Digitalisierung Baugenehmigungsverfahren" + + - id: "kurzbeschreibung" + name: "Kurzbeschreibung des Bedarfs" + datentyp: "text" + pflicht: true + max_laenge: 500 + hinweis: "Prägnante Zusammenfassung in 2-3 Sätzen" + + - id: "eingereicht_von" + name: "Eingereicht von (Stakeholder)" + datentyp: "object" + pflicht: true + struktur: + - feld: "name" + datentyp: "string" + pflicht: true + - feld: "amt" + datentyp: "string" + pflicht: true + - feld: "abteilung" + datentyp: "string" + pflicht: false + + - id: "eingangsdatum" + name: "Eingangsdatum" + datentyp: "date" + format: "tt.mm.jjjj" + pflicht: true + + - id: "bearbeitender_shm" + name: "Bearbeitende:r Stakeholdermanager:in" + datentyp: "string" + pflicht: true + referenz: "shm_rolle" + + - id: "ticket_referenz" + name: "Ticket-Referenz" + datentyp: "url" + pflicht: true + hinweis: "Link zu Ticketsystem" + + - id: "status" + name: "Status" + datentyp: "enum" + pflicht: true + werteliste: + - wert: "in_qualifizierung" + label: "in Qualifizierung" + beschreibung: "SHM arbeitet am Steckbrief" + - wert: "in_so_klaerung" + label: "in Service-Owner-Klärung" + beschreibung: "Routing-Entscheidung Change vs. Demand steht aus – Service Owner klärt bilateral" + - wert: "an_spm_uebergeben" + label: "an Service-Portfolio-Management übergeben" + beschreibung: "Change-Routing entschieden (SO oder direkt SHM)" + - wert: "an_dpm_uebergeben" + label: "an Demand-Portfolio-Management übergeben" + beschreibung: "DSR hat Demand-Routing entschieden" + default: "in_qualifizierung" + + - id: "shm_einschaetzung" + name: "Stakeholdermanagement-Einschätzung / -Anmerkung" + datentyp: "text" + pflicht: true + pflicht_bedingung: "status = 'an_dpm_uebergeben'" + hinweis: "Kurze qualitative Einschätzung: Besonderheiten, Risiken und Empfehlung für DPM" + max_laenge: 1000 + +# ============================================================================= +# ABSCHNITT 1b: STAKEHOLDER-KONTEXT +# ============================================================================= + + stakeholder_kontext: + name: "Stakeholder-Kontext" + beschreibung: "Informationen aus dem Stakeholder-Portfolio (automatisch übernommen)" + + referenz: "shm_schema_amtssteckbrief.yaml" + + felder: + - id: "stakeholder_prioritaet" + name: "Stakeholder-Priorität" + datentyp: "enum" + pflicht: true + quelle: "automatisch aus Amts-Steckbrief" + werteliste: + - wert: "key" + label: "Key" + beschreibung: "Strategisch wichtigste Stakeholder" + - wert: "aktiv" + label: "Aktiv" + beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung" + - wert: "standard" + label: "Standard" + beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf" + - wert: "basis" + label: "Basis" + beschreibung: "Stakeholder mit reaktiver Betreuung" + routing_relevant: false + priorisierung_relevant: true + hinweis: "Beeinflusst Bearbeitungsgeschwindigkeit, nicht Routing-Ziel" + + - id: "it_anforderungsprofil" + name: "IT-Anforderungsprofil" + datentyp: "enum" + pflicht: true + quelle: "automatisch aus Amts-Steckbrief" + werteliste: + - wert: "basis" + label: "Basis" + beschreibung: "Standardbedarf, Grundausstattung reicht" + spm_korrespondenz: "Kategorie A" + - wert: "erweitert" + label: "Erweitert" + beschreibung: "Fachspezifische Bedarfe über Standard hinaus" + spm_korrespondenz: "Kategorie B" + - wert: "spezial" + label: "Spezial" + beschreibung: "Individuelle Bedarfe nur für dieses Amt" + spm_korrespondenz: "Kategorie C" + routing_relevant: false + hinweis: "Gibt Kontext zur typischen Bedarfskomplexität des Stakeholders" + +# ============================================================================= +# ABSCHNITT 2: BEDARFSBESCHREIBUNG +# ============================================================================= + + bedarfsbeschreibung: + name: "Bedarfsbeschreibung" + beschreibung: "Situationsanalyse und Problemdefinition" + + unterabschnitte: + + situationsanalyse: + name: "Situationsanalyse" + + felder: + - id: "ausgangssituation" + name: "Ausgangssituation" + datentyp: "text" + pflicht: true + leitfragen: + - "Wie ist der aktuelle Zustand?" + - "Um was geht es?" + - "Wie funktioniert es heute?" + + - id: "kernproblem" + name: "Kernproblem" + datentyp: "text" + pflicht: true + leitfragen: + - "Was genau funktioniert nicht oder fehlt?" + - "Worin besteht die Herausforderung?" + + - id: "auswirkungen" + name: "Auswirkungen" + datentyp: "text" + pflicht: true + leitfragen: + - "Welche konkreten negativen Effekte entstehen durch das Problem?" + + - id: "zielbild" + name: "Zielbild" + datentyp: "text" + pflicht: true + hinweis: "Kurzfassung: Wie soll die Situation nach der Lösung aussehen?" + +# ============================================================================= +# ABSCHNITT 3: NUTZEN +# ============================================================================= + + nutzen: + name: "Nutzen / Erwarteter Mehrwert / Public Value" + beschreibung: "Erwartete Wertbeiträge des Bedarfs" + + felder: + - id: "primaernutzen" + name: "Primärnutzen" + datentyp: "text" + pflicht: true + beschreibung: "Hauptnutzen für die anfragende Stelle" + + - id: "sekundaernutzen" + name: "Sekundärnutzen" + datentyp: "text" + pflicht: false + beschreibung: "Weitere positive Effekte oder andere Profiteure" + beispiele: + - "Auswirkung auf Mitarbeiterzufriedenheit" + - "Effizienzgewinne in anderen Bereichen" + + - id: "public_value" + name: "Public Value" + datentyp: "text" + pflicht: false + beschreibung: "Nutzen für Bürger:innen oder Gemeinwohl" + hinweis: "Falls relevant" + + - id: "innovationsbeitrag" + name: "Innovationsbeitrag" + datentyp: "object" + pflicht: false + struktur: + - feld: "vorhanden" + datentyp: "boolean" + - feld: "beschreibung" + datentyp: "text" + pflicht_bedingung: "vorhanden = true" + leitfrage: "Welche neuen Möglichkeiten ergeben sich?" + +# ============================================================================= +# ABSCHNITT 4: USER STORIES +# ============================================================================= + + user_stories: + name: "User Stories" + beschreibung: "Dokumentation der Bedarfe aus Nutzerperspektive" + + referenz_leitfaden: + titel: "Leitfaden: User Stories im DIGIT aufnehmen" + pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" + + felder: + - id: "stories" + name: "User Stories" + datentyp: "array" + pflicht: true + min_eintraege: 1 + + element_struktur: + - feld: "rolle" + name: "Als" + datentyp: "string" + pflicht: true + beschreibung: "Rolle/Bereich des Nutzers" + beispiel: "Sachbearbeiter:in Bauamt" + + - feld: "funktionalitaet" + name: "möchte ich" + datentyp: "string" + pflicht: true + beschreibung: "Gewünschte Funktionalität/Lösung" + beispiel: "Bauanträge digital einreichen können" + + - feld: "nutzen" + name: "um" + datentyp: "string" + pflicht: true + beschreibung: "Nutzen/Ziel zu erreichen" + beispiel: "Bearbeitungszeiten zu reduzieren" + +# ============================================================================= +# ABSCHNITT 5: RAHMENBEDINGUNGEN +# ============================================================================= + + rahmenbedingungen: + name: "Rahmenbedingungen" + beschreibung: "Zeitliche und organisatorische Randbedingungen" + + unterabschnitte: + + zeitliche_aspekte: + name: "Zeitliche Aspekte" + + felder: + - id: "harte_deadline" + name: "Harte Deadline" + datentyp: "object" + pflicht: false + struktur: + - feld: "datum" + datentyp: "date" + format: "tt.mm.jjjj" + - feld: "begruendung" + datentyp: "text" + pflicht: true + hinweis: "Erläuterung / Begründung der Deadline" + + - id: "gewuenschter_termin" + name: "Gewünschter Termin" + datentyp: "object" + pflicht: false + struktur: + - feld: "datum" + datentyp: "date" + format: "tt.mm.jjjj" + - feld: "begruendung" + datentyp: "text" + hinweis: "Erläuterung / Begründung" + + - id: "zeitliche_begruendung" + name: "Begründung" + datentyp: "text" + pflicht: false + leitfrage: "Warum diese Einschätzung?" + +# ============================================================================= +# ABSCHNITT 6: ABHÄNGIGKEITEN & CONSTRAINTS +# ============================================================================= + + abhaengigkeiten: + name: "Abhängigkeiten & Constraints/Auflagen" + beschreibung: "Interne und externe Abhängigkeiten, betroffene Systeme" + + unterabschnitte: + + interne_beteiligte: + name: "Interne Beteiligte / Abhängigkeiten" + + felder: + - id: "dx_office_abstimmung" + name: "Abstimmung mit DX-Office erforderlich" + datentyp: "boolean" + pflicht: true + default: false + + - id: "digit_intern_beteiligte" + name: "DIGIT-intern beteiligte/r Bereich/Funktionen" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "bereich" + name: "Name des Bereichs / der Funktion" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Beteiligung / Abhängigkeit" + datentyp: "text" + pflicht: true + + externe_beteiligte: + name: "Externe Beteiligte / externe Abhängigkeiten" + + felder: + - id: "datenschutz_beteiligung" + name: "Beteiligung Datenschutz erforderlich" + datentyp: "boolean" + pflicht: true + default: false + + - id: "stadtkaemmerei_beteiligung" + name: "Beteiligung Stadtkämmerei erforderlich" + datentyp: "boolean" + pflicht: true + default: false + + - id: "digit_externe_aemter" + name: "DIGIT-externe Ämter/Funktionen" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "amt" + name: "Name des Amts / der Funktion" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Beteiligung / Abhängigkeit" + datentyp: "text" + pflicht: true + + - id: "andere_behoerden" + name: "Andere Behörden" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "behoerde" + name: "Name der Behörde" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Beteiligung / Abhängigkeit" + datentyp: "text" + pflicht: true + + - id: "regulatorisch" + name: "Regulatorisch" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "vorgabe" + name: "Bezeichnung der Regulatorischen Vorgabe / Abhängigkeit" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Abhängigkeit / Frist / Vorgabe" + datentyp: "text" + pflicht: true + + - id: "externe_dienstleister" + name: "Externe Dienstleister / Lieferanten" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "dienstleister" + name: "Name des Dienstleisters / Lieferanten" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Beteiligung / Abhängigkeit" + datentyp: "text" + pflicht: true + + - id: "weitere_externe" + name: "Weitere" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "bezeichnung" + name: "Bezeichnung des Beteiligten / der Abhängigkeit" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Beteiligung / Abhängigkeit" + datentyp: "text" + pflicht: true + + betroffene_systeme: + name: "Betroffene Systeme" + + felder: + - id: "systeme" + name: "System / Komponente" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "system" + name: "Name des Systems / der Komponente" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Abhängigkeit / des Zusammenhangs" + datentyp: "text" + pflicht: true + + thematische_abhaengigkeiten: + name: "Thematische Abhängigkeiten" + + felder: + - id: "projekte_themen" + name: "Projekte / Themen" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "projekt" + name: "Name des Projekts / Themas" + datentyp: "string" + pflicht: true + - feld: "erlaeuterung" + name: "Erläuterung der Abhängigkeit / des Zusammenhangs" + datentyp: "text" + pflicht: true + +# ============================================================================= +# ABSCHNITT 7: ERSTE GRÖßENEINSCHÄTZUNG +# ============================================================================= + + groesseneinschaetzung: + name: "Erste Größeneinschätzung" + beschreibung: "Initiale Aufwandsschätzung durch SHM" + + felder: + - id: "geschaetzter_aufwand" + name: "Geschätzter Aufwand" + datentyp: "enum" + pflicht: true + werteliste: + - wert: "gering" + label: "GERING" + beschreibung: "< 20 Personentage" + pt_range: [0, 20] + - wert: "mittel" + label: "MITTEL" + beschreibung: "20-50 Personentage" + pt_range: [20, 50] + - wert: "hoch" + label: "HOCH" + beschreibung: "> 50 Personentage" + pt_range: [50, null] + - wert: "analyse_erforderlich" + label: "Analyse erforderlich" + beschreibung: "Keine belastbare Schätzung möglich" + icon: "?" + + - id: "begruendung_einschaetzung" + name: "Begründung der Einschätzung" + datentyp: "text" + pflicht: true + hinweis: "Kurze Erläuterung der Annahmen" + +# ============================================================================= +# ABSCHNITT 8: LÖSUNGSDISKUSSION +# ============================================================================= + + loesungsdiskussion: + name: "Lösungsdiskussion" + beschreibung: "Dokumentation der Lösungsideen (nicht Bewertung durch SHM)" + + hinweis: | + SHM nimmt Lösungsvorschläge des Stakeholders auf, bewertet aber + nicht technisch. Die technische Bewertung erfolgt durch DPM/SPM. + + felder: + - id: "stakeholder_loesung" + name: "Vom Stakeholder initial vorgeschlagene Lösung" + datentyp: "text" + pflicht: false + hinweis: "Falls eine spezifische Lösung gewünscht wurde" + + - id: "diskutierte_alternativen" + name: "Diskutierte Alternativen" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "alternative" + name: "Beschreibung" + datentyp: "text" + pflicht: true + - feld: "bewertung" + name: "Bewertung" + datentyp: "text" + pflicht: true + hinweis: "Warum (nicht) geeignet?" + + - id: "praeferierte_loesungsrichtung" + name: "Präferierte Lösungsrichtung" + datentyp: "text" + pflicht: false + leitfrage: "Welche Richtung erscheint nach Diskussion am sinnvollsten?" + +# ============================================================================= +# ABSCHNITT 9: FREIGABE ZUR DEMAND-TRANSFORMATION +# ============================================================================= + + freigabe: + name: "Freigabe zur Demand-Transformation" + beschreibung: "Validierung und Freigabe durch Stakeholder" + + unterabschnitte: + + stakeholder_validierung: + name: "Stakeholder-Validierung" + + felder: + - id: "besprochen_am" + name: "Steckbrief mit Stakeholder besprochen am" + datentyp: "date" + format: "tt.mm.jjjj" + pflicht: true + + - id: "aenderungswuensche_eingearbeitet" + name: "Änderungswünsche eingearbeitet" + datentyp: "boolean" + pflicht: true + + - id: "freigabe_erteilt" + name: "Freigabe durch Stakeholder erteilt" + datentyp: "boolean" + pflicht: true + validierung: "Muss 'true' sein für Status-Übergang zu 'bereit_fuer_sor'" + +# ============================================================================= +# ABSCHNITT 10: SERVICE-KATALOG-PRÜFUNG +# ============================================================================= + + service_katalog_pruefung: + name: "Service-Katalog-Prüfung" + beschreibung: "Abgleich mit bestehendem Service-Katalog" + + verantwortung: "SHM mit Unterstützung SPM" + referenz: "demand-lifecycle-blueprint_phase-1.yaml, Schritt 1.4" + + felder: + - id: "pruefergebnis" + name: "Prüfergebnis" + datentyp: "enum" + pflicht: true + werteliste: + - wert: "nicht_abbildbar" + label: "nicht abbildbar durch aktuellen Servicekatalog" + erfordert: "begruendung" + - wert: "teilweise_abbildbar" + label: "teilweise abbildbar durch aktuellen Servicekatalog" + erfordert: "service_referenz" + - wert: "abbildbar" + label: "abbildbar durch aktuellen Servicekatalog" + erfordert: "service_referenz" + hinweis: "Routing in Request Fulfilment (Out of Demand Scope)" + + - id: "begruendung" + name: "Begründung" + datentyp: "text" + pflicht: true + pflicht_bedingung: "pruefergebnis = 'nicht_abbildbar'" + hinweis: "Prägnante Ausformulierung" + + - id: "service_referenz" + name: "Service-Referenz" + datentyp: "string" + pflicht: true + pflicht_bedingung: "pruefergebnis IN ('teilweise_abbildbar', 'abbildbar')" + format: "Service-ID" + beispiel: "SVC-CORE-042" + +# ============================================================================= +# ABSCHNITT 11: ANLAGEN +# ============================================================================= + + anlagen: + name: "Anlagen" + beschreibung: "Ergänzende Dokumente und Materialien" + + felder: + - id: "unterstuetzende_dokumente" + name: "Link zu unterstützenden Dokumenten" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "titel" + datentyp: "string" + - feld: "url" + datentyp: "url" + + - id: "gespraechsprotokolle" + name: "Gesprächsprotokolle" + datentyp: "array" + pflicht: false + element_struktur: + - feld: "titel" + datentyp: "string" + - feld: "datum" + datentyp: "date" + - feld: "url" + datentyp: "url" + + - id: "skizzen_mockups" + name: "Skizzen/Mockups" + datentyp: "array" + pflicht: false + hinweis: "Falls vorhanden" + element_struktur: + - feld: "titel" + datentyp: "string" + - feld: "url" + datentyp: "url" + +# ============================================================================= +# VALIDIERUNGSREGELN +# ============================================================================= + +validierung: + + regeln: + - id: "VAL-BED-001" + name: "Pflichtfelder Basisdaten" + beschreibung: "Alle Pflichtfelder in Basisdaten müssen gefüllt sein" + typ: "formal" + pruefung: "bedarfs_id, bedarfs_titel, kurzbeschreibung, eingereicht_von, eingangsdatum, bearbeitender_shm, ticket_referenz, status sind gefüllt" + + - id: "VAL-BED-002" + name: "SHM-Einschätzung bei DPM-Übergabe" + beschreibung: "Bei Status 'an_dpm_uebergeben' muss SHM-Einschätzung vorhanden sein" + typ: "bedingt" + pruefung: "WENN status = 'an_dpm_uebergeben' DANN shm_einschaetzung ist gefüllt" + + - id: "VAL-BED-003" + name: "Mindestens eine User Story" + beschreibung: "Es muss mindestens eine User Story dokumentiert sein" + typ: "formal" + pruefung: "user_stories.stories.length >= 1" + + - id: "VAL-BED-004" + name: "Stakeholder-Freigabe vor Statuswechsel" + beschreibung: "Freigabe muss erteilt sein für DPM-Übergabe" + typ: "workflow" + pruefung: "WENN status = 'an_dpm_uebergeben' DANN freigabe.freigabe_erteilt = true" + hinweis: | + Freigabe ist nur für DPM-Routing (Quality Gate 1) erforderlich. + Für SOR-Eskalation und SPM-Routing ist keine formale Freigabe nötig. + + - id: "VAL-BED-005" + name: "Service-Katalog-Prüfung vollständig" + beschreibung: "Prüfergebnis muss mit passenden Detailfeldern dokumentiert sein" + typ: "bedingt" + pruefung: | + WENN pruefergebnis = 'nicht_abbildbar' DANN begruendung ist gefüllt + WENN pruefergebnis IN ('teilweise_abbildbar', 'abbildbar') DANN service_referenz ist gefüllt + + - id: "VAL-BED-006" + name: "Aufwandsschätzung mit Begründung" + beschreibung: "Jede Aufwandsschätzung muss begründet werden" + typ: "formal" + pruefung: "geschaetzter_aufwand ist gefüllt UND begruendung_einschaetzung ist gefüllt" + + qualitaetskriterien: + beschreibung: "Qualitative Kriterien für Übergabereife" + + kriterien: + - "Problemverständnis: Kernproblem ist klar vom Symptom getrennt" + - "Stakeholder-Validierung: Steckbrief wurde mit Stakeholder besprochen" + - "User Stories: Mindestens eine User Story nach Standard-Format" + - "Vollständigkeit: Alle relevanten Abhängigkeiten identifiziert" + - "Konsistenz: Zielbild passt zu Problemstellung" + +# ============================================================================= +# VALIDIERUNGSPROFILE NACH ROUTING-PFAD +# ============================================================================= + +validierungsprofile: + + beschreibung: | + Die Pflichtfelder im Bedarfssteckbrief variieren je nach Routing-Ziel. + Nicht jeder Routing-Pfad erfordert einen vollständig ausgefüllten Steckbrief. + + Diese Profile definieren, welche Abschnitte für welchen Routing-Pfad + erforderlich sind. Sie ergänzen die allgemeinen Validierungsregeln. + + referenz: "shm_bedarfsbewertung.yaml" + + profile: + + - routing_id: "ROUTE-REQ" + name: "Request Fulfilment" + status: null + steckbrief_erforderlich: false + beschreibung: | + Bedarf ist durch bestehenden Katalog abbildbar. + Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung + an Service Desk / Request Fulfilment. + + - routing_id: "ROUTE-SPM" + name: "Service Portfolio Management (Change)" + status: "an_spm_uebergeben" + steckbrief_erforderlich: true + beschreibung: | + Bedarf betrifft Änderung an bestehendem Service. + Reduzierter Steckbrief ausreichend. + + erforderliche_abschnitte: + - abschnitt: "basisdaten" + vollstaendig: true + - abschnitt: "stakeholder_kontext" + vollstaendig: true + - abschnitt: "bedarfsbeschreibung" + vollstaendig: false + erforderliche_felder: + - "ausgangssituation" + - "kernproblem" + - abschnitt: "service_katalog_pruefung" + vollstaendig: true + hinweis: "Service-Referenz muss gefüllt sein" + + optionale_abschnitte: + - "user_stories" + - "rahmenbedingungen" + - "abhaengigkeiten" + - "groesseneinschaetzung" + - "loesungsdiskussion" + - "freigabe" + + anzuwendende_validierungsregeln: + - "VAL-BED-001" + - "VAL-BED-005" + + - routing_id: "ROUTE-SO" + name: "Service-Owner-Klärung" + status: "in_so_klaerung" + steckbrief_erforderlich: true + beschreibung: | + Routing unklar – Service Owner klärt bilateral über Zuordnung. + Wenn SO identifizierbar: direkte Klärung. Wenn nicht: SPM hilft + bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. + Steckbrief soweit wie möglich befüllen, aber Vollständigkeit keine Voraussetzung. + referenz: "GOV-SHM-029" + + erforderliche_abschnitte: + - abschnitt: "basisdaten" + vollstaendig: true + zusatz: "shm_einschaetzung muss eigene Einschätzung + Service-Portfolio-Prüfung dokumentieren" + - abschnitt: "stakeholder_kontext" + vollstaendig: true + - abschnitt: "bedarfsbeschreibung" + vollstaendig: false + erforderliche_felder: + - "ausgangssituation" + - "kernproblem" + - abschnitt: "service_katalog_pruefung" + vollstaendig: true + + optionale_abschnitte: + - "user_stories" + - "rahmenbedingungen" + - "abhaengigkeiten" + - "groesseneinschaetzung" + - "loesungsdiskussion" + - "freigabe" + + anzuwendende_validierungsregeln: + - "VAL-BED-001" + - "VAL-BED-005" + + besonderheit: | + Stakeholder-Freigabe (VAL-BED-004) ist für SO-Klärung + NICHT erforderlich – SO kann auch ohne Stakeholder-Freigabe + bilateral angerufen werden, wenn Klärungsbedarf besteht. + + - routing_id: "ROUTE-DPM-INTERN" + name: "Demand Portfolio Management (Intern)" + status: "an_dpm_uebergeben_intern" + steckbrief_erforderlich: true + beschreibung: | + Bedarf von internem DIGIT-Mitarbeiter für neuen Service. + Reduzierter Steckbrief ausreichend (Fast Track). DPM kann bei Bedarf + Nachforderungen über Rückkopplungsschleife stellen. + + erforderliche_abschnitte: + - abschnitt: "basisdaten" + vollstaendig: true + - abschnitt: "stakeholder_kontext" + vollstaendig: false + erforderliche_felder: + - "stakeholder_prioritaet: 'intern'" + hinweis: "Quelle ist intern, daher automatisch mit 'intern' befüllt" + - abschnitt: "bedarfsbeschreibung" + vollstaendig: false + erforderliche_felder: + - "kernproblem" + - "zielbild" + hinweis: "Ausgangssituation und Auswirkungen sind optional" + - abschnitt: "groesseneinschaetzung" + vollstaendig: true + - abschnitt: "shm_einschaetzung" + vollstaendig: true + hinweis: "2-3 Sätze ausreichend. Siehe shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern" + - abschnitt: "service_katalog_pruefung" + vollstaendig: true + + optionale_abschnitte: + - "user_stories" + - "nutzen" + - "rahmenbedingungen" + - "abhaengigkeiten" + - "loesungsdiskussion" + - "freigabe" + - "anlagen" + + anzuwendende_validierungsregeln: + - "VAL-BED-001" + - "VAL-BED-005" + + besonderheit: | + Stakeholder-Freigabe (VAL-BED-004) ist für interne Demands NICHT + erforderlich. DPM kann über Rückkopplungsschleife (shm_d2p-integration.yaml) + Nachforderungen stellen, wenn für Klassifizierung zusätzliche + Informationen benötigt werden. + + qualitaetssicherung: | + SHM Fast Track Validation (10-15min) ist Quality Gate 1. + DPM Quality Gate 2 prüft Klassifizierbarkeit und kann bei Bedarf + zurückweisen. + + - routing_id: "ROUTE-DPM" + name: "Demand Portfolio Management (Extern)" + status: "an_dpm_uebergeben" + steckbrief_erforderlich: true + beschreibung: | + Bedarf von externem Stakeholder (anderes Amt, Bürger, Politik) + erfordert neuen Service oder grundlegende Neugestaltung. + Vollständiger Steckbrief erforderlich für Quality Gate 1. + + erforderliche_abschnitte: + - abschnitt: "basisdaten" + vollstaendig: true + - abschnitt: "stakeholder_kontext" + vollstaendig: true + - abschnitt: "bedarfsbeschreibung" + vollstaendig: true + - abschnitt: "user_stories" + vollstaendig: true + hinweis: "Mindestens eine User Story nach Standard-Format" + - abschnitt: "rahmenbedingungen" + vollstaendig: false + erforderliche_felder: [] + hinweis: "Harte Deadline oder gewünschter Termin falls relevant" + - abschnitt: "abhaengigkeiten" + vollstaendig: true + - abschnitt: "groesseneinschaetzung" + vollstaendig: true + - abschnitt: "service_katalog_pruefung" + vollstaendig: true + - abschnitt: "freigabe" + vollstaendig: true + hinweis: "Stakeholder-Freigabe erforderlich" + + optionale_abschnitte: + - "loesungsdiskussion" + - "anlagen" + + anzuwendende_validierungsregeln: + - "VAL-BED-001" + - "VAL-BED-002" + - "VAL-BED-003" + - "VAL-BED-004" + - "VAL-BED-005" + - "VAL-BED-006" + +# ============================================================================= +# SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + + eingang: + beschreibung: "Quellen für die Steckbrief-Erstellung" + quellen: + - quelle: "Stakeholder" + artefakt: "Bedarfsmeldung (unqualifiziert)" + kanal: "Ticketsystem / direkte Ansprache" + + - quelle: "Bedarfsklärungsgespräch" + artefakt: "Protokollierte Anforderungen" + + ausgang: + beschreibung: "Übergabe des finalen Steckbriefs" + ziele: + - ziel: "Service Owner (SO)" + artefakt: "Bedarfs-Steckbrief (Final)" + zweck: "Routing-Entscheidung Change vs. Demand" + status_nach_uebergabe: "in_so_klaerung" + + - ziel: "DPM (externer Bedarf)" + artefakt: "Bedarfs-Steckbrief (Final)" + zweck: "Demand-Qualifizierung" + status_nach_uebergabe: "an_dpm_uebergeben" + bedingung: "Externer Stakeholder-Bedarf, Routing-Entscheidung = ROUTE-DPM" + + - ziel: "DPM (interner Fast-Track-Bedarf)" + artefakt: "Bedarfs-Steckbrief (Reduziert, Profil ROUTE-DPM-INTERN)" + zweck: "Demand-Qualifizierung interner Bedarf" + status_nach_uebergabe: "an_dpm_uebergeben_intern" + bedingung: "DIGIT-Mitarbeiter als Nutzer, Routing-Entscheidung = ROUTE-DPM-INTERN" + hinweis: "Reduzierter Steckbrief, DPM kann über Rückkopplungsschleife nachfordern" + + - ziel: "SPM" + artefakt: "Bedarfs-Steckbrief (Final)" + zweck: "Change an bestehendem Service" + status_nach_uebergabe: "an_spm_uebergeben" + bedingung: "DSR-Entscheidung = Change" + +# ============================================================================= +# REFERENZEN +# ============================================================================= + +referenzen: + + prozess_kontext: + - titel: "Demand-Lifecycle-Blueprint Phase 1" + pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml" + relevanz: "Prozesskontext für Steckbrief-Erstellung" + + - titel: "SHM Engagement-Framework" + pfad: "#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml" + relevanz: "Formate für Bedarfserhebung" + + verwandte_schemas: + - titel: "Amts-Steckbrief Schema" + pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_amtssteckbrief.yaml" + relevanz: "Stakeholder-Stammdaten" + + - titel: "Service-Steckbrief Schema" + pfad: "#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml" + relevanz: "Analoges Schema im SPM-Kontext" + + arbeitsmaterialien: + - titel: "Leitfaden User Stories" + pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" + hinweis: "Referenziert im PDF auf Seite 108" + + - titel: "Template Bedarfs-Steckbrief" + pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_template_bedarfssteckbrief.md" + status: "abzuleiten aus diesem Schema" + + methodik_referenz: + - dokument: "shm_bedarfsbewertung.yaml" + pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" + beschreibung: "Routing-Logik und Entscheidungsbaum für Bedarfsbewertung" + - dokument: "shm_stakeholder-portfolio.yaml" + pfad: "#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml" + beschreibung: "Stakeholder-Priorisierung und IT-Anforderungsprofil" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-BED-001" + beschreibung: "Template (Markdown) aus Schema ableiten" + prioritaet: "hoch" + ziel_ordner: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" + + - id: "OPEN-BED-002" + beschreibung: "Leitfaden User Stories erstellen" + prioritaet: "mittel" + referenz: "PDF Seite 108" + + - id: "OPEN-BED-003" + beschreibung: "ITSM-Tool-Mapping definieren" + prioritaet: "niedrig" + hinweis: "Wie wird der Steckbrief im Ticketsystem abgebildet?" + + - id: "OPEN-BED-004" + beschreibung: "Abstimmung SOR-Integration" + prioritaet: "mittel" + hinweis: "SOR-Prozess noch nicht vollständig modelliert" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.1" + datum: "2025-12-09" + aenderung: | + - Neuer Abschnitt: stakeholder_kontext (Integration Stakeholder-Portfolio) + - Neuer Abschnitt: validierungsprofile (Routing-basierte Pflichtfelder) + - Update: referenz_leitfaden auf YAML-Pfad + - Update: VAL-BED-004 präzisiert (nur DPM erfordert Freigabe) + - Neue Methodik-Referenzen ergänzt + autor: "DIGITOM-Projekt" + quelle: "SHM Phase 3 – Bedarfsbewertung" + + - version: "1.3" + datum: "2026-03-07" + aenderung: | + - Schnittstellen.ausgang: DPM-Eintrag aufgeteilt in zwei Ziele + (externer Bedarf ROUTE-DPM / interner Fast-Track ROUTE-DPM-INTERN) + - Status "an_dpm_uebergeben_intern" in Ausgangs-Übersicht ergänzt + - Bedingungsformulierung bei DPM-extern auf ROUTE-DPM-Terminologie präzisiert + autor: "DIGITOM-Projekt" + quelle: "Lückenanalyse Bedarfsrouting 2026-03-07" + + - version: "1.2" + datum: "2026-01-22" + aenderung: | + - Neues Validierungsprofil: ROUTE-DPM-INTERN + - Reduzierte Pflichtfelder für interne DIGIT-Bedarfe + - Status: "an_dpm_uebergeben_intern" + - Hinweis auf DPM Rückkopplungsschleife bei Nachforderungen + - Umbenennung bestehendes Profil: ROUTE-DPM → ROUTE-DPM (Extern) zur Klarheit + autor: "DIGITOM-Projekt" + quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe" + + - version: "1.0" + datum: "2025-12-09" + aenderung: "Initiale Schema-Erstellung aus PDF-Template" + autor: "DIGITOM-Projekt" quelle: "Konzept_DPM_Abnahme20230925, Seiten 106-112" \ No newline at end of file diff --git a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_interne-bedarfe-routing.yaml b/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_interne-bedarfe-routing.yaml index 49dfde5..960bc0c 100644 --- a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_interne-bedarfe-routing.yaml +++ b/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_interne-bedarfe-routing.yaml @@ -1,567 +1,567 @@ -# ============================================================================= -# SHM: ROUTING INTERNER DIGIT-BEDARFE -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Typ: Arbeitsmaterial / Übersicht -# Version: 2.0 -# Datum: 2025-01-29 -# Status: Entwurf -# ============================================================================= - -meta: - modul_id: "SHM-AM-02" - name: "Routing interner DIGIT-Bedarfe" - typ: "Arbeitsmaterial" - - zweck: | - Diese Übersicht klärt die drei unterschiedlichen Bedarfstypen und ihre - jeweiligen Prozesswege. Sie dient als Entscheidungshilfe für SHM und - als Orientierung für DIGIT-Mitarbeiter. - - **Kernaussage:** Es gibt drei Bedarfstypen mit unterschiedlichen Wegen: - 1. Externe Stakeholder-Bedarfe → Regelweg (vollständige Bedarfsbewertung) - 2. Interne DIGIT-Mitarbeiter-Bedarfe → Fast Track (10-15 min) - 3. Service-Lifecycle-Bedarfe → Bypass (direkt in Demand-Lifecycle) - - referenzen: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "funktionale_herleitung.geltungsbereich" - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "prozessablauf.schritt_0a_fast_track_intern" - - dokument: "shm_d2p-integration.yaml" - abschnitt: "abgrenzung_bedarfsquellen" - - dokument: "PATCH_NOTES_interne_bedarfe_v1.1.md" - beschreibung: "Konzeptdokumentation Fast Track" - - governance_referenz: "GOV-SHM-026" - -# ============================================================================= -# ÜBERSICHT: DREI BEDARFSTYPEN -# ============================================================================= - -bedarfstypen_uebersicht: - - visualisierung: | - - ┌─────────────────────────────────────────────────────────────────────────┐ - │ BEDARFSTYPEN IM DIGIT │ - └─────────────────────────────────────────────────────────────────────────┘ - - ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ - │ TYP 1: EXTERN │ │ TYP 2: INTERN │ │ TYP 3: LIFECYCLE │ - │ (Regelweg) │ │ (Fast Track) │ │ (Bypass) │ - └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ - │ │ │ - Bedarfsträger: Bedarfsträger: Bedarfsträger: - Externe Ämter, DIGIT-Mitarbeiter Service Owner, - Dienststellen als Nutzer ISB, SOR, Leitung - │ │ │ - ▼ ▼ ▼ - ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ - │ SHM Bedarfsbewertung│ │ SHM Fast Track │ │ Direkt DPM/SOR │ - │ - Schritt 0 │ │ - 3 Schritte │ │ - Kein SHM-Routing │ - │ - Prüfungen 1-3 │ │ - 10-15 Minuten │ │ - SHM informiert │ - │ - Vollständiger │ │ - Reduzierter │ │ bei Stakeholder- │ - │ Steckbrief │ │ Steckbrief │ │ Auswirkungen │ - └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ - │ │ │ - └─────────────────────────┼─────────────────────────┘ - │ - ▼ - ┌─────────────────────┐ - │ DPM / DSR / MB │ - │ (einheitliche │ - │ Klassifizierung) │ - └─────────────────────┘ - - zusammenfassung_tabelle: - - spalten: - - "Bedarfstyp" - - "Bedarfsträger" - - "Eintrittskanal" - - "Prozess" - - "Aufwand SHM" - - "Steckbrief" - - zeilen: - - bedarfstyp: "Extern (Regelweg)" - bedarfstraeger: "Ämter, Dienststellen außerhalb DIGIT" - eintrittskanal: "SHM" - prozess: "Schritt 0 + Prüfungen 1-3" - aufwand_shm: "2-4 Stunden" - steckbrief: "Vollständig (ROUTE-DPM)" - - - bedarfstyp: "Intern (Fast Track)" - bedarfstraeger: "DIGIT-Mitarbeiter als Nutzer" - eintrittskanal: "SHM (Self-Service-Portal)" - prozess: "3-Schritte Fast Track" - aufwand_shm: "10-15 Minuten" - steckbrief: "Reduziert (ROUTE-DPM-INTERN)" - - - bedarfstyp: "Service-Lifecycle (Bypass)" - bedarfstraeger: "SO, ISB, SOR, DIGIT-Leitung" - eintrittskanal: "Direkt SOR/DPM" - prozess: "Kein SHM-Routing" - aufwand_shm: "0 (nur Information)" - steckbrief: "Vom Bedarfsträger erstellt" - -# ============================================================================= -# TYP 1: EXTERNE STAKEHOLDER-BEDARFE (REGELWEG) -# ============================================================================= - -typ_1_externe_bedarfe: - - name: "Externe Stakeholder-Bedarfe" - kurzbezeichnung: "Regelweg" - - definition: | - Bedarfe, die von Stakeholdern außerhalb von DIGIT an DIGIT herangetragen - werden. Der Stakeholder ist Bedarfsträger und Auftraggeber. - - bedarfstraeger: - - "Städtische Ämter (z.B. Bauamt, Sozialamt, Ordnungsamt)" - - "Städtische Dienststellen" - - "Eigenbetriebe" - - "Andere kommunale Einrichtungen" - - eintrittskanal: "SHM (Stakeholder-Management)" - - prozess: - beschreibung: "Vollständige Bedarfsbewertung gemäß shm_bedarfsbewertung.yaml" - schritte: - - "Schritt 0: Bedarfserhebung (User Stories)" - - "Prüfung 1: Service-Katalog-Check" - - "Prüfung 2: Change-Qualifizierung" - - "Prüfung 3: Demand-Indikation" - aufwand: "2-4 Stunden" - steckbrief: "Vollständig (Validierungsprofil ROUTE-DPM)" - - routing_optionen: - - "ROUTE-REQ → Service Desk / Request Fulfilment" - - "ROUTE-SPM → Service Owner (Change)" - - "ROUTE-DPM → Demand Portfolio Management" - - "ROUTE-SO → Service-Owner-Klärung (bei Unklarheit)" - - beispiele: - - - titel: "Bauamt benötigt neue Funktion im Fachverfahren" - situation: | - Das Bauamt meldet, dass im Bauantragsverfahren eine Funktion zur - automatischen Flurstücksvalidierung fehlt. - prozess: | - SHM führt vollständige Bedarfsbewertung durch: - - Schritt 0: User Stories mit Sachbearbeitern erarbeiten - - Prüfung 1: Service existiert (Bauantragsverfahren) - - Prüfung 2: Change am bestehenden Service → ROUTE-SPM - ergebnis: "Vollständiger Bedarfssteckbrief an Service Owner" - - - titel: "Sozialamt möchte digitale Antragsstellung" - situation: | - Das Sozialamt möchte Bürgeranträge online entgegennehmen können. - Aktuell existiert kein entsprechender Service. - prozess: | - SHM führt vollständige Bedarfsbewertung durch: - - Schritt 0: User Stories und Anforderungen erheben - - Prüfung 1: Kein passender Service im Katalog - - Prüfung 3: Demand-Indikation positiv → ROUTE-DPM - ergebnis: "Vollständiger Bedarfssteckbrief an DPM" - -# ============================================================================= -# TYP 2: INTERNE DIGIT-MITARBEITER-BEDARFE (FAST TRACK) -# ============================================================================= - -typ_2_interne_nutzer_bedarfe: - - name: "Interne DIGIT-Mitarbeiter-Bedarfe" - kurzbezeichnung: "Fast Track" - - definition: | - Bedarfe von DIGIT-Mitarbeitern, die als *Nutzer* von IT-Services - auftreten – nicht in ihrer Funktion als Service Owner, ISB oder - andere technische Rolle. - - bedarfstraeger: - - "DIGIT-Personalabteilung" - - "DIGIT-Sekretariat" - - "DIGIT-Sachbearbeiter (als Nutzer)" - - "Andere DIGIT-interne Organisationseinheiten" - - "Ggf. Stabsstelle Digital Freiburg (als Nutzer)" - - abgrenzung_zu_service_lifecycle: | - Der Fast Track gilt für DIGIT-Mitarbeiter als **Nutzer**. - - Wenn ein Service Owner einen Bedarf für seinen **eigenen Service** hat, - ist das ein Service-Lifecycle-Bedarf (Typ 3), kein Fast-Track-Fall. - - Beispiel: - - Personalabteilung braucht neue Zeiterfassung → Fast Track (Typ 2) - - Service Owner DMS plant Redesign seines Service → Lifecycle (Typ 3) - - eintrittskanal: - primaer: "Self-Service-Portal (ITSM-Tool)" - mvp: "E-Mail-Template an SHM" - - prozess: - beschreibung: "Vereinfachter 3-Schritte Fast Track (10-15 Minuten)" - - schritt_1: - name: "Basistriage" - dauer: "3-5 Minuten" - frage: "Ist es ein valider Bedarf?" - - schritt_2: - name: "Routing-Entscheidung" - dauer: "5-7 Minuten" - frage: "Wohin gehört der Bedarf?" - optionen: - - "Bestehender Service → Direkt an Service Owner" - - "Neuer Service → ROUTE-DPM-INTERN" - - "Unklar → ROUTE-SO" - - schritt_3: - name: "Minimaldokumentation" - dauer: "3-5 Minuten" - bedingung: "Nur bei ROUTE-DPM-INTERN" - - aufwand: "10-15 Minuten" - steckbrief: "Reduziert (Validierungsprofil ROUTE-DPM-INTERN)" - - routing_optionen: - - "Direkt an Service Owner (kein Steckbrief)" - - "ROUTE-DPM-INTERN (reduzierter Steckbrief)" - - "ROUTE-SO (bei Unklarheit)" - - beispiele: - - - titel: "Personalabteilung DIGIT möchte neue Personalsoftware" - situation: | - Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue - Software zur Zeiterfassung, da das aktuelle System nicht mehr - den Anforderungen entspricht. - prozess: - schritt_1: "Valide – Bedarf verständlich, im Scope" - schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN" - schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M" - ergebnis: "An DPM mit reduziertem Steckbrief" - aufwand: "~12 Minuten" - - - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" - situation: | - Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang - für kollaborative Workshops. - prozess: - schritt_1: "Valide – Bedarf verständlich" - schritt_2: "Bestehender Service: Conceptboard → Direkt an SO" - schritt_3: "Nicht erforderlich" - ergebnis: | - Direkt an Service Owner Conceptboard. SO klärt: - - Reicht Conceptboard aus? - - Fehlt eine Funktion? → Ggf. Change - - Begründeter Mehrbedarf? → SO entscheidet - aufwand: "~8 Minuten" - - - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" - situation: | - Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung - mit externen Besuchern (Buchungslink-Funktion). - prozess: - schritt_1: "Valide – Bedarf verständlich, im Scope" - schritt_2: "Prüfung: Kalendertool mit Buchungsfunktion vorhanden?" - schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" - ergebnis: "Abhängig von Service-Katalog-Prüfung" - aufwand: "~10 Minuten" - -# ============================================================================= -# TYP 3: SERVICE-LIFECYCLE-BEDARFE (BYPASS) -# ============================================================================= - -typ_3_service_lifecycle_bedarfe: - - name: "Service-Lifecycle-Bedarfe" - kurzbezeichnung: "Bypass" - - definition: | - Bedarfe, die aus dem Service-Lifecycle oder aus technisch-strategischen - Rollen heraus entstehen. Der Bedarfsträger ist eine DIGIT-interne Rolle - mit fachlicher Expertise (Service Owner, ISB, SOR, DIGIT-Leitung). - - Diese Bedarfe durchlaufen die SHM-Triage NICHT, weil die fachliche - Qualifizierung bereits durch den Bedarfsträger erfolgt ist. - - bedarfstraeger: - - "Service Owner (für eigenen Service)" - - "ISB / Compliance" - - "SOR (strategische Entscheidungen)" - - "DIGIT-Leitung / Mission Board" - - "Technische Architektur-Rollen" - - eintrittskanal: "Direkt SOR / DPM (je nach Umfang)" - - shm_rolle: | - SHM ist bei Service-Lifecycle-Bedarfen **nicht Routing-Instanz**, aber: - - SHM wird **informiert**, wenn externe Stakeholder betroffen sind - - SHM übernimmt dann die **Stakeholder-Kommunikation** - - SHM kann **Stakeholder-Perspektive** in DSR/MB einbringen - - szenarien: - - # ------------------------------------------------------------------------- - szenario_1_change_bedarf_so: - name: "Service Owner identifiziert Change-Bedarf" - - beschreibung: | - Der Service Owner erkennt im Rahmen seiner laufenden Arbeit oder aus - dem Service Review, dass sein Service angepasst werden muss. - - ausloeser: - - "Service Review (sr_02) zeigt Optimierungspotenzial" - - "Technische Schulden müssen abgebaut werden" - - "Performance-Verbesserung erforderlich" - - "Nutzer-Feedback zeigt Verbesserungsbedarf" - - routing: "SO führt Change selbst durch (Normal Change Authority)" - shm_information: "Nur bei Stakeholder-Auswirkungen" - - beispiel: - titel: "Performance-Optimierung Ticketsystem" - situation: "SO stellt fest, dass die Suche zu langsam ist." - routing: "SO führt Datenbank-Tuning als Change durch" - shm_information: "Nicht erforderlich (keine Nutzer-Auswirkung)" - - # ------------------------------------------------------------------------- - szenario_2_redesign_bedarf_so: - name: "Service Owner identifiziert Redesign-Bedarf" - - beschreibung: | - Der Service Owner erkennt, dass sein Service grundlegend überarbeitet - werden muss – die Änderung hat Projektcharakter. - - ausloeser: - - "Service Review zeigt grundlegenden Modernisierungsbedarf" - - "Technologie ist veraltet (End-of-Life)" - - "Architektur-Änderung erforderlich" - - routing: "SO → SOR (REDESIGN) → DPM (Demand)" - shm_information: "Ja, da Stakeholder betroffen" - - beispiel: - titel: "Modernisierung Dokumentenmanagement" - situation: "SO erkennt im Review: DMS technisch veraltet" - routing: "SO → SOR bestätigt → DPM erhält Demand" - shm_information: "SHM bereitet Stakeholder-Kommunikation vor" - - # ------------------------------------------------------------------------- - szenario_3_service_abloesung: - name: "Service-Ablösung / Retirement" - - beschreibung: | - Ein Service soll nicht mehr weitergeführt werden – entweder - ersatzlos oder durch einen anderen Service ersetzt. - - ausloeser: - - "End-of-Life des Produkts/der Technologie" - - "Strategische Konsolidierung" - - "Service wird nicht mehr benötigt" - - routing: "SO → SOR (RETIRE) → DPM (Retirement-Projekt)" - shm_information: "Ja, zwingend" - - beispiel: - titel: "Ablösung Legacy-Mailsystem" - situation: "DIGIT entscheidet strategisch: Mailsystem ersetzen" - routing: "SO (alt) → SOR → DPM (Retirement + ggf. neues System)" - shm_information: | - SHM übernimmt komplette Stakeholder-Kommunikation: - - Key-Stakeholder: Persönliche Gespräche - - Aktiv-Stakeholder: Strukturierte Information - - Standard/Basis: Schriftliche Ankündigung - - # ------------------------------------------------------------------------- - szenario_4_sicherheit_compliance: - name: "Sicherheits- oder Compliance-Anforderung" - - beschreibung: | - Eine Änderung wird durch Sicherheitsvorgaben, Regulatorik oder - Compliance-Anforderungen notwendig. - - ausloeser: - - "Sicherheitsvorfall oder -erkenntnis" - - "Neue gesetzliche Anforderung" - - "Audit-Feststellung" - - "BSI-Empfehlung" - - routing: "ISB → SOR/SO (je nach Umfang)" - shm_information: "Bei Stakeholder-Auswirkungen" - - beispiel: - titel: "Zwei-Faktor-Authentifizierung verpflichtend" - situation: "Neue Sicherheitsrichtlinie erfordert 2FA" - routing: "ISB → SOR → Umsetzung durch betroffene SOs" - shm_information: | - SHM übernimmt Stakeholder-Kommunikation: - - Erklärung der Notwendigkeit - - Zeitplan und Umstellungsprozess - - Schulungs-/Support-Angebote - - # ------------------------------------------------------------------------- - szenario_5_strategische_initiative: - name: "Strategische DIGIT-Initiative" - - beschreibung: | - DIGIT startet eine übergreifende Initiative, die mehrere Services - betrifft oder neue Infrastruktur schafft. - - ausloeser: - - "IT-Strategie-Umsetzung" - - "Konsolidierungsprojekt" - - "Infrastruktur-Modernisierung" - - "Einführung neuer Basisdienste" - - routing: "DIGIT-Leitung → MB → DPM" - shm_information: "Ja, bei Stakeholder-Auswirkungen" - - beispiel: - titel: "Einführung zentrales Identity Management" - situation: "DIGIT führt IAM-System ein (Single Sign-On)" - routing: "DIGIT-Leitung → MB (Freigabe) → DPM (Programm)" - shm_information: | - SHM wird frühzeitig eingebunden: - - Vorteile kommunizieren - - Migrationsplanung je Amt - - Schulungskonzept - -# ============================================================================= -# ENTSCHEIDUNGSHILFE -# ============================================================================= - -entscheidungshilfe: - - kernfragen: - - frage: "Wer ist Bedarfsträger?" - typ_1: "Externes Amt / Dienststelle" - typ_2: "DIGIT-Mitarbeiter als Nutzer" - typ_3: "SO, ISB, SOR, DIGIT-Leitung" - - - frage: "Woher kommt der Bedarf?" - typ_1: "Stakeholder-Anfrage von außerhalb DIGIT" - typ_2: "Interne Nutzer-Anforderung" - typ_3: "Service-Lifecycle, Sicherheit, Strategie" - - - frage: "Hat der Bedarfsträger fachliche IT-Expertise?" - typ_1: "Nein (fachliche Übersetzung durch SHM nötig)" - typ_2: "Begrenzt (vereinfachte Prüfung ausreichend)" - typ_3: "Ja (Bedarfsträger qualifiziert selbst)" - - grenzfaelle: - - - fall: "Stakeholder beschwert sich, SO erkennt daraus Redesign-Bedarf" - einschaetzung: | - Der initiale Bedarf war extern (Beschwerde) → Typ 1. - Die Schlussfolgerung "Redesign nötig" ist SO-Erkenntnis → Typ 3. - - Routing: Beschwerde über SHM (Typ 1). Wenn SHM an SO routet und - SO dann Redesign empfiehlt, geht der Demand direkt zu DPM (Typ 3). - - - fall: "SO möchte Feature, das Stakeholder auch wünschen" - einschaetzung: | - Entscheidend ist, wer den Bedarf zuerst artikuliert hat: - - Stakeholder zuerst → Typ 1 (SHM-Regelweg) - - SO zuerst → Typ 3 (Service-Lifecycle) - - In der Praxis: SO kann auf Stakeholder-Unterstützung verweisen. - - - fall: "DIGIT-Personalabteilung vs. Personalamt der Stadt" - einschaetzung: | - - DIGIT-Personalabteilung → Typ 2 (Fast Track) - - Personalamt der Stadt (anderes Amt) → Typ 1 (Regelweg) - - Entscheidend ist die organisatorische Zugehörigkeit, nicht die - funktionale Ähnlichkeit. - - - fall: "ISB fordert Änderung, die Stakeholder nicht wollen" - einschaetzung: | - Sicherheits-/Compliance-Anforderungen sind Typ 3, auch wenn sie - Stakeholder-Widerstand erzeugen. - - SHM übernimmt die (ggf. schwierige) Stakeholder-Kommunikation, - aber das Routing bleibt Typ 3 (ISB → SOR/SO). - -# ============================================================================= -# ROUTING-MATRIX (KOMPAKT) -# ============================================================================= - -routing_matrix_kompakt: - - zeilen: - - bedarfstyp: "Extern (Typ 1)" - beispiel: "Bauamt braucht neue Funktion" - eintritt: "SHM" - prozess: "Regelweg" - aufwand: "2-4h" - steckbrief: "Vollständig" - - - bedarfstyp: "Intern-Nutzer (Typ 2)" - beispiel: "DIGIT-Personal braucht Zeiterfassung" - eintritt: "SHM (Fast Track)" - prozess: "3 Schritte" - aufwand: "10-15min" - steckbrief: "Reduziert" - - - bedarfstyp: "Service-Lifecycle (Typ 3)" - beispiel: "SO plant DMS-Modernisierung" - eintritt: "Direkt SOR/DPM" - prozess: "Kein SHM" - aufwand: "0 (SHM)" - steckbrief: "Vom SO" - -# ============================================================================= -# SHM-AUFGABEN JE BEDARFSTYP -# ============================================================================= - -shm_aufgaben_je_typ: - - typ_1_extern: - - "Vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3)" - - "User-Story-Erhebung mit Stakeholder" - - "Bedarfssteckbrief erstellen und validieren" - - "Routing-Entscheidung treffen" - - "Stakeholder-Kommunikation im gesamten Prozess" - - typ_2_intern_nutzer: - - "Fast Track Basistriage (3-5 min)" - - "Schnelle Routing-Entscheidung (5-7 min)" - - "Minimaldokumentation bei ROUTE-DPM-INTERN (3-5 min)" - - "Weiterleitung an SO oder DPM" - - typ_3_service_lifecycle: - - "Keine Routing-Aufgabe" - - "Information bei Stakeholder-Auswirkungen entgegennehmen" - - "Stakeholder-Kommunikation übernehmen (wenn informiert)" - - "Stakeholder-Perspektive in DSR/MB einbringen" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-01-29" - aenderung: "Initiale Erstellung (Fokus auf Service-Lifecycle-Bedarfe)" - autor: "DIGITOM-Projekt" - quelle: "Chat-Session Konzeptprüfung" - - - version: "2.0" - datum: "2025-01-29" - aenderung: | - Komplette Überarbeitung: Drei Bedarfstypen klar unterschieden - - Typ 1: Externe Stakeholder-Bedarfe (Regelweg) - - Typ 2: Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track) - - Typ 3: Service-Lifecycle-Bedarfe (Bypass) - - Visualisierung und Routing-Matrix ergänzt - - Entscheidungshilfe mit Grenzfällen - - SHM-Aufgaben je Bedarfstyp - - Synchronisierung mit shm_bedarfsbewertung.yaml v1.3 - autor: "DIGITOM-Projekt" - quelle: "Chat-Session Konzeptprüfung" +# ============================================================================= +# SHM: ROUTING INTERNER DIGIT-BEDARFE +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Typ: Arbeitsmaterial / Übersicht +# Version: 2.0 +# Datum: 2025-01-29 +# Status: Entwurf +# ============================================================================= + +meta: + modul_id: "SHM-AM-02" + name: "Routing interner DIGIT-Bedarfe" + typ: "Arbeitsmaterial" + + zweck: | + Diese Übersicht klärt die drei unterschiedlichen Bedarfstypen und ihre + jeweiligen Prozesswege. Sie dient als Entscheidungshilfe für SHM und + als Orientierung für DIGIT-Mitarbeiter. + + **Kernaussage:** Es gibt drei Bedarfstypen mit unterschiedlichen Wegen: + 1. Externe Stakeholder-Bedarfe → Regelweg (vollständige Bedarfsbewertung) + 2. Interne DIGIT-Mitarbeiter-Bedarfe → Fast Track (10-15 min) + 3. Service-Lifecycle-Bedarfe → Bypass (direkt in Demand-Lifecycle) + + referenzen: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "funktionale_herleitung.geltungsbereich" + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "prozessablauf.schritt_0a_fast_track_intern" + - dokument: "shm_d2p-integration.yaml" + abschnitt: "abgrenzung_bedarfsquellen" + - dokument: "PATCH_NOTES_interne_bedarfe_v1.1.md" + beschreibung: "Konzeptdokumentation Fast Track" + + governance_referenz: "GOV-SHM-026" + +# ============================================================================= +# ÜBERSICHT: DREI BEDARFSTYPEN +# ============================================================================= + +bedarfstypen_uebersicht: + + visualisierung: | + + ┌─────────────────────────────────────────────────────────────────────────┐ + │ BEDARFSTYPEN IM DIGIT │ + └─────────────────────────────────────────────────────────────────────────┘ + + ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ + │ TYP 1: EXTERN │ │ TYP 2: INTERN │ │ TYP 3: LIFECYCLE │ + │ (Regelweg) │ │ (Fast Track) │ │ (Bypass) │ + └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ + │ │ │ + Bedarfsträger: Bedarfsträger: Bedarfsträger: + Externe Ämter, DIGIT-Mitarbeiter Service Owner, + Dienststellen als Nutzer ISB, SOR, Leitung + │ │ │ + ▼ ▼ ▼ + ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ + │ SHM Bedarfsbewertung│ │ SHM Fast Track │ │ Direkt DPM/SOR │ + │ - Schritt 0 │ │ - 3 Schritte │ │ - Kein SHM-Routing │ + │ - Prüfungen 1-3 │ │ - 10-15 Minuten │ │ - SHM informiert │ + │ - Vollständiger │ │ - Reduzierter │ │ bei Stakeholder- │ + │ Steckbrief │ │ Steckbrief │ │ Auswirkungen │ + └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ + │ │ │ + └─────────────────────────┼─────────────────────────┘ + │ + ▼ + ┌─────────────────────┐ + │ DPM / DSR / MB │ + │ (einheitliche │ + │ Klassifizierung) │ + └─────────────────────┘ + + zusammenfassung_tabelle: + + spalten: + - "Bedarfstyp" + - "Bedarfsträger" + - "Eintrittskanal" + - "Prozess" + - "Aufwand SHM" + - "Steckbrief" + + zeilen: + - bedarfstyp: "Extern (Regelweg)" + bedarfstraeger: "Ämter, Dienststellen außerhalb DIGIT" + eintrittskanal: "SHM" + prozess: "Schritt 0 + Prüfungen 1-3" + aufwand_shm: "2-4 Stunden" + steckbrief: "Vollständig (ROUTE-DPM)" + + - bedarfstyp: "Intern (Fast Track)" + bedarfstraeger: "DIGIT-Mitarbeiter als Nutzer" + eintrittskanal: "SHM (Self-Service-Portal)" + prozess: "3-Schritte Fast Track" + aufwand_shm: "10-15 Minuten" + steckbrief: "Reduziert (ROUTE-DPM-INTERN)" + + - bedarfstyp: "Service-Lifecycle (Bypass)" + bedarfstraeger: "SO, ISB, SOR, DIGIT-Leitung" + eintrittskanal: "Direkt SOR/DPM" + prozess: "Kein SHM-Routing" + aufwand_shm: "0 (nur Information)" + steckbrief: "Vom Bedarfsträger erstellt" + +# ============================================================================= +# TYP 1: EXTERNE STAKEHOLDER-BEDARFE (REGELWEG) +# ============================================================================= + +typ_1_externe_bedarfe: + + name: "Externe Stakeholder-Bedarfe" + kurzbezeichnung: "Regelweg" + + definition: | + Bedarfe, die von Stakeholdern außerhalb von DIGIT an DIGIT herangetragen + werden. Der Stakeholder ist Bedarfsträger und Auftraggeber. + + bedarfstraeger: + - "Städtische Ämter (z.B. Bauamt, Sozialamt, Ordnungsamt)" + - "Städtische Dienststellen" + - "Eigenbetriebe" + - "Andere kommunale Einrichtungen" + + eintrittskanal: "SHM (Stakeholder-Management)" + + prozess: + beschreibung: "Vollständige Bedarfsbewertung gemäß shm_bedarfsbewertung.yaml" + schritte: + - "Schritt 0: Bedarfserhebung (User Stories)" + - "Prüfung 1: Service-Katalog-Check" + - "Prüfung 2: Change-Qualifizierung" + - "Prüfung 3: Demand-Indikation" + aufwand: "2-4 Stunden" + steckbrief: "Vollständig (Validierungsprofil ROUTE-DPM)" + + routing_optionen: + - "ROUTE-REQ → Service Desk / Request Fulfilment" + - "ROUTE-SPM → Service Owner (Change)" + - "ROUTE-DPM → Demand Portfolio Management" + - "ROUTE-SO → Service-Owner-Klärung (bei Unklarheit)" + + beispiele: + + - titel: "Bauamt benötigt neue Funktion im Fachverfahren" + situation: | + Das Bauamt meldet, dass im Bauantragsverfahren eine Funktion zur + automatischen Flurstücksvalidierung fehlt. + prozess: | + SHM führt vollständige Bedarfsbewertung durch: + - Schritt 0: User Stories mit Sachbearbeitern erarbeiten + - Prüfung 1: Service existiert (Bauantragsverfahren) + - Prüfung 2: Change am bestehenden Service → ROUTE-SPM + ergebnis: "Vollständiger Bedarfssteckbrief an Service Owner" + + - titel: "Sozialamt möchte digitale Antragsstellung" + situation: | + Das Sozialamt möchte Bürgeranträge online entgegennehmen können. + Aktuell existiert kein entsprechender Service. + prozess: | + SHM führt vollständige Bedarfsbewertung durch: + - Schritt 0: User Stories und Anforderungen erheben + - Prüfung 1: Kein passender Service im Katalog + - Prüfung 3: Demand-Indikation positiv → ROUTE-DPM + ergebnis: "Vollständiger Bedarfssteckbrief an DPM" + +# ============================================================================= +# TYP 2: INTERNE DIGIT-MITARBEITER-BEDARFE (FAST TRACK) +# ============================================================================= + +typ_2_interne_nutzer_bedarfe: + + name: "Interne DIGIT-Mitarbeiter-Bedarfe" + kurzbezeichnung: "Fast Track" + + definition: | + Bedarfe von DIGIT-Mitarbeitern, die als *Nutzer* von IT-Services + auftreten – nicht in ihrer Funktion als Service Owner, ISB oder + andere technische Rolle. + + bedarfstraeger: + - "DIGIT-Personalabteilung" + - "DIGIT-Sekretariat" + - "DIGIT-Sachbearbeiter (als Nutzer)" + - "Andere DIGIT-interne Organisationseinheiten" + - "Ggf. Stabsstelle Digital Freiburg (als Nutzer)" + + abgrenzung_zu_service_lifecycle: | + Der Fast Track gilt für DIGIT-Mitarbeiter als **Nutzer**. + + Wenn ein Service Owner einen Bedarf für seinen **eigenen Service** hat, + ist das ein Service-Lifecycle-Bedarf (Typ 3), kein Fast-Track-Fall. + + Beispiel: + - Personalabteilung braucht neue Zeiterfassung → Fast Track (Typ 2) + - Service Owner DMS plant Redesign seines Service → Lifecycle (Typ 3) + + eintrittskanal: + primaer: "Self-Service-Portal (ITSM-Tool)" + mvp: "E-Mail-Template an SHM" + + prozess: + beschreibung: "Vereinfachter 3-Schritte Fast Track (10-15 Minuten)" + + schritt_1: + name: "Basistriage" + dauer: "3-5 Minuten" + frage: "Ist es ein valider Bedarf?" + + schritt_2: + name: "Routing-Entscheidung" + dauer: "5-7 Minuten" + frage: "Wohin gehört der Bedarf?" + optionen: + - "Bestehender Service → Direkt an Service Owner" + - "Neuer Service → ROUTE-DPM-INTERN" + - "Unklar → ROUTE-SO" + + schritt_3: + name: "Minimaldokumentation" + dauer: "3-5 Minuten" + bedingung: "Nur bei ROUTE-DPM-INTERN" + + aufwand: "10-15 Minuten" + steckbrief: "Reduziert (Validierungsprofil ROUTE-DPM-INTERN)" + + routing_optionen: + - "Direkt an Service Owner (kein Steckbrief)" + - "ROUTE-DPM-INTERN (reduzierter Steckbrief)" + - "ROUTE-SO (bei Unklarheit)" + + beispiele: + + - titel: "Personalabteilung DIGIT möchte neue Personalsoftware" + situation: | + Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue + Software zur Zeiterfassung, da das aktuelle System nicht mehr + den Anforderungen entspricht. + prozess: + schritt_1: "Valide – Bedarf verständlich, im Scope" + schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN" + schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M" + ergebnis: "An DPM mit reduziertem Steckbrief" + aufwand: "~12 Minuten" + + - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" + situation: | + Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang + für kollaborative Workshops. + prozess: + schritt_1: "Valide – Bedarf verständlich" + schritt_2: "Bestehender Service: Conceptboard → Direkt an SO" + schritt_3: "Nicht erforderlich" + ergebnis: | + Direkt an Service Owner Conceptboard. SO klärt: + - Reicht Conceptboard aus? + - Fehlt eine Funktion? → Ggf. Change + - Begründeter Mehrbedarf? → SO entscheidet + aufwand: "~8 Minuten" + + - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" + situation: | + Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung + mit externen Besuchern (Buchungslink-Funktion). + prozess: + schritt_1: "Valide – Bedarf verständlich, im Scope" + schritt_2: "Prüfung: Kalendertool mit Buchungsfunktion vorhanden?" + schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" + ergebnis: "Abhängig von Service-Katalog-Prüfung" + aufwand: "~10 Minuten" + +# ============================================================================= +# TYP 3: SERVICE-LIFECYCLE-BEDARFE (BYPASS) +# ============================================================================= + +typ_3_service_lifecycle_bedarfe: + + name: "Service-Lifecycle-Bedarfe" + kurzbezeichnung: "Bypass" + + definition: | + Bedarfe, die aus dem Service-Lifecycle oder aus technisch-strategischen + Rollen heraus entstehen. Der Bedarfsträger ist eine DIGIT-interne Rolle + mit fachlicher Expertise (Service Owner, ISB, SOR, DIGIT-Leitung). + + Diese Bedarfe durchlaufen die SHM-Triage NICHT, weil die fachliche + Qualifizierung bereits durch den Bedarfsträger erfolgt ist. + + bedarfstraeger: + - "Service Owner (für eigenen Service)" + - "ISB / Compliance" + - "SOR (strategische Entscheidungen)" + - "DIGIT-Leitung / Mission Board" + - "Technische Architektur-Rollen" + + eintrittskanal: "Direkt SOR / DPM (je nach Umfang)" + + shm_rolle: | + SHM ist bei Service-Lifecycle-Bedarfen **nicht Routing-Instanz**, aber: + - SHM wird **informiert**, wenn externe Stakeholder betroffen sind + - SHM übernimmt dann die **Stakeholder-Kommunikation** + - SHM kann **Stakeholder-Perspektive** in DSR/MB einbringen + + szenarien: + + # ------------------------------------------------------------------------- + szenario_1_change_bedarf_so: + name: "Service Owner identifiziert Change-Bedarf" + + beschreibung: | + Der Service Owner erkennt im Rahmen seiner laufenden Arbeit oder aus + dem Service Review, dass sein Service angepasst werden muss. + + ausloeser: + - "Service Review (sr_02) zeigt Optimierungspotenzial" + - "Technische Schulden müssen abgebaut werden" + - "Performance-Verbesserung erforderlich" + - "Nutzer-Feedback zeigt Verbesserungsbedarf" + + routing: "SO führt Change selbst durch (Normal Change Authority)" + shm_information: "Nur bei Stakeholder-Auswirkungen" + + beispiel: + titel: "Performance-Optimierung Ticketsystem" + situation: "SO stellt fest, dass die Suche zu langsam ist." + routing: "SO führt Datenbank-Tuning als Change durch" + shm_information: "Nicht erforderlich (keine Nutzer-Auswirkung)" + + # ------------------------------------------------------------------------- + szenario_2_redesign_bedarf_so: + name: "Service Owner identifiziert Redesign-Bedarf" + + beschreibung: | + Der Service Owner erkennt, dass sein Service grundlegend überarbeitet + werden muss – die Änderung hat Projektcharakter. + + ausloeser: + - "Service Review zeigt grundlegenden Modernisierungsbedarf" + - "Technologie ist veraltet (End-of-Life)" + - "Architektur-Änderung erforderlich" + + routing: "SO → SOR (REDESIGN) → DPM (Demand)" + shm_information: "Ja, da Stakeholder betroffen" + + beispiel: + titel: "Modernisierung Dokumentenmanagement" + situation: "SO erkennt im Review: DMS technisch veraltet" + routing: "SO → SOR bestätigt → DPM erhält Demand" + shm_information: "SHM bereitet Stakeholder-Kommunikation vor" + + # ------------------------------------------------------------------------- + szenario_3_service_abloesung: + name: "Service-Ablösung / Retirement" + + beschreibung: | + Ein Service soll nicht mehr weitergeführt werden – entweder + ersatzlos oder durch einen anderen Service ersetzt. + + ausloeser: + - "End-of-Life des Produkts/der Technologie" + - "Strategische Konsolidierung" + - "Service wird nicht mehr benötigt" + + routing: "SO → SOR (RETIRE) → DPM (Retirement-Projekt)" + shm_information: "Ja, zwingend" + + beispiel: + titel: "Ablösung Legacy-Mailsystem" + situation: "DIGIT entscheidet strategisch: Mailsystem ersetzen" + routing: "SO (alt) → SOR → DPM (Retirement + ggf. neues System)" + shm_information: | + SHM übernimmt komplette Stakeholder-Kommunikation: + - Key-Stakeholder: Persönliche Gespräche + - Aktiv-Stakeholder: Strukturierte Information + - Standard/Basis: Schriftliche Ankündigung + + # ------------------------------------------------------------------------- + szenario_4_sicherheit_compliance: + name: "Sicherheits- oder Compliance-Anforderung" + + beschreibung: | + Eine Änderung wird durch Sicherheitsvorgaben, Regulatorik oder + Compliance-Anforderungen notwendig. + + ausloeser: + - "Sicherheitsvorfall oder -erkenntnis" + - "Neue gesetzliche Anforderung" + - "Audit-Feststellung" + - "BSI-Empfehlung" + + routing: "ISB → SOR/SO (je nach Umfang)" + shm_information: "Bei Stakeholder-Auswirkungen" + + beispiel: + titel: "Zwei-Faktor-Authentifizierung verpflichtend" + situation: "Neue Sicherheitsrichtlinie erfordert 2FA" + routing: "ISB → SOR → Umsetzung durch betroffene SOs" + shm_information: | + SHM übernimmt Stakeholder-Kommunikation: + - Erklärung der Notwendigkeit + - Zeitplan und Umstellungsprozess + - Schulungs-/Support-Angebote + + # ------------------------------------------------------------------------- + szenario_5_strategische_initiative: + name: "Strategische DIGIT-Initiative" + + beschreibung: | + DIGIT startet eine übergreifende Initiative, die mehrere Services + betrifft oder neue Infrastruktur schafft. + + ausloeser: + - "IT-Strategie-Umsetzung" + - "Konsolidierungsprojekt" + - "Infrastruktur-Modernisierung" + - "Einführung neuer Basisdienste" + + routing: "DIGIT-Leitung → MB → DPM" + shm_information: "Ja, bei Stakeholder-Auswirkungen" + + beispiel: + titel: "Einführung zentrales Identity Management" + situation: "DIGIT führt IAM-System ein (Single Sign-On)" + routing: "DIGIT-Leitung → MB (Freigabe) → DPM (Programm)" + shm_information: | + SHM wird frühzeitig eingebunden: + - Vorteile kommunizieren + - Migrationsplanung je Amt + - Schulungskonzept + +# ============================================================================= +# ENTSCHEIDUNGSHILFE +# ============================================================================= + +entscheidungshilfe: + + kernfragen: + - frage: "Wer ist Bedarfsträger?" + typ_1: "Externes Amt / Dienststelle" + typ_2: "DIGIT-Mitarbeiter als Nutzer" + typ_3: "SO, ISB, SOR, DIGIT-Leitung" + + - frage: "Woher kommt der Bedarf?" + typ_1: "Stakeholder-Anfrage von außerhalb DIGIT" + typ_2: "Interne Nutzer-Anforderung" + typ_3: "Service-Lifecycle, Sicherheit, Strategie" + + - frage: "Hat der Bedarfsträger fachliche IT-Expertise?" + typ_1: "Nein (fachliche Übersetzung durch SHM nötig)" + typ_2: "Begrenzt (vereinfachte Prüfung ausreichend)" + typ_3: "Ja (Bedarfsträger qualifiziert selbst)" + + grenzfaelle: + + - fall: "Stakeholder beschwert sich, SO erkennt daraus Redesign-Bedarf" + einschaetzung: | + Der initiale Bedarf war extern (Beschwerde) → Typ 1. + Die Schlussfolgerung "Redesign nötig" ist SO-Erkenntnis → Typ 3. + + Routing: Beschwerde über SHM (Typ 1). Wenn SHM an SO routet und + SO dann Redesign empfiehlt, geht der Demand direkt zu DPM (Typ 3). + + - fall: "SO möchte Feature, das Stakeholder auch wünschen" + einschaetzung: | + Entscheidend ist, wer den Bedarf zuerst artikuliert hat: + - Stakeholder zuerst → Typ 1 (SHM-Regelweg) + - SO zuerst → Typ 3 (Service-Lifecycle) + + In der Praxis: SO kann auf Stakeholder-Unterstützung verweisen. + + - fall: "DIGIT-Personalabteilung vs. Personalamt der Stadt" + einschaetzung: | + - DIGIT-Personalabteilung → Typ 2 (Fast Track) + - Personalamt der Stadt (anderes Amt) → Typ 1 (Regelweg) + + Entscheidend ist die organisatorische Zugehörigkeit, nicht die + funktionale Ähnlichkeit. + + - fall: "ISB fordert Änderung, die Stakeholder nicht wollen" + einschaetzung: | + Sicherheits-/Compliance-Anforderungen sind Typ 3, auch wenn sie + Stakeholder-Widerstand erzeugen. + + SHM übernimmt die (ggf. schwierige) Stakeholder-Kommunikation, + aber das Routing bleibt Typ 3 (ISB → SOR/SO). + +# ============================================================================= +# ROUTING-MATRIX (KOMPAKT) +# ============================================================================= + +routing_matrix_kompakt: + + zeilen: + - bedarfstyp: "Extern (Typ 1)" + beispiel: "Bauamt braucht neue Funktion" + eintritt: "SHM" + prozess: "Regelweg" + aufwand: "2-4h" + steckbrief: "Vollständig" + + - bedarfstyp: "Intern-Nutzer (Typ 2)" + beispiel: "DIGIT-Personal braucht Zeiterfassung" + eintritt: "SHM (Fast Track)" + prozess: "3 Schritte" + aufwand: "10-15min" + steckbrief: "Reduziert" + + - bedarfstyp: "Service-Lifecycle (Typ 3)" + beispiel: "SO plant DMS-Modernisierung" + eintritt: "Direkt SOR/DPM" + prozess: "Kein SHM" + aufwand: "0 (SHM)" + steckbrief: "Vom SO" + +# ============================================================================= +# SHM-AUFGABEN JE BEDARFSTYP +# ============================================================================= + +shm_aufgaben_je_typ: + + typ_1_extern: + - "Vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3)" + - "User-Story-Erhebung mit Stakeholder" + - "Bedarfssteckbrief erstellen und validieren" + - "Routing-Entscheidung treffen" + - "Stakeholder-Kommunikation im gesamten Prozess" + + typ_2_intern_nutzer: + - "Fast Track Basistriage (3-5 min)" + - "Schnelle Routing-Entscheidung (5-7 min)" + - "Minimaldokumentation bei ROUTE-DPM-INTERN (3-5 min)" + - "Weiterleitung an SO oder DPM" + + typ_3_service_lifecycle: + - "Keine Routing-Aufgabe" + - "Information bei Stakeholder-Auswirkungen entgegennehmen" + - "Stakeholder-Kommunikation übernehmen (wenn informiert)" + - "Stakeholder-Perspektive in DSR/MB einbringen" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-01-29" + aenderung: "Initiale Erstellung (Fokus auf Service-Lifecycle-Bedarfe)" + autor: "DIGITOM-Projekt" + quelle: "Chat-Session Konzeptprüfung" + + - version: "2.0" + datum: "2025-01-29" + aenderung: | + Komplette Überarbeitung: Drei Bedarfstypen klar unterschieden + - Typ 1: Externe Stakeholder-Bedarfe (Regelweg) + - Typ 2: Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track) + - Typ 3: Service-Lifecycle-Bedarfe (Bypass) + - Visualisierung und Routing-Matrix ergänzt + - Entscheidungshilfe mit Grenzfällen + - SHM-Aufgaben je Bedarfstyp + - Synchronisierung mit shm_bedarfsbewertung.yaml v1.3 + autor: "DIGITOM-Projekt" + quelle: "Chat-Session Konzeptprüfung" diff --git a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_leitfaden_user-stories.yaml b/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_leitfaden_user-stories.yaml index 0322273..9fa930e 100644 --- a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_leitfaden_user-stories.yaml +++ b/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_leitfaden_user-stories.yaml @@ -1,470 +1,470 @@ -# ============================================================================= -# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN -# ============================================================================= -# Modul: Stakeholder-Management (SHM) -# Typ: Arbeitsmaterial (Leitfaden) -# Version: 1.0 -# Datum: 2025-12-09 -# Status: Final -# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131 -# ============================================================================= - -meta: - dokument_id: "SHM-A-01" - name: "Leitfaden User Stories" - typ: "Arbeitsmaterial" - - zweck: | - Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen - aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte - Bedarfe in konkrete, nachvollziehbare Funktionswünsche. - - zielgruppe: "Stakeholder-Manager:innen" - - kontext: | - Im DIGIT-Kontext helfen User Stories, die Perspektive der - Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen. - Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung). - - geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" - - status_dokument: - abgestimmt_zwischen: ["human", "DPM-Teammitglied"] - inhaltlich_abgenommen_durch: - - person: "DPM-Teammitglied" - datum: "2025-09-17" - - person: "DPM-Leitung" - datum: null - abgenommen_in_gesamtkonzept: false - - referenzen: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "schritt_0" - beschreibung: "Integration in Bedarfsbewertungs-Prozess" - - dokument: "shm_schema_bedarfssteckbrief.yaml" - abschnitt: "user_stories" - beschreibung: "Dokumentation der erhobenen User Stories" - -# ============================================================================= -# GRUNDLAGEN -# ============================================================================= - -grundlagen: - - definition: | - User Stories beschreiben Anforderungen aus Sicht der Nutzenden. - Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare - Funktionswünsche. - - grundformat: - schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]" - - elemente: - - element: "Rolle" - beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')" - beispiele: - - "Sachbearbeiter*in Bauamt" - - "Abteilungsleitung" - - "Bürger*in" - - "Antragsteller*in" - - - element: "Funktionalität" - beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)" - beispiele: - - "Bauanträge nach Flurstücknummer durchsuchen" - - "Urlaubsanträge digital genehmigen" - - "Bearbeitungsstatus online einsehen" - - - element: "Nutzen" - beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)" - beispiele: - - "zusammenhängende Anträge schnell identifizieren" - - "Prozess auch im Homeoffice funktioniert" - - "nicht telefonisch nachfragen müssen" - - mehrwert: - - aspekt: "Perspektivwechsel" - beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf" - - - aspekt: "Verständlichkeit" - beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache" - - - aspekt: "Priorisierung" - beschreibung: "Nutzen wird explizit und bewertbar" - - - aspekt: "Validierung" - beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'" - -# ============================================================================= -# SCHRITT-FÜR-SCHRITT-ANLEITUNG -# ============================================================================= - -anleitung: - - # --------------------------------------------------------------------------- - # SCHRITT 1: VORBEREITUNG - # --------------------------------------------------------------------------- - - schritt_1: - name: "Vorbereitung des Gesprächs" - - vor_dem_termin_klaeren: - - "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)" - - "Welcher Prozess ist betroffen?" - - "Gibt es Vorarbeiten oder Dokumentationen?" - - materialien_bereithalten: - - "Bedarfs-Steckbrief" - - "Ggf. Prozessvisualisierung" - - "Beispiel-User-Stories zur Illustration" - - # --------------------------------------------------------------------------- - # SCHRITT 2: EINSTIEG - # --------------------------------------------------------------------------- - - schritt_2: - name: "Einstieg ins Gespräch" - - grundprinzip: - falsch: "Welche User Stories haben Sie?" - richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten." - - leitfragen_einstieg: - - "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt." - - "Was würde Ihnen die Arbeit erleichtern?" - - "Wobei verlieren Sie die meiste Zeit?" - - # --------------------------------------------------------------------------- - # SCHRITT 3: ROLLEN IDENTIFIZIEREN - # --------------------------------------------------------------------------- - - schritt_3: - name: "Die richtigen Rollen identifizieren" - - typische_rollen: - verwaltungsintern: - - "Sachbearbeiter*in [Amt]" - - "Abteilungsleitung" - - "Verwaltungsmitarbeitende" - - "Amtsleitung" - - "Datenschutzbeauftragte*r" - - verwaltungsextern: - - "Bürger*in" - - "Antragsteller*in" - - "Unternehmen" - - "Andere Institute" - - "Dienstleister" - - wichtiger_hinweis: | - Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle" - - # --------------------------------------------------------------------------- - # SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN - # --------------------------------------------------------------------------- - - schritt_4: - name: "Funktionalitäten herausarbeiten" - - prinzip: "Von der Lösung zum Bedarf" - - uebersetzungen: - - stakeholder_sagt: "Wir brauchen eine Datenbank" - shm_fragt: "Was möchten Sie damit tun?" - story_wird: "...möchte ich Anträge zentral verwalten..." - - - stakeholder_sagt: "Das System ist zu langsam" - shm_fragt: "Wobei genau verlieren Sie Zeit?" - story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..." - - - stakeholder_sagt: "Wir wollen alles digitalisieren" - shm_fragt: "Was genau soll digital werden?" - story_wird: "...möchte ich Anträge online einreichen..." - - # --------------------------------------------------------------------------- - # SCHRITT 5: NUTZEN EXPLIZIT MACHEN - # --------------------------------------------------------------------------- - - schritt_5: - name: "Den Nutzen explizit machen" - - nachfragen: - - "Warum ist das wichtig?" - - "Was können Sie dann besser machen?" - - nutzen_kategorien: - - kategorie: "Effizienz" - beispiel: "...damit ich mehr Anträge bearbeiten kann" - - - kategorie: "Qualität" - beispiel: "...damit weniger Fehler passieren" - - - kategorie: "Service" - beispiel: "...damit Bürger*innen schneller Antworten erhalten" - - - kategorie: "Compliance" - beispiel: "...damit wir gesetzeskonform arbeiten" - - - kategorie: "Transparenz" - beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist" - - # --------------------------------------------------------------------------- - # SCHRITT 6: FORMULIEREN - # --------------------------------------------------------------------------- - - schritt_6: - name: "User Stories formulieren" - - beispiel_gut: - rolle: "Sachbearbeiterin im Bauamt" - funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können" - nutzen: "zusammenhängende Anträge schnell identifiziere" - vollstaendig: | - Als Sachbearbeiterin im Bauamt - möchte ich Bauanträge nach Flurstücknummer durchsuchen können - damit ich zusammenhängende Anträge schnell identifiziere - - beispiel_schlecht: - rolle: "Nutzer" - funktionalitaet: "eine bessere Suche" - nutzen: "es schneller geht" - vollstaendig: | - Als Nutzer - möchte ich eine bessere Suche - damit es schneller geht - probleme: - - "Rolle zu unspezifisch" - - "Funktionalität zu vage" - - "Nutzen nicht konkret" - - # --------------------------------------------------------------------------- - # SCHRITT 7: PRIORISIEREN UND VALIDIEREN - # --------------------------------------------------------------------------- - - schritt_7: - name: "Stories priorisieren und validieren" - - validierungsfragen: - - "Habe ich Sie richtig verstanden?" - - "Ist diese Reihenfolge nach Wichtigkeit korrekt?" - - "Fehlt noch etwas Wesentliches?" - - priorisierungsstufen: - - stufe: "Kritisch" - beschreibung: "Ohne geht es nicht" - - - stufe: "Wichtig" - beschreibung: "Deutliche Verbesserung" - - - stufe: "Nützlich" - beschreibung: "Wäre schön" - -# ============================================================================= -# TYPISCHE HERAUSFORDERUNGEN -# ============================================================================= - -herausforderungen: - - # --------------------------------------------------------------------------- - # HERAUSFORDERUNG 1: LÖSUNGSDENKEN - # --------------------------------------------------------------------------- - - loesungsdenken: - name: "Der Stakeholder denkt nur in Lösungen" - - technik: "Die 5-Warum-Methode" - - beispiel_dialog: - - sprecher: "Stakeholder" - aussage: "Wir brauchen ein Dashboard" - - sprecher: "SHM" - aussage: "Warum brauchen Sie ein Dashboard?" - - sprecher: "Stakeholder" - aussage: "Um die Zahlen zu sehen" - - sprecher: "SHM" - aussage: "Warum müssen Sie die Zahlen sehen?" - - sprecher: "Stakeholder" - aussage: "Um zu erkennen, wo sich Anträge stauen" - - resultierende_story: | - Als Abteilungsleitung - möchte ich Engpässe im Antragsprozess erkennen - damit ich Ressourcen umverteilen kann - - # --------------------------------------------------------------------------- - # HERAUSFORDERUNG 2: ALLES DRINGEND - # --------------------------------------------------------------------------- - - alles_dringend: - name: "Alles ist wichtig und dringend" - - technik: "Relatives Priorisieren" - - hilfreiche_fragen: - - "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?" - - "Was würde am meisten wehtun, wenn es fehlt?" - - "Was nutzen Sie täglich vs. was nur monatlich?" - -# ============================================================================= -# QUALITÄTSKRITERIEN -# ============================================================================= - -qualitaetskriterien: - - invest: - name: "INVEST-Kriterien" - beschreibung: "Qualitätsstandard für gute User Stories" - - kriterien: - - buchstabe: "I" - name: "Independent" - beschreibung: "Unabhängig von anderen Stories" - - - buchstabe: "N" - name: "Negotiable" - beschreibung: "Nicht in Stein gemeißelt" - - - buchstabe: "V" - name: "Valuable" - beschreibung: "Klarer Nutzen erkennbar" - - - buchstabe: "E" - name: "Estimable" - beschreibung: "Größe grob einschätzbar" - - - buchstabe: "S" - name: "Small" - beschreibung: "In überschaubarer Zeit umsetzbar" - - - buchstabe: "T" - name: "Testable" - beschreibung: "Überprüfbare Erfolgskriterien" - -# ============================================================================= -# BEISPIEL-STORIES -# ============================================================================= - -beispiel_stories: - - - bereich: "Bürgerservice" - story: - rolle: "Bürger*in" - funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen" - nutzen: "ich nicht telefonisch nachfragen muss" - volltext: | - Als Bürger*in - möchte ich den Bearbeitungsstatus meines Antrags online einsehen - damit ich nicht telefonisch nachfragen muss - - - bereich: "Interne Verwaltung" - story: - rolle: "Personalverantwortliche" - funktionalitaet: "Urlaubsanträge digital genehmigen können" - nutzen: "der Prozess auch im Homeoffice funktioniert" - volltext: | - Als Personalverantwortliche - möchte ich Urlaubsanträge digital genehmigen können - damit der Prozess auch im Homeoffice funktioniert - - - bereich: "Schnittstellen" - story: - rolle: "Mitarbeitende im Einwohnermeldeamt" - funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen" - nutzen: "Bürger*innen sich nicht doppelt melden müssen" - volltext: | - Als Mitarbeitende im Einwohnermeldeamt - möchte ich Meldedaten automatisch ans Finanzamt übertragen - damit Bürger*innen sich nicht doppelt melden müssen - -# ============================================================================= -# CHECKLISTE FÜR SHM -# ============================================================================= - -checkliste: - - name: "Checkliste für Stakeholder-Manager" - - pruefpunkte: - - id: "CK-01" - pruefpunkt: "Rollen spezifisch identifiziert" - beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'" - - - id: "CK-02" - pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)" - beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'" - - - id: "CK-03" - pruefpunkt: "Nutzen explizit gemacht" - beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'" - - - id: "CK-04" - pruefpunkt: "Stories mit Stakeholder validiert" - beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'" - - - id: "CK-05" - pruefpunkt: "Prioritäten geklärt" - beispiel: "Kritisch / Wichtig / Nützlich zugeordnet" - - - id: "CK-06" - pruefpunkt: "Zusammenhang zum Problem hergestellt" - beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse" - - - id: "CK-07" - pruefpunkt: "In Bedarfs-Steckbrief übertragen" - beispiel: "Stories im Schema-konformen Format dokumentiert" - -# ============================================================================= -# DOKUMENTATION -# ============================================================================= - -dokumentation: - - nach_dem_gespraech: - - schritt: 1 - aktion: "Stories im Steckbrief sauber dokumentieren" - - schritt: 2 - aktion: "Priorisierung vermerken" - - schritt: 3 - aktion: "Offene Punkte notieren" - - schritt: 4 - aktion: "Validierungstermin vereinbaren" - - ablage: - ziel_dokument: "Bedarfs-Steckbrief" - ziel_abschnitt: "user_stories" - schema_referenz: "shm_schema_bedarfssteckbrief.yaml" - -# ============================================================================= -# HINWEISE -# ============================================================================= - -hinweise: - - - typ: "Tipp" - text: | - Die erste User Story ist die schwerste. Mit etwas Übung entwickeln - Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe - strukturiert zu erfassen. - - - typ: "Warnung" - text: | - Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist - es, den Bedarf zu verstehen – nicht, ihn zu lösen. - - - typ: "Best Practice" - text: | - Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie - konkrete User Stories formulieren. Der Kontext hilft, die - richtigen Fragen zu stellen. - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2025-12-09" - aenderung: "Initiale Erstellung aus PDF-Vorlage" - autor: "DIGITOM-Projekt" +# ============================================================================= +# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN +# ============================================================================= +# Modul: Stakeholder-Management (SHM) +# Typ: Arbeitsmaterial (Leitfaden) +# Version: 1.0 +# Datum: 2025-12-09 +# Status: Final +# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131 +# ============================================================================= + +meta: + dokument_id: "SHM-A-01" + name: "Leitfaden User Stories" + typ: "Arbeitsmaterial" + + zweck: | + Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen + aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte + Bedarfe in konkrete, nachvollziehbare Funktionswünsche. + + zielgruppe: "Stakeholder-Manager:innen" + + kontext: | + Im DIGIT-Kontext helfen User Stories, die Perspektive der + Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen. + Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung). + + geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" + + status_dokument: + abgestimmt_zwischen: ["human", "DPM-Teammitglied"] + inhaltlich_abgenommen_durch: + - person: "DPM-Teammitglied" + datum: "2025-09-17" + - person: "DPM-Leitung" + datum: null + abgenommen_in_gesamtkonzept: false + + referenzen: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "schritt_0" + beschreibung: "Integration in Bedarfsbewertungs-Prozess" + - dokument: "shm_schema_bedarfssteckbrief.yaml" + abschnitt: "user_stories" + beschreibung: "Dokumentation der erhobenen User Stories" + +# ============================================================================= +# GRUNDLAGEN +# ============================================================================= + +grundlagen: + + definition: | + User Stories beschreiben Anforderungen aus Sicht der Nutzenden. + Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare + Funktionswünsche. + + grundformat: + schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]" + + elemente: + - element: "Rolle" + beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')" + beispiele: + - "Sachbearbeiter*in Bauamt" + - "Abteilungsleitung" + - "Bürger*in" + - "Antragsteller*in" + + - element: "Funktionalität" + beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)" + beispiele: + - "Bauanträge nach Flurstücknummer durchsuchen" + - "Urlaubsanträge digital genehmigen" + - "Bearbeitungsstatus online einsehen" + + - element: "Nutzen" + beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)" + beispiele: + - "zusammenhängende Anträge schnell identifizieren" + - "Prozess auch im Homeoffice funktioniert" + - "nicht telefonisch nachfragen müssen" + + mehrwert: + - aspekt: "Perspektivwechsel" + beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf" + + - aspekt: "Verständlichkeit" + beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache" + + - aspekt: "Priorisierung" + beschreibung: "Nutzen wird explizit und bewertbar" + + - aspekt: "Validierung" + beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'" + +# ============================================================================= +# SCHRITT-FÜR-SCHRITT-ANLEITUNG +# ============================================================================= + +anleitung: + + # --------------------------------------------------------------------------- + # SCHRITT 1: VORBEREITUNG + # --------------------------------------------------------------------------- + + schritt_1: + name: "Vorbereitung des Gesprächs" + + vor_dem_termin_klaeren: + - "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)" + - "Welcher Prozess ist betroffen?" + - "Gibt es Vorarbeiten oder Dokumentationen?" + + materialien_bereithalten: + - "Bedarfs-Steckbrief" + - "Ggf. Prozessvisualisierung" + - "Beispiel-User-Stories zur Illustration" + + # --------------------------------------------------------------------------- + # SCHRITT 2: EINSTIEG + # --------------------------------------------------------------------------- + + schritt_2: + name: "Einstieg ins Gespräch" + + grundprinzip: + falsch: "Welche User Stories haben Sie?" + richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten." + + leitfragen_einstieg: + - "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt." + - "Was würde Ihnen die Arbeit erleichtern?" + - "Wobei verlieren Sie die meiste Zeit?" + + # --------------------------------------------------------------------------- + # SCHRITT 3: ROLLEN IDENTIFIZIEREN + # --------------------------------------------------------------------------- + + schritt_3: + name: "Die richtigen Rollen identifizieren" + + typische_rollen: + verwaltungsintern: + - "Sachbearbeiter*in [Amt]" + - "Abteilungsleitung" + - "Verwaltungsmitarbeitende" + - "Amtsleitung" + - "Datenschutzbeauftragte*r" + + verwaltungsextern: + - "Bürger*in" + - "Antragsteller*in" + - "Unternehmen" + - "Andere Institute" + - "Dienstleister" + + wichtiger_hinweis: | + Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle" + + # --------------------------------------------------------------------------- + # SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN + # --------------------------------------------------------------------------- + + schritt_4: + name: "Funktionalitäten herausarbeiten" + + prinzip: "Von der Lösung zum Bedarf" + + uebersetzungen: + - stakeholder_sagt: "Wir brauchen eine Datenbank" + shm_fragt: "Was möchten Sie damit tun?" + story_wird: "...möchte ich Anträge zentral verwalten..." + + - stakeholder_sagt: "Das System ist zu langsam" + shm_fragt: "Wobei genau verlieren Sie Zeit?" + story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..." + + - stakeholder_sagt: "Wir wollen alles digitalisieren" + shm_fragt: "Was genau soll digital werden?" + story_wird: "...möchte ich Anträge online einreichen..." + + # --------------------------------------------------------------------------- + # SCHRITT 5: NUTZEN EXPLIZIT MACHEN + # --------------------------------------------------------------------------- + + schritt_5: + name: "Den Nutzen explizit machen" + + nachfragen: + - "Warum ist das wichtig?" + - "Was können Sie dann besser machen?" + + nutzen_kategorien: + - kategorie: "Effizienz" + beispiel: "...damit ich mehr Anträge bearbeiten kann" + + - kategorie: "Qualität" + beispiel: "...damit weniger Fehler passieren" + + - kategorie: "Service" + beispiel: "...damit Bürger*innen schneller Antworten erhalten" + + - kategorie: "Compliance" + beispiel: "...damit wir gesetzeskonform arbeiten" + + - kategorie: "Transparenz" + beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist" + + # --------------------------------------------------------------------------- + # SCHRITT 6: FORMULIEREN + # --------------------------------------------------------------------------- + + schritt_6: + name: "User Stories formulieren" + + beispiel_gut: + rolle: "Sachbearbeiterin im Bauamt" + funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können" + nutzen: "zusammenhängende Anträge schnell identifiziere" + vollstaendig: | + Als Sachbearbeiterin im Bauamt + möchte ich Bauanträge nach Flurstücknummer durchsuchen können + damit ich zusammenhängende Anträge schnell identifiziere + + beispiel_schlecht: + rolle: "Nutzer" + funktionalitaet: "eine bessere Suche" + nutzen: "es schneller geht" + vollstaendig: | + Als Nutzer + möchte ich eine bessere Suche + damit es schneller geht + probleme: + - "Rolle zu unspezifisch" + - "Funktionalität zu vage" + - "Nutzen nicht konkret" + + # --------------------------------------------------------------------------- + # SCHRITT 7: PRIORISIEREN UND VALIDIEREN + # --------------------------------------------------------------------------- + + schritt_7: + name: "Stories priorisieren und validieren" + + validierungsfragen: + - "Habe ich Sie richtig verstanden?" + - "Ist diese Reihenfolge nach Wichtigkeit korrekt?" + - "Fehlt noch etwas Wesentliches?" + + priorisierungsstufen: + - stufe: "Kritisch" + beschreibung: "Ohne geht es nicht" + + - stufe: "Wichtig" + beschreibung: "Deutliche Verbesserung" + + - stufe: "Nützlich" + beschreibung: "Wäre schön" + +# ============================================================================= +# TYPISCHE HERAUSFORDERUNGEN +# ============================================================================= + +herausforderungen: + + # --------------------------------------------------------------------------- + # HERAUSFORDERUNG 1: LÖSUNGSDENKEN + # --------------------------------------------------------------------------- + + loesungsdenken: + name: "Der Stakeholder denkt nur in Lösungen" + + technik: "Die 5-Warum-Methode" + + beispiel_dialog: + - sprecher: "Stakeholder" + aussage: "Wir brauchen ein Dashboard" + - sprecher: "SHM" + aussage: "Warum brauchen Sie ein Dashboard?" + - sprecher: "Stakeholder" + aussage: "Um die Zahlen zu sehen" + - sprecher: "SHM" + aussage: "Warum müssen Sie die Zahlen sehen?" + - sprecher: "Stakeholder" + aussage: "Um zu erkennen, wo sich Anträge stauen" + + resultierende_story: | + Als Abteilungsleitung + möchte ich Engpässe im Antragsprozess erkennen + damit ich Ressourcen umverteilen kann + + # --------------------------------------------------------------------------- + # HERAUSFORDERUNG 2: ALLES DRINGEND + # --------------------------------------------------------------------------- + + alles_dringend: + name: "Alles ist wichtig und dringend" + + technik: "Relatives Priorisieren" + + hilfreiche_fragen: + - "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?" + - "Was würde am meisten wehtun, wenn es fehlt?" + - "Was nutzen Sie täglich vs. was nur monatlich?" + +# ============================================================================= +# QUALITÄTSKRITERIEN +# ============================================================================= + +qualitaetskriterien: + + invest: + name: "INVEST-Kriterien" + beschreibung: "Qualitätsstandard für gute User Stories" + + kriterien: + - buchstabe: "I" + name: "Independent" + beschreibung: "Unabhängig von anderen Stories" + + - buchstabe: "N" + name: "Negotiable" + beschreibung: "Nicht in Stein gemeißelt" + + - buchstabe: "V" + name: "Valuable" + beschreibung: "Klarer Nutzen erkennbar" + + - buchstabe: "E" + name: "Estimable" + beschreibung: "Größe grob einschätzbar" + + - buchstabe: "S" + name: "Small" + beschreibung: "In überschaubarer Zeit umsetzbar" + + - buchstabe: "T" + name: "Testable" + beschreibung: "Überprüfbare Erfolgskriterien" + +# ============================================================================= +# BEISPIEL-STORIES +# ============================================================================= + +beispiel_stories: + + - bereich: "Bürgerservice" + story: + rolle: "Bürger*in" + funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen" + nutzen: "ich nicht telefonisch nachfragen muss" + volltext: | + Als Bürger*in + möchte ich den Bearbeitungsstatus meines Antrags online einsehen + damit ich nicht telefonisch nachfragen muss + + - bereich: "Interne Verwaltung" + story: + rolle: "Personalverantwortliche" + funktionalitaet: "Urlaubsanträge digital genehmigen können" + nutzen: "der Prozess auch im Homeoffice funktioniert" + volltext: | + Als Personalverantwortliche + möchte ich Urlaubsanträge digital genehmigen können + damit der Prozess auch im Homeoffice funktioniert + + - bereich: "Schnittstellen" + story: + rolle: "Mitarbeitende im Einwohnermeldeamt" + funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen" + nutzen: "Bürger*innen sich nicht doppelt melden müssen" + volltext: | + Als Mitarbeitende im Einwohnermeldeamt + möchte ich Meldedaten automatisch ans Finanzamt übertragen + damit Bürger*innen sich nicht doppelt melden müssen + +# ============================================================================= +# CHECKLISTE FÜR SHM +# ============================================================================= + +checkliste: + + name: "Checkliste für Stakeholder-Manager" + + pruefpunkte: + - id: "CK-01" + pruefpunkt: "Rollen spezifisch identifiziert" + beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'" + + - id: "CK-02" + pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)" + beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'" + + - id: "CK-03" + pruefpunkt: "Nutzen explizit gemacht" + beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'" + + - id: "CK-04" + pruefpunkt: "Stories mit Stakeholder validiert" + beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'" + + - id: "CK-05" + pruefpunkt: "Prioritäten geklärt" + beispiel: "Kritisch / Wichtig / Nützlich zugeordnet" + + - id: "CK-06" + pruefpunkt: "Zusammenhang zum Problem hergestellt" + beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse" + + - id: "CK-07" + pruefpunkt: "In Bedarfs-Steckbrief übertragen" + beispiel: "Stories im Schema-konformen Format dokumentiert" + +# ============================================================================= +# DOKUMENTATION +# ============================================================================= + +dokumentation: + + nach_dem_gespraech: + - schritt: 1 + aktion: "Stories im Steckbrief sauber dokumentieren" + - schritt: 2 + aktion: "Priorisierung vermerken" + - schritt: 3 + aktion: "Offene Punkte notieren" + - schritt: 4 + aktion: "Validierungstermin vereinbaren" + + ablage: + ziel_dokument: "Bedarfs-Steckbrief" + ziel_abschnitt: "user_stories" + schema_referenz: "shm_schema_bedarfssteckbrief.yaml" + +# ============================================================================= +# HINWEISE +# ============================================================================= + +hinweise: + + - typ: "Tipp" + text: | + Die erste User Story ist die schwerste. Mit etwas Übung entwickeln + Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe + strukturiert zu erfassen. + + - typ: "Warnung" + text: | + Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist + es, den Bedarf zu verstehen – nicht, ihn zu lösen. + + - typ: "Best Practice" + text: | + Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie + konkrete User Stories formulieren. Der Kontext hilft, die + richtigen Fragen zu stellen. + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2025-12-09" + aenderung: "Initiale Erstellung aus PDF-Vorlage" + autor: "DIGITOM-Projekt" quelle: "Konzept_DPM_Abnahme20230925, Seiten 125-131" \ No newline at end of file diff --git a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_sims-konzept.yaml b/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_sims-konzept.yaml deleted file mode 100644 index 4461b4b..0000000 --- a/#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_sims-konzept.yaml +++ /dev/null @@ -1,20 +0,0 @@ -# ======================================== -# Stakeholder-Informations-Management-System (SIMS) -# ======================================== -# Version: 0.1 (Platzhalter) -# Datum: 2024-12-03 -# Status: Ausstehend -# Entwicklungsphase: 11 -# ======================================== - -# ITIL4-Referenz (falls zutreffend): -# itil4_referenz: -# practice: "" -# relevante_elemente: [] -# adaption_fuer_digitom: "" - -# ======================================== -# INHALT -# ======================================== - -# [Inhalt folgt in Phase 11] diff --git a/#03_stakeholder-management/readme_shm_governance-entscheidungs-log.yaml b/#03_stakeholder-management/readme_shm_governance-entscheidungs-log.yaml index f09e431..c0c7908 100644 --- a/#03_stakeholder-management/readme_shm_governance-entscheidungs-log.yaml +++ b/#03_stakeholder-management/readme_shm_governance-entscheidungs-log.yaml @@ -1,1361 +1,1361 @@ -# ============================================================================= -# SHM GOVERNANCE-ENTSCHEIDUNGS-LOG -# ============================================================================= -# Version: 1.8 -# Datum: 2026-01-23 -# Letzte Änderung: Bedarfsrouting SO-Klärung (GOV-SHM-029) -# Status: Final -# Quelle: Chat-Session SHM-Konzeptentwicklung -# ============================================================================= - -meta: - beschreibung: | - Dokumentation aller Governance-Entscheidungen, die während der - Entwicklung des SHM Stakeholder-Portfolio-Konzepts getroffen wurden. - - kontext: | - Diese Entscheidungen wurden in der Chat-Session zur Phase 1 - (Stakeholder-Portfolio-Modellierung) erarbeitet und bilden die - Grundlage für die MVP-Konzeption. - - referenz_arbeitsdokumente: - - "[tmp]_shm_amtssteckbrief.yaml" - - "[tmp]_shm_stakeholder-segmentierung.yaml" - - "[tmp]_shm_stakeholder-priorisierung.yaml" - -# ============================================================================= -# ENTSCHEIDUNGEN: GRUNDSTRUKTUR -# ============================================================================= - -entscheidungen: - - # --------------------------------------------------------------------------- - # PORTFOLIO-STRUKTUR - # --------------------------------------------------------------------------- - - - id: GOV-SHM-001 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio" - - frage: | - Welche Grundstruktur hat das Stakeholder-Portfolio? - - entscheidung: | - Drei-Ebenen-Modell: - 1. Amts-Steckbrief (Datengrundlage pro Amt) - 2. Segmentierung (Clustering nach zwei Dimensionen) - 3. Priorisierung (Bewertung zur Betreuungsallokation) - - begruendung: | - Das Portfolio muss drei Kernentscheidungen unterstützen: - - E1: Betreuungsallokation (Wer wird wie intensiv betreut?) - - E2: Bedarfsrouting (Wohin gehört dieser Bedarf?) - - E3: Governance-Zuordnung (Wer sitzt in welchem Gremium?) - - Die drei Ebenen adressieren diese Entscheidungen systematisch. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Gesamtstruktur" - - status: final - - # --------------------------------------------------------------------------- - # SEGMENTIERUNG - # --------------------------------------------------------------------------- - - - id: GOV-SHM-002 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Segmentierung" - - frage: | - Nach welcher Logik werden Ämter segmentiert? - - entscheidung: | - Zweidimensionale Segmentierung: - - Dimension 1: Funktion (organisatorische Rolle) - - Dimension 2: IT-Anforderungsprofil (Bedarfskomplexität) - - Beide Dimensionen sind unabhängig. Jedes Amt erhält genau eine - Ausprägung pro Dimension (keine Mehrfachzuordnung/Tags). - - begruendung: | - Die ursprüngliche Drei-Cluster-Logik (Querschnitt, Bürgerkontakt, - Technisch) vermischte verschiedene Dimensionen (Funktion, Arbeitsweise, - Anforderungsniveau). Die zweidimensionale Struktur trennt diese - sauber und ermöglicht differenziertere Zuordnung. - - verworfene_alternativen: - - option: "Eindimensionale Cluster nach Bedarfsprofil" - grund: "Nicht trennscharf, viele Überlappungen" - - option: "Tagging statt exklusiver Zuordnung" - grund: "Erhöht Komplexität ohne klaren Mehrwert" - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Segmentierung" - - dokument: "[tmp]_shm_stakeholder-segmentierung.yaml" - abschnitt: "grundkonzept" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-003 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Segmentierung" - - frage: | - Welche Ausprägungen hat Dimension 1 (Funktion)? - - entscheidung: | - Vier Ausprägungen mit Entscheidungsbaum-Logik: - - 1. Sondereinheit – Eigenbetriebe, Stabsstellen, Projektgruppen - 2. Querschnitt – Verwaltungsinterne Unterstützungsfunktion - 3. Bürgerservice – Direkter Bürgerkontakt als Kernaufgabe - 4. Fachamt – Spezialisierte Fachaufgabe (Default) - - Zuordnungslogik (erste zutreffende Kategorie gewinnt): - Sondereinheit → Querschnitt → Bürgerservice → Fachamt - - begruendung: | - - "Sondereinheit" wurde ergänzt für Eigenbetriebe etc., die - organisatorisch anders strukturiert sind - - Entscheidungsbaum-Logik vermeidet Mehrdeutigkeiten - - "Fachamt" als Default fängt alle nicht anderweitig zuordenbaren Ämter - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Segmentierung / Dimension 1" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-004 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Segmentierung" - - frage: | - Welche Ausprägungen hat Dimension 2 (IT-Anforderungsprofil)? - - entscheidung: | - Drei Ausprägungen (bedarfsorientiert, nicht nutzungsorientiert): - - 1. Basis – Standardbedarf, Grundausstattung reicht aus - 2. Erweitert – Fachspezifische Bedarfe über Standard hinaus - 3. Spezial – Individuelle Bedarfe, die nur für dieses Amt gelten - - Zuordnungslogik (Entscheidungsbaum): - 1. Individuelle IT-Bedarfe nur für dieses Amt? → Spezial - 2. Fachspezifische Bedarfe über Grundausstattung? → Erweitert - 3. Sonst → Basis - - begruendung: | - - Bedarfsorientiert (nicht nutzungsorientiert), um zukünftige - Bedarfe vorherzusagen, nicht nur Status quo abzubilden - - Terminologie harmonisiert mit SPM Service-Kategorien (siehe GOV-SHM-005) - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Segmentierung / Dimension 2" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-005 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / SPM-Harmonisierung" - - frage: | - Wie wird terminologische Konsistenz zwischen SHM und SPM hergestellt? - - entscheidung: | - Harmonisierte Terminologie für IT-Profile (SHM) und Service-Kategorien (SPM): - - | SHM IT-Profil | SPM Service-Kategorie | - |---------------|----------------------| - | Basis | A – Basis-Services | - | Erweitert | B – Erweiterte Services | - | Spezial | C – Spezial-Services | - - Erforderliche Änderung im SPM: - Kategorie B wird von "Modular-Services" zu "Erweiterte Services" umbenannt. - - begruendung: | - - "Modular" beschreibt die Architektur des Services (zubuchbar) - - "Erweitert" beschreibt die Beziehung zum Basis-Level - - "Erweitert" funktioniert für beide Perspektiven (Service und Amt) - - auswirkung_auf: - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "Service-Kategorien" - - dokument: "spm_practice_service-catalog-management.yaml" - abschnitt: "Kategorien-Logik" - - dokument: "spm_schema_service-definition.yaml" - abschnitt: "Enum-Werte" - - status: draft # Umsetzung im SPM noch ausstehend - - offene_fragen: - - "Governance-Entscheidung ins SPM-Log übertragen" - - "Templates anpassen" - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-006 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Segmentierung" - - frage: | - Haben Sondereinheiten (Eigenbetriebe etc.) auch ein IT-Anforderungsprofil? - - entscheidung: | - Ja. Sondereinheiten sind eine Funktionskategorie, keine Ausnahme - von der zweidimensionalen Logik. Sie werden wie alle anderen Ämter - in die Matrix (Funktion × IT-Profil) eingeordnet. - - Beispiele: - - Eigenbetrieb Stadtentwässerung → Sondereinheit + Spezial - - Eigenbetrieb Theater → Sondereinheit + Basis - - begruendung: | - Sondereinheiten sind organisatorisch anders, haben aber trotzdem - IT-Bedarfe, die für Betreuung und Governance relevant sind. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Matrix-Beschreibung" - - status: final - - # --------------------------------------------------------------------------- - # PRIORISIERUNG - # --------------------------------------------------------------------------- - - - id: GOV-SHM-007 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Nach welchen Dimensionen werden Stakeholder priorisiert? - - entscheidung: | - Drei Dimensionen (binär bewertet): - - 1. Einfluss – Kann das Amt DIGIT-relevante Entscheidungen beeinflussen? - Indikatoren: Entscheidungsbefugnis über IT-Budgets/Standards ODER - Multiplikator-Rolle durch Größe/Querschnittsfunktion - - 2. Abhängigkeit – Steht das Amt ohne IT still? - Indikatoren: Kernprozesse IT-abhängig ODER externe Schnittstellen - setzen funktionierende IT voraus - - 3. Relevanz – Ist das Amt gerade besonders wichtig für die Gesamtverwaltung? - Indikatoren: Hohe politische/öffentliche Sichtbarkeit ODER - Beteiligung an strategischen Projekten - - begruendung: | - - Basiert auf SALI-Modell aus Workshop, aber angepasst: - - "Macht/Einfluss" → "Einfluss" (präzisiert) - - "Legitimität" → größtenteils durch Scope-Definition abgedeckt - - "Dringlichkeit" → aufgeteilt in "Abhängigkeit" und "Relevanz" - - Binäre Bewertung (ja/nein) für Nachvollziehbarkeit - - "Bedarfsvolumen" bewusst ausgeschlossen (ist Symptom, nicht Kriterium) - - verworfene_alternativen: - - option: "SALI mit Legitimität" - grund: "Legitimität teilweise durch Scope-Definition abgedeckt" - - option: "Bedarfsvolumen als Dimension" - grund: "Ist Symptom, nicht strategisches Kriterium" - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Priorisierung / Dimensionen" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-008 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Wie werden die Priorisierungsdimensionen gewichtet? - - entscheidung: | - Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt - beeinflussen können. - - Gewichtung: Einfluss > Abhängigkeit = Relevanz - - begruendung: | - Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen - von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist - strategisch wichtiger als zu Ämtern, die "nur" abhängig sind. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Priorisierung / Kombinationslogik" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-009 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Welche Prio-Stufen gibt es und wie ergeben sie sich aus den Dimensionen? - - entscheidung: | - Vier Prio-Stufen mit folgender Kombinationslogik: - - | Prio-Stufe | Kombination | - |------------|------------------------------------------| - | Key | Alle drei ODER Einfluss + eine weitere | - | Aktiv | Zwei (ohne Einfluss) ODER nur Einfluss | - | Standard | Eine (Abhängigkeit oder Relevanz) | - | Basis | Keine Dimension erfüllt | - - Vollständige Kombinationstabelle: - | E | A | R | Prio-Stufe | - |---|---|---|------------| - | ✓ | ✓ | ✓ | Key | - | ✓ | ✓ | – | Key | - | ✓ | – | ✓ | Key | - | – | ✓ | ✓ | Aktiv | - | ✓ | – | – | Aktiv | - | – | ✓ | – | Standard | - | – | – | ✓ | Standard | - | – | – | – | Basis | - - begruendung: | - - Vier Stufen sind ausreichend differenziert für ~40-50 Ämter - - Einfluss-Gewichtung spiegelt sich in Kombinationslogik wider - - Sieben Prio-Stufen (wie im SALI-Original) wären zu granular - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Priorisierung / Kombinationslogik" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-010 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Welcher Betreuungsmodus ergibt sich aus welcher Prio-Stufe? - - entscheidung: | - | Prio-Stufe | Betreuungsmodus | Konkret | - |------------|---------------------|--------------------------------------------------| - | Key | Proaktiv/Dediziert | Turnusgespräche, dedizierter SM, aktive Bedarfserhebung | - | Aktiv | Regelmäßig | Advisory Board, anlassbezogene Gespräche | - | Standard | Eingebunden | Advisory Board, reaktiv bei Anfragen | - | Basis | Reaktiv | Nur bei eingehenden Anfragen | - - begruendung: | - Abstufung der Betreuungsintensität entsprechend der Ressourcenverfügbarkeit - und strategischen Bedeutung. Key-Stakeholder erhalten dedizierte Betreuung, - andere werden über Cluster-Formate (Advisory Boards) eingebunden. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Priorisierung / Betreuungsmodus" - - dokument: "shm_engagement-framework.yaml" - abschnitt: "Betreuungskonzepte (noch zu entwickeln)" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-011 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Gibt es eine Obergrenze für die Anzahl Key-Stakeholder? - - entscheidung: | - Nein. Im ersten Schritt wird ohne Cap modelliert. - - begruendung: | - - Die Kombinationslogik führt organisch zu einer begrenzten Anzahl - - Ein künstliches Cap könnte relevante Stakeholder ausschließen - - Nach empirischer Validierung kann ggf. nachjustiert werden - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Priorisierung" - - status: final - - offene_fragen: - - "Nach empirischer Validierung prüfen, ob Anzahl Key-Stakeholder handhabbar ist" - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-012 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Priorisierung" - - frage: | - Wie oft wird die Priorisierung überprüft? - - entscheidung: | - Die Priorisierung wird periodisch im Rahmen der Koordinations- und - Steuerungsstruktur überprüft (E2-Standard und E2-Erweitert Review-Zyklen). - - Insbesondere die Dimension "Relevanz" kann sich ändern (politische - Themen kommen und gehen) und erfordert regelmäßige Aktualisierung. - - begruendung: | - - Einfluss und Abhängigkeit sind relativ stabil - - Relevanz ist dynamisch (politische Themen, strategische Projekte) - - Integration in bestehenden Review-Prozess vermeidet Zusatzaufwand - - auswirkung_auf: - - dokument: "shm_portfolio-review.yaml" - abschnitt: "Review-Aktivitäten (noch zu entwickeln)" - - status: final - - # --------------------------------------------------------------------------- - # AMTS-STECKBRIEF - # --------------------------------------------------------------------------- - - - id: GOV-SHM-013 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" - - frage: | - Wer ist der primäre Ansprechpartner für SLA-Befugnis? - - entscheidung: | - Analog zur SPM-Logik (P-02 SLM): - - Primär: Amtsleitung - - Alternativ: Delegierte Person mit dokumentierter Entscheidungsbefugnis - - Die Delegation muss dokumentiert sein. - - begruendung: | - Konsistenz mit SPM-Governance. SLA-Partner müssen Entscheidungsbefugnis - haben, nicht nur operative Ansprechpartner sein. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Amts-Steckbrief / Stammdaten" - - referenz: - - dokument: "spm_practice_service-level-management.yaml" - entscheidung: "GOV-005" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-014 - datum: 2025-12-03 - quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" - - frage: | - Welche Organisationseinheiten sind im Scope des Stakeholder-Portfolios? - - entscheidung: | - Alle Einheiten im Dezernatsverteilungsplan: - - Ämter - - Eigenbetriebe - - Referate - - Stabsstellen - - Projektgruppen - - begruendung: | - Breiter Scope sichert vollständige Abdeckung. Die Segmentierung - (insbesondere "Sondereinheit") ermöglicht differenzierte Behandlung. - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "Scope" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-015 - datum: 2025-12-09 - quelle_modul: "SHM Engagement-Framework (Phase 2)" - - frage: | - Sollen die SHM-Advisory-Boards und die SLM-Kundenvertretungen - als separate Gremien geführt werden? - - entscheidung: | - Nein. Die Formate werden zu einem integrierten "Kundenforum"-Konzept - konsolidiert: - - 1. Kundenforum Basisservices (für Kat. A): - - Vereint SLA-Review (SLM) und Beziehungspflege/Bedarfssammlung (SHM) - - Frequenz: Jährlich (Pilotierungs-Vorbehalt) - - Gemeinsame Moderation: Service Owner + Stakeholder-Manager - - Zusammensetzung: Pflichtvertreter (Querschnittsämter) + Rotation - - 2. Kundenforum [Service] (für Kat. B): - - Primär SLA-Review, SHM-Beteiligung optional - - Frequenz: Jährlich - - Leitung: Service Owner - - 3. Bilaterale Formate (für Kat. C und Key-Stakeholder): - - Kombination aus SLA-Themen und strategischen Themen - - SO und SHM nach Bedarf gemeinsam oder getrennt - - begruendung: | - - Vermeidung von Gremien-Redundanz (gleiche Teilnehmer, ähnliche Themen) - - Ressourceneffizienz (weniger Termine für Ämter und DIGIT) - - Stärkung der "One DIGIT"-Wahrnehmung - - Natürliche Integration von Service-Qualität und Beziehungsqualität - - auswirkung_auf: - - dokument: "shm_engagement-framework.yaml" - abschnitt: "kollektive_formate" - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "kundenvertretung, slm_09" - - status: "final" - - offene_punkte: - - "Konkrete Besetzung Pflichtvertreter (Abstimmung mit Verwaltung)" - - "Frequenz-Validierung in Pilotierung" - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-016 - datum: 2025-12-09 - quelle_modul: "Bedarfsbewertung (Phase 3)" - - frage: | - Beeinflusst die Stakeholder-Priorität das Routing? - - entscheidung: | - Nein. Das Routing basiert ausschließlich auf der Sachfrage - "Was ist der Bedarf?". Die Stakeholder-Priorität beeinflusst - die Bearbeitungsgeschwindigkeit, nicht das Ziel. - - begruendung: | - Routing muss sachlogisch nachvollziehbar sein. Ein Demand bleibt - ein Demand, unabhängig davon, wer ihn einreicht. - - auswirkung_auf: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "stakeholder_kontext" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-017 - datum: 2025-12-09 - quelle_modul: "Bedarfsbewertung (Phase 3)" - - frage: | - Welche Kriterien triggern eine Routing-Klärung? - - entscheidung: | - Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. - Es gibt keine quantitativen Schwellenwerte. - - begruendung: | - Objektivierte Kriterien würden zu Schein-Objektivität führen. - Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu - erkennen und angemessen zu eskalieren. - - auswirkung_auf: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "dsr_routing_klaerung" - - status: final - - nachtrag: - datum: "2025-12-17" - aenderung: | - Demand-Routing erfolgt direkt an DPM (nicht über DSR). - Siehe GOV-SOR-001: Demand-Routing geht direkt an DPM. DSR nur für Portfolio-Governance. - referenz: "GOV-SOR-001" - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-018 - datum: 2025-12-09 - quelle_modul: "Bedarfsbewertung (Phase 3)" - - frage: | - Prüft SHM die Service-Kategorie (A/B/C) bei der Bewertung? - - entscheidung: | - Nein. Die Service-Kategorie ist informativ (aus Amts-Steckbrief), - aber nicht entscheidungsrelevant für das Routing. - - begruendung: | - Die konkrete Service-Kategorie-Zuordnung ist Aufgabe von SPM/SO. - SHM prüft nur: "Ist der Bedarf katalog-abbildbar?" - - auswirkung_auf: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "abgrenzung" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-019 - datum: 2025-12-09 - quelle_modul: "Bedarfsbewertung (Phase 3)" - - frage: | - Ist eine Aufwandsschätzung routing-relevant? - - entscheidung: | - Nein. Die Aufwandsschätzung im Bedarfssteckbrief ist informativ - für den Empfänger, aber nicht entscheidungsrelevant für das Routing. - - begruendung: | - Die Frage "Was ist es?" ist unabhängig von "Wie groß ist es?". - Ein kleiner Demand bleibt ein Demand. - - auswirkung_auf: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "funktionale_herleitung" - - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-020 - datum: 2025-12-09 - quelle_modul: "Bedarfsbewertung (Phase 3) / Bedarfssteckbrief-Schema" - - frage: | - Welche Pflichtfelder gelten für welchen Routing-Pfad? - - entscheidung: | - Die Validierungsanforderungen im Bedarfssteckbrief variieren je nach - Routing-Ziel: - - 1. ROUTE-REQ: Kein Steckbrief erforderlich - 2. ROUTE-SPM: Reduzierter Steckbrief (Basisdaten, Bedarfsbeschreibung, - Service-Katalog-Prüfung). Keine Stakeholder-Freigabe erforderlich. - 3. ROUTE-DPM: Demand geht direkt an DPM. Reduzierter Steckbrief + - SHM-Einschätzung. Keine DSR-Bestätigung für Demands nötig. - 4. ROUTE-DPM: Vollständiger Steckbrief inkl. User Stories, Abhängigkeiten, - Größeneinschätzung. Stakeholder-Freigabe erforderlich (Quality Gate 1). - - Die Validierungsregel VAL-BED-004 wird entsprechend präzisiert. - - begruendung: | - Nicht jeder Routing-Pfad erfordert den gleichen Dokumentationsaufwand. - SPM-Changes können mit reduziertem Steckbrief erfolgen. - Nur DPM-Übergaben erfordern die formale Stakeholder-Freigabe, da hier - das Quality Gate 1 des Demand-to-Product-Prozesses greift. - - auswirkung_auf: - - dokument: "shm_schema_bedarfssteckbrief.yaml" - abschnitt: "validierungsprofile, validierung.regeln.VAL-BED-004" - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "routing_pfade" - - status: final - - nachtrag: - datum: "2025-12-17" - aenderung: | - ROUTE-DSR wurde zu ROUTE-DPM geändert (Demand direkt an DPM). - Demand-Routing erfolgt direkt an DPM. DSR nur Portfolio-Governance. - referenz: "GOV-SOR-001" - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-021 - datum: 2025-12-09 - quelle_modul: "D2P-Integration (Phase 4)" - - frage: | - Hat SHM Einwand-Recht beim Demand-Routing? - - entscheidung: | - SHM bringt Perspektive bilateral ein. DPM nimmt Demands direkt entgegen. - Dies ergibt sich bereits aus der bestehenden DSR-Geschäftsordnung. - - begruendung: | - SHM vertritt die Stakeholder-Perspektive ("Kundenanwalt"). - Ein Demand, der gegen fundamentale Stakeholder-Interessen verstößt, - sollte nicht ohne SHM-Zustimmung freigegeben werden. - - Die DSR-GO regelt bereits: - - SHM ist stimmberechtigtes Mitglied (Abschnitt 3.1) - - Konsent-Prinzip gilt für alle Mitglieder (Abschnitt 5.1) - - Bei Einwand muss einwendende Rolle Alternative einbringen - - Ein separater Patch ist nicht erforderlich – diese Governance- - Entscheidung dokumentiert die Interpretation der bestehenden Regelung. - - auswirkung_auf: - - dokument: "shm_d2p-integration.yaml" - abschnitt: "shm_rolle_dsr.einwand_recht" - - typ: "Klarstellung" - status: final - - # --------------------------------------------------------------------------- - - - id: GOV-SHM-022 - datum: 2025-12-09 - quelle_modul: "D2P-Integration (Phase 4)" - - frage: | - Welche Rolle hat SHM bei Demand-Ablehnung durch DSR/MB? - - entscheidung: | - Differenziert nach Stakeholder-Priorität: - - Key-Stakeholder & Aktiv: Vermittlungsfunktion - - Standard & Basis: Kommunikationsfunktion - - begruendung: | - Ressourcenallokation entsprechend Betreuungsmodus. Bei Key/Aktiv - besteht höheres Risiko für Beziehungsschäden, daher intensivere - Begleitung. - - auswirkung_auf: - - dokument: "shm_d2p-integration.yaml" - abschnitt: "shm_rolle_bei_ablehnung" - - status: final - - # =========================================================================== - # PHASE 5: KOORDINATIONS- UND STEUERUNGSSTRUKTUR - # =========================================================================== - - - id: "GOV-SHM-023" - datum: "2025-12-10" - quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" - urspruengliche_id: "GOV-KSS-001" - - frage: | - Soll die SHM-Steuerung auf Prozess-Indikatoren (Aktivitäten) oder - Ergebnis-Indikatoren (Wirkung) fokussieren? - - optionen: - - option: "A" - beschreibung: "Fokus auf Prozess-Indikatoren" - beispiele: - - "Anzahl durchgeführter Turnus-Gespräche" - - "Anzahl Routing-Entscheidungen" - - "Durchlaufzeit Bedarfssteckbrief" - - option: "B" - beschreibung: "Fokus auf Ergebnis-Indikatoren" - beispiele: - - "Beziehungsqualität im Portfolio" - - "VoC-Cluster-Status" - - "Stakeholder-Wahrnehmung" - - option: "C" - beschreibung: "Beides gleichwertig" - - entscheidung: "Option B – Fokus auf Ergebnis-Indikatoren" - - begruendung: | - SHM ist eine beziehungsorientierte Funktion. Der Erfolg bemisst sich - nicht daran, wie viele Gespräche geführt wurden, sondern ob die - Stakeholder-Beziehungen gut sind und die Bedarfe erkannt werden. - - Prozess-Indikatoren können als operative Selbstvergewisserung dienen, - sind aber nicht Gegenstand des formalen Reviews. - - Diese Entscheidung ist konsistent mit PRIN-03 ("Lernen vor Messen") - und dem Verwaltungskontext, in dem qualitative Einschätzungen - anschlussfähiger sind als quantifizierte Aktivitäts-KPIs. - - konsequenzen: - - "Primäre Indikatoren: Beziehungsqualität, VoC-Cluster-Ampeln, Highlights" - - "Sekundäre Indikatoren (nicht berichtet): Gesprächsquoten, Routing-Statistik" - - "Review-Templates enthalten narrative Einschätzungen, keine Prozess-Metriken-Tabellen" - - auswirkung_auf: - - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" - abschnitt: "review_formate" - - status: "final" - - - id: "GOV-SHM-024" - datum: "2025-12-10" - quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" - urspruengliche_id: "GOV-KSS-002" - - frage: | - Wie grenzen sich SHM-Reporting und SPM-Reporting voneinander ab, - um Redundanz und Widersprüche zu vermeiden? - - kontext: | - Beide Funktionen berichten über Aspekte der Kundenbeziehung: - - SPM/SLM: Service-Qualität, SLA-Erfüllung, Kundenzufriedenheit mit Services - - SHM: Beziehungsqualität, Bedarfserfüllung, strategische Passung - - entscheidung: | - Klare Verantwortungstrennung nach Gegenstand: - - SHM verantwortet: - - Beziehungsqualität (D1) - - Bedarfserfüllung (D3) - - Strategische Passung (D4) - - Aggregierte Stakeholder-Sicht (Portfolio-Perspektive) - - SPM verantwortet: - - Service-Qualität (D2) - - SLA-Erfüllung - - Einzelne Service-Performance (Service-Perspektive) - - Gemeinsame Verantwortung: - - Kundenforum (integriertes Format) - - Eskalationen, die beide Bereiche betreffen - - begruendung: | - Die Trennung folgt der funktionalen Logik: SHM betreut Stakeholder, - SPM betreut Services. Die Stakeholder-Zufriedenheit mit Services (D2) - ist für SHM Kontext-Information, aber nicht Berichtsgegenstand. - - Diese Trennung vermeidet Doppel-Reporting, widersprüchliche Bewertungen - und unklare Verantwortlichkeiten. - - konsequenzen: - - "SHM-Review enthält keine SLA-Metriken" - - "SPM-Review enthält keine Beziehungsbewertung" - - "VoC-Dimension D2 wird als Kontext erfasst und an SPM weitergeleitet" - - "Integriertes Reporting für Mission Board nur bei Bedarf (anlassbezogen)" - - schnittstellenregelung: - - schnittstelle: "VoC-Feedback zu D2" - von: "SHM" - an: "SPM / Service Owner" - - schnittstelle: "Service-Performance-Daten" - von: "SPM" - an: "SHM (Leserecht)" - - schnittstelle: "Kundenforum" - verantwortung: "Gemeinsam SHM + SPM" - - auswirkung_auf: - - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" - abschnitt: "review_formate, voc_dimensionen" - - dokument: "spm_practice_service-level-management.yaml" - abschnitt: "slm_09" - - status: "final" - - # =========================================================================== - # PHASE 6: ROLLENBESCHREIBUNGEN - # =========================================================================== - - - id: "GOV-SHM-025" - datum: "2025-12-10" - quelle_modul: "Rollenbeschreibungen (Phase 6)" - - frage: | - Ist die Leitung SHM Mitglied im Mission Board? - - optionen: - - option: "A" - beschreibung: "Nein – SHM bringt sich nur über DSR ein" - - option: "B" - beschreibung: "Ja – Leitung SHM ist vollwertiges MB-Mitglied" - - option: "C" - beschreibung: "Teilweise – Beobachterstatus ohne Stimmrecht" - - entscheidung: "Option B – Leitung SHM ist vollwertiges MB-Mitglied" - - begruendung: | - Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene - direkt vertreten sein. Während die operative DSR-Arbeit bei den - Stakeholder-Manager:innen liegt, braucht das MB eine Person, die: - - - den Gesamt-Überblick über das Stakeholder-Portfolio hat - - strategische Stakeholder-Themen einbringen kann - - Entscheidungsauswirkungen auf Stakeholder bewerten kann - - Dies differenziert die Aussage aus GOV-SHM-022 / Phase 4: - "SHM ist kein ständiges MB-Mitglied" bezog sich auf die operative - Rolle (Stakeholder-Manager:in), nicht auf die Leitungsrolle. - - Die Entscheidung reflektiert die organisatorische Realität: - Die Leitung SHM ist Abteilungsleitung und damit auf der gleichen - Hierarchieebene wie andere MB-Mitglieder (z.B. AL Planung für DPM). - - konsequenzen: - - "Leitung SHM nimmt regelmäßig an MB-Sitzungen teil" - - "Stakeholder-Manager:in bringt sich weiterhin über DSR ein" - - "shm_d2p-integration.yaml Abschnitt MB-Rolle wird präzisiert" - - auswirkung_auf: - - dokument: "shm_rollen.yaml" - abschnitt: "leitung_shm.gremienrollen" - - dokument: "shm_d2p-integration.yaml" - abschnitt: "shm_rolle_mission_board" - aenderung: "Präzisierung: Differenzierung nach Rolle" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: "GOV-SHM-026" - datum: "2025-12-17" - quelle_modul: "SOR-Geschäftsordnung / SHM-Patch" - - frage: | - Wie erfolgt Demand-Routing? - - entscheidung: | - Demands gehen direkt an DPM. Changes werden in der SOR bestätigt. - - Der bisherige Routing-Pfad "ROUTE-SOR" wird zu "ROUTE-DSR" geändert. - - Betroffene Dokumente wurden entsprechend gepatcht (siehe PATCH-SOR-001, - PATCH-SOR-002 in spm_sor-geschaeftsordnung.yaml). - - begruendung: | - In der DSR sind alle relevanten Perspektiven vertreten (SHM, DPM, SPM). - Die Routing-Frage "Ist das ein Service-Change oder ein Demand?" ist - ihrem Wesen nach eine Demand-Einordnungsfrage und gehört daher in - die DSR. - - Die SOR konzentriert sich auf Service-Portfolio-Governance - (Go-Live, Review, Major Changes). - - auswirkung_auf: - - dokument: "shm_governance-framework.yaml" - aenderung: "ROUTE-SOR → ROUTE-DSR, sor_eskalation → dsr_routing_klaerung" - - - dokument: "shm_bedarfsbewertung.yaml" - aenderung: "ROUTE-SOR → ROUTE-DSR in routing_pfade und prozessablauf" - - - dokument: "shm_schema_bedarfssteckbrief.yaml" - aenderung: "Validierungsprofil ROUTE-SOR → ROUTE-DSR" - - - dokument: "shm_raci.yaml" - aenderung: "Aktivitäten GA-05, GA-06, BR-05, BR-06 angepasst" - - - dokument: "demand-lifecycle-blueprint_phase-1.yaml" - aenderung: "routing_optionen ROUTE-SOR → ROUTE-DSR" - - querverweise: - - "GOV-SOR-001 (SOR-Geschäftsordnung)" - - "GOV-SHM-017 (Routing-Klärungskriterium - Nachtrag)" - - "GOV-SHM-020 (Validierungsprofile - Nachtrag)" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: "GOV-SHM-027" - datum: "2026-01-23" - quelle_modul: "Stakeholder-Portfolio / Funktionszuordnung" - - frage: | - Wie wird bei Ämtern mit hybriden Funktionscharakteristika die - Funktionszuordnung vorgenommen? - - kontext: | - Manche Ämter (z.B. Stadtkämmerei) weisen Charakteristika mehrerer - Funktionskategorien auf. Die bisherige Zuordnungslogik sah nur eine - Primärfunktion vor, ohne Verfahren für Hybridfälle. - - entscheidung: | - Einführung einer Primär-/Sekundärfunktionslogik: - - 1. Primärfunktion (steuernd): - - Wird durch Entscheidungsbaum bestimmt (Dominanzprinzip) - - Bestimmt Bedarfsrouting und Governance-Zuordnung - - Pflichtfeld im Amts-Steckbrief - - 2. Sekundärfunktion (informierend): - - Optionale zweite Funktionscharakteristik - - Dokumentiert Kontext für differenzierte Betrachtung - - Begründungspflicht bei Vergabe - - Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert." - - begruendung: | - - Kundenwunsch: Transparenz über hybride Funktionscharakteristika - - Praktischer Nutzen bei Bedarfsrouting (Bedarfe können eher zur - Sekundärfunktion passen) - - Governance-Relevanz (optionale Einbindung in Gremien der - Sekundärkategorie) - - Keine Verkomplizierung der Steuerungslogik (Primärfunktion bleibt - maßgeblich) - - konsequenzen: - - "Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema" - - "Erweiterter Entscheidungsbaum mit Entscheidungshilfe bei Mehrdeutigkeit" - - "Dokumentationspflicht bei Sekundärfunktionsvergabe" - - "Neue Validierungsregeln (VAL-007, VAL-008)" - - auswirkung_auf: - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "dimension_1_funktion.zuordnungslogik" - aenderung: "Erweiterung um Primär-/Sekundärlogik" - - - dokument: "shm_schema_amtssteckbrief.yaml" - abschnitt: "segmentierung.attribute" - aenderung: "Neues Attribut sekundaerfunktion, Umbenennung funktion" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: "GOV-SHM-028" - datum: "2026-01-23" - quelle_modul: "Stakeholder-Portfolio / Betreuungsstatus" - - frage: | - Wie wird dokumentiert, ob eine Zusammenarbeit mit einem Amt - überhaupt möglich ist – unabhängig von dessen Wichtigkeit? - - kontext: | - Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) - beantworten die Frage "Wie wichtig ist das Amt?", nicht aber - "Können wir mit dem Amt zusammenarbeiten?". - - Beispiele für eingeschränkte Zusammenarbeit: - - Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung - - Amt X: Schwierige Beziehung, Zugang erschwert - - Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit), - aber die Betreuungslogik muss die Realität abbilden. - - entscheidung: | - Einführung eines neuen Attributs "Betreuungsstatus" in den Stammdaten - (nicht in der Priorisierung): - - 1. Drei Ausprägungen: - - AKTIV: Zusammenarbeit möglich, normale Priorisierung greift - - EINGESCHRÄNKT: Zusammenarbeit nur punktuell möglich - - RUHEND: Aktuell keine Zusammenarbeit möglich - - 2. Begründungspflicht bei EINGESCHRÄNKT und RUHEND (min. 30 Zeichen) - - 3. Deckelungslogik bei EINGESCHRÄNKT: - - Individueller maximaler Betreuungsmodus wird festgelegt - - Effektiver Modus = MIN(aus Prio-Stufe, max. Betreuungsmodus) - - 4. Bei RUHEND: - - Automatisch "Keine aktive Betreuung" - - Priorisierung wird trotzdem erfasst (für Reaktivierung) - - 5. Entscheidungsbefugnis: Leitung SHM - - 6. Review: Im Portfolio-Review (E2-Standard/Erweitert) wird geprüft, - ob Status noch aktuell ist - - begruendung: | - - Priorisierung bleibt sauber (nur Wichtigkeit, nicht Machbarkeit) - - Vollständigkeit des Portfolios bleibt erhalten - - Transparente Dokumentation der Zusammenarbeitssituation - - Flexibilität bei Statusänderungen (einfache Umstellung) - - Reporting kann nach Status filtern ("aktiv betreute Ämter" vs. - "Gesamtportfolio") - - Individuelle Deckelung statt mechanischer Reduktion, da - Einschränkungsgründe sehr unterschiedlich sein können - - ableitungslogik: | - Effektiver Betreuungsmodus: - - WENN status == "RUHEND": - effektiver_modus = "KEINE_AKTIVE_BETREUUNG" - - WENN status == "EINGESCHRAENKT": - abgeleiteter_modus = aus_prio_stufe(prio_stufe) - effektiver_modus = MIN(abgeleiteter_modus, max_betreuungsmodus) - - WENN status == "AKTIV": - effektiver_modus = aus_prio_stufe(prio_stufe) - - konsequenzen: - - "Neues Attribut 'betreuungsstatus' im Amts-Steckbrief-Schema (Stammdaten)" - - "Neues abgeleitetes Attribut 'effektiver_betreuungsmodus'" - - "Neue Validierungsregeln VAL-009, VAL-010, VAL-011" - - "Erweiterung des Betreuungsmodus-Enums um 'KEINE_AKTIVE_BETREUUNG'" - - auswirkung_auf: - - dokument: "shm_schema_amtssteckbrief.yaml" - abschnitt: "stammdaten.attribute" - aenderung: "Neues Attribut betreuungsstatus" - - - dokument: "shm_schema_amtssteckbrief.yaml" - abschnitt: "priorisierung.attribute" - aenderung: "Neues abgeleitetes Attribut effektiver_betreuungsmodus" - - - dokument: "shm_stakeholder-portfolio.yaml" - abschnitt: "ebene_1_amtssteckbrief" - aenderung: "Erläuterung des Betreuungsstatus-Konzepts" - - status: "final" - - # --------------------------------------------------------------------------- - - - id: "GOV-SHM-029" - datum: "2026-03-04" - quelle_modul: "SHM-Bedarfsbewertung / Bedarfsrouting" - - frage: | - Wie wird ein Bedarf geroutet, wenn SHM nach der Bedarfsbewertung unsicher - ist, ob es sich um einen bestehenden Service (RUN/Change) oder einen - neuen Demand handelt? Wer trifft die Routing-Entscheidung? - - kontext: | - Bisherige Regelung (GOV-SHM-026): Unklare Bedarfe wurden über ROUTE-DSR - an das DSR-Gremium (DPM, SHM, SPM, PPM) weitergeleitet. Dort wurde - kollektiv entschieden, ob ein Bedarf als RUN/Change oder Demand einzustufen ist. - - Workshop-Ergebnis vom 04.03.2026: Die bilaterale Klärung mit dem - Service Owner ist schneller, fachlich näher am Thema und entlastet - das DSR-Gremium von operativen Routing-Klärungen. - - Drei Varianten wurden im Vorfeld evaluiert: - - Variante A: DSR-First (bisherige Regelung) - - Variante B: SOR-First (ursprünglicher Blueprint) - - Variante C: Hybrid mit Service-Owner als Entscheidungsträger - - Die Workshop-Entscheidung entspricht Variante C mit dem Service Owner - als zentralem Entscheidungsträger. - - entscheidung: | - Ablösung von ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung): - - 1. Neuer Routing-Pfad ROUTE-SO mit zwei Pfaden: - - Pfad A — Service Owner identifizierbar: - SHM prüft Service-Portfolio → SO identifiziert → - SHM kontaktiert SO bilateral → SO gibt Routing-Empfehlung ab: - - RUN/Change → formelle Bestätigung durch SOR (Vorsitz SPM) - - Demand → formelle Bestätigung durch DSR (Vorsitz DPM) - - Pfad B — Kein Service Owner identifizierbar: - SHM kontaktiert SPM → SPM hilft bei Service-Identifikation → - SO wird einbezogen → SO gibt Routing-Empfehlung ab (wie Pfad A) - Fallback: Kein Service identifizierbar → automatisch Demand → DPM - - 2. Neuer Status "in_so_klaerung" ersetzt "bereit_fuer_dsr" - - 3. Eskalation: - - Stufe 1: Leitung SHM / SPM bei Uneinigkeit - - Stufe 2: Mission Board bei DPM-Ablehnung - - 4. DSR behält Governance-Rolle (Portfolio-Steuerung, Priorisierung), - verliert aber die operative Routing-Klärungsfunktion - - 5. GOV-SOR-001 wird angepasst: SOR bestätigt formal RUN/Change-Routing-Empfehlungen - des Service Owners (nicht mehr DSR-Routing-Klärungen) - - begruendung: | - - Schnellere Klärung durch bilateralen Prozess statt Gremium - - Service Owner hat fachliche Nähe und Entscheidungskompetenz - - DSR-Gremium wird von operativen Einzelfall-Klärungen entlastet - - SPM als Fallback gewährleistet Vollständigkeit der Portfolio-Abdeckung - - Klare Eskalationskette bis zum Mission Board - - Konsistent mit ITIL4-Prinzip der dezentralen Entscheidungsfindung - - Workshop-Konsens aller Beteiligten (SHM, SPM, DPM) - - konsequenzen: - - "ROUTE-DSR wird durch ROUTE-SO ersetzt (alle Routing-Pfade)" - - "Neuer Status 'in_so_klaerung' im Bedarfssteckbrief-Schema" - - "Service Owner gibt Routing-Empfehlung ab (keine endgültige Entscheidung)" - - "Formelle Bestätigung durch Gremien: SOR (Vorsitz SPM) für Changes, DSR (Vorsitz DPM) für Demands" - - "Weiterbearbeitung erfolgt 'als ob' bereits entschieden, während auf formelle Bestätigung im nächsten Takt gewartet wird" - - "DSR-Rolle reduziert auf Portfolio-Governance (keine Einzelfall-Klärungen)" - - "GOV-SOR-001 inhaltlich angepasst (SOR empfängt SO-Empfehlungen zur formellen Bestätigung)" - - "Anpassung in 13 YAML-Dateien über SHM, SPM, DPM" - - auswirkung_auf: - - dokument: "shm_bedarfsbewertung.yaml" - abschnitt: "routing_pfade, entscheidungsbaum, so_routing_klaerung" - aenderung: "Komplett-Überarbeitung: ROUTE-DSR → ROUTE-SO mit Pfad A/B" - - - dokument: "shm_governance-framework.yaml" - abschnitt: "routing_pfade, eskalation" - aenderung: "ROUTE-DSR → ROUTE-SO, Eskalationspfade aktualisiert" - - - dokument: "shm_raci.yaml" - abschnitt: "bedarfsrouting-aktivitaeten" - aenderung: "SO als Accountable für Routing-Entscheidung, DSR-Rolle reduziert" - - - dokument: "shm_schema_bedarfssteckbrief.yaml" - abschnitt: "status_enum, validierung" - aenderung: "bereit_fuer_dsr → in_so_klaerung" - - - dokument: "demand-lifecycle-blueprint_phase-1.yaml" - abschnitt: "phase_1_schritt_1_7" - aenderung: "ROUTE-DSR Routing-Option → ROUTE-SO" - - - dokument: "spm_sor_go.yaml" - abschnitt: "GOV-SOR-001, aufgaben" - aenderung: "SOR empfängt SO-Entscheidungen statt DSR-Routing-Klärungen" - - - dokument: "spm_governance_framework.yaml" - abschnitt: "GOV-SOR-001 Referenz" - aenderung: "Beschreibungstext aktualisiert" - - - dokument: "rolle_service-portfolio-manager.yaml" - abschnitt: "routing-klaerung, dsr-beteiligung" - aenderung: "Referenzen auf SO-basiertes Routing aktualisiert" - - - dokument: "spm_funktionsbeschreibung.yaml" - abschnitt: "dsr_gremium Governance" - aenderung: "Referenz auf GOV-SOR-001 aktualisiert" - - - dokument: "spm_practice_change-enablement.yaml" - abschnitt: "bei_dissens" - aenderung: "Referenz auf GOV-SOR-001 aktualisiert" - - - dokument: "shm_interne-bedarfe-routing.yaml" - abschnitt: "routing-optionen" - aenderung: "ROUTE-DSR → ROUTE-SO" - - - dokument: "spec_shm-dokumentation.yaml" - abschnitt: "routing-referenzen" - aenderung: "ROUTE-DSR → ROUTE-SO" - - status: "final" - -# ============================================================================= -# OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - - id: "OPEN-GOV-001" - thema: "SPM-Terminologie-Umsetzung" - beschreibung: | - Die Entscheidung GOV-SHM-005 (Modular → Erweitert) muss im SPM - umgesetzt und als Governance-Entscheidung dort dokumentiert werden. - prioritaet: "mittel" - status: "erledigt" - erledigt_am: "2025-12-03" - - - id: "OPEN-GOV-002" - thema: "Empirische Validierung" - beschreibung: | - Die Segmentierungs- und Priorisierungslogik muss gegen den - vollständigen Dezernatsverteilungsplan validiert werden. - prioritaet: "hoch" - status: "erledigt" - erledigt_am: "2025-12-03" - anmerkung: "Validierung durchgeführt (verprobt)" - - - id: "OPEN-GOV-003" - thema: "ITIL4-Referenz dokumentieren" - beschreibung: | - Abgleich des Portfolio-Konzepts mit ITIL4 Relationship Management - Practice sollte dokumentiert werden. - prioritaet: "niedrig" - status: "gestrichen" - begruendung: "Nicht erforderlich für MVP" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "0.1" - datum: "2025-12-03" - autor: "Chat-Session SHM-Konzeptentwicklung" - aenderung: "Initiale Erstellung mit 14 Governance-Entscheidungen" - - - version: "1.0" - datum: "2025-12-03" - autor: "DIGITOM-Projekt" - aenderung: "Phase 1 abgeschlossen, offene Punkte aktualisiert, Status auf Final" - - - version: "1.1" - datum: "2025-12-09" - autor: "DIGITOM-Projekt" - aenderung: "Phase 3 (Bedarfsbewertung) Governance-Entscheidungen ergänzt (GOV-SHM-016 bis GOV-SHM-019)" - - - version: "1.2" - datum: "2025-12-09" - autor: "DIGITOM-Projekt" - aenderung: "Phase 4 (D2P-Integration) Governance-Entscheidungen ergänzt (GOV-SHM-021, GOV-SHM-022)" - - - version: "1.3" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: "Phase 5 (Koordinations- und Steuerungsstruktur) Governance-Entscheidungen ergänzt (GOV-SHM-023, GOV-SHM-024)" - - - version: "1.4" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: "Phase 6 (Rollenbeschreibungen) Governance-Entscheidung ergänzt (GOV-SHM-025: MB-Mitgliedschaft Leitung SHM)" - - - version: "1.5" - datum: "2025-12-10" - autor: "DIGITOM-Projekt" - aenderung: | - Phase 7 (Governance-Framework + RACI) abgeschlossen: - - shm_governance-framework.yaml erstellt (Konsolidierung GOV-SHM-001 bis GOV-SHM-025) - - shm_raci.yaml erstellt (54 Aktivitäten in 6 Bereichen) - - Governance-Prinzipien GP-SHM-01 bis GP-SHM-05 definiert - - Entscheidungsmatrix mit 20 Entscheidungsgegenständen - - Eskalationslogik mit 5 Pfaden dokumentiert - - - version: "1.6" - datum: "2025-12-17" - autor: "DIGITOM-Projekt" - aenderung: | - Patch ROUTE-SOR → ROUTE-DSR (GOV-SHM-026): - - Routing-Klärungen werden nun in der DSR behandelt (nicht SOR) - - Betroffene Dateien: shm_governance-framework.yaml, shm_bedarfsbewertung.yaml, - shm_schema_bedarfssteckbrief.yaml, shm_raci.yaml, demand-lifecycle-blueprint_phase-1.yaml - - Nachträge zu GOV-SHM-017 und GOV-SHM-020 hinzugefügt - - Neue Governance-Entscheidung GOV-SHM-026 dokumentiert - - Referenz: GOV-SOR-001 (SOR-Geschäftsordnung) - - - version: "1.7" - datum: "2026-01-23" - autor: "DIGITOM-Projekt" - aenderung: | - Primär-/Sekundärfunktionslogik (GOV-SHM-027): - - Erweiterung der Funktionszuordnung für Ämter mit hybriden Charakteristika - - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung - - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien - - Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema - - Neue Validierungsregeln VAL-007, VAL-008 - - Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert" - - - version: "1.8" - datum: "2026-01-23" - autor: "DIGITOM-Projekt" - aenderung: | - Betreuungsstatus-Konzept (GOV-SHM-028): - - Neues Attribut 'betreuungsstatus' in Stammdaten (nicht Priorisierung) - - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND - - Begründungspflicht bei EINGESCHRÄNKT und RUHEND - - Deckelungslogik für effektiven Betreuungsmodus bei EINGESCHRÄNKT - - Neuer Betreuungsmodus 'KEINE_AKTIVE_BETREUUNG' für RUHEND - - Entscheidungsbefugnis bei Leitung SHM - - Review im Portfolio-Review (E2-Standard/Erweitert) - - - version: "1.9" - datum: "2026-03-04" - autor: "DIGITOM-Projekt" - aenderung: | - Bedarfsrouting SO-Klärung (GOV-SHM-029): - - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) abgelöst - - SO gibt Routing-Empfehlung ab (keine endgültige Entscheidung) - - Bilaterale Klärung mit Service Owner, formelle Bestätigung durch SOR (Changes) bzw. DSR (Demands) - - Pfad A (SO identifizierbar) und Pfad B (SPM hilft bei Identifikation) - - Neuer Status 'in_so_klaerung' ersetzt 'bereit_fuer_dsr' - - Weiterbearbeitung erfolgt 'als ob' bereits entschieden, Bestätigung im nächsten Takt - - GOV-SOR-001 angepasst (SOR bestätigt formal SO-Routing-Empfehlungen) - - Anpassungen in 13 YAML-Dateien über SHM, SPM, DPM - - Workshop-Entscheidung vom 04.03.2026 +# ============================================================================= +# SHM GOVERNANCE-ENTSCHEIDUNGS-LOG +# ============================================================================= +# Version: 1.8 +# Datum: 2026-01-23 +# Letzte Änderung: Bedarfsrouting SO-Klärung (GOV-SHM-029) +# Status: Final +# Quelle: Chat-Session SHM-Konzeptentwicklung +# ============================================================================= + +meta: + beschreibung: | + Dokumentation aller Governance-Entscheidungen, die während der + Entwicklung des SHM Stakeholder-Portfolio-Konzepts getroffen wurden. + + kontext: | + Diese Entscheidungen wurden in der Chat-Session zur Phase 1 + (Stakeholder-Portfolio-Modellierung) erarbeitet und bilden die + Grundlage für die MVP-Konzeption. + + referenz_arbeitsdokumente: + - "[tmp]_shm_amtssteckbrief.yaml" + - "[tmp]_shm_stakeholder-segmentierung.yaml" + - "[tmp]_shm_stakeholder-priorisierung.yaml" + +# ============================================================================= +# ENTSCHEIDUNGEN: GRUNDSTRUKTUR +# ============================================================================= + +entscheidungen: + + # --------------------------------------------------------------------------- + # PORTFOLIO-STRUKTUR + # --------------------------------------------------------------------------- + + - id: GOV-SHM-001 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio" + + frage: | + Welche Grundstruktur hat das Stakeholder-Portfolio? + + entscheidung: | + Drei-Ebenen-Modell: + 1. Amts-Steckbrief (Datengrundlage pro Amt) + 2. Segmentierung (Clustering nach zwei Dimensionen) + 3. Priorisierung (Bewertung zur Betreuungsallokation) + + begruendung: | + Das Portfolio muss drei Kernentscheidungen unterstützen: + - E1: Betreuungsallokation (Wer wird wie intensiv betreut?) + - E2: Bedarfsrouting (Wohin gehört dieser Bedarf?) + - E3: Governance-Zuordnung (Wer sitzt in welchem Gremium?) + + Die drei Ebenen adressieren diese Entscheidungen systematisch. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Gesamtstruktur" + + status: final + + # --------------------------------------------------------------------------- + # SEGMENTIERUNG + # --------------------------------------------------------------------------- + + - id: GOV-SHM-002 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Segmentierung" + + frage: | + Nach welcher Logik werden Ämter segmentiert? + + entscheidung: | + Zweidimensionale Segmentierung: + - Dimension 1: Funktion (organisatorische Rolle) + - Dimension 2: IT-Anforderungsprofil (Bedarfskomplexität) + + Beide Dimensionen sind unabhängig. Jedes Amt erhält genau eine + Ausprägung pro Dimension (keine Mehrfachzuordnung/Tags). + + begruendung: | + Die ursprüngliche Drei-Cluster-Logik (Querschnitt, Bürgerkontakt, + Technisch) vermischte verschiedene Dimensionen (Funktion, Arbeitsweise, + Anforderungsniveau). Die zweidimensionale Struktur trennt diese + sauber und ermöglicht differenziertere Zuordnung. + + verworfene_alternativen: + - option: "Eindimensionale Cluster nach Bedarfsprofil" + grund: "Nicht trennscharf, viele Überlappungen" + - option: "Tagging statt exklusiver Zuordnung" + grund: "Erhöht Komplexität ohne klaren Mehrwert" + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Segmentierung" + - dokument: "[tmp]_shm_stakeholder-segmentierung.yaml" + abschnitt: "grundkonzept" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-003 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Segmentierung" + + frage: | + Welche Ausprägungen hat Dimension 1 (Funktion)? + + entscheidung: | + Vier Ausprägungen mit Entscheidungsbaum-Logik: + + 1. Sondereinheit – Eigenbetriebe, Stabsstellen, Projektgruppen + 2. Querschnitt – Verwaltungsinterne Unterstützungsfunktion + 3. Bürgerservice – Direkter Bürgerkontakt als Kernaufgabe + 4. Fachamt – Spezialisierte Fachaufgabe (Default) + + Zuordnungslogik (erste zutreffende Kategorie gewinnt): + Sondereinheit → Querschnitt → Bürgerservice → Fachamt + + begruendung: | + - "Sondereinheit" wurde ergänzt für Eigenbetriebe etc., die + organisatorisch anders strukturiert sind + - Entscheidungsbaum-Logik vermeidet Mehrdeutigkeiten + - "Fachamt" als Default fängt alle nicht anderweitig zuordenbaren Ämter + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Segmentierung / Dimension 1" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-004 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Segmentierung" + + frage: | + Welche Ausprägungen hat Dimension 2 (IT-Anforderungsprofil)? + + entscheidung: | + Drei Ausprägungen (bedarfsorientiert, nicht nutzungsorientiert): + + 1. Basis – Standardbedarf, Grundausstattung reicht aus + 2. Erweitert – Fachspezifische Bedarfe über Standard hinaus + 3. Spezial – Individuelle Bedarfe, die nur für dieses Amt gelten + + Zuordnungslogik (Entscheidungsbaum): + 1. Individuelle IT-Bedarfe nur für dieses Amt? → Spezial + 2. Fachspezifische Bedarfe über Grundausstattung? → Erweitert + 3. Sonst → Basis + + begruendung: | + - Bedarfsorientiert (nicht nutzungsorientiert), um zukünftige + Bedarfe vorherzusagen, nicht nur Status quo abzubilden + - Terminologie harmonisiert mit SPM Service-Kategorien (siehe GOV-SHM-005) + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Segmentierung / Dimension 2" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-005 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / SPM-Harmonisierung" + + frage: | + Wie wird terminologische Konsistenz zwischen SHM und SPM hergestellt? + + entscheidung: | + Harmonisierte Terminologie für IT-Profile (SHM) und Service-Kategorien (SPM): + + | SHM IT-Profil | SPM Service-Kategorie | + |---------------|----------------------| + | Basis | A – Basis-Services | + | Erweitert | B – Erweiterte Services | + | Spezial | C – Spezial-Services | + + Erforderliche Änderung im SPM: + Kategorie B wird von "Modular-Services" zu "Erweiterte Services" umbenannt. + + begruendung: | + - "Modular" beschreibt die Architektur des Services (zubuchbar) + - "Erweitert" beschreibt die Beziehung zum Basis-Level + - "Erweitert" funktioniert für beide Perspektiven (Service und Amt) + + auswirkung_auf: + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "Service-Kategorien" + - dokument: "spm_practice_service-catalog-management.yaml" + abschnitt: "Kategorien-Logik" + - dokument: "spm_schema_service-definition.yaml" + abschnitt: "Enum-Werte" + + status: draft # Umsetzung im SPM noch ausstehend + + offene_fragen: + - "Governance-Entscheidung ins SPM-Log übertragen" + - "Templates anpassen" + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-006 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Segmentierung" + + frage: | + Haben Sondereinheiten (Eigenbetriebe etc.) auch ein IT-Anforderungsprofil? + + entscheidung: | + Ja. Sondereinheiten sind eine Funktionskategorie, keine Ausnahme + von der zweidimensionalen Logik. Sie werden wie alle anderen Ämter + in die Matrix (Funktion × IT-Profil) eingeordnet. + + Beispiele: + - Eigenbetrieb Stadtentwässerung → Sondereinheit + Spezial + - Eigenbetrieb Theater → Sondereinheit + Basis + + begruendung: | + Sondereinheiten sind organisatorisch anders, haben aber trotzdem + IT-Bedarfe, die für Betreuung und Governance relevant sind. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Matrix-Beschreibung" + + status: final + + # --------------------------------------------------------------------------- + # PRIORISIERUNG + # --------------------------------------------------------------------------- + + - id: GOV-SHM-007 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Nach welchen Dimensionen werden Stakeholder priorisiert? + + entscheidung: | + Drei Dimensionen (binär bewertet): + + 1. Einfluss – Kann das Amt DIGIT-relevante Entscheidungen beeinflussen? + Indikatoren: Entscheidungsbefugnis über IT-Budgets/Standards ODER + Multiplikator-Rolle durch Größe/Querschnittsfunktion + + 2. Abhängigkeit – Steht das Amt ohne IT still? + Indikatoren: Kernprozesse IT-abhängig ODER externe Schnittstellen + setzen funktionierende IT voraus + + 3. Relevanz – Ist das Amt gerade besonders wichtig für die Gesamtverwaltung? + Indikatoren: Hohe politische/öffentliche Sichtbarkeit ODER + Beteiligung an strategischen Projekten + + begruendung: | + - Basiert auf SALI-Modell aus Workshop, aber angepasst: + - "Macht/Einfluss" → "Einfluss" (präzisiert) + - "Legitimität" → größtenteils durch Scope-Definition abgedeckt + - "Dringlichkeit" → aufgeteilt in "Abhängigkeit" und "Relevanz" + - Binäre Bewertung (ja/nein) für Nachvollziehbarkeit + - "Bedarfsvolumen" bewusst ausgeschlossen (ist Symptom, nicht Kriterium) + + verworfene_alternativen: + - option: "SALI mit Legitimität" + grund: "Legitimität teilweise durch Scope-Definition abgedeckt" + - option: "Bedarfsvolumen als Dimension" + grund: "Ist Symptom, nicht strategisches Kriterium" + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Priorisierung / Dimensionen" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-008 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Wie werden die Priorisierungsdimensionen gewichtet? + + entscheidung: | + Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt + beeinflussen können. + + Gewichtung: Einfluss > Abhängigkeit = Relevanz + + begruendung: | + Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen + von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist + strategisch wichtiger als zu Ämtern, die "nur" abhängig sind. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Priorisierung / Kombinationslogik" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-009 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Welche Prio-Stufen gibt es und wie ergeben sie sich aus den Dimensionen? + + entscheidung: | + Vier Prio-Stufen mit folgender Kombinationslogik: + + | Prio-Stufe | Kombination | + |------------|------------------------------------------| + | Key | Alle drei ODER Einfluss + eine weitere | + | Aktiv | Zwei (ohne Einfluss) ODER nur Einfluss | + | Standard | Eine (Abhängigkeit oder Relevanz) | + | Basis | Keine Dimension erfüllt | + + Vollständige Kombinationstabelle: + | E | A | R | Prio-Stufe | + |---|---|---|------------| + | ✓ | ✓ | ✓ | Key | + | ✓ | ✓ | – | Key | + | ✓ | – | ✓ | Key | + | – | ✓ | ✓ | Aktiv | + | ✓ | – | – | Aktiv | + | – | ✓ | – | Standard | + | – | – | ✓ | Standard | + | – | – | – | Basis | + + begruendung: | + - Vier Stufen sind ausreichend differenziert für ~40-50 Ämter + - Einfluss-Gewichtung spiegelt sich in Kombinationslogik wider + - Sieben Prio-Stufen (wie im SALI-Original) wären zu granular + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Priorisierung / Kombinationslogik" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-010 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Welcher Betreuungsmodus ergibt sich aus welcher Prio-Stufe? + + entscheidung: | + | Prio-Stufe | Betreuungsmodus | Konkret | + |------------|---------------------|--------------------------------------------------| + | Key | Proaktiv/Dediziert | Turnusgespräche, dedizierter SM, aktive Bedarfserhebung | + | Aktiv | Regelmäßig | Advisory Board, anlassbezogene Gespräche | + | Standard | Eingebunden | Advisory Board, reaktiv bei Anfragen | + | Basis | Reaktiv | Nur bei eingehenden Anfragen | + + begruendung: | + Abstufung der Betreuungsintensität entsprechend der Ressourcenverfügbarkeit + und strategischen Bedeutung. Key-Stakeholder erhalten dedizierte Betreuung, + andere werden über Cluster-Formate (Advisory Boards) eingebunden. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Priorisierung / Betreuungsmodus" + - dokument: "shm_engagement-framework.yaml" + abschnitt: "Betreuungskonzepte (noch zu entwickeln)" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-011 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Gibt es eine Obergrenze für die Anzahl Key-Stakeholder? + + entscheidung: | + Nein. Im ersten Schritt wird ohne Cap modelliert. + + begruendung: | + - Die Kombinationslogik führt organisch zu einer begrenzten Anzahl + - Ein künstliches Cap könnte relevante Stakeholder ausschließen + - Nach empirischer Validierung kann ggf. nachjustiert werden + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Priorisierung" + + status: final + + offene_fragen: + - "Nach empirischer Validierung prüfen, ob Anzahl Key-Stakeholder handhabbar ist" + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-012 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Priorisierung" + + frage: | + Wie oft wird die Priorisierung überprüft? + + entscheidung: | + Die Priorisierung wird periodisch im Rahmen der Koordinations- und + Steuerungsstruktur überprüft (E2-Standard und E2-Erweitert Review-Zyklen). + + Insbesondere die Dimension "Relevanz" kann sich ändern (politische + Themen kommen und gehen) und erfordert regelmäßige Aktualisierung. + + begruendung: | + - Einfluss und Abhängigkeit sind relativ stabil + - Relevanz ist dynamisch (politische Themen, strategische Projekte) + - Integration in bestehenden Review-Prozess vermeidet Zusatzaufwand + + auswirkung_auf: + - dokument: "shm_portfolio-review.yaml" + abschnitt: "Review-Aktivitäten (noch zu entwickeln)" + + status: final + + # --------------------------------------------------------------------------- + # AMTS-STECKBRIEF + # --------------------------------------------------------------------------- + + - id: GOV-SHM-013 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" + + frage: | + Wer ist der primäre Ansprechpartner für SLA-Befugnis? + + entscheidung: | + Analog zur SPM-Logik (P-02 SLM): + - Primär: Amtsleitung + - Alternativ: Delegierte Person mit dokumentierter Entscheidungsbefugnis + + Die Delegation muss dokumentiert sein. + + begruendung: | + Konsistenz mit SPM-Governance. SLA-Partner müssen Entscheidungsbefugnis + haben, nicht nur operative Ansprechpartner sein. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Amts-Steckbrief / Stammdaten" + + referenz: + - dokument: "spm_practice_service-level-management.yaml" + entscheidung: "GOV-005" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-014 + datum: 2025-12-03 + quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" + + frage: | + Welche Organisationseinheiten sind im Scope des Stakeholder-Portfolios? + + entscheidung: | + Alle Einheiten im Dezernatsverteilungsplan: + - Ämter + - Eigenbetriebe + - Referate + - Stabsstellen + - Projektgruppen + + begruendung: | + Breiter Scope sichert vollständige Abdeckung. Die Segmentierung + (insbesondere "Sondereinheit") ermöglicht differenzierte Behandlung. + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "Scope" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-015 + datum: 2025-12-09 + quelle_modul: "SHM Engagement-Framework (Phase 2)" + + frage: | + Sollen die SHM-Advisory-Boards und die SLM-Kundenvertretungen + als separate Gremien geführt werden? + + entscheidung: | + Nein. Die Formate werden zu einem integrierten "Kundenforum"-Konzept + konsolidiert: + + 1. Kundenforum Basisservices (für Kat. A): + - Vereint SLA-Review (SLM) und Beziehungspflege/Bedarfssammlung (SHM) + - Frequenz: Jährlich (Pilotierungs-Vorbehalt) + - Gemeinsame Moderation: Service Owner + Stakeholder-Manager + - Zusammensetzung: Pflichtvertreter (Querschnittsämter) + Rotation + + 2. Kundenforum [Service] (für Kat. B): + - Primär SLA-Review, SHM-Beteiligung optional + - Frequenz: Jährlich + - Leitung: Service Owner + + 3. Bilaterale Formate (für Kat. C und Key-Stakeholder): + - Kombination aus SLA-Themen und strategischen Themen + - SO und SHM nach Bedarf gemeinsam oder getrennt + + begruendung: | + - Vermeidung von Gremien-Redundanz (gleiche Teilnehmer, ähnliche Themen) + - Ressourceneffizienz (weniger Termine für Ämter und DIGIT) + - Stärkung der "One DIGIT"-Wahrnehmung + - Natürliche Integration von Service-Qualität und Beziehungsqualität + + auswirkung_auf: + - dokument: "shm_engagement-framework.yaml" + abschnitt: "kollektive_formate" + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "kundenvertretung, slm_09" + + status: "final" + + offene_punkte: + - "Konkrete Besetzung Pflichtvertreter (Abstimmung mit Verwaltung)" + - "Frequenz-Validierung in Pilotierung" + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-016 + datum: 2025-12-09 + quelle_modul: "Bedarfsbewertung (Phase 3)" + + frage: | + Beeinflusst die Stakeholder-Priorität das Routing? + + entscheidung: | + Nein. Das Routing basiert ausschließlich auf der Sachfrage + "Was ist der Bedarf?". Die Stakeholder-Priorität beeinflusst + die Bearbeitungsgeschwindigkeit, nicht das Ziel. + + begruendung: | + Routing muss sachlogisch nachvollziehbar sein. Ein Demand bleibt + ein Demand, unabhängig davon, wer ihn einreicht. + + auswirkung_auf: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "stakeholder_kontext" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-017 + datum: 2025-12-09 + quelle_modul: "Bedarfsbewertung (Phase 3)" + + frage: | + Welche Kriterien triggern eine Routing-Klärung? + + entscheidung: | + Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. + Es gibt keine quantitativen Schwellenwerte. + + begruendung: | + Objektivierte Kriterien würden zu Schein-Objektivität führen. + Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu + erkennen und angemessen zu eskalieren. + + auswirkung_auf: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "dsr_routing_klaerung" + + status: final + + nachtrag: + datum: "2025-12-17" + aenderung: | + Demand-Routing erfolgt direkt an DPM (nicht über DSR). + Siehe GOV-SOR-001: Demand-Routing geht direkt an DPM. DSR nur für Portfolio-Governance. + referenz: "GOV-SOR-001" + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-018 + datum: 2025-12-09 + quelle_modul: "Bedarfsbewertung (Phase 3)" + + frage: | + Prüft SHM die Service-Kategorie (A/B/C) bei der Bewertung? + + entscheidung: | + Nein. Die Service-Kategorie ist informativ (aus Amts-Steckbrief), + aber nicht entscheidungsrelevant für das Routing. + + begruendung: | + Die konkrete Service-Kategorie-Zuordnung ist Aufgabe von SPM/SO. + SHM prüft nur: "Ist der Bedarf katalog-abbildbar?" + + auswirkung_auf: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "abgrenzung" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-019 + datum: 2025-12-09 + quelle_modul: "Bedarfsbewertung (Phase 3)" + + frage: | + Ist eine Aufwandsschätzung routing-relevant? + + entscheidung: | + Nein. Die Aufwandsschätzung im Bedarfssteckbrief ist informativ + für den Empfänger, aber nicht entscheidungsrelevant für das Routing. + + begruendung: | + Die Frage "Was ist es?" ist unabhängig von "Wie groß ist es?". + Ein kleiner Demand bleibt ein Demand. + + auswirkung_auf: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "funktionale_herleitung" + + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-020 + datum: 2025-12-09 + quelle_modul: "Bedarfsbewertung (Phase 3) / Bedarfssteckbrief-Schema" + + frage: | + Welche Pflichtfelder gelten für welchen Routing-Pfad? + + entscheidung: | + Die Validierungsanforderungen im Bedarfssteckbrief variieren je nach + Routing-Ziel: + + 1. ROUTE-REQ: Kein Steckbrief erforderlich + 2. ROUTE-SPM: Reduzierter Steckbrief (Basisdaten, Bedarfsbeschreibung, + Service-Katalog-Prüfung). Keine Stakeholder-Freigabe erforderlich. + 3. ROUTE-DPM: Demand geht direkt an DPM. Reduzierter Steckbrief + + SHM-Einschätzung. Keine DSR-Bestätigung für Demands nötig. + 4. ROUTE-DPM: Vollständiger Steckbrief inkl. User Stories, Abhängigkeiten, + Größeneinschätzung. Stakeholder-Freigabe erforderlich (Quality Gate 1). + + Die Validierungsregel VAL-BED-004 wird entsprechend präzisiert. + + begruendung: | + Nicht jeder Routing-Pfad erfordert den gleichen Dokumentationsaufwand. + SPM-Changes können mit reduziertem Steckbrief erfolgen. + Nur DPM-Übergaben erfordern die formale Stakeholder-Freigabe, da hier + das Quality Gate 1 des Demand-to-Product-Prozesses greift. + + auswirkung_auf: + - dokument: "shm_schema_bedarfssteckbrief.yaml" + abschnitt: "validierungsprofile, validierung.regeln.VAL-BED-004" + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "routing_pfade" + + status: final + + nachtrag: + datum: "2025-12-17" + aenderung: | + ROUTE-DSR wurde zu ROUTE-DPM geändert (Demand direkt an DPM). + Demand-Routing erfolgt direkt an DPM. DSR nur Portfolio-Governance. + referenz: "GOV-SOR-001" + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-021 + datum: 2025-12-09 + quelle_modul: "D2P-Integration (Phase 4)" + + frage: | + Hat SHM Einwand-Recht beim Demand-Routing? + + entscheidung: | + SHM bringt Perspektive bilateral ein. DPM nimmt Demands direkt entgegen. + Dies ergibt sich bereits aus der bestehenden DSR-Geschäftsordnung. + + begruendung: | + SHM vertritt die Stakeholder-Perspektive ("Kundenanwalt"). + Ein Demand, der gegen fundamentale Stakeholder-Interessen verstößt, + sollte nicht ohne SHM-Zustimmung freigegeben werden. + + Die DSR-GO regelt bereits: + - SHM ist stimmberechtigtes Mitglied (Abschnitt 3.1) + - Konsent-Prinzip gilt für alle Mitglieder (Abschnitt 5.1) + - Bei Einwand muss einwendende Rolle Alternative einbringen + + Ein separater Patch ist nicht erforderlich – diese Governance- + Entscheidung dokumentiert die Interpretation der bestehenden Regelung. + + auswirkung_auf: + - dokument: "shm_d2p-integration.yaml" + abschnitt: "shm_rolle_dsr.einwand_recht" + + typ: "Klarstellung" + status: final + + # --------------------------------------------------------------------------- + + - id: GOV-SHM-022 + datum: 2025-12-09 + quelle_modul: "D2P-Integration (Phase 4)" + + frage: | + Welche Rolle hat SHM bei Demand-Ablehnung durch DSR/MB? + + entscheidung: | + Differenziert nach Stakeholder-Priorität: + - Key-Stakeholder & Aktiv: Vermittlungsfunktion + - Standard & Basis: Kommunikationsfunktion + + begruendung: | + Ressourcenallokation entsprechend Betreuungsmodus. Bei Key/Aktiv + besteht höheres Risiko für Beziehungsschäden, daher intensivere + Begleitung. + + auswirkung_auf: + - dokument: "shm_d2p-integration.yaml" + abschnitt: "shm_rolle_bei_ablehnung" + + status: final + + # =========================================================================== + # PHASE 5: KOORDINATIONS- UND STEUERUNGSSTRUKTUR + # =========================================================================== + + - id: "GOV-SHM-023" + datum: "2025-12-10" + quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" + urspruengliche_id: "GOV-KSS-001" + + frage: | + Soll die SHM-Steuerung auf Prozess-Indikatoren (Aktivitäten) oder + Ergebnis-Indikatoren (Wirkung) fokussieren? + + optionen: + - option: "A" + beschreibung: "Fokus auf Prozess-Indikatoren" + beispiele: + - "Anzahl durchgeführter Turnus-Gespräche" + - "Anzahl Routing-Entscheidungen" + - "Durchlaufzeit Bedarfssteckbrief" + - option: "B" + beschreibung: "Fokus auf Ergebnis-Indikatoren" + beispiele: + - "Beziehungsqualität im Portfolio" + - "VoC-Cluster-Status" + - "Stakeholder-Wahrnehmung" + - option: "C" + beschreibung: "Beides gleichwertig" + + entscheidung: "Option B – Fokus auf Ergebnis-Indikatoren" + + begruendung: | + SHM ist eine beziehungsorientierte Funktion. Der Erfolg bemisst sich + nicht daran, wie viele Gespräche geführt wurden, sondern ob die + Stakeholder-Beziehungen gut sind und die Bedarfe erkannt werden. + + Prozess-Indikatoren können als operative Selbstvergewisserung dienen, + sind aber nicht Gegenstand des formalen Reviews. + + Diese Entscheidung ist konsistent mit PRIN-03 ("Lernen vor Messen") + und dem Verwaltungskontext, in dem qualitative Einschätzungen + anschlussfähiger sind als quantifizierte Aktivitäts-KPIs. + + konsequenzen: + - "Primäre Indikatoren: Beziehungsqualität, VoC-Cluster-Ampeln, Highlights" + - "Sekundäre Indikatoren (nicht berichtet): Gesprächsquoten, Routing-Statistik" + - "Review-Templates enthalten narrative Einschätzungen, keine Prozess-Metriken-Tabellen" + + auswirkung_auf: + - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" + abschnitt: "review_formate" + + status: "final" + + - id: "GOV-SHM-024" + datum: "2025-12-10" + quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" + urspruengliche_id: "GOV-KSS-002" + + frage: | + Wie grenzen sich SHM-Reporting und SPM-Reporting voneinander ab, + um Redundanz und Widersprüche zu vermeiden? + + kontext: | + Beide Funktionen berichten über Aspekte der Kundenbeziehung: + - SPM/SLM: Service-Qualität, SLA-Erfüllung, Kundenzufriedenheit mit Services + - SHM: Beziehungsqualität, Bedarfserfüllung, strategische Passung + + entscheidung: | + Klare Verantwortungstrennung nach Gegenstand: + + SHM verantwortet: + - Beziehungsqualität (D1) + - Bedarfserfüllung (D3) + - Strategische Passung (D4) + - Aggregierte Stakeholder-Sicht (Portfolio-Perspektive) + + SPM verantwortet: + - Service-Qualität (D2) + - SLA-Erfüllung + - Einzelne Service-Performance (Service-Perspektive) + + Gemeinsame Verantwortung: + - Kundenforum (integriertes Format) + - Eskalationen, die beide Bereiche betreffen + + begruendung: | + Die Trennung folgt der funktionalen Logik: SHM betreut Stakeholder, + SPM betreut Services. Die Stakeholder-Zufriedenheit mit Services (D2) + ist für SHM Kontext-Information, aber nicht Berichtsgegenstand. + + Diese Trennung vermeidet Doppel-Reporting, widersprüchliche Bewertungen + und unklare Verantwortlichkeiten. + + konsequenzen: + - "SHM-Review enthält keine SLA-Metriken" + - "SPM-Review enthält keine Beziehungsbewertung" + - "VoC-Dimension D2 wird als Kontext erfasst und an SPM weitergeleitet" + - "Integriertes Reporting für Mission Board nur bei Bedarf (anlassbezogen)" + + schnittstellenregelung: + - schnittstelle: "VoC-Feedback zu D2" + von: "SHM" + an: "SPM / Service Owner" + - schnittstelle: "Service-Performance-Daten" + von: "SPM" + an: "SHM (Leserecht)" + - schnittstelle: "Kundenforum" + verantwortung: "Gemeinsam SHM + SPM" + + auswirkung_auf: + - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" + abschnitt: "review_formate, voc_dimensionen" + - dokument: "spm_practice_service-level-management.yaml" + abschnitt: "slm_09" + + status: "final" + + # =========================================================================== + # PHASE 6: ROLLENBESCHREIBUNGEN + # =========================================================================== + + - id: "GOV-SHM-025" + datum: "2025-12-10" + quelle_modul: "Rollenbeschreibungen (Phase 6)" + + frage: | + Ist die Leitung SHM Mitglied im Mission Board? + + optionen: + - option: "A" + beschreibung: "Nein – SHM bringt sich nur über DSR ein" + - option: "B" + beschreibung: "Ja – Leitung SHM ist vollwertiges MB-Mitglied" + - option: "C" + beschreibung: "Teilweise – Beobachterstatus ohne Stimmrecht" + + entscheidung: "Option B – Leitung SHM ist vollwertiges MB-Mitglied" + + begruendung: | + Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene + direkt vertreten sein. Während die operative DSR-Arbeit bei den + Stakeholder-Manager:innen liegt, braucht das MB eine Person, die: + + - den Gesamt-Überblick über das Stakeholder-Portfolio hat + - strategische Stakeholder-Themen einbringen kann + - Entscheidungsauswirkungen auf Stakeholder bewerten kann + + Dies differenziert die Aussage aus GOV-SHM-022 / Phase 4: + "SHM ist kein ständiges MB-Mitglied" bezog sich auf die operative + Rolle (Stakeholder-Manager:in), nicht auf die Leitungsrolle. + + Die Entscheidung reflektiert die organisatorische Realität: + Die Leitung SHM ist Abteilungsleitung und damit auf der gleichen + Hierarchieebene wie andere MB-Mitglieder (z.B. AL Planung für DPM). + + konsequenzen: + - "Leitung SHM nimmt regelmäßig an MB-Sitzungen teil" + - "Stakeholder-Manager:in bringt sich weiterhin über DSR ein" + - "shm_d2p-integration.yaml Abschnitt MB-Rolle wird präzisiert" + + auswirkung_auf: + - dokument: "shm_rollen.yaml" + abschnitt: "leitung_shm.gremienrollen" + - dokument: "shm_d2p-integration.yaml" + abschnitt: "shm_rolle_mission_board" + aenderung: "Präzisierung: Differenzierung nach Rolle" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: "GOV-SHM-026" + datum: "2025-12-17" + quelle_modul: "SOR-Geschäftsordnung / SHM-Patch" + + frage: | + Wie erfolgt Demand-Routing? + + entscheidung: | + Demands gehen direkt an DPM. Changes werden in der SOR bestätigt. + + Der bisherige Routing-Pfad "ROUTE-SOR" wird zu "ROUTE-DSR" geändert. + + Betroffene Dokumente wurden entsprechend gepatcht (siehe PATCH-SOR-001, + PATCH-SOR-002 in spm_sor-geschaeftsordnung.yaml). + + begruendung: | + In der DSR sind alle relevanten Perspektiven vertreten (SHM, DPM, SPM). + Die Routing-Frage "Ist das ein Service-Change oder ein Demand?" ist + ihrem Wesen nach eine Demand-Einordnungsfrage und gehört daher in + die DSR. + + Die SOR konzentriert sich auf Service-Portfolio-Governance + (Go-Live, Review, Major Changes). + + auswirkung_auf: + - dokument: "shm_governance-framework.yaml" + aenderung: "ROUTE-SOR → ROUTE-DSR, sor_eskalation → dsr_routing_klaerung" + + - dokument: "shm_bedarfsbewertung.yaml" + aenderung: "ROUTE-SOR → ROUTE-DSR in routing_pfade und prozessablauf" + + - dokument: "shm_schema_bedarfssteckbrief.yaml" + aenderung: "Validierungsprofil ROUTE-SOR → ROUTE-DSR" + + - dokument: "shm_raci.yaml" + aenderung: "Aktivitäten GA-05, GA-06, BR-05, BR-06 angepasst" + + - dokument: "demand-lifecycle-blueprint_phase-1.yaml" + aenderung: "routing_optionen ROUTE-SOR → ROUTE-DSR" + + querverweise: + - "GOV-SOR-001 (SOR-Geschäftsordnung)" + - "GOV-SHM-017 (Routing-Klärungskriterium - Nachtrag)" + - "GOV-SHM-020 (Validierungsprofile - Nachtrag)" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: "GOV-SHM-027" + datum: "2026-01-23" + quelle_modul: "Stakeholder-Portfolio / Funktionszuordnung" + + frage: | + Wie wird bei Ämtern mit hybriden Funktionscharakteristika die + Funktionszuordnung vorgenommen? + + kontext: | + Manche Ämter (z.B. Stadtkämmerei) weisen Charakteristika mehrerer + Funktionskategorien auf. Die bisherige Zuordnungslogik sah nur eine + Primärfunktion vor, ohne Verfahren für Hybridfälle. + + entscheidung: | + Einführung einer Primär-/Sekundärfunktionslogik: + + 1. Primärfunktion (steuernd): + - Wird durch Entscheidungsbaum bestimmt (Dominanzprinzip) + - Bestimmt Bedarfsrouting und Governance-Zuordnung + - Pflichtfeld im Amts-Steckbrief + + 2. Sekundärfunktion (informierend): + - Optionale zweite Funktionscharakteristik + - Dokumentiert Kontext für differenzierte Betrachtung + - Begründungspflicht bei Vergabe + + Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert." + + begruendung: | + - Kundenwunsch: Transparenz über hybride Funktionscharakteristika + - Praktischer Nutzen bei Bedarfsrouting (Bedarfe können eher zur + Sekundärfunktion passen) + - Governance-Relevanz (optionale Einbindung in Gremien der + Sekundärkategorie) + - Keine Verkomplizierung der Steuerungslogik (Primärfunktion bleibt + maßgeblich) + + konsequenzen: + - "Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema" + - "Erweiterter Entscheidungsbaum mit Entscheidungshilfe bei Mehrdeutigkeit" + - "Dokumentationspflicht bei Sekundärfunktionsvergabe" + - "Neue Validierungsregeln (VAL-007, VAL-008)" + + auswirkung_auf: + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "dimension_1_funktion.zuordnungslogik" + aenderung: "Erweiterung um Primär-/Sekundärlogik" + + - dokument: "shm_schema_amtssteckbrief.yaml" + abschnitt: "segmentierung.attribute" + aenderung: "Neues Attribut sekundaerfunktion, Umbenennung funktion" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: "GOV-SHM-028" + datum: "2026-01-23" + quelle_modul: "Stakeholder-Portfolio / Betreuungsstatus" + + frage: | + Wie wird dokumentiert, ob eine Zusammenarbeit mit einem Amt + überhaupt möglich ist – unabhängig von dessen Wichtigkeit? + + kontext: | + Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) + beantworten die Frage "Wie wichtig ist das Amt?", nicht aber + "Können wir mit dem Amt zusammenarbeiten?". + + Beispiele für eingeschränkte Zusammenarbeit: + - Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung + - Amt X: Schwierige Beziehung, Zugang erschwert + + Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit), + aber die Betreuungslogik muss die Realität abbilden. + + entscheidung: | + Einführung eines neuen Attributs "Betreuungsstatus" in den Stammdaten + (nicht in der Priorisierung): + + 1. Drei Ausprägungen: + - AKTIV: Zusammenarbeit möglich, normale Priorisierung greift + - EINGESCHRÄNKT: Zusammenarbeit nur punktuell möglich + - RUHEND: Aktuell keine Zusammenarbeit möglich + + 2. Begründungspflicht bei EINGESCHRÄNKT und RUHEND (min. 30 Zeichen) + + 3. Deckelungslogik bei EINGESCHRÄNKT: + - Individueller maximaler Betreuungsmodus wird festgelegt + - Effektiver Modus = MIN(aus Prio-Stufe, max. Betreuungsmodus) + + 4. Bei RUHEND: + - Automatisch "Keine aktive Betreuung" + - Priorisierung wird trotzdem erfasst (für Reaktivierung) + + 5. Entscheidungsbefugnis: Leitung SHM + + 6. Review: Im Portfolio-Review (E2-Standard/Erweitert) wird geprüft, + ob Status noch aktuell ist + + begruendung: | + - Priorisierung bleibt sauber (nur Wichtigkeit, nicht Machbarkeit) + - Vollständigkeit des Portfolios bleibt erhalten + - Transparente Dokumentation der Zusammenarbeitssituation + - Flexibilität bei Statusänderungen (einfache Umstellung) + - Reporting kann nach Status filtern ("aktiv betreute Ämter" vs. + "Gesamtportfolio") + - Individuelle Deckelung statt mechanischer Reduktion, da + Einschränkungsgründe sehr unterschiedlich sein können + + ableitungslogik: | + Effektiver Betreuungsmodus: + + WENN status == "RUHEND": + effektiver_modus = "KEINE_AKTIVE_BETREUUNG" + + WENN status == "EINGESCHRAENKT": + abgeleiteter_modus = aus_prio_stufe(prio_stufe) + effektiver_modus = MIN(abgeleiteter_modus, max_betreuungsmodus) + + WENN status == "AKTIV": + effektiver_modus = aus_prio_stufe(prio_stufe) + + konsequenzen: + - "Neues Attribut 'betreuungsstatus' im Amts-Steckbrief-Schema (Stammdaten)" + - "Neues abgeleitetes Attribut 'effektiver_betreuungsmodus'" + - "Neue Validierungsregeln VAL-009, VAL-010, VAL-011" + - "Erweiterung des Betreuungsmodus-Enums um 'KEINE_AKTIVE_BETREUUNG'" + + auswirkung_auf: + - dokument: "shm_schema_amtssteckbrief.yaml" + abschnitt: "stammdaten.attribute" + aenderung: "Neues Attribut betreuungsstatus" + + - dokument: "shm_schema_amtssteckbrief.yaml" + abschnitt: "priorisierung.attribute" + aenderung: "Neues abgeleitetes Attribut effektiver_betreuungsmodus" + + - dokument: "shm_stakeholder-portfolio.yaml" + abschnitt: "ebene_1_amtssteckbrief" + aenderung: "Erläuterung des Betreuungsstatus-Konzepts" + + status: "final" + + # --------------------------------------------------------------------------- + + - id: "GOV-SHM-029" + datum: "2026-03-04" + quelle_modul: "SHM-Bedarfsbewertung / Bedarfsrouting" + + frage: | + Wie wird ein Bedarf geroutet, wenn SHM nach der Bedarfsbewertung unsicher + ist, ob es sich um einen bestehenden Service (RUN/Change) oder einen + neuen Demand handelt? Wer trifft die Routing-Entscheidung? + + kontext: | + Bisherige Regelung (GOV-SHM-026): Unklare Bedarfe wurden über ROUTE-DSR + an das DSR-Gremium (DPM, SHM, SPM, PPM) weitergeleitet. Dort wurde + kollektiv entschieden, ob ein Bedarf als RUN/Change oder Demand einzustufen ist. + + Workshop-Ergebnis vom 04.03.2026: Die bilaterale Klärung mit dem + Service Owner ist schneller, fachlich näher am Thema und entlastet + das DSR-Gremium von operativen Routing-Klärungen. + + Drei Varianten wurden im Vorfeld evaluiert: + - Variante A: DSR-First (bisherige Regelung) + - Variante B: SOR-First (ursprünglicher Blueprint) + - Variante C: Hybrid mit Service-Owner als Entscheidungsträger + + Die Workshop-Entscheidung entspricht Variante C mit dem Service Owner + als zentralem Entscheidungsträger. + + entscheidung: | + Ablösung von ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung): + + 1. Neuer Routing-Pfad ROUTE-SO mit zwei Pfaden: + + Pfad A — Service Owner identifizierbar: + SHM prüft Service-Portfolio → SO identifiziert → + SHM kontaktiert SO bilateral → SO gibt Routing-Empfehlung ab: + - RUN/Change → formelle Bestätigung durch SOR (Vorsitz SPM) + - Demand → formelle Bestätigung durch DSR (Vorsitz DPM) + + Pfad B — Kein Service Owner identifizierbar: + SHM kontaktiert SPM → SPM hilft bei Service-Identifikation → + SO wird einbezogen → SO gibt Routing-Empfehlung ab (wie Pfad A) + Fallback: Kein Service identifizierbar → automatisch Demand → DPM + + 2. Neuer Status "in_so_klaerung" ersetzt "bereit_fuer_dsr" + + 3. Eskalation: + - Stufe 1: Leitung SHM / SPM bei Uneinigkeit + - Stufe 2: Mission Board bei DPM-Ablehnung + + 4. DSR behält Governance-Rolle (Portfolio-Steuerung, Priorisierung), + verliert aber die operative Routing-Klärungsfunktion + + 5. GOV-SOR-001 wird angepasst: SOR bestätigt formal RUN/Change-Routing-Empfehlungen + des Service Owners (nicht mehr DSR-Routing-Klärungen) + + begruendung: | + - Schnellere Klärung durch bilateralen Prozess statt Gremium + - Service Owner hat fachliche Nähe und Entscheidungskompetenz + - DSR-Gremium wird von operativen Einzelfall-Klärungen entlastet + - SPM als Fallback gewährleistet Vollständigkeit der Portfolio-Abdeckung + - Klare Eskalationskette bis zum Mission Board + - Konsistent mit ITIL4-Prinzip der dezentralen Entscheidungsfindung + - Workshop-Konsens aller Beteiligten (SHM, SPM, DPM) + + konsequenzen: + - "ROUTE-DSR wird durch ROUTE-SO ersetzt (alle Routing-Pfade)" + - "Neuer Status 'in_so_klaerung' im Bedarfssteckbrief-Schema" + - "Service Owner gibt Routing-Empfehlung ab (keine endgültige Entscheidung)" + - "Formelle Bestätigung durch Gremien: SOR (Vorsitz SPM) für Changes, DSR (Vorsitz DPM) für Demands" + - "Weiterbearbeitung erfolgt 'als ob' bereits entschieden, während auf formelle Bestätigung im nächsten Takt gewartet wird" + - "DSR-Rolle reduziert auf Portfolio-Governance (keine Einzelfall-Klärungen)" + - "GOV-SOR-001 inhaltlich angepasst (SOR empfängt SO-Empfehlungen zur formellen Bestätigung)" + - "Anpassung in 13 YAML-Dateien über SHM, SPM, DPM" + + auswirkung_auf: + - dokument: "shm_bedarfsbewertung.yaml" + abschnitt: "routing_pfade, entscheidungsbaum, so_routing_klaerung" + aenderung: "Komplett-Überarbeitung: ROUTE-DSR → ROUTE-SO mit Pfad A/B" + + - dokument: "shm_governance-framework.yaml" + abschnitt: "routing_pfade, eskalation" + aenderung: "ROUTE-DSR → ROUTE-SO, Eskalationspfade aktualisiert" + + - dokument: "shm_raci.yaml" + abschnitt: "bedarfsrouting-aktivitaeten" + aenderung: "SO als Accountable für Routing-Entscheidung, DSR-Rolle reduziert" + + - dokument: "shm_schema_bedarfssteckbrief.yaml" + abschnitt: "status_enum, validierung" + aenderung: "bereit_fuer_dsr → in_so_klaerung" + + - dokument: "demand-lifecycle-blueprint_phase-1.yaml" + abschnitt: "phase_1_schritt_1_7" + aenderung: "ROUTE-DSR Routing-Option → ROUTE-SO" + + - dokument: "spm_sor_go.yaml" + abschnitt: "GOV-SOR-001, aufgaben" + aenderung: "SOR empfängt SO-Entscheidungen statt DSR-Routing-Klärungen" + + - dokument: "spm_governance_framework.yaml" + abschnitt: "GOV-SOR-001 Referenz" + aenderung: "Beschreibungstext aktualisiert" + + - dokument: "rolle_service-portfolio-manager.yaml" + abschnitt: "routing-klaerung, dsr-beteiligung" + aenderung: "Referenzen auf SO-basiertes Routing aktualisiert" + + - dokument: "spm_funktionsbeschreibung.yaml" + abschnitt: "dsr_gremium Governance" + aenderung: "Referenz auf GOV-SOR-001 aktualisiert" + + - dokument: "spm_practice_change-enablement.yaml" + abschnitt: "bei_dissens" + aenderung: "Referenz auf GOV-SOR-001 aktualisiert" + + - dokument: "shm_interne-bedarfe-routing.yaml" + abschnitt: "routing-optionen" + aenderung: "ROUTE-DSR → ROUTE-SO" + + - dokument: "spec_shm-dokumentation.yaml" + abschnitt: "routing-referenzen" + aenderung: "ROUTE-DSR → ROUTE-SO" + + status: "final" + +# ============================================================================= +# OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + - id: "OPEN-GOV-001" + thema: "SPM-Terminologie-Umsetzung" + beschreibung: | + Die Entscheidung GOV-SHM-005 (Modular → Erweitert) muss im SPM + umgesetzt und als Governance-Entscheidung dort dokumentiert werden. + prioritaet: "mittel" + status: "erledigt" + erledigt_am: "2025-12-03" + + - id: "OPEN-GOV-002" + thema: "Empirische Validierung" + beschreibung: | + Die Segmentierungs- und Priorisierungslogik muss gegen den + vollständigen Dezernatsverteilungsplan validiert werden. + prioritaet: "hoch" + status: "erledigt" + erledigt_am: "2025-12-03" + anmerkung: "Validierung durchgeführt (verprobt)" + + - id: "OPEN-GOV-003" + thema: "ITIL4-Referenz dokumentieren" + beschreibung: | + Abgleich des Portfolio-Konzepts mit ITIL4 Relationship Management + Practice sollte dokumentiert werden. + prioritaet: "niedrig" + status: "gestrichen" + begruendung: "Nicht erforderlich für MVP" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "0.1" + datum: "2025-12-03" + autor: "Chat-Session SHM-Konzeptentwicklung" + aenderung: "Initiale Erstellung mit 14 Governance-Entscheidungen" + + - version: "1.0" + datum: "2025-12-03" + autor: "DIGITOM-Projekt" + aenderung: "Phase 1 abgeschlossen, offene Punkte aktualisiert, Status auf Final" + + - version: "1.1" + datum: "2025-12-09" + autor: "DIGITOM-Projekt" + aenderung: "Phase 3 (Bedarfsbewertung) Governance-Entscheidungen ergänzt (GOV-SHM-016 bis GOV-SHM-019)" + + - version: "1.2" + datum: "2025-12-09" + autor: "DIGITOM-Projekt" + aenderung: "Phase 4 (D2P-Integration) Governance-Entscheidungen ergänzt (GOV-SHM-021, GOV-SHM-022)" + + - version: "1.3" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: "Phase 5 (Koordinations- und Steuerungsstruktur) Governance-Entscheidungen ergänzt (GOV-SHM-023, GOV-SHM-024)" + + - version: "1.4" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: "Phase 6 (Rollenbeschreibungen) Governance-Entscheidung ergänzt (GOV-SHM-025: MB-Mitgliedschaft Leitung SHM)" + + - version: "1.5" + datum: "2025-12-10" + autor: "DIGITOM-Projekt" + aenderung: | + Phase 7 (Governance-Framework + RACI) abgeschlossen: + - shm_governance-framework.yaml erstellt (Konsolidierung GOV-SHM-001 bis GOV-SHM-025) + - shm_raci.yaml erstellt (54 Aktivitäten in 6 Bereichen) + - Governance-Prinzipien GP-SHM-01 bis GP-SHM-05 definiert + - Entscheidungsmatrix mit 20 Entscheidungsgegenständen + - Eskalationslogik mit 5 Pfaden dokumentiert + + - version: "1.6" + datum: "2025-12-17" + autor: "DIGITOM-Projekt" + aenderung: | + Patch ROUTE-SOR → ROUTE-DSR (GOV-SHM-026): + - Routing-Klärungen werden nun in der DSR behandelt (nicht SOR) + - Betroffene Dateien: shm_governance-framework.yaml, shm_bedarfsbewertung.yaml, + shm_schema_bedarfssteckbrief.yaml, shm_raci.yaml, demand-lifecycle-blueprint_phase-1.yaml + - Nachträge zu GOV-SHM-017 und GOV-SHM-020 hinzugefügt + - Neue Governance-Entscheidung GOV-SHM-026 dokumentiert + - Referenz: GOV-SOR-001 (SOR-Geschäftsordnung) + + - version: "1.7" + datum: "2026-01-23" + autor: "DIGITOM-Projekt" + aenderung: | + Primär-/Sekundärfunktionslogik (GOV-SHM-027): + - Erweiterung der Funktionszuordnung für Ämter mit hybriden Charakteristika + - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung + - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien + - Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema + - Neue Validierungsregeln VAL-007, VAL-008 + - Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert" + + - version: "1.8" + datum: "2026-01-23" + autor: "DIGITOM-Projekt" + aenderung: | + Betreuungsstatus-Konzept (GOV-SHM-028): + - Neues Attribut 'betreuungsstatus' in Stammdaten (nicht Priorisierung) + - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND + - Begründungspflicht bei EINGESCHRÄNKT und RUHEND + - Deckelungslogik für effektiven Betreuungsmodus bei EINGESCHRÄNKT + - Neuer Betreuungsmodus 'KEINE_AKTIVE_BETREUUNG' für RUHEND + - Entscheidungsbefugnis bei Leitung SHM + - Review im Portfolio-Review (E2-Standard/Erweitert) + + - version: "1.9" + datum: "2026-03-04" + autor: "DIGITOM-Projekt" + aenderung: | + Bedarfsrouting SO-Klärung (GOV-SHM-029): + - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) abgelöst + - SO gibt Routing-Empfehlung ab (keine endgültige Entscheidung) + - Bilaterale Klärung mit Service Owner, formelle Bestätigung durch SOR (Changes) bzw. DSR (Demands) + - Pfad A (SO identifizierbar) und Pfad B (SPM hilft bei Identifikation) + - Neuer Status 'in_so_klaerung' ersetzt 'bereit_fuer_dsr' + - Weiterbearbeitung erfolgt 'als ob' bereits entschieden, Bestätigung im nächsten Takt + - GOV-SOR-001 angepasst (SOR bestätigt formal SO-Routing-Empfehlungen) + - Anpassungen in 13 YAML-Dateien über SHM, SPM, DPM + - Workshop-Entscheidung vom 04.03.2026 diff --git a/#04_mission-board/mb_geschaeftsordnung.yaml b/#04_mission-board/mb_geschaeftsordnung.yaml index ddbd2c1..0cb7494 100644 --- a/#04_mission-board/mb_geschaeftsordnung.yaml +++ b/#04_mission-board/mb_geschaeftsordnung.yaml @@ -1,1135 +1,1135 @@ -# ============================================================================= -# MISSION BOARD – GESCHÄFTSORDNUNG -# ============================================================================= -# -# Geschäftsordnung des Mission Boards des Amts für Digitales und IT. -# Definiert Zweck, Zusammensetzung, Verantwortungsbereiche, -# Entscheidungsprozesse und Eskalationsmechanismen. -# -# Status: Draft (zur Validierung mit DIGIT) -# ============================================================================= - -metadata: - id: "G-MB" - typ: "geschaeftsordnung" - gremium_id: "mission_board" - gremium_name: "Mission Board" - aliases: ["MB"] - version: "0.3" - status: "draft" - erstellt: "2025-03-20" - gueltig_ab: "[Datum nach Freigabe]" - geltungsbereich: "DIGITOM / Zentrale Governance" - projekt: "DIGITOM" - organisation: "DIGIT" - dokumenttyp: "geschaeftsordnung" - - abstimmung: - sparring_mit: [] - abgestimmt_mit: [] - inhaltlich_abgenommen_durch: [] - status: "in_abstimmung" - - kontext_tags: - - "governance" - - "entscheidungsgremium" - - "taktische-steuerung" - - "portfolio-management" - - "digitalisierung" - - referenzen: - taxonomie: "00_meta/digitom_taxonomie.yaml → gremium" - vision_board: "[Referenz auf Vision Board GO, falls vorhanden]" - dsr_go: "01_demand-portfolio-management/dpm_dsr-go.yaml" - sor_go: "02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml" - -# ============================================================================= -# 1. ZWECK UND GELTUNGSBEREICH -# ============================================================================= - -zweck: - - kurzform: "Zentrales taktisches Entscheidungs- und Koordinierungsgremium" - - beschreibung: | - Das Mission Board ist das zentrale Entscheidungs- und Koordinierungsgremium - für IT- und Digitalisierungsinitiativen. Es trifft alle taktischen - Entscheidungen im Rahmen der strategischen Planung. Überschreitet ein - Vorhaben diesen Rahmen (durch grundlegende Strategieänderungen oder große - Investitionen), eskaliert das Mission Board die Entscheidung an das - Vision Board oder die Amtsleitung. - - mission: | - Die strategische Planung aus dem Vision Board in greifbare, umsetzbare - Maßnahmen übersetzen. Das Board setzt klare Prioritäten, begleitet - Projekte wachsam und adressiert Engpässe durch proaktive Lösungen. - - funktion: | - Das Mission Board orchestriert sämtliche taktischen Maßnahmen und sorgt - dafür, dass Projekte und Services im Einklang mit technischen Innovationen, - hohen Sicherheitsstandards und effektiver Ressourcennutzung stehen. - - externe_anforderungen: | - Externe Anforderungen – politisch oder anderweitig – werden strukturiert - geprüft, um Ad-hoc-Entscheidungen zu vermeiden, die die langfristige - Planung gefährden könnten. - - governance_ebene: "taktisch" - - geltungsbereich: | - Das Mission Board befasst sich mit allen IT- und Digitalisierungsprojekten - sowie IT-Demands. Sein Wirkungsbereich ist taktisch: es steuert das - Projekt- und Demand-Portfolio bereichsübergreifend und stellt die - Umsetzung strategischer Ziele auf dieser Ebene sicher. - -# ============================================================================= -# 2. ZUSAMMENSETZUNG -# ============================================================================= - -zusammensetzung: - - differenzierung: | - Die Zusammensetzung des Mission Boards folgt einer klaren Differenzierung - zwischen stimmberechtigten Mitgliedern, beratenden Mitgliedern und - themenspezifischen Expert*innen. - - # --------------------------------------------------------------------------- - # 2.1 STIMMBERECHTIGTE MITGLIEDER - # --------------------------------------------------------------------------- - - stimmberechtigte_mitglieder: - - - rolle_id: "amtsleitung" - rolle_name: "Amtsleitung" - funktion: "vorsitz" - stimmberechtigt: true - verantwortlichkeiten: - - "Leitung des Mission Boards" - - "Trägt Gesamtverantwortung" - - "Letztes Entscheidungsrecht bei Stimmengleichheit" - - - rolle_id: "cdo" - rolle_name: "Chief Digital Officer (CDO)" - funktion: "mitglied" - stimmberechtigt: true - verantwortlichkeiten: - - "Verantwortet die Digitalisierungsstrategie" - - "Stimmt operative Maßnahmen mit strategischen Zielen ab" - - - rolle_id: "al_n" - rolle_name: "Alle Abteilungsleitungen des DIGIT gemäß aktueller Aufbauorganisation" - funktion: "mitglied" - stimmberechtigt: true - vertretung_moeglich: true - verantwortlichkeiten: - - "Vertreten ihre jeweiligen Abteilungen mit fachlicher, personeller und budgetbezogener Verantwortung" - - "Bringen Abteilungsperspektive und Ressourcenplanung ein" - - "Verantworten operative Umsetzung der Beschlüsse in ihrer Abteilung" - - # --------------------------------------------------------------------------- - # 2.2 BERATENDE MITGLIEDER (regelmäßig teilnehmend, ohne Stimmrecht) - # --------------------------------------------------------------------------- - - beratende_mitglieder: - - - rolle_id: "cos" - rolle_name: "Chief of Staff (CoS)" - stimmberechtigt: false - teilnahme: "regelmaessig" - verantwortlichkeiten: - - "Unterstützt Vorbereitung und Koordination des Gremiums" - - - rolle_id: "isb" - rolle_name: "Informationssicherheitsbeauftragte*r (ISB)" - stimmberechtigt: false - teilnahme: "regelmaessig" - verantwortlichkeiten: - - "Berät zu Security- und Compliance-Aspekten" - - "Identifiziert Risiken und Maßnahmen" - - - rolle_id: "dpm" - rolle_name: "Demand-Portfolio-Management" - stimmberechtigt: false - teilnahme: "agenda_abhaengig" - teilnahme_bei: - - "Neue Demands" - - "Freigaben" - verantwortlichkeiten: - - "Qualifiziert und bewertet neue Demands" - - "Liefert Priorisierungsvorschläge" - - - rolle_id: "spm" - rolle_name: "Service-Portfolio-Management" - stimmberechtigt: false - teilnahme: "agenda_abhaengig" - teilnahme_bei: - - "Service-Performance" - - "Services-Weiterentwicklung" - verantwortlichkeiten: - - "Überwacht Service-Landschaft (SLA-Reports, kritische Services)" - - "Leitet Bedarf für Serviceweiterentwicklung ab" - - - rolle_id: "ppm" - rolle_name: "Projekt-Portfolio-Management" - stimmberechtigt: false - teilnahme: "agenda_abhaengig" - teilnahme_bei: - - "Projektstatus" - - "Projekt-Freigaben" - verantwortlichkeiten: - - "Meldet Status und Risiken aus laufenden Projekten" - - "Berät zur Steuerung und Priorisierung" - - - rolle_id: "board_facilitator" - rolle_name: "Board Meeting Facilitator" - stimmberechtigt: false - teilnahme: "regelmaessig" - verantwortlichkeiten: - - "Erstellt und kommuniziert die Agenda" - - "Moderiert die Sitzung" - - "Achtet auf Zeitplan und Zielerreichung" - - "Koordiniert die Protokollierung" - - "Verfolgt To-dos und Beschlüsse" - - # --------------------------------------------------------------------------- - # 2.3 BEI BEDARF HINZUGEZOGENE EXPERT*INNEN - # --------------------------------------------------------------------------- - - experten_bei_bedarf: - - - rolle_id: "it_architektur" - rolle_name: "IT-Architektur-Board (Vertreter*in)" - stimmberechtigt: false - teilnahme: "bei_bedarf" - verantwortlichkeiten: - - "Beratung bei komplexen technischen Fragen" - - "Architekturentscheidungen" - - "Schnittstellen" - - "Systemauswahl" - - - rolle_id: "projektleitungen" - rolle_name: "Projektleitungen (einzelner Projekte)" - stimmberechtigt: false - teilnahme: "bei_bedarf" - verantwortlichkeiten: - - "Berichten projektbezogen" - - "Erläutern Sachstände und Risiken" - - "Erhalten Feedback und Beschlüsse aus dem Gremium" - - - rolle_id: "stakeholder_management" - rolle_name: "Stakeholder-Management" - stimmberechtigt: false - teilnahme: "bei_bedarf" - verantwortlichkeiten: - - "Bei spezifischen Stakeholder-/Fachbereichsanforderungen eingebunden" - - "Kann Konflikte oder eskalierte Demands erläutern" - - - rolle_id: "notfallmanagement" - rolle_name: "IT-Notfallmanagement" - stimmberechtigt: false - teilnahme: "bei_bedarf" - verantwortlichkeiten: - - "Bei sicherheitskritischen Themen oder Notfallszenarien" - - "Unterstützt taktische Entscheidungen" - -# ============================================================================= -# 3. VERANTWORTUNGSBEREICH -# ============================================================================= - -verantwortungsbereich: - - beschreibung: | - In diesem Kapitel werden die Kernthemen des Mission Board beschrieben. - Ziel ist es, IT- und Digitalisierungsmaßnahmen im Sinne der strategischen - Vorgaben zu steuern, Ressourcen gezielt einzusetzen und Risiken frühzeitig - zu erkennen. - - hinweis: | - Detailfragen einzelner Fachbereiche (z.B. Personalverantwortliche) werden - durch die Amtsleitung und Abteilungsleitungen behandelt. - - # --------------------------------------------------------------------------- - # 3.1 DEMAND- & PROJEKTPORTFOLIO-STEUERUNG - # --------------------------------------------------------------------------- - - demand_projekt_steuerung: - - was: - - "Systematische Evaluierung neuer Vorhaben anhand strategischer Relevanz und Ressourcenverfügbarkeit" - - "Entscheidung über Freigabe, zeitliche Neuplanung oder Beendigung von Projekten und Demands" - - "Integration politischer Vorgaben in die strukturierte Portfolioplanung" - - warum: - - "Fokussierung auf strategisch relevante Vorhaben zur Vermeidung unkoordinierter Ad-hoc-Initiativen" - - "Prävention von Redundanzen und Ressourcenkonflikten durch zentralisiertes Projektportfolio" - - "Gewährleistung der Integration politischer Anforderungen in den strategischen Gesamtrahmen" - - "Bewertung und Management von Schnittstellenabhängigkeiten zwischen Projekten, Services und Systemen zur Sicherstellung einer kohärenten Gesamtarchitektur und Strategie-fit" - - wie: - - "Projekt-Portfolio Reportings mit Statusindikation (bspw. Ampelsystem)" - - "Qualifizierte Voranalyse und Empfehlungserstellung durch das Demand-Portfolio-Management" - - "Architektur-Fit durch regelmäßige Berichte des IT-Architektur-Boards zur Bewertung der technologischen Kompatibilität und Zukunftsfähigkeit von Vorhaben" - - entscheidung: | - Das Mission Board entscheidet über Initiierung, Priorisierung und - Beendigung von IT-/Digitalprojekten und über Demands mit dem Ziel - einer realistischen Umsetzung strategischer Vorgaben. - - # --------------------------------------------------------------------------- - # 3.2 RESSOURCENALLOKATION & KAPAZITÄTSSTEUERUNG - # --------------------------------------------------------------------------- - - ressourcenallokation: - - was: - - "Kontinuierliches Monitoring verfügbarer und allokierter Ressourcen" - - "Fundierte Entscheidungsfindung bezüglich Personal- und Budgetzuordnungen" - - "Repriorisierung von Ressourcen, falls notwendig" - - warum: - - "Prävention von Kapazitätsengpässen in einzelnen Organisationsbereichen" - - "Gewährleistung adäquater Ressourcenausstattung für priorisierte Projektvorhaben" - - "Förderung von Transparenz und Objektivität bei der Allokation limitierter Ressourcen" - - wie: - - "Ressourcen-Informationen (Personal, Budget, Sachmittel)" - - "Engpassmeldungen aus den Abteilungen (Abteilungsleitungen identifizieren Kapazitätskonflikte)" - - "Kurzstellungnahmen von betroffenen Projekten (z.B. 'Für Projekt X fehlen uns 2 FTE')" - - "Finanzabsprache mit Governance-/Finanzstelle, falls Budgetübertragungen nötig sind" - - entscheidung: | - Das Mission Board koordiniert die taktische Allokation von Personal-, - Budget- und Sachmitteln mit dem Ziel der Engpassvermeidung und - effizienten Projekt- und Betriebsdurchführung. - - # --------------------------------------------------------------------------- - # 3.3 MONITORING & ESKALATION - # --------------------------------------------------------------------------- - - monitoring_eskalation: - - was: - - "Regelmäßige Statusbewertung für Projekte und Services mittels standardisierter Bewertungsmethodik (Ampelsystem)" - - "Frühzeitige Erkennung von Engpässen oder Risiken, deren Bewältigung die Kapazitäten einzelner Fachbereiche übersteigt" - - "Entwicklung und Implementierung taktischer Gegenmaßnahmen" - - warum: - - "Minimierung eskalierender Problementwicklungen durch proaktive Intervention" - - "Herstellung von Transparenz bezüglich Projektfortschritt und Servicequalität" - - "Zeitnahe Reaktionsfähigkeit bei signifikanten Abweichungen oder Servicebeeinträchtigungen" - - wie: - - "Projektstatus-Report (Ampelsystem) aus dem Projekt-Portfolio-Management" - - "Service-Performance-Report für kritische Services erstellt vom Service-Portfolio-Management" - - "Risikomeldungen oder Konflikt-Eskalationen durch Abteilungsleitungen" - - "Berichte und Bewertungen des IT-Architektur-Boards zu kritischen technologischen Themen (proaktiv oder auf Anforderung des Mission Boards)" - - entscheidung: | - Das Mission Board bewertet laufende Projekte und kritische Services, - identifiziert frühzeitig potenzielle Probleme und initiiert Lösungen - oder leitet geregelte Eskalationsverfahren ein. - - # --------------------------------------------------------------------------- - # 3.4 UMSETZUNG STRATEGISCHER ENTSCHEIDUNGEN - # --------------------------------------------------------------------------- - - umsetzung_strategie: - - was: - - "Harmonisierung der taktischen Planung mit aktuellen strategischen Zielvorgaben" - - "Kontinuierliche Überprüfung der Strategiekonformität laufender Vorhaben" - - "Bedarfsgerechte Modifikation von Projektzielen oder Zeitplänen bei strategischen Kurskorrekturen" - - warum: - - "Sicherstellen, dass die operative Umsetzung mit den strategischen Zielen übereinstimmt" - - "Gewährleistung zeitnaher Anpassungsfähigkeit bei politischen oder strategischen Richtungsänderungen" - - "Etablierung einer kontinuierlichen Qualitätskontrolle für sämtliche laufenden Initiativen" - - wie: - - "Strategie-Updates vom Vision Board" - - "Roadmap-Abgleich: Welche laufenden Projekte müssen angepasst werden?" - - "Architektur- und ISB-Feedback bei größeren Kursänderungen" - - "Review bzw. Re-Priorisierung im Board, wenn Projekt/Service nicht mehr zum neuen Zielbild passt" - - "Regelmäßige und anlassbezogene Rückmeldung relevanter Erkenntnisse aus der operativen Umsetzung an das Vision Board, um strategische Entscheidungen mit der Realität abzugleichen" - - entscheidung: | - Das Mission Board transformiert strategische Vorgaben des Vision Boards - und des Gemeinderats in umsetzbare Projekte und Maßnahmen und justiert - Prioritäten bei strategischen Neuausrichtungen entsprechend. - - # --------------------------------------------------------------------------- - # 3.5 QUERSCHNITT: SECURITY, COMPLIANCE & POLITIK - # --------------------------------------------------------------------------- - - security_compliance_politik: - - was: - - "Situativ angemessene Konsultation von Informationssicherheitsbeauftragten, Datenschutzstellen, IT-Notfallmanagement oder relevanten politischen Stakeholdern" - - "Systematische Integration politischer Initiativen in das strukturierte Demand-Portfolio" - - "Implementierung eines übergreifenden Risikomanagements für Sicherheits- und Compliance-relevante Aspekte" - - warum: - - "Sicherstellung der Konformität mit gesetzlichen Vorgaben und strategischen Richtlinien" - - "Prävention kostenintensiver Nachbesserungen durch frühzeitige Koordination relevanter Faktoren" - - "Integration politischer Vorgaben in die strukturierte Planung anstelle reaktiver Ad-hoc-Implementierung" - - wie: - - "Security & Compliance-Check durch ISB oder Compliance-Stelle (Risikoabschätzung, Freigabeempfehlung)" - - "Politische Anforderungen: Demand-Portfolio Management und Stakeholder Manager*in liefert Machbarkeitsabgleich" - - entscheidung: | - Das Mission Board integriert Sicherheits-, Datenschutz- und politische - Anforderungen in alle taktischen Entscheidungsprozesse unter Wahrung - der Grenzen der Detailverantwortung. - -# ============================================================================= -# 4. ENTSCHEIDUNGSPROZESSE UND ABLÄUFE -# ============================================================================= - -entscheidungsprozesse: - - beschreibung: | - Das Mission Board steuert alle taktischen Entscheidungen innerhalb des - vom Vision Board festgelegten strategischen Rahmens und des genehmigten - Budgets. - - grundsaetze: - - ziel: | - Das Gremium zielt darauf ab, frühzeitig Klarheit über Anforderungen, - Ressourcen und Risiken zu schaffen, um Ad-hoc-Entscheidungen mit - unkalkulierbaren Folgen zu vermeiden. - - prinzipien: - - - name: "Strategische Passung" - beschreibung: | - Jede Maßnahme soll zu den Zielen des Vision Boards passen und - einen erkennbaren Mehrwert liefern. - - - name: "Effektive Ressourcennutzung" - beschreibung: | - Personal, Budget und Zeit werden so verteilt, dass Engpässe - minimiert und wichtige Projekte priorisiert werden. - - - name: "Transparente Prozesse" - beschreibung: | - Fortschritte, Engpässe und Konflikte werden offen adressiert - und nach Möglichkeit zeitnah gelöst. - - # --------------------------------------------------------------------------- - # 4.1 GRUNDSÄTZE ZUR BESCHLUSSFASSUNG - # --------------------------------------------------------------------------- - - beschlussfassung: - - grundprinzip: "konsens_mehrheit" - - beschreibung: | - Das Gremium strebt einen Konsens an. Kann dieser nicht erzielt werden, - entscheidet die einfache Mehrheit der stimmberechtigten Mitglieder. - Bei Stimmengleichheit entscheidet die Stimme der Vorsitzenden (Amtsleitung). - - quorum: - regel: "nicht_formal_definiert" - beschreibung: | - Formale Quorum-Regeln sind in der aktuellen Fassung der Geschäftsordnung - nicht vorgesehen. Stattdessen sorgt der Board Facilitator in Rücksprache - mit dem Chief of Staff (CoS) dafür, dass die relevanten Personen für - Entscheidungen teilnehmen. - bei_unvollstaendigkeit: | - Sollte sich eine Entscheidung nicht mit hinreichender Verbindlichkeit - treffen lassen, wird sie auf einen Folgetermin vertagt, bis alle - benötigten Informationen und Beteiligten verfügbar sind. - - # --------------------------------------------------------------------------- - # 4.2 ENTSCHEIDUNGSKATEGORIEN - # --------------------------------------------------------------------------- - - entscheidungskategorien: - - # ------------------------------------------------------------------------- - # 4.2.1 Initiierung und Priorisierung neuer Vorhaben - # ------------------------------------------------------------------------- - - - kategorie_id: "initiierung_priorisierung" - name: "Initiierung und Priorisierung neuer Vorhaben" - - umfang: - - "Entscheidung über Start und Priorisierung neuer IT-/Digital-Projekte" - - "Bewertung von Demands nach: Strategischer Relevanz, Nutzen, Machbarkeit, Ressourcenverfügbarkeit, Zeithorizont/Dringlichkeit, Risikomaß (Optional)" - - ziel: "Vermeidung unkoordinierter Ad-hoc-Projekte durch strukturierte Prüfung" - - vorbereitung: - - "Demand-/Projektportfoliomanagement sammelt Bewertungsinformationen" - - "Empfehlung wird auf Basis der Analyse erstellt und dem Board vorgelegt" - - "Bei Bedarf: Ergänzung durch politische Vorgaben und Fachexpertise relevanter Abteilungen" - - entscheidungsprozess: - - "Vorstellung der neuen Projektidee" - - "Diskussion im Mission Board, Abwägung von Nutzen, Risiken, Ressourcenverfügbarkeit" - - "Beschluss (Mehrheitsentscheidung oder Konsens)" - - entscheidungsoptionen: - - option: "sofort_freigeben" - beschreibung: "Ressourcen stehen bereit" - naechster_schritt: "Übergabe an das Projekt-Portfolio-Management" - - - option: "freigabe_ressourcenpruefung" - beschreibung: "Freigabe, Ressourcenverfügbarkeit muss geprüft werden" - - - option: "vertagen" - beschreibung: "Vertagen/weitere Infos einholen" - - - option: "ablehnen" - beschreibung: "Ablehnen" - - eskalation: | - Eskalation erfolgt bei fehlender Entscheidungsfähigkeit des Boards - oder wenn der Vorschlag das Board-Mandat übersteigt. Weiterleitung - typischerweise an Vision Board oder Verwaltungsleitung, besonders - bei strategischen Fragen oder großem Ressourcenbedarf. Höhere - Instanz trifft dann Abschlussentscheidung oder gibt Leitlinien - für das Mission Board vor. - - # ------------------------------------------------------------------------- - # 4.2.2 Änderung laufender Projekte - # ------------------------------------------------------------------------- - - - kategorie_id: "aenderung_projekte" - name: "Änderung laufender Projekte" - - umfang: - - "Wesentliche Änderungen in laufenden Projekten" - - "Scope-, Ziel- und Budgetanpassungen" - - "Neuausrichtung oder vorzeitige Beendigung" - - ziel: | - Kontinuierliche Ausrichtung der Projekte an den übergeordneten - strategischen Zielen und Gewährleistung deren erfolgreicher Umsetzung. - - vorbereitung: - - "Change Requests werden von Projektleitung/Portfoliomanagement mit Beschlussvorlage vorbereitet" - - "Vorlage enthält Änderungsanlass, Projektstatus und Impact-Analyse (Budget/Zeit/Ziele)" - - "Bei Bedarf werden Experten-Einschätzungen (z.B. Architektur, Controlling) eingeholt" - - entscheidungsprozess: - - "Projektleitung/Portfolio-Verantwortliche stellt Änderungsantrag im Board vor" - - "Board bewertet Auswirkungen auf das betroffene Projekt und das Gesamtportfolio" - - "Entscheidung erfolgt im Konsens oder per Mehrheitsbeschluss" - - entscheidungsoptionen: - - "Genehmigung" - - "Freigabe unter Auflagen" - - "Ablehnung" - - eskalation: | - Eskalation erfolgt bei fehlender Einigung im Mission Board oder wenn - Entscheidungen außerhalb seiner Befugnisse liegen. Strategisch bedeutsame - Projektänderungen (z.B. vorzeitige Beendigung) oder große Budgetaufstockungen - werden ans Vision Board/Verwaltungsführung weitergeleitet. Dies sichert ab, - dass kritische Änderungen von der richtigen Autoritätsebene entschieden werden. - - # ------------------------------------------------------------------------- - # 4.2.3 Ressourcenallokation und -verteilung - # ------------------------------------------------------------------------- - - - kategorie_id: "ressourcenallokation" - name: "Ressourcenallokation und -verteilung" - - umfang: - - "Verteilung von Personal, Budget und Sachmitteln auf Projekte und operative Maßnahmen" - - "Bei Bedarf Umverteilung zwischen Vorhaben, um Engpässe zu vermeiden" - - ziel: | - Angemessene Ausstattung priorisierter Projekte bei gleichzeitig - effizientem Gesamteinsatz der verfügbaren Ressourcen. - - vorbereitung: - - "Erhebung der aktuellen Ressourcenauslastung und Konsolidierung von Rückmeldungen (Engpässe, fehlende Kapazitäten)" - - "Einbeziehung von Budgetübersichten" - - "Aufbereitung aller Informationen mit konkreten Vorschlägen zur Priorisierung/Umverteilung" - - entscheidungsprozess: - - "Mission Board analysiert Ressourcenberichte" - - "Identifiziert Engpässe/Überbelastungen" - - "Beschließt konkrete Anpassungsmaßnahmen" - - typische_entscheidungen: - - "Verschiebung niedrig priorisierter Projekte" - - "Freigabe zusätzlicher Mittel" - - "Umverteilung von Personal zwischen Vorhaben" - - beschluss: | - Die Beschlüsse werden idealerweise im Konsens, notfalls per - Mehrheitsvotum getroffen und verbindlich an die betroffenen - Bereiche kommuniziert. - - eskalation: | - Eskalation ans Vision Board/Verwaltungsleitung bei unlösbaren - Ressourcenengpässen. Mögliche Eskalationsanlässe: Bedarf an - zusätzlichen Budgetmitteln oder Neujustierung strategischer - Prioritäten. Weiterleitung festgefahrener Bereichskonflikte zur - verbindlichen Entscheidung (z.B. Portfolioneugewichtung, - Bereitstellung externer Ressourcen). - - # ------------------------------------------------------------------------- - # 4.2.4 Problemlösung und Eskalationsmanagement - # ------------------------------------------------------------------------- - - - kategorie_id: "problemloesung" - name: "Problemlösung und Eskalationsmanagement" - - umfang: - - "Behandlung eskalierter Probleme und Risiken aus Projekten/IT-Betrieb, die untere Ebenen nicht selbst lösen können" - - "Analyse der Problemlage" - - "Entscheidung über Gegenmaßnahmen und Verantwortlichkeiten zur Lösung auf taktischer Ebene" - - "Bei Bedarf strukturierte Weiterleitung an höhere Entscheidungsebenen" - - problembeispiele: - - "Gravierende Abweichungen" - - "Ressourcenkonflikte" - - vorbereitung: - - "Probleme werden entweder durch Monitoring-Systeme (rote Ampelwerte) oder durch direkte Meldung von Verantwortlichen identifiziert" - - "Meldender Verantwortlicher dokumentiert Problem, bisherige Maßnahmen, konkrete Auswirkungen und mögliche Lösungsoptionen in einer kompakten Entscheidungsvorlage" - - "Bei Bedarf ergänzen Fachexperten (z.B. ISB, IT-Architektur) den Sachverhalt mit zusätzlichen Analysen" - - entscheidungsprozess: - - "Board analysiert den Fall mit den Betroffenen und diskutiert Lösungswege" - - "Board beschließt konkrete Maßnahmen wie Ressourcenzuweisung, Anpassung von Zielen oder externe Unterstützung" - - "Bei unlösbaren Problemen wird der Fall gemäß Eskalationsplan an die nächsthöhere Stelle weitergeleitet" - - eskalation: - trigger: - - "Board kann ein Problem nicht selbst lösen oder seine Befugnisse werden überschritten" - - "Fälle, die strategische Entscheidungen oder erhebliche zusätzliche Ressourcen erfordern" - - "Kritische Situationen mit möglichen rechtlichen oder politischen Auswirkungen" - - # ------------------------------------------------------------------------- - # 4.2.5 Festlegung von Zielen und taktischen Leitplanken - # ------------------------------------------------------------------------- - - - kategorie_id: "ziele_leitplanken" - name: "Festlegung von Zielen und taktischen Leitplanken" - - umfang: - - "Übersetzung strategischer Vorgaben in messbare operative Ziele und Erfolgskennzahlen" - - "Definition verbindlicher Leitplanken wie Bewertungskriterien, Priorisierungsprinzipien und methodische Vorgaben" - - ziel: | - Sicherstellung eines einheitlichen Vorgehens und Ausrichtung aller - Maßnahmen auf die strategischen Ziele. - - vorbereitung: - - "Grundsatzthemen werden meist in der strategischen Planung vom Board-Leiter (Amtsleitung/Chief of Staff) vorbereitet" - - "Entwürfe basieren auf strategischen Vorgaben, Betriebserfahrungen und Experteninput (IT-Architektur, ISB)" - - "Ergebnis ist ein kompaktes Vorschlagspapier mit konkreten Zielen und Leitplanken" - - entscheidungsprozess: - - "Gemeinsam auf Realisierbarkeit geprüft und bis zur Einigung diskutiert" - - "Formal durch Konsens oder Mehrheitsbeschluss verabschiedet" - - "Als verbindlicher Rahmen dokumentiert und an alle betroffenen Bereiche kommuniziert" - - eskalation: | - Bei Unstimmigkeit oder hat eine Vorgabe strategische/politische - Auswirkungen, eskaliert das Board an das Vision Board oder die - Verwaltungsspitze. Eskalation ist besonders bei Berührung strategischer - Ausrichtungen oder externer Anforderungen (Gesetz, Politik) notwendig. - Nach Klärung durch die höhere Instanz legt das Mission Board die - finalen Ziele und Leitplanken fest. - - # ------------------------------------------------------------------------- - # 4.2.6 Governance- und Compliance-Entscheidungen (Querschnittsthemen) - # ------------------------------------------------------------------------- - - - kategorie_id: "governance_compliance" - name: "Governance- und Compliance-Entscheidungen (Querschnittsthemen)" - - umfang: - - "Sicherstellung, dass Governance-, Sicherheits-, Compliance- und politische Vorgaben beachtet werden" - - "Verabschiedung von Richtlinien für Projekt-Management, Sicherheit, Datenschutz und Prozessstandards" - - "Berücksichtigung politischer Anforderungen vom Oberbürgermeister, Gemeinderat oder Dezernentenrunde" - - "Prozess Management-Richtlinien, die die Standardisierung, Optimierung und Steuerung von Organisationsprozessen betreffen" - - "Freigaben für neue oder überarbeitete Prozessstandards" - - vorbereitung: - - "Fachexperten (ISB, Datenschutz) erstellen Risikoanalysen und Handlungsempfehlungen für sicherheitskritische Themen" - - "Governance/Verwaltung bewertet politische Anforderungen auf Machbarkeit und Auswirkungen" - - "Prozess-Management analysiert Optimierungspotenziale in operativen Abläufen und erarbeitet Verbesserungsvorschläge" - - "Alle relevanten Vorgaben und Risiken werden für informierte Entscheidungen des Boards konsolidiert" - - "Fachvertreter werden zu Sitzungen hinzugezogen, um ihre Empfehlungen direkt einzubringen" - - entscheidungsprozess: - - "Fachverantwortliche präsentieren neue Governance-/Compliance-Anforderungen im Board-Meeting" - - "Mission Board diskutiert operative Auswirkungen sowie Risiken und Vorteile der vorgeschlagenen Änderungen" - - "Bei Bedarf werden betroffene Abteilungen oder das IT-Architektur-Board in die Diskussion einbezogen" - - "Entscheidung erfolgt gemeinschaftlich mit besonderer Berücksichtigung der Fachexpertise" - - entscheidungsoptionen: - - "Freigabe" - - "Anpassungen anfordern" - - "Eskalation an höhere Instanzen" - - eskalation: - - ziel: "Vision Board" - bei: "Grundsatzentscheidungen zu IT-Governance oder Digitalstrategie" - - - ziel: "Verwaltungsleitung oder Gemeinderat" - bei: "Politische Entscheidungen (Budget, Beschlüsse)" - - - ziel: "Fachabteilungen oder externe Prüfstellen" - bei: "Signifikante Compliance- und Sicherheitsfragen" - - - ziel: "Vision Board oder verwaltungsweite Prozessgremien" - bei: "Organisationsweite Prozessänderungen" - - begruendung_eskalation: | - Dies stellt sicher, dass das Mission Board innerhalb seines Mandats - bleibt und übergreifende Risiken an die zuständige Stelle eskaliert werden. - -# ============================================================================= -# 5. SCHNITTSTELLEN UND ABSTIMMUNGSWEGE -# ============================================================================= - -schnittstellen: - - beschreibung: | - Das Mission Board steht im engen Austausch mit anderen Gremien und Ebenen. - - hinweis: | - Neben diesen Hauptschnittstellen interagiert das Mission Board natürlich - auch mit der operativen Ebene: Projektleitungen und Fachabteilungen setzen - die Beschlüsse des Boards um und melden Status oder Eskalationen zurück. - Diese Interaktion läuft im täglichen Betrieb über die Abteilungsleiter*innen - und Portfolio-Manager*innen, die im Mission Board vertreten sind. - - # --------------------------------------------------------------------------- - # 5.1 HAUPTSCHNITTSTELLEN - # --------------------------------------------------------------------------- - - hauptschnittstellen: - - - partner: "Vision Board" - beschreibung: | - Das Mission Board setzt die Strategie des Vision Boards operativ um - und berichtet regelmäßig über Fortschritte und Hindernisse. - interaktion: - - "Strategisch relevante Entscheidungen oder unlösbare Konflikte werden vom Mission Board an das Vision Board eskaliert" - - "Rückkopplungsschleife gewährleistet, dass strategische Entscheidungen auf realistischen operativen Daten basieren" - - "Operatives Geschäft bleibt stets im Einklang mit der Gesamtstrategie" - - - partner: "Demand- & Stakeholder-Runde (DSR)" - beschreibung: | - Neue Anforderungen werden zuerst in der Demand- und Stakeholder-Runde - bewertet, priorisiert und aufbereitet, bevor sie ans Mission Board - weitergeleitet werden. - interaktion: - - "Mission Board entscheidet final über größere Demands" - - "Gibt der Demand-Runde strategische Leitplanken vor" - - "Bei komplexen oder besonders wichtigen Anforderungen kann die Demand-Runde direkt ans Mission Board eskalieren" - - - partner: "IT-Architektur-Board" - beschreibung: | - Das Mission Board berücksichtigt die Vorgaben des IT-Architektur-Boards - für technische Standards und Sicherheitsrichtlinien bei allen - Portfolio-Entscheidungen. - interaktion: - - "Bei technologisch komplexen Projekten werden Vertreter des Architektur-Boards direkt in die Beratung einbezogen" - - "Gewährleistung technischer Machbarkeit und Architekturkonformität" - - "Gegenseitige Information über relevante Entwicklungen" - - "Architekturaspekte fließen frühzeitig in Projektentscheidungen ein" - - "Mission Board trifft keine technischen Detailentscheidungen ohne Fachexpertise" - -# ============================================================================= -# 6. ESKALATIONSMECHANISMEN -# ============================================================================= - -eskalationsmechanismen: - - grundsatz: | - Das Mission Board geht mit Problemen und Konflikten proaktiv und - lösungsorientiert um. Es folgt dem Grundsatz: "Probleme dort lösen, - wo sie entstehen" – also auf der niedrigstmöglichen Ebene. Erst wenn - dies nicht möglich ist, werden strukturierte Eskalationswege beschritten. - - # --------------------------------------------------------------------------- - # 6.1 PROBLEMLÖSUNG AUF BOARD-EBENE - # --------------------------------------------------------------------------- - - problemloesung_board_ebene: - - ablauf: - - "Projektprobleme (z.B. Terminverzug, Ressourcenmangel) werden durch Abteilungs- oder Projektleiter eingebracht" - - "Board analysiert und beschließt direkte Gegenmaßnahmen (Umpriorisierung, Ressourcenumverteilung)" - - "Frühzeitiges Gegensteuern soll weitreichendere Eskalationen vermeiden" - - # --------------------------------------------------------------------------- - # 6.2 ESKALATION ANS VISION BOARD - # --------------------------------------------------------------------------- - - eskalation_vision_board: - - beschreibung: | - Wird erforderlich, wenn Probleme die Befugnisse oder Möglichkeiten - des Mission Boards überschreiten. - - typische_gruende: - - - grund: "Strategische Konflikte" - beschreibung: | - Strategische Konflikte oder Zielkonflikte, die im Mission Board - nicht gelöst werden können (etwa wenn ein Projekt die Gesamtstrategie - infrage stellt). - - - grund: "Ressourcenbedarf oder Budgetüberschreitungen" - beschreibung: | - Ressourcenbedarf oder Budgetüberschreitungen, die außerhalb des - vom Mission Board kontrollierbaren Rahmens liegen (z.B. es werden - Mittel benötigt, die nur durch den Gemeinderat/Vision Board - freigegeben werden können). - - - grund: "Politisch sensible Entscheidungen" - beschreibung: | - Politisch sensible Entscheidungen, bei denen eine Abstimmung mit - dem Oberbürgermeister, Gemeinderat oder Dezernentenrunde, - Top-Management oder der Politik erforderlich ist. - - - grund: "Unauflösbare Konflikte" - beschreibung: | - Unauflösbare Konflikte zwischen Bereichen, wenn trotz Vermittlung - im Mission Board keine Einigung erzielt wird und ein höheres - Organ entscheiden muss. - - - grund: "Risiken zur Erreichung strategischer Zielvorgaben" - beschreibung: | - Risiken zur Erreichung von strategischen Zielvorgaben, wenn - erkennbar wird, dass wichtige strategische Meilensteine oder - Kennzahlen trotz taktischer Gegenmaßnahmen verfehlt werden könnten. - - verfahren: - - beschreibung: | - Bei Eskalationsfällen agiert das Mission Board strukturiert und - zielorientiert. Es erstellt eine präzise Eskalationsvorlage für - das Vision Board. - - vorlage_inhalte: - - "Das Problem klar definiert" - - "Bereits geprüfte Lösungsoptionen darstellt" - - "Einen konkreten Vorschlag oder Klärungsbedarf formuliert" - - entscheidung: | - Auf Basis dieser Vorlage entscheidet das Vision Board über das - weitere Vorgehen oder gibt Leitplanken vor. - - subsidiaritaetsprinzip: - - beschreibung: | - Zentral dabei ist das Subsidiaritätsprinzip: Probleme werden stets - auf der niedrigstmöglichen Ebene gelöst, um Effizienz zu wahren. - - ebenen: - - problem_typ: "Routineprobleme" - zustaendig: "Fachabteilung" - - - problem_typ: "Bereichsübergreifende taktische Probleme" - zustaendig: "Mission Board" - - - problem_typ: "Strategische oder außerordentliche Probleme" - zustaendig: "Vision Board" - - # --------------------------------------------------------------------------- - # 6.3 ESKALATIONSTRIGGER - # --------------------------------------------------------------------------- - - eskalationstrigger: - - beschreibung: | - Um Transparenz und Konsistenz zu gewährleisten, dokumentiert das - Mission Board alle Eskalationstrigger und -stufen schriftlich und - verfolgt Eskalationsfälle konsequent nach. Diese Dokumentation hilft - dabei, ähnliche Probleme in Zukunft zu vermeiden. - - trigger: - - - name: "Strategische Konflikte" - beschreibung: | - Sobald ein Projekt oder eine Entscheidung zentrale Zielsetzungen - des Vision Boards infrage stellt oder grundlegende - Strategieänderungen erfordert. - - - name: "Budgetüberschreitungen" - beschreibung: | - Wenn der Finanzrahmen des Mission Boards nicht mehr ausreicht - und übergeordnete Freigaben (z.B. durch Gemeinderat, - Verwaltungsleitung) notwendig werden. - - - name: "Politische Sensitivität" - beschreibung: | - Bei Vorgaben oder Beschlüssen, die möglicherweise politischen - Rückhalt erfordern bzw. erhebliche Außenwirkung haben und nicht - allein vom Mission Board verantwortet werden können. - - - name: "Bereichsübergreifende Konflikte" - beschreibung: | - Wenn trotz Vermittlungsversuchen im Mission Board kein Konsens - zwischen betroffenen Abteilungen oder Projekten erzielt wird und - eine höhere Autorität entscheiden muss. - - - name: "Rechtliche oder Compliance-relevante Aspekte" - beschreibung: | - Insbesondere bei Verstößen gegen Sicherheitsauflagen, - Datenschutzgesetze oder andere zwingende Vorgaben, die außerhalb - des Mandats des Mission Boards geregelt werden müssen. - - - name: "Gravierende Termin- und Qualitätsrisiken" - beschreibung: | - Sobald Verzögerungen oder Qualitätsprobleme den Erfolg zentraler - Vorhaben gefährden und das Mission Board keine hinreichenden - Gegenmaßnahmen mehr treffen kann. - - anmerkung: | - Welche Eskalationsstufe jeweils gewählt wird, richtet sich nach - Ausmaß und Art des Problems. Üblicherweise erfolgt eine Eskalation - an das Vision Board, sobald das Mission Board selbst den - Handlungsspielraum überschreitet (z.B. wegen fehlender Ressourcen, - nötiger Strategieänderungen oder politischer Tragweite). - - zweck: | - Die hier aufgeführten Punkte sollen es allen Beteiligten erleichtern, - kritische Situationen frühzeitig zu erkennen und an die richtige - Stelle zu adressieren. Auf diese Weise lassen sich größere Schäden - abwenden, und das Mission Board kann sich auf sein Kerngeschäft – - die taktische Steuerung von IT- und Digitalisierungsinitiativen – - konzentrieren. - -# ============================================================================= -# 7. DOKUMENTATION UND REPORTING -# ============================================================================= - -dokumentation_reporting: - - beschreibung: | - Eine saubere Dokumentation und regelmäßiges Reporting stellen die - Nachvollziehbarkeit der Entscheidungen und die Informationsversorgung - aller Stakeholder*innen sicher. - - # --------------------------------------------------------------------------- - # 7.1 PROTOKOLLIERUNG - # --------------------------------------------------------------------------- - - protokollierung: - - methode: "live_protokoll" - - beschreibung: | - Jede Sitzung des Mission Boards wird live protokolliert. - - inhalte: - - "Wichtige Aspekte und getroffene Entscheidungen (mit Begründung, falls notwendig)" - - "Die Verantwortlichen für Folgeaktionen" - - "Etwaige abweichende Meinungen oder offene Punkte" - - beschluesse: - erfassung: "Mit einer eindeutigen Kennziffer erfasst" - zweck: "Umsetzung kann nachverfolgt werden" - - # --------------------------------------------------------------------------- - # 7.2 ENTSCHEIDUNGS-TRACKING - # --------------------------------------------------------------------------- - - entscheidungs_tracking: - - beschreibung: | - Beschlossene Maßnahmen und Aufträge werden in einem Entscheidungs- - und Maßnahmentracker festgehalten. - - tool_beispiele: - - "Confluence-Liste" - - "Excel-Übersicht" - - verantwortlich: "Board Facilitator" - - ueberpruefung: | - Zu Beginn jeder Sitzung wird der Status früherer Beschlüsse kurz - überprüft, um sicherzustellen, dass Entscheidungen umgesetzt wurden - bzw. um Hindernisse dabei frühzeitig zu erkennen. - - zweck: | - Dieses regelmäßige Tracking schafft Verbindlichkeit und Transparenz - über den Outcome der Board-Entscheidungen. - - # --------------------------------------------------------------------------- - # 7.3 REGELMÄSSIGE REPORTS - # --------------------------------------------------------------------------- - - regelmaessige_reports: - - beschreibung: | - Zur fundierten Entscheidungsfindung erhält das Mission Board vor - jeder Sitzung standardisierte Berichte. Diese werden von den - zuständigen Portfolio-Verantwortlichen bzw. Abteilungen erstellt - und an alle Mitglieder verteilt. - - verteilung: | - Die genannten Berichte gehen standardmäßig an alle Mission-Board-Mitglieder - (stimmberechtigte und beratende) vorab über den Board Facilitator zur - Vorbereitung. Wichtige Kennzahlen oder Zusammenfassungen daraus werden - bei Bedarf auch dem Vision Board zur Verfügung gestellt, insbesondere - wenn sie für strategische Entscheidungen relevant sind. - - zweck: | - Durch das feste Reporting-Set ist sichergestellt, dass das Mission Board - stets aktuelle, vollständige Informationen hat und Entscheidungen - datenbasiert treffen kann. - - reports: - - - name: "Demand-Portfolio-Bericht" - erstellt_von: "Demand-Portfolio-Management" - inhalt: | - Übersicht aller neuen und offenen Anforderungen (Demands) inkl. - Bewertung ihres strategischen Nutzens, Aufwands und Priorisierungsstatus. - - - name: "Projekt-Portfolio-Bericht" - erstellt_von: "Projekt-Portfolio-Management" - inhalt: | - Statusbericht zu allen laufenden Projekten mit Ampelstatus, - wichtigen Meilensteinen, Risiken, Problemen und Abhängigkeiten. - Dieser Report gibt dem Board einen Gesamtüberblick und identifiziert - Projekte, die besonderer Aufmerksamkeit bedürfen. - - - name: "Service-Bericht" - erstellt_von: "Service-Portfolio-Management" - inhalt: | - Bericht über die Betriebs- und Servicekennzahlen kritischer - IT-Services (z.B. Verfügbarkeit, Störungen, SLA-Einhaltung, - Sicherheitsvorfälle). So behält das Board neben Projekten auch - den laufenden IT-Betrieb im Blick und kann bei Qualitätsproblemen - reagieren. - - - name: "Ressourcen-Report" - erstellt_von: "Governance/Verwaltung und Abteilungsleitungen" - inhalt: | - Zusammenstellung der aktuellen Personalkapazitäten und Budgetmittel - vs. der geplanten/benötigten Ressourcen in Projekten. Enthält auch - Hinweise auf Engpässe oder Überlast in bestimmten Bereichen. Dieser - Bericht ermöglicht dem Mission Board, Engpasssituationen zu erkennen - und früh gegenzusteuern. - - - name: "Statusberichte für kritische Vorhaben" - erstellt_von: "Projektleitung über das Projekt-Portfolio-Management" - inhalt: | - Für Projekte oder Initiativen, die als kritisch eingestuft sind - (z.B. wegen hoher strategischer Bedeutung oder erheblicher Probleme), - werden detaillierte Sonderberichte vorgelegt. Diese enthalten - tiefergehende Analysen und ggf. Eskalationsempfehlungen, damit das - Board gezielt über solche Sonderfälle beraten kann. - - # --------------------------------------------------------------------------- - # 7.4 KOMMUNIKATION DER BESCHLÜSSE - # --------------------------------------------------------------------------- - - kommunikation_beschluesse: - - beschreibung: | - Relevante Board-Entscheidungen werden an die jeweiligen Umsetzungsteams - kommuniziert, zum Beispiel durch den Versand des Protokolls an beteiligte - Projektleitungen. - - eskalation_information: | - Müssen darüber hinaus das Vision Board oder andere Gremien informiert - werden (z.B. bei Eskalationen oder strategischen Themen), so erhalten - sie eine kurze Management Summary. - - zweck: | - Das schafft stadtweit Transparenz, ohne die Vertraulichkeit interner - Diskussionen zu verletzen. - - zusammenfassung: | - Zusammenfassend stellt die Kombination aus Protokollierung, regelmäßigen - Reports und aktivem Tracking sicher, dass Entscheidungen nachvollziehbar - dokumentiert sind und deren Umsetzung konsequent verfolgt wird. - Informationsflüsse nach oben (Vision Board) und unten (Fachbereiche/Projekte) - sind etabliert, sodass alle Beteiligten stets auf dem aktuellen Stand sind. - -# ============================================================================= -# 8. MEETING-RHYTHMUS UND ABLAUF -# ============================================================================= - -meeting_rhythmus: - - # --------------------------------------------------------------------------- - # 8.1 REGULÄRE SITZUNGEN - # --------------------------------------------------------------------------- - - regulaere_sitzungen: - frequenz: "zweiwochenrhythmus" - tag: "mittwoch" - dauer_minuten: 120 - - vorbereitung: | - Alle Mitglieder sind verpflichtet, sich im Vorfeld auf die Sitzungen - angemessen vorzubereiten. - - # --------------------------------------------------------------------------- - # 8.2 AD-HOC SITZUNGEN - # --------------------------------------------------------------------------- - - ad_hoc_sitzungen: - einberufung: "bei_bedarf" - voraussetzung: "Vorherige Abstimmung mit den relevanten Mitgliedern" - - # --------------------------------------------------------------------------- - # 8.3 AGENDA-ERSTELLUNG - # --------------------------------------------------------------------------- - - agenda_erstellung: - verantwortlich: "Board Facilitator" - abstimmung_mit: "Chief of Staff (CoS)" - - inhalte: - - "Alle vorgesehenen Tagesordnungspunkte" - - "Vorbereitete Unterlagen zu den wichtigsten zu besprechenden Themen" - - # --------------------------------------------------------------------------- - # 8.4 DOKUMENTATION - # --------------------------------------------------------------------------- - - dokumentation: - methode: "Live-Protokoll während jeder Sitzung" - - pflichtinhalte: - - "Alle relevanten Beschlüsse und Entwicklungen" - - "Welche Folgemaßnahmen vereinbart wurden" - - "Welche Mitglieder für Folgemaßnahmen verantwortlich sind" - - # --------------------------------------------------------------------------- - # 8.5 EINREICHUNGSFRIST FÜR UNTERLAGEN - # --------------------------------------------------------------------------- - - einreichungsfrist: - frist: "Montag der jeweiligen Sitzungswoche, 12:00 Uhr" - anforderung: "Verwendung der vorgegebenen einheitlichen Vorlage" - - # --------------------------------------------------------------------------- - # 8.6 BESCHLUSSVORLAGEN - # --------------------------------------------------------------------------- - - beschlussvorlagen: - qualitaetssicherung: "Vor Behandlung im Gremium" - finale_entscheidung: "Obliegt dem Vision Board" - -# ============================================================================= -# 9. ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "0.3" - datum: "2025-03-20" - aenderung: "Initiale YAML-Fassung basierend auf Word-Dokument" - autor: "DIGITOM-Projekt" - quelle: "250320_Mission_Board-Geschäftsordnung_v0_3.docx" +# ============================================================================= +# MISSION BOARD – GESCHÄFTSORDNUNG +# ============================================================================= +# +# Geschäftsordnung des Mission Boards des Amts für Digitales und IT. +# Definiert Zweck, Zusammensetzung, Verantwortungsbereiche, +# Entscheidungsprozesse und Eskalationsmechanismen. +# +# Status: Draft (zur Validierung mit DIGIT) +# ============================================================================= + +metadata: + id: "G-MB" + typ: "geschaeftsordnung" + gremium_id: "mission_board" + gremium_name: "Mission Board" + aliases: ["MB"] + version: "0.3" + status: "draft" + erstellt: "2025-03-20" + gueltig_ab: "[Datum nach Freigabe]" + geltungsbereich: "DIGITOM / Zentrale Governance" + projekt: "DIGITOM" + organisation: "DIGIT" + dokumenttyp: "geschaeftsordnung" + + abstimmung: + sparring_mit: [] + abgestimmt_mit: [] + inhaltlich_abgenommen_durch: [] + status: "in_abstimmung" + + kontext_tags: + - "governance" + - "entscheidungsgremium" + - "taktische-steuerung" + - "portfolio-management" + - "digitalisierung" + + referenzen: + taxonomie: "00_meta/digitom_taxonomie.yaml → gremium" + vision_board: "[Referenz auf Vision Board GO, falls vorhanden]" + dsr_go: "01_demand-portfolio-management/dpm_dsr-go.yaml" + sor_go: "02_service-portfolio-management/02.1_spm_konzepte/01_spm_governance/spm_sor_go.yaml" + +# ============================================================================= +# 1. ZWECK UND GELTUNGSBEREICH +# ============================================================================= + +zweck: + + kurzform: "Zentrales taktisches Entscheidungs- und Koordinierungsgremium" + + beschreibung: | + Das Mission Board ist das zentrale Entscheidungs- und Koordinierungsgremium + für IT- und Digitalisierungsinitiativen. Es trifft alle taktischen + Entscheidungen im Rahmen der strategischen Planung. Überschreitet ein + Vorhaben diesen Rahmen (durch grundlegende Strategieänderungen oder große + Investitionen), eskaliert das Mission Board die Entscheidung an das + Vision Board oder die Amtsleitung. + + mission: | + Die strategische Planung aus dem Vision Board in greifbare, umsetzbare + Maßnahmen übersetzen. Das Board setzt klare Prioritäten, begleitet + Projekte wachsam und adressiert Engpässe durch proaktive Lösungen. + + funktion: | + Das Mission Board orchestriert sämtliche taktischen Maßnahmen und sorgt + dafür, dass Projekte und Services im Einklang mit technischen Innovationen, + hohen Sicherheitsstandards und effektiver Ressourcennutzung stehen. + + externe_anforderungen: | + Externe Anforderungen – politisch oder anderweitig – werden strukturiert + geprüft, um Ad-hoc-Entscheidungen zu vermeiden, die die langfristige + Planung gefährden könnten. + + governance_ebene: "taktisch" + + geltungsbereich: | + Das Mission Board befasst sich mit allen IT- und Digitalisierungsprojekten + sowie IT-Demands. Sein Wirkungsbereich ist taktisch: es steuert das + Projekt- und Demand-Portfolio bereichsübergreifend und stellt die + Umsetzung strategischer Ziele auf dieser Ebene sicher. + +# ============================================================================= +# 2. ZUSAMMENSETZUNG +# ============================================================================= + +zusammensetzung: + + differenzierung: | + Die Zusammensetzung des Mission Boards folgt einer klaren Differenzierung + zwischen stimmberechtigten Mitgliedern, beratenden Mitgliedern und + themenspezifischen Expert*innen. + + # --------------------------------------------------------------------------- + # 2.1 STIMMBERECHTIGTE MITGLIEDER + # --------------------------------------------------------------------------- + + stimmberechtigte_mitglieder: + + - rolle_id: "amtsleitung" + rolle_name: "Amtsleitung" + funktion: "vorsitz" + stimmberechtigt: true + verantwortlichkeiten: + - "Leitung des Mission Boards" + - "Trägt Gesamtverantwortung" + - "Letztes Entscheidungsrecht bei Stimmengleichheit" + + - rolle_id: "cdo" + rolle_name: "Chief Digital Officer (CDO)" + funktion: "mitglied" + stimmberechtigt: true + verantwortlichkeiten: + - "Verantwortet die Digitalisierungsstrategie" + - "Stimmt operative Maßnahmen mit strategischen Zielen ab" + + - rolle_id: "al_n" + rolle_name: "Alle Abteilungsleitungen des DIGIT gemäß aktueller Aufbauorganisation" + funktion: "mitglied" + stimmberechtigt: true + vertretung_moeglich: true + verantwortlichkeiten: + - "Vertreten ihre jeweiligen Abteilungen mit fachlicher, personeller und budgetbezogener Verantwortung" + - "Bringen Abteilungsperspektive und Ressourcenplanung ein" + - "Verantworten operative Umsetzung der Beschlüsse in ihrer Abteilung" + + # --------------------------------------------------------------------------- + # 2.2 BERATENDE MITGLIEDER (regelmäßig teilnehmend, ohne Stimmrecht) + # --------------------------------------------------------------------------- + + beratende_mitglieder: + + - rolle_id: "cos" + rolle_name: "Chief of Staff (CoS)" + stimmberechtigt: false + teilnahme: "regelmaessig" + verantwortlichkeiten: + - "Unterstützt Vorbereitung und Koordination des Gremiums" + + - rolle_id: "isb" + rolle_name: "Informationssicherheitsbeauftragte*r (ISB)" + stimmberechtigt: false + teilnahme: "regelmaessig" + verantwortlichkeiten: + - "Berät zu Security- und Compliance-Aspekten" + - "Identifiziert Risiken und Maßnahmen" + + - rolle_id: "dpm" + rolle_name: "Demand-Portfolio-Management" + stimmberechtigt: false + teilnahme: "agenda_abhaengig" + teilnahme_bei: + - "Neue Demands" + - "Freigaben" + verantwortlichkeiten: + - "Qualifiziert und bewertet neue Demands" + - "Liefert Priorisierungsvorschläge" + + - rolle_id: "spm" + rolle_name: "Service-Portfolio-Management" + stimmberechtigt: false + teilnahme: "agenda_abhaengig" + teilnahme_bei: + - "Service-Performance" + - "Services-Weiterentwicklung" + verantwortlichkeiten: + - "Überwacht Service-Landschaft (SLA-Reports, kritische Services)" + - "Leitet Bedarf für Serviceweiterentwicklung ab" + + - rolle_id: "ppm" + rolle_name: "Projekt-Portfolio-Management" + stimmberechtigt: false + teilnahme: "agenda_abhaengig" + teilnahme_bei: + - "Projektstatus" + - "Projekt-Freigaben" + verantwortlichkeiten: + - "Meldet Status und Risiken aus laufenden Projekten" + - "Berät zur Steuerung und Priorisierung" + + - rolle_id: "board_facilitator" + rolle_name: "Board Meeting Facilitator" + stimmberechtigt: false + teilnahme: "regelmaessig" + verantwortlichkeiten: + - "Erstellt und kommuniziert die Agenda" + - "Moderiert die Sitzung" + - "Achtet auf Zeitplan und Zielerreichung" + - "Koordiniert die Protokollierung" + - "Verfolgt To-dos und Beschlüsse" + + # --------------------------------------------------------------------------- + # 2.3 BEI BEDARF HINZUGEZOGENE EXPERT*INNEN + # --------------------------------------------------------------------------- + + experten_bei_bedarf: + + - rolle_id: "it_architektur" + rolle_name: "IT-Architektur-Board (Vertreter*in)" + stimmberechtigt: false + teilnahme: "bei_bedarf" + verantwortlichkeiten: + - "Beratung bei komplexen technischen Fragen" + - "Architekturentscheidungen" + - "Schnittstellen" + - "Systemauswahl" + + - rolle_id: "projektleitungen" + rolle_name: "Projektleitungen (einzelner Projekte)" + stimmberechtigt: false + teilnahme: "bei_bedarf" + verantwortlichkeiten: + - "Berichten projektbezogen" + - "Erläutern Sachstände und Risiken" + - "Erhalten Feedback und Beschlüsse aus dem Gremium" + + - rolle_id: "stakeholder_management" + rolle_name: "Stakeholder-Management" + stimmberechtigt: false + teilnahme: "bei_bedarf" + verantwortlichkeiten: + - "Bei spezifischen Stakeholder-/Fachbereichsanforderungen eingebunden" + - "Kann Konflikte oder eskalierte Demands erläutern" + + - rolle_id: "notfallmanagement" + rolle_name: "IT-Notfallmanagement" + stimmberechtigt: false + teilnahme: "bei_bedarf" + verantwortlichkeiten: + - "Bei sicherheitskritischen Themen oder Notfallszenarien" + - "Unterstützt taktische Entscheidungen" + +# ============================================================================= +# 3. VERANTWORTUNGSBEREICH +# ============================================================================= + +verantwortungsbereich: + + beschreibung: | + In diesem Kapitel werden die Kernthemen des Mission Board beschrieben. + Ziel ist es, IT- und Digitalisierungsmaßnahmen im Sinne der strategischen + Vorgaben zu steuern, Ressourcen gezielt einzusetzen und Risiken frühzeitig + zu erkennen. + + hinweis: | + Detailfragen einzelner Fachbereiche (z.B. Personalverantwortliche) werden + durch die Amtsleitung und Abteilungsleitungen behandelt. + + # --------------------------------------------------------------------------- + # 3.1 DEMAND- & PROJEKTPORTFOLIO-STEUERUNG + # --------------------------------------------------------------------------- + + demand_projekt_steuerung: + + was: + - "Systematische Evaluierung neuer Vorhaben anhand strategischer Relevanz und Ressourcenverfügbarkeit" + - "Entscheidung über Freigabe, zeitliche Neuplanung oder Beendigung von Projekten und Demands" + - "Integration politischer Vorgaben in die strukturierte Portfolioplanung" + + warum: + - "Fokussierung auf strategisch relevante Vorhaben zur Vermeidung unkoordinierter Ad-hoc-Initiativen" + - "Prävention von Redundanzen und Ressourcenkonflikten durch zentralisiertes Projektportfolio" + - "Gewährleistung der Integration politischer Anforderungen in den strategischen Gesamtrahmen" + - "Bewertung und Management von Schnittstellenabhängigkeiten zwischen Projekten, Services und Systemen zur Sicherstellung einer kohärenten Gesamtarchitektur und Strategie-fit" + + wie: + - "Projekt-Portfolio Reportings mit Statusindikation (bspw. Ampelsystem)" + - "Qualifizierte Voranalyse und Empfehlungserstellung durch das Demand-Portfolio-Management" + - "Architektur-Fit durch regelmäßige Berichte des IT-Architektur-Boards zur Bewertung der technologischen Kompatibilität und Zukunftsfähigkeit von Vorhaben" + + entscheidung: | + Das Mission Board entscheidet über Initiierung, Priorisierung und + Beendigung von IT-/Digitalprojekten und über Demands mit dem Ziel + einer realistischen Umsetzung strategischer Vorgaben. + + # --------------------------------------------------------------------------- + # 3.2 RESSOURCENALLOKATION & KAPAZITÄTSSTEUERUNG + # --------------------------------------------------------------------------- + + ressourcenallokation: + + was: + - "Kontinuierliches Monitoring verfügbarer und allokierter Ressourcen" + - "Fundierte Entscheidungsfindung bezüglich Personal- und Budgetzuordnungen" + - "Repriorisierung von Ressourcen, falls notwendig" + + warum: + - "Prävention von Kapazitätsengpässen in einzelnen Organisationsbereichen" + - "Gewährleistung adäquater Ressourcenausstattung für priorisierte Projektvorhaben" + - "Förderung von Transparenz und Objektivität bei der Allokation limitierter Ressourcen" + + wie: + - "Ressourcen-Informationen (Personal, Budget, Sachmittel)" + - "Engpassmeldungen aus den Abteilungen (Abteilungsleitungen identifizieren Kapazitätskonflikte)" + - "Kurzstellungnahmen von betroffenen Projekten (z.B. 'Für Projekt X fehlen uns 2 FTE')" + - "Finanzabsprache mit Governance-/Finanzstelle, falls Budgetübertragungen nötig sind" + + entscheidung: | + Das Mission Board koordiniert die taktische Allokation von Personal-, + Budget- und Sachmitteln mit dem Ziel der Engpassvermeidung und + effizienten Projekt- und Betriebsdurchführung. + + # --------------------------------------------------------------------------- + # 3.3 MONITORING & ESKALATION + # --------------------------------------------------------------------------- + + monitoring_eskalation: + + was: + - "Regelmäßige Statusbewertung für Projekte und Services mittels standardisierter Bewertungsmethodik (Ampelsystem)" + - "Frühzeitige Erkennung von Engpässen oder Risiken, deren Bewältigung die Kapazitäten einzelner Fachbereiche übersteigt" + - "Entwicklung und Implementierung taktischer Gegenmaßnahmen" + + warum: + - "Minimierung eskalierender Problementwicklungen durch proaktive Intervention" + - "Herstellung von Transparenz bezüglich Projektfortschritt und Servicequalität" + - "Zeitnahe Reaktionsfähigkeit bei signifikanten Abweichungen oder Servicebeeinträchtigungen" + + wie: + - "Projektstatus-Report (Ampelsystem) aus dem Projekt-Portfolio-Management" + - "Service-Performance-Report für kritische Services erstellt vom Service-Portfolio-Management" + - "Risikomeldungen oder Konflikt-Eskalationen durch Abteilungsleitungen" + - "Berichte und Bewertungen des IT-Architektur-Boards zu kritischen technologischen Themen (proaktiv oder auf Anforderung des Mission Boards)" + + entscheidung: | + Das Mission Board bewertet laufende Projekte und kritische Services, + identifiziert frühzeitig potenzielle Probleme und initiiert Lösungen + oder leitet geregelte Eskalationsverfahren ein. + + # --------------------------------------------------------------------------- + # 3.4 UMSETZUNG STRATEGISCHER ENTSCHEIDUNGEN + # --------------------------------------------------------------------------- + + umsetzung_strategie: + + was: + - "Harmonisierung der taktischen Planung mit aktuellen strategischen Zielvorgaben" + - "Kontinuierliche Überprüfung der Strategiekonformität laufender Vorhaben" + - "Bedarfsgerechte Modifikation von Projektzielen oder Zeitplänen bei strategischen Kurskorrekturen" + + warum: + - "Sicherstellen, dass die operative Umsetzung mit den strategischen Zielen übereinstimmt" + - "Gewährleistung zeitnaher Anpassungsfähigkeit bei politischen oder strategischen Richtungsänderungen" + - "Etablierung einer kontinuierlichen Qualitätskontrolle für sämtliche laufenden Initiativen" + + wie: + - "Strategie-Updates vom Vision Board" + - "Roadmap-Abgleich: Welche laufenden Projekte müssen angepasst werden?" + - "Architektur- und ISB-Feedback bei größeren Kursänderungen" + - "Review bzw. Re-Priorisierung im Board, wenn Projekt/Service nicht mehr zum neuen Zielbild passt" + - "Regelmäßige und anlassbezogene Rückmeldung relevanter Erkenntnisse aus der operativen Umsetzung an das Vision Board, um strategische Entscheidungen mit der Realität abzugleichen" + + entscheidung: | + Das Mission Board transformiert strategische Vorgaben des Vision Boards + und des Gemeinderats in umsetzbare Projekte und Maßnahmen und justiert + Prioritäten bei strategischen Neuausrichtungen entsprechend. + + # --------------------------------------------------------------------------- + # 3.5 QUERSCHNITT: SECURITY, COMPLIANCE & POLITIK + # --------------------------------------------------------------------------- + + security_compliance_politik: + + was: + - "Situativ angemessene Konsultation von Informationssicherheitsbeauftragten, Datenschutzstellen, IT-Notfallmanagement oder relevanten politischen Stakeholdern" + - "Systematische Integration politischer Initiativen in das strukturierte Demand-Portfolio" + - "Implementierung eines übergreifenden Risikomanagements für Sicherheits- und Compliance-relevante Aspekte" + + warum: + - "Sicherstellung der Konformität mit gesetzlichen Vorgaben und strategischen Richtlinien" + - "Prävention kostenintensiver Nachbesserungen durch frühzeitige Koordination relevanter Faktoren" + - "Integration politischer Vorgaben in die strukturierte Planung anstelle reaktiver Ad-hoc-Implementierung" + + wie: + - "Security & Compliance-Check durch ISB oder Compliance-Stelle (Risikoabschätzung, Freigabeempfehlung)" + - "Politische Anforderungen: Demand-Portfolio Management und Stakeholder Manager*in liefert Machbarkeitsabgleich" + + entscheidung: | + Das Mission Board integriert Sicherheits-, Datenschutz- und politische + Anforderungen in alle taktischen Entscheidungsprozesse unter Wahrung + der Grenzen der Detailverantwortung. + +# ============================================================================= +# 4. ENTSCHEIDUNGSPROZESSE UND ABLÄUFE +# ============================================================================= + +entscheidungsprozesse: + + beschreibung: | + Das Mission Board steuert alle taktischen Entscheidungen innerhalb des + vom Vision Board festgelegten strategischen Rahmens und des genehmigten + Budgets. + + grundsaetze: + + ziel: | + Das Gremium zielt darauf ab, frühzeitig Klarheit über Anforderungen, + Ressourcen und Risiken zu schaffen, um Ad-hoc-Entscheidungen mit + unkalkulierbaren Folgen zu vermeiden. + + prinzipien: + + - name: "Strategische Passung" + beschreibung: | + Jede Maßnahme soll zu den Zielen des Vision Boards passen und + einen erkennbaren Mehrwert liefern. + + - name: "Effektive Ressourcennutzung" + beschreibung: | + Personal, Budget und Zeit werden so verteilt, dass Engpässe + minimiert und wichtige Projekte priorisiert werden. + + - name: "Transparente Prozesse" + beschreibung: | + Fortschritte, Engpässe und Konflikte werden offen adressiert + und nach Möglichkeit zeitnah gelöst. + + # --------------------------------------------------------------------------- + # 4.1 GRUNDSÄTZE ZUR BESCHLUSSFASSUNG + # --------------------------------------------------------------------------- + + beschlussfassung: + + grundprinzip: "konsens_mehrheit" + + beschreibung: | + Das Gremium strebt einen Konsens an. Kann dieser nicht erzielt werden, + entscheidet die einfache Mehrheit der stimmberechtigten Mitglieder. + Bei Stimmengleichheit entscheidet die Stimme der Vorsitzenden (Amtsleitung). + + quorum: + regel: "nicht_formal_definiert" + beschreibung: | + Formale Quorum-Regeln sind in der aktuellen Fassung der Geschäftsordnung + nicht vorgesehen. Stattdessen sorgt der Board Facilitator in Rücksprache + mit dem Chief of Staff (CoS) dafür, dass die relevanten Personen für + Entscheidungen teilnehmen. + bei_unvollstaendigkeit: | + Sollte sich eine Entscheidung nicht mit hinreichender Verbindlichkeit + treffen lassen, wird sie auf einen Folgetermin vertagt, bis alle + benötigten Informationen und Beteiligten verfügbar sind. + + # --------------------------------------------------------------------------- + # 4.2 ENTSCHEIDUNGSKATEGORIEN + # --------------------------------------------------------------------------- + + entscheidungskategorien: + + # ------------------------------------------------------------------------- + # 4.2.1 Initiierung und Priorisierung neuer Vorhaben + # ------------------------------------------------------------------------- + + - kategorie_id: "initiierung_priorisierung" + name: "Initiierung und Priorisierung neuer Vorhaben" + + umfang: + - "Entscheidung über Start und Priorisierung neuer IT-/Digital-Projekte" + - "Bewertung von Demands nach: Strategischer Relevanz, Nutzen, Machbarkeit, Ressourcenverfügbarkeit, Zeithorizont/Dringlichkeit, Risikomaß (Optional)" + + ziel: "Vermeidung unkoordinierter Ad-hoc-Projekte durch strukturierte Prüfung" + + vorbereitung: + - "Demand-/Projektportfoliomanagement sammelt Bewertungsinformationen" + - "Empfehlung wird auf Basis der Analyse erstellt und dem Board vorgelegt" + - "Bei Bedarf: Ergänzung durch politische Vorgaben und Fachexpertise relevanter Abteilungen" + + entscheidungsprozess: + - "Vorstellung der neuen Projektidee" + - "Diskussion im Mission Board, Abwägung von Nutzen, Risiken, Ressourcenverfügbarkeit" + - "Beschluss (Mehrheitsentscheidung oder Konsens)" + + entscheidungsoptionen: + - option: "sofort_freigeben" + beschreibung: "Ressourcen stehen bereit" + naechster_schritt: "Übergabe an das Projekt-Portfolio-Management" + + - option: "freigabe_ressourcenpruefung" + beschreibung: "Freigabe, Ressourcenverfügbarkeit muss geprüft werden" + + - option: "vertagen" + beschreibung: "Vertagen/weitere Infos einholen" + + - option: "ablehnen" + beschreibung: "Ablehnen" + + eskalation: | + Eskalation erfolgt bei fehlender Entscheidungsfähigkeit des Boards + oder wenn der Vorschlag das Board-Mandat übersteigt. Weiterleitung + typischerweise an Vision Board oder Verwaltungsleitung, besonders + bei strategischen Fragen oder großem Ressourcenbedarf. Höhere + Instanz trifft dann Abschlussentscheidung oder gibt Leitlinien + für das Mission Board vor. + + # ------------------------------------------------------------------------- + # 4.2.2 Änderung laufender Projekte + # ------------------------------------------------------------------------- + + - kategorie_id: "aenderung_projekte" + name: "Änderung laufender Projekte" + + umfang: + - "Wesentliche Änderungen in laufenden Projekten" + - "Scope-, Ziel- und Budgetanpassungen" + - "Neuausrichtung oder vorzeitige Beendigung" + + ziel: | + Kontinuierliche Ausrichtung der Projekte an den übergeordneten + strategischen Zielen und Gewährleistung deren erfolgreicher Umsetzung. + + vorbereitung: + - "Change Requests werden von Projektleitung/Portfoliomanagement mit Beschlussvorlage vorbereitet" + - "Vorlage enthält Änderungsanlass, Projektstatus und Impact-Analyse (Budget/Zeit/Ziele)" + - "Bei Bedarf werden Experten-Einschätzungen (z.B. Architektur, Controlling) eingeholt" + + entscheidungsprozess: + - "Projektleitung/Portfolio-Verantwortliche stellt Änderungsantrag im Board vor" + - "Board bewertet Auswirkungen auf das betroffene Projekt und das Gesamtportfolio" + - "Entscheidung erfolgt im Konsens oder per Mehrheitsbeschluss" + + entscheidungsoptionen: + - "Genehmigung" + - "Freigabe unter Auflagen" + - "Ablehnung" + + eskalation: | + Eskalation erfolgt bei fehlender Einigung im Mission Board oder wenn + Entscheidungen außerhalb seiner Befugnisse liegen. Strategisch bedeutsame + Projektänderungen (z.B. vorzeitige Beendigung) oder große Budgetaufstockungen + werden ans Vision Board/Verwaltungsführung weitergeleitet. Dies sichert ab, + dass kritische Änderungen von der richtigen Autoritätsebene entschieden werden. + + # ------------------------------------------------------------------------- + # 4.2.3 Ressourcenallokation und -verteilung + # ------------------------------------------------------------------------- + + - kategorie_id: "ressourcenallokation" + name: "Ressourcenallokation und -verteilung" + + umfang: + - "Verteilung von Personal, Budget und Sachmitteln auf Projekte und operative Maßnahmen" + - "Bei Bedarf Umverteilung zwischen Vorhaben, um Engpässe zu vermeiden" + + ziel: | + Angemessene Ausstattung priorisierter Projekte bei gleichzeitig + effizientem Gesamteinsatz der verfügbaren Ressourcen. + + vorbereitung: + - "Erhebung der aktuellen Ressourcenauslastung und Konsolidierung von Rückmeldungen (Engpässe, fehlende Kapazitäten)" + - "Einbeziehung von Budgetübersichten" + - "Aufbereitung aller Informationen mit konkreten Vorschlägen zur Priorisierung/Umverteilung" + + entscheidungsprozess: + - "Mission Board analysiert Ressourcenberichte" + - "Identifiziert Engpässe/Überbelastungen" + - "Beschließt konkrete Anpassungsmaßnahmen" + + typische_entscheidungen: + - "Verschiebung niedrig priorisierter Projekte" + - "Freigabe zusätzlicher Mittel" + - "Umverteilung von Personal zwischen Vorhaben" + + beschluss: | + Die Beschlüsse werden idealerweise im Konsens, notfalls per + Mehrheitsvotum getroffen und verbindlich an die betroffenen + Bereiche kommuniziert. + + eskalation: | + Eskalation ans Vision Board/Verwaltungsleitung bei unlösbaren + Ressourcenengpässen. Mögliche Eskalationsanlässe: Bedarf an + zusätzlichen Budgetmitteln oder Neujustierung strategischer + Prioritäten. Weiterleitung festgefahrener Bereichskonflikte zur + verbindlichen Entscheidung (z.B. Portfolioneugewichtung, + Bereitstellung externer Ressourcen). + + # ------------------------------------------------------------------------- + # 4.2.4 Problemlösung und Eskalationsmanagement + # ------------------------------------------------------------------------- + + - kategorie_id: "problemloesung" + name: "Problemlösung und Eskalationsmanagement" + + umfang: + - "Behandlung eskalierter Probleme und Risiken aus Projekten/IT-Betrieb, die untere Ebenen nicht selbst lösen können" + - "Analyse der Problemlage" + - "Entscheidung über Gegenmaßnahmen und Verantwortlichkeiten zur Lösung auf taktischer Ebene" + - "Bei Bedarf strukturierte Weiterleitung an höhere Entscheidungsebenen" + + problembeispiele: + - "Gravierende Abweichungen" + - "Ressourcenkonflikte" + + vorbereitung: + - "Probleme werden entweder durch Monitoring-Systeme (rote Ampelwerte) oder durch direkte Meldung von Verantwortlichen identifiziert" + - "Meldender Verantwortlicher dokumentiert Problem, bisherige Maßnahmen, konkrete Auswirkungen und mögliche Lösungsoptionen in einer kompakten Entscheidungsvorlage" + - "Bei Bedarf ergänzen Fachexperten (z.B. ISB, IT-Architektur) den Sachverhalt mit zusätzlichen Analysen" + + entscheidungsprozess: + - "Board analysiert den Fall mit den Betroffenen und diskutiert Lösungswege" + - "Board beschließt konkrete Maßnahmen wie Ressourcenzuweisung, Anpassung von Zielen oder externe Unterstützung" + - "Bei unlösbaren Problemen wird der Fall gemäß Eskalationsplan an die nächsthöhere Stelle weitergeleitet" + + eskalation: + trigger: + - "Board kann ein Problem nicht selbst lösen oder seine Befugnisse werden überschritten" + - "Fälle, die strategische Entscheidungen oder erhebliche zusätzliche Ressourcen erfordern" + - "Kritische Situationen mit möglichen rechtlichen oder politischen Auswirkungen" + + # ------------------------------------------------------------------------- + # 4.2.5 Festlegung von Zielen und taktischen Leitplanken + # ------------------------------------------------------------------------- + + - kategorie_id: "ziele_leitplanken" + name: "Festlegung von Zielen und taktischen Leitplanken" + + umfang: + - "Übersetzung strategischer Vorgaben in messbare operative Ziele und Erfolgskennzahlen" + - "Definition verbindlicher Leitplanken wie Bewertungskriterien, Priorisierungsprinzipien und methodische Vorgaben" + + ziel: | + Sicherstellung eines einheitlichen Vorgehens und Ausrichtung aller + Maßnahmen auf die strategischen Ziele. + + vorbereitung: + - "Grundsatzthemen werden meist in der strategischen Planung vom Board-Leiter (Amtsleitung/Chief of Staff) vorbereitet" + - "Entwürfe basieren auf strategischen Vorgaben, Betriebserfahrungen und Experteninput (IT-Architektur, ISB)" + - "Ergebnis ist ein kompaktes Vorschlagspapier mit konkreten Zielen und Leitplanken" + + entscheidungsprozess: + - "Gemeinsam auf Realisierbarkeit geprüft und bis zur Einigung diskutiert" + - "Formal durch Konsens oder Mehrheitsbeschluss verabschiedet" + - "Als verbindlicher Rahmen dokumentiert und an alle betroffenen Bereiche kommuniziert" + + eskalation: | + Bei Unstimmigkeit oder hat eine Vorgabe strategische/politische + Auswirkungen, eskaliert das Board an das Vision Board oder die + Verwaltungsspitze. Eskalation ist besonders bei Berührung strategischer + Ausrichtungen oder externer Anforderungen (Gesetz, Politik) notwendig. + Nach Klärung durch die höhere Instanz legt das Mission Board die + finalen Ziele und Leitplanken fest. + + # ------------------------------------------------------------------------- + # 4.2.6 Governance- und Compliance-Entscheidungen (Querschnittsthemen) + # ------------------------------------------------------------------------- + + - kategorie_id: "governance_compliance" + name: "Governance- und Compliance-Entscheidungen (Querschnittsthemen)" + + umfang: + - "Sicherstellung, dass Governance-, Sicherheits-, Compliance- und politische Vorgaben beachtet werden" + - "Verabschiedung von Richtlinien für Projekt-Management, Sicherheit, Datenschutz und Prozessstandards" + - "Berücksichtigung politischer Anforderungen vom Oberbürgermeister, Gemeinderat oder Dezernentenrunde" + - "Prozess Management-Richtlinien, die die Standardisierung, Optimierung und Steuerung von Organisationsprozessen betreffen" + - "Freigaben für neue oder überarbeitete Prozessstandards" + + vorbereitung: + - "Fachexperten (ISB, Datenschutz) erstellen Risikoanalysen und Handlungsempfehlungen für sicherheitskritische Themen" + - "Governance/Verwaltung bewertet politische Anforderungen auf Machbarkeit und Auswirkungen" + - "Prozess-Management analysiert Optimierungspotenziale in operativen Abläufen und erarbeitet Verbesserungsvorschläge" + - "Alle relevanten Vorgaben und Risiken werden für informierte Entscheidungen des Boards konsolidiert" + - "Fachvertreter werden zu Sitzungen hinzugezogen, um ihre Empfehlungen direkt einzubringen" + + entscheidungsprozess: + - "Fachverantwortliche präsentieren neue Governance-/Compliance-Anforderungen im Board-Meeting" + - "Mission Board diskutiert operative Auswirkungen sowie Risiken und Vorteile der vorgeschlagenen Änderungen" + - "Bei Bedarf werden betroffene Abteilungen oder das IT-Architektur-Board in die Diskussion einbezogen" + - "Entscheidung erfolgt gemeinschaftlich mit besonderer Berücksichtigung der Fachexpertise" + + entscheidungsoptionen: + - "Freigabe" + - "Anpassungen anfordern" + - "Eskalation an höhere Instanzen" + + eskalation: + - ziel: "Vision Board" + bei: "Grundsatzentscheidungen zu IT-Governance oder Digitalstrategie" + + - ziel: "Verwaltungsleitung oder Gemeinderat" + bei: "Politische Entscheidungen (Budget, Beschlüsse)" + + - ziel: "Fachabteilungen oder externe Prüfstellen" + bei: "Signifikante Compliance- und Sicherheitsfragen" + + - ziel: "Vision Board oder verwaltungsweite Prozessgremien" + bei: "Organisationsweite Prozessänderungen" + + begruendung_eskalation: | + Dies stellt sicher, dass das Mission Board innerhalb seines Mandats + bleibt und übergreifende Risiken an die zuständige Stelle eskaliert werden. + +# ============================================================================= +# 5. SCHNITTSTELLEN UND ABSTIMMUNGSWEGE +# ============================================================================= + +schnittstellen: + + beschreibung: | + Das Mission Board steht im engen Austausch mit anderen Gremien und Ebenen. + + hinweis: | + Neben diesen Hauptschnittstellen interagiert das Mission Board natürlich + auch mit der operativen Ebene: Projektleitungen und Fachabteilungen setzen + die Beschlüsse des Boards um und melden Status oder Eskalationen zurück. + Diese Interaktion läuft im täglichen Betrieb über die Abteilungsleiter*innen + und Portfolio-Manager*innen, die im Mission Board vertreten sind. + + # --------------------------------------------------------------------------- + # 5.1 HAUPTSCHNITTSTELLEN + # --------------------------------------------------------------------------- + + hauptschnittstellen: + + - partner: "Vision Board" + beschreibung: | + Das Mission Board setzt die Strategie des Vision Boards operativ um + und berichtet regelmäßig über Fortschritte und Hindernisse. + interaktion: + - "Strategisch relevante Entscheidungen oder unlösbare Konflikte werden vom Mission Board an das Vision Board eskaliert" + - "Rückkopplungsschleife gewährleistet, dass strategische Entscheidungen auf realistischen operativen Daten basieren" + - "Operatives Geschäft bleibt stets im Einklang mit der Gesamtstrategie" + + - partner: "Demand- & Stakeholder-Runde (DSR)" + beschreibung: | + Neue Anforderungen werden zuerst in der Demand- und Stakeholder-Runde + bewertet, priorisiert und aufbereitet, bevor sie ans Mission Board + weitergeleitet werden. + interaktion: + - "Mission Board entscheidet final über größere Demands" + - "Gibt der Demand-Runde strategische Leitplanken vor" + - "Bei komplexen oder besonders wichtigen Anforderungen kann die Demand-Runde direkt ans Mission Board eskalieren" + + - partner: "IT-Architektur-Board" + beschreibung: | + Das Mission Board berücksichtigt die Vorgaben des IT-Architektur-Boards + für technische Standards und Sicherheitsrichtlinien bei allen + Portfolio-Entscheidungen. + interaktion: + - "Bei technologisch komplexen Projekten werden Vertreter des Architektur-Boards direkt in die Beratung einbezogen" + - "Gewährleistung technischer Machbarkeit und Architekturkonformität" + - "Gegenseitige Information über relevante Entwicklungen" + - "Architekturaspekte fließen frühzeitig in Projektentscheidungen ein" + - "Mission Board trifft keine technischen Detailentscheidungen ohne Fachexpertise" + +# ============================================================================= +# 6. ESKALATIONSMECHANISMEN +# ============================================================================= + +eskalationsmechanismen: + + grundsatz: | + Das Mission Board geht mit Problemen und Konflikten proaktiv und + lösungsorientiert um. Es folgt dem Grundsatz: "Probleme dort lösen, + wo sie entstehen" – also auf der niedrigstmöglichen Ebene. Erst wenn + dies nicht möglich ist, werden strukturierte Eskalationswege beschritten. + + # --------------------------------------------------------------------------- + # 6.1 PROBLEMLÖSUNG AUF BOARD-EBENE + # --------------------------------------------------------------------------- + + problemloesung_board_ebene: + + ablauf: + - "Projektprobleme (z.B. Terminverzug, Ressourcenmangel) werden durch Abteilungs- oder Projektleiter eingebracht" + - "Board analysiert und beschließt direkte Gegenmaßnahmen (Umpriorisierung, Ressourcenumverteilung)" + - "Frühzeitiges Gegensteuern soll weitreichendere Eskalationen vermeiden" + + # --------------------------------------------------------------------------- + # 6.2 ESKALATION ANS VISION BOARD + # --------------------------------------------------------------------------- + + eskalation_vision_board: + + beschreibung: | + Wird erforderlich, wenn Probleme die Befugnisse oder Möglichkeiten + des Mission Boards überschreiten. + + typische_gruende: + + - grund: "Strategische Konflikte" + beschreibung: | + Strategische Konflikte oder Zielkonflikte, die im Mission Board + nicht gelöst werden können (etwa wenn ein Projekt die Gesamtstrategie + infrage stellt). + + - grund: "Ressourcenbedarf oder Budgetüberschreitungen" + beschreibung: | + Ressourcenbedarf oder Budgetüberschreitungen, die außerhalb des + vom Mission Board kontrollierbaren Rahmens liegen (z.B. es werden + Mittel benötigt, die nur durch den Gemeinderat/Vision Board + freigegeben werden können). + + - grund: "Politisch sensible Entscheidungen" + beschreibung: | + Politisch sensible Entscheidungen, bei denen eine Abstimmung mit + dem Oberbürgermeister, Gemeinderat oder Dezernentenrunde, + Top-Management oder der Politik erforderlich ist. + + - grund: "Unauflösbare Konflikte" + beschreibung: | + Unauflösbare Konflikte zwischen Bereichen, wenn trotz Vermittlung + im Mission Board keine Einigung erzielt wird und ein höheres + Organ entscheiden muss. + + - grund: "Risiken zur Erreichung strategischer Zielvorgaben" + beschreibung: | + Risiken zur Erreichung von strategischen Zielvorgaben, wenn + erkennbar wird, dass wichtige strategische Meilensteine oder + Kennzahlen trotz taktischer Gegenmaßnahmen verfehlt werden könnten. + + verfahren: + + beschreibung: | + Bei Eskalationsfällen agiert das Mission Board strukturiert und + zielorientiert. Es erstellt eine präzise Eskalationsvorlage für + das Vision Board. + + vorlage_inhalte: + - "Das Problem klar definiert" + - "Bereits geprüfte Lösungsoptionen darstellt" + - "Einen konkreten Vorschlag oder Klärungsbedarf formuliert" + + entscheidung: | + Auf Basis dieser Vorlage entscheidet das Vision Board über das + weitere Vorgehen oder gibt Leitplanken vor. + + subsidiaritaetsprinzip: + + beschreibung: | + Zentral dabei ist das Subsidiaritätsprinzip: Probleme werden stets + auf der niedrigstmöglichen Ebene gelöst, um Effizienz zu wahren. + + ebenen: + - problem_typ: "Routineprobleme" + zustaendig: "Fachabteilung" + + - problem_typ: "Bereichsübergreifende taktische Probleme" + zustaendig: "Mission Board" + + - problem_typ: "Strategische oder außerordentliche Probleme" + zustaendig: "Vision Board" + + # --------------------------------------------------------------------------- + # 6.3 ESKALATIONSTRIGGER + # --------------------------------------------------------------------------- + + eskalationstrigger: + + beschreibung: | + Um Transparenz und Konsistenz zu gewährleisten, dokumentiert das + Mission Board alle Eskalationstrigger und -stufen schriftlich und + verfolgt Eskalationsfälle konsequent nach. Diese Dokumentation hilft + dabei, ähnliche Probleme in Zukunft zu vermeiden. + + trigger: + + - name: "Strategische Konflikte" + beschreibung: | + Sobald ein Projekt oder eine Entscheidung zentrale Zielsetzungen + des Vision Boards infrage stellt oder grundlegende + Strategieänderungen erfordert. + + - name: "Budgetüberschreitungen" + beschreibung: | + Wenn der Finanzrahmen des Mission Boards nicht mehr ausreicht + und übergeordnete Freigaben (z.B. durch Gemeinderat, + Verwaltungsleitung) notwendig werden. + + - name: "Politische Sensitivität" + beschreibung: | + Bei Vorgaben oder Beschlüssen, die möglicherweise politischen + Rückhalt erfordern bzw. erhebliche Außenwirkung haben und nicht + allein vom Mission Board verantwortet werden können. + + - name: "Bereichsübergreifende Konflikte" + beschreibung: | + Wenn trotz Vermittlungsversuchen im Mission Board kein Konsens + zwischen betroffenen Abteilungen oder Projekten erzielt wird und + eine höhere Autorität entscheiden muss. + + - name: "Rechtliche oder Compliance-relevante Aspekte" + beschreibung: | + Insbesondere bei Verstößen gegen Sicherheitsauflagen, + Datenschutzgesetze oder andere zwingende Vorgaben, die außerhalb + des Mandats des Mission Boards geregelt werden müssen. + + - name: "Gravierende Termin- und Qualitätsrisiken" + beschreibung: | + Sobald Verzögerungen oder Qualitätsprobleme den Erfolg zentraler + Vorhaben gefährden und das Mission Board keine hinreichenden + Gegenmaßnahmen mehr treffen kann. + + anmerkung: | + Welche Eskalationsstufe jeweils gewählt wird, richtet sich nach + Ausmaß und Art des Problems. Üblicherweise erfolgt eine Eskalation + an das Vision Board, sobald das Mission Board selbst den + Handlungsspielraum überschreitet (z.B. wegen fehlender Ressourcen, + nötiger Strategieänderungen oder politischer Tragweite). + + zweck: | + Die hier aufgeführten Punkte sollen es allen Beteiligten erleichtern, + kritische Situationen frühzeitig zu erkennen und an die richtige + Stelle zu adressieren. Auf diese Weise lassen sich größere Schäden + abwenden, und das Mission Board kann sich auf sein Kerngeschäft – + die taktische Steuerung von IT- und Digitalisierungsinitiativen – + konzentrieren. + +# ============================================================================= +# 7. DOKUMENTATION UND REPORTING +# ============================================================================= + +dokumentation_reporting: + + beschreibung: | + Eine saubere Dokumentation und regelmäßiges Reporting stellen die + Nachvollziehbarkeit der Entscheidungen und die Informationsversorgung + aller Stakeholder*innen sicher. + + # --------------------------------------------------------------------------- + # 7.1 PROTOKOLLIERUNG + # --------------------------------------------------------------------------- + + protokollierung: + + methode: "live_protokoll" + + beschreibung: | + Jede Sitzung des Mission Boards wird live protokolliert. + + inhalte: + - "Wichtige Aspekte und getroffene Entscheidungen (mit Begründung, falls notwendig)" + - "Die Verantwortlichen für Folgeaktionen" + - "Etwaige abweichende Meinungen oder offene Punkte" + + beschluesse: + erfassung: "Mit einer eindeutigen Kennziffer erfasst" + zweck: "Umsetzung kann nachverfolgt werden" + + # --------------------------------------------------------------------------- + # 7.2 ENTSCHEIDUNGS-TRACKING + # --------------------------------------------------------------------------- + + entscheidungs_tracking: + + beschreibung: | + Beschlossene Maßnahmen und Aufträge werden in einem Entscheidungs- + und Maßnahmentracker festgehalten. + + tool_beispiele: + - "Confluence-Liste" + - "Excel-Übersicht" + + verantwortlich: "Board Facilitator" + + ueberpruefung: | + Zu Beginn jeder Sitzung wird der Status früherer Beschlüsse kurz + überprüft, um sicherzustellen, dass Entscheidungen umgesetzt wurden + bzw. um Hindernisse dabei frühzeitig zu erkennen. + + zweck: | + Dieses regelmäßige Tracking schafft Verbindlichkeit und Transparenz + über den Outcome der Board-Entscheidungen. + + # --------------------------------------------------------------------------- + # 7.3 REGELMÄSSIGE REPORTS + # --------------------------------------------------------------------------- + + regelmaessige_reports: + + beschreibung: | + Zur fundierten Entscheidungsfindung erhält das Mission Board vor + jeder Sitzung standardisierte Berichte. Diese werden von den + zuständigen Portfolio-Verantwortlichen bzw. Abteilungen erstellt + und an alle Mitglieder verteilt. + + verteilung: | + Die genannten Berichte gehen standardmäßig an alle Mission-Board-Mitglieder + (stimmberechtigte und beratende) vorab über den Board Facilitator zur + Vorbereitung. Wichtige Kennzahlen oder Zusammenfassungen daraus werden + bei Bedarf auch dem Vision Board zur Verfügung gestellt, insbesondere + wenn sie für strategische Entscheidungen relevant sind. + + zweck: | + Durch das feste Reporting-Set ist sichergestellt, dass das Mission Board + stets aktuelle, vollständige Informationen hat und Entscheidungen + datenbasiert treffen kann. + + reports: + + - name: "Demand-Portfolio-Bericht" + erstellt_von: "Demand-Portfolio-Management" + inhalt: | + Übersicht aller neuen und offenen Anforderungen (Demands) inkl. + Bewertung ihres strategischen Nutzens, Aufwands und Priorisierungsstatus. + + - name: "Projekt-Portfolio-Bericht" + erstellt_von: "Projekt-Portfolio-Management" + inhalt: | + Statusbericht zu allen laufenden Projekten mit Ampelstatus, + wichtigen Meilensteinen, Risiken, Problemen und Abhängigkeiten. + Dieser Report gibt dem Board einen Gesamtüberblick und identifiziert + Projekte, die besonderer Aufmerksamkeit bedürfen. + + - name: "Service-Bericht" + erstellt_von: "Service-Portfolio-Management" + inhalt: | + Bericht über die Betriebs- und Servicekennzahlen kritischer + IT-Services (z.B. Verfügbarkeit, Störungen, SLA-Einhaltung, + Sicherheitsvorfälle). So behält das Board neben Projekten auch + den laufenden IT-Betrieb im Blick und kann bei Qualitätsproblemen + reagieren. + + - name: "Ressourcen-Report" + erstellt_von: "Governance/Verwaltung und Abteilungsleitungen" + inhalt: | + Zusammenstellung der aktuellen Personalkapazitäten und Budgetmittel + vs. der geplanten/benötigten Ressourcen in Projekten. Enthält auch + Hinweise auf Engpässe oder Überlast in bestimmten Bereichen. Dieser + Bericht ermöglicht dem Mission Board, Engpasssituationen zu erkennen + und früh gegenzusteuern. + + - name: "Statusberichte für kritische Vorhaben" + erstellt_von: "Projektleitung über das Projekt-Portfolio-Management" + inhalt: | + Für Projekte oder Initiativen, die als kritisch eingestuft sind + (z.B. wegen hoher strategischer Bedeutung oder erheblicher Probleme), + werden detaillierte Sonderberichte vorgelegt. Diese enthalten + tiefergehende Analysen und ggf. Eskalationsempfehlungen, damit das + Board gezielt über solche Sonderfälle beraten kann. + + # --------------------------------------------------------------------------- + # 7.4 KOMMUNIKATION DER BESCHLÜSSE + # --------------------------------------------------------------------------- + + kommunikation_beschluesse: + + beschreibung: | + Relevante Board-Entscheidungen werden an die jeweiligen Umsetzungsteams + kommuniziert, zum Beispiel durch den Versand des Protokolls an beteiligte + Projektleitungen. + + eskalation_information: | + Müssen darüber hinaus das Vision Board oder andere Gremien informiert + werden (z.B. bei Eskalationen oder strategischen Themen), so erhalten + sie eine kurze Management Summary. + + zweck: | + Das schafft stadtweit Transparenz, ohne die Vertraulichkeit interner + Diskussionen zu verletzen. + + zusammenfassung: | + Zusammenfassend stellt die Kombination aus Protokollierung, regelmäßigen + Reports und aktivem Tracking sicher, dass Entscheidungen nachvollziehbar + dokumentiert sind und deren Umsetzung konsequent verfolgt wird. + Informationsflüsse nach oben (Vision Board) und unten (Fachbereiche/Projekte) + sind etabliert, sodass alle Beteiligten stets auf dem aktuellen Stand sind. + +# ============================================================================= +# 8. MEETING-RHYTHMUS UND ABLAUF +# ============================================================================= + +meeting_rhythmus: + + # --------------------------------------------------------------------------- + # 8.1 REGULÄRE SITZUNGEN + # --------------------------------------------------------------------------- + + regulaere_sitzungen: + frequenz: "zweiwochenrhythmus" + tag: "mittwoch" + dauer_minuten: 120 + + vorbereitung: | + Alle Mitglieder sind verpflichtet, sich im Vorfeld auf die Sitzungen + angemessen vorzubereiten. + + # --------------------------------------------------------------------------- + # 8.2 AD-HOC SITZUNGEN + # --------------------------------------------------------------------------- + + ad_hoc_sitzungen: + einberufung: "bei_bedarf" + voraussetzung: "Vorherige Abstimmung mit den relevanten Mitgliedern" + + # --------------------------------------------------------------------------- + # 8.3 AGENDA-ERSTELLUNG + # --------------------------------------------------------------------------- + + agenda_erstellung: + verantwortlich: "Board Facilitator" + abstimmung_mit: "Chief of Staff (CoS)" + + inhalte: + - "Alle vorgesehenen Tagesordnungspunkte" + - "Vorbereitete Unterlagen zu den wichtigsten zu besprechenden Themen" + + # --------------------------------------------------------------------------- + # 8.4 DOKUMENTATION + # --------------------------------------------------------------------------- + + dokumentation: + methode: "Live-Protokoll während jeder Sitzung" + + pflichtinhalte: + - "Alle relevanten Beschlüsse und Entwicklungen" + - "Welche Folgemaßnahmen vereinbart wurden" + - "Welche Mitglieder für Folgemaßnahmen verantwortlich sind" + + # --------------------------------------------------------------------------- + # 8.5 EINREICHUNGSFRIST FÜR UNTERLAGEN + # --------------------------------------------------------------------------- + + einreichungsfrist: + frist: "Montag der jeweiligen Sitzungswoche, 12:00 Uhr" + anforderung: "Verwendung der vorgegebenen einheitlichen Vorlage" + + # --------------------------------------------------------------------------- + # 8.6 BESCHLUSSVORLAGEN + # --------------------------------------------------------------------------- + + beschlussvorlagen: + qualitaetssicherung: "Vor Behandlung im Gremium" + finale_entscheidung: "Obliegt dem Vision Board" + +# ============================================================================= +# 9. ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "0.3" + datum: "2025-03-20" + aenderung: "Initiale YAML-Fassung basierend auf Word-Dokument" + autor: "DIGITOM-Projekt" + quelle: "250320_Mission_Board-Geschäftsordnung_v0_3.docx" diff --git a/#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml b/#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml index b051750..6cac79e 100644 --- a/#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml +++ b/#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml @@ -1,837 +1,837 @@ -# ============================================================================= -# FUNKTIONSBESCHREIBUNG: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "funktionsbeschreibung" - funktion_id: "pm" - funktion_name: "Prozess-Management" - aliases: ["PM", "PZM", "Prozess-Funktion"] - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Governance" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied", "PM-Leitung"] - status: "draft" - - kontext_tags: - - "prozess-management" - - "funktion" - - "prozess-governance" - - "prozess-optimierung" - - "befaehigung" - - "key-user" - - quellen: - - "#02 - Prozess-Management: Funktionsbeschreibung.docx" - - taxonomie_referenz: "#00_meta/digitom_taxonomie.yaml" - -# ============================================================================= -# ABKÜRZUNGSVERZEICHNIS -# ============================================================================= - -abkuerzungen: - pm: "Prozess-Management" - pzm: "Prozess-Management (alternative Abkürzung)" - dpm: "Demand-Portfolio-Management" - spm: "Service-Portfolio-Management" - shm: "Stakeholder-Management" - ppm: "Projekt-Portfolio-Management" - mb: "Mission Board" - vb: "Vision Board" - digitom: "Digital Target Operating Model" - -# ============================================================================= -# 1. ZWECK -# ============================================================================= - -zweck: - wozu_existiert_diese_funktion: - kurz: | - Das Prozess-Management gestaltet aktiv die Art und Weise, wie das DIGIT arbeitet. - Als unterstützende und befähigende Einheit etabliert und verantwortet es den - verbindlichen methodischen Rahmen für alle übergreifenden (Organisations-)Prozesse (DIGITOM). - - ausfuehrlich: | - Das Prozess-Management agiert im Auftrag des Vision Board (strategisches Führungsgremium) - und dient internen Kunden - den Fachbereichen/Abteilungen und ihren Key Usern sowie - den Projektteams - indem es methodische Standards, Werkzeuge und Beratung bereitstellt, - damit diese ihre Prozesse eigenständig managen und verbessern können. - - Ziel ist es, durch klare Strukturen, einheitliche Standards und gezielte Befähigung - eine solide Grundlage für Effektivität, Transparenz und kontinuierliche Verbesserung - im gesamten Amt zu schaffen. - - Dadurch unterstützt das Prozess-Management die erfolgreiche Umsetzung der Digitalstrategie - und schafft Arbeitsabläufe, die gut funktionieren und sich flexibel an neue Anforderungen - anpassen lassen. - - wertbeitrag: - - "Einheitliche, vergleichbare und nachvollziehbare Prozessdokumentation im Amt" - - "Methodische Qualität und Effektivität in der Prozessgestaltung und -optimierung" - - "Gemeinsame 'Prozess-Sprache' und Verständnis über Abteilungsgrenzen hinweg" - - "Befähigung der Organisation zur eigenverantwortlichen Prozesssteuerung" - - "Flexibel anpassbare Arbeitsabläufe für neue Anforderungen" - - kritisches_merkmal: | - Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation. - Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung - zu ersetzen. Die Verantwortung bleibt, wo sie hingehört - bei den Fachbereichen. - - hauptziel: - beschreibung: | - Nachhaltig wirksame und anpassungsfähige Prozesse in der Organisation zu verankern. - - erreicht_durch: - - id: "Z1" - aktivitaet: "Prozesslandschaft schaffen und pflegen" - beschreibung: | - Eine konsistente, transparente und an der Strategie ausgerichtete Prozesslandschaft - schaffen und pflegen, die Silos überwindet. - umfasst: - - "Erhebung und Visualisierung der Prozesslandkarte" - - "Laufende Pflege und Aktualisierung" - - "Strategische Ausrichtung sicherstellen" - - - id: "Z2" - aktivitaet: "Organisation befähigen" - beschreibung: | - Die Organisation durch gezielte Beratung, Coaching und Schulung befähigen, - ihre Prozesse innerhalb des Rahmens eigenverantwortlich zu steuern und zu optimieren. - umfasst: - - "Beratung und Coaching von Prozessverantwortlichen" - - "Schulungen und Workshops durchführen" - - "Key-User-Netzwerk aufbauen und betreuen" - - - id: "Z3" - aktivitaet: "Prozess-Governance überwachen" - beschreibung: | - Die Einhaltung der Prozess-Governance (Standards, Methoden, Dokumentation) als Grundlage - für Qualität, Nachvollziehbarkeit und Verlässlichkeit überwachen und unterstützen. - umfasst: - - "Qualitäts-Checks und Reviews durchführen" - - "Framework-Konformität prüfen" - - "Governance-Lücken identifizieren und adressieren" - - - id: "Z4" - aktivitaet: "DIGITOM weiterentwickeln" - beschreibung: | - Die kontinuierliche Weiterentwicklung und Anpassung des DIGITOMs als lebendiges - Organisationsmodell vorantreiben, um auf veränderte Anforderungen und gewonnene - Erkenntnisse reagieren zu können. - umfasst: - - "Analyse interner Bedarfe und externer Best Practices" - - "Konzepte zur Weiterentwicklung erarbeiten" - - "Änderungen umsetzen und kommunizieren" - -# ============================================================================= -# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG -# ============================================================================= - -funktionsverstaendnis: - charakterisierung: - typ: "Unterstützende und befähigende Funktion" - - beschreibung: | - Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation. - Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung - zu ersetzen. Dies beinhaltet eine klare Rollenverteilung zwischen Linienorganisation - und Prozessmanagement. - - grundprinzipien: - - prinzip_1: - name: "Die Verantwortung bleibt, wo sie hingehört" - beschreibung: | - Die Fachbereiche/Abteilungen sind fachlich und operativ für die Ausführung und Ergebnisse - ihrer Prozesse verantwortlich. Sie liefern die Prozessinhalte und gewährleisten funktionierende - Abläufe im Tagesgeschäft. Hierfür werden in der Regel Prozessverantwortliche - wie Key User - oder Process Owner - als erste Ansprechpartner benannt. - - Das zentrale Prozess-Management verantwortet Rahmen und Methodik der Prozessarbeit, gibt - Standards vor, überblickt die Prozesslandschaft und berät Prozessverantwortliche. Es greift - nicht in die Liniensteuerung ein, sondern beeinflusst durch Expertise, Governance und - Koordination. Entscheidungen werden bei Bedarf über Gremien initiiert. - auswirkung: | - Klare Trennung zwischen operativer Prozessverantwortung (Fachbereich) und - methodischer Prozessverantwortung (PM). Eigenverantwortung der Fachbereiche bleibt erhalten. - referenz: "#02 - Funktionsbeschreibung.docx" - - prinzip_2: - name: "Partnerschaft statt Kontrolle" - beschreibung: | - Prozess-Management agiert als proaktiver Partner der Fachbereiche/Abteilungen und schafft - einen verbindlichen Ordnungsrahmen. Bei signifikanten Abweichungen von Standards oder - Governance-Lücken greift es unterstützend ein. - auswirkung: | - Fördert Vertrauen: Fachbereiche erhalten Unterstützung zur Selbsthilfe, während das - Management die Einhaltung der Standards und der Gesamtzusammenhänge gewährleistet sieht. - referenz: "#02 - Funktionsbeschreibung.docx" - - prinzip_3: - name: "Strukturierte Leistungserbringung" - beschreibung: | - Das Prozess-Management differenziert seine Unterstützung nach vier Leistungskategorien, - die unterschiedlichen Beauftragungswegen und Priorisierungslogiken folgen. - auswirkung: | - Bedarfsgerechte Ressourcensteuerung und klare Erwartungen auf allen Seiten. - referenz: "#02 - Funktionsbeschreibung.docx" - - leistungskategorien: - - kategorie: "Standard-Leistungen" - beschreibung: "Wiederkehrende Unterstützung für operative Prozessbedarfe (Beratung, Workshops, Schulungen)" - beauftragung: "Niedrigschwellig, etablierte Muster" - - - kategorie: "Projekt-Leistungen" - beschreibung: "Ressourcenintensive Vorhaben mit mehrwöchiger Laufzeit (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)" - beauftragung: "Formale Beauftragung durch Mission Board" - - - kategorie: "Strategische Leistungen" - beschreibung: "Weiterentwicklung des DIGITOMs, grundlegende Transformation der Prozesslandschaft" - beauftragung: "Beauftragung durch Vision Board" - - - kategorie: "Krisen-Leistungen" - beschreibung: "Akute Prozessstörungen oder Compliance-Verstöße mit sofortigem Handlungsbedarf" - beauftragung: "Sofortige Priorisierung, andere Aktivitäten werden zurückgestellt" - - abgrenzung_zu_angrenzenden_funktionen: - - - funktion: "dpm" - name: "Demand-Portfolio-Management" - dpm_tut: | - Steuert und priorisiert Demands über den gesamten Lifecycle. - Managt das Demand-Portfolio und koordiniert die Umsetzung. - pm_tut: | - Definiert den methodischen Rahmen für Prozesse, die Demands auslösen können. - Unterstützt bei Prozessänderungen, die aus Demands resultieren. - schnittstelle: | - Demands können Prozess-Änderungen sein. PM unterstützt DPM bei der Bewertung - prozessualer Auswirkungen von Demands. - - - funktion: "spm" - name: "Service-Portfolio-Management" - spm_tut: | - Steuert das Service-Portfolio, verantwortet Service-Lifecycle und Service-Level. - Managt servicebezogene Prozesse nach ITIL-Framework. - pm_tut: | - Stellt methodischen Rahmen für die Dokumentation von Service-Prozessen bereit. - Unterstützt bei der Gestaltung und Standardisierung von Service-Prozessen. - schnittstelle: | - Services basieren auf Prozessen. PM liefert Methodik und Framework, - SPM wendet diese auf Service-Prozesse an. Gegenseitiges Feedback zur - Anwendbarkeit des Frameworks. - - - funktion: "shm" - name: "Stakeholder-Management" - shm_tut: | - Identifiziert und managt Stakeholder-Beziehungen. - Erfasst Stakeholder-Anforderungen und -Feedback. - pm_tut: | - Definiert Prozesse für den Umgang mit externen Stakeholdern. - Berücksichtigt Stakeholder-Anforderungen in der Prozessgestaltung. - schnittstelle: | - Stakeholder haben Prozess-Anforderungen. PM erhält von SHM Anforderungen - (z.B. Kundenfeedback, regulative Vorgaben), die Prozesse beeinflussen. - - - funktion: "ppm" - name: "Projekt-Portfolio-Management" - ppm_tut: | - Plant und priorisiert Projekte. - Steuert das Projekt-Portfolio. - pm_tut: | - Definiert Vorgaben, wie Projekte im Rahmen des DIGITOM ablaufen sollen. - Bewertet Machbarkeit von Projekten aus prozessualer Sicht. - schnittstelle: | - Projekte können Prozess-Änderungen erfordern. PM erhält Informationen zu - geplanten Projekten und deren Prozessauswirkungen. - -# ============================================================================= -# 3. VERANTWORTUNGSBEREICHE -# ============================================================================= - -verantwortungsbereiche: - - beschreibung: | - Das Prozess-Management gliedert sich in fünf Kernverantwortungsbereiche, - die das Spektrum von der Framework-Definition über das Prozesslandschafts-Management - bis zur Befähigung und Leistungssteuerung abdecken. - - # --------------------------------------------------------------------------- - # 3.1 VERANTWORTUNGSBEREICH 1 - # --------------------------------------------------------------------------- - bereich_1_framework: - id: "VB1" - name: "Prozess-Management-Framework definieren und weiterentwickeln" - - beschreibung: | - Definition, Kommunikation und Weiterentwicklung der verbindlichen methodischen - und technischen Grundlagen für das gesamte Prozess-Management im DIGIT als - Fundament für einheitliche und qualitativ hochwertige Prozessarbeit. - - was: - - "Etablierung eines einheitlichen Prozess-Management-Frameworks: Gemeinsame verbindliche Standards und Methoden für die Darstellung, Dokumentation und Steuerung von Prozessen" - - "Festlegung von Governance-Regeln und Richtlinien für alle Aspekte der Prozessarbeit (von der Dokumentation über die Analyse bis zur Steuerung)" - - "Auswahl, Bereitstellung und laufende Betreuung zentraler Prozess-Management-Werkzeuge" - - warum: - - "Sicherstellung einer einheitlichen, vergleichbaren und nachvollziehbaren Prozessdokumentation im Amt" - - "Gewährleistung von methodischer Qualität, Effektivität und fundierter Erhebung in der Prozessgestaltung und -optimierung" - - "Schaffung einer gemeinsamen 'Prozess-Sprache' und eines gemeinsamen Verständnisses für Prozessarbeit über Abteilungsgrenzen hinweg" - - wie: - governance: - - "Laufende Analyse von internen Bedarfen und externen Best Practices/Standards im Prozess-Management" - - "Abstimmung der Anforderungen mit Fachbereichen, IT-Architektur und übergreifenden Governance-Vorgaben" - - "Klare Dokumentation des Prozess-Management-Frameworks (z.B. Methodenhandbuch oder Playbook)" - - frequenz: - - "Framework-Reviews: quartalsweise" - - "Tool-Updates: bei Bedarf" - - "Schulungen: laufend" - - outputs: - - "Prozess-Management-Framework (Methodenhandbuch/Playbook)" - - "Governance-Regeln und Richtlinien" - - "Tool-Dokumentation und Anleitungen" - - # --------------------------------------------------------------------------- - # 3.2 VERANTWORTUNGSBEREICH 2 - # --------------------------------------------------------------------------- - bereich_2_prozesslandschaft: - id: "VB2" - name: "Übergreifende Prozesslandschaft managen und Governance sicherstellen" - - beschreibung: | - Aufbau, Pflege und Überwachung der Gesamtarchitektur der bereichsübergreifenden - Prozesse (Kern-, Management- und Supportprozesse) des DIGIT zur Schaffung von - Transparenz, zur Steuerung und zur Sicherstellung der Einhaltung des definierten Rahmens. - - was: - - "Erhebung, Visualisierung und laufende Pflege der übergreifenden Prozesslandkarte des DIGIT" - - "Überwachung der Einhaltung des Prozess-Management-Frameworks (Methoden, Standards, Dokumentationsqualität)" - - "Systematische Identifikation und Adressierung von Governance-Lücken: Dokumentation fehlender Regelungen, strukturierte Eskalation über definierte Wege, Nachverfolgung bis zur Schließung der Lücke" - - warum: - - "Schaffung von Transparenz über die Kernabläufe, Abhängigkeiten und Schnittstellen im Amt" - - "Ermöglichung einer strategischen Steuerung und Priorisierung von bereichsübergreifenden Prozessinitiativen (durch das Vision Board)" - - "Sicherstellung der Konsistenz und Qualität der Prozessarbeit sowie Einhaltung von Compliance-Vorgaben" - - "Vermeidung von Silos und unkoordinierten Insellösungen" - - wie: - governance: - - "Nutzung des Prozess-Management-Werkzeugs zur Darstellung und Verwaltung der Prozessarchitektur" - - "Regelmäßige Qualitäts-Checks und Reviews zur Prüfung der Framework-Konformität" - - "Kontinuierlicher Austausch mit den Fachbereichen (u.a. über Key-User)" - - "Regelmäßiges Reporting an das Vision Board und relevante Gremien" - - frequenz: - - "Prozesslandkarten-Review: quartalsweise" - - "Qualitäts-Checks: monatlich" - - "Vision Board Reporting: quartalsweise" - - outputs: - - "Übergreifende Prozesslandkarte" - - "Governance-Reports" - - "Qualitäts-Berichte" - - # --------------------------------------------------------------------------- - # 3.3 VERANTWORTUNGSBEREICH 3 - # --------------------------------------------------------------------------- - bereich_3_beratung: - id: "VB3" - name: "Beratung und operative Prozessgestaltung (in definierten Fällen)" - - beschreibung: | - Methodische Unterstützung der Fachbereiche bei Prozessfragen sowie aktive Gestaltung - und Optimierung von Prozessen in spezifischen, strategisch relevanten oder komplexen - Situationen, wobei die Rolle klar als Berater und Befähiger verstanden wird. - - was: - - "Fachliche Beratung von Fachbereichen und Teams bei der Analyse, Neugestaltung und Optimierung ihrer Prozesse (methodische Fachexpertise bereitstellen)" - - "Bei Bedarf Moderation von Prozessworkshops bei bereichsübergreifenden oder komplexen Abläufen" - - "In ausgewählten Ausnahmefällen operative Unterstützung bei der Prozessaufnahme, -modellierung und -optimierung (bei strategisch bedeutsamen oder abteilungsübergreifenden Prozessen, bei Projekten mit großem Prozesseinfluss oder initial als 'Starthilfe')" - - warum: - - "Sicherstellung hoher methodischer Qualität bei der Lösung komplexer Prozessherausforderungen" - - "Unterstützung der Fachbereiche bei der Erreichung ihrer Ziele durch effektive Prozesse ('Enabling')" - - "Gezielter Einsatz zentraler Ressourcen auf die Prozesse mit dem größten Hebel oder der höchsten Komplexität" - - wie: - governance: - - "Durchführung von individuellen Beratungsgesprächen und Coachings für Prozessverantwortliche/-teams" - - "Planung und professionelle Moderation von Analyse- und Design-Workshops" - - "Anwendung geeigneter Prozessanalyse- und Optimierungstechniken" - - "Detaillierte Modellierung (Ist/Soll) gemäß Prozess-Framework bei Übernahme operativer Verantwortung" - - frequenz: - - "Beratungsgespräche: bei Bedarf" - - "Workshops: nach Vereinbarung" - - "Operative Unterstützung: in definierten Fällen" - - outputs: - - "Beratungsprotokolle" - - "Workshop-Ergebnisse" - - "Prozessmodelle (Ist/Soll)" - - "Optimierungsempfehlungen" - - # --------------------------------------------------------------------------- - # 3.4 VERANTWORTUNGSBEREICH 4 - # --------------------------------------------------------------------------- - bereich_4_befaehigung: - id: "VB4" - name: "Dezentrale Prozesskompetenz durch Befähigung und Aufbau Key-User-Konzept" - - beschreibung: | - Systematischer Aufbau und Pflege von Prozess-Management-Kompetenzen in den Fachbereichen, - insbesondere durch die Etablierung und Betreuung eines Key-User-Netzwerks, um die - Prozessarbeit nachhaltig in der Organisation zu verankern. - - was: - - "Entwicklung und Umsetzung eines übergreifenden Befähigungskonzepts für Prozess-Management" - - "Identifikation, Gewinnung und Qualifizierung von geeigneten Key-Usern für Prozesse in den Fachbereichen als dezentrale Prozess-Ansprechpartner" - - "Aufbau und Management eines Key-User-Netzwerks, das den regelmäßigen Erfahrungsaustausch fördert und die kontinuierliche Weiterbildung im Prozessmanagement sicherstellt" - - warum: - - "Stärkung der Eigenverantwortung der Fachbereiche für ihre Prozesse ('Hilfe zur Selbsthilfe')" - - "Sicherstellung der nachhaltigen Anwendung und Verbesserung von Prozessen im Tagesgeschäft" - - "Schaffung von Multiplikatoren für Prozessdenken und das Prozessmanagement-Framework in der gesamten Organisation" - - wie: - governance: - - "Konzeption und Durchführung von zielgruppenspezifischen Trainings und Workshops (Methoden, Tools)" - - "Definition der Rolle und Aufgaben von Key-Usern in Abstimmung mit den Fachbereichen" - - "Organisation von regelmäßigen Austauschformaten für Key-User (z.B. Community of Practice, Best-Practice-Sharing)" - - "Bereitstellung von Lernmaterialien, Leitfäden und Coaching für die Key-User" - - "Strategische Netzwerk-Entwicklung: Systematische Identifikation von Kompetenzlücken, gezielte Rekrutierung neuer Key-User" - - frequenz: - - "Key-User-Netzwerktreffen: monatlich" - - "Trainings: quartalsweise" - - "Coaching: bei Bedarf" - - outputs: - - "Befähigungskonzept" - - "Schulungsmaterialien und Leitfäden" - - "Key-User-Dokumentation" - - "Community-of-Practice-Protokolle" - - # --------------------------------------------------------------------------- - # 3.5 VERANTWORTUNGSBEREICH 5 - # --------------------------------------------------------------------------- - bereich_5_leistungssteuerung: - id: "VB5" - name: "Leistungserbringung strukturieren und steuern" - - beschreibung: | - Die Prozess-Management-Funktion erbringt ihre Leistungen in vier unterschiedlichen Modi, - die sich nach Komplexität, strategischer Bedeutung und Ressourcenbedarf unterscheiden. - Diese differenzierte Herangehensweise ermöglicht es, flexibel auf verschiedene - organisationale Bedarfe zu reagieren und gleichzeitig die verfügbaren Ressourcen - optimal einzusetzen. - - was: - - "Standard-Leistungen: Wiederkehrende Unterstützung für operative Prozessbedarfe wie Einzelberatungen, Prozess-Management-Framework-Schulungen oder methodische Kurzberatungen" - - "Projekt-Leistungen: Umfangreichere Prozess-Management-Unterstützung, die signifikante Ressourcen bindet (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)" - - "Strategische Leistungen: Initiativen zur Weiterentwicklung des gesamten DIGITOMs oder zur grundlegenden Transformation der Prozesslandschaft" - - "Krisen-Leistungen: Sofortige Unterstützung bei akuten Prozess-Störungen oder Compliance-Verstößen" - - warum: - - "Sicherstellung einer bedarfsgerechten und ressourceneffizienten Leistungserbringung durch klare Priorisierung" - - "Schaffung von Transparenz über verfügbare Prozess-Management-Services und deren Zugangswege" - - "Ermöglichung einer strategischen Kapazitätsplanung und vorausschauenden Ressourcenallokation" - - "Balance zwischen planbaren Aktivitäten und der notwendigen Flexibilität für ungeplante Bedarfe" - - wie: - governance: - - "Definition klarer Kriterien für die Zuordnung von Anfragen zu Leistungskategorien (Aufwand, Laufzeit, Komplexität, strategische Relevanz)" - - "Etablierung unterschiedlicher Beauftragungswege je nach Leistungstyp (von Ticketsystemen bis Gremienentscheidungen)" - - "Regelmäßige Überprüfung der Leistungsverteilung und Anpassung der Kapazitätsallokation" - - "Transparente Kommunikation der Leistungstypen und ihrer Zugangswege" - - frequenz: - - "Kapazitätsplanung: quartalsweise" - - "Leistungs-Review: monatlich" - - outputs: - - "Leistungskatalog" - - "Beauftragungsrichtlinien" - - "Kapazitätsberichte" - -# ============================================================================= -# 4. SCHNITTSTELLEN -# ============================================================================= - -schnittstellen: - beschreibung: "Input/Output und typische Abstimmungswege der Prozess-Management-Funktion" - - # --------------------------------------------------------------------------- - # 4.1 INPUTS - # --------------------------------------------------------------------------- - inputs: - beschreibung: "Was das Prozess-Management empfängt" - - quellen: - - von: "vision_board" - name: "Vision Board" - inhalt: | - - Strategische Leitlinien und Entscheidungen zur Ausgestaltung des DIGITOMs - - Aufträge zur Umsetzung beschlossener Änderungen - - Entscheidungen über Framework-Transformationen, strategische PM-Ausrichtung, Ressourcenrahmen - - - von: "mission_board" - name: "Mission Board" - inhalt: | - - Impulse und Prioritäten aus der strategischen bzw. taktischen Steuerung - - Entscheidungen bei Eskalationen von bereichsübergreifenden Prozesskonflikten - - Entscheidungen über Projekt-Leistungen, Prioritätskonflikte bei Ressourcenengpässen, Governance-Eskalationen - - - von: "ppm" - name: "Projekt-Portfolio-Management" - inhalt: | - - Informationen zu geplanten Projekten und priorisierten Initiativen, die prozessuale Änderungen erfordern oder bestehende Prozesse betreffen - - - von: "spm" - name: "Service-Portfolio-Management" - inhalt: | - - Anforderungen aus der Service-Entwicklung und dem Service-Betrieb, die neue Prozesse oder Anpassungen bestehender Prozesse nötig machen - - Feedback zur Anwendbarkeit/Vollständigkeit des Prozess-Management-Frameworks für Service-Prozesse - - Feedback zur Effektivität bestehender Prozessmodelle aus Service-Sicht - - Informationen zur Ausgestaltung des ITIL-Frameworks mit Bezug zum Prozess-Management-Framework - - - von: "shm" - name: "Stakeholder-Management" - inhalt: | - - Anforderungen von Stakeholdern (z.B. Kundenfeedback, gesetzliche/regulative Vorgaben), welche die internen Prozesse beeinflussen - - - von: "key_user" - name: "Key-User" - inhalt: | - - Bindeglied zwischen zentralem Prozess-Management-Team und Fachbereich - - Feedback zur Anwendbarkeit des Frameworks, spezifische Unterstützungsbedarfe, operative Prozessdetails - - Anforderungen, Detailfragen und Rückmeldungen aus ihrem Bereich - - - von: "fachbereiche" - name: "Fachbereiche / Teams" - inhalt: | - - Input in Form von Bedarfen (z.B. Wunsch nach Neugestaltung eines Prozesses, Hinweise auf ineffiziente Abläufe, spezifische Beratungsanfragen) - - Feedback zur bestehenden Prozessausführung - - - von: "it_architektur" - name: "IT-Architektur" - inhalt: | - - Technische Rahmenbedingungen - - Informationen über IT-Systemlandschaft - - Technische Standards - - # --------------------------------------------------------------------------- - # 4.2 OUTPUTS - # --------------------------------------------------------------------------- - outputs: - beschreibung: "Was das Prozess-Management weitergibt" - - ziele: - - an: "vision_board" - name: "Vision Board" - inhalt: | - - Konzepte und Vorschläge zur Weiterentwicklung des DIGITOMs (inkl. Begründungen und Auswirkungen) - - Regelmäßige Statusberichte zur Implementierung des DIGITOMs - - Meldung von grundsätzlichen Problemen oder Risiken in der Prozesslandschaft (Eskalation) - - - an: "mission_board" - name: "Mission Board" - inhalt: | - - Berichte über operative Herausforderungen und bereichsübergreifende Prozess-Themen, die strategische Entscheidungen erfordern - - Empfehlungen für taktische Maßnahmen zur Prozessanpassung - - - an: "ppm" - name: "Projekt-Portfolio-Management" - inhalt: | - - Vorgaben und Richtlinien, wie Projekte im Rahmen des DIGITOM ablaufen sollen (z.B. definierte Prozessschritte, Decision Gates) - - Bewertung der Machbarkeit geplanter Projekte aus (organisations-)prozessualer Sicht - - - an: "spm" - name: "Service-Portfolio-Management" - inhalt: | - - Bei Bedarf Unterstützung bei der Gestaltung von servicebezogenen Prozessen (z.B. Einführung neuer Services) - - Unterstützung bei der Standardisierung/Dokumentation von Service-Prozessen - - - an: "shm" - name: "Stakeholder-Management" - inhalt: | - - Definierte Prozesse und Verantwortlichkeiten für den Umgang mit externen Stakeholdern - - Rückmeldung, wie externe Anforderungen im DIGITOM berücksichtigt wurden - - - an: "fachbereiche" - name: "Fachbereiche / Abteilungen" - inhalt: | - - Schulungsmaterial, Handbücher und Leitfäden zum DIGITOM - - Individuelle Beratung und Lösungen für gemeldete Prozessprobleme - - Methodische Unterstützung und Empfehlungen zur Prozessgestaltung und Dokumentation - - Informationen über anstehende Prozessänderungen - - - an: "key_user" - name: "Key-User" - inhalt: | - - Weitergabe der vom Prozess-Management entwickelten Lösungen, Standards und Guidelines in ihre Teams - - Unterstützung der jeweiligen Abteilungen oder Teams bei der Prozessanwendung - - # --------------------------------------------------------------------------- - # 4.3 TYPISCHE ABSTIMMUNGSWEGE - # --------------------------------------------------------------------------- - typische_abstimmungswege: - beschreibung: "Standardisierte Interaktionsformate" - - formate: - - format: "vision_board_reporting" - name: "Vision Board (Regel-Reporting)" - frequenz: "quartalsweise" - inhalt: - - "Status Prozesslandschaft & Framework-Compliance" - - "Strategische Abstimmung" - - "Eskalationen" - - "Grundsatzentscheidungen" - - - format: "mission_board" - name: "Mission Board (bei Bedarf)" - frequenz: "bei Bedarf" - inhalt: - - "Abstimmung bereichsübergreifender Prozessfragen" - - "Entscheidungen über Priorisierungen oder Ressourcenkonflikte" - - - format: "beratungsgespraech" - name: "Beratungsgespräch / Coaching (Fachbereich/Key-User)" - frequenz: "bei Bedarf" - inhalt: - - "Methodische Unterstützung bei Prozessfragen" - - "Anleitung zur Prozess-Framework-Anwendung" - - "Problemlösung" - - - format: "schulung_workshop" - name: "Schulung / Workshop (Key-User/Teams)" - frequenz: "quartalsweise / bei Bedarf" - inhalt: - - "Kompetenzaufbau (Methoden, Tools)" - - "Praktische Anwendung" - - "Befähigung zur dezentralen Prozessarbeit" - - - format: "key_user_netzwerk" - name: "Key-User-Netzwerktreffen / Community of Practice" - frequenz: "monatlich" - inhalt: - - "Erfahrungsaustausch" - - "Best-Practice-Sharing" - - "Feedback zum Framework" - - "Multiplikation von Wissen" - - - format: "projekt_meeting" - name: "Projekt-Meeting / Abstimmungsrunde" - frequenz: "projektabhängig" - inhalt: - - "Klärung Prozessauswirkungen von Projekten" - - "Sicherstellung Prozess-Management-Standards in Projekten" - - "Prozess-Integrationsplanung" - - - format: "architektur_board" - name: "Architektur-Board" - frequenz: "bei Bedarf" - inhalt: - - "Abgleich Prozessanforderungen mit technischer Machbarkeit" - - "Systemauswahl/-anpassung" - - - format: "ad_hoc_workshop" - name: "Ad-hoc-Workshops" - frequenz: "bei Bedarf" - inhalt: - - "Bei größeren Prozessänderungen oder neuen Initiativen" - - "Gemeinsame Erarbeitung von Lösungen" - - "Vorbereitung der Umsetzung" - - - format: "ad_hoc_abstimmung" - name: "Ad-hoc Abstimmung / Klärung" - frequenz: "bei Bedarf" - inhalt: - - "Lösung spezifischer, oft bereichsübergreifender Prozesskonflikte" - - "Prozess-Management-Framework-Interpretationsfragen" - - - format: "info_veranstaltung" - name: "Info-Veranstaltung / Intranet News" - frequenz: "bei Bedarf" - inhalt: - - "Breite Kommunikation von Prozess-Management-Framework-Updates" - - "Prozessänderungen" - - "Relevante Prozess-Management-Informationen" - - # --------------------------------------------------------------------------- - # 4.4 ESKALATIONSPROZESS - # --------------------------------------------------------------------------- - eskalationsprozess: - beschreibung: "3-stufiger Eskalationsprozess für Prozesskonflikte und Governance-Themen" - - stufen: - - stufe: 1 - name: "Intern" - zeitrahmen: "24-48 Stunden" - beschreibung: "Klärung innerhalb des Prozess-Management-Teams und mit den direkt Beteiligten" - - - stufe: 2 - name: "Mission Board" - zeitrahmen: "1-2 Wochen" - beschreibung: "Eskalation an das Mission Board für taktische Entscheidungen bei bereichsübergreifenden Konflikten" - - - stufe: 3 - name: "Vision Board" - zeitrahmen: "2-4 Wochen" - beschreibung: "Eskalation an das Vision Board für strategische Grundsatzentscheidungen" - -# ============================================================================= -# 5. ORGANISATORISCHE EINORDNUNG -# ============================================================================= - -organisatorische_einordnung: - - abteilung: "DIGIT (Amt für Digitalisierung und IT)" - berichtslinie: "Vision Board (strategisch) / Mission Board (taktisch)" - - designentscheidungen: - - id: "D-PM-01" - entscheidung: | - Prozess-Management als zentrale, befähigende Funktion statt als Kontrollinstanz - begruendung: | - Fördert Eigenverantwortung der Fachbereiche und schafft Vertrauen. - Prozess-Management unterstützt, kontrolliert aber nicht. - - - id: "D-PM-02" - entscheidung: | - Differenzierte Leistungserbringung nach vier Kategorien - begruendung: | - Ermöglicht bedarfsgerechte Ressourcensteuerung und klare Erwartungen. - Balance zwischen planbaren und ungeplanten Aktivitäten. - - - id: "D-PM-03" - entscheidung: | - Key-User-Netzwerk als dezentrale Prozess-Kompetenz - begruendung: | - Nachhaltige Verankerung von Prozesswissen in der Organisation. - Multiplikatoren-Effekt für Prozessdenken. - - rollen_in_funktion: - - rolle: "Prozess-Manager" - typ: "Einzelrolle" - beschreibung: | - Verantwortlich für das Prozess-Management-Framework und die Prozesslandschaft. - Koordiniert Beratung, Befähigung und Leistungserbringung. - referenz: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml" - - - rolle: "Key-User (Prozesse)" - typ: "Mehrfachrolle" - beschreibung: | - Dezentrale Prozess-Ansprechpartner in den Fachbereichen. - Bindeglied zwischen zentralem PM und Fachbereich. - referenz: "#05_prozessmanagement/#05.4_rollen/rolle_key-user-prozesse.yaml" - - vertretung: - regel: | - Die Vertretung des Prozess-Managers wird im Governance-Modell geregelt. - Key-User vertreten sich innerhalb ihres Fachbereichs gegenseitig. - -# ============================================================================= -# 6. OFFENE PUNKTE -# ============================================================================= - -offene_punkte: - - fuer_mvp_nicht_adressiert: - - - id: "OPEN-PM-001" - thema: "Detail-Definition Key-User-Rolle" - beschreibung: | - Genaue Aufgaben, Kompetenzen und Zeitbudget der Key-User-Rolle - müssen noch mit den Fachbereichen abgestimmt werden. - status: "Bei Bedarf zu klären" - prioritaet: "mittel" - - - id: "OPEN-PM-002" - thema: "Tool-Auswahl Prozess-Management" - beschreibung: | - Auswahl und Einführung eines zentralen Prozess-Management-Werkzeugs - steht noch aus. - status: "Post-MVP-Erweiterung" - prioritaet: "hoch" - - - id: "OPEN-PM-003" - thema: "Integration PPM-Schnittstelle" - beschreibung: | - Die Schnittstelle zu Projekt-Portfolio-Management muss noch - detailliert ausgearbeitet werden. - status: "Post-MVP-Erweiterung" - prioritaet: "mittel" - -# ============================================================================= -# 7. REFERENZEN -# ============================================================================= - -referenzen: - - verwandte_dokumente: - - titel: "Rollenbeschreibung Prozess-Manager" - pfad: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml" - unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch" - - - titel: "Governance-Framework PM" - pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" - relevanz: "Übergeordneter Governance-Rahmen für PM-Funktion" - - - titel: "RACI-Matrix PM" - pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" - relevanz: "Detaillierte Verantwortlichkeiten" - - - titel: "Leistungs-Canvas PM" - pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" - relevanz: "Practices und Leistungsportfolio" - - - titel: "DIGITOM Taxonomie" - pfad: "#00_meta/digitom_taxonomie.yaml" - relevanz: "Konzeptuelle Grundlagen (Funktion, Practice, Rolle, Gremium)" - - - titel: "DPM-Funktionsbeschreibung" - pfad: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml" - relevanz: "Parallele Portfolio-Funktion, Strukturvorlage" - - - titel: "SPM-Funktionsbeschreibung" - pfad: "#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml" - relevanz: "Parallele Portfolio-Funktion" - - - titel: "SHM-Funktionsbeschreibung" - pfad: "#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml" - relevanz: "Parallele Management-Funktion" - -# ============================================================================= -# 8. ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - - Quelle: #02 - Prozess-Management: Funktionsbeschreibung.docx - - Inhalte: - - Zweck und Hauptziel - - Funktionsverständnis und Abgrenzung - - 5 Verantwortungsbereiche (VB1-VB5) - - Schnittstellen (Inputs/Outputs) - - Typische Abstimmungswege - - Eskalationsprozess (3-stufig) - - Organisatorische Einordnung - - Strukturvorlage: spm_funktionsbeschreibung.yaml - autor: "DIGITOM-Projekt" +# ============================================================================= +# FUNKTIONSBESCHREIBUNG: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "funktionsbeschreibung" + funktion_id: "pm" + funktion_name: "Prozess-Management" + aliases: ["PM", "PZM", "Prozess-Funktion"] + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Governance" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied", "PM-Leitung"] + status: "draft" + + kontext_tags: + - "prozess-management" + - "funktion" + - "prozess-governance" + - "prozess-optimierung" + - "befaehigung" + - "key-user" + + quellen: + - "#02 - Prozess-Management: Funktionsbeschreibung.docx" + + taxonomie_referenz: "#00_meta/digitom_taxonomie.yaml" + +# ============================================================================= +# ABKÜRZUNGSVERZEICHNIS +# ============================================================================= + +abkuerzungen: + pm: "Prozess-Management" + pzm: "Prozess-Management (alternative Abkürzung)" + dpm: "Demand-Portfolio-Management" + spm: "Service-Portfolio-Management" + shm: "Stakeholder-Management" + ppm: "Projekt-Portfolio-Management" + mb: "Mission Board" + vb: "Vision Board" + digitom: "Digital Target Operating Model" + +# ============================================================================= +# 1. ZWECK +# ============================================================================= + +zweck: + wozu_existiert_diese_funktion: + kurz: | + Das Prozess-Management gestaltet aktiv die Art und Weise, wie das DIGIT arbeitet. + Als unterstützende und befähigende Einheit etabliert und verantwortet es den + verbindlichen methodischen Rahmen für alle übergreifenden (Organisations-)Prozesse (DIGITOM). + + ausfuehrlich: | + Das Prozess-Management agiert im Auftrag des Vision Board (strategisches Führungsgremium) + und dient internen Kunden - den Fachbereichen/Abteilungen und ihren Key Usern sowie + den Projektteams - indem es methodische Standards, Werkzeuge und Beratung bereitstellt, + damit diese ihre Prozesse eigenständig managen und verbessern können. + + Ziel ist es, durch klare Strukturen, einheitliche Standards und gezielte Befähigung + eine solide Grundlage für Effektivität, Transparenz und kontinuierliche Verbesserung + im gesamten Amt zu schaffen. + + Dadurch unterstützt das Prozess-Management die erfolgreiche Umsetzung der Digitalstrategie + und schafft Arbeitsabläufe, die gut funktionieren und sich flexibel an neue Anforderungen + anpassen lassen. + + wertbeitrag: + - "Einheitliche, vergleichbare und nachvollziehbare Prozessdokumentation im Amt" + - "Methodische Qualität und Effektivität in der Prozessgestaltung und -optimierung" + - "Gemeinsame 'Prozess-Sprache' und Verständnis über Abteilungsgrenzen hinweg" + - "Befähigung der Organisation zur eigenverantwortlichen Prozesssteuerung" + - "Flexibel anpassbare Arbeitsabläufe für neue Anforderungen" + + kritisches_merkmal: | + Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation. + Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung + zu ersetzen. Die Verantwortung bleibt, wo sie hingehört - bei den Fachbereichen. + + hauptziel: + beschreibung: | + Nachhaltig wirksame und anpassungsfähige Prozesse in der Organisation zu verankern. + + erreicht_durch: + - id: "Z1" + aktivitaet: "Prozesslandschaft schaffen und pflegen" + beschreibung: | + Eine konsistente, transparente und an der Strategie ausgerichtete Prozesslandschaft + schaffen und pflegen, die Silos überwindet. + umfasst: + - "Erhebung und Visualisierung der Prozesslandkarte" + - "Laufende Pflege und Aktualisierung" + - "Strategische Ausrichtung sicherstellen" + + - id: "Z2" + aktivitaet: "Organisation befähigen" + beschreibung: | + Die Organisation durch gezielte Beratung, Coaching und Schulung befähigen, + ihre Prozesse innerhalb des Rahmens eigenverantwortlich zu steuern und zu optimieren. + umfasst: + - "Beratung und Coaching von Prozessverantwortlichen" + - "Schulungen und Workshops durchführen" + - "Key-User-Netzwerk aufbauen und betreuen" + + - id: "Z3" + aktivitaet: "Prozess-Governance überwachen" + beschreibung: | + Die Einhaltung der Prozess-Governance (Standards, Methoden, Dokumentation) als Grundlage + für Qualität, Nachvollziehbarkeit und Verlässlichkeit überwachen und unterstützen. + umfasst: + - "Qualitäts-Checks und Reviews durchführen" + - "Framework-Konformität prüfen" + - "Governance-Lücken identifizieren und adressieren" + + - id: "Z4" + aktivitaet: "DIGITOM weiterentwickeln" + beschreibung: | + Die kontinuierliche Weiterentwicklung und Anpassung des DIGITOMs als lebendiges + Organisationsmodell vorantreiben, um auf veränderte Anforderungen und gewonnene + Erkenntnisse reagieren zu können. + umfasst: + - "Analyse interner Bedarfe und externer Best Practices" + - "Konzepte zur Weiterentwicklung erarbeiten" + - "Änderungen umsetzen und kommunizieren" + +# ============================================================================= +# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG +# ============================================================================= + +funktionsverstaendnis: + charakterisierung: + typ: "Unterstützende und befähigende Funktion" + + beschreibung: | + Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation. + Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung + zu ersetzen. Dies beinhaltet eine klare Rollenverteilung zwischen Linienorganisation + und Prozessmanagement. + + grundprinzipien: + + prinzip_1: + name: "Die Verantwortung bleibt, wo sie hingehört" + beschreibung: | + Die Fachbereiche/Abteilungen sind fachlich und operativ für die Ausführung und Ergebnisse + ihrer Prozesse verantwortlich. Sie liefern die Prozessinhalte und gewährleisten funktionierende + Abläufe im Tagesgeschäft. Hierfür werden in der Regel Prozessverantwortliche - wie Key User + oder Process Owner - als erste Ansprechpartner benannt. + + Das zentrale Prozess-Management verantwortet Rahmen und Methodik der Prozessarbeit, gibt + Standards vor, überblickt die Prozesslandschaft und berät Prozessverantwortliche. Es greift + nicht in die Liniensteuerung ein, sondern beeinflusst durch Expertise, Governance und + Koordination. Entscheidungen werden bei Bedarf über Gremien initiiert. + auswirkung: | + Klare Trennung zwischen operativer Prozessverantwortung (Fachbereich) und + methodischer Prozessverantwortung (PM). Eigenverantwortung der Fachbereiche bleibt erhalten. + referenz: "#02 - Funktionsbeschreibung.docx" + + prinzip_2: + name: "Partnerschaft statt Kontrolle" + beschreibung: | + Prozess-Management agiert als proaktiver Partner der Fachbereiche/Abteilungen und schafft + einen verbindlichen Ordnungsrahmen. Bei signifikanten Abweichungen von Standards oder + Governance-Lücken greift es unterstützend ein. + auswirkung: | + Fördert Vertrauen: Fachbereiche erhalten Unterstützung zur Selbsthilfe, während das + Management die Einhaltung der Standards und der Gesamtzusammenhänge gewährleistet sieht. + referenz: "#02 - Funktionsbeschreibung.docx" + + prinzip_3: + name: "Strukturierte Leistungserbringung" + beschreibung: | + Das Prozess-Management differenziert seine Unterstützung nach vier Leistungskategorien, + die unterschiedlichen Beauftragungswegen und Priorisierungslogiken folgen. + auswirkung: | + Bedarfsgerechte Ressourcensteuerung und klare Erwartungen auf allen Seiten. + referenz: "#02 - Funktionsbeschreibung.docx" + + leistungskategorien: + - kategorie: "Standard-Leistungen" + beschreibung: "Wiederkehrende Unterstützung für operative Prozessbedarfe (Beratung, Workshops, Schulungen)" + beauftragung: "Niedrigschwellig, etablierte Muster" + + - kategorie: "Projekt-Leistungen" + beschreibung: "Ressourcenintensive Vorhaben mit mehrwöchiger Laufzeit (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)" + beauftragung: "Formale Beauftragung durch Mission Board" + + - kategorie: "Strategische Leistungen" + beschreibung: "Weiterentwicklung des DIGITOMs, grundlegende Transformation der Prozesslandschaft" + beauftragung: "Beauftragung durch Vision Board" + + - kategorie: "Krisen-Leistungen" + beschreibung: "Akute Prozessstörungen oder Compliance-Verstöße mit sofortigem Handlungsbedarf" + beauftragung: "Sofortige Priorisierung, andere Aktivitäten werden zurückgestellt" + + abgrenzung_zu_angrenzenden_funktionen: + + - funktion: "dpm" + name: "Demand-Portfolio-Management" + dpm_tut: | + Steuert und priorisiert Demands über den gesamten Lifecycle. + Managt das Demand-Portfolio und koordiniert die Umsetzung. + pm_tut: | + Definiert den methodischen Rahmen für Prozesse, die Demands auslösen können. + Unterstützt bei Prozessänderungen, die aus Demands resultieren. + schnittstelle: | + Demands können Prozess-Änderungen sein. PM unterstützt DPM bei der Bewertung + prozessualer Auswirkungen von Demands. + + - funktion: "spm" + name: "Service-Portfolio-Management" + spm_tut: | + Steuert das Service-Portfolio, verantwortet Service-Lifecycle und Service-Level. + Managt servicebezogene Prozesse nach ITIL-Framework. + pm_tut: | + Stellt methodischen Rahmen für die Dokumentation von Service-Prozessen bereit. + Unterstützt bei der Gestaltung und Standardisierung von Service-Prozessen. + schnittstelle: | + Services basieren auf Prozessen. PM liefert Methodik und Framework, + SPM wendet diese auf Service-Prozesse an. Gegenseitiges Feedback zur + Anwendbarkeit des Frameworks. + + - funktion: "shm" + name: "Stakeholder-Management" + shm_tut: | + Identifiziert und managt Stakeholder-Beziehungen. + Erfasst Stakeholder-Anforderungen und -Feedback. + pm_tut: | + Definiert Prozesse für den Umgang mit externen Stakeholdern. + Berücksichtigt Stakeholder-Anforderungen in der Prozessgestaltung. + schnittstelle: | + Stakeholder haben Prozess-Anforderungen. PM erhält von SHM Anforderungen + (z.B. Kundenfeedback, regulative Vorgaben), die Prozesse beeinflussen. + + - funktion: "ppm" + name: "Projekt-Portfolio-Management" + ppm_tut: | + Plant und priorisiert Projekte. + Steuert das Projekt-Portfolio. + pm_tut: | + Definiert Vorgaben, wie Projekte im Rahmen des DIGITOM ablaufen sollen. + Bewertet Machbarkeit von Projekten aus prozessualer Sicht. + schnittstelle: | + Projekte können Prozess-Änderungen erfordern. PM erhält Informationen zu + geplanten Projekten und deren Prozessauswirkungen. + +# ============================================================================= +# 3. VERANTWORTUNGSBEREICHE +# ============================================================================= + +verantwortungsbereiche: + + beschreibung: | + Das Prozess-Management gliedert sich in fünf Kernverantwortungsbereiche, + die das Spektrum von der Framework-Definition über das Prozesslandschafts-Management + bis zur Befähigung und Leistungssteuerung abdecken. + + # --------------------------------------------------------------------------- + # 3.1 VERANTWORTUNGSBEREICH 1 + # --------------------------------------------------------------------------- + bereich_1_framework: + id: "VB1" + name: "Prozess-Management-Framework definieren und weiterentwickeln" + + beschreibung: | + Definition, Kommunikation und Weiterentwicklung der verbindlichen methodischen + und technischen Grundlagen für das gesamte Prozess-Management im DIGIT als + Fundament für einheitliche und qualitativ hochwertige Prozessarbeit. + + was: + - "Etablierung eines einheitlichen Prozess-Management-Frameworks: Gemeinsame verbindliche Standards und Methoden für die Darstellung, Dokumentation und Steuerung von Prozessen" + - "Festlegung von Governance-Regeln und Richtlinien für alle Aspekte der Prozessarbeit (von der Dokumentation über die Analyse bis zur Steuerung)" + - "Auswahl, Bereitstellung und laufende Betreuung zentraler Prozess-Management-Werkzeuge" + + warum: + - "Sicherstellung einer einheitlichen, vergleichbaren und nachvollziehbaren Prozessdokumentation im Amt" + - "Gewährleistung von methodischer Qualität, Effektivität und fundierter Erhebung in der Prozessgestaltung und -optimierung" + - "Schaffung einer gemeinsamen 'Prozess-Sprache' und eines gemeinsamen Verständnisses für Prozessarbeit über Abteilungsgrenzen hinweg" + + wie: + governance: + - "Laufende Analyse von internen Bedarfen und externen Best Practices/Standards im Prozess-Management" + - "Abstimmung der Anforderungen mit Fachbereichen, IT-Architektur und übergreifenden Governance-Vorgaben" + - "Klare Dokumentation des Prozess-Management-Frameworks (z.B. Methodenhandbuch oder Playbook)" + + frequenz: + - "Framework-Reviews: quartalsweise" + - "Tool-Updates: bei Bedarf" + - "Schulungen: laufend" + + outputs: + - "Prozess-Management-Framework (Methodenhandbuch/Playbook)" + - "Governance-Regeln und Richtlinien" + - "Tool-Dokumentation und Anleitungen" + + # --------------------------------------------------------------------------- + # 3.2 VERANTWORTUNGSBEREICH 2 + # --------------------------------------------------------------------------- + bereich_2_prozesslandschaft: + id: "VB2" + name: "Übergreifende Prozesslandschaft managen und Governance sicherstellen" + + beschreibung: | + Aufbau, Pflege und Überwachung der Gesamtarchitektur der bereichsübergreifenden + Prozesse (Kern-, Management- und Supportprozesse) des DIGIT zur Schaffung von + Transparenz, zur Steuerung und zur Sicherstellung der Einhaltung des definierten Rahmens. + + was: + - "Erhebung, Visualisierung und laufende Pflege der übergreifenden Prozesslandkarte des DIGIT" + - "Überwachung der Einhaltung des Prozess-Management-Frameworks (Methoden, Standards, Dokumentationsqualität)" + - "Systematische Identifikation und Adressierung von Governance-Lücken: Dokumentation fehlender Regelungen, strukturierte Eskalation über definierte Wege, Nachverfolgung bis zur Schließung der Lücke" + + warum: + - "Schaffung von Transparenz über die Kernabläufe, Abhängigkeiten und Schnittstellen im Amt" + - "Ermöglichung einer strategischen Steuerung und Priorisierung von bereichsübergreifenden Prozessinitiativen (durch das Vision Board)" + - "Sicherstellung der Konsistenz und Qualität der Prozessarbeit sowie Einhaltung von Compliance-Vorgaben" + - "Vermeidung von Silos und unkoordinierten Insellösungen" + + wie: + governance: + - "Nutzung des Prozess-Management-Werkzeugs zur Darstellung und Verwaltung der Prozessarchitektur" + - "Regelmäßige Qualitäts-Checks und Reviews zur Prüfung der Framework-Konformität" + - "Kontinuierlicher Austausch mit den Fachbereichen (u.a. über Key-User)" + - "Regelmäßiges Reporting an das Vision Board und relevante Gremien" + + frequenz: + - "Prozesslandkarten-Review: quartalsweise" + - "Qualitäts-Checks: monatlich" + - "Vision Board Reporting: quartalsweise" + + outputs: + - "Übergreifende Prozesslandkarte" + - "Governance-Reports" + - "Qualitäts-Berichte" + + # --------------------------------------------------------------------------- + # 3.3 VERANTWORTUNGSBEREICH 3 + # --------------------------------------------------------------------------- + bereich_3_beratung: + id: "VB3" + name: "Beratung und operative Prozessgestaltung (in definierten Fällen)" + + beschreibung: | + Methodische Unterstützung der Fachbereiche bei Prozessfragen sowie aktive Gestaltung + und Optimierung von Prozessen in spezifischen, strategisch relevanten oder komplexen + Situationen, wobei die Rolle klar als Berater und Befähiger verstanden wird. + + was: + - "Fachliche Beratung von Fachbereichen und Teams bei der Analyse, Neugestaltung und Optimierung ihrer Prozesse (methodische Fachexpertise bereitstellen)" + - "Bei Bedarf Moderation von Prozessworkshops bei bereichsübergreifenden oder komplexen Abläufen" + - "In ausgewählten Ausnahmefällen operative Unterstützung bei der Prozessaufnahme, -modellierung und -optimierung (bei strategisch bedeutsamen oder abteilungsübergreifenden Prozessen, bei Projekten mit großem Prozesseinfluss oder initial als 'Starthilfe')" + + warum: + - "Sicherstellung hoher methodischer Qualität bei der Lösung komplexer Prozessherausforderungen" + - "Unterstützung der Fachbereiche bei der Erreichung ihrer Ziele durch effektive Prozesse ('Enabling')" + - "Gezielter Einsatz zentraler Ressourcen auf die Prozesse mit dem größten Hebel oder der höchsten Komplexität" + + wie: + governance: + - "Durchführung von individuellen Beratungsgesprächen und Coachings für Prozessverantwortliche/-teams" + - "Planung und professionelle Moderation von Analyse- und Design-Workshops" + - "Anwendung geeigneter Prozessanalyse- und Optimierungstechniken" + - "Detaillierte Modellierung (Ist/Soll) gemäß Prozess-Framework bei Übernahme operativer Verantwortung" + + frequenz: + - "Beratungsgespräche: bei Bedarf" + - "Workshops: nach Vereinbarung" + - "Operative Unterstützung: in definierten Fällen" + + outputs: + - "Beratungsprotokolle" + - "Workshop-Ergebnisse" + - "Prozessmodelle (Ist/Soll)" + - "Optimierungsempfehlungen" + + # --------------------------------------------------------------------------- + # 3.4 VERANTWORTUNGSBEREICH 4 + # --------------------------------------------------------------------------- + bereich_4_befaehigung: + id: "VB4" + name: "Dezentrale Prozesskompetenz durch Befähigung und Aufbau Key-User-Konzept" + + beschreibung: | + Systematischer Aufbau und Pflege von Prozess-Management-Kompetenzen in den Fachbereichen, + insbesondere durch die Etablierung und Betreuung eines Key-User-Netzwerks, um die + Prozessarbeit nachhaltig in der Organisation zu verankern. + + was: + - "Entwicklung und Umsetzung eines übergreifenden Befähigungskonzepts für Prozess-Management" + - "Identifikation, Gewinnung und Qualifizierung von geeigneten Key-Usern für Prozesse in den Fachbereichen als dezentrale Prozess-Ansprechpartner" + - "Aufbau und Management eines Key-User-Netzwerks, das den regelmäßigen Erfahrungsaustausch fördert und die kontinuierliche Weiterbildung im Prozessmanagement sicherstellt" + + warum: + - "Stärkung der Eigenverantwortung der Fachbereiche für ihre Prozesse ('Hilfe zur Selbsthilfe')" + - "Sicherstellung der nachhaltigen Anwendung und Verbesserung von Prozessen im Tagesgeschäft" + - "Schaffung von Multiplikatoren für Prozessdenken und das Prozessmanagement-Framework in der gesamten Organisation" + + wie: + governance: + - "Konzeption und Durchführung von zielgruppenspezifischen Trainings und Workshops (Methoden, Tools)" + - "Definition der Rolle und Aufgaben von Key-Usern in Abstimmung mit den Fachbereichen" + - "Organisation von regelmäßigen Austauschformaten für Key-User (z.B. Community of Practice, Best-Practice-Sharing)" + - "Bereitstellung von Lernmaterialien, Leitfäden und Coaching für die Key-User" + - "Strategische Netzwerk-Entwicklung: Systematische Identifikation von Kompetenzlücken, gezielte Rekrutierung neuer Key-User" + + frequenz: + - "Key-User-Netzwerktreffen: monatlich" + - "Trainings: quartalsweise" + - "Coaching: bei Bedarf" + + outputs: + - "Befähigungskonzept" + - "Schulungsmaterialien und Leitfäden" + - "Key-User-Dokumentation" + - "Community-of-Practice-Protokolle" + + # --------------------------------------------------------------------------- + # 3.5 VERANTWORTUNGSBEREICH 5 + # --------------------------------------------------------------------------- + bereich_5_leistungssteuerung: + id: "VB5" + name: "Leistungserbringung strukturieren und steuern" + + beschreibung: | + Die Prozess-Management-Funktion erbringt ihre Leistungen in vier unterschiedlichen Modi, + die sich nach Komplexität, strategischer Bedeutung und Ressourcenbedarf unterscheiden. + Diese differenzierte Herangehensweise ermöglicht es, flexibel auf verschiedene + organisationale Bedarfe zu reagieren und gleichzeitig die verfügbaren Ressourcen + optimal einzusetzen. + + was: + - "Standard-Leistungen: Wiederkehrende Unterstützung für operative Prozessbedarfe wie Einzelberatungen, Prozess-Management-Framework-Schulungen oder methodische Kurzberatungen" + - "Projekt-Leistungen: Umfangreichere Prozess-Management-Unterstützung, die signifikante Ressourcen bindet (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)" + - "Strategische Leistungen: Initiativen zur Weiterentwicklung des gesamten DIGITOMs oder zur grundlegenden Transformation der Prozesslandschaft" + - "Krisen-Leistungen: Sofortige Unterstützung bei akuten Prozess-Störungen oder Compliance-Verstößen" + + warum: + - "Sicherstellung einer bedarfsgerechten und ressourceneffizienten Leistungserbringung durch klare Priorisierung" + - "Schaffung von Transparenz über verfügbare Prozess-Management-Services und deren Zugangswege" + - "Ermöglichung einer strategischen Kapazitätsplanung und vorausschauenden Ressourcenallokation" + - "Balance zwischen planbaren Aktivitäten und der notwendigen Flexibilität für ungeplante Bedarfe" + + wie: + governance: + - "Definition klarer Kriterien für die Zuordnung von Anfragen zu Leistungskategorien (Aufwand, Laufzeit, Komplexität, strategische Relevanz)" + - "Etablierung unterschiedlicher Beauftragungswege je nach Leistungstyp (von Ticketsystemen bis Gremienentscheidungen)" + - "Regelmäßige Überprüfung der Leistungsverteilung und Anpassung der Kapazitätsallokation" + - "Transparente Kommunikation der Leistungstypen und ihrer Zugangswege" + + frequenz: + - "Kapazitätsplanung: quartalsweise" + - "Leistungs-Review: monatlich" + + outputs: + - "Leistungskatalog" + - "Beauftragungsrichtlinien" + - "Kapazitätsberichte" + +# ============================================================================= +# 4. SCHNITTSTELLEN +# ============================================================================= + +schnittstellen: + beschreibung: "Input/Output und typische Abstimmungswege der Prozess-Management-Funktion" + + # --------------------------------------------------------------------------- + # 4.1 INPUTS + # --------------------------------------------------------------------------- + inputs: + beschreibung: "Was das Prozess-Management empfängt" + + quellen: + - von: "vision_board" + name: "Vision Board" + inhalt: | + - Strategische Leitlinien und Entscheidungen zur Ausgestaltung des DIGITOMs + - Aufträge zur Umsetzung beschlossener Änderungen + - Entscheidungen über Framework-Transformationen, strategische PM-Ausrichtung, Ressourcenrahmen + + - von: "mission_board" + name: "Mission Board" + inhalt: | + - Impulse und Prioritäten aus der strategischen bzw. taktischen Steuerung + - Entscheidungen bei Eskalationen von bereichsübergreifenden Prozesskonflikten + - Entscheidungen über Projekt-Leistungen, Prioritätskonflikte bei Ressourcenengpässen, Governance-Eskalationen + + - von: "ppm" + name: "Projekt-Portfolio-Management" + inhalt: | + - Informationen zu geplanten Projekten und priorisierten Initiativen, die prozessuale Änderungen erfordern oder bestehende Prozesse betreffen + + - von: "spm" + name: "Service-Portfolio-Management" + inhalt: | + - Anforderungen aus der Service-Entwicklung und dem Service-Betrieb, die neue Prozesse oder Anpassungen bestehender Prozesse nötig machen + - Feedback zur Anwendbarkeit/Vollständigkeit des Prozess-Management-Frameworks für Service-Prozesse + - Feedback zur Effektivität bestehender Prozessmodelle aus Service-Sicht + - Informationen zur Ausgestaltung des ITIL-Frameworks mit Bezug zum Prozess-Management-Framework + + - von: "shm" + name: "Stakeholder-Management" + inhalt: | + - Anforderungen von Stakeholdern (z.B. Kundenfeedback, gesetzliche/regulative Vorgaben), welche die internen Prozesse beeinflussen + + - von: "key_user" + name: "Key-User" + inhalt: | + - Bindeglied zwischen zentralem Prozess-Management-Team und Fachbereich + - Feedback zur Anwendbarkeit des Frameworks, spezifische Unterstützungsbedarfe, operative Prozessdetails + - Anforderungen, Detailfragen und Rückmeldungen aus ihrem Bereich + + - von: "fachbereiche" + name: "Fachbereiche / Teams" + inhalt: | + - Input in Form von Bedarfen (z.B. Wunsch nach Neugestaltung eines Prozesses, Hinweise auf ineffiziente Abläufe, spezifische Beratungsanfragen) + - Feedback zur bestehenden Prozessausführung + + - von: "it_architektur" + name: "IT-Architektur" + inhalt: | + - Technische Rahmenbedingungen + - Informationen über IT-Systemlandschaft + - Technische Standards + + # --------------------------------------------------------------------------- + # 4.2 OUTPUTS + # --------------------------------------------------------------------------- + outputs: + beschreibung: "Was das Prozess-Management weitergibt" + + ziele: + - an: "vision_board" + name: "Vision Board" + inhalt: | + - Konzepte und Vorschläge zur Weiterentwicklung des DIGITOMs (inkl. Begründungen und Auswirkungen) + - Regelmäßige Statusberichte zur Implementierung des DIGITOMs + - Meldung von grundsätzlichen Problemen oder Risiken in der Prozesslandschaft (Eskalation) + + - an: "mission_board" + name: "Mission Board" + inhalt: | + - Berichte über operative Herausforderungen und bereichsübergreifende Prozess-Themen, die strategische Entscheidungen erfordern + - Empfehlungen für taktische Maßnahmen zur Prozessanpassung + + - an: "ppm" + name: "Projekt-Portfolio-Management" + inhalt: | + - Vorgaben und Richtlinien, wie Projekte im Rahmen des DIGITOM ablaufen sollen (z.B. definierte Prozessschritte, Decision Gates) + - Bewertung der Machbarkeit geplanter Projekte aus (organisations-)prozessualer Sicht + + - an: "spm" + name: "Service-Portfolio-Management" + inhalt: | + - Bei Bedarf Unterstützung bei der Gestaltung von servicebezogenen Prozessen (z.B. Einführung neuer Services) + - Unterstützung bei der Standardisierung/Dokumentation von Service-Prozessen + + - an: "shm" + name: "Stakeholder-Management" + inhalt: | + - Definierte Prozesse und Verantwortlichkeiten für den Umgang mit externen Stakeholdern + - Rückmeldung, wie externe Anforderungen im DIGITOM berücksichtigt wurden + + - an: "fachbereiche" + name: "Fachbereiche / Abteilungen" + inhalt: | + - Schulungsmaterial, Handbücher und Leitfäden zum DIGITOM + - Individuelle Beratung und Lösungen für gemeldete Prozessprobleme + - Methodische Unterstützung und Empfehlungen zur Prozessgestaltung und Dokumentation + - Informationen über anstehende Prozessänderungen + + - an: "key_user" + name: "Key-User" + inhalt: | + - Weitergabe der vom Prozess-Management entwickelten Lösungen, Standards und Guidelines in ihre Teams + - Unterstützung der jeweiligen Abteilungen oder Teams bei der Prozessanwendung + + # --------------------------------------------------------------------------- + # 4.3 TYPISCHE ABSTIMMUNGSWEGE + # --------------------------------------------------------------------------- + typische_abstimmungswege: + beschreibung: "Standardisierte Interaktionsformate" + + formate: + - format: "vision_board_reporting" + name: "Vision Board (Regel-Reporting)" + frequenz: "quartalsweise" + inhalt: + - "Status Prozesslandschaft & Framework-Compliance" + - "Strategische Abstimmung" + - "Eskalationen" + - "Grundsatzentscheidungen" + + - format: "mission_board" + name: "Mission Board (bei Bedarf)" + frequenz: "bei Bedarf" + inhalt: + - "Abstimmung bereichsübergreifender Prozessfragen" + - "Entscheidungen über Priorisierungen oder Ressourcenkonflikte" + + - format: "beratungsgespraech" + name: "Beratungsgespräch / Coaching (Fachbereich/Key-User)" + frequenz: "bei Bedarf" + inhalt: + - "Methodische Unterstützung bei Prozessfragen" + - "Anleitung zur Prozess-Framework-Anwendung" + - "Problemlösung" + + - format: "schulung_workshop" + name: "Schulung / Workshop (Key-User/Teams)" + frequenz: "quartalsweise / bei Bedarf" + inhalt: + - "Kompetenzaufbau (Methoden, Tools)" + - "Praktische Anwendung" + - "Befähigung zur dezentralen Prozessarbeit" + + - format: "key_user_netzwerk" + name: "Key-User-Netzwerktreffen / Community of Practice" + frequenz: "monatlich" + inhalt: + - "Erfahrungsaustausch" + - "Best-Practice-Sharing" + - "Feedback zum Framework" + - "Multiplikation von Wissen" + + - format: "projekt_meeting" + name: "Projekt-Meeting / Abstimmungsrunde" + frequenz: "projektabhängig" + inhalt: + - "Klärung Prozessauswirkungen von Projekten" + - "Sicherstellung Prozess-Management-Standards in Projekten" + - "Prozess-Integrationsplanung" + + - format: "architektur_board" + name: "Architektur-Board" + frequenz: "bei Bedarf" + inhalt: + - "Abgleich Prozessanforderungen mit technischer Machbarkeit" + - "Systemauswahl/-anpassung" + + - format: "ad_hoc_workshop" + name: "Ad-hoc-Workshops" + frequenz: "bei Bedarf" + inhalt: + - "Bei größeren Prozessänderungen oder neuen Initiativen" + - "Gemeinsame Erarbeitung von Lösungen" + - "Vorbereitung der Umsetzung" + + - format: "ad_hoc_abstimmung" + name: "Ad-hoc Abstimmung / Klärung" + frequenz: "bei Bedarf" + inhalt: + - "Lösung spezifischer, oft bereichsübergreifender Prozesskonflikte" + - "Prozess-Management-Framework-Interpretationsfragen" + + - format: "info_veranstaltung" + name: "Info-Veranstaltung / Intranet News" + frequenz: "bei Bedarf" + inhalt: + - "Breite Kommunikation von Prozess-Management-Framework-Updates" + - "Prozessänderungen" + - "Relevante Prozess-Management-Informationen" + + # --------------------------------------------------------------------------- + # 4.4 ESKALATIONSPROZESS + # --------------------------------------------------------------------------- + eskalationsprozess: + beschreibung: "3-stufiger Eskalationsprozess für Prozesskonflikte und Governance-Themen" + + stufen: + - stufe: 1 + name: "Intern" + zeitrahmen: "24-48 Stunden" + beschreibung: "Klärung innerhalb des Prozess-Management-Teams und mit den direkt Beteiligten" + + - stufe: 2 + name: "Mission Board" + zeitrahmen: "1-2 Wochen" + beschreibung: "Eskalation an das Mission Board für taktische Entscheidungen bei bereichsübergreifenden Konflikten" + + - stufe: 3 + name: "Vision Board" + zeitrahmen: "2-4 Wochen" + beschreibung: "Eskalation an das Vision Board für strategische Grundsatzentscheidungen" + +# ============================================================================= +# 5. ORGANISATORISCHE EINORDNUNG +# ============================================================================= + +organisatorische_einordnung: + + abteilung: "DIGIT (Amt für Digitalisierung und IT)" + berichtslinie: "Vision Board (strategisch) / Mission Board (taktisch)" + + designentscheidungen: + - id: "D-PM-01" + entscheidung: | + Prozess-Management als zentrale, befähigende Funktion statt als Kontrollinstanz + begruendung: | + Fördert Eigenverantwortung der Fachbereiche und schafft Vertrauen. + Prozess-Management unterstützt, kontrolliert aber nicht. + + - id: "D-PM-02" + entscheidung: | + Differenzierte Leistungserbringung nach vier Kategorien + begruendung: | + Ermöglicht bedarfsgerechte Ressourcensteuerung und klare Erwartungen. + Balance zwischen planbaren und ungeplanten Aktivitäten. + + - id: "D-PM-03" + entscheidung: | + Key-User-Netzwerk als dezentrale Prozess-Kompetenz + begruendung: | + Nachhaltige Verankerung von Prozesswissen in der Organisation. + Multiplikatoren-Effekt für Prozessdenken. + + rollen_in_funktion: + - rolle: "Prozess-Manager" + typ: "Einzelrolle" + beschreibung: | + Verantwortlich für das Prozess-Management-Framework und die Prozesslandschaft. + Koordiniert Beratung, Befähigung und Leistungserbringung. + referenz: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml" + + - rolle: "Key-User (Prozesse)" + typ: "Mehrfachrolle" + beschreibung: | + Dezentrale Prozess-Ansprechpartner in den Fachbereichen. + Bindeglied zwischen zentralem PM und Fachbereich. + referenz: "#05_prozessmanagement/#05.4_rollen/rolle_key-user-prozesse.yaml" + + vertretung: + regel: | + Die Vertretung des Prozess-Managers wird im Governance-Modell geregelt. + Key-User vertreten sich innerhalb ihres Fachbereichs gegenseitig. + +# ============================================================================= +# 6. OFFENE PUNKTE +# ============================================================================= + +offene_punkte: + + fuer_mvp_nicht_adressiert: + + - id: "OPEN-PM-001" + thema: "Detail-Definition Key-User-Rolle" + beschreibung: | + Genaue Aufgaben, Kompetenzen und Zeitbudget der Key-User-Rolle + müssen noch mit den Fachbereichen abgestimmt werden. + status: "Bei Bedarf zu klären" + prioritaet: "mittel" + + - id: "OPEN-PM-002" + thema: "Tool-Auswahl Prozess-Management" + beschreibung: | + Auswahl und Einführung eines zentralen Prozess-Management-Werkzeugs + steht noch aus. + status: "Post-MVP-Erweiterung" + prioritaet: "hoch" + + - id: "OPEN-PM-003" + thema: "Integration PPM-Schnittstelle" + beschreibung: | + Die Schnittstelle zu Projekt-Portfolio-Management muss noch + detailliert ausgearbeitet werden. + status: "Post-MVP-Erweiterung" + prioritaet: "mittel" + +# ============================================================================= +# 7. REFERENZEN +# ============================================================================= + +referenzen: + + verwandte_dokumente: + - titel: "Rollenbeschreibung Prozess-Manager" + pfad: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml" + unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch" + + - titel: "Governance-Framework PM" + pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" + relevanz: "Übergeordneter Governance-Rahmen für PM-Funktion" + + - titel: "RACI-Matrix PM" + pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" + relevanz: "Detaillierte Verantwortlichkeiten" + + - titel: "Leistungs-Canvas PM" + pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" + relevanz: "Practices und Leistungsportfolio" + + - titel: "DIGITOM Taxonomie" + pfad: "#00_meta/digitom_taxonomie.yaml" + relevanz: "Konzeptuelle Grundlagen (Funktion, Practice, Rolle, Gremium)" + + - titel: "DPM-Funktionsbeschreibung" + pfad: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml" + relevanz: "Parallele Portfolio-Funktion, Strukturvorlage" + + - titel: "SPM-Funktionsbeschreibung" + pfad: "#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml" + relevanz: "Parallele Portfolio-Funktion" + + - titel: "SHM-Funktionsbeschreibung" + pfad: "#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml" + relevanz: "Parallele Management-Funktion" + +# ============================================================================= +# 8. ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + + Quelle: #02 - Prozess-Management: Funktionsbeschreibung.docx + + Inhalte: + - Zweck und Hauptziel + - Funktionsverständnis und Abgrenzung + - 5 Verantwortungsbereiche (VB1-VB5) + - Schnittstellen (Inputs/Outputs) + - Typische Abstimmungswege + - Eskalationsprozess (3-stufig) + - Organisatorische Einordnung + + Strukturvorlage: spm_funktionsbeschreibung.yaml + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml b/#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml index f6a981d..26a2d27 100644 --- a/#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml +++ b/#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml @@ -1,528 +1,528 @@ -# ============================================================================= -# GOVERNANCE-FRAMEWORK: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "governance-framework" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Governance" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#05 - Prozess-Management: Governance-Modell.docx" - -# ============================================================================= -# 1. GOVERNANCE-PHILOSOPHIE UND GRUNDPRINZIPIEN -# ============================================================================= - -governance_philosophie: - kernaussage: | - Das Prozess-Management-Governance-Framework folgt dem Prinzip der - "Befähigungs-Governance" - es soll befähigen und unterstützen, nicht - kontrollieren und bremsen. Gleichzeitig muss es sich nahtlos in die - bestehende DIGITOM-Governance-Architektur integrieren. - - leitprinzipien: - - prinzip: "Subsidiarität" - beschreibung: | - Entscheidungen werden auf der niedrigstmöglichen Ebene getroffen, - die kompetent und legitimiert ist. Operative Prozess-Beratung braucht - keine Gremien-Freigabe, strategische Framework-Änderungen schon. - - - prinzip: "Proportionalität" - beschreibung: | - Der Governance-Aufwand muss dem Risiko und der Tragweite einer - Entscheidung angemessen sein. Eine Template-Anpassung braucht weniger - Governance als eine komplette Framework-Transformation. - - - prinzip: "Integration" - beschreibung: | - PM-Governance ergänzt die bestehende DIGITOM-Governance, ersetzt sie nicht. - Vision Board, Mission Board und DSR bleiben die primären Steuerungsgremien. - - - prinzip: "Transparenz" - beschreibung: | - Alle Governance-Entscheidungen und ihre Begründungen müssen nachvollziehbar - dokumentiert und kommuniziert werden. - -# ============================================================================= -# 2. INTERNE PM-GOVERNANCE -# ============================================================================= - -interne_governance: - - # --------------------------------------------------------------------------- - # 2.1 Framework-Änderungs-Governance - # --------------------------------------------------------------------------- - framework_aenderungen: - beschreibung: | - Die Governance für Framework-Änderungen folgt einem dreistufigen Modell, - das die Komplexität und Tragweite der Änderungen berücksichtigt. - - kategorie_a: - name: "Operative Anpassungen" - definition: | - Kleinere Verbesserungen, Klarstellungen oder Ergänzungen, - die die Framework-Grundlogik nicht verändern. - beispiele: - - "Template-Updates" - - "Methodenbeschreibungs-Präzisierungen" - - "Tool-Konfigurationsanpassungen" - - "FAQ-Ergänzungen" - entscheidungsweg: - - schritt: 1 - aktion: "Prozess-Framework-Manager*in trifft Entscheidung eigenständig nach fachlicher Prüfung und Dokumentation" - - schritt: 2 - aktion: "Prozess-Management-Team gibt formale Freigabe" - - schritt: 3 - aktion: "Leiter*in Prozess-Management wird zeitnah informiert" - - schritt: 4 - aktion: "Betroffene Process Owner und Key-User werden über reguläre Kommunikationskanäle benachrichtigt" - implementierung: - - "Kann sofort umgesetzt werden" - - "Änderungen werden im Framework-Changelog dokumentiert" - - kategorie_b: - name: "Taktische Erweiterungen" - definition: | - Bedeutendere Änderungen, die neue Elemente einführen oder bestehende erweitern, - aber die Framework-Architektur beibehalten. - beispiele: - - "Neue Prozess-Kategorien" - - "Zusätzliche PM-Governance-Elemente" - - "Erweiterte KPI-Systematiken" - - "Neue Qualifizierungsmodule" - entscheidungsweg: - - schritt: 1 - aktion: "Prozess-Framework-Manager*in entwickelt den Vorschlag" - - schritt: 2 - aktion: "Prozess-Management-Team gibt formale Freigabe" - - schritt: 3 - aktion: "Betroffene Process Owner werden konsultiert und können Einwände oder Verbesserungsvorschläge einbringen" - - schritt: 4 - aktion: "Mission Board wird über die Änderung informiert und kann Feedback geben" - implementierung: - - "Erfordert Vorlaufzeit für Stakeholder-Abstimmung und Kommunikation" - - "Implementierung erfolgt zu definierten Stichtagen für Planbarkeit" - - kategorie_c: - name: "Strategische Transformationen" - definition: | - Fundamentale Änderungen der Framework-Philosophie oder -Architektur, - die das Operating Model betreffen. - beispiele: - - "Wechsel der Grundmethodik" - - "Komplette Neudefinition der PM-Governance-Struktur" - - "Integration neuer strategischer Anforderungen" - entscheidungsweg: - - schritt: 1 - aktion: "Prozess-Framework-Manager*in erarbeitet Konzept mit Stakeholder-Analyse und Impact-Assessment" - - schritt: 2 - aktion: "Leiter*in Prozess-Management koordiniert umfassende Abstimmungsrunde mit allen betroffenen Bereichen" - - schritt: 3 - aktion: "Mission Board führt Vorbewertung durch und gibt Empfehlung ab" - - schritt: 4 - aktion: "Vision Board trifft finale Entscheidung nach Präsentation des Konzepts" - implementierung: - - "Erfordert längere Vorlaufzeit mit detailliertem Change Management-Plan" - - "Implementierung erfolgt als formales Transformationsprojekt mit entsprechendem Projektmanagement" - - # --------------------------------------------------------------------------- - # 2.2 Ressourcen- und Prioritäts-Governance - # --------------------------------------------------------------------------- - ressourcen_governance: - kapazitaetsallokation: - beschreibung: | - Die Leiter*in Prozess-Management verteilt die verfügbaren PM-Kapazitäten - nach folgender Prioritätslogik: - prioritaeten: - - prio: 1 - typ: "Strategische Leistungen mit Vision Board-Freigabe" - - prio: 2 - typ: "Projekt Leistungen mit Mission Board-Freigabe" - - prio: 3 - typ: "Compliance-kritische Standard Leistungen" - - prio: 4 - typ: "Geplante Standard Leistungen aus Jahresplanung" - - prio: 5 - typ: "Ad-hoc Standard Leistungen nach Verfügbarkeit" - - interne_koordination: - - format: "Wöchentliche PM-Team-Abstimmung" - inhalt: "Operative Koordination, Ressourcenplanung, Problem-Eskalation" - - format: "Monatliche Stakeholder-Runde" - inhalt: "Review mit Process Ownern, Feedback-Sammlung, Planungsabstimmung" - - format: "Regelmäßige Governance-Review" - inhalt: "Framework-Performance, Governance-Optimierung, strategische Ausrichtung" - -# ============================================================================= -# 3. LEISTUNGS-GOVERNANCE UND BEAUFTRAGUNG -# ============================================================================= - -leistungs_governance: - - # --------------------------------------------------------------------------- - # 3.1 Leistungskategorien - # --------------------------------------------------------------------------- - leistungskategorien: - - standard_leistungen: - definition: | - Wiederkehrende, standardisierte PM-Unterstützung für operative Bedarfe. - beispiele: - - "Prozess-Workshops in definierten Bereichen" - - "Einzelberatungen" - - "PM-Framework-Schulungen" - - "Prozess-Assessments" - - "Key-User-Support" - beauftragungsberechtigung: "Alle DIGITOM-Mitarbeitenden über Ticketsystem oder direkte Anfrage" - entscheidungsweg: - - "Anfragen werden von zuständiger PM-Rolle (meist Prozess-Berater*in) bewertet" - - "Bearbeitung nach Verfügbarkeit und Priorität" - - "Bei Ressourcenkonflikten entscheidet Leiter*in Prozess-Management" - - projekt_leistungen: - definition: | - Umfangreichere, projektähnliche PM-Unterstützung, die signifikante Ressourcen bindet. - beispiele: - - "Komplette Prozess-Neugestaltung" - - "PM-Tool-Einführung" - - "Bereichsspezifische PM-Framework-Entwicklung" - - "Umfassende Prozess-Transformationen" - abgrenzung: - quantitativ: - - "Leistung über 10 Beratungstage" - - "Laufzeit über 4 Wochen" - qualitativ: - - "Leistung mit mehreren Fachbereichen/Abteilungen" - - "Framework-Implikationen" - - "Strategische Relevanz" - beauftragungsberechtigung: "Fachbereichs-/Abteilungsleitungen, Projektleitungen, Gremien" - entscheidungsweg: - - "Antrag wird von Leiter*in PM formuliert und in Mission Board eingebracht" - - "Mission Board prüft strategische Passung, Ressourcen-Impact und Priorisierung" - - "Bei Freigabe wird Leistung als Projekt konfiguriert mit entsprechendem Projektmanagement" - - strategische_leistungen: - definition: | - Strategische PM-Initiativen, die das Operating Model weiterentwickeln oder transformieren. - beispiele: - - "Entwicklung neuer Governance-Strukturen" - - "Strategische Prozess-Digitalisierung" - - "Organisationsweite Methodeneinführung" - - "Integration in Transformationsprojekte" - beauftragungsberechtigung: - - "Vision Board (proaktiv)" - - "Mission Board/Leiter*in PM (als Vorschlag)" - entscheidungsweg: - - "Konzeptentwicklung durch PM-Team mit strategischer Stakeholder-Analyse" - - "Vision Board-Präsentation mit Ressourcen-Impact, Zeitplan und erwarteten Outcomes" - - "Bei Freigabe erfolgt Mandatierung als strategisches Projekt" - - krisen_leistungen: - definition: | - Dringende Prozess-Unterstützung bei akuten Problemen oder Krisen. - beispiele: - - "Compliance-Verstöße mit Prozess-Bezug" - - "Schwerwiegende Prozess-Störungen" - - "Akute Konfliktmediation" - beauftragungsberechtigung: - - "Jede Abteilungsleitung bei akuten Problemen" - - "Amtsleitung bei kritischen Situationen" - entscheidungsweg: - - "Sofortige Bewertung und Klassifizierung durch Leiter*in PM" - - "Ressourcen-Umschichtung nach Krisenlogik (andere Leistungen werden pausiert)" - - "Bildung eines Response-Teams aus relevanten PM-Rollen" - - "Nachträgliche Information an Mission Board" - - "Post-Crisis-Review zur Governance-Optimierung" - - # --------------------------------------------------------------------------- - # 3.2 Projektzentrierte Prozessgestaltung - # --------------------------------------------------------------------------- - projektzentrierte_prozessgestaltung: - beschreibung: "Spezial-PM-Governance für Projekte mit Prozess-Impact" - - obligatorische_compliance: - hinweis: "Jedes Projekt, das Prozesse neu gestaltet oder verändert, muss folgende PM-Elemente berücksichtigen:" - elemente: - - name: "Key-User-Integration" - beschreibung: "Key-User müssen konsultiert und in die Prozessgestaltung eingebunden werden" - - name: "PM-Framework-konforme Dokumentation" - beschreibung: "Neue Prozesse müssen nach PM-Standards dokumentiert werden" - - name: "Process Owner-Koordination" - beschreibung: "Bei Änderungen an bestehenden Prozessen muss der zuständige Process Owner konsultiert werden" - - name: "Standardnotation" - beschreibung: "Prozessmodellierung muss PM-Framework-konforme Notation verwenden" - - process_owner_abnahme: - name: "Process Owner-Abnahme als Quality Gate" - beschreibung: | - Bei allen Projekten, die Prozesse verändern, die einem Process Owner - zugeordnet sind, muss dieser formale Abnahme-Verantwortung übernehmen. - pruefbereiche: - - "Fachliche Korrektheit: End-to-End-Konsistenz des veränderten Prozesses" - - "Schnittstellen-Impact: Auswirkungen auf vor- und nachgelagerte Prozesse" - - "Implementierbarkeit: Praktische Umsetzbarkeit im operativen Betrieb" - veto_recht: - - "Process Owner hat finales Veto-Recht bei inhaltlichen Aspekten" - - "Bei Veto: Verpflichtende Mediation durch PM-Leitung" - - "Eskalation ans Mission Board nur bei unlösbaren Konflikten" - - "Dokumentationspflicht für Veto-Gründe" - - pm_qualitaetspruefung: - name: "PM-Qualitätsprüfung als methodisches Quality Gate" - beschreibung: | - Für alle Projekte mit Prozess-Impact führt die PM-Funktion eine formale - Qualitätsprüfung durch (vor Projektabschluss, Voraussetzung für finale Abnahme). - pruefbereiche: - - "PM-Framework-Compliance-Check: Einhaltung aller PM-Standards" - - "Cross-Process-Impact-Analysis: Bewertung möglicher Seiteneffekte auf andere Prozesse" - - "Tool-Kompatibilität: Integration in bestehende PM-Tools" - - "Dokumentations-Vollständigkeit: Vollständige und korrekte Dokumentation" - -# ============================================================================= -# 4. EXTERNE GOVERNANCE-INTEGRATION -# ============================================================================= - -externe_governance: - - # --------------------------------------------------------------------------- - # 4.1 Vision Board-Integration - # --------------------------------------------------------------------------- - vision_board: - pm_relevante_entscheidungen: - - "PM-Strategische Ausrichtung: Grundsätzliche Rolle und Positionierung der PM-Funktion in DIGITOM" - - "Framework-Transformationen: Freigabe strategischer Framework-Änderungen (Kategorie C)" - - "Strategische Leistungen: Beauftragung und Priorisierung strategischer PM-Initiativen" - - "PM-Ressourcen-Rahmen: Grundsätzliche Kapazitäts- und Budget-Entscheidungen für PM-Funktion" - - pm_input: - beschreibung: "Die Leiter*in PM liefert strategischen Input für Vision Board-Entscheidungen:" - inhalte: - - "Prozesslandschafts-Assessment: Jährliche Bewertung der Prozess-Reife und strategischen Prozess-Herausforderungen" - - "Framework-Entwicklungsvorschläge: Vorschläge für strategische Framework-Weiterentwicklungen" - - "Organisationsreife-Einschätzung: Assessment der PM-Kompetenz und Change-Bereitschaft in DIGITOM" - - # --------------------------------------------------------------------------- - # 4.2 Mission Board-Integration - # --------------------------------------------------------------------------- - mission_board: - pm_relevante_entscheidungen: - beschreibung: "Das Mission Board fungiert als taktische Steuerungsebene für PM-Leistungen:" - entscheidungen: - - "Freigabe von Projekt-Leistungen: Entscheidung über ressourcenintensive PM-Unterstützung" - - "Prioritäts-Konflikte: Auflösung von Ressourcenkonflikten zwischen verschiedenen PM-Anfragen" - - "Prozess-Governance-Eskalationen: Entscheidung bei schwerwiegenden Governance-Konflikten" - - "Jährliche PM-Leistungsplanung: Freigabe des Jahresplans für geplante PM-Leistungen" - - pm_reporting: - - "Regelmäßige Governance-Reports: Performance der PM-Funktion, Framework-Adoption, kritische Issues" - - "Ad-hoc Eskalations-Briefings: Bei strategischen Problemen oder Ressourcenengpässen" - - "Jährliche Leistungsplanung: Vorstellung des geplanten Leistungs-Portfolios für das Folgejahr" - -# ============================================================================= -# 5. VERANTWORTUNGS- UND ESKALATIONSARCHITEKTUR -# ============================================================================= - -verantwortungsarchitektur: - - # --------------------------------------------------------------------------- - # 5.1 Primäre Verantwortlichkeiten - # --------------------------------------------------------------------------- - primaere_verantwortlichkeiten: - - leiter_pm: - rolle: "Leiter*in Prozess-Management" - verantwortlichkeiten: - - "Strategische Verantwortung: Ausrichtung der PM-Funktion an DIGITOM-Zielen" - - "Ressourcen-Verantwortung: Allokation von PM-Kapazitäten nach strategischen Prioritäten" - - "Stakeholder-Verantwortung: Management der Beziehungen zu Gremien und Fachbereichen" - - "Eskalations-Verantwortung: Entscheidung bei PM-internen Konflikten und strategischen Issues" - delegation_nach_oben: - - "Konflikte mit gesetzlichen vs. strategischen Prioritäten" - - "Grundsätzliche Richtungsentscheidungen" - - "Politisch sensible Themen" - - prozess_framework_manager: - rolle: "Prozess-Framework-Manager*in" - verantwortlichkeiten: - - "Framework-Verantwortung: Qualität, Aktualität und Anwendbarkeit des PM-Frameworks" - - "Standards-Verantwortung: Definition und Pflege einheitlicher PM-Standards" - - "Innovation-Verantwortung: Integration neuer Tools, Methoden und Best Practices" - - prozesslandschafts_koordinator: - rolle: "Prozesslandschafts-Koordinator*in" - verantwortlichkeiten: - - "Governance-Verantwortung: Überwachung der PM-Framework-Compliance und Governance-Qualität" - - "Koordinations-Verantwortung: Abstimmung zwischen verschiedenen Process Ownern" - - "Reporting-Verantwortung: Bereitstellung von PM-Governance-Transparenz für Gremien" - - prozess_berater: - rolle: "Prozess-Berater*in" - verantwortlichkeiten: - - "Leistungsverantwortung: Qualität der direkten PM-Beratung und -Unterstützung" - - "Kundenverantwortung: Zufriedenheit und Erfolg der betreuten Fachbereiche" - - key_user_netzwerk_manager: - rolle: "Key-User-Netzwerk-Manager*in" - verantwortlichkeiten: - - "Community-Verantwortung: Aufbau und Betreuung des dezentralen PM-Netzwerks" - - "Befähigungs-Verantwortung: Kompetenzentwicklung und Selbsthilfe-Befähigung" - - # --------------------------------------------------------------------------- - # 5.2 Eskalationswege - # --------------------------------------------------------------------------- - eskalationswege: - - stufe_1: - name: "Operative Eskalation (binnen PM-Funktion)" - trigger: - - "Ressourcenkonflikte" - - "Komplexe Beratungsfälle" - - "Methodenunklarheiten" - eskalationsweg: "Beratende PM-Rolle → Leiter*in PM" - zeitrahmen: "24-48 Stunden für Entscheidung" - outcomes: - - "Ressourcen-Umpriorisierung" - - "Methodische Klärung" - - "Interne Lösungsfindung" - - stufe_2: - name: "Taktische Eskalation (Mission Board)" - trigger: - - "Strategische Ressourcenkonflikte" - - "Framework-Widerstand" - - "Prozessübergreifende Konflikte" - eskalationsweg: "Leiter*in PM → Mission Board (über reguläre Sitzungen oder ad-hoc)" - zeitrahmen: "1-2 Wochen für Mission Board-Behandlung" - outcomes: - - "Prioritäts-Neuordnung" - - "Konfliktlösung" - - "Zusätzliche Ressourcen-Freigabe" - verpflichtende_eskalation: - - "Ressourcenkonflikte zwischen Projekten mit harten Deadlines" - - "Governance-Lücken, die nicht binnen 4 Wochen gelöst werden können" - - "Verweigerung der Zusammenarbeit durch Abteilungen" - - "Grundsätzliche Framework-Widerstände aus mehreren Bereichen" - - stufe_3: - name: "Strategische Eskalation (Vision Board)" - trigger: - - "Grundsätzliche Framework-Konflikte" - - "Strategische PM-Richtungsfragen" - - "Organisationsweite PM-Krisen" - eskalationsweg: "Mission Board → Vision Board oder direkt durch Leiter*in PM bei Krisensituationen" - zeitrahmen: "2-4 Wochen für strategische Entscheidung" - outcomes: - - "Strategische Neuausrichtung" - - "Framework-Grundsatzentscheidungen" - - "Organisationsänderungen" - - # --------------------------------------------------------------------------- - # 5.3 Governance-Lücken-Management - # --------------------------------------------------------------------------- - governance_luecken_management: - beschreibung: "Wenn die PLK eine Governance-Lücke im DIGIT/DIGITOM identifiziert:" - - kurzfristig_loesbar: - - "PLK informiert Prozessberater*in" - - "Prozessberater*in spricht mit verantwortlicher Person im Fachbereich" - - "Bei erfolgreicher Lösung: Dokumentation durch PLK, Monitoring der Umsetzung" - - langfristig_strukturell: - - "PLK dokumentiert die Governance-Lücke" - - "Strukturierte Eskalation über LPM ans Mission Board" - - "Mission Board priorisiert und entscheidet über Maßnahmen" - - "PLK verfolgt initiierte Maßnahmen bis zur Schließung der Lücke nach" - - keine_kooperation: - - "Direkte Eskalation ans Mission Board mit Hinweis auf Verweigerung" - - "Mission Board entscheidet über verbindliche Maßnahmen" - - # --------------------------------------------------------------------------- - # 5.4 Konfliktlösungs-Mechanismen - # --------------------------------------------------------------------------- - konfliktloesung: - - framework_widerstand: - - stufe: 1 - aktion: "Prozess-Berater*in führt Stakeholder-Dialog zur Bedarfsklärung" - - stufe: 2 - aktion: "Prozesslandschafts-Koordinator*in moderiert Interessenausgleich" - - stufe: 3 - aktion: "Leiter*in PM eskaliert an zuständiges Gremium für autoritative Entscheidung" - - ressourcen_konkurrenz: - - "Dokumentation aller konkurrierenden Anfragen mit Business Case und Dringlichkeit" - - "Stakeholder-Konsultation zur Interessenabwägung" - - "Entscheidung durch Leiter*in PM nach definierten Prioritätskriterien" - - "Transparente Kommunikation der Entscheidung und alternative Lösungsoptionen" - - compliance_konflikte: - - "Sofortige Einbindung relevanter Compliance-Funktionen (ISB, Datenschutz, QM)" - - "Gemeinsame Lösungsentwicklung zwischen PM und Compliance-Bereichen" - - "Eskalation an Mission Board bei unauflösbaren Zielkonflikten" - -# ============================================================================= -# 6. JAHRESPLANUNG UND STRATEGISCHE LEISTUNGS-GOVERNANCE -# ============================================================================= - -jahresplanung: - - planungsprozess: - - zeitpunkt: "Q4 des Vorjahres" - aktivitaet: "Bedarfserhebung bei allen Stakeholdern und strategische Priorisierung" - - zeitpunkt: "Dezember" - aktivitaet: "Entwurf des PM-Leistungsplans mit Ressourcenallokation und Zeitplanung" - - zeitpunkt: "Januar" - aktivitaet: "Mission Board-Freigabe des Plans nach eventuellen Anpassungen" - - zeitpunkt: "Februar" - aktivitaet: "Kommunikation und Abstimmung der geplanten Leistungen mit Stakeholdern" - - leistungs_portfolio_struktur: - hinweis: "Beispielhafte Verteilung" - verteilung: - - kategorie: "Strategische Leistungen" - anteil: "40%" - beschreibung: "Vom Vision Board beauftragte strategische Initiativen" - - kategorie: "Projekt Leistungen" - anteil: "30%" - beschreibung: "Geplante projektbezogene PM-Unterstützung nach Mission Board-Priorisierung" - - kategorie: "Geplante Standard-Leistungen" - anteil: "20%" - beschreibung: "Regelmäßige Leistungen wie Schulungen, Community-Events, Framework-Updates" - - kategorie: "Krisen-Reserve" - anteil: "10%" - beschreibung: "Reserve für ungeplante Krisen-Leistungen" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #05 - Prozess-Management: Governance-Modell.docx - - Inhalte: - - Governance-Philosophie und Leitprinzipien - - Interne PM-Governance (Framework-Änderungen Kat. A/B/C) - - Leistungs-Governance (4 Leistungskategorien) - - Projektzentrierte Prozessgestaltung (Quality Gates) - - Externe Governance-Integration (VB, MB) - - Eskalationsarchitektur (3 Stufen) - - Konfliktlösungs-Mechanismen - - Jahresplanung - autor: "DIGITOM-Projekt" +# ============================================================================= +# GOVERNANCE-FRAMEWORK: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "governance-framework" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Governance" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#05 - Prozess-Management: Governance-Modell.docx" + +# ============================================================================= +# 1. GOVERNANCE-PHILOSOPHIE UND GRUNDPRINZIPIEN +# ============================================================================= + +governance_philosophie: + kernaussage: | + Das Prozess-Management-Governance-Framework folgt dem Prinzip der + "Befähigungs-Governance" - es soll befähigen und unterstützen, nicht + kontrollieren und bremsen. Gleichzeitig muss es sich nahtlos in die + bestehende DIGITOM-Governance-Architektur integrieren. + + leitprinzipien: + - prinzip: "Subsidiarität" + beschreibung: | + Entscheidungen werden auf der niedrigstmöglichen Ebene getroffen, + die kompetent und legitimiert ist. Operative Prozess-Beratung braucht + keine Gremien-Freigabe, strategische Framework-Änderungen schon. + + - prinzip: "Proportionalität" + beschreibung: | + Der Governance-Aufwand muss dem Risiko und der Tragweite einer + Entscheidung angemessen sein. Eine Template-Anpassung braucht weniger + Governance als eine komplette Framework-Transformation. + + - prinzip: "Integration" + beschreibung: | + PM-Governance ergänzt die bestehende DIGITOM-Governance, ersetzt sie nicht. + Vision Board, Mission Board und DSR bleiben die primären Steuerungsgremien. + + - prinzip: "Transparenz" + beschreibung: | + Alle Governance-Entscheidungen und ihre Begründungen müssen nachvollziehbar + dokumentiert und kommuniziert werden. + +# ============================================================================= +# 2. INTERNE PM-GOVERNANCE +# ============================================================================= + +interne_governance: + + # --------------------------------------------------------------------------- + # 2.1 Framework-Änderungs-Governance + # --------------------------------------------------------------------------- + framework_aenderungen: + beschreibung: | + Die Governance für Framework-Änderungen folgt einem dreistufigen Modell, + das die Komplexität und Tragweite der Änderungen berücksichtigt. + + kategorie_a: + name: "Operative Anpassungen" + definition: | + Kleinere Verbesserungen, Klarstellungen oder Ergänzungen, + die die Framework-Grundlogik nicht verändern. + beispiele: + - "Template-Updates" + - "Methodenbeschreibungs-Präzisierungen" + - "Tool-Konfigurationsanpassungen" + - "FAQ-Ergänzungen" + entscheidungsweg: + - schritt: 1 + aktion: "Prozess-Framework-Manager*in trifft Entscheidung eigenständig nach fachlicher Prüfung und Dokumentation" + - schritt: 2 + aktion: "Prozess-Management-Team gibt formale Freigabe" + - schritt: 3 + aktion: "Leiter*in Prozess-Management wird zeitnah informiert" + - schritt: 4 + aktion: "Betroffene Process Owner und Key-User werden über reguläre Kommunikationskanäle benachrichtigt" + implementierung: + - "Kann sofort umgesetzt werden" + - "Änderungen werden im Framework-Changelog dokumentiert" + + kategorie_b: + name: "Taktische Erweiterungen" + definition: | + Bedeutendere Änderungen, die neue Elemente einführen oder bestehende erweitern, + aber die Framework-Architektur beibehalten. + beispiele: + - "Neue Prozess-Kategorien" + - "Zusätzliche PM-Governance-Elemente" + - "Erweiterte KPI-Systematiken" + - "Neue Qualifizierungsmodule" + entscheidungsweg: + - schritt: 1 + aktion: "Prozess-Framework-Manager*in entwickelt den Vorschlag" + - schritt: 2 + aktion: "Prozess-Management-Team gibt formale Freigabe" + - schritt: 3 + aktion: "Betroffene Process Owner werden konsultiert und können Einwände oder Verbesserungsvorschläge einbringen" + - schritt: 4 + aktion: "Mission Board wird über die Änderung informiert und kann Feedback geben" + implementierung: + - "Erfordert Vorlaufzeit für Stakeholder-Abstimmung und Kommunikation" + - "Implementierung erfolgt zu definierten Stichtagen für Planbarkeit" + + kategorie_c: + name: "Strategische Transformationen" + definition: | + Fundamentale Änderungen der Framework-Philosophie oder -Architektur, + die das Operating Model betreffen. + beispiele: + - "Wechsel der Grundmethodik" + - "Komplette Neudefinition der PM-Governance-Struktur" + - "Integration neuer strategischer Anforderungen" + entscheidungsweg: + - schritt: 1 + aktion: "Prozess-Framework-Manager*in erarbeitet Konzept mit Stakeholder-Analyse und Impact-Assessment" + - schritt: 2 + aktion: "Leiter*in Prozess-Management koordiniert umfassende Abstimmungsrunde mit allen betroffenen Bereichen" + - schritt: 3 + aktion: "Mission Board führt Vorbewertung durch und gibt Empfehlung ab" + - schritt: 4 + aktion: "Vision Board trifft finale Entscheidung nach Präsentation des Konzepts" + implementierung: + - "Erfordert längere Vorlaufzeit mit detailliertem Change Management-Plan" + - "Implementierung erfolgt als formales Transformationsprojekt mit entsprechendem Projektmanagement" + + # --------------------------------------------------------------------------- + # 2.2 Ressourcen- und Prioritäts-Governance + # --------------------------------------------------------------------------- + ressourcen_governance: + kapazitaetsallokation: + beschreibung: | + Die Leiter*in Prozess-Management verteilt die verfügbaren PM-Kapazitäten + nach folgender Prioritätslogik: + prioritaeten: + - prio: 1 + typ: "Strategische Leistungen mit Vision Board-Freigabe" + - prio: 2 + typ: "Projekt Leistungen mit Mission Board-Freigabe" + - prio: 3 + typ: "Compliance-kritische Standard Leistungen" + - prio: 4 + typ: "Geplante Standard Leistungen aus Jahresplanung" + - prio: 5 + typ: "Ad-hoc Standard Leistungen nach Verfügbarkeit" + + interne_koordination: + - format: "Wöchentliche PM-Team-Abstimmung" + inhalt: "Operative Koordination, Ressourcenplanung, Problem-Eskalation" + - format: "Monatliche Stakeholder-Runde" + inhalt: "Review mit Process Ownern, Feedback-Sammlung, Planungsabstimmung" + - format: "Regelmäßige Governance-Review" + inhalt: "Framework-Performance, Governance-Optimierung, strategische Ausrichtung" + +# ============================================================================= +# 3. LEISTUNGS-GOVERNANCE UND BEAUFTRAGUNG +# ============================================================================= + +leistungs_governance: + + # --------------------------------------------------------------------------- + # 3.1 Leistungskategorien + # --------------------------------------------------------------------------- + leistungskategorien: + + standard_leistungen: + definition: | + Wiederkehrende, standardisierte PM-Unterstützung für operative Bedarfe. + beispiele: + - "Prozess-Workshops in definierten Bereichen" + - "Einzelberatungen" + - "PM-Framework-Schulungen" + - "Prozess-Assessments" + - "Key-User-Support" + beauftragungsberechtigung: "Alle DIGITOM-Mitarbeitenden über Ticketsystem oder direkte Anfrage" + entscheidungsweg: + - "Anfragen werden von zuständiger PM-Rolle (meist Prozess-Berater*in) bewertet" + - "Bearbeitung nach Verfügbarkeit und Priorität" + - "Bei Ressourcenkonflikten entscheidet Leiter*in Prozess-Management" + + projekt_leistungen: + definition: | + Umfangreichere, projektähnliche PM-Unterstützung, die signifikante Ressourcen bindet. + beispiele: + - "Komplette Prozess-Neugestaltung" + - "PM-Tool-Einführung" + - "Bereichsspezifische PM-Framework-Entwicklung" + - "Umfassende Prozess-Transformationen" + abgrenzung: + quantitativ: + - "Leistung über 10 Beratungstage" + - "Laufzeit über 4 Wochen" + qualitativ: + - "Leistung mit mehreren Fachbereichen/Abteilungen" + - "Framework-Implikationen" + - "Strategische Relevanz" + beauftragungsberechtigung: "Fachbereichs-/Abteilungsleitungen, Projektleitungen, Gremien" + entscheidungsweg: + - "Antrag wird von Leiter*in PM formuliert und in Mission Board eingebracht" + - "Mission Board prüft strategische Passung, Ressourcen-Impact und Priorisierung" + - "Bei Freigabe wird Leistung als Projekt konfiguriert mit entsprechendem Projektmanagement" + + strategische_leistungen: + definition: | + Strategische PM-Initiativen, die das Operating Model weiterentwickeln oder transformieren. + beispiele: + - "Entwicklung neuer Governance-Strukturen" + - "Strategische Prozess-Digitalisierung" + - "Organisationsweite Methodeneinführung" + - "Integration in Transformationsprojekte" + beauftragungsberechtigung: + - "Vision Board (proaktiv)" + - "Mission Board/Leiter*in PM (als Vorschlag)" + entscheidungsweg: + - "Konzeptentwicklung durch PM-Team mit strategischer Stakeholder-Analyse" + - "Vision Board-Präsentation mit Ressourcen-Impact, Zeitplan und erwarteten Outcomes" + - "Bei Freigabe erfolgt Mandatierung als strategisches Projekt" + + krisen_leistungen: + definition: | + Dringende Prozess-Unterstützung bei akuten Problemen oder Krisen. + beispiele: + - "Compliance-Verstöße mit Prozess-Bezug" + - "Schwerwiegende Prozess-Störungen" + - "Akute Konfliktmediation" + beauftragungsberechtigung: + - "Jede Abteilungsleitung bei akuten Problemen" + - "Amtsleitung bei kritischen Situationen" + entscheidungsweg: + - "Sofortige Bewertung und Klassifizierung durch Leiter*in PM" + - "Ressourcen-Umschichtung nach Krisenlogik (andere Leistungen werden pausiert)" + - "Bildung eines Response-Teams aus relevanten PM-Rollen" + - "Nachträgliche Information an Mission Board" + - "Post-Crisis-Review zur Governance-Optimierung" + + # --------------------------------------------------------------------------- + # 3.2 Projektzentrierte Prozessgestaltung + # --------------------------------------------------------------------------- + projektzentrierte_prozessgestaltung: + beschreibung: "Spezial-PM-Governance für Projekte mit Prozess-Impact" + + obligatorische_compliance: + hinweis: "Jedes Projekt, das Prozesse neu gestaltet oder verändert, muss folgende PM-Elemente berücksichtigen:" + elemente: + - name: "Key-User-Integration" + beschreibung: "Key-User müssen konsultiert und in die Prozessgestaltung eingebunden werden" + - name: "PM-Framework-konforme Dokumentation" + beschreibung: "Neue Prozesse müssen nach PM-Standards dokumentiert werden" + - name: "Process Owner-Koordination" + beschreibung: "Bei Änderungen an bestehenden Prozessen muss der zuständige Process Owner konsultiert werden" + - name: "Standardnotation" + beschreibung: "Prozessmodellierung muss PM-Framework-konforme Notation verwenden" + + process_owner_abnahme: + name: "Process Owner-Abnahme als Quality Gate" + beschreibung: | + Bei allen Projekten, die Prozesse verändern, die einem Process Owner + zugeordnet sind, muss dieser formale Abnahme-Verantwortung übernehmen. + pruefbereiche: + - "Fachliche Korrektheit: End-to-End-Konsistenz des veränderten Prozesses" + - "Schnittstellen-Impact: Auswirkungen auf vor- und nachgelagerte Prozesse" + - "Implementierbarkeit: Praktische Umsetzbarkeit im operativen Betrieb" + veto_recht: + - "Process Owner hat finales Veto-Recht bei inhaltlichen Aspekten" + - "Bei Veto: Verpflichtende Mediation durch PM-Leitung" + - "Eskalation ans Mission Board nur bei unlösbaren Konflikten" + - "Dokumentationspflicht für Veto-Gründe" + + pm_qualitaetspruefung: + name: "PM-Qualitätsprüfung als methodisches Quality Gate" + beschreibung: | + Für alle Projekte mit Prozess-Impact führt die PM-Funktion eine formale + Qualitätsprüfung durch (vor Projektabschluss, Voraussetzung für finale Abnahme). + pruefbereiche: + - "PM-Framework-Compliance-Check: Einhaltung aller PM-Standards" + - "Cross-Process-Impact-Analysis: Bewertung möglicher Seiteneffekte auf andere Prozesse" + - "Tool-Kompatibilität: Integration in bestehende PM-Tools" + - "Dokumentations-Vollständigkeit: Vollständige und korrekte Dokumentation" + +# ============================================================================= +# 4. EXTERNE GOVERNANCE-INTEGRATION +# ============================================================================= + +externe_governance: + + # --------------------------------------------------------------------------- + # 4.1 Vision Board-Integration + # --------------------------------------------------------------------------- + vision_board: + pm_relevante_entscheidungen: + - "PM-Strategische Ausrichtung: Grundsätzliche Rolle und Positionierung der PM-Funktion in DIGITOM" + - "Framework-Transformationen: Freigabe strategischer Framework-Änderungen (Kategorie C)" + - "Strategische Leistungen: Beauftragung und Priorisierung strategischer PM-Initiativen" + - "PM-Ressourcen-Rahmen: Grundsätzliche Kapazitäts- und Budget-Entscheidungen für PM-Funktion" + + pm_input: + beschreibung: "Die Leiter*in PM liefert strategischen Input für Vision Board-Entscheidungen:" + inhalte: + - "Prozesslandschafts-Assessment: Jährliche Bewertung der Prozess-Reife und strategischen Prozess-Herausforderungen" + - "Framework-Entwicklungsvorschläge: Vorschläge für strategische Framework-Weiterentwicklungen" + - "Organisationsreife-Einschätzung: Assessment der PM-Kompetenz und Change-Bereitschaft in DIGITOM" + + # --------------------------------------------------------------------------- + # 4.2 Mission Board-Integration + # --------------------------------------------------------------------------- + mission_board: + pm_relevante_entscheidungen: + beschreibung: "Das Mission Board fungiert als taktische Steuerungsebene für PM-Leistungen:" + entscheidungen: + - "Freigabe von Projekt-Leistungen: Entscheidung über ressourcenintensive PM-Unterstützung" + - "Prioritäts-Konflikte: Auflösung von Ressourcenkonflikten zwischen verschiedenen PM-Anfragen" + - "Prozess-Governance-Eskalationen: Entscheidung bei schwerwiegenden Governance-Konflikten" + - "Jährliche PM-Leistungsplanung: Freigabe des Jahresplans für geplante PM-Leistungen" + + pm_reporting: + - "Regelmäßige Governance-Reports: Performance der PM-Funktion, Framework-Adoption, kritische Issues" + - "Ad-hoc Eskalations-Briefings: Bei strategischen Problemen oder Ressourcenengpässen" + - "Jährliche Leistungsplanung: Vorstellung des geplanten Leistungs-Portfolios für das Folgejahr" + +# ============================================================================= +# 5. VERANTWORTUNGS- UND ESKALATIONSARCHITEKTUR +# ============================================================================= + +verantwortungsarchitektur: + + # --------------------------------------------------------------------------- + # 5.1 Primäre Verantwortlichkeiten + # --------------------------------------------------------------------------- + primaere_verantwortlichkeiten: + + leiter_pm: + rolle: "Leiter*in Prozess-Management" + verantwortlichkeiten: + - "Strategische Verantwortung: Ausrichtung der PM-Funktion an DIGITOM-Zielen" + - "Ressourcen-Verantwortung: Allokation von PM-Kapazitäten nach strategischen Prioritäten" + - "Stakeholder-Verantwortung: Management der Beziehungen zu Gremien und Fachbereichen" + - "Eskalations-Verantwortung: Entscheidung bei PM-internen Konflikten und strategischen Issues" + delegation_nach_oben: + - "Konflikte mit gesetzlichen vs. strategischen Prioritäten" + - "Grundsätzliche Richtungsentscheidungen" + - "Politisch sensible Themen" + + prozess_framework_manager: + rolle: "Prozess-Framework-Manager*in" + verantwortlichkeiten: + - "Framework-Verantwortung: Qualität, Aktualität und Anwendbarkeit des PM-Frameworks" + - "Standards-Verantwortung: Definition und Pflege einheitlicher PM-Standards" + - "Innovation-Verantwortung: Integration neuer Tools, Methoden und Best Practices" + + prozesslandschafts_koordinator: + rolle: "Prozesslandschafts-Koordinator*in" + verantwortlichkeiten: + - "Governance-Verantwortung: Überwachung der PM-Framework-Compliance und Governance-Qualität" + - "Koordinations-Verantwortung: Abstimmung zwischen verschiedenen Process Ownern" + - "Reporting-Verantwortung: Bereitstellung von PM-Governance-Transparenz für Gremien" + + prozess_berater: + rolle: "Prozess-Berater*in" + verantwortlichkeiten: + - "Leistungsverantwortung: Qualität der direkten PM-Beratung und -Unterstützung" + - "Kundenverantwortung: Zufriedenheit und Erfolg der betreuten Fachbereiche" + + key_user_netzwerk_manager: + rolle: "Key-User-Netzwerk-Manager*in" + verantwortlichkeiten: + - "Community-Verantwortung: Aufbau und Betreuung des dezentralen PM-Netzwerks" + - "Befähigungs-Verantwortung: Kompetenzentwicklung und Selbsthilfe-Befähigung" + + # --------------------------------------------------------------------------- + # 5.2 Eskalationswege + # --------------------------------------------------------------------------- + eskalationswege: + + stufe_1: + name: "Operative Eskalation (binnen PM-Funktion)" + trigger: + - "Ressourcenkonflikte" + - "Komplexe Beratungsfälle" + - "Methodenunklarheiten" + eskalationsweg: "Beratende PM-Rolle → Leiter*in PM" + zeitrahmen: "24-48 Stunden für Entscheidung" + outcomes: + - "Ressourcen-Umpriorisierung" + - "Methodische Klärung" + - "Interne Lösungsfindung" + + stufe_2: + name: "Taktische Eskalation (Mission Board)" + trigger: + - "Strategische Ressourcenkonflikte" + - "Framework-Widerstand" + - "Prozessübergreifende Konflikte" + eskalationsweg: "Leiter*in PM → Mission Board (über reguläre Sitzungen oder ad-hoc)" + zeitrahmen: "1-2 Wochen für Mission Board-Behandlung" + outcomes: + - "Prioritäts-Neuordnung" + - "Konfliktlösung" + - "Zusätzliche Ressourcen-Freigabe" + verpflichtende_eskalation: + - "Ressourcenkonflikte zwischen Projekten mit harten Deadlines" + - "Governance-Lücken, die nicht binnen 4 Wochen gelöst werden können" + - "Verweigerung der Zusammenarbeit durch Abteilungen" + - "Grundsätzliche Framework-Widerstände aus mehreren Bereichen" + + stufe_3: + name: "Strategische Eskalation (Vision Board)" + trigger: + - "Grundsätzliche Framework-Konflikte" + - "Strategische PM-Richtungsfragen" + - "Organisationsweite PM-Krisen" + eskalationsweg: "Mission Board → Vision Board oder direkt durch Leiter*in PM bei Krisensituationen" + zeitrahmen: "2-4 Wochen für strategische Entscheidung" + outcomes: + - "Strategische Neuausrichtung" + - "Framework-Grundsatzentscheidungen" + - "Organisationsänderungen" + + # --------------------------------------------------------------------------- + # 5.3 Governance-Lücken-Management + # --------------------------------------------------------------------------- + governance_luecken_management: + beschreibung: "Wenn die PLK eine Governance-Lücke im DIGIT/DIGITOM identifiziert:" + + kurzfristig_loesbar: + - "PLK informiert Prozessberater*in" + - "Prozessberater*in spricht mit verantwortlicher Person im Fachbereich" + - "Bei erfolgreicher Lösung: Dokumentation durch PLK, Monitoring der Umsetzung" + + langfristig_strukturell: + - "PLK dokumentiert die Governance-Lücke" + - "Strukturierte Eskalation über LPM ans Mission Board" + - "Mission Board priorisiert und entscheidet über Maßnahmen" + - "PLK verfolgt initiierte Maßnahmen bis zur Schließung der Lücke nach" + + keine_kooperation: + - "Direkte Eskalation ans Mission Board mit Hinweis auf Verweigerung" + - "Mission Board entscheidet über verbindliche Maßnahmen" + + # --------------------------------------------------------------------------- + # 5.4 Konfliktlösungs-Mechanismen + # --------------------------------------------------------------------------- + konfliktloesung: + + framework_widerstand: + - stufe: 1 + aktion: "Prozess-Berater*in führt Stakeholder-Dialog zur Bedarfsklärung" + - stufe: 2 + aktion: "Prozesslandschafts-Koordinator*in moderiert Interessenausgleich" + - stufe: 3 + aktion: "Leiter*in PM eskaliert an zuständiges Gremium für autoritative Entscheidung" + + ressourcen_konkurrenz: + - "Dokumentation aller konkurrierenden Anfragen mit Business Case und Dringlichkeit" + - "Stakeholder-Konsultation zur Interessenabwägung" + - "Entscheidung durch Leiter*in PM nach definierten Prioritätskriterien" + - "Transparente Kommunikation der Entscheidung und alternative Lösungsoptionen" + + compliance_konflikte: + - "Sofortige Einbindung relevanter Compliance-Funktionen (ISB, Datenschutz, QM)" + - "Gemeinsame Lösungsentwicklung zwischen PM und Compliance-Bereichen" + - "Eskalation an Mission Board bei unauflösbaren Zielkonflikten" + +# ============================================================================= +# 6. JAHRESPLANUNG UND STRATEGISCHE LEISTUNGS-GOVERNANCE +# ============================================================================= + +jahresplanung: + + planungsprozess: + - zeitpunkt: "Q4 des Vorjahres" + aktivitaet: "Bedarfserhebung bei allen Stakeholdern und strategische Priorisierung" + - zeitpunkt: "Dezember" + aktivitaet: "Entwurf des PM-Leistungsplans mit Ressourcenallokation und Zeitplanung" + - zeitpunkt: "Januar" + aktivitaet: "Mission Board-Freigabe des Plans nach eventuellen Anpassungen" + - zeitpunkt: "Februar" + aktivitaet: "Kommunikation und Abstimmung der geplanten Leistungen mit Stakeholdern" + + leistungs_portfolio_struktur: + hinweis: "Beispielhafte Verteilung" + verteilung: + - kategorie: "Strategische Leistungen" + anteil: "40%" + beschreibung: "Vom Vision Board beauftragte strategische Initiativen" + - kategorie: "Projekt Leistungen" + anteil: "30%" + beschreibung: "Geplante projektbezogene PM-Unterstützung nach Mission Board-Priorisierung" + - kategorie: "Geplante Standard-Leistungen" + anteil: "20%" + beschreibung: "Regelmäßige Leistungen wie Schulungen, Community-Events, Framework-Updates" + - kategorie: "Krisen-Reserve" + anteil: "10%" + beschreibung: "Reserve für ungeplante Krisen-Leistungen" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + Quelle: #05 - Prozess-Management: Governance-Modell.docx + + Inhalte: + - Governance-Philosophie und Leitprinzipien + - Interne PM-Governance (Framework-Änderungen Kat. A/B/C) + - Leistungs-Governance (4 Leistungskategorien) + - Projektzentrierte Prozessgestaltung (Quality Gates) + - Externe Governance-Integration (VB, MB) + - Eskalationsarchitektur (3 Stufen) + - Konfliktlösungs-Mechanismen + - Jahresplanung + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.2_governance/pm_raci.yaml b/#05_prozessmanagement/#05.2_governance/pm_raci.yaml index cdfae04..f67aa38 100644 --- a/#05_prozessmanagement/#05.2_governance/pm_raci.yaml +++ b/#05_prozessmanagement/#05.2_governance/pm_raci.yaml @@ -1,721 +1,721 @@ -# ============================================================================= -# RACI-MATRIX: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Excel-Dokumentation -# ============================================================================= - -meta: - typ: "raci-matrix" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#06 - Prozess-Management: RACI Matrix.xlsx" - -# ============================================================================= -# RACI-LEGENDE -# ============================================================================= - -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" - - kombinationen: - "A/R": "Accountable und Responsible in einer Rolle" - "R (lokal)": "Responsible auf lokaler Ebene (Key-User-Netzwerk/Bereich)" - "C (fachlich)": "Consulted für Fachprozesse" - - hinweis_entscheidung: "Bei Unentschieden im PM-Team hat LPM Entscheidungshoheit" - -# ============================================================================= -# ROLLEN-ÜBERSICHT -# ============================================================================= - -rollen: - # Interne PM-Rollen - LPM: - name: "Leitung Prozess-Management" - fokus: "Strategische Führung, Ressourcenverantwortung" - kategorie: "intern" - - PFM: - name: "Prozess-Framework-Manager:in" - fokus: "Methodische Standards, Framework-Entwicklung" - kategorie: "intern" - - PLK: - name: "Prozesslandschafts-Koordinator:in" - fokus: "Übergreifende Prozessharmonisierung" - kategorie: "intern" - - PB: - name: "Prozess-Berater:in-Team" - fokus: "Operative Beratung und Durchführung" - kategorie: "intern" - - KNM: - name: "Key-User-Netzwerk-Manager:in" - fokus: "Dezentrale PM-Befähigung, Community-Management" - kategorie: "intern" - - # Schnittstellenrollen - PO: - name: "Process Owner" - fokus: "Fachliche Prozessverantwortung" - kategorie: "schnittstelle" - - KU: - name: "Key User" - fokus: "Lokale Prozessexpertise, erste Anlaufstelle" - kategorie: "schnittstelle" - - # Governance-Rollen - GL: - name: "Geschäftsleitung (VB/MB/AL konsolidiert)" - fokus: "Strategische Entscheidungen" - kategorie: "governance" - hinweis: "VB = Vision Board, MB = Mission Board, AL = Amtsleitung" - - # Externe Rollen - PL: - name: "Projektleitung" - fokus: "Projektspezifische Umsetzung" - kategorie: "extern" - - QS: - name: "Qualitätssicherung (ISB/DSB/ITA konsolidiert)" - fokus: "Compliance und technische Standards" - kategorie: "extern" - hinweis: "ISB = Informationssicherheitsbeauftragter, DSB = Datenschutzbeauftragter, ITA = IT-Architektur" - - FBL: - name: "Fachbereichsleitung" - fokus: "Fachliche Auftraggeber" - kategorie: "extern" - -# ============================================================================= -# 1. FRAMEWORK-GOVERNANCE -# ============================================================================= - -bereich_1_framework_governance: - name: "Framework-Governance" - - # --------------------------------------------------------------------------- - # 1.1 Framework-Entwicklung - # --------------------------------------------------------------------------- - framework_entwicklung: - name: "Framework-Entwicklung" - - kategorie_a_operative_anpassungen: - name: "Kategorie A: Operative Anpassungen" - aktivitaeten: - - aktivitaet: "Methoden-Feintuning" - LPM: "I" - PFM: "R" - PLK: "C" - PB: "C" - PO: "I" - GL: "-" - KNM: "I" - KU: "I" - PM_Team: "A/R" - - - aktivitaet: "Template-Updates" - LPM: "I" - PFM: "R" - PLK: "C" - PB: "C" - PO: "I" - GL: "-" - KNM: "I" - KU: "I" - PM_Team: "A/R" - - - aktivitaet: "Dokumentation aktualisieren" - LPM: "I" - PFM: "R" - PLK: "C" - PB: "C" - PO: "I" - GL: "-" - KNM: "I" - KU: "I" - PM_Team: "A/R" - - kategorie_b_taktische_erweiterungen: - name: "Kategorie B: Taktische Erweiterungen" - aktivitaeten: - - aktivitaet: "Neue Methoden entwickeln" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C" - GL: "I" - KNM: "C" - KU: "I" - - - aktivitaet: "Standards erweitern" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C" - GL: "I" - KNM: "C" - KU: "I" - - - aktivitaet: "Tool-Integration" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - PO: "I" - GL: "I" - QS: "C" - - kategorie_c_strategische_transformationen: - name: "Kategorie C: Strategische Transformationen" - aktivitaeten: - - aktivitaet: "Framework-Neuausrichtung" - LPM: "R" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C" - GL: "A" - KNM: "C" - KU: "I" - - - aktivitaet: "Paradigmenwechsel" - LPM: "R" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C" - GL: "A" - KNM: "C" - KU: "I" - - # --------------------------------------------------------------------------- - # 1.2 Framework-Kommunikation - # --------------------------------------------------------------------------- - framework_kommunikation: - name: "Framework-Kommunikation" - aktivitaeten: - - aktivitaet: "Schulungskonzepte" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - KNM: "R" - KU: "I" - - - aktivitaet: "Updates kommunizieren" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "R" - KNM: "R" - KU: "R (lokal)" - hinweis: "R (lokal) = für KU-Netzwerk/Bereich" - - - aktivitaet: "Framework-Portal pflegen" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - KNM: "C" - -# ============================================================================= -# 2. LEISTUNGSERBRINGUNG -# ============================================================================= - -bereich_2_leistungserbringung: - name: "Leistungserbringung" - - # --------------------------------------------------------------------------- - # 2.1 Standard Leistungen - # --------------------------------------------------------------------------- - standard_leistungen: - name: "Standard Leistungen (Regelgeschäft)" - aktivitaeten: - - aktivitaet: "Leistungsanfrage annehmen" - LPM: "I" - PFM: "I" - PLK: "I" - PB: "R" - PO: "C" - FBL: "C" - - - aktivitaet: "Aufwand schätzen" - LPM: "I" - PFM: "C" - PLK: "C" - PB: "R" - PO: "I" - - - aktivitaet: "Leistung durchführen" - LPM: "I" - PFM: "C" - PLK: "C" - PB: "R" - PO: "C" - KU: "C" - - - aktivitaet: "Qualität sicherstellen" - LPM: "A" - PFM: "C" - PLK: "C" - PB: "R" - PO: "C" - - # --------------------------------------------------------------------------- - # 2.2 Projekt Leistungen - # --------------------------------------------------------------------------- - projekt_leistungen: - name: "Projekt Leistungen (Geplante Projekte)" - hinweis: "Bei kritischen Konflikten: Empfehlung an MB, finale Entscheidung durch MB" - aktivitaeten: - - aktivitaet: "Projektantrag bewerten" - LPM: "R" - PFM: "C" - PLK: "C" - PB: "C" - PO: "C" - GL: "A" - PL: "R" - - - aktivitaet: "Ressourcen zuweisen" - LPM: "A" - PFM: "C" - PLK: "C" - PB: "I" - GL: "I" - PL: "C" - - - aktivitaet: "PM-Integration planen" - LPM: "A" - PFM: "C" - PLK: "R" - PB: "R" - PO: "C" - PL: "C" - - - aktivitaet: "Projekt begleiten" - LPM: "I" - PFM: "C" - PLK: "C" - PB: "R" - PO: "C" - PL: "A" - - # --------------------------------------------------------------------------- - # 2.3 Strategische Leistungen - # --------------------------------------------------------------------------- - strategische_leistungen: - name: "Strategische Leistungen (Transformationsinitiativen)" - aktivitaeten: - - aktivitaet: "Initiative konzipieren" - LPM: "R" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C" - GL: "I" - - - aktivitaet: "Business Case erstellen" - LPM: "R" - PFM: "R" - PLK: "C" - PB: "C" - GL: "I" - - - aktivitaet: "Board-Freigabe einholen" - LPM: "R" - PFM: "C" - PLK: "C" - GL: "A" - - - aktivitaet: "Umsetzung steuern" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "R" - PO: "C" - GL: "I" - - # --------------------------------------------------------------------------- - # 2.4 Krisen-Leistungen - # --------------------------------------------------------------------------- - krisen_leistungen: - name: "Krisen-Leistungen (Krisensituationen)" - aktivitaeten: - - aktivitaet: "Notfall klassifizieren" - LPM: "A" - PFM: "C" - PLK: "C" - PB: "R" - GL: "I" - - - aktivitaet: "Ressourcen mobilisieren" - LPM: "A" - PFM: "C" - PLK: "C" - PB: "R" - GL: "I" - - - aktivitaet: "Krisenunterstützung" - LPM: "A" - PFM: "C" - PLK: "C" - PB: "R" - PO: "C" - FBL: "C" - - - aktivitaet: "Lessons Learned" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "R" - PO: "C" - GL: "I" - - # --------------------------------------------------------------------------- - # 2.5 Key-User-Management - # --------------------------------------------------------------------------- - key_user_management: - name: "Key-User-Management" - aktivitaeten: - - aktivitaet: "KU identifizieren" - LPM: "A" - KNM: "R" - PB: "C" - FBL: "C" - - - aktivitaet: "KU qualifizieren" - LPM: "A" - KNM: "R" - PFM: "C" - PB: "C" - - - aktivitaet: "KU-Netzwerk betreuen" - LPM: "A" - KNM: "R" - PB: "C" - KU: "C" - - - aktivitaet: "Best Practices teilen" - LPM: "I" - KNM: "R" - PB: "C" - KU: "R" - - - aktivitaet: "Lokale PM-Unterstützung" - LPM: "I" - KNM: "C" - PB: "C" - KU: "R" - -# ============================================================================= -# 3. QUALITÄTSSICHERUNG -# ============================================================================= - -bereich_3_qualitaetssicherung: - name: "Qualitätssicherung" - - # --------------------------------------------------------------------------- - # 3.1 Process Owner Quality Gate - # --------------------------------------------------------------------------- - process_owner_quality_gate: - name: "Process Owner Quality Gate" - aktivitaeten: - - aktivitaet: "Fachliche Konsistenz prüfen" - LPM: "I" - PLK: "C" - PB: "C" - PO: "R" - PL: "C" - - - aktivitaet: "Schnittstellen validieren" - LPM: "I" - PLK: "R" - PB: "C" - PO: "A" - PL: "C" - - - aktivitaet: "Implementierbarkeit bewerten" - LPM: "I" - PLK: "C" - PB: "C" - PO: "R" - PL: "C" - - - aktivitaet: "Gate-Entscheidung" - LPM: "I" - PLK: "C" - PO: "A" - PL: "I" - - # --------------------------------------------------------------------------- - # 3.2 PM Quality Gate - # --------------------------------------------------------------------------- - pm_quality_gate: - name: "PM Quality Gate" - aktivitaeten: - - aktivitaet: "Methodische Konformität" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - PO: "I" - - - aktivitaet: "Prozesslandschafts-Fit" - LPM: "A" - PFM: "C" - PLK: "R" - PB: "C" - PO: "C" - - - aktivitaet: "Dokumentationsqualität" - LPM: "A" - PFM: "R" - PLK: "C" - PB: "C" - PO: "C (fachlich)" - KU: "C (fachlich)" - hinweis: "C (fachlich) = für Fachprozesse" - -# ============================================================================= -# 4. GOVERNANCE-INTEGRATION -# ============================================================================= - -bereich_4_governance_integration: - name: "Governance-Integration" - - # --------------------------------------------------------------------------- - # 4.1 Strategische Ausrichtung - # --------------------------------------------------------------------------- - strategische_ausrichtung: - name: "Strategische Ausrichtung" - aktivitaeten: - - aktivitaet: "Jahresplanung PM" - LPM: "R" - PFM: "C" - PLK: "C" - PB: "C" - GL: "A" - KNM: "C" - - - aktivitaet: "Strategische Reviews" - LPM: "R" - PFM: "C" - PLK: "C" - PB: "C" - GL: "A" - - - aktivitaet: "Ressourcenrahmen" - LPM: "R" - PFM: "C" - PLK: "C" - GL: "A" - - # --------------------------------------------------------------------------- - # 4.2 Operative Koordination - # --------------------------------------------------------------------------- - operative_koordination: - name: "Operative Koordination" - aktivitaeten: - - aktivitaet: "Wöchentliche Teamrunde" - LPM: "A" - PFM: "R" - PLK: "R" - PB: "R" - KNM: "R" - - - aktivitaet: "Monatliche Stakeholder" - LPM: "A" - PFM: "C" - PLK: "R" - PB: "C" - PO: "C" - KNM: "C" - - - aktivitaet: "Quartals-Review" - LPM: "A" - PFM: "R" - PLK: "R" - PB: "C" - GL: "I" - - # --------------------------------------------------------------------------- - # 4.3 Governance-Lücken-Management - # --------------------------------------------------------------------------- - governance_luecken_management: - name: "Governance-Lücken-Management" - aktivitaeten: - - aktivitaet: "Lücke identifizieren" - LPM: "I" - PFM: "C" - PLK: "R" - PB: "C" - PO: "C" - KU: "R (lokal)" - hinweis: "R (lokal) = auf lokaler Ebene" - - - aktivitaet: "Kurzfristige Lösung initiieren" - LPM: "I" - PLK: "A" - PB: "R" - PO: "C" - - - aktivitaet: "Strukturierte Eskalation" - LPM: "R" - PLK: "R" - GL: "A" - - - aktivitaet: "Maßnahmen-Nachverfolgung" - LPM: "A" - PLK: "R" - PB: "C" - - # --------------------------------------------------------------------------- - # 4.4 Management von End-to-End-Geschäftsprozessen - # --------------------------------------------------------------------------- - e2e_prozess_management: - name: "Management von End-to-End-Geschäftsprozessen" - aktivitaeten: - - aktivitaet: "Prozess-Performance messen & berichten" - LPM: "I" - PLK: "C" - PB: "C" - PO: "A" - - - aktivitaet: "Prozess-Schwachstellen analysieren" - LPM: "I" - PLK: "C" - PB: "C" - PO: "R" - - - aktivitaet: "Prozess-Änderungsbedarf definieren & priorisieren" - LPM: "C" - PLK: "C" - PB: "C" - PO: "A" - - - aktivitaet: "Prozess-Änderungsprojekt beauftragen" - LPM: "C" - PO: "R" - GL: "A" - - - aktivitaet: "Prozess-Dokumentation aktuell halten" - LPM: "I" - PLK: "C" - PB: "C" - PO: "A" - KU: "R" - - # --------------------------------------------------------------------------- - # 4.5 Dezentrale Prozessarbeit - # --------------------------------------------------------------------------- - dezentrale_prozessarbeit: - name: "Dezentrale Prozessarbeit" - aktivitaeten: - - aktivitaet: "Fachprozesse modellieren" - LPM: "I" - PFM: "C" - PLK: "C" - PB: "C" - KNM: "C" - KU: "R" - - - aktivitaet: "PM-Framework lokal umsetzen" - LPM: "I" - PFM: "C" - KNM: "C" - KU: "R" - - - aktivitaet: "Lokale Optimierung initiieren" - LPM: "I" - PLK: "I" - PB: "C" - KU: "R" - - - aktivitaet: "PM-Bedarfe identifizieren" - LPM: "I" - PB: "I" - KNM: "I" - KU: "R" - -# ============================================================================= -# 5. KONFLIKTMANAGEMENT -# ============================================================================= - -bereich_5_konfliktmanagement: - name: "Konfliktmanagement (Explizite Eskalationspfade)" - - eskalationsstufen: - - stufe: 1 - name: "Stufe 1" - konflikttyp: "Methodische Differenzen" - primaer_entscheider: "LPM" - zeitrahmen: "48h" - - - stufe: 2 - name: "Stufe 2" - konflikttyp: "Ressourcenkonflikte" - primaer_entscheider: "GL (MB)" - zeitrahmen: "1 Woche" - - - stufe: 3 - name: "Stufe 3" - konflikttyp: "Strategische Divergenzen" - primaer_entscheider: "GL (VB)" - zeitrahmen: "2-4 Wochen" - - sonderfaelle: - - typ: "Fachkonflikt" - thema: "Prozess-Inhalt" - primaer_entscheider: "PO" - zeitrahmen: "72h" - - - typ: "Governance-Lücke" - thema: "Nicht lösbar binnen 4 Wochen" - primaer_entscheider: "GL (MB)" - zeitrahmen: "nach Eskalation" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Excel-Dokument. - Quelle: #06 - Prozess-Management: RACI Matrix.xlsx - - Inhalte: - - 11 Rollen definiert (LPM, PFM, PLK, PB, KNM, PO, KU, GL, PL, QS, FBL) - - 5 Hauptbereiche mit RACI-Zuordnungen - - Eskalationsstufen und Sonderfälle - autor: "DIGITOM-Projekt" +# ============================================================================= +# RACI-MATRIX: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Excel-Dokumentation +# ============================================================================= + +meta: + typ: "raci-matrix" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Management" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#06 - Prozess-Management: RACI Matrix.xlsx" + +# ============================================================================= +# RACI-LEGENDE +# ============================================================================= + +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" + + kombinationen: + "A/R": "Accountable und Responsible in einer Rolle" + "R (lokal)": "Responsible auf lokaler Ebene (Key-User-Netzwerk/Bereich)" + "C (fachlich)": "Consulted für Fachprozesse" + + hinweis_entscheidung: "Bei Unentschieden im PM-Team hat LPM Entscheidungshoheit" + +# ============================================================================= +# ROLLEN-ÜBERSICHT +# ============================================================================= + +rollen: + # Interne PM-Rollen + LPM: + name: "Leitung Prozess-Management" + fokus: "Strategische Führung, Ressourcenverantwortung" + kategorie: "intern" + + PFM: + name: "Prozess-Framework-Manager:in" + fokus: "Methodische Standards, Framework-Entwicklung" + kategorie: "intern" + + PLK: + name: "Prozesslandschafts-Koordinator:in" + fokus: "Übergreifende Prozessharmonisierung" + kategorie: "intern" + + PB: + name: "Prozess-Berater:in-Team" + fokus: "Operative Beratung und Durchführung" + kategorie: "intern" + + KNM: + name: "Key-User-Netzwerk-Manager:in" + fokus: "Dezentrale PM-Befähigung, Community-Management" + kategorie: "intern" + + # Schnittstellenrollen + PO: + name: "Process Owner" + fokus: "Fachliche Prozessverantwortung" + kategorie: "schnittstelle" + + KU: + name: "Key User" + fokus: "Lokale Prozessexpertise, erste Anlaufstelle" + kategorie: "schnittstelle" + + # Governance-Rollen + GL: + name: "Geschäftsleitung (VB/MB/AL konsolidiert)" + fokus: "Strategische Entscheidungen" + kategorie: "governance" + hinweis: "VB = Vision Board, MB = Mission Board, AL = Amtsleitung" + + # Externe Rollen + PL: + name: "Projektleitung" + fokus: "Projektspezifische Umsetzung" + kategorie: "extern" + + QS: + name: "Qualitätssicherung (ISB/DSB/ITA konsolidiert)" + fokus: "Compliance und technische Standards" + kategorie: "extern" + hinweis: "ISB = Informationssicherheitsbeauftragter, DSB = Datenschutzbeauftragter, ITA = IT-Architektur" + + FBL: + name: "Fachbereichsleitung" + fokus: "Fachliche Auftraggeber" + kategorie: "extern" + +# ============================================================================= +# 1. FRAMEWORK-GOVERNANCE +# ============================================================================= + +bereich_1_framework_governance: + name: "Framework-Governance" + + # --------------------------------------------------------------------------- + # 1.1 Framework-Entwicklung + # --------------------------------------------------------------------------- + framework_entwicklung: + name: "Framework-Entwicklung" + + kategorie_a_operative_anpassungen: + name: "Kategorie A: Operative Anpassungen" + aktivitaeten: + - aktivitaet: "Methoden-Feintuning" + LPM: "I" + PFM: "R" + PLK: "C" + PB: "C" + PO: "I" + GL: "-" + KNM: "I" + KU: "I" + PM_Team: "A/R" + + - aktivitaet: "Template-Updates" + LPM: "I" + PFM: "R" + PLK: "C" + PB: "C" + PO: "I" + GL: "-" + KNM: "I" + KU: "I" + PM_Team: "A/R" + + - aktivitaet: "Dokumentation aktualisieren" + LPM: "I" + PFM: "R" + PLK: "C" + PB: "C" + PO: "I" + GL: "-" + KNM: "I" + KU: "I" + PM_Team: "A/R" + + kategorie_b_taktische_erweiterungen: + name: "Kategorie B: Taktische Erweiterungen" + aktivitaeten: + - aktivitaet: "Neue Methoden entwickeln" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C" + GL: "I" + KNM: "C" + KU: "I" + + - aktivitaet: "Standards erweitern" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C" + GL: "I" + KNM: "C" + KU: "I" + + - aktivitaet: "Tool-Integration" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + PO: "I" + GL: "I" + QS: "C" + + kategorie_c_strategische_transformationen: + name: "Kategorie C: Strategische Transformationen" + aktivitaeten: + - aktivitaet: "Framework-Neuausrichtung" + LPM: "R" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C" + GL: "A" + KNM: "C" + KU: "I" + + - aktivitaet: "Paradigmenwechsel" + LPM: "R" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C" + GL: "A" + KNM: "C" + KU: "I" + + # --------------------------------------------------------------------------- + # 1.2 Framework-Kommunikation + # --------------------------------------------------------------------------- + framework_kommunikation: + name: "Framework-Kommunikation" + aktivitaeten: + - aktivitaet: "Schulungskonzepte" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + KNM: "R" + KU: "I" + + - aktivitaet: "Updates kommunizieren" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "R" + KNM: "R" + KU: "R (lokal)" + hinweis: "R (lokal) = für KU-Netzwerk/Bereich" + + - aktivitaet: "Framework-Portal pflegen" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + KNM: "C" + +# ============================================================================= +# 2. LEISTUNGSERBRINGUNG +# ============================================================================= + +bereich_2_leistungserbringung: + name: "Leistungserbringung" + + # --------------------------------------------------------------------------- + # 2.1 Standard Leistungen + # --------------------------------------------------------------------------- + standard_leistungen: + name: "Standard Leistungen (Regelgeschäft)" + aktivitaeten: + - aktivitaet: "Leistungsanfrage annehmen" + LPM: "I" + PFM: "I" + PLK: "I" + PB: "R" + PO: "C" + FBL: "C" + + - aktivitaet: "Aufwand schätzen" + LPM: "I" + PFM: "C" + PLK: "C" + PB: "R" + PO: "I" + + - aktivitaet: "Leistung durchführen" + LPM: "I" + PFM: "C" + PLK: "C" + PB: "R" + PO: "C" + KU: "C" + + - aktivitaet: "Qualität sicherstellen" + LPM: "A" + PFM: "C" + PLK: "C" + PB: "R" + PO: "C" + + # --------------------------------------------------------------------------- + # 2.2 Projekt Leistungen + # --------------------------------------------------------------------------- + projekt_leistungen: + name: "Projekt Leistungen (Geplante Projekte)" + hinweis: "Bei kritischen Konflikten: Empfehlung an MB, finale Entscheidung durch MB" + aktivitaeten: + - aktivitaet: "Projektantrag bewerten" + LPM: "R" + PFM: "C" + PLK: "C" + PB: "C" + PO: "C" + GL: "A" + PL: "R" + + - aktivitaet: "Ressourcen zuweisen" + LPM: "A" + PFM: "C" + PLK: "C" + PB: "I" + GL: "I" + PL: "C" + + - aktivitaet: "PM-Integration planen" + LPM: "A" + PFM: "C" + PLK: "R" + PB: "R" + PO: "C" + PL: "C" + + - aktivitaet: "Projekt begleiten" + LPM: "I" + PFM: "C" + PLK: "C" + PB: "R" + PO: "C" + PL: "A" + + # --------------------------------------------------------------------------- + # 2.3 Strategische Leistungen + # --------------------------------------------------------------------------- + strategische_leistungen: + name: "Strategische Leistungen (Transformationsinitiativen)" + aktivitaeten: + - aktivitaet: "Initiative konzipieren" + LPM: "R" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C" + GL: "I" + + - aktivitaet: "Business Case erstellen" + LPM: "R" + PFM: "R" + PLK: "C" + PB: "C" + GL: "I" + + - aktivitaet: "Board-Freigabe einholen" + LPM: "R" + PFM: "C" + PLK: "C" + GL: "A" + + - aktivitaet: "Umsetzung steuern" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "R" + PO: "C" + GL: "I" + + # --------------------------------------------------------------------------- + # 2.4 Krisen-Leistungen + # --------------------------------------------------------------------------- + krisen_leistungen: + name: "Krisen-Leistungen (Krisensituationen)" + aktivitaeten: + - aktivitaet: "Notfall klassifizieren" + LPM: "A" + PFM: "C" + PLK: "C" + PB: "R" + GL: "I" + + - aktivitaet: "Ressourcen mobilisieren" + LPM: "A" + PFM: "C" + PLK: "C" + PB: "R" + GL: "I" + + - aktivitaet: "Krisenunterstützung" + LPM: "A" + PFM: "C" + PLK: "C" + PB: "R" + PO: "C" + FBL: "C" + + - aktivitaet: "Lessons Learned" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "R" + PO: "C" + GL: "I" + + # --------------------------------------------------------------------------- + # 2.5 Key-User-Management + # --------------------------------------------------------------------------- + key_user_management: + name: "Key-User-Management" + aktivitaeten: + - aktivitaet: "KU identifizieren" + LPM: "A" + KNM: "R" + PB: "C" + FBL: "C" + + - aktivitaet: "KU qualifizieren" + LPM: "A" + KNM: "R" + PFM: "C" + PB: "C" + + - aktivitaet: "KU-Netzwerk betreuen" + LPM: "A" + KNM: "R" + PB: "C" + KU: "C" + + - aktivitaet: "Best Practices teilen" + LPM: "I" + KNM: "R" + PB: "C" + KU: "R" + + - aktivitaet: "Lokale PM-Unterstützung" + LPM: "I" + KNM: "C" + PB: "C" + KU: "R" + +# ============================================================================= +# 3. QUALITÄTSSICHERUNG +# ============================================================================= + +bereich_3_qualitaetssicherung: + name: "Qualitätssicherung" + + # --------------------------------------------------------------------------- + # 3.1 Process Owner Quality Gate + # --------------------------------------------------------------------------- + process_owner_quality_gate: + name: "Process Owner Quality Gate" + aktivitaeten: + - aktivitaet: "Fachliche Konsistenz prüfen" + LPM: "I" + PLK: "C" + PB: "C" + PO: "R" + PL: "C" + + - aktivitaet: "Schnittstellen validieren" + LPM: "I" + PLK: "R" + PB: "C" + PO: "A" + PL: "C" + + - aktivitaet: "Implementierbarkeit bewerten" + LPM: "I" + PLK: "C" + PB: "C" + PO: "R" + PL: "C" + + - aktivitaet: "Gate-Entscheidung" + LPM: "I" + PLK: "C" + PO: "A" + PL: "I" + + # --------------------------------------------------------------------------- + # 3.2 PM Quality Gate + # --------------------------------------------------------------------------- + pm_quality_gate: + name: "PM Quality Gate" + aktivitaeten: + - aktivitaet: "Methodische Konformität" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + PO: "I" + + - aktivitaet: "Prozesslandschafts-Fit" + LPM: "A" + PFM: "C" + PLK: "R" + PB: "C" + PO: "C" + + - aktivitaet: "Dokumentationsqualität" + LPM: "A" + PFM: "R" + PLK: "C" + PB: "C" + PO: "C (fachlich)" + KU: "C (fachlich)" + hinweis: "C (fachlich) = für Fachprozesse" + +# ============================================================================= +# 4. GOVERNANCE-INTEGRATION +# ============================================================================= + +bereich_4_governance_integration: + name: "Governance-Integration" + + # --------------------------------------------------------------------------- + # 4.1 Strategische Ausrichtung + # --------------------------------------------------------------------------- + strategische_ausrichtung: + name: "Strategische Ausrichtung" + aktivitaeten: + - aktivitaet: "Jahresplanung PM" + LPM: "R" + PFM: "C" + PLK: "C" + PB: "C" + GL: "A" + KNM: "C" + + - aktivitaet: "Strategische Reviews" + LPM: "R" + PFM: "C" + PLK: "C" + PB: "C" + GL: "A" + + - aktivitaet: "Ressourcenrahmen" + LPM: "R" + PFM: "C" + PLK: "C" + GL: "A" + + # --------------------------------------------------------------------------- + # 4.2 Operative Koordination + # --------------------------------------------------------------------------- + operative_koordination: + name: "Operative Koordination" + aktivitaeten: + - aktivitaet: "Wöchentliche Teamrunde" + LPM: "A" + PFM: "R" + PLK: "R" + PB: "R" + KNM: "R" + + - aktivitaet: "Monatliche Stakeholder" + LPM: "A" + PFM: "C" + PLK: "R" + PB: "C" + PO: "C" + KNM: "C" + + - aktivitaet: "Quartals-Review" + LPM: "A" + PFM: "R" + PLK: "R" + PB: "C" + GL: "I" + + # --------------------------------------------------------------------------- + # 4.3 Governance-Lücken-Management + # --------------------------------------------------------------------------- + governance_luecken_management: + name: "Governance-Lücken-Management" + aktivitaeten: + - aktivitaet: "Lücke identifizieren" + LPM: "I" + PFM: "C" + PLK: "R" + PB: "C" + PO: "C" + KU: "R (lokal)" + hinweis: "R (lokal) = auf lokaler Ebene" + + - aktivitaet: "Kurzfristige Lösung initiieren" + LPM: "I" + PLK: "A" + PB: "R" + PO: "C" + + - aktivitaet: "Strukturierte Eskalation" + LPM: "R" + PLK: "R" + GL: "A" + + - aktivitaet: "Maßnahmen-Nachverfolgung" + LPM: "A" + PLK: "R" + PB: "C" + + # --------------------------------------------------------------------------- + # 4.4 Management von End-to-End-Geschäftsprozessen + # --------------------------------------------------------------------------- + e2e_prozess_management: + name: "Management von End-to-End-Geschäftsprozessen" + aktivitaeten: + - aktivitaet: "Prozess-Performance messen & berichten" + LPM: "I" + PLK: "C" + PB: "C" + PO: "A" + + - aktivitaet: "Prozess-Schwachstellen analysieren" + LPM: "I" + PLK: "C" + PB: "C" + PO: "R" + + - aktivitaet: "Prozess-Änderungsbedarf definieren & priorisieren" + LPM: "C" + PLK: "C" + PB: "C" + PO: "A" + + - aktivitaet: "Prozess-Änderungsprojekt beauftragen" + LPM: "C" + PO: "R" + GL: "A" + + - aktivitaet: "Prozess-Dokumentation aktuell halten" + LPM: "I" + PLK: "C" + PB: "C" + PO: "A" + KU: "R" + + # --------------------------------------------------------------------------- + # 4.5 Dezentrale Prozessarbeit + # --------------------------------------------------------------------------- + dezentrale_prozessarbeit: + name: "Dezentrale Prozessarbeit" + aktivitaeten: + - aktivitaet: "Fachprozesse modellieren" + LPM: "I" + PFM: "C" + PLK: "C" + PB: "C" + KNM: "C" + KU: "R" + + - aktivitaet: "PM-Framework lokal umsetzen" + LPM: "I" + PFM: "C" + KNM: "C" + KU: "R" + + - aktivitaet: "Lokale Optimierung initiieren" + LPM: "I" + PLK: "I" + PB: "C" + KU: "R" + + - aktivitaet: "PM-Bedarfe identifizieren" + LPM: "I" + PB: "I" + KNM: "I" + KU: "R" + +# ============================================================================= +# 5. KONFLIKTMANAGEMENT +# ============================================================================= + +bereich_5_konfliktmanagement: + name: "Konfliktmanagement (Explizite Eskalationspfade)" + + eskalationsstufen: + - stufe: 1 + name: "Stufe 1" + konflikttyp: "Methodische Differenzen" + primaer_entscheider: "LPM" + zeitrahmen: "48h" + + - stufe: 2 + name: "Stufe 2" + konflikttyp: "Ressourcenkonflikte" + primaer_entscheider: "GL (MB)" + zeitrahmen: "1 Woche" + + - stufe: 3 + name: "Stufe 3" + konflikttyp: "Strategische Divergenzen" + primaer_entscheider: "GL (VB)" + zeitrahmen: "2-4 Wochen" + + sonderfaelle: + - typ: "Fachkonflikt" + thema: "Prozess-Inhalt" + primaer_entscheider: "PO" + zeitrahmen: "72h" + + - typ: "Governance-Lücke" + thema: "Nicht lösbar binnen 4 Wochen" + primaer_entscheider: "GL (MB)" + zeitrahmen: "nach Eskalation" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Excel-Dokument. + Quelle: #06 - Prozess-Management: RACI Matrix.xlsx + + Inhalte: + - 11 Rollen definiert (LPM, PFM, PLK, PB, KNM, PO, KU, GL, PL, QS, FBL) + - 5 Hauptbereiche mit RACI-Zuordnungen + - Eskalationsstufen und Sonderfälle + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml b/#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml index 79845d7..883a76f 100644 --- a/#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml +++ b/#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml @@ -1,263 +1,263 @@ -# ============================================================================= -# KONZEPTRAHMEN: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "konzeptrahmen" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx" - -# ============================================================================= -# 1. DIE HERAUSFORDERUNG -# ============================================================================= - -herausforderung: - titel: "Zwischen Standardisierung und Befähigung" - - beschreibung: | - Moderne Verwaltungsorganisationen stehen vor einem fundamentalen Dilemma: - Sie müssen gleichzeitig Stabilität gewährleisten und Agilität ermöglichen. - Im Kontext des DIGITOM manifestiert sich diese Spannung besonders deutlich - in der Frage, wie Prozesse gestaltet und gesteuert werden sollen. - - problemstellung: | - Die traditionelle Antwort - zentrale Vorgaben und strikte Kontrolle - - greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig - führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz. - - ansatz: | - Die Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem - Spannungsfeld. - -# ============================================================================= -# 2. DIE LÖSUNG -# ============================================================================= - -loesung: - titel: "Eine mehrdimensionale Organisationsarchitektur" - - beschreibung: | - Statt einer monolithischen Struktur wurde für das Prozess-Management - eine vielschichtige Architektur entwickelt. Diese erlaubt es, verschiedene - organisationale Bedürfnisse gleichzeitig zu adressieren. - - spannungsfelder: - - dimension_1: "Strategische Steuerung" - dimension_2: "Operative Flexibilität" - - - dimension_1: "Methodische Standards" - dimension_2: "Fachliche Autonomie" - - - dimension_1: "Zentrale Kompetenz" - dimension_2: "Dezentrale Befähigung" - - prinzip: | - Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv - genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige - Verbesserung. - -# ============================================================================= -# 3. DOKUMENTATIONSARCHITEKTUR -# ============================================================================= - -dokumentationsarchitektur: - titel: "Fünf Perspektiven, ein System" - - beschreibung: | - Die Komplexität dieser Organisationsform spiegelt sich in der bewusst - gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das - Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen eigenen Zweck. - - dokumente: - - id: "DOK-1" - name: "Funktionsbeschreibung" - untertitel: "Legitimation und Mandat" - kernfrage: "Was darf und soll die PM-Funktion?" - beschreibung: | - Schafft die formale Grundlage. Definiert den Verantwortungsbereich, - grenzt Zuständigkeiten ab und legitimiert das Handeln der PM-Funktion - innerhalb der Gesamtorganisation. - metapher: "Die 'Verfassung' der Funktion - ihre grundlegenden Rechte und Pflichten" - pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml" - - - id: "DOK-2" - name: "Leistungs-Canvas" - untertitel: "Der Nutzennachweis" - kernfrage: "Welchen konkreten Mehrwert schafft die PM-Funktion?" - beschreibung: | - Zeigt, was tatsächlich geleistet wird. Nimmt konsequent die Perspektive - der Nutzer:innen ein und macht sichtbar, wie aus Aktivitäten konkreter - Nutzen entsteht. - format: "Canvas-Format ermöglicht ganzheitliche Betrachtung aller relevanten Elemente" - pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" - - - id: "DOK-3" - name: "Rollenmodell" - untertitel: "Die Arbeitsorganisation" - kernfrage: "Wer trägt welche Verantwortung?" - beschreibung: | - Elf differenzierte Rollen ermöglichen es, verschiedene Aspekte der - PM-Arbeit klar zu verteilen. Von der strategischen Führung über - methodische Expertise bis zur operativen Beratung. - mehrwert: "Verhindert Interessenskonflikte und schafft Klarheit in der Zusammenarbeit" - pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml" - - - id: "DOK-4" - name: "Governance-Modell" - untertitel: "Die Spielregeln" - kernfrage: "Wie werden Entscheidungen getroffen?" - beschreibung: | - Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Definiert - differenzierte Entscheidungswege für verschiedene Leistungstypen. - design: "Eskalationspfade sind klar definiert, aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden" - pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" - - - id: "DOK-5" - name: "RACI-Matrix" - untertitel: "Das Navigationsinstrument" - kernfrage: "Wer ist wofür konkret zuständig?" - beschreibung: | - Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf - einen Blick sichtbar. Dient als praktisches Nachschlagewerk im - Arbeitsalltag. - mehrwert: "Verhindert Zuständigkeitskonflikte durch klare Rollenzuweisungen" - pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" - -# ============================================================================= -# 4. SYSTEMISCHE ZUSAMMENHÄNGE -# ============================================================================= - -systemische_zusammenhaenge: - beschreibung: | - Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden - ein integriertes System. Jedes Element verstärkt und ergänzt die anderen. - Gemeinsam schaffen sie ein robustes, aber flexibles Organisationsdesign. - - verknuepfungen: - - von: "Funktionsbeschreibung" - zu: "Leistungs-Canvas" - beziehung: "legitimiert die beschriebenen Leistungen" - - - von: "Rollenmodell" - zu: "Leistungserbringung" - beziehung: "operationalisiert durch klare Verantwortlichkeiten" - - - von: "Governance-Modell" - zu: "Rollen" - beziehung: "regelt, wie diese zusammenarbeiten und Entscheidungen treffen" - - - von: "RACI-Matrix" - zu: "Zusammenarbeit" - beziehung: "macht transparent und nachvollziehbar" - -# ============================================================================= -# 5. NAVIGATIONSHINWEISE -# ============================================================================= - -navigationshinweise: - beschreibung: | - Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche - Einstiegspunkte in die Dokumentation. - - zielgruppen: - - zielgruppe: "Führungskräfte und Entscheidungsträger:innen" - einstieg: "Governance-Modell" - zweck: "Entscheidungswege und Steuerungsmechanismen verstehen" - dann: "Leistungs-Canvas für den strategischen Nutzen" - - - zielgruppe: "Operative Teams und Fachbereiche" - einstieg: "Leistungs-Canvas" - zweck: "Verfügbare Services und Zugangswege erkunden" - dann: "RACI-Matrix zeigt konkrete Ansprechpersonen" - - - zielgruppe: "Neue Mitarbeitende der PM-Funktion" - einstieg: "Funktionsbeschreibung" - zweck: "Grundlegendes Verständnis aufbauen" - dann: "Rollenmodell für die eigene Verortung im Team" - - - zielgruppe: "Projektleitungen" - einstieg: "Governance-Modell (Abschnitt projektzentrierte Prozessgestaltung)" - zweck: "PM-Integration in Projekten verstehen" - dann: "RACI-Matrix für konkrete Abstimmungswege" - -# ============================================================================= -# 6. DIE ZENTRALE BALANCE -# ============================================================================= - -zentrale_balance: - titel: "Standardisierung ermöglichen, Autonomie bewahren" - - beschreibung: | - Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung. - Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen - fachliche Vielfalt möglich bleibt. - - dimensionen: - - dimension_1: "Methodische Standards" - dimension_2: "Fachliche Freiheit" - - - dimension_1: "Zentrale Governance" - dimension_2: "Dezentrale Ausführung" - - - dimension_1: "Verbindliche Frameworks" - dimension_2: "Situative Anpassung" - - leitsatz: | - Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen, - ohne die notwendige Flexibilität zu ersticken. - -# ============================================================================= -# 7. AUSBLICK -# ============================================================================= - -ausblick: - titel: "Ein lernendes System" - - beschreibung: | - Die hier dokumentierte Organisationsform ist kein statisches Konstrukt. - Sie ist darauf angelegt, sich weiterzuentwickeln - durch Feedback aus - der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse. - - anpassungsfaehigkeit: | - Die mehrdimensionale Dokumentation ermöglicht gezielte Anpassungen: - Einzelne Elemente können weiterentwickelt werden, ohne das Gesamtsystem - zu destabilisieren. - - vision: | - So entsteht eine Organisation, die gleichzeitig stabil und adaptiv ist - - genau das, was moderne Verwaltung braucht. - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx - - Inhalte: - - Herausforderung: Standardisierung vs. Befähigung - - Lösung: Mehrdimensionale Organisationsarchitektur - - Dokumentationsarchitektur (5 Dokumente) - - Systemische Zusammenhänge - - Navigationshinweise nach Zielgruppen - - Zentrale Balance - - Ausblick: Lernendes System - autor: "DIGITOM-Projekt" +# ============================================================================= +# KONZEPTRAHMEN: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "konzeptrahmen" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Management" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx" + +# ============================================================================= +# 1. DIE HERAUSFORDERUNG +# ============================================================================= + +herausforderung: + titel: "Zwischen Standardisierung und Befähigung" + + beschreibung: | + Moderne Verwaltungsorganisationen stehen vor einem fundamentalen Dilemma: + Sie müssen gleichzeitig Stabilität gewährleisten und Agilität ermöglichen. + Im Kontext des DIGITOM manifestiert sich diese Spannung besonders deutlich + in der Frage, wie Prozesse gestaltet und gesteuert werden sollen. + + problemstellung: | + Die traditionelle Antwort - zentrale Vorgaben und strikte Kontrolle - + greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig + führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz. + + ansatz: | + Die Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem + Spannungsfeld. + +# ============================================================================= +# 2. DIE LÖSUNG +# ============================================================================= + +loesung: + titel: "Eine mehrdimensionale Organisationsarchitektur" + + beschreibung: | + Statt einer monolithischen Struktur wurde für das Prozess-Management + eine vielschichtige Architektur entwickelt. Diese erlaubt es, verschiedene + organisationale Bedürfnisse gleichzeitig zu adressieren. + + spannungsfelder: + - dimension_1: "Strategische Steuerung" + dimension_2: "Operative Flexibilität" + + - dimension_1: "Methodische Standards" + dimension_2: "Fachliche Autonomie" + + - dimension_1: "Zentrale Kompetenz" + dimension_2: "Dezentrale Befähigung" + + prinzip: | + Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv + genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige + Verbesserung. + +# ============================================================================= +# 3. DOKUMENTATIONSARCHITEKTUR +# ============================================================================= + +dokumentationsarchitektur: + titel: "Fünf Perspektiven, ein System" + + beschreibung: | + Die Komplexität dieser Organisationsform spiegelt sich in der bewusst + gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das + Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen eigenen Zweck. + + dokumente: + - id: "DOK-1" + name: "Funktionsbeschreibung" + untertitel: "Legitimation und Mandat" + kernfrage: "Was darf und soll die PM-Funktion?" + beschreibung: | + Schafft die formale Grundlage. Definiert den Verantwortungsbereich, + grenzt Zuständigkeiten ab und legitimiert das Handeln der PM-Funktion + innerhalb der Gesamtorganisation. + metapher: "Die 'Verfassung' der Funktion - ihre grundlegenden Rechte und Pflichten" + pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml" + + - id: "DOK-2" + name: "Leistungs-Canvas" + untertitel: "Der Nutzennachweis" + kernfrage: "Welchen konkreten Mehrwert schafft die PM-Funktion?" + beschreibung: | + Zeigt, was tatsächlich geleistet wird. Nimmt konsequent die Perspektive + der Nutzer:innen ein und macht sichtbar, wie aus Aktivitäten konkreter + Nutzen entsteht. + format: "Canvas-Format ermöglicht ganzheitliche Betrachtung aller relevanten Elemente" + pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" + + - id: "DOK-3" + name: "Rollenmodell" + untertitel: "Die Arbeitsorganisation" + kernfrage: "Wer trägt welche Verantwortung?" + beschreibung: | + Elf differenzierte Rollen ermöglichen es, verschiedene Aspekte der + PM-Arbeit klar zu verteilen. Von der strategischen Führung über + methodische Expertise bis zur operativen Beratung. + mehrwert: "Verhindert Interessenskonflikte und schafft Klarheit in der Zusammenarbeit" + pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml" + + - id: "DOK-4" + name: "Governance-Modell" + untertitel: "Die Spielregeln" + kernfrage: "Wie werden Entscheidungen getroffen?" + beschreibung: | + Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Definiert + differenzierte Entscheidungswege für verschiedene Leistungstypen. + design: "Eskalationspfade sind klar definiert, aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden" + pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" + + - id: "DOK-5" + name: "RACI-Matrix" + untertitel: "Das Navigationsinstrument" + kernfrage: "Wer ist wofür konkret zuständig?" + beschreibung: | + Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf + einen Blick sichtbar. Dient als praktisches Nachschlagewerk im + Arbeitsalltag. + mehrwert: "Verhindert Zuständigkeitskonflikte durch klare Rollenzuweisungen" + pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" + +# ============================================================================= +# 4. SYSTEMISCHE ZUSAMMENHÄNGE +# ============================================================================= + +systemische_zusammenhaenge: + beschreibung: | + Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden + ein integriertes System. Jedes Element verstärkt und ergänzt die anderen. + Gemeinsam schaffen sie ein robustes, aber flexibles Organisationsdesign. + + verknuepfungen: + - von: "Funktionsbeschreibung" + zu: "Leistungs-Canvas" + beziehung: "legitimiert die beschriebenen Leistungen" + + - von: "Rollenmodell" + zu: "Leistungserbringung" + beziehung: "operationalisiert durch klare Verantwortlichkeiten" + + - von: "Governance-Modell" + zu: "Rollen" + beziehung: "regelt, wie diese zusammenarbeiten und Entscheidungen treffen" + + - von: "RACI-Matrix" + zu: "Zusammenarbeit" + beziehung: "macht transparent und nachvollziehbar" + +# ============================================================================= +# 5. NAVIGATIONSHINWEISE +# ============================================================================= + +navigationshinweise: + beschreibung: | + Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche + Einstiegspunkte in die Dokumentation. + + zielgruppen: + - zielgruppe: "Führungskräfte und Entscheidungsträger:innen" + einstieg: "Governance-Modell" + zweck: "Entscheidungswege und Steuerungsmechanismen verstehen" + dann: "Leistungs-Canvas für den strategischen Nutzen" + + - zielgruppe: "Operative Teams und Fachbereiche" + einstieg: "Leistungs-Canvas" + zweck: "Verfügbare Services und Zugangswege erkunden" + dann: "RACI-Matrix zeigt konkrete Ansprechpersonen" + + - zielgruppe: "Neue Mitarbeitende der PM-Funktion" + einstieg: "Funktionsbeschreibung" + zweck: "Grundlegendes Verständnis aufbauen" + dann: "Rollenmodell für die eigene Verortung im Team" + + - zielgruppe: "Projektleitungen" + einstieg: "Governance-Modell (Abschnitt projektzentrierte Prozessgestaltung)" + zweck: "PM-Integration in Projekten verstehen" + dann: "RACI-Matrix für konkrete Abstimmungswege" + +# ============================================================================= +# 6. DIE ZENTRALE BALANCE +# ============================================================================= + +zentrale_balance: + titel: "Standardisierung ermöglichen, Autonomie bewahren" + + beschreibung: | + Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung. + Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen + fachliche Vielfalt möglich bleibt. + + dimensionen: + - dimension_1: "Methodische Standards" + dimension_2: "Fachliche Freiheit" + + - dimension_1: "Zentrale Governance" + dimension_2: "Dezentrale Ausführung" + + - dimension_1: "Verbindliche Frameworks" + dimension_2: "Situative Anpassung" + + leitsatz: | + Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen, + ohne die notwendige Flexibilität zu ersticken. + +# ============================================================================= +# 7. AUSBLICK +# ============================================================================= + +ausblick: + titel: "Ein lernendes System" + + beschreibung: | + Die hier dokumentierte Organisationsform ist kein statisches Konstrukt. + Sie ist darauf angelegt, sich weiterzuentwickeln - durch Feedback aus + der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse. + + anpassungsfaehigkeit: | + Die mehrdimensionale Dokumentation ermöglicht gezielte Anpassungen: + Einzelne Elemente können weiterentwickelt werden, ohne das Gesamtsystem + zu destabilisieren. + + vision: | + So entsteht eine Organisation, die gleichzeitig stabil und adaptiv ist - + genau das, was moderne Verwaltung braucht. + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + Quelle: #01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx + + Inhalte: + - Herausforderung: Standardisierung vs. Befähigung + - Lösung: Mehrdimensionale Organisationsarchitektur + - Dokumentationsarchitektur (5 Dokumente) + - Systemische Zusammenhänge + - Navigationshinweise nach Zielgruppen + - Zentrale Balance + - Ausblick: Lernendes System + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml b/#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml index 9ae1ce0..d32c076 100644 --- a/#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml +++ b/#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml @@ -1,481 +1,481 @@ -# ============================================================================= -# LEISTUNGS-CANVAS: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "leistungs-canvas" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#03.1 - Prozess-Management: Leistungs-Canvas.docx" - -# ============================================================================= -# 1. EINFÜHRUNG -# ============================================================================= - -einfuehrung: - warum_ein_leistungs_canvas: | - Das Leistungs-Canvas betrachtet die Prozess-Management-Funktion konsequent - aus der Perspektive ihrer Nutzer:innen. Diese Perspektivverschiebung macht - sichtbar, was in traditionellen Funktionsbeschreibungen oft untergeht: - Wie entsteht konkret Nutzen? Welche Beziehungen ermöglichen wirksame - Zusammenarbeit? Über welche Wege werden Leistungen tatsächlich zugänglich? - - leitfragen: - - "Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?" - - "Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?" - - "Welche Voraussetzungen müssen dafür geschaffen werden?" - - funktionen_des_canvas: - - "Schafft Klarheit über das Leistungsportfolio" - - "Macht Zusammenhänge zwischen verschiedenen Elementen sichtbar" - - "Dient als Kommunikationsinstrument zwischen PM-Funktion und Nutzer:innen" - - "Steuerungsinstrument für Ressourcen-Investitionen" - -# ============================================================================= -# 2. CANVAS-LOGIK -# ============================================================================= - -canvas_logik: - beschreibung: | - Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander - verbundene Bausteine. Die rechte Seite fokussiert auf die Außenperspektive, - die linke Seite richtet den Blick nach innen. Im Zentrum steht das - Wertversprechen als verbindendes Element. - - bausteine: - rechte_seite_aussen: - - "Nutzendensegmente" - - "Nutzendenbeziehung" - - "Kanäle" - zentrum: - - "Wertversprechen" - linke_seite_innen: - - "Schlüsselaktivitäten" - - "Schlüsselressourcen" - - "Schlüsselpartner" - -# ============================================================================= -# 3. CLUSTER A: FÜR WEN DIE PM-FUNKTION DA IST -# ============================================================================= - -cluster_a_fuer_wen: - name: "Für wen die PM-Funktion da ist" - - # --------------------------------------------------------------------------- - # 3.1 Nutzendensegmente - # --------------------------------------------------------------------------- - nutzendensegmente: - beschreibung: | - Die verschiedenen internen Zielgruppen, für die die PM-Funktion Leistungen - erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen und Arbeitsweisen. - - segmente: - - segment: "Management-Gremien" - beispiele: "Vision Board, Mission Board" - bedarfe: - - "Transparenz über die Prozesslandschaft" - - "Governance-Berichte" - - "Einheitliche Standards zur besseren Steuerung" - - "Strategische Ausrichtung der Organisation" - - - segment: "Abteilungsleitungen" - bedarfe: - - "Prozessperspektive für bessere Ressourcenplanung" - - "Steuerung ihrer Bereiche" - - "Fundierte Entscheidungen bei bereichsübergreifenden Themen" - - - segment: "Process Owner der Teilprozesse" - beispiele: "SHM, DPM, PPM, SPM" - bedarfe: - - "End-to-End-Verantwortung für ihre jeweiligen Teilprozesse" - - "Methodische Unterstützung zur Prozessoptimierung" - - "Unterstützung bei Prozesssteuerung" - - - segment: "Fachbereiche und Teams mit Key-Usern" - bedarfe: - - "Methodische Unterstützung" - - "Befähigung und Standards" - - "Eigenständige Dokumentation und Verbesserung fachspezifischer Prozesse" - - - segment: "Projekt- und Programmorganisationen" - bedarfe: - - "Einheitliche Prozessvorgaben" - - "Methodische Beratung" - - "Sicherstellung der Framework-Compliance in Projekten" - - # --------------------------------------------------------------------------- - # 3.2 Nutzendenbeziehung - # --------------------------------------------------------------------------- - nutzendenbeziehung: - beschreibung: | - Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren - Nutzer:innen. Sie definiert das "Wie" der Interaktion. - - beziehungstypen: - - typ: "Partnerschaftliche Zusammenarbeit & Co-Kreation" - beschreibung: | - Aufbau von Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen. - Key-User als zentrale Partner:innen eng in Entwicklung und Umsetzung - von Prozesslösungen eingebunden. - - - typ: "Persönliche Beratung & Dedizierte Unterstützung" - beschreibung: | - Direkte Beratung und Coaching, insbesondere bei komplexen - Prozessherausforderungen oder strategischen Initiativen. - Besonderer Fokus auf Befähigung der Key-User als Multiplikator:innen. - - - typ: "Befähigungsorientierte Begleitung" - beschreibung: | - Konsequente Fokussierung auf Befähigung statt Ausführung. - Ermächtigung der Nutzenden, ihre Prozesse eigenständig zu managen. - Key-User als erste Ansprechpartner:innen in ihren Bereichen. - - - typ: "Community Building & Facilitation" - beschreibung: | - Aktive Förderung und Pflege des Key-User-Netzwerks als zentrales - Element für gemeinsames Lernen, Erfahrungsaustausch und kontinuierliche - Verbesserung über Abteilungsgrenzen hinweg. - - - typ: "Proaktive Impulsgebung" - beschreibung: | - Agieren als Impulsgeber durch Vorstellung neuer Methoden, Best Practices - und Anregung des Prozessdenkens. Key-User als Multiplikator:innen - tragen diese Impulse in ihre Fachbereiche. - - - typ: "Governance-basierte Interaktion" - beschreibung: | - Formelles Reporting, strategische Abstimmung und Eskalationsmanagement - mit Vision/Mission Boards. Regelmäßige Berichte über Entwicklung der - dezentralen Prozesskompetenzen. - - # --------------------------------------------------------------------------- - # 3.3 Kanäle - # --------------------------------------------------------------------------- - kanaele: - beschreibung: | - Die Wege und Formate, über die PM-Leistungen zugänglich werden. - Die Vielfalt der Kanäle sichert niedrigschwelligen Zugang und ermöglicht - situationsgerechte Unterstützung. - - kategorien: - direkte_interaktion: - name: "Direkte Interaktions- & Befähigungskanäle" - kanaele: - - name: "Workshops und Schulungen" - beschreibung: "Vermittlung von Wissen, Methoden und Werkzeugkompetenzen" - - name: "Beratungsgespräche und Coaching" - beschreibung: "Maßgeschneiderte Unterstützung (individuell oder Team)" - - name: "Moderation von Prozess-Workshops" - beschreibung: "Kollaborative Prozessarbeit bei komplexen/bereichsübergreifenden Prozessen" - - name: "Ticketsystem" - beschreibung: "Formaler Kanal für Anfragen mit automatischem Routing ans PM-Team" - - self_service: - name: "Self-Service & digitale Lernkanäle" - kanaele: - - name: "Zentrale Wissensplattform (Confluence)" - beschreibung: "PM-Framework, Methodenhandbuch, Templates, Prozessregister, FAQs" - - name: "KI-gestützter PM-Assistent" - beschreibung: "Interaktiver Dialog für Prozessfragen und kontextspezifische Antworten" - - name: "Prozessvisualisierungs-Tool (Picture Prozess Plattform)" - beschreibung: "Eigenständige Arbeit mit der Prozesslandschaft" - - name: "E-Learning-Module" - beschreibung: "Strukturierte Lernpfade für selbstgesteuertes Lernen" - - community: - name: "Community- & Kommunikationskanäle" - kanaele: - - name: "Key-User-Netzwerktreffen und Communities of Practice" - beschreibung: "Regelmäßiger Erfahrungsaustausch und kollektives Lernen" - - name: "Informationsveranstaltungen und Newsletter" - beschreibung: "Framework-Updates und relevante PM-Informationen" - - name: "DigiLog Podcast-Format" - beschreibung: "Einsichten und Erfolgsgeschichten zur Förderung des Prozessdenkens" - -# ============================================================================= -# 4. CLUSTER B: WAS DIE PM-FUNKTION BIETET -# ============================================================================= - -cluster_b_was: - name: "Was die PM-Funktion bietet" - - wertversprechen: - beschreibung: | - Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen - Zielgruppen schafft. Es ist das zentrale Element, das alle anderen - Bausteine ausrichtet. - - fuer_strategische_gremien: - - nutzen: "Strategische Prozess-Governance und Transparenz" - beschreibung: "Konsistente, strategisch ausgerichtete Prozesslandschaft" - - nutzen: "Messbare Verbesserung und KPI-basierte Steuerung" - beschreibung: "Faktenbasierte Bewertung von Prozessleistung und Nachweis von Optimierungserfolgen" - - nutzen: "Entscheidungsunterstützung und Risikominimierung" - beschreibung: "Konzepte zur Weiterentwicklung des Operating Models und proaktive Meldung von Risiken" - - nutzen: "Skalierbare Prozessstrukturen" - beschreibung: "Ermöglichung von Organisationswachstum und systematische Erschließung von Automatisierungspotenzialen" - - fuer_fachbereiche_und_teams: - - nutzen: "Einheitliches Prozessmanagement-Framework" - beschreibung: "Verbindliche Standards, Methoden, Werkzeuge und Templates" - - nutzen: "Methodische Beratung und Unterstützung" - beschreibung: "Von der Erstaufnahme bis zur Automatisierung" - - nutzen: "Systematische Befähigung zur Selbsthilfe" - beschreibung: "Schulungen, Coaching, Self-Service-Ressourcen und Key-User-Netzwerk" - - nutzen: "Klarheit und Orientierung" - beschreibung: "Gemeinsame Prozess-Sprache über alle Hierarchieebenen" - - fuer_gesamtorganisation: - - nutzen: "Grundlage für Effektivität und kontinuierliche Verbesserung" - beschreibung: "Methodische Rahmenbedingungen für anpassungsfähige Arbeitsabläufe" - - nutzen: "Automatisierung und Digitalisierung" - beschreibung: "Systematische Identifikation von Automatisierungspotenzialen" - - nutzen: "Siloüberwindung und Integration" - beschreibung: "Transparente End-to-End-Prozesse und einheitliche Standards" - -# ============================================================================= -# 5. CLUSTER C: WIE DIE PM-FUNKTION ES ERMÖGLICHT -# ============================================================================= - -cluster_c_wie: - name: "Wie die PM-Funktion es ermöglicht" - - # --------------------------------------------------------------------------- - # 5.1 Schlüsselaktivitäten - # --------------------------------------------------------------------------- - schluesselaktivitaeten: - beschreibung: | - Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen - einlöst. Sie transformieren Ressourcen in konkreten Nutzen. - - aktivitaeten: - - aktivitaet: "Framework-Entwicklung & -Pflege" - beschreibung: | - Kontinuierliche Definition und Weiterentwicklung des verbindlichen - PM-Frameworks inklusive Methoden, Standards, Templates und Governance-Regeln. - umfasst: - - "Laufende Analyse interner Bedarfe und externer Best Practices" - - "Entwicklung standardisierter Templates" - - - aktivitaet: "Management der Prozesslandschaft & Governance" - beschreibung: | - Aufbau, Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse. - umfasst: - - "Sicherstellung der Framework-Compliance" - - "Aufdecken von Governance-Lücken" - - "Bereitstellung des Prozessregisters" - - - aktivitaet: "Tool-Bereitstellung & -Management" - beschreibung: | - Auswahl, Implementierung und kontinuierliche Wartung zentraler PM-Tools. - umfasst: - - "Technische Verfügbarkeit, Updates und Support" - - "Integration neuer Möglichkeiten wie KI-gestützte Prozessanalyse" - - - aktivitaet: "Beratung & Methodische Unterstützung" - beschreibung: | - Durchführung von Beratungen, Coachings und Moderation von Workshops - zur Prozessanalyse und -optimierung. - umfasst: - - "Schwerpunkt auf Befähigung der Fachbereiche zur eigenständigen Prozessarbeit" - - - aktivitaet: "Befähigung & Kompetenzaufbau" - beschreibung: | - Entwicklung und Umsetzung des Befähigungskonzepts. - umfasst: - - "Qualifizierung und Betreuung des Key-User-Netzwerks" - - "Durchführung von Schulungen" - - - aktivitaet: "Kommunikation & Stakeholder-Engagement" - beschreibung: | - Aktive Kommunikation von Framework-Updates und Prozessänderungen. - umfasst: - - "Reporting an Gremien" - - "Proaktive Information bei identifizierten Governance-Lücken" - - - aktivitaet: "Prozessinnovation & -weiterentwicklung" - beschreibung: | - Identifikation von Optimierungspotenzialen und Automatisierungsmöglichkeiten. - umfasst: - - "Zusammenarbeit mit dem KI-Hub für innovative Lösungsansätze" - - # --------------------------------------------------------------------------- - # 5.2 Schlüsselressourcen - # --------------------------------------------------------------------------- - schluesselressourcen: - beschreibung: | - Das notwendige Fundament für wirksame PM-Arbeit. Diese Ressourcen ermöglichen - erst die Durchführung der Schlüsselaktivitäten. - - kategorien: - menschliche_ressourcen: - name: "Menschliche Ressourcen" - elemente: - - "Fachliche und methodische Expertise in PM-Methoden, -Standards und -Governance" - - "Beratungs- und Moderationskompetenz" - - "Ausreichende personelle Kapazität" - - intellektuelle_ressourcen: - name: "Intellektuelle Ressourcen" - elemente: - - "Dokumentiertes PM-Framework mit Standards und Methoden" - - "Prozesslandkarte mit Prozessregister" - - "Strukturierte Schulungskonzepte" - - "Umfassende Template-Bibliothek" - - technische_ressourcen: - name: "Physische/Technische Ressourcen" - elemente: - - "Zentrale PM-Werkzeuge für Prozessmodellierung und -dokumentation" - - "KI-gestützte Assistenzsysteme zur Prozessanalyse" - - "Digitale Kollaborationsplattformen" - - beziehungsnetzwerk: - name: "Beziehungsnetzwerk & Zugänge" - elemente: - - "Etablierte Governance-Zugänge zu relevanten Entscheidungsgremien" - - "Key-User-Netzwerk als Community dezentraler Prozessansprechpartner" - - "Organisationsweites Beziehungsnetzwerk von Mitarbeitenden bis zur Führung" - - # --------------------------------------------------------------------------- - # 5.3 Schlüsselpartner - # --------------------------------------------------------------------------- - schluesselpartner: - beschreibung: | - Die internen Kooperationspartner, mit denen die PM-Funktion zusammenarbeitet, - um ihr volles Potenzial zu entfalten. Erfolgreiche PM-Arbeit ist immer - Teamarbeit über Funktionsgrenzen hinweg. - - partner: - - partner: "IT-Architektur" - beitrag: "Definiert technische Rahmenbedingungen und Standards, die Framework und Werkzeugauswahl beeinflussen" - - - partner: "Informationssicherheitsbeauftragter" - beitrag: "Stellt IT-Sicherheit und technische Compliance von Prozessen sicher" - - - partner: "Datenschutzbeauftragte" - beitrag: "Gewährleistet datenschutzkonforme Prozessgestaltung" - - - partner: "Business Continuity Management" - beitrag: "Kategorisiert kritische Prozesse und integriert Notfallpläne" - - - partner: "Data Excellence Governance" - beitrag: "Stimmt datengetriebene Prozesse ab" - - - partner: "KI-Hub" - beitrag: "Strategischer Partner für KI-basierte Prozessinnovationen" - - - partner: "Vision Board" - beitrag: "Strategischer Auftraggeber für die PM-Ausrichtung" - - - partner: "Process Owner (SHM, DPM, PPM, SPM)" - beitrag: "Verantworten ihre jeweiligen Teilprozesse" - - - partner: "Qualitätsmanagement" - beitrag: "Partner zur Abstimmung von QM-Anforderungen und PM-Standards" - status: "noch zu klären" - - - partner: "Zentrale GPM (Geschäftsprozess Management)" - beitrag: | - Ämterübergreifender Prozess-Framework-Verantwortlicher für einheitliche - GPM-Standards und -Methoden. Verfügt über vollständige Prozesslandkarte - aller Ämter. - -# ============================================================================= -# 6. ZUSAMMENHÄNGE UND LESEHILFEN -# ============================================================================= - -zusammenhaenge: - gesamtbild: | - Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der - PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen - Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese - Bedarfe in konkrete Leistungszusagen. - - wechselwirkungen: - - element: "Key-User-Netzwerk" - mehrfachrolle: - - "Kanal (für dezentrale Unterstützung)" - - "Beziehungselement (Community Building)" - - "Ressource (Multiplikator:innen)" - - - element: "Framework-Entwicklung" - wechselwirkung: "Schlüsselaktivität, deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten ermöglicht" - - lesehilfen_nach_zielgruppe: - gremien: - fokus: - - "Strategisches Wertversprechen" - - "Governance-basierte Beziehungen" - - "Formelle Berichtskanäle" - relevante_aktivitaeten: - - "Framework-Entwicklung" - - "Prozesslandschafts-Management" - - fachbereiche_und_teams: - fokus: - - "Operatives Wertversprechen" - - "Befähigungsorientierte Beziehungen" - - "Vielfältige Zugangskanäle (Beratung bis Self-Service)" - relevante_aktivitaeten: - - "Beratung" - - "Befähigung" - - "Tool-Bereitstellung" - - key_user: - mehrfachverortung: - - "Teil der Nutzendensegmente" - - "Element der Community-Beziehungen" - - "Wichtiger Kanal" - - "Schlüsselressource" - bedeutung: "Zentrale Rolle im Gesamtkonzept" - -# ============================================================================= -# 7. VERBINDUNG ZU ANDEREN KONZEPTBAUSTEINEN -# ============================================================================= - -verbindung_zu_anderen_dokumenten: - - dokument: "Funktionsbeschreibung" - verbindung: "Definiert die formalen Verantwortlichkeiten, die den Leistungen zugrunde liegen" - - - dokument: "Governance-Modell" - verbindung: "Konkretisiert die Entscheidungswege und Beauftragungslogiken" - - - dokument: "Rollenmodell" - verbindung: "Spezifiziert, wer innerhalb der PM-Funktion für welche Canvas-Elemente verantwortlich ist" - - - dokument: "RACI-Matrix" - verbindung: "Operationalisiert die Zusammenarbeit mit den Schlüsselpartnern" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #03.1 - Prozess-Management: Leistungs-Canvas.docx - - Inhalte: - - Canvas-Logik (7 Bausteine) - - Cluster A: Nutzendensegmente, Nutzendenbeziehung, Kanäle - - Cluster B: Wertversprechen (nach Zielgruppen) - - Cluster C: Schlüsselaktivitäten, -ressourcen, -partner - - Zusammenhänge und Lesehilfen - - Verbindungen zu anderen Dokumenten - autor: "DIGITOM-Projekt" +# ============================================================================= +# LEISTUNGS-CANVAS: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "leistungs-canvas" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Management" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#03.1 - Prozess-Management: Leistungs-Canvas.docx" + +# ============================================================================= +# 1. EINFÜHRUNG +# ============================================================================= + +einfuehrung: + warum_ein_leistungs_canvas: | + Das Leistungs-Canvas betrachtet die Prozess-Management-Funktion konsequent + aus der Perspektive ihrer Nutzer:innen. Diese Perspektivverschiebung macht + sichtbar, was in traditionellen Funktionsbeschreibungen oft untergeht: + Wie entsteht konkret Nutzen? Welche Beziehungen ermöglichen wirksame + Zusammenarbeit? Über welche Wege werden Leistungen tatsächlich zugänglich? + + leitfragen: + - "Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?" + - "Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?" + - "Welche Voraussetzungen müssen dafür geschaffen werden?" + + funktionen_des_canvas: + - "Schafft Klarheit über das Leistungsportfolio" + - "Macht Zusammenhänge zwischen verschiedenen Elementen sichtbar" + - "Dient als Kommunikationsinstrument zwischen PM-Funktion und Nutzer:innen" + - "Steuerungsinstrument für Ressourcen-Investitionen" + +# ============================================================================= +# 2. CANVAS-LOGIK +# ============================================================================= + +canvas_logik: + beschreibung: | + Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander + verbundene Bausteine. Die rechte Seite fokussiert auf die Außenperspektive, + die linke Seite richtet den Blick nach innen. Im Zentrum steht das + Wertversprechen als verbindendes Element. + + bausteine: + rechte_seite_aussen: + - "Nutzendensegmente" + - "Nutzendenbeziehung" + - "Kanäle" + zentrum: + - "Wertversprechen" + linke_seite_innen: + - "Schlüsselaktivitäten" + - "Schlüsselressourcen" + - "Schlüsselpartner" + +# ============================================================================= +# 3. CLUSTER A: FÜR WEN DIE PM-FUNKTION DA IST +# ============================================================================= + +cluster_a_fuer_wen: + name: "Für wen die PM-Funktion da ist" + + # --------------------------------------------------------------------------- + # 3.1 Nutzendensegmente + # --------------------------------------------------------------------------- + nutzendensegmente: + beschreibung: | + Die verschiedenen internen Zielgruppen, für die die PM-Funktion Leistungen + erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen und Arbeitsweisen. + + segmente: + - segment: "Management-Gremien" + beispiele: "Vision Board, Mission Board" + bedarfe: + - "Transparenz über die Prozesslandschaft" + - "Governance-Berichte" + - "Einheitliche Standards zur besseren Steuerung" + - "Strategische Ausrichtung der Organisation" + + - segment: "Abteilungsleitungen" + bedarfe: + - "Prozessperspektive für bessere Ressourcenplanung" + - "Steuerung ihrer Bereiche" + - "Fundierte Entscheidungen bei bereichsübergreifenden Themen" + + - segment: "Process Owner der Teilprozesse" + beispiele: "SHM, DPM, PPM, SPM" + bedarfe: + - "End-to-End-Verantwortung für ihre jeweiligen Teilprozesse" + - "Methodische Unterstützung zur Prozessoptimierung" + - "Unterstützung bei Prozesssteuerung" + + - segment: "Fachbereiche und Teams mit Key-Usern" + bedarfe: + - "Methodische Unterstützung" + - "Befähigung und Standards" + - "Eigenständige Dokumentation und Verbesserung fachspezifischer Prozesse" + + - segment: "Projekt- und Programmorganisationen" + bedarfe: + - "Einheitliche Prozessvorgaben" + - "Methodische Beratung" + - "Sicherstellung der Framework-Compliance in Projekten" + + # --------------------------------------------------------------------------- + # 3.2 Nutzendenbeziehung + # --------------------------------------------------------------------------- + nutzendenbeziehung: + beschreibung: | + Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren + Nutzer:innen. Sie definiert das "Wie" der Interaktion. + + beziehungstypen: + - typ: "Partnerschaftliche Zusammenarbeit & Co-Kreation" + beschreibung: | + Aufbau von Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen. + Key-User als zentrale Partner:innen eng in Entwicklung und Umsetzung + von Prozesslösungen eingebunden. + + - typ: "Persönliche Beratung & Dedizierte Unterstützung" + beschreibung: | + Direkte Beratung und Coaching, insbesondere bei komplexen + Prozessherausforderungen oder strategischen Initiativen. + Besonderer Fokus auf Befähigung der Key-User als Multiplikator:innen. + + - typ: "Befähigungsorientierte Begleitung" + beschreibung: | + Konsequente Fokussierung auf Befähigung statt Ausführung. + Ermächtigung der Nutzenden, ihre Prozesse eigenständig zu managen. + Key-User als erste Ansprechpartner:innen in ihren Bereichen. + + - typ: "Community Building & Facilitation" + beschreibung: | + Aktive Förderung und Pflege des Key-User-Netzwerks als zentrales + Element für gemeinsames Lernen, Erfahrungsaustausch und kontinuierliche + Verbesserung über Abteilungsgrenzen hinweg. + + - typ: "Proaktive Impulsgebung" + beschreibung: | + Agieren als Impulsgeber durch Vorstellung neuer Methoden, Best Practices + und Anregung des Prozessdenkens. Key-User als Multiplikator:innen + tragen diese Impulse in ihre Fachbereiche. + + - typ: "Governance-basierte Interaktion" + beschreibung: | + Formelles Reporting, strategische Abstimmung und Eskalationsmanagement + mit Vision/Mission Boards. Regelmäßige Berichte über Entwicklung der + dezentralen Prozesskompetenzen. + + # --------------------------------------------------------------------------- + # 3.3 Kanäle + # --------------------------------------------------------------------------- + kanaele: + beschreibung: | + Die Wege und Formate, über die PM-Leistungen zugänglich werden. + Die Vielfalt der Kanäle sichert niedrigschwelligen Zugang und ermöglicht + situationsgerechte Unterstützung. + + kategorien: + direkte_interaktion: + name: "Direkte Interaktions- & Befähigungskanäle" + kanaele: + - name: "Workshops und Schulungen" + beschreibung: "Vermittlung von Wissen, Methoden und Werkzeugkompetenzen" + - name: "Beratungsgespräche und Coaching" + beschreibung: "Maßgeschneiderte Unterstützung (individuell oder Team)" + - name: "Moderation von Prozess-Workshops" + beschreibung: "Kollaborative Prozessarbeit bei komplexen/bereichsübergreifenden Prozessen" + - name: "Ticketsystem" + beschreibung: "Formaler Kanal für Anfragen mit automatischem Routing ans PM-Team" + + self_service: + name: "Self-Service & digitale Lernkanäle" + kanaele: + - name: "Zentrale Wissensplattform (Confluence)" + beschreibung: "PM-Framework, Methodenhandbuch, Templates, Prozessregister, FAQs" + - name: "KI-gestützter PM-Assistent" + beschreibung: "Interaktiver Dialog für Prozessfragen und kontextspezifische Antworten" + - name: "Prozessvisualisierungs-Tool (Picture Prozess Plattform)" + beschreibung: "Eigenständige Arbeit mit der Prozesslandschaft" + - name: "E-Learning-Module" + beschreibung: "Strukturierte Lernpfade für selbstgesteuertes Lernen" + + community: + name: "Community- & Kommunikationskanäle" + kanaele: + - name: "Key-User-Netzwerktreffen und Communities of Practice" + beschreibung: "Regelmäßiger Erfahrungsaustausch und kollektives Lernen" + - name: "Informationsveranstaltungen und Newsletter" + beschreibung: "Framework-Updates und relevante PM-Informationen" + - name: "DigiLog Podcast-Format" + beschreibung: "Einsichten und Erfolgsgeschichten zur Förderung des Prozessdenkens" + +# ============================================================================= +# 4. CLUSTER B: WAS DIE PM-FUNKTION BIETET +# ============================================================================= + +cluster_b_was: + name: "Was die PM-Funktion bietet" + + wertversprechen: + beschreibung: | + Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen + Zielgruppen schafft. Es ist das zentrale Element, das alle anderen + Bausteine ausrichtet. + + fuer_strategische_gremien: + - nutzen: "Strategische Prozess-Governance und Transparenz" + beschreibung: "Konsistente, strategisch ausgerichtete Prozesslandschaft" + - nutzen: "Messbare Verbesserung und KPI-basierte Steuerung" + beschreibung: "Faktenbasierte Bewertung von Prozessleistung und Nachweis von Optimierungserfolgen" + - nutzen: "Entscheidungsunterstützung und Risikominimierung" + beschreibung: "Konzepte zur Weiterentwicklung des Operating Models und proaktive Meldung von Risiken" + - nutzen: "Skalierbare Prozessstrukturen" + beschreibung: "Ermöglichung von Organisationswachstum und systematische Erschließung von Automatisierungspotenzialen" + + fuer_fachbereiche_und_teams: + - nutzen: "Einheitliches Prozessmanagement-Framework" + beschreibung: "Verbindliche Standards, Methoden, Werkzeuge und Templates" + - nutzen: "Methodische Beratung und Unterstützung" + beschreibung: "Von der Erstaufnahme bis zur Automatisierung" + - nutzen: "Systematische Befähigung zur Selbsthilfe" + beschreibung: "Schulungen, Coaching, Self-Service-Ressourcen und Key-User-Netzwerk" + - nutzen: "Klarheit und Orientierung" + beschreibung: "Gemeinsame Prozess-Sprache über alle Hierarchieebenen" + + fuer_gesamtorganisation: + - nutzen: "Grundlage für Effektivität und kontinuierliche Verbesserung" + beschreibung: "Methodische Rahmenbedingungen für anpassungsfähige Arbeitsabläufe" + - nutzen: "Automatisierung und Digitalisierung" + beschreibung: "Systematische Identifikation von Automatisierungspotenzialen" + - nutzen: "Siloüberwindung und Integration" + beschreibung: "Transparente End-to-End-Prozesse und einheitliche Standards" + +# ============================================================================= +# 5. CLUSTER C: WIE DIE PM-FUNKTION ES ERMÖGLICHT +# ============================================================================= + +cluster_c_wie: + name: "Wie die PM-Funktion es ermöglicht" + + # --------------------------------------------------------------------------- + # 5.1 Schlüsselaktivitäten + # --------------------------------------------------------------------------- + schluesselaktivitaeten: + beschreibung: | + Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen + einlöst. Sie transformieren Ressourcen in konkreten Nutzen. + + aktivitaeten: + - aktivitaet: "Framework-Entwicklung & -Pflege" + beschreibung: | + Kontinuierliche Definition und Weiterentwicklung des verbindlichen + PM-Frameworks inklusive Methoden, Standards, Templates und Governance-Regeln. + umfasst: + - "Laufende Analyse interner Bedarfe und externer Best Practices" + - "Entwicklung standardisierter Templates" + + - aktivitaet: "Management der Prozesslandschaft & Governance" + beschreibung: | + Aufbau, Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse. + umfasst: + - "Sicherstellung der Framework-Compliance" + - "Aufdecken von Governance-Lücken" + - "Bereitstellung des Prozessregisters" + + - aktivitaet: "Tool-Bereitstellung & -Management" + beschreibung: | + Auswahl, Implementierung und kontinuierliche Wartung zentraler PM-Tools. + umfasst: + - "Technische Verfügbarkeit, Updates und Support" + - "Integration neuer Möglichkeiten wie KI-gestützte Prozessanalyse" + + - aktivitaet: "Beratung & Methodische Unterstützung" + beschreibung: | + Durchführung von Beratungen, Coachings und Moderation von Workshops + zur Prozessanalyse und -optimierung. + umfasst: + - "Schwerpunkt auf Befähigung der Fachbereiche zur eigenständigen Prozessarbeit" + + - aktivitaet: "Befähigung & Kompetenzaufbau" + beschreibung: | + Entwicklung und Umsetzung des Befähigungskonzepts. + umfasst: + - "Qualifizierung und Betreuung des Key-User-Netzwerks" + - "Durchführung von Schulungen" + + - aktivitaet: "Kommunikation & Stakeholder-Engagement" + beschreibung: | + Aktive Kommunikation von Framework-Updates und Prozessänderungen. + umfasst: + - "Reporting an Gremien" + - "Proaktive Information bei identifizierten Governance-Lücken" + + - aktivitaet: "Prozessinnovation & -weiterentwicklung" + beschreibung: | + Identifikation von Optimierungspotenzialen und Automatisierungsmöglichkeiten. + umfasst: + - "Zusammenarbeit mit dem KI-Hub für innovative Lösungsansätze" + + # --------------------------------------------------------------------------- + # 5.2 Schlüsselressourcen + # --------------------------------------------------------------------------- + schluesselressourcen: + beschreibung: | + Das notwendige Fundament für wirksame PM-Arbeit. Diese Ressourcen ermöglichen + erst die Durchführung der Schlüsselaktivitäten. + + kategorien: + menschliche_ressourcen: + name: "Menschliche Ressourcen" + elemente: + - "Fachliche und methodische Expertise in PM-Methoden, -Standards und -Governance" + - "Beratungs- und Moderationskompetenz" + - "Ausreichende personelle Kapazität" + + intellektuelle_ressourcen: + name: "Intellektuelle Ressourcen" + elemente: + - "Dokumentiertes PM-Framework mit Standards und Methoden" + - "Prozesslandkarte mit Prozessregister" + - "Strukturierte Schulungskonzepte" + - "Umfassende Template-Bibliothek" + + technische_ressourcen: + name: "Physische/Technische Ressourcen" + elemente: + - "Zentrale PM-Werkzeuge für Prozessmodellierung und -dokumentation" + - "KI-gestützte Assistenzsysteme zur Prozessanalyse" + - "Digitale Kollaborationsplattformen" + + beziehungsnetzwerk: + name: "Beziehungsnetzwerk & Zugänge" + elemente: + - "Etablierte Governance-Zugänge zu relevanten Entscheidungsgremien" + - "Key-User-Netzwerk als Community dezentraler Prozessansprechpartner" + - "Organisationsweites Beziehungsnetzwerk von Mitarbeitenden bis zur Führung" + + # --------------------------------------------------------------------------- + # 5.3 Schlüsselpartner + # --------------------------------------------------------------------------- + schluesselpartner: + beschreibung: | + Die internen Kooperationspartner, mit denen die PM-Funktion zusammenarbeitet, + um ihr volles Potenzial zu entfalten. Erfolgreiche PM-Arbeit ist immer + Teamarbeit über Funktionsgrenzen hinweg. + + partner: + - partner: "IT-Architektur" + beitrag: "Definiert technische Rahmenbedingungen und Standards, die Framework und Werkzeugauswahl beeinflussen" + + - partner: "Informationssicherheitsbeauftragter" + beitrag: "Stellt IT-Sicherheit und technische Compliance von Prozessen sicher" + + - partner: "Datenschutzbeauftragte" + beitrag: "Gewährleistet datenschutzkonforme Prozessgestaltung" + + - partner: "Business Continuity Management" + beitrag: "Kategorisiert kritische Prozesse und integriert Notfallpläne" + + - partner: "Data Excellence Governance" + beitrag: "Stimmt datengetriebene Prozesse ab" + + - partner: "KI-Hub" + beitrag: "Strategischer Partner für KI-basierte Prozessinnovationen" + + - partner: "Vision Board" + beitrag: "Strategischer Auftraggeber für die PM-Ausrichtung" + + - partner: "Process Owner (SHM, DPM, PPM, SPM)" + beitrag: "Verantworten ihre jeweiligen Teilprozesse" + + - partner: "Qualitätsmanagement" + beitrag: "Partner zur Abstimmung von QM-Anforderungen und PM-Standards" + status: "noch zu klären" + + - partner: "Zentrale GPM (Geschäftsprozess Management)" + beitrag: | + Ämterübergreifender Prozess-Framework-Verantwortlicher für einheitliche + GPM-Standards und -Methoden. Verfügt über vollständige Prozesslandkarte + aller Ämter. + +# ============================================================================= +# 6. ZUSAMMENHÄNGE UND LESEHILFEN +# ============================================================================= + +zusammenhaenge: + gesamtbild: | + Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der + PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen + Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese + Bedarfe in konkrete Leistungszusagen. + + wechselwirkungen: + - element: "Key-User-Netzwerk" + mehrfachrolle: + - "Kanal (für dezentrale Unterstützung)" + - "Beziehungselement (Community Building)" + - "Ressource (Multiplikator:innen)" + + - element: "Framework-Entwicklung" + wechselwirkung: "Schlüsselaktivität, deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten ermöglicht" + + lesehilfen_nach_zielgruppe: + gremien: + fokus: + - "Strategisches Wertversprechen" + - "Governance-basierte Beziehungen" + - "Formelle Berichtskanäle" + relevante_aktivitaeten: + - "Framework-Entwicklung" + - "Prozesslandschafts-Management" + + fachbereiche_und_teams: + fokus: + - "Operatives Wertversprechen" + - "Befähigungsorientierte Beziehungen" + - "Vielfältige Zugangskanäle (Beratung bis Self-Service)" + relevante_aktivitaeten: + - "Beratung" + - "Befähigung" + - "Tool-Bereitstellung" + + key_user: + mehrfachverortung: + - "Teil der Nutzendensegmente" + - "Element der Community-Beziehungen" + - "Wichtiger Kanal" + - "Schlüsselressource" + bedeutung: "Zentrale Rolle im Gesamtkonzept" + +# ============================================================================= +# 7. VERBINDUNG ZU ANDEREN KONZEPTBAUSTEINEN +# ============================================================================= + +verbindung_zu_anderen_dokumenten: + - dokument: "Funktionsbeschreibung" + verbindung: "Definiert die formalen Verantwortlichkeiten, die den Leistungen zugrunde liegen" + + - dokument: "Governance-Modell" + verbindung: "Konkretisiert die Entscheidungswege und Beauftragungslogiken" + + - dokument: "Rollenmodell" + verbindung: "Spezifiziert, wer innerhalb der PM-Funktion für welche Canvas-Elemente verantwortlich ist" + + - dokument: "RACI-Matrix" + verbindung: "Operationalisiert die Zusammenarbeit mit den Schlüsselpartnern" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + Quelle: #03.1 - Prozess-Management: Leistungs-Canvas.docx + + Inhalte: + - Canvas-Logik (7 Bausteine) + - Cluster A: Nutzendensegmente, Nutzendenbeziehung, Kanäle + - Cluster B: Wertversprechen (nach Zielgruppen) + - Cluster C: Schlüsselaktivitäten, -ressourcen, -partner + - Zusammenhänge und Lesehilfen + - Verbindungen zu anderen Dokumenten + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml b/#05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml deleted file mode 100644 index b5871a3..0000000 --- a/#05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml +++ /dev/null @@ -1,337 +0,0 @@ -# ============================================================================= -# PILOTKONZEPT: WORKING STREAM "PROZESSMANAGEMENT" -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "pilotkonzept" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#07 - Pilot-Konzept.docx" - -# ============================================================================= -# 1. KONTEXT & KONZEPTBESCHREIBUNG -# ============================================================================= - -kontext: - pilotgegenstand: | - Einführung und Erprobung der neuen Prozess-Management-Funktionsbereich - nach DIGITOM-Modell - - voraussetzungen: - titel: "Was benötigen wir zur Zielerreichung?" - anforderungen: - - id: "VA-1" - beschreibung: "Prozess-Management-Tool & Methodik (Auswahl und Setup)" - - - id: "VA-2" - beschreibung: "Key-User aus verschiedenen Fachbereichen, je nach Prozessauswahl" - - - id: "VA-3" - beschreibung: "Zugang zu bestehender Prozessdokumentation" - - - id: "VA-4" - beschreibung: "Workshops-Räume und Moderationsausstattung" - - - id: "VA-5" - beschreibung: | - Zugriff auf Prozess-Funktions-Mitglieder (Kapazität muss vorhanden sein, - Coaching für Framework-Schulungen durchführen zu können) - - - id: "VA-6" - beschreibung: | - Schulung und Coaching für PM-Team (Coaching für ein Train-the-Trainer-Konzept) - und Key-User (Qualifizierungsmaßnahmen intern/extern). - Bei Bedarf Einbindung externer Trainer. - - - id: "VA-7" - beschreibung: | - Auswahl mindestens eines passenden Prozesses zum Prüfen der Wirksamkeit - und Arbeitsweise des PM-Teams im Rahmen der Funktion - - hypothesen: - titel: "Was wollen wir mit dem Pilot beweisen/widerlegen?" - items: - - id: "HYP-1" - hypothese: | - Der definierte PM-Funktionsbereich ist in der Praxis funktionsfähig - und wird von den Fachbereichen akzeptiert - - - id: "HYP-2" - hypothese: | - Key-User können nach entsprechender Befähigung eigenständig Prozesse - dokumentieren und optimieren - - - id: "HYP-3" - hypothese: | - Die Prozessberater sind fähig, die Key-User bei ihrer Aufgabe zu - befähigen und zu unterstützen - - - id: "HYP-4" - hypothese: | - Die Aufnahme eines Prozesses bis in das Prozesstool Picture schafft - einen Mehrwert bei der täglichen Arbeit - - - id: "HYP-5" - hypothese: "Das Governance-Modell funktioniert effektiv" - - risiken: - titel: "Welche potenziellen Risiken sehen wir im Zuge des Piloten?" - items: - - id: "RISK-1" - risiko: | - Keine verfügbaren Ressourcen in der Pilotphase, die konkret - (verfügbare Zeit) mit der Abteilungsleitung abgestimmt wurden - - - id: "RISK-2" - risiko: | - Fachbereich kooperiert nicht mit dem Key-User oder Prozessberater - (Zeit-Konflikt oder Akzeptanz) - - - id: "RISK-3" - risiko: | - Keine externe Unterstützung in der anvisierten Zeit - (Dienstleister, HPA...) - - - id: "RISK-4" - risiko: "Zu starke Anpassungen am Pilotkonzept im Pilotzeitraum" - -# ============================================================================= -# 2. ROLLENVERGABE -# ============================================================================= - -rollenvergabe: - pilot_sponsor: - rolle: "Pilot-Sponsor" - person: "Lisa Schroth" - - coaches: - rolle: "Coaches" - personen: - - "Patrick Breitenbach" - - "Human Nagafi" - - pilot_lead_operativ: - rolle: "Pilot-Lead operativ" - person: "Martin Mayer" - - pilot_lead_konsultativ: - rolle: "Pilot-Lead konsultativ" - person: "Patrick Breitenbach" - - pilot_team: - titel: "Pilot-Team" - mitglieder: - - rolle: "PFM (Prozess-Framework-Manager)" - person: "Martin Mayer" - - - rolle: "PB (Prozess-Berater)" - personen: - - "Gordian Gossen" - - "Jannik Eisenmann" - - "David Trenkle" - - - rolle: "PLK (Prozesslandschafts-Koordinator)" - personen: - - "David Trenkle" - - "Gordian Gossen" - - hinweis: "Key-User und Process Owner werden im Pilotplan bestimmt" - -# ============================================================================= -# 3. ARBEITSPAKETE -# ============================================================================= - -arbeitspakete: - - id: "AP-1" - name: "Kick-off" - aktivitaeten: - - "Kick-off mit dem Funktions-Team" - output: "Pilotvorstellungs-Präsentation" - - - id: "AP-2" - name: "Planungsphase" - aktivitaeten: - - "Projektmanagement: Projektplan, Risikobewertung, Stakeholder, Ressourceplanung etc." - - "Kommunikationsmaßnahmen" - - "Schulungsbedarf und Durchführung der Schulungen (Prozess-Berater und Key-User)" - - "Tool-Setup" - - "Prozessmanagement-Leistungsangebot" - - "Methodenübersicht (z.B. Prozess- und Methodenhandbuch)" - - "GPM-Kreislauf für die Prozess-Management-Funktion" - - "Onboarding Key-User" - - "Aufbau Prozessartefakte: Prozessteckbriefe, Prozesslandkarte, Prozessregister" - output: "Pilotplan" - - - id: "AP-3" - name: "Onboarding und Informationsphase" - aktivitaeten: - - "Pilotprozesse auswählen" - - "Prozess-Berater onboarden" - - "Key-User auswählen und onboarden" - output: "Bei Bedarf aktualisierter Pilotplan" - - - id: "AP-4" - name: "Umsetzungsphase" - aktivitaeten: - - "Pilotprozess aufnehmen in definierten Bereichen" - - "Pilotdurchführung monitoren (Quantitativ und Qualitativ)" - - "Pilotdurchführung reviewen (Was läuft gut? / Was lernen wir unterwegs? / Wo haben wir Probleme?)" - output: "Prozess-Artefakte, Bei Bedarf aktualisierter Pilotplan" - - - id: "AP-5" - name: "Retrospektive" - aktivitaeten: - - "Retrospektive vorbereiten und durchführen" - - "Empfehlung weitere Vorgehen durch 1789 ausarbeiten" - output: "Ergebnisbericht Pilotdurchführung, Empfehlungsbericht" - -# ============================================================================= -# 4. KOMMUNIKATIONSWEGE -# ============================================================================= - -kommunikation: - intern: - titel: "Interne Kommunikation" - kanaele: - - kanal: "Mission Board" - zweck: "Vorstellung Pilotkonzept und Retroergebnisse" - - - kanal: "SyncUp PzM" - rhythmus: "1x Woche" - format: "Teil für Pilot-Team, Teil für restliches Funktions-Team" - - - kanal: "Key-User Runde" - - - kanal: "Abteilungsleitungen" - - - kanal: "DIGIT Allgemein" - - - kanal: "Process Owner" - - - kanal: "Weekly Check-In Pilotstatus und Review" - rhythmus: "Wöchentlich" - dauer: "Maximal 30 Minuten" - verantwortlich: "1789 inkl. PzM-Team" - - - kanal: "Ad-Hoc Coaching" - format: "Auf Anfrage durch 1789" - - - kanal: "Moderierte Retrospektive" - anzahl: "1x" - verantwortlich: "1789" - - hinweis: "Weitere Maßnahmen gemäß Ergebnisse Kommunikationsplanung (Maßnahme)" - - extern: - titel: "Externe Schnittstellen" - partner: - - "Zentrales GPM der Stadt Freiburg" - -# ============================================================================= -# 5. TIMELINE / RHYTHMUS -# ============================================================================= - -timeline: - hinweis: | - Folgende Phasenzeitplanung wird angenommen. Anpassungen können während - der Pilotphase erfolgen. - - verlaengerung: | - Bei Bedarf Verlängerung bis Anfang 2026. Die Retrospektive sowie die - Empfehlungsdokumente von 1789 sind dann davon nicht betroffen. - - phasen: - - phase: "Kick-off" - termin: "ca. 27.08.2025" - typ: "Meilenstein" - - - phase: "Pilotphase allgemein" - start: "15.08.2025" - ende: "31.12.2025" - typ: "Rahmen" - - - phase: "Planungsphase" - start: "15.08.2025" - ende: "30.09.2025" - arbeitspaket: "AP-2" - - - phase: "Onboarding und Informationsphase" - start: "01.10.2025" - ende: "15.11.2025" - arbeitspaket: "AP-3" - - - phase: "Umsetzungsphase" - start: "15.10.2025" - ende: "15.12.2025" - arbeitspaket: "AP-4" - - - phase: "Retrospektive" - termin: "ca. 16.12.2025" - typ: "Meilenstein" - arbeitspaket: "AP-5" - -# ============================================================================= -# VERKNÜPFUNGEN -# ============================================================================= - -verknuepfungen: - referenzierte_dokumente: - - dokument: "Funktionsbeschreibung" - pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml" - relevanz: "Definiert die zu pilotierende Funktion" - - - dokument: "Rollenmodell" - pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml" - relevanz: "Beschreibt die Rollen PFM, PB, PLK, KNM, KU, PO" - - - dokument: "Governance-Framework" - pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" - relevanz: "Hypothese HYP-5 testet dessen Wirksamkeit" - - - dokument: "Leistungs-Canvas" - pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" - relevanz: "Definiert das Leistungsangebot" - - externe_partner: - - partner: "1789" - rolle: "Coaching und Moderation" - leistungen: - - "Weekly Check-In" - - "Ad-Hoc Coaching" - - "Moderierte Retrospektive" - - "Empfehlungsbericht" - - - partner: "Zentrales GPM Stadt Freiburg (HPA)" - rolle: "Externe Schnittstelle" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #07 - Pilot-Konzept.docx - - Inhalte: - - Kontext & Konzeptbeschreibung (7 Voraussetzungen, 5 Hypothesen, 4 Risiken) - - Rollenvergabe (Sponsor, Coaches, Leads, Team) - - 5 Arbeitspakete (Kick-off bis Retrospektive) - - Kommunikationswege (intern und extern) - - Timeline (15.08.2025 - 31.12.2025) - autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml b/#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml index 1e0803f..0736cc7 100644 --- a/#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml +++ b/#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml @@ -1,162 +1,162 @@ -# ============================================================================= -# ROLLENMODELL: PROZESS-MANAGEMENT (PM) -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "rollenmodell" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#04 - Prozess-Management: Rollenmodell.docx" - -# ============================================================================= -# STRATEGISCHE ARCHITEKTUR-PRINZIPIEN -# ============================================================================= - -architektur_prinzipien: - beschreibung: | - Das Prozess-Management im DIGITOM operiert als Enabling-Funktion mit klarer - Trennung zwischen methodischer Beratung und operativer PM-Governance. - Die Rollen-Architektur folgt dem Prinzip der dezentralen Befähigung bei - zentraler Methodenkompetenz. - - kernprinzipien: - - prinzip: "Enabling-Funktion" - beschreibung: "PM unterstützt und befähigt, kontrolliert nicht" - - - prinzip: "Dezentrale Befähigung" - beschreibung: "Prozess-Kompetenz wird in die Fachbereiche getragen" - - - prinzip: "Zentrale Methodenkompetenz" - beschreibung: "Framework und Standards werden zentral gepflegt" - - - prinzip: "Beratung-vs.-Governance-Trennung" - beschreibung: | - Methodische Unterstützung und PM-Compliance-Überwachung werden auf - unterschiedliche Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten. - - hinweis: | - Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare Verantwortungsschnitte - und vermeidet Interessenskonflikte (z.B. zwischen PM-Governance-Überwachung und - PM-Framework-Gestaltung). - -# ============================================================================= -# BEGRIFFSDEFINITION: END-TO-END VERANTWORTUNG -# ============================================================================= - -begriffsdefinitionen: - end_to_end_verantwortung: - definition: | - Im DIGITOM-Kontext bedeutet "End-to-End Verantwortung" die vollständige - Verantwortung für einen definierten Prozessabschnitt über alle beteiligten - Funktionen und Abteilungen hinweg. - - abgrenzungen: - - "End-to-End bezieht sich auf Teilprozesse, nicht auf den Gesamtprozess" - - "Der Process Owner trägt die Verantwortung innerhalb seiner Prozessebene" - - "Aktive Gestaltung der Schnittstellen zu vor- und nachgelagerten Prozessen" - - verantwortung_umfasst: - - "Performance und Qualität des eigenen Teilprozesses" - - "Schnittstellen-Vereinbarungen mit angrenzenden Process Ownern" - - "Eskalation bei Problemen in verbundenen Prozessen" - - "Kontinuierliche Optimierung inkl. schnittstellenübergreifender Verbesserungen" - -# ============================================================================= -# ROLLEN-ÜBERSICHT -# ============================================================================= - -rollen_uebersicht: - - kernrollen_intern: - beschreibung: "Interne PM-Organisation" - rollen: - - id: "R1" - name: "Leiter*in Prozess-Management" - kurzform: "LPM" - datei: "rolle_leiter-pm.yaml" - - - id: "R2" - name: "Prozess-Framework-Manager*in" - kurzform: "PFM" - datei: "rolle_prozess-framework-manager.yaml" - - - id: "R3" - name: "Prozesslandschafts-Koordinator*in" - kurzform: "PLK" - datei: "rolle_prozesslandschafts-koordinator.yaml" - - - id: "R4" - name: "Prozess-Berater*in" - kurzform: "PB" - datei: "rolle_prozess-berater.yaml" - - - id: "R5" - name: "Key-User-Netzwerk-Manager*in" - kurzform: "KNM" - datei: "rolle_key-user-netzwerk-manager.yaml" - - schnittstellenrollen: - beschreibung: "Rollen an der Schnittstelle zwischen PM und Organisation" - rollen: - - id: "R6" - name: "Process Owner" - kurzform: "PO" - datei: "rolle_process-owner.yaml" - hinweis: "Übernommen von SHM, DPM, PPM, SPM" - - - id: "R7" - name: "Key-User" - kurzform: "KU" - datei: "rolle_key-user.yaml" - hinweis: "Formale Rolle in den Fachbereichen" - - - id: "R8" - name: "Auftraggeber Prozess-Management" - kurzform: "AG-PM" - datei: "rolle_auftraggeber-pm.yaml" - hinweis: "Verschiedene organisatorische Ausprägungen" - - governance_support_rollen: - beschreibung: "Governance- und Support-Rollen" - rollen: - - id: "R9" - name: "IT-Architektur" - kurzform: "ITA" - datei: "rolle_it-architektur.yaml" - hinweis: "Technische Schnittstelle" - - - id: "R10" - name: "ISB / Datenschutzbeauftragte*r" - kurzform: "ISB/DSB" - datei: "rolle_isb-dsb.yaml" - - - id: "R11" - name: "Gremien" - kurzform: "VB/MB/DSR" - datei: "rolle_gremien.yaml" - hinweis: "Vision Board, Mission Board, DSR" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #04 - Prozess-Management: Rollenmodell.docx - autor: "DIGITOM-Projekt" +# ============================================================================= +# ROLLENMODELL: PROZESS-MANAGEMENT (PM) +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "rollenmodell" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Management" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#04 - Prozess-Management: Rollenmodell.docx" + +# ============================================================================= +# STRATEGISCHE ARCHITEKTUR-PRINZIPIEN +# ============================================================================= + +architektur_prinzipien: + beschreibung: | + Das Prozess-Management im DIGITOM operiert als Enabling-Funktion mit klarer + Trennung zwischen methodischer Beratung und operativer PM-Governance. + Die Rollen-Architektur folgt dem Prinzip der dezentralen Befähigung bei + zentraler Methodenkompetenz. + + kernprinzipien: + - prinzip: "Enabling-Funktion" + beschreibung: "PM unterstützt und befähigt, kontrolliert nicht" + + - prinzip: "Dezentrale Befähigung" + beschreibung: "Prozess-Kompetenz wird in die Fachbereiche getragen" + + - prinzip: "Zentrale Methodenkompetenz" + beschreibung: "Framework und Standards werden zentral gepflegt" + + - prinzip: "Beratung-vs.-Governance-Trennung" + beschreibung: | + Methodische Unterstützung und PM-Compliance-Überwachung werden auf + unterschiedliche Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten. + + hinweis: | + Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare Verantwortungsschnitte + und vermeidet Interessenskonflikte (z.B. zwischen PM-Governance-Überwachung und + PM-Framework-Gestaltung). + +# ============================================================================= +# BEGRIFFSDEFINITION: END-TO-END VERANTWORTUNG +# ============================================================================= + +begriffsdefinitionen: + end_to_end_verantwortung: + definition: | + Im DIGITOM-Kontext bedeutet "End-to-End Verantwortung" die vollständige + Verantwortung für einen definierten Prozessabschnitt über alle beteiligten + Funktionen und Abteilungen hinweg. + + abgrenzungen: + - "End-to-End bezieht sich auf Teilprozesse, nicht auf den Gesamtprozess" + - "Der Process Owner trägt die Verantwortung innerhalb seiner Prozessebene" + - "Aktive Gestaltung der Schnittstellen zu vor- und nachgelagerten Prozessen" + + verantwortung_umfasst: + - "Performance und Qualität des eigenen Teilprozesses" + - "Schnittstellen-Vereinbarungen mit angrenzenden Process Ownern" + - "Eskalation bei Problemen in verbundenen Prozessen" + - "Kontinuierliche Optimierung inkl. schnittstellenübergreifender Verbesserungen" + +# ============================================================================= +# ROLLEN-ÜBERSICHT +# ============================================================================= + +rollen_uebersicht: + + kernrollen_intern: + beschreibung: "Interne PM-Organisation" + rollen: + - id: "R1" + name: "Leiter*in Prozess-Management" + kurzform: "LPM" + datei: "rolle_leiter-pm.yaml" + + - id: "R2" + name: "Prozess-Framework-Manager*in" + kurzform: "PFM" + datei: "rolle_prozess-framework-manager.yaml" + + - id: "R3" + name: "Prozesslandschafts-Koordinator*in" + kurzform: "PLK" + datei: "rolle_prozesslandschafts-koordinator.yaml" + + - id: "R4" + name: "Prozess-Berater*in" + kurzform: "PB" + datei: "rolle_prozess-berater.yaml" + + - id: "R5" + name: "Key-User-Netzwerk-Manager*in" + kurzform: "KNM" + datei: "rolle_key-user-netzwerk-manager.yaml" + + schnittstellenrollen: + beschreibung: "Rollen an der Schnittstelle zwischen PM und Organisation" + rollen: + - id: "R6" + name: "Process Owner" + kurzform: "PO" + datei: "rolle_process-owner.yaml" + hinweis: "Übernommen von SHM, DPM, PPM, SPM" + + - id: "R7" + name: "Key-User" + kurzform: "KU" + datei: "rolle_key-user.yaml" + hinweis: "Formale Rolle in den Fachbereichen" + + - id: "R8" + name: "Auftraggeber Prozess-Management" + kurzform: "AG-PM" + datei: "rolle_auftraggeber-pm.yaml" + hinweis: "Verschiedene organisatorische Ausprägungen" + + governance_support_rollen: + beschreibung: "Governance- und Support-Rollen" + rollen: + - id: "R9" + name: "IT-Architektur" + kurzform: "ITA" + datei: "rolle_it-architektur.yaml" + hinweis: "Technische Schnittstelle" + + - id: "R10" + name: "ISB / Datenschutzbeauftragte*r" + kurzform: "ISB/DSB" + datei: "rolle_isb-dsb.yaml" + + - id: "R11" + name: "Gremien" + kurzform: "VB/MB/DSR" + datei: "rolle_gremien.yaml" + hinweis: "Vision Board, Mission Board, DSR" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + Quelle: #04 - Prozess-Management: Rollenmodell.docx + autor: "DIGITOM-Projekt" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_auftraggeber-pm.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_auftraggeber-pm.yaml index aa26810..b69098a 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_auftraggeber-pm.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_auftraggeber-pm.yaml @@ -1,69 +1,69 @@ -# ============================================================================= -# ROLLE: AUFTRAGGEBER PROZESS-MANAGEMENT (AG-PM) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R8-AG-PM" - rolle_name: "Auftraggeber Prozess-Management" - kurzform: "AG-PM" - kategorie: "schnittstellenrolle" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - - hinweis: "Verschiedene organisatorische Ausprägungen" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Bedarfs-Artikulation und Beauftragung der PM-Funktion zur zielgerichteten - Nutzung der PM-Services für spezifische organisatorische Herausforderungen. - -kernaufgaben: - - "Identifikation und Artikulation von Prozess-Management-Bedarfen" - - "Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder Projekten" - - "Bereitstellung notwendiger Ressourcen und Informationen für PM-Services" - - "Definition von Erfolgserwartungen und Zielen für PM-Unterstützung" - - "Feedback und Bewertung der erbrachten PM-Leistungen" - - "Sicherstellung der Implementierung von PM-Empfehlungen" - -# ============================================================================= -# AUFTRAGGEBER-KATEGORIEN -# ============================================================================= - -auftraggeber_kategorien: - - kategorie: "Abteilungsleitung" - fokus: "Bereichsspezifische Prozessoptimierungen" - - - kategorie: "Projektleitungen" - fokus: "Projektbezogene Prozess-Unterstützung" - - - kategorie: "Vision Board / Mission Board" - fokus: "Strategische PM-Initiativen" - - - kategorie: "Service-(Portfolio)-Manager" - fokus: "Servicebezogene Prozessentwicklung" - -stakeholder: - - name: "PM-Funktion" - beziehung: "Beauftragung und Zusammenarbeit" - - name: "Betroffene Teams und Bereiche" - beziehung: "Implementierung" - - name: "Übergeordnete Gremien" - beziehung: "Bei strategischen Aufträgen" - -entscheidungsbefugnisse: - - "Beauftragung und Priorisierung von PM-Services im eigenen Verantwortungsbereich" - - "Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten" - - "Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen" - -kompetenzen: - - "Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen" - - "Stakeholder-Management für Implementierungsmaßnahmen" - - "Change-Management-Grundverständnis" - - "Budget- und Ressourcen-Verantwortung" +# ============================================================================= +# ROLLE: AUFTRAGGEBER PROZESS-MANAGEMENT (AG-PM) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R8-AG-PM" + rolle_name: "Auftraggeber Prozess-Management" + kurzform: "AG-PM" + kategorie: "schnittstellenrolle" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + + hinweis: "Verschiedene organisatorische Ausprägungen" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Bedarfs-Artikulation und Beauftragung der PM-Funktion zur zielgerichteten + Nutzung der PM-Services für spezifische organisatorische Herausforderungen. + +kernaufgaben: + - "Identifikation und Artikulation von Prozess-Management-Bedarfen" + - "Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder Projekten" + - "Bereitstellung notwendiger Ressourcen und Informationen für PM-Services" + - "Definition von Erfolgserwartungen und Zielen für PM-Unterstützung" + - "Feedback und Bewertung der erbrachten PM-Leistungen" + - "Sicherstellung der Implementierung von PM-Empfehlungen" + +# ============================================================================= +# AUFTRAGGEBER-KATEGORIEN +# ============================================================================= + +auftraggeber_kategorien: + - kategorie: "Abteilungsleitung" + fokus: "Bereichsspezifische Prozessoptimierungen" + + - kategorie: "Projektleitungen" + fokus: "Projektbezogene Prozess-Unterstützung" + + - kategorie: "Vision Board / Mission Board" + fokus: "Strategische PM-Initiativen" + + - kategorie: "Service-(Portfolio)-Manager" + fokus: "Servicebezogene Prozessentwicklung" + +stakeholder: + - name: "PM-Funktion" + beziehung: "Beauftragung und Zusammenarbeit" + - name: "Betroffene Teams und Bereiche" + beziehung: "Implementierung" + - name: "Übergeordnete Gremien" + beziehung: "Bei strategischen Aufträgen" + +entscheidungsbefugnisse: + - "Beauftragung und Priorisierung von PM-Services im eigenen Verantwortungsbereich" + - "Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten" + - "Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen" + +kompetenzen: + - "Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen" + - "Stakeholder-Management für Implementierungsmaßnahmen" + - "Change-Management-Grundverständnis" + - "Budget- und Ressourcen-Verantwortung" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml index 7abf77f..21ef3c2 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml @@ -1,71 +1,71 @@ -# ============================================================================= -# ROLLE: GREMIEN (Vision Board, Mission Board, DSR) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R11-GREMIEN" - rolle_name: "Gremien" - kurzform: "VB/MB/DSR" - kategorie: "governance_support" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - - hinweis: "Vision Board, Mission Board, Digital Services Review" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Strategische und taktische Steuerung der PM-Funktion sowie - Entscheidungen zu prozessrelevanten Governance-Fragen. - -# ============================================================================= -# GREMIEN-SPEZIFISCHE AUFGABEN -# ============================================================================= - -gremien: - vision_board: - name: "Vision Board" - ebene: "strategisch" - aufgaben: - - "Strategische PM-Ausrichtung und Framework-Grundsätze" - - "Budget- und Ressourcen-Entscheidungen für PM-Funktion" - - "Grundsatzentscheidungen bei Eskalationen" - - mission_board: - name: "Mission Board" - ebene: "taktisch" - aufgaben: - - "Taktische PM-Priorisierung und Konfliktlösung" - - "Prozessübergreifende Optimierungsentscheidungen" - - "Entscheidungen bei Ressourcenkonflikten" - - "Governance-Eskalationen" - - dsr: - name: "Digital Services Review (DSR)" - ebene: "operativ" - aufgaben: - - "Operative Prozess-Entscheidungen im Kontext des Service-Portfolios" - -# ============================================================================= -# BEZIEHUNG ZUR PM-FUNKTION -# ============================================================================= - -beziehung_pm: - vision_board: - - "Empfängt strategische Berichte und Konzepte von PM" - - "Erteilt strategische Aufträge an PM" - - "Entscheidet über Framework-Transformationen" - - mission_board: - - "Empfängt operative Berichte von PM" - - "Entscheidet über Projekt-Leistungen" - - "Löst Prioritätskonflikte" - - dsr: - - "Abstimmung servicebezogener Prozessfragen" +# ============================================================================= +# ROLLE: GREMIEN (Vision Board, Mission Board, DSR) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R11-GREMIEN" + rolle_name: "Gremien" + kurzform: "VB/MB/DSR" + kategorie: "governance_support" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + + hinweis: "Vision Board, Mission Board, Digital Services Review" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Strategische und taktische Steuerung der PM-Funktion sowie + Entscheidungen zu prozessrelevanten Governance-Fragen. + +# ============================================================================= +# GREMIEN-SPEZIFISCHE AUFGABEN +# ============================================================================= + +gremien: + vision_board: + name: "Vision Board" + ebene: "strategisch" + aufgaben: + - "Strategische PM-Ausrichtung und Framework-Grundsätze" + - "Budget- und Ressourcen-Entscheidungen für PM-Funktion" + - "Grundsatzentscheidungen bei Eskalationen" + + mission_board: + name: "Mission Board" + ebene: "taktisch" + aufgaben: + - "Taktische PM-Priorisierung und Konfliktlösung" + - "Prozessübergreifende Optimierungsentscheidungen" + - "Entscheidungen bei Ressourcenkonflikten" + - "Governance-Eskalationen" + + dsr: + name: "Digital Services Review (DSR)" + ebene: "operativ" + aufgaben: + - "Operative Prozess-Entscheidungen im Kontext des Service-Portfolios" + +# ============================================================================= +# BEZIEHUNG ZUR PM-FUNKTION +# ============================================================================= + +beziehung_pm: + vision_board: + - "Empfängt strategische Berichte und Konzepte von PM" + - "Erteilt strategische Aufträge an PM" + - "Entscheidet über Framework-Transformationen" + + mission_board: + - "Empfängt operative Berichte von PM" + - "Entscheidet über Projekt-Leistungen" + - "Löst Prioritätskonflikte" + + dsr: + - "Abstimmung servicebezogener Prozessfragen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml index 3dd06c5..3ae970b 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml @@ -1,40 +1,40 @@ -# ============================================================================= -# ROLLE: ISB / DATENSCHUTZBEAUFTRAGTE*R -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R10-ISB-DSB" - rolle_name: "Informationssicherheitsbeauftragte*r / Datenschutzbeauftragte*r" - kurzform: "ISB/DSB" - kategorie: "governance_support" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Sicherstellung der Compliance von Prozessen und PM-Tools mit - Sicherheits- und Datenschutzvorgaben. - -kernaufgaben: - - "Compliance-Prüfung von Prozess-Designs und PM-Tools" - - "Definition sicherheitsrelevanter Prozess-Anforderungen" - - "Risiko-Assessment für prozessbezogene Datenverarbeitung" - -stakeholder: - - name: "PM-Funktion" - beziehung: "Compliance-Beratung und -Freigaben" - - name: "Process Owner" - beziehung: "Prozessbezogene Sicherheitsanforderungen" - - name: "Fachbereiche/Abteilungen" - beziehung: "Datenschutz-Compliance" - -entscheidungsbefugnisse: - - "Compliance-Freigaben für Prozesse und Tools" - - "Definition von Sicherheitsanforderungen" +# ============================================================================= +# ROLLE: ISB / DATENSCHUTZBEAUFTRAGTE*R +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R10-ISB-DSB" + rolle_name: "Informationssicherheitsbeauftragte*r / Datenschutzbeauftragte*r" + kurzform: "ISB/DSB" + kategorie: "governance_support" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Sicherstellung der Compliance von Prozessen und PM-Tools mit + Sicherheits- und Datenschutzvorgaben. + +kernaufgaben: + - "Compliance-Prüfung von Prozess-Designs und PM-Tools" + - "Definition sicherheitsrelevanter Prozess-Anforderungen" + - "Risiko-Assessment für prozessbezogene Datenverarbeitung" + +stakeholder: + - name: "PM-Funktion" + beziehung: "Compliance-Beratung und -Freigaben" + - name: "Process Owner" + beziehung: "Prozessbezogene Sicherheitsanforderungen" + - name: "Fachbereiche/Abteilungen" + beziehung: "Datenschutz-Compliance" + +entscheidungsbefugnisse: + - "Compliance-Freigaben für Prozesse und Tools" + - "Definition von Sicherheitsanforderungen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml index 06cbefe..b944e4d 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml @@ -1,43 +1,43 @@ -# ============================================================================= -# ROLLE: IT-ARCHITEKTUR (Technische Schnittstelle) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R9-ITA" - rolle_name: "IT-Architektur" - kurzform: "ITA" - kategorie: "governance_support" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - - hinweis: "Technische Schnittstelle zur PM-Funktion" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Sicherstellung der technischen Machbarkeit und Integration von - Prozess-Lösungen in die DIGITOM-IT-Landschaft. - -kernaufgaben: - - "Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen" - - "Definition technischer Rahmenbedingungen für Prozess-Tools und -systeme" - - "Sicherstellung der Systemkompatibilität bei prozessbezogenen IT-Lösungen" - - "Beratung zu technischen Möglichkeiten und Grenzen bei Prozessoptimierungen" - -stakeholder: - - name: "PM-Funktion" - beziehung: "Technische Beratung und Abstimmung" - - name: "Process Owner" - beziehung: "Prozessbezogene IT-Anforderungen" - - name: "IT-Betrieb" - beziehung: "Systemintegration und -betrieb" - -entscheidungsbefugnisse: - - "Technische Architektur-Vorgaben für Prozess-Tools" - - "System-Kompatibilitäts-Bewertungen" +# ============================================================================= +# ROLLE: IT-ARCHITEKTUR (Technische Schnittstelle) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R9-ITA" + rolle_name: "IT-Architektur" + kurzform: "ITA" + kategorie: "governance_support" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + + hinweis: "Technische Schnittstelle zur PM-Funktion" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Sicherstellung der technischen Machbarkeit und Integration von + Prozess-Lösungen in die DIGITOM-IT-Landschaft. + +kernaufgaben: + - "Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen" + - "Definition technischer Rahmenbedingungen für Prozess-Tools und -systeme" + - "Sicherstellung der Systemkompatibilität bei prozessbezogenen IT-Lösungen" + - "Beratung zu technischen Möglichkeiten und Grenzen bei Prozessoptimierungen" + +stakeholder: + - name: "PM-Funktion" + beziehung: "Technische Beratung und Abstimmung" + - name: "Process Owner" + beziehung: "Prozessbezogene IT-Anforderungen" + - name: "IT-Betrieb" + beziehung: "Systemintegration und -betrieb" + +entscheidungsbefugnisse: + - "Technische Architektur-Vorgaben für Prozess-Tools" + - "System-Kompatibilitäts-Bewertungen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_key-user-netzwerk-manager.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_key-user-netzwerk-manager.yaml index 2c5e325..332129d 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_key-user-netzwerk-manager.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_key-user-netzwerk-manager.yaml @@ -1,57 +1,57 @@ -# ============================================================================= -# ROLLE: KEY-USER-NETZWERK-MANAGER*IN (KNM) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R5-KNM" - rolle_name: "Key-User-Netzwerk-Manager*in" - kurzform: "KNM" - kategorie: "kernrolle_intern" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Systematischer Aufbau und Betreuung eines dezentralen Netzwerks von - Prozess-Champions zur Skalierung der PM-Kompetenz in die gesamte - DIGITOM-Organisation. - -kernaufgaben: - - "Identifikation, Rekrutierung und Onboarding geeigneter Key-User in allen Abteilungen" - - "Entwicklung und Durchführung strukturierter Qualifizierungsprogramme für Key-User" - - "Community-Management durch regelmäßige Netzwerk-Events und Erfahrungsaustausch" - - "Aufbau und Pflege der zentralen Wissensplattform mit Self-Service-Ressourcen" - - "Best-Practice-Transfer zwischen Abteilungen durch das Key-User-Netzwerk" - - "Performance-Management des Key-User-Netzwerks und kontinuierliche Weiterentwicklung" - -stakeholder: - - name: "Key-User in allen Fachbereichen/Abteilungen" - beziehung: "Direkte Betreuung und Entwicklung" - - name: "Fachbereichsleitungen" - beziehung: "Key-User-Nominierung und Freistellung" - - name: "Prozess-Berater:innen" - beziehung: "Operative Zusammenarbeit bei Fachbereichs-Support" - - name: "IT-Abteilung" - beziehung: "Wissensplattform-Entwicklung und -betrieb" - - name: "Personalentwicklung" - beziehung: "Qualifizierungskoordination" - -entscheidungsbefugnisse: - - "Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design" - - "Community-Event-Planung und Ressourcen-Allokation" - - "Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung" - - "Key-User-Performance-Bewertung und Entwicklungsempfehlungen" - -kompetenzen: - - "Community-Building und Netzwerk-Management für diverse organisatorische Kontexte" - - "Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung" - - "Content-Management für digitale Wissensplattformen" - - "Motivations- und Engagement-Management für freiwillige Communities" - - "Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung" +# ============================================================================= +# ROLLE: KEY-USER-NETZWERK-MANAGER*IN (KNM) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R5-KNM" + rolle_name: "Key-User-Netzwerk-Manager*in" + kurzform: "KNM" + kategorie: "kernrolle_intern" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Systematischer Aufbau und Betreuung eines dezentralen Netzwerks von + Prozess-Champions zur Skalierung der PM-Kompetenz in die gesamte + DIGITOM-Organisation. + +kernaufgaben: + - "Identifikation, Rekrutierung und Onboarding geeigneter Key-User in allen Abteilungen" + - "Entwicklung und Durchführung strukturierter Qualifizierungsprogramme für Key-User" + - "Community-Management durch regelmäßige Netzwerk-Events und Erfahrungsaustausch" + - "Aufbau und Pflege der zentralen Wissensplattform mit Self-Service-Ressourcen" + - "Best-Practice-Transfer zwischen Abteilungen durch das Key-User-Netzwerk" + - "Performance-Management des Key-User-Netzwerks und kontinuierliche Weiterentwicklung" + +stakeholder: + - name: "Key-User in allen Fachbereichen/Abteilungen" + beziehung: "Direkte Betreuung und Entwicklung" + - name: "Fachbereichsleitungen" + beziehung: "Key-User-Nominierung und Freistellung" + - name: "Prozess-Berater:innen" + beziehung: "Operative Zusammenarbeit bei Fachbereichs-Support" + - name: "IT-Abteilung" + beziehung: "Wissensplattform-Entwicklung und -betrieb" + - name: "Personalentwicklung" + beziehung: "Qualifizierungskoordination" + +entscheidungsbefugnisse: + - "Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design" + - "Community-Event-Planung und Ressourcen-Allokation" + - "Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung" + - "Key-User-Performance-Bewertung und Entwicklungsempfehlungen" + +kompetenzen: + - "Community-Building und Netzwerk-Management für diverse organisatorische Kontexte" + - "Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung" + - "Content-Management für digitale Wissensplattformen" + - "Motivations- und Engagement-Management für freiwillige Communities" + - "Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml index 3a5e30d..49ca371 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml @@ -1,59 +1,59 @@ -# ============================================================================= -# ROLLE: KEY-USER (KU) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R7-KU" - rolle_name: "Key-User" - kurzform: "KU" - kategorie: "schnittstellenrolle" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - - hinweis: "Formale Rolle in den Fachbereichen/Abteilungen" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Dezentrale PM-Kompetenz und Change-Agenten in den Fachbereichen/Abteilungen - zur lokalen Prozessexpertise und Schnittstelle zur zentralen PM-Funktion. - -kernaufgaben: - - "Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im eigenen Fachbereich/Abteilung" - - "Lokale Prozessexpertise und Unterstützung der Kollegen bei Prozessarbeit" - - "Schnittstelle zwischen Fachbereichen/Abteilungen und zentraler PM-Funktion" - - "Modellierung spezifischer (Fach-)Prozesse" - - "Implementierung von Framework-Updates und Prozessänderungen im Fachbereich" - - "Identifikation lokaler Optimierungspotenziale und Weiterleitung an PM-Funktion" - - "Multiplikator für Prozess-Know-how und Best Practices" - -stakeholder: - - name: "Kolleg:innen im eigenen Fachbereich/Abteilung" - beziehung: "Direkte Unterstützung" - - name: "Key-User-Netzwerk-Manager:in" - beziehung: "Qualifizierung und Community" - - name: "Prozess-Berater:innen" - beziehung: "Bei komplexeren Herausforderungen" - - name: "Fachbereichs-/Abteilungsleitung" - beziehung: "Lokale PM-Vertretung" - - name: "Andere Key-User" - beziehung: "Erfahrungsaustausch und Peer-Learning" - -entscheidungsbefugnisse: - - "Erste Bewertung und Priorisierung lokaler Prozess-Anfragen" - - "Methodische Empfehlungen für Standardsituationen im Rahmen des Frameworks" - - "Weiterleitung komplexerer Fälle an zentrale PM-Funktion" - - "Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner" - -kompetenzen: - - "Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden" - - "Beratungs- und Unterstützungskompetenz für Kolleg:innen" - - "Fachbereichs-spezifisches Prozess-Know-how" - - "Netzwerk- und Community-Fähigkeiten" - - "Change-Agent-Qualitäten für lokale Prozessverbesserungen" +# ============================================================================= +# ROLLE: KEY-USER (KU) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R7-KU" + rolle_name: "Key-User" + kurzform: "KU" + kategorie: "schnittstellenrolle" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + + hinweis: "Formale Rolle in den Fachbereichen/Abteilungen" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Dezentrale PM-Kompetenz und Change-Agenten in den Fachbereichen/Abteilungen + zur lokalen Prozessexpertise und Schnittstelle zur zentralen PM-Funktion. + +kernaufgaben: + - "Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im eigenen Fachbereich/Abteilung" + - "Lokale Prozessexpertise und Unterstützung der Kollegen bei Prozessarbeit" + - "Schnittstelle zwischen Fachbereichen/Abteilungen und zentraler PM-Funktion" + - "Modellierung spezifischer (Fach-)Prozesse" + - "Implementierung von Framework-Updates und Prozessänderungen im Fachbereich" + - "Identifikation lokaler Optimierungspotenziale und Weiterleitung an PM-Funktion" + - "Multiplikator für Prozess-Know-how und Best Practices" + +stakeholder: + - name: "Kolleg:innen im eigenen Fachbereich/Abteilung" + beziehung: "Direkte Unterstützung" + - name: "Key-User-Netzwerk-Manager:in" + beziehung: "Qualifizierung und Community" + - name: "Prozess-Berater:innen" + beziehung: "Bei komplexeren Herausforderungen" + - name: "Fachbereichs-/Abteilungsleitung" + beziehung: "Lokale PM-Vertretung" + - name: "Andere Key-User" + beziehung: "Erfahrungsaustausch und Peer-Learning" + +entscheidungsbefugnisse: + - "Erste Bewertung und Priorisierung lokaler Prozess-Anfragen" + - "Methodische Empfehlungen für Standardsituationen im Rahmen des Frameworks" + - "Weiterleitung komplexerer Fälle an zentrale PM-Funktion" + - "Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner" + +kompetenzen: + - "Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden" + - "Beratungs- und Unterstützungskompetenz für Kolleg:innen" + - "Fachbereichs-spezifisches Prozess-Know-how" + - "Netzwerk- und Community-Fähigkeiten" + - "Change-Agent-Qualitäten für lokale Prozessverbesserungen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml index eaa3edc..5d2688a 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml @@ -1,61 +1,61 @@ -# ============================================================================= -# ROLLE: LEITER*IN PROZESS-MANAGEMENT (LPM) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R1-LPM" - rolle_name: "Leiter*in Prozess-Management" - kurzform: "LPM" - kategorie: "kernrolle_intern" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Strategische Führung und operative Steuerung der gesamten PM-Funktion - zur Sicherstellung der Wertschöpfung für DIGITOM. - -kernaufgaben: - - "Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und organisationalen Bedarfen" - - "Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Perspektive (z.B. neue Funktionen, Rollenanpassungen, Governance-Strukturen)" - - "Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB, KNM)" - - "Stakeholder-Management zu Gremien und Fachbereichen/Abteilungen" - - "Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der PM-Funktion" - - "Eskalationsmanagement bei strategischen Konflikten oder Ressourcenengpässen" - - "Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei kritischen Fällen Eskalation ans Mission Board" - - "Berichterstattung an Vision Board über PM-Performance und strategische Entwicklungen" - -stakeholder: - - name: "Vision Board" - beziehung: "Auftraggeber und strategische Abstimmung" - - name: "Mission Board" - beziehung: "Taktische Abstimmung" - - name: "Interne PM-Rollen" - beziehung: "Führung und Koordination" - - name: "Abteilungsleitungen" - beziehung: "Strategische PM-Partnerschaften" - - name: "Amtsleitung DIGIT" - beziehung: "Organisatorische Einbindung" - - name: "Externe Berater und Dienstleister" - beziehung: "Strategische Partnerschaften" - -entscheidungsbefugnisse: - - "Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei kritischen Entscheidungen in Konsultation mit Mission Board)" - - "Personalentscheidungen für PM-Team (Einstellung, Entwicklung, Zielsetzung)" - - "Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung" - - "Eskalation an Mission Board bei konkurrierenden Prioritäten" - - "PM-Framework-Freigaben nach PFM-Vorschlägen" - -kompetenzen: - - "Führungskompetenz für interdisziplinäre Teams mit verschiedenen Expertisen" - - "Strategisches Stakeholder-Management und politische Sensibilität in der Verwaltung" - - "Verständnis für das DIGITOM und das PM-Framework sowie organisationale Transformationen" - - "Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen Fachbereichen/Abteilungen" - - "Change Management für komplexe organisatorische Veränderungen" +# ============================================================================= +# ROLLE: LEITER*IN PROZESS-MANAGEMENT (LPM) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R1-LPM" + rolle_name: "Leiter*in Prozess-Management" + kurzform: "LPM" + kategorie: "kernrolle_intern" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Strategische Führung und operative Steuerung der gesamten PM-Funktion + zur Sicherstellung der Wertschöpfung für DIGITOM. + +kernaufgaben: + - "Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und organisationalen Bedarfen" + - "Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Perspektive (z.B. neue Funktionen, Rollenanpassungen, Governance-Strukturen)" + - "Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB, KNM)" + - "Stakeholder-Management zu Gremien und Fachbereichen/Abteilungen" + - "Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der PM-Funktion" + - "Eskalationsmanagement bei strategischen Konflikten oder Ressourcenengpässen" + - "Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei kritischen Fällen Eskalation ans Mission Board" + - "Berichterstattung an Vision Board über PM-Performance und strategische Entwicklungen" + +stakeholder: + - name: "Vision Board" + beziehung: "Auftraggeber und strategische Abstimmung" + - name: "Mission Board" + beziehung: "Taktische Abstimmung" + - name: "Interne PM-Rollen" + beziehung: "Führung und Koordination" + - name: "Abteilungsleitungen" + beziehung: "Strategische PM-Partnerschaften" + - name: "Amtsleitung DIGIT" + beziehung: "Organisatorische Einbindung" + - name: "Externe Berater und Dienstleister" + beziehung: "Strategische Partnerschaften" + +entscheidungsbefugnisse: + - "Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei kritischen Entscheidungen in Konsultation mit Mission Board)" + - "Personalentscheidungen für PM-Team (Einstellung, Entwicklung, Zielsetzung)" + - "Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung" + - "Eskalation an Mission Board bei konkurrierenden Prioritäten" + - "PM-Framework-Freigaben nach PFM-Vorschlägen" + +kompetenzen: + - "Führungskompetenz für interdisziplinäre Teams mit verschiedenen Expertisen" + - "Strategisches Stakeholder-Management und politische Sensibilität in der Verwaltung" + - "Verständnis für das DIGITOM und das PM-Framework sowie organisationale Transformationen" + - "Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen Fachbereichen/Abteilungen" + - "Change Management für komplexe organisatorische Veränderungen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml index 49f9308..862985c 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml @@ -1,80 +1,80 @@ -# ============================================================================= -# ROLLE: PROCESS OWNER (PO) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R6-PO" - rolle_name: "Process Owner" - kurzform: "PO" - kategorie: "schnittstellenrolle" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - - hinweis: | - Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager (DPM), - Projekt Portfolio Manager (PPM), Service Portfolio Manager (SPM) - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - End-to-End-Verantwortung für spezifische Teilprozess-Prozesse zur - Sicherstellung von Prozess-Performance, Qualität und kontinuierlicher Optimierung. - -kernaufgaben: - - "Strategische Verantwortung für Performance und Qualität der zugeordneten End-to-End-Prozesse" - - "Definition prozessspezifischer KPIs auf Basis zentral vorgegebener KPI-Kategorien und Standards" - - "Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen" - - "Koordination prozessbezogener Optimierungsinitiativen zwischen beteiligten Bereichen" - - "Eskalationsmanagement bei prozessrelevanten Problemen oder Ressourcenkonflikten" - - "Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen Änderungen" - - "Sicherstellung der Framework-Compliance in den verantworteten Prozessen" - -# ============================================================================= -# PROCESS OWNER-ZUORDNUNG -# ============================================================================= - -spezifische_zuordnung: - - funktion: "SHM" - name: "Stakeholder-Management" - prozess: "Bedarfserfassung und -qualifizierung" - - - funktion: "DPM" - name: "Demand-Portfolio-Management" - prozess: "Demand-Bewertung und Demand-Portfolio-Steuerung" - - - funktion: "PPM" - name: "Projekt-Portfolio-Management" - prozess: "Projektsteuerung und -überwachung" - - - funktion: "SPM" - name: "Service-Portfolio-Management" - prozess: "Service-Integration und Betriebsüberführung" - -stakeholder: - - name: "PM-Funktion" - beziehung: "Methodische Unterstützung und Framework-Compliance" - - name: "Beteiligte Fachbereiche/Abteilungen" - beziehung: "Im jeweiligen End-to-End-Prozess" - - name: "Mission Board" - beziehung: "Performance-Reporting und strategische Abstimmung" - - name: "Key-User" - beziehung: "In den prozessrelevanten Bereichen" - -entscheidungsbefugnisse: - - "Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks" - - "Ressourcen-Anfrage/Priorisierung für prozessbezogene Optimierungsmaßnahmen" - - "Eskalations-Entscheidungen bei prozessübergreifenden Konflikten" - - "KPI-Definition und Performance-Ziele für die verantworteten Prozesse" - - "Abnahme-Entscheidungen für Prozessänderungen" - -kompetenzen: - - "End-to-End-Prozess-Verständnis mit systemischer Sichtweise" - - "Performance-Management mit KPI-Entwicklung und -monitoring" - - "Cross-funktionale Koordination zwischen verschiedenen Bereichen" - - "Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis" +# ============================================================================= +# ROLLE: PROCESS OWNER (PO) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R6-PO" + rolle_name: "Process Owner" + kurzform: "PO" + kategorie: "schnittstellenrolle" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + + hinweis: | + Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager (DPM), + Projekt Portfolio Manager (PPM), Service Portfolio Manager (SPM) + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + End-to-End-Verantwortung für spezifische Teilprozess-Prozesse zur + Sicherstellung von Prozess-Performance, Qualität und kontinuierlicher Optimierung. + +kernaufgaben: + - "Strategische Verantwortung für Performance und Qualität der zugeordneten End-to-End-Prozesse" + - "Definition prozessspezifischer KPIs auf Basis zentral vorgegebener KPI-Kategorien und Standards" + - "Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen" + - "Koordination prozessbezogener Optimierungsinitiativen zwischen beteiligten Bereichen" + - "Eskalationsmanagement bei prozessrelevanten Problemen oder Ressourcenkonflikten" + - "Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen Änderungen" + - "Sicherstellung der Framework-Compliance in den verantworteten Prozessen" + +# ============================================================================= +# PROCESS OWNER-ZUORDNUNG +# ============================================================================= + +spezifische_zuordnung: + - funktion: "SHM" + name: "Stakeholder-Management" + prozess: "Bedarfserfassung und -qualifizierung" + + - funktion: "DPM" + name: "Demand-Portfolio-Management" + prozess: "Demand-Bewertung und Demand-Portfolio-Steuerung" + + - funktion: "PPM" + name: "Projekt-Portfolio-Management" + prozess: "Projektsteuerung und -überwachung" + + - funktion: "SPM" + name: "Service-Portfolio-Management" + prozess: "Service-Integration und Betriebsüberführung" + +stakeholder: + - name: "PM-Funktion" + beziehung: "Methodische Unterstützung und Framework-Compliance" + - name: "Beteiligte Fachbereiche/Abteilungen" + beziehung: "Im jeweiligen End-to-End-Prozess" + - name: "Mission Board" + beziehung: "Performance-Reporting und strategische Abstimmung" + - name: "Key-User" + beziehung: "In den prozessrelevanten Bereichen" + +entscheidungsbefugnisse: + - "Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks" + - "Ressourcen-Anfrage/Priorisierung für prozessbezogene Optimierungsmaßnahmen" + - "Eskalations-Entscheidungen bei prozessübergreifenden Konflikten" + - "KPI-Definition und Performance-Ziele für die verantworteten Prozesse" + - "Abnahme-Entscheidungen für Prozessänderungen" + +kompetenzen: + - "End-to-End-Prozess-Verständnis mit systemischer Sichtweise" + - "Performance-Management mit KPI-Entwicklung und -monitoring" + - "Cross-funktionale Koordination zwischen verschiedenen Bereichen" + - "Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_prozess-berater.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_prozess-berater.yaml index 1699774..8578aa2 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_prozess-berater.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_prozess-berater.yaml @@ -1,57 +1,57 @@ -# ============================================================================= -# ROLLE: PROZESS-BERATER*IN (PB) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R4-PB" - rolle_name: "Prozess-Berater*in" - kurzform: "PB" - kategorie: "kernrolle_intern" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Direkte, vertrauensvolle methodische Unterstützung der Fachbereiche/Abteilungen - bei Prozessanalyse, -gestaltung und -optimierung zur Befähigung für - eigenständige Prozessarbeit. - -kernaufgaben: - - "Individuelle Beratung und Coaching von Fachbereichen/Abteilungen bei konkreten Prozess-Herausforderungen" - - "Moderation von Prozess-Workshops für kollaborative Analyse und Optimierung in definierten Fällen" - - "Methodische Unterstützung bei Prozessmodellierung und -dokumentation" - - "Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl. Erstbewertung von Anfragen über das Ticketsystem)" - - "Identifikation von Optimierungspotenzialen durch Prozess-Assessments" - - "Begleitende Umsetzungsunterstützung bei Prozessänderungen" - -stakeholder: - - name: "Fachbereiche/Abteilungen und deren Teams" - beziehung: "Direkte Beratung und Coaching" - - name: "Key-User" - beziehung: "Operative Zusammenarbeit und Befähigung" - - name: "Projektteams" - beziehung: "Prozessbezogene Projektunterstützung" - - name: "Auftraggeber PM" - beziehung: "Bedarfsklärung und Erwartungsmanagement" - - name: "Process Owner" - beziehung: "Methodische Unterstützung bei End-to-End-Optimierungen" - -entscheidungsbefugnisse: - - "Methodische Empfehlungen im Rahmen des gültigen Frameworks" - - "Workshop-Design und Moderations-Ansätze für spezifische Situationen" - - "Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen" - - "Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven Problemen" - -kompetenzen: - - "Prozessberatungs-Expertise mit breitem Methoden-Portfolio" - - "Workshop-Moderation und Facilitierung für diverse Stakeholder-Konstellationen" - - "Change Management-Fähigkeiten für begleitende Prozessveränderungen" - - "Empathie und Beziehungsaufbau für vertrauensvolle Beratungspartnerschaften" - - "Problemlösungs-Kompetenz für komplexe organisatorische Herausforderungen" +# ============================================================================= +# ROLLE: PROZESS-BERATER*IN (PB) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R4-PB" + rolle_name: "Prozess-Berater*in" + kurzform: "PB" + kategorie: "kernrolle_intern" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Direkte, vertrauensvolle methodische Unterstützung der Fachbereiche/Abteilungen + bei Prozessanalyse, -gestaltung und -optimierung zur Befähigung für + eigenständige Prozessarbeit. + +kernaufgaben: + - "Individuelle Beratung und Coaching von Fachbereichen/Abteilungen bei konkreten Prozess-Herausforderungen" + - "Moderation von Prozess-Workshops für kollaborative Analyse und Optimierung in definierten Fällen" + - "Methodische Unterstützung bei Prozessmodellierung und -dokumentation" + - "Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl. Erstbewertung von Anfragen über das Ticketsystem)" + - "Identifikation von Optimierungspotenzialen durch Prozess-Assessments" + - "Begleitende Umsetzungsunterstützung bei Prozessänderungen" + +stakeholder: + - name: "Fachbereiche/Abteilungen und deren Teams" + beziehung: "Direkte Beratung und Coaching" + - name: "Key-User" + beziehung: "Operative Zusammenarbeit und Befähigung" + - name: "Projektteams" + beziehung: "Prozessbezogene Projektunterstützung" + - name: "Auftraggeber PM" + beziehung: "Bedarfsklärung und Erwartungsmanagement" + - name: "Process Owner" + beziehung: "Methodische Unterstützung bei End-to-End-Optimierungen" + +entscheidungsbefugnisse: + - "Methodische Empfehlungen im Rahmen des gültigen Frameworks" + - "Workshop-Design und Moderations-Ansätze für spezifische Situationen" + - "Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen" + - "Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven Problemen" + +kompetenzen: + - "Prozessberatungs-Expertise mit breitem Methoden-Portfolio" + - "Workshop-Moderation und Facilitierung für diverse Stakeholder-Konstellationen" + - "Change Management-Fähigkeiten für begleitende Prozessveränderungen" + - "Empathie und Beziehungsaufbau für vertrauensvolle Beratungspartnerschaften" + - "Problemlösungs-Kompetenz für komplexe organisatorische Herausforderungen" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_prozess-framework-manager.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_prozess-framework-manager.yaml index a53f4b5..9bcaebd 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_prozess-framework-manager.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_prozess-framework-manager.yaml @@ -1,64 +1,64 @@ -# ============================================================================= -# ROLLE: PROZESS-FRAMEWORK-MANAGER*IN (PFM) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R2-PFM" - rolle_name: "Prozess-Framework-Manager*in" - kurzform: "PFM" - kategorie: "kernrolle_intern" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Entwicklung und Pflege eines einheitlichen, zukunftsfähigen PM-Frameworks, - das DIGITOM-weit als methodische Grundlage für qualitativ hochwertige - Prozessarbeit dient. - -kernaufgaben: - - "Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des verbindlichen PM-Frameworks (Standards, Methoden, Tools, Governance-Regeln)" - - "Entwicklung und Pflege eines zentralen KPI-Frameworks mit standardisierten Messkategorien, Berechnungsmethoden und Reporting-Standards" - - "Analyse externer Best Practices, Standards und gesetzlicher Anforderungen für Integration ins PM-Framework" - - "PM-Framework-Kommunikation und Change Management bei größeren Methodenänderungen" - - "Qualitätssicherung des PM-Frameworks durch systematisches Feedback-Management" - - "Entwicklung von PM-Framework-Schulungskonzepten und Zertifizierungsstandards" - - "Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Sicht" - - "Harmonisierung des PM-Frameworks mit dem Service Management Framework" - - "Identifikation geeigneter Methoden und technischer Ansätze zur Digitalisierung und (Teil-)Automatisierung von Prozessen" - -stakeholder: - - name: "Leiter*in Prozess-Management" - beziehung: "Strategische Abstimmung und Freigaben" - - name: "Alle internen PM-Rollen" - beziehung: "Framework-Anwendung und Feedback" - - name: "IT-Architektur" - beziehung: "Technische Machbarkeit und Systemintegration" - - name: "ISB/Datenschutz" - beziehung: "Compliance-Anforderungen" - - name: "Process Owner" - beziehung: "Framework-Implementierung in spezifischen Prozessen" - - name: "Externe Standards-Organisationen und Beratungsunternehmen" - beziehung: "Best Practices und Standards" - - name: "Zentrales GPM (HPA)" - beziehung: "Übergeordnete Abstimmung" - -entscheidungsbefugnisse: - - "PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben" - - "Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen" - - "Methodische Standards für einheitliche Prozessarbeit in DIGITOM" - - "PM-Framework-Update-Prioritäten basierend auf organisationalen Bedarfen" - -kompetenzen: - - "Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design Thinking)" - - "Technisches Verständnis für digitale Prozess-Tools und Plattform-Architekturen" - - "Systemisches Denken für komplexe organisatorische Zusammenhänge" - - "Didaktische Fähigkeiten für Framework-Kommunikation und Wissensvermittlung" - - "Analytische Fähigkeiten für Technologie-Assessment und Standards-Evaluierung" +# ============================================================================= +# ROLLE: PROZESS-FRAMEWORK-MANAGER*IN (PFM) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R2-PFM" + rolle_name: "Prozess-Framework-Manager*in" + kurzform: "PFM" + kategorie: "kernrolle_intern" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Entwicklung und Pflege eines einheitlichen, zukunftsfähigen PM-Frameworks, + das DIGITOM-weit als methodische Grundlage für qualitativ hochwertige + Prozessarbeit dient. + +kernaufgaben: + - "Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des verbindlichen PM-Frameworks (Standards, Methoden, Tools, Governance-Regeln)" + - "Entwicklung und Pflege eines zentralen KPI-Frameworks mit standardisierten Messkategorien, Berechnungsmethoden und Reporting-Standards" + - "Analyse externer Best Practices, Standards und gesetzlicher Anforderungen für Integration ins PM-Framework" + - "PM-Framework-Kommunikation und Change Management bei größeren Methodenänderungen" + - "Qualitätssicherung des PM-Frameworks durch systematisches Feedback-Management" + - "Entwicklung von PM-Framework-Schulungskonzepten und Zertifizierungsstandards" + - "Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Sicht" + - "Harmonisierung des PM-Frameworks mit dem Service Management Framework" + - "Identifikation geeigneter Methoden und technischer Ansätze zur Digitalisierung und (Teil-)Automatisierung von Prozessen" + +stakeholder: + - name: "Leiter*in Prozess-Management" + beziehung: "Strategische Abstimmung und Freigaben" + - name: "Alle internen PM-Rollen" + beziehung: "Framework-Anwendung und Feedback" + - name: "IT-Architektur" + beziehung: "Technische Machbarkeit und Systemintegration" + - name: "ISB/Datenschutz" + beziehung: "Compliance-Anforderungen" + - name: "Process Owner" + beziehung: "Framework-Implementierung in spezifischen Prozessen" + - name: "Externe Standards-Organisationen und Beratungsunternehmen" + beziehung: "Best Practices und Standards" + - name: "Zentrales GPM (HPA)" + beziehung: "Übergeordnete Abstimmung" + +entscheidungsbefugnisse: + - "PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben" + - "Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen" + - "Methodische Standards für einheitliche Prozessarbeit in DIGITOM" + - "PM-Framework-Update-Prioritäten basierend auf organisationalen Bedarfen" + +kompetenzen: + - "Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design Thinking)" + - "Technisches Verständnis für digitale Prozess-Tools und Plattform-Architekturen" + - "Systemisches Denken für komplexe organisatorische Zusammenhänge" + - "Didaktische Fähigkeiten für Framework-Kommunikation und Wissensvermittlung" + - "Analytische Fähigkeiten für Technologie-Assessment und Standards-Evaluierung" diff --git a/#05_prozessmanagement/#05.4_rollen/rolle_prozesslandschafts-koordinator.yaml b/#05_prozessmanagement/#05.4_rollen/rolle_prozesslandschafts-koordinator.yaml index ab0b0ee..f215ff6 100644 --- a/#05_prozessmanagement/#05.4_rollen/rolle_prozesslandschafts-koordinator.yaml +++ b/#05_prozessmanagement/#05.4_rollen/rolle_prozesslandschafts-koordinator.yaml @@ -1,65 +1,65 @@ -# ============================================================================= -# ROLLE: PROZESSLANDSCHAFTS-KOORDINATOR*IN (PLK) -# ============================================================================= -meta: - typ: "rollenbeschreibung" - rolle_id: "R3-PLK" - rolle_name: "Prozesslandschafts-Koordinator*in" - kurzform: "PLK" - kategorie: "kernrolle_intern" - funktion_id: "pm" - version: "1.0" - gueltig_ab: "2026-02-05" - - status: - status: "draft" - -# ============================================================================= -# ROLLENBESCHREIBUNG -# ============================================================================= - -hauptzweck: | - Operative Governance und Transparenz der DIGITOM-Prozesslandschaft zur - Sicherstellung von Framework-Compliance und End-to-End-Prozessqualität. - -kernaufgaben: - - "Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen Prozessregisters" - - "Monitoring von Framework-Compliance und Identifikation von PM-Governance-Lücken" - - "Koordination prozessübergreifender Initiativen zwischen verschiedenen Process Ownern" - - "PM-Governance-Reporting für Gremien mit Prozess-KPIs und Compliance-Status" - - "Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen" - - "Risiko-Assessment für Prozesslandschaft und frühzeitige Problemerkennung" - - "Schnittstellen-Governance: Moderation von Schnittstellen-Vereinbarungen zwischen Process Ownern und Konfliktlösung bei schnittstellenübergreifenden Problemen" - -pm_governance_luecken_management: - beschreibung: "Systematisches Management von PM-Governance-Lücken" - aufgaben: - - "Systematische Identifikation von PM-Governance-Lücken im DIGIT/DIGITOM" - - "Abstimmung mit Prozessberater:innen für Lösungsansätze" - - "Bei kurzfristiger Lösung: Dokumentation und Monitoring" - - "Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans Mission Board" - -stakeholder: - - name: "Process Owner (SHM, DPM, PPM, SPM)" - beziehung: "End-to-End-Prozess-Koordination" - - name: "Leiter*in Prozess-Management" - beziehung: "Governance-Reporting und Eskalationen" - - name: "Mission Board" - beziehung: "Taktische Governance-Entscheidungen" - - name: "Fachbereiche/Abteilungen" - beziehung: "Compliance-Unterstützung und Konfliktlösung" - - name: "IT-Architektur" - beziehung: "Systemische Prozess-Dependencies" - -entscheidungsbefugnisse: - - "Governance-Compliance-Bewertungen und Abweichungsmanagement" - - "Prozessregister-Updates und Dokumentationsstandards" - - "Eskalations-Empfehlungen bei systematischen Governance-Problemen" - - "Priorisierung von prozessübergreifenden Optimierungsmaßnahmen" - -kompetenzen: - - "Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften" - - "Governance-Kompetenz mit Verständnis für Compliance und Risikomanagement" - - "Diplomatische Fähigkeiten für Konfliktmediation zwischen Fachbereichen/Abteilungen" - - "Analytische Fähigkeiten für KPI-Entwicklung und Performance-Measurement" - - "Kommunikationsstärke für verständliches Governance-Reporting" +# ============================================================================= +# ROLLE: PROZESSLANDSCHAFTS-KOORDINATOR*IN (PLK) +# ============================================================================= +meta: + typ: "rollenbeschreibung" + rolle_id: "R3-PLK" + rolle_name: "Prozesslandschafts-Koordinator*in" + kurzform: "PLK" + kategorie: "kernrolle_intern" + funktion_id: "pm" + version: "1.0" + gueltig_ab: "2026-02-05" + + status: + status: "draft" + +# ============================================================================= +# ROLLENBESCHREIBUNG +# ============================================================================= + +hauptzweck: | + Operative Governance und Transparenz der DIGITOM-Prozesslandschaft zur + Sicherstellung von Framework-Compliance und End-to-End-Prozessqualität. + +kernaufgaben: + - "Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen Prozessregisters" + - "Monitoring von Framework-Compliance und Identifikation von PM-Governance-Lücken" + - "Koordination prozessübergreifender Initiativen zwischen verschiedenen Process Ownern" + - "PM-Governance-Reporting für Gremien mit Prozess-KPIs und Compliance-Status" + - "Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen" + - "Risiko-Assessment für Prozesslandschaft und frühzeitige Problemerkennung" + - "Schnittstellen-Governance: Moderation von Schnittstellen-Vereinbarungen zwischen Process Ownern und Konfliktlösung bei schnittstellenübergreifenden Problemen" + +pm_governance_luecken_management: + beschreibung: "Systematisches Management von PM-Governance-Lücken" + aufgaben: + - "Systematische Identifikation von PM-Governance-Lücken im DIGIT/DIGITOM" + - "Abstimmung mit Prozessberater:innen für Lösungsansätze" + - "Bei kurzfristiger Lösung: Dokumentation und Monitoring" + - "Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans Mission Board" + +stakeholder: + - name: "Process Owner (SHM, DPM, PPM, SPM)" + beziehung: "End-to-End-Prozess-Koordination" + - name: "Leiter*in Prozess-Management" + beziehung: "Governance-Reporting und Eskalationen" + - name: "Mission Board" + beziehung: "Taktische Governance-Entscheidungen" + - name: "Fachbereiche/Abteilungen" + beziehung: "Compliance-Unterstützung und Konfliktlösung" + - name: "IT-Architektur" + beziehung: "Systemische Prozess-Dependencies" + +entscheidungsbefugnisse: + - "Governance-Compliance-Bewertungen und Abweichungsmanagement" + - "Prozessregister-Updates und Dokumentationsstandards" + - "Eskalations-Empfehlungen bei systematischen Governance-Problemen" + - "Priorisierung von prozessübergreifenden Optimierungsmaßnahmen" + +kompetenzen: + - "Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften" + - "Governance-Kompetenz mit Verständnis für Compliance und Risikomanagement" + - "Diplomatische Fähigkeiten für Konfliktmediation zwischen Fachbereichen/Abteilungen" + - "Analytische Fähigkeiten für KPI-Entwicklung und Performance-Measurement" + - "Kommunikationsstärke für verständliches Governance-Reporting" diff --git a/#05_prozessmanagement/pm_uebersicht.yaml b/#05_prozessmanagement/pm_uebersicht.yaml index 799364c..48bd1b7 100644 --- a/#05_prozessmanagement/pm_uebersicht.yaml +++ b/#05_prozessmanagement/pm_uebersicht.yaml @@ -1,353 +1,353 @@ -# ============================================================================= -# PROZESS-MANAGEMENT: EXECUTIVE SUMMARY / ÜBERSICHT -# ============================================================================= -# Version: 1.0 -# Datum: 2026-02-05 -# Status: Draft - Konvertiert aus Word-Dokumentation -# ============================================================================= - -meta: - typ: "executive_summary" - funktion_id: "pm" - funktion_name: "Prozess-Management" - version: "1.0" - gueltig_ab: "2026-02-05" - geltungsbereich: "DIGITOM / Prozess-Management" - - status: - inhaltlich_abgenommen_durch: ["PM-Teammitglied"] - status: "draft" - - quellen: - - "#00 - Prozess-Management.docx" - -# ============================================================================= -# 1. STRATEGISCHER KONTEXT UND KERNKONZEPT -# ============================================================================= - -strategischer_kontext: - titel: "Strategischer Kontext und Kernkonzept" - - organisationale_herausforderung: - titel: "Die organisationale Herausforderung" - beschreibung: | - Das DIGITOM steht vor einem typischen Widerspruch in modernen - Verwaltungen: Es braucht einheitliche Standards für Effektivität und - Vergleichbarkeit - gleichzeitig müssen Fachbereiche flexibel auf ihre - spezifischen Anforderungen reagieren können. - - ausgangslage: - - "Fragmentierte Abläufe" - - "Methodische Vielfalt ohne gemeinsame Basis" - - "Silos statt Integration" - - konsequenzen: - - "Operative Reibungsverluste" - - "Verhinderte strategische Weiterentwicklung" - - "Ungenutzte Digitalisierungs- und Automatisierungspotenziale" - - "Fehlender strukturierter Überblick und notwendige Befähigungen" - - "Lokale Optimierungen ohne systemische Wirkung" - - loesungskonzept: - titel: "Ein neuer Weg zwischen Kontrolle und Autonomie" - beschreibung: | - Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung - und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn - produktiv. - - kernprinzipien: - - prinzip: "Zentrale Methodenkompetenz trifft dezentrale Umsetzung" - beschreibung: | - Die PM-Funktion definiert den Rahmen durch einheitliche Standards, - Methoden und Werkzeuge. Innerhalb dieses Rahmens gestalten die - Fachbereiche ihre Prozesse aktiv und tragen somit die Verantwortung dafür. - - - prinzip: "Befähigung statt Kontrolle" - beschreibung: | - Die Funktion versteht sich als Ermöglicher, nicht als Wächter. - Sie schafft Kompetenzen vor Ort durch ein Netzwerk von "Key-User", - die als Multiplikator:innen in ihren Bereichen wirken. - - - prinzip: "Nutzenorientierung statt Strukturfixierung" - beschreibung: | - Ausgangspunkt sind nicht interne Logiken, sondern die Bedarfe der - internen Kund:innen - von strategischen Gremien bis zu operativen Teams. - - erwarteter_mehrwert: - titel: "Der erwartete Mehrwert" - - fuer_strategische_entscheider: - zielgruppe: "Strategische Entscheider:innen" - mehrwert: - - "Erstmals Transparenz über die gesamte Prozesslandschaft" - - "Ermöglichte strategische Gestaltung" - - "Frühzeitige Sichtbarkeit von Risiken" - - "Systematische Erschließung von Digitalisierungs- und Automatisierungspotenzialen" - - fuer_operative_teams: - zielgruppe: "Operative Teams" - mehrwert: - - "Methodische Unterstützung genau dann, wenn sie benötigt wird" - - "Von schneller Beratung bis zur Begleitung komplexer Transformationen" - - "Einheitliche Standards für bereichsübergreifende Zusammenarbeit" - - fuer_gesamtorganisation: - zielgruppe: "Gesamtorganisation" - mehrwert: - - "Anpassungsfähigkeit ohne Kontrollverlust" - - "Kontinuierliche Prozessverbesserung statt nur Dokumentation" - - "Systematische Identifikation von Digitalisierungs- und Automatisierungspotenzialen" - - "Adressierung von Fachkräftemangel und steigenden Anforderungen" - -# ============================================================================= -# 2. ORGANISATIONSDESIGN UND GOVERNANCE -# ============================================================================= - -organisationsdesign: - titel: "Organisationsdesign und Governance" - - architektur: - titel: "Eine Architektur der produktiven Spannung" - prinzip: | - Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung. - Methodische Beratung und operative Governance liegen in unterschiedlichen - Händen - so entsteht Vertrauen statt Kontrollangst. - - zentrale_rollen: - beschreibung: | - Fünf zentrale Rollen im PM-Team decken das Spektrum von strategischer - Führung über Methodenentwicklung bis zur operativen Beratung ab. - Jede Rolle hat klare Verantwortlichkeiten, Überschneidungen werden vermieden. - rollen: - - "Leiter*in Prozess-Management" - - "Prozess-Framework-Manager*in (PFM)" - - "Prozesslandschafts-Koordinator*in (PLK)" - - "Prozess-Berater*in (PB)" - - "Key-User-Netzwerk-Manager*in (KNM)" - - process_owner: - beschreibung: | - Process Owner in den Hauptprozessen tragen horizontale und vertikale - End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren - bereichsübergreifend und sichern Prozessqualität. - hauptprozesse: - - "Stakeholder-Management" - - "Demand-Management" - - "Projekt-Management" - - "Service-Management" - - key_user: - beschreibung: | - Key-User werden in allen Fachbereichen identifiziert und zu lokalen - Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle vor Ort - und Bindeglied zur zentralen PM-Funktion. - - governance: - titel: "Governance: So viel wie nötig, so wenig wie möglich" - prinzip: "Subsidiaritätsprinzip" - - entscheidungskategorien: - - kategorie: "Operative Anpassungen" - entscheidungsträger: "PM-Team eigenständig" - beispiele: - - "Tool-Konfigurationen" - - "Template-Updates" - - "Schulungsinhalte" - - - kategorie: "Prozessspezifische Anpassungen" - entscheidungsträger: "Abstimmung mit jeweiligem Process Owner" - beispiele: - - "Änderungen an Prozessschnittstellen" - - "Neue Metriken für spezifische Prozesse" - - "Integration neuer Systeme in bestehende Prozesse" - - - kategorie: "PM-Framework-Weiterentwicklungen" - entscheidungsträger: "PM-Team eigenständig (Information an Process Owner)" - beispiele: - - "Neue Modellierungsstandards" - - "Erweiterte Methodenbausteine" - - "Übergreifende Bewertungskriterien" - - - kategorie: "Fundamentale Änderungen" - entscheidungsträger: "Steuerungsgremien" - beispiele: - - "Wechsel der Prozessmodellierungssprache" - - "Grundlegende Änderung der PM-Strategie" - - "Neuausrichtung der Prozessarchitektur" - - leistungsbeauftragung: - - typ: "Standard-Leistungen" - zugang: "Niedrigschwellig für alle zugänglich" - beispiele: - - "Beratung" - - "Workshops" - - - typ: "Projekt-Leistungen" - zugang: "Mission Board-Freigabe erforderlich" - beispiele: - - "Größere Transformationen" - - - typ: "Strategische Initiativen" - zugang: "Direkte Beauftragung durch Vision Board" - - - typ: "Krisen-Interventionen" - zugang: "Jederzeit durch Führungskräfte auslösbar" - - eskalationsmodell: - beschreibung: "Dreistufiges Eskalationsmodell sichert schnelle Konfliktlösung" - stufen: - - stufe: 1 - typ: "Operative Themen" - zeitrahmen: "Binnen 48 Stunden" - - - stufe: 2 - typ: "Taktische Konflikte" - gremium: "Mission Board" - zeitrahmen: "Binnen einer Woche" - - - stufe: 3 - typ: "Strategische Grundsatzfragen" - gremium: "Vision Board" - zeitrahmen: "Binnen eines Monats" - - integration: - titel: "Integration statt Parallelstruktur" - beschreibung: | - Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance - ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien. - Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor. - - schluesselpartner: - - "Zentrales Geschäftsprozessmanagement (HPA)" - - "IT-Architektur" - - "Datenschutz" - - "Informationssicherheit" - - prinzip: | - Systematische Einbindung schafft vernetzte Kompetenz statt neuer Silos. - -# ============================================================================= -# 3. IMPLEMENTIERUNG UND KRITISCHE ERFOLGSFAKTOREN -# ============================================================================= - -implementierung: - titel: "Implementierung und kritische Erfolgsfaktoren" - - leistungsportfolio: - titel: "Konkrete Leistungen, klare Zugänge" - orientierung: "Reale Bedarfe" - - leistungsbereiche: - - bereich: "Prozess-Framework/DIGITOM-Entwicklung" - zweck: "Schafft die methodische Basis" - - - bereich: "Beratung und Coaching" - zweck: "Unterstützt bei konkreten Herausforderungen" - - - bereich: "Befähigung und Schulung" - zweck: "Baut Kompetenzen dezentral auf" - - - bereich: "Transparenz und Reporting" - zweck: "Ermöglicht faktenbasierte Steuerung" - - zugangswege: - - "Ticketsystem für direkte Hilfe" - - "Strukturierte Beauftragungen für größere Vorhaben" - - "Informelle Kanäle über das Key-User-Netzwerk" - - ressourcen: - titel: "Ressourcen und Voraussetzungen" - - quantitativ: - - "Dediziertes PM-Team mit komplementären Kompetenzen" - - "Moderne Prozess-Tools" - - "Qualifizierungsbudgets" - - qualitativ: - wichtigkeit: "Wichtiger als Ressourcen sind die qualitativen Voraussetzungen" - faktoren: - - faktor: "Klares Mandat der Führung" - wirkung: "Legitimiert die Funktion" - - - faktor: "Bereitschaft der Fachbereiche" - wirkung: "Zur aktiven Mitgestaltung" - - - faktor: "Einbindung der Schlüsselpartner" - wirkung: "Von Anfang an" - - - faktor: "Verständnis von Prozessmanagement" - wirkung: "Als kontinuierliche Entwicklung, nicht als Projekt" - - risikomanagement: - titel: "Risiken aktiv managen" - - risiken: - - risiko: "Akzeptanzrisiken" - mitigationsstrategie: | - Konsequente Trennung von Beratung und Kontrolle. - Erfolgsgeschichten und Key-User als Botschafter:innen schaffen Vertrauen. - - - risiko: "Ressourcenkonflikte" - mitigationsstrategie: | - Transparentes Priorisierungsmodell. Strategische Initiativen gehen - stets vor, konkurrierende Anfragen werden offen abgewogen. - - - risiko: "Qualitätsrisiken" - mitigationsstrategie: | - Systematische Einbindung von Compliance-Funktionen und - Process Owner als Qualitätsgatekeeper. - -# ============================================================================= -# VERKNÜPFUNGEN ZU ANDEREN PM-DOKUMENTEN -# ============================================================================= - -dokumentverknuepfungen: - beschreibung: | - Diese Executive Summary gibt einen kompakten Überblick. Die Details - finden sich in den spezialisierten Dokumenten der PM-Funktion. - - detaildokumente: - - dokument: "Funktionsbeschreibung" - pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml" - inhalt: "Formale Grundlagen, Verantwortungsbereiche, Mandat" - - - dokument: "Leistungs-Canvas" - pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" - inhalt: "Detaillierte Leistungen, Nutzersegmente, Wertversprechen" - - - dokument: "Rollenmodell" - pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml" - inhalt: "Alle 11 Rollen mit Aufgaben, Befugnissen, Schnittstellen" - - - dokument: "Governance-Framework" - pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" - inhalt: "Entscheidungswege, Eskalation, Leitprinzipien" - - - dokument: "RACI-Matrix" - pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" - inhalt: "Verantwortlichkeitsmatrix für alle Leistungen" - - - dokument: "Konzeptrahmen" - pfad: "#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml" - inhalt: "Dokumentationsarchitektur und Navigationshilfe" - -# ============================================================================= -# ÄNDERUNGSHISTORIE -# ============================================================================= - -aenderungshistorie: - - version: "1.0" - datum: "2026-02-05" - aenderung: | - Initiale Erstellung durch Konvertierung aus Word-Dokument. - Quelle: #00 - Prozess-Management.docx - - Inhalte: - - Strategischer Kontext und Kernkonzept - - Organisationale Herausforderung - - Lösungskonzept (3 Kernprinzipien) - - Erwarteter Mehrwert (3 Zielgruppen) - - Organisationsdesign (Rollen, Process Owner, Key-User) - - Governance (4 Entscheidungskategorien, 4 Leistungstypen, 3 Eskalationsstufen) - - Implementierung (Leistungsportfolio, Ressourcen, Risikomanagement) - autor: "DIGITOM-Projekt" +# ============================================================================= +# PROZESS-MANAGEMENT: EXECUTIVE SUMMARY / ÜBERSICHT +# ============================================================================= +# Version: 1.0 +# Datum: 2026-02-05 +# Status: Draft - Konvertiert aus Word-Dokumentation +# ============================================================================= + +meta: + typ: "executive_summary" + funktion_id: "pm" + funktion_name: "Prozess-Management" + version: "1.0" + gueltig_ab: "2026-02-05" + geltungsbereich: "DIGITOM / Prozess-Management" + + status: + inhaltlich_abgenommen_durch: ["PM-Teammitglied"] + status: "draft" + + quellen: + - "#00 - Prozess-Management.docx" + +# ============================================================================= +# 1. STRATEGISCHER KONTEXT UND KERNKONZEPT +# ============================================================================= + +strategischer_kontext: + titel: "Strategischer Kontext und Kernkonzept" + + organisationale_herausforderung: + titel: "Die organisationale Herausforderung" + beschreibung: | + Das DIGITOM steht vor einem typischen Widerspruch in modernen + Verwaltungen: Es braucht einheitliche Standards für Effektivität und + Vergleichbarkeit - gleichzeitig müssen Fachbereiche flexibel auf ihre + spezifischen Anforderungen reagieren können. + + ausgangslage: + - "Fragmentierte Abläufe" + - "Methodische Vielfalt ohne gemeinsame Basis" + - "Silos statt Integration" + + konsequenzen: + - "Operative Reibungsverluste" + - "Verhinderte strategische Weiterentwicklung" + - "Ungenutzte Digitalisierungs- und Automatisierungspotenziale" + - "Fehlender strukturierter Überblick und notwendige Befähigungen" + - "Lokale Optimierungen ohne systemische Wirkung" + + loesungskonzept: + titel: "Ein neuer Weg zwischen Kontrolle und Autonomie" + beschreibung: | + Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung + und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn + produktiv. + + kernprinzipien: + - prinzip: "Zentrale Methodenkompetenz trifft dezentrale Umsetzung" + beschreibung: | + Die PM-Funktion definiert den Rahmen durch einheitliche Standards, + Methoden und Werkzeuge. Innerhalb dieses Rahmens gestalten die + Fachbereiche ihre Prozesse aktiv und tragen somit die Verantwortung dafür. + + - prinzip: "Befähigung statt Kontrolle" + beschreibung: | + Die Funktion versteht sich als Ermöglicher, nicht als Wächter. + Sie schafft Kompetenzen vor Ort durch ein Netzwerk von "Key-User", + die als Multiplikator:innen in ihren Bereichen wirken. + + - prinzip: "Nutzenorientierung statt Strukturfixierung" + beschreibung: | + Ausgangspunkt sind nicht interne Logiken, sondern die Bedarfe der + internen Kund:innen - von strategischen Gremien bis zu operativen Teams. + + erwarteter_mehrwert: + titel: "Der erwartete Mehrwert" + + fuer_strategische_entscheider: + zielgruppe: "Strategische Entscheider:innen" + mehrwert: + - "Erstmals Transparenz über die gesamte Prozesslandschaft" + - "Ermöglichte strategische Gestaltung" + - "Frühzeitige Sichtbarkeit von Risiken" + - "Systematische Erschließung von Digitalisierungs- und Automatisierungspotenzialen" + + fuer_operative_teams: + zielgruppe: "Operative Teams" + mehrwert: + - "Methodische Unterstützung genau dann, wenn sie benötigt wird" + - "Von schneller Beratung bis zur Begleitung komplexer Transformationen" + - "Einheitliche Standards für bereichsübergreifende Zusammenarbeit" + + fuer_gesamtorganisation: + zielgruppe: "Gesamtorganisation" + mehrwert: + - "Anpassungsfähigkeit ohne Kontrollverlust" + - "Kontinuierliche Prozessverbesserung statt nur Dokumentation" + - "Systematische Identifikation von Digitalisierungs- und Automatisierungspotenzialen" + - "Adressierung von Fachkräftemangel und steigenden Anforderungen" + +# ============================================================================= +# 2. ORGANISATIONSDESIGN UND GOVERNANCE +# ============================================================================= + +organisationsdesign: + titel: "Organisationsdesign und Governance" + + architektur: + titel: "Eine Architektur der produktiven Spannung" + prinzip: | + Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung. + Methodische Beratung und operative Governance liegen in unterschiedlichen + Händen - so entsteht Vertrauen statt Kontrollangst. + + zentrale_rollen: + beschreibung: | + Fünf zentrale Rollen im PM-Team decken das Spektrum von strategischer + Führung über Methodenentwicklung bis zur operativen Beratung ab. + Jede Rolle hat klare Verantwortlichkeiten, Überschneidungen werden vermieden. + rollen: + - "Leiter*in Prozess-Management" + - "Prozess-Framework-Manager*in (PFM)" + - "Prozesslandschafts-Koordinator*in (PLK)" + - "Prozess-Berater*in (PB)" + - "Key-User-Netzwerk-Manager*in (KNM)" + + process_owner: + beschreibung: | + Process Owner in den Hauptprozessen tragen horizontale und vertikale + End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren + bereichsübergreifend und sichern Prozessqualität. + hauptprozesse: + - "Stakeholder-Management" + - "Demand-Management" + - "Projekt-Management" + - "Service-Management" + + key_user: + beschreibung: | + Key-User werden in allen Fachbereichen identifiziert und zu lokalen + Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle vor Ort + und Bindeglied zur zentralen PM-Funktion. + + governance: + titel: "Governance: So viel wie nötig, so wenig wie möglich" + prinzip: "Subsidiaritätsprinzip" + + entscheidungskategorien: + - kategorie: "Operative Anpassungen" + entscheidungsträger: "PM-Team eigenständig" + beispiele: + - "Tool-Konfigurationen" + - "Template-Updates" + - "Schulungsinhalte" + + - kategorie: "Prozessspezifische Anpassungen" + entscheidungsträger: "Abstimmung mit jeweiligem Process Owner" + beispiele: + - "Änderungen an Prozessschnittstellen" + - "Neue Metriken für spezifische Prozesse" + - "Integration neuer Systeme in bestehende Prozesse" + + - kategorie: "PM-Framework-Weiterentwicklungen" + entscheidungsträger: "PM-Team eigenständig (Information an Process Owner)" + beispiele: + - "Neue Modellierungsstandards" + - "Erweiterte Methodenbausteine" + - "Übergreifende Bewertungskriterien" + + - kategorie: "Fundamentale Änderungen" + entscheidungsträger: "Steuerungsgremien" + beispiele: + - "Wechsel der Prozessmodellierungssprache" + - "Grundlegende Änderung der PM-Strategie" + - "Neuausrichtung der Prozessarchitektur" + + leistungsbeauftragung: + - typ: "Standard-Leistungen" + zugang: "Niedrigschwellig für alle zugänglich" + beispiele: + - "Beratung" + - "Workshops" + + - typ: "Projekt-Leistungen" + zugang: "Mission Board-Freigabe erforderlich" + beispiele: + - "Größere Transformationen" + + - typ: "Strategische Initiativen" + zugang: "Direkte Beauftragung durch Vision Board" + + - typ: "Krisen-Interventionen" + zugang: "Jederzeit durch Führungskräfte auslösbar" + + eskalationsmodell: + beschreibung: "Dreistufiges Eskalationsmodell sichert schnelle Konfliktlösung" + stufen: + - stufe: 1 + typ: "Operative Themen" + zeitrahmen: "Binnen 48 Stunden" + + - stufe: 2 + typ: "Taktische Konflikte" + gremium: "Mission Board" + zeitrahmen: "Binnen einer Woche" + + - stufe: 3 + typ: "Strategische Grundsatzfragen" + gremium: "Vision Board" + zeitrahmen: "Binnen eines Monats" + + integration: + titel: "Integration statt Parallelstruktur" + beschreibung: | + Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance + ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien. + Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor. + + schluesselpartner: + - "Zentrales Geschäftsprozessmanagement (HPA)" + - "IT-Architektur" + - "Datenschutz" + - "Informationssicherheit" + + prinzip: | + Systematische Einbindung schafft vernetzte Kompetenz statt neuer Silos. + +# ============================================================================= +# 3. IMPLEMENTIERUNG UND KRITISCHE ERFOLGSFAKTOREN +# ============================================================================= + +implementierung: + titel: "Implementierung und kritische Erfolgsfaktoren" + + leistungsportfolio: + titel: "Konkrete Leistungen, klare Zugänge" + orientierung: "Reale Bedarfe" + + leistungsbereiche: + - bereich: "Prozess-Framework/DIGITOM-Entwicklung" + zweck: "Schafft die methodische Basis" + + - bereich: "Beratung und Coaching" + zweck: "Unterstützt bei konkreten Herausforderungen" + + - bereich: "Befähigung und Schulung" + zweck: "Baut Kompetenzen dezentral auf" + + - bereich: "Transparenz und Reporting" + zweck: "Ermöglicht faktenbasierte Steuerung" + + zugangswege: + - "Ticketsystem für direkte Hilfe" + - "Strukturierte Beauftragungen für größere Vorhaben" + - "Informelle Kanäle über das Key-User-Netzwerk" + + ressourcen: + titel: "Ressourcen und Voraussetzungen" + + quantitativ: + - "Dediziertes PM-Team mit komplementären Kompetenzen" + - "Moderne Prozess-Tools" + - "Qualifizierungsbudgets" + + qualitativ: + wichtigkeit: "Wichtiger als Ressourcen sind die qualitativen Voraussetzungen" + faktoren: + - faktor: "Klares Mandat der Führung" + wirkung: "Legitimiert die Funktion" + + - faktor: "Bereitschaft der Fachbereiche" + wirkung: "Zur aktiven Mitgestaltung" + + - faktor: "Einbindung der Schlüsselpartner" + wirkung: "Von Anfang an" + + - faktor: "Verständnis von Prozessmanagement" + wirkung: "Als kontinuierliche Entwicklung, nicht als Projekt" + + risikomanagement: + titel: "Risiken aktiv managen" + + risiken: + - risiko: "Akzeptanzrisiken" + mitigationsstrategie: | + Konsequente Trennung von Beratung und Kontrolle. + Erfolgsgeschichten und Key-User als Botschafter:innen schaffen Vertrauen. + + - risiko: "Ressourcenkonflikte" + mitigationsstrategie: | + Transparentes Priorisierungsmodell. Strategische Initiativen gehen + stets vor, konkurrierende Anfragen werden offen abgewogen. + + - risiko: "Qualitätsrisiken" + mitigationsstrategie: | + Systematische Einbindung von Compliance-Funktionen und + Process Owner als Qualitätsgatekeeper. + +# ============================================================================= +# VERKNÜPFUNGEN ZU ANDEREN PM-DOKUMENTEN +# ============================================================================= + +dokumentverknuepfungen: + beschreibung: | + Diese Executive Summary gibt einen kompakten Überblick. Die Details + finden sich in den spezialisierten Dokumenten der PM-Funktion. + + detaildokumente: + - dokument: "Funktionsbeschreibung" + pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml" + inhalt: "Formale Grundlagen, Verantwortungsbereiche, Mandat" + + - dokument: "Leistungs-Canvas" + pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml" + inhalt: "Detaillierte Leistungen, Nutzersegmente, Wertversprechen" + + - dokument: "Rollenmodell" + pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml" + inhalt: "Alle 11 Rollen mit Aufgaben, Befugnissen, Schnittstellen" + + - dokument: "Governance-Framework" + pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml" + inhalt: "Entscheidungswege, Eskalation, Leitprinzipien" + + - dokument: "RACI-Matrix" + pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml" + inhalt: "Verantwortlichkeitsmatrix für alle Leistungen" + + - dokument: "Konzeptrahmen" + pfad: "#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml" + inhalt: "Dokumentationsarchitektur und Navigationshilfe" + +# ============================================================================= +# ÄNDERUNGSHISTORIE +# ============================================================================= + +aenderungshistorie: + - version: "1.0" + datum: "2026-02-05" + aenderung: | + Initiale Erstellung durch Konvertierung aus Word-Dokument. + Quelle: #00 - Prozess-Management.docx + + Inhalte: + - Strategischer Kontext und Kernkonzept + - Organisationale Herausforderung + - Lösungskonzept (3 Kernprinzipien) + - Erwarteter Mehrwert (3 Zielgruppen) + - Organisationsdesign (Rollen, Process Owner, Key-User) + - Governance (4 Entscheidungskategorien, 4 Leistungstypen, 3 Eskalationsstufen) + - Implementierung (Leistungsportfolio, Ressourcen, Risikomanagement) + autor: "DIGITOM-Projekt"