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