950 lines
No EOL
36 KiB
YAML
950 lines
No EOL
36 KiB
YAML
# =============================================================================
|
||
# 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 |