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