init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)
This commit is contained in:
commit
f599c7ced7
91 changed files with 56355 additions and 0 deletions
|
|
@ -0,0 +1,950 @@
|
|||
# =============================================================================
|
||||
# SHM STAKEHOLDER-PORTFOLIO: KONZEPT
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Funktion: Konzepte
|
||||
# Version: 1.3
|
||||
# Datum: 2026-01-23
|
||||
# Status: Final
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-K-01"
|
||||
name: "Stakeholder-Portfolio"
|
||||
typ: "Konzept"
|
||||
|
||||
zweck: |
|
||||
Das Stakeholder-Portfolio ist das zentrale Steuerungsinstrument des
|
||||
Stakeholder-Managements. Es erfasst alle Organisationseinheiten im
|
||||
Kundenkreis von DIGIT, segmentiert sie nach relevanten Dimensionen
|
||||
und priorisiert sie für die Ressourcenallokation.
|
||||
|
||||
Das Portfolio ist kein Selbstzweck, sondern ein Entscheidungsinstrument.
|
||||
Seine Struktur folgt aus den Entscheidungen, die es unterstützen soll.
|
||||
|
||||
scope: |
|
||||
Alle Organisationseinheiten im Dezernatsverteilungsplan der Stadt:
|
||||
- Ämter
|
||||
- Eigenbetriebe
|
||||
- Referate
|
||||
- Stabsstellen
|
||||
- Projektgruppen
|
||||
|
||||
governance_referenzen:
|
||||
- "GOV-SHM-001 bis GOV-SHM-014"
|
||||
- "readme_shm_governance-entscheidungs-log.yaml"
|
||||
|
||||
schema_referenz:
|
||||
dokument: "shm_schema_amtssteckbrief.yaml"
|
||||
beschreibung: "Technisches Attribut-Schema für die Datenerfassung pro Amt"
|
||||
|
||||
# =============================================================================
|
||||
# FUNKTIONALE HERLEITUNG
|
||||
# =============================================================================
|
||||
|
||||
funktionale_herleitung:
|
||||
|
||||
leitfrage: |
|
||||
Welche Entscheidungen soll das Stakeholder-Portfolio ermöglichen?
|
||||
|
||||
kernentscheidungen:
|
||||
|
||||
- id: PKE-1
|
||||
name: "Betreuungsallokation"
|
||||
leitfrage: "Wer wird wie intensiv betreut?"
|
||||
kontext: |
|
||||
Ressourcenknappheit erfordert Priorisierung. Nicht alle Ämter
|
||||
können gleich intensiv betreut werden. Das Portfolio muss helfen,
|
||||
die Betreuungsintensität systematisch zu differenzieren.
|
||||
unterstuetzt_durch:
|
||||
- "Priorisierung (Ebene 3)"
|
||||
- "Betreuungsmodus-Ableitung"
|
||||
|
||||
- id: PKE-2
|
||||
name: "Bedarfsrouting"
|
||||
leitfrage: "Wohin gehört dieser Bedarf?"
|
||||
kontext: |
|
||||
Wenn ein Bedarf eingeht, muss SHM entscheiden: Ist das ein
|
||||
Service-Request (→ Katalog), ein Change an bestehendem Service
|
||||
(→ Service Owner), oder ein neuer Demand (→ DPM)? Das Wissen
|
||||
über den Stakeholder und sein typisches Bedarfsprofil beeinflusst
|
||||
diese Einordnung.
|
||||
unterstuetzt_durch:
|
||||
- "Segmentierung (Ebene 2)"
|
||||
- "Funktion + IT-Anforderungsprofil"
|
||||
|
||||
- id: PKE-3
|
||||
name: "Governance-Zuordnung"
|
||||
leitfrage: "Wer sitzt in welchem Gremium?"
|
||||
kontext: |
|
||||
Für SLAs (Kundenvertretungen), für Bedarfspriorisierung (DSR),
|
||||
für strategische Abstimmung braucht es Zuordnungslogiken.
|
||||
Das IT-Anforderungsprofil korrespondiert mit den SPM-Service-
|
||||
Kategorien und damit mit der Gremienstruktur.
|
||||
unterstuetzt_durch:
|
||||
- "IT-Anforderungsprofil → SPM-Kategorie-Mapping"
|
||||
- "SLA-Befugnis im Amts-Steckbrief"
|
||||
|
||||
# =============================================================================
|
||||
# DREI-EBENEN-MODELL
|
||||
# =============================================================================
|
||||
|
||||
drei_ebenen_modell:
|
||||
|
||||
beschreibung: |
|
||||
Das Portfolio ist in drei Ebenen strukturiert, die aufeinander aufbauen:
|
||||
|
||||
1. Amts-Steckbrief – Datengrundlage pro Organisationseinheit
|
||||
2. Segmentierung – Clustering nach zwei unabhängigen Dimensionen
|
||||
3. Priorisierung – Bewertung zur Ableitung des Betreuungsmodus
|
||||
|
||||
Ergänzend: Der Betreuungsstatus (Stammdaten) dokumentiert, ob eine
|
||||
Zusammenarbeit mit dem Amt überhaupt möglich ist – unabhängig von
|
||||
dessen Wichtigkeit (Priorisierung).
|
||||
|
||||
governance_referenz: "GOV-SHM-001"
|
||||
|
||||
# =============================================================================
|
||||
# BETREUUNGSSTATUS-KONZEPT
|
||||
# =============================================================================
|
||||
|
||||
betreuungsstatus_konzept:
|
||||
|
||||
beschreibung: |
|
||||
Der Betreuungsstatus ist ein Stammdatum (nicht Teil der Priorisierung),
|
||||
das dokumentiert, ob eine Zusammenarbeit mit einem Amt möglich ist.
|
||||
|
||||
Hintergrund:
|
||||
Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz)
|
||||
beantworten die Frage "Wie wichtig ist das Amt?". Sie beantworten
|
||||
nicht "Können wir mit dem Amt zusammenarbeiten?"
|
||||
|
||||
Beispiele für eingeschränkte Zusammenarbeit:
|
||||
- Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung
|
||||
- Amt X: Schwierige Beziehung, Zugang erschwert
|
||||
|
||||
Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit),
|
||||
aber die Betreuungslogik muss die Realität abbilden.
|
||||
|
||||
governance_referenz: "GOV-SHM-028"
|
||||
schema_referenz: "shm_schema_amtssteckbrief.yaml → stammdaten.betreuungsstatus"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "AKTIV"
|
||||
name: "Aktiv"
|
||||
beschreibung: |
|
||||
Zusammenarbeit möglich. Normale Priorisierung greift,
|
||||
Betreuungsmodus wird direkt aus Prio-Stufe abgeleitet.
|
||||
konsequenz: "effektiver_betreuungsmodus = betreuungsmodus (aus Prio-Stufe)"
|
||||
|
||||
- id: "EINGESCHRAENKT"
|
||||
name: "Eingeschränkt"
|
||||
beschreibung: |
|
||||
Zusammenarbeit nur punktuell möglich. Priorisierung greift,
|
||||
aber Betreuungsmodus wird auf individuell festgelegtes
|
||||
Maximum gedeckelt.
|
||||
konsequenz: |
|
||||
effektiver_betreuungsmodus = MIN(betreuungsmodus, max_betreuungsmodus)
|
||||
Beispiel: Key-Stakeholder mit max_betreuungsmodus REGELMAESSIG
|
||||
→ effektiver_betreuungsmodus = REGELMAESSIG (nicht PROAKTIV_DEDIZIERT)
|
||||
pflichtfelder:
|
||||
- "begruendung (min. 30 Zeichen)"
|
||||
- "max_betreuungsmodus"
|
||||
- "entschieden_von"
|
||||
- "entschieden_am"
|
||||
|
||||
- id: "RUHEND"
|
||||
name: "Ruhend"
|
||||
beschreibung: |
|
||||
Aktuell keine Zusammenarbeit möglich. Amt bleibt im
|
||||
Portfolio dokumentiert, aber außerhalb aktiver Betreuung.
|
||||
Priorisierung wird trotzdem erfasst (für Reaktivierung).
|
||||
konsequenz: "effektiver_betreuungsmodus = KEINE_AKTIVE_BETREUUNG"
|
||||
pflichtfelder:
|
||||
- "begruendung (min. 30 Zeichen)"
|
||||
- "entschieden_von"
|
||||
- "entschieden_am"
|
||||
|
||||
vorteile:
|
||||
- "Vollständigkeit: Alle Ämter bleiben im Portfolio dokumentiert"
|
||||
- "Flexibilität: Bei Statusänderung einfache Umstellung"
|
||||
- "Saubere Priorisierung: Nur Wichtigkeit, nicht Machbarkeit"
|
||||
- "Reporting: Filter nach 'aktiv betreute Ämter' vs. 'Gesamtportfolio'"
|
||||
- "Transparenz: Gründe für eingeschränkte Zusammenarbeit dokumentiert"
|
||||
|
||||
entscheidungsbefugnis:
|
||||
rolle: "Leitung SHM"
|
||||
begruendung: |
|
||||
Die Entscheidung, ein Amt als 'ruhend' oder 'eingeschränkt' zu
|
||||
klassifizieren, hat strategische Konsequenzen und sollte nicht
|
||||
willkürlich getroffen werden. Die Leitung SHM hat den Gesamtüberblick
|
||||
über das Portfolio und kann die Entscheidung im Kontext bewerten.
|
||||
dokumentation: |
|
||||
Jede Entscheidung muss dokumentiert werden:
|
||||
- Wer hat entschieden (entschieden_von)
|
||||
- Wann wurde entschieden (entschieden_am)
|
||||
- Warum (begruendung)
|
||||
- Wann wird der Status überprüft (naechste_pruefung, empfohlen)
|
||||
|
||||
review:
|
||||
zyklus: "Im Portfolio-Review (E2-Standard/Erweitert)"
|
||||
inhalt: |
|
||||
Bei jedem Portfolio-Review wird geprüft:
|
||||
- Sind EINGESCHRÄNKT- und RUHEND-Status noch aktuell?
|
||||
- Haben sich Rahmenbedingungen geändert?
|
||||
- Sollten Ämter reaktiviert werden?
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 1: AMTS-STECKBRIEF
|
||||
# =============================================================================
|
||||
|
||||
ebene_1_amtssteckbrief:
|
||||
|
||||
beschreibung: |
|
||||
Jede Organisationseinheit im Scope erhält einen Amts-Steckbrief.
|
||||
Dieser enthält alle Informationen, die für die drei Kernentscheidungen
|
||||
(Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung) benötigt
|
||||
werden.
|
||||
|
||||
herleitung: |
|
||||
Die Attribute des Steckbriefs sind nicht willkürlich gewählt, sondern
|
||||
leiten sich aus den Kernentscheidungen ab. Jedes Attribut muss
|
||||
mindestens eine der drei Entscheidungen unterstützen. Attribute ohne
|
||||
klaren Entscheidungsbezug werden nicht erfasst.
|
||||
|
||||
attribut_kategorien:
|
||||
|
||||
- kategorie: "Stammdaten"
|
||||
zweck: "Identifikation und organisatorische Einordnung"
|
||||
entscheidungsbezug: "Alle (PKE-1, PKE-2, PKE-3)"
|
||||
beispiele:
|
||||
- "Amt/Organisationseinheit"
|
||||
- "Dezernat"
|
||||
- "Amtsleitung"
|
||||
- "SLA-Befugnis (wer hat Entscheidungsbefugnis)"
|
||||
|
||||
- kategorie: "Segmentierung"
|
||||
zweck: "Einordnung in die zweidimensionale Matrix"
|
||||
entscheidungsbezug: "PKE-2 Bedarfsrouting, PKE-3 Governance"
|
||||
beispiele:
|
||||
- "Funktion (Sondereinheit/Querschnitt/Bürgerservice/Fachamt)"
|
||||
- "IT-Anforderungsprofil (Basis/Erweitert/Spezial)"
|
||||
|
||||
- kategorie: "Priorisierung"
|
||||
zweck: "Bewertung für Betreuungsallokation"
|
||||
entscheidungsbezug: "PKE-1 Betreuungsallokation"
|
||||
beispiele:
|
||||
- "Einfluss (boolean)"
|
||||
- "Abhängigkeit (boolean)"
|
||||
- "Relevanz (boolean)"
|
||||
- "Prio-Stufe (abgeleitet)"
|
||||
- "Betreuungsmodus (abgeleitet)"
|
||||
|
||||
- kategorie: "Governance"
|
||||
zweck: "Gremien-Zuordnung und Vertretungslogik"
|
||||
entscheidungsbezug: "PKE-3 Governance-Zuordnung"
|
||||
beispiele:
|
||||
- "Gremien-Mitgliedschaften"
|
||||
|
||||
- kategorie: "Betreuung"
|
||||
zweck: "Operative Beziehungspflege"
|
||||
entscheidungsbezug: "E1 Betreuungsallokation"
|
||||
beispiele:
|
||||
- "Zugeordneter Stakeholder-Manager"
|
||||
- "Beziehungsqualität"
|
||||
- "Aktive Themen"
|
||||
|
||||
schema_verweis: |
|
||||
Das vollständige Attribut-Schema mit Datentypen, Wertelisten und
|
||||
Validierungsregeln ist in shm_schema_amtssteckbrief.yaml dokumentiert.
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 2: SEGMENTIERUNG
|
||||
# =============================================================================
|
||||
|
||||
ebene_2_segmentierung:
|
||||
|
||||
beschreibung: |
|
||||
Die Segmentierung erfolgt zweidimensional. Beide Dimensionen sind
|
||||
unabhängig voneinander. Jedes Amt erhält genau eine Ausprägung pro
|
||||
Dimension (keine Mehrfachzuordnung, keine Tags).
|
||||
|
||||
governance_referenz: "GOV-SHM-002"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSION 1: FUNKTION
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimension_1_funktion:
|
||||
|
||||
name: "Funktion"
|
||||
beschreibung: "Organisatorische Rolle des Amtes in der Stadtverwaltung"
|
||||
|
||||
governance_referenz: "GOV-SHM-003"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "SONDER"
|
||||
name: "Sondereinheit"
|
||||
charakteristik: |
|
||||
Organisatorisch eigenständig, eigene Rechtsform oder
|
||||
Sonderstatus (Eigenbetriebe, Stabsstellen, Projektgruppen)
|
||||
beispiele:
|
||||
- "Eigenbetrieb Stadtentwässerung"
|
||||
- "Eigenbetrieb Theater"
|
||||
- "Stabsstelle Digitalisierung"
|
||||
|
||||
- id: "QUER"
|
||||
name: "Querschnittsamt"
|
||||
charakteristik: |
|
||||
Erbringt interne Dienstleistungen für andere Ämter,
|
||||
hat Multiplikator-Wirkung
|
||||
beispiele:
|
||||
- "Haupt- und Personalamt"
|
||||
- "Stadtkämmerei"
|
||||
- "Rechtsamt"
|
||||
|
||||
- id: "BUERGER"
|
||||
name: "Bürgerservice"
|
||||
charakteristik: |
|
||||
Direkter Bürgerkontakt als Kernaufgabe,
|
||||
hohe externe Sichtbarkeit
|
||||
beispiele:
|
||||
- "Amt für Bürgerservice"
|
||||
- "Standesamt"
|
||||
- "Amt für Soziales"
|
||||
|
||||
- id: "FACH"
|
||||
name: "Fachamt"
|
||||
charakteristik: |
|
||||
Spezialisierte Fachaufgaben, oft technisch geprägt,
|
||||
geringerer direkter Bürgerkontakt
|
||||
beispiele:
|
||||
- "Stadtplanungsamt"
|
||||
- "Garten- und Tiefbauamt"
|
||||
- "Umweltschutzamt"
|
||||
|
||||
zuordnungslogik:
|
||||
|
||||
grundprinzip: |
|
||||
Die Funktionszuordnung unterscheidet zwischen Primärfunktion
|
||||
(steuernd) und Sekundärfunktion (informierend).
|
||||
|
||||
- Primärfunktion: Bestimmt Bedarfsrouting und Governance-Zuordnung
|
||||
- Sekundärfunktion: Dokumentiert Kontext für differenzierte Betrachtung
|
||||
|
||||
Nicht jedes Amt hat eine Sekundärfunktion. Sie wird nur vergeben,
|
||||
wenn ein Amt deutlich erkennbare Charakteristika einer zweiten
|
||||
Funktionskategorie aufweist.
|
||||
|
||||
governance_referenz: "GOV-SHM-027"
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# PRIMÄRFUNKTIONSBESTIMMUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
primaerfunktion:
|
||||
|
||||
beschreibung: |
|
||||
Die Primärfunktion wird durch einen Entscheidungsbaum bestimmt.
|
||||
Die erste zutreffende Kategorie gewinnt (Dominanzprinzip).
|
||||
|
||||
entscheidungsbaum:
|
||||
|
||||
schritt_1:
|
||||
frage: "Ist das Amt organisatorisch eigenständig?"
|
||||
indikatoren:
|
||||
- "Eigene Rechtsform (Eigenbetrieb)"
|
||||
- "Sonderstatus (Stabsstelle, Projektgruppe)"
|
||||
- "Nicht in regulärer Amtsstruktur eingegliedert"
|
||||
ja: "SONDER (Sondereinheit)"
|
||||
nein: "weiter zu Schritt 2"
|
||||
|
||||
schritt_2:
|
||||
frage: "Erbringt das Amt primär interne Dienstleistungen für andere Ämter?"
|
||||
indikatoren:
|
||||
- "Hauptaufgabe ist Unterstützung anderer Ämter"
|
||||
- "Querschnittsfunktion (Personal, Finanzen, Recht, IT, Organisation)"
|
||||
- "Multiplikator-Wirkung auf andere Ämter"
|
||||
ja: "QUER (Querschnittsamt)"
|
||||
nein: "weiter zu Schritt 3"
|
||||
|
||||
schritt_3:
|
||||
frage: "Hat das Amt direkten Bürgerkontakt als Kernaufgabe?"
|
||||
indikatoren:
|
||||
- "Publikumsverkehr ist zentrale Aufgabe"
|
||||
- "Bürger:innen sind primäre Zielgruppe"
|
||||
- "Hohe externe Sichtbarkeit durch Bürger-Interaktion"
|
||||
ja: "BUERGER (Bürgerservice)"
|
||||
nein: "FACH (Fachamt)"
|
||||
|
||||
entscheidungshilfe_bei_mehrdeutigkeit: |
|
||||
Wenn ein Amt mehrere Charakteristika erfüllt, gilt:
|
||||
|
||||
1. Dominanzprinzip anwenden: Die erste zutreffende Kategorie
|
||||
im Entscheidungsbaum bestimmt die Primärfunktion.
|
||||
|
||||
2. Hauptaufgabe identifizieren: Was ist der Kern-Auftrag des Amtes
|
||||
laut Dezernatsverteilungsplan oder Geschäftsverteilungsplan?
|
||||
|
||||
3. Ressourcenallokation prüfen: Wohin fließen die meisten Ressourcen
|
||||
(Personal, Budget, Zeit)?
|
||||
|
||||
4. Selbstverständnis einbeziehen: Wie beschreibt das Amt selbst
|
||||
seine Hauptaufgabe?
|
||||
|
||||
Beispiel Stadtkämmerei:
|
||||
- Erfüllt Querschnitts-Kriterien (Finanzdienstleistungen für alle Ämter)
|
||||
- Hat auch Fachamt-Charakteristika (spezialisierte Haushaltsführung)
|
||||
→ Primärfunktion: QUER (Querschnittsamt), da interne Dienstleistung
|
||||
die Kernaufgabe ist
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# SEKUNDÄRFUNKTIONSBESTIMMUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
sekundaerfunktion:
|
||||
|
||||
beschreibung: |
|
||||
Die Sekundärfunktion dokumentiert eine zusätzliche Funktions-
|
||||
charakteristik, die für Kontext und differenzierte Betrachtung
|
||||
relevant ist.
|
||||
|
||||
vergabe_kriterien: |
|
||||
Eine Sekundärfunktion wird vergeben, wenn:
|
||||
|
||||
1. Das Amt deutlich erkennbare Charakteristika einer zweiten
|
||||
Funktionskategorie aufweist (nicht nur marginal)
|
||||
|
||||
2. Diese zweite Funktion für Bedarfsrouting oder Governance
|
||||
relevant sein kann (z.B. Bedarfe, die eher zur Sekundär-
|
||||
funktion passen)
|
||||
|
||||
3. Die Zuordnung nachvollziehbar begründet werden kann
|
||||
|
||||
nicht_vergeben_wenn: |
|
||||
Keine Sekundärfunktion, wenn:
|
||||
|
||||
- Das Amt klar einer einzigen Kategorie zuzuordnen ist
|
||||
- Die zweite Charakteristik nur marginal ausgeprägt ist
|
||||
- Kein praktischer Nutzen für Routing oder Governance erkennbar ist
|
||||
|
||||
moegliche_kombinationen:
|
||||
|
||||
- primaer: "QUER"
|
||||
sekundaer: "FACH"
|
||||
typisch: true
|
||||
beispiel: "Stadtkämmerei (Querschnitt + spezialisierte Haushaltsführung)"
|
||||
|
||||
- primaer: "QUER"
|
||||
sekundaer: "BUERGER"
|
||||
typisch: false
|
||||
beispiel: "Haupt- und Personalamt mit Bürgerbüro-Funktion"
|
||||
|
||||
- primaer: "BUERGER"
|
||||
sekundaer: "FACH"
|
||||
typisch: true
|
||||
beispiel: "Amt für Soziales (Bürgerservice + spezialisierte Sozialarbeit)"
|
||||
|
||||
- primaer: "FACH"
|
||||
sekundaer: "BUERGER"
|
||||
typisch: true
|
||||
beispiel: "Baurechtsamt (Fachamt + Bauberatung für Bürger:innen)"
|
||||
|
||||
- primaer: "FACH"
|
||||
sekundaer: "QUER"
|
||||
typisch: false
|
||||
beispiel: "IT-Amt mit internen Dienstleistungen (eher selten)"
|
||||
|
||||
- primaer: "SONDER"
|
||||
sekundaer: "beliebig"
|
||||
typisch: true
|
||||
beispiel: "Eigenbetrieb mit Bürgerservice-Anteil"
|
||||
|
||||
ausgeschlossene_kombinationen:
|
||||
- kombination: "gleiche Primär- und Sekundärfunktion"
|
||||
grund: "Logisch unmöglich"
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# OPERATIVE ANWENDUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
verwendung_primaerfunktion:
|
||||
- "Bedarfsrouting (PKE-2): Bestimmt typisches Bedarfsprofil"
|
||||
- "Governance-Zuordnung (PKE-3): Bestimmt Gremien-Mitgliedschaften"
|
||||
- "Betreuungsallokation (PKE-1): Kontextinformation für Priorisierung"
|
||||
|
||||
verwendung_sekundaerfunktion:
|
||||
- "Bedarfsrouting: Differenzierte Betrachtung bei Bedarfen, die eher
|
||||
zur Sekundärfunktion passen"
|
||||
- "Governance: Optionale Einbindung in Gremien der Sekundärkategorie"
|
||||
- "Bedarfsvorhersage: Vollständigeres Bild des typischen Bedarfsprofils"
|
||||
- "Transparenz: Dokumentation für Nachvollziehbarkeit"
|
||||
|
||||
steuerungsprinzip: |
|
||||
Primärfunktion steuert, Sekundärfunktion informiert.
|
||||
|
||||
Bei Entscheidungen (Routing, Governance) ist die Primärfunktion
|
||||
maßgeblich. Die Sekundärfunktion kann bei begründeten Ausnahmen
|
||||
herangezogen werden, überschreibt aber nie die Primärfunktion.
|
||||
|
||||
dokumentationspflicht: |
|
||||
Bei Vergabe einer Sekundärfunktion muss im Amts-Steckbrief eine
|
||||
Begründung dokumentiert werden, die erklärt:
|
||||
- Warum das Amt Charakteristika der Sekundärkategorie aufweist
|
||||
- Welche praktische Relevanz die Sekundärfunktion hat
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSION 2: IT-ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimension_2_it_profil:
|
||||
|
||||
name: "IT-Anforderungsprofil"
|
||||
beschreibung: |
|
||||
Komplexität der IT-Bedarfe des Amtes. Die Dimension ist
|
||||
bedarfsorientiert (nicht nutzungsorientiert), um zukünftige
|
||||
Bedarfe vorherzusagen, nicht nur den Status quo abzubilden.
|
||||
|
||||
governance_referenz: "GOV-SHM-004"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "BASIS"
|
||||
name: "Basis"
|
||||
charakteristik: |
|
||||
Standardbedarf, Grundausstattung reicht aus,
|
||||
geringe IT-Komplexität
|
||||
spm_korrespondenz: "Kategorie A – Basis-Services"
|
||||
typische_services:
|
||||
- "Standard-Arbeitsplatz (Büro-PC, Office-Anwendungen)"
|
||||
- "E-Mail und Kalender"
|
||||
- "Zugang zu zentralen Verwaltungssystemen"
|
||||
beispiele:
|
||||
- "Rechtsamt"
|
||||
- "Rechnungsprüfungsamt"
|
||||
- "Standesamt"
|
||||
|
||||
- id: "ERWEITERT"
|
||||
name: "Erweitert"
|
||||
charakteristik: |
|
||||
Fachspezifische Bedarfe über Standard hinaus,
|
||||
mittlere IT-Komplexität. Häufig: Benötigt Zugriff auf
|
||||
Daten im Außendienst – erbringt einen erheblichen Teil
|
||||
der Arbeit außerhalb des Bürostandorts und benötigt dabei
|
||||
Zugriff auf städtische oder weitere relevante Daten
|
||||
(Baupläne, Elektropläne, Meldedaten, KFZ-Daten etc.).
|
||||
spm_korrespondenz: "Kategorie B – Erweiterte Services"
|
||||
typische_services:
|
||||
- "Mobile Hardware (VPN-Notebook, EC-Cash-Gerät etc.)"
|
||||
- "Zugriffe auf interne Daten außerhalb vom Bürostandort"
|
||||
- "Fachverfahren mit erweitertem Funktionsumfang"
|
||||
- "DMS, Terminbuchung, Workflow-Systeme"
|
||||
beispiele:
|
||||
- "Haupt- und Personalamt"
|
||||
- "Amt für Bürgerservice"
|
||||
- "Umweltschutzamt"
|
||||
|
||||
- id: "SPEZIAL"
|
||||
name: "Spezial"
|
||||
charakteristik: |
|
||||
Individuelle Bedarfe, die nur für dieses Amt gelten,
|
||||
hohe IT-Komplexität, Spezialsoftware, bilaterale SLAs.
|
||||
Arbeiten aus dem Homeoffice oft nur durch besondere
|
||||
Lösungen möglich (Standard-Homeoffice-Lösungen greifen nicht).
|
||||
spm_korrespondenz: "Kategorie C – Spezial-Services"
|
||||
typische_services:
|
||||
- "Exklusive Fachsoftware (CAD, GIS, Spezialsysteme)"
|
||||
- "Spezialhardware (Plotter, Messgeräte, Spezialdrucker)"
|
||||
- "Individuelle Schnittstellenlösungen"
|
||||
- "Besondere Homeoffice-/Remote-Lösungen"
|
||||
beispiele:
|
||||
- "Stadtplanungsamt (CAD, GIS)"
|
||||
- "Garten- und Tiefbauamt"
|
||||
- "Immobilienmanagement (Eigenbetrieb)"
|
||||
|
||||
zuordnungslogik: |
|
||||
Entscheidungsbaum:
|
||||
|
||||
1. Hat das Amt individuelle IT-Bedarfe, die NUR für dieses Amt
|
||||
gelten? (exklusive Fachsoftware, Spezialhardware, bilaterale SLAs)
|
||||
→ JA: Spezial
|
||||
→ NEIN: weiter zu 2.
|
||||
|
||||
2. Hat das Amt fachspezifische IT-Bedarfe über die Grundausstattung
|
||||
hinaus? (DMS, Fachverfahren, Terminbuchung, Workflow-Systeme)
|
||||
→ JA: Erweitert
|
||||
→ NEIN: Basis
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MATRIX
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
matrix:
|
||||
|
||||
beschreibung: |
|
||||
Die Kombination der beiden Dimensionen ergibt eine 4×3-Matrix.
|
||||
Jedes Amt wird genau einem Feld zugeordnet. Nicht alle
|
||||
Kombinationen sind gleich häufig oder wahrscheinlich.
|
||||
|
||||
governance_referenz: "GOV-SHM-006"
|
||||
|
||||
hinweis_sondereinheiten: |
|
||||
Sondereinheiten sind eine Funktionskategorie, keine Ausnahme
|
||||
von der zweidimensionalen Logik. Sie haben wie alle anderen
|
||||
Ämter ein IT-Anforderungsprofil.
|
||||
|
||||
unwahrscheinliche_kombinationen:
|
||||
- kombination: "Querschnitt + Spezial"
|
||||
begruendung: |
|
||||
Querschnittsämter erbringen standardisierte interne Services.
|
||||
Hochspezialisierte IT-Bedarfe sind untypisch.
|
||||
- kombination: "Bürgerservice + Spezial"
|
||||
begruendung: |
|
||||
Bürgerservice-Ämter nutzen typischerweise standardisierte
|
||||
Bürger-Fachverfahren, keine exklusiven Spezial-Lösungen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# VERKNÜPFUNG ZU ENTSCHEIDUNGEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
verknuepfung_entscheidungen:
|
||||
|
||||
bedarfsrouting_PKE2:
|
||||
relevante_dimensionen: "Funktion + IT-Profil"
|
||||
logik: |
|
||||
Die Kombination hilft, typische Bedarfe vorherzusagen:
|
||||
- Bürgerservice + Erweitert → Terminbuchung, Aufrufsysteme, DMS
|
||||
- Fachamt + Spezial → CAD, GIS, Spezialhardware
|
||||
- Querschnitt + Erweitert → Personalverwaltung, Finanz-Systeme
|
||||
|
||||
governance_zuordnung_PKE3:
|
||||
relevante_dimension: "IT-Anforderungsprofil"
|
||||
logik: |
|
||||
Das IT-Profil korrespondiert mit SPM-Kategorien und damit
|
||||
mit der SLA-Governance:
|
||||
- Basis-Profil → primär in Kundenvertretung Basisservices (Kat. A)
|
||||
- Erweitert-Profil → in servicespezifischen Kundenvertretungen (Kat. B)
|
||||
- Spezial-Profil → bilaterale SLAs (Kat. C)
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 3: PRIORISIERUNG
|
||||
# =============================================================================
|
||||
|
||||
ebene_3_priorisierung:
|
||||
|
||||
beschreibung: |
|
||||
Die Priorisierung identifiziert innerhalb der Segmente die
|
||||
Key-Stakeholder und leitet den Betreuungsmodus ab. Sie basiert
|
||||
auf drei Dimensionen, die binär (ja/nein) bewertet werden.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSIONEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimensionen:
|
||||
|
||||
governance_referenz: "GOV-SHM-007"
|
||||
|
||||
bewertungslogik: |
|
||||
Jede Dimension wird binär bewertet (ja/nein). Die Bewertung
|
||||
erfolgt durch den Stakeholder-Manager mit dokumentierter
|
||||
Begründung. Die Begründung macht die Einschätzung
|
||||
nachvollziehbar und überprüfbar.
|
||||
|
||||
dimension_1_einfluss:
|
||||
|
||||
id: "E"
|
||||
name: "Einfluss"
|
||||
leitfrage: "Kann das Amt DIGIT-relevante Entscheidungen beeinflussen?"
|
||||
|
||||
indikatoren:
|
||||
- "Entscheidungsbefugnis über IT-Budgets oder IT-Standards"
|
||||
- "Multiplikator-Rolle durch Größe oder Querschnittsfunktion"
|
||||
- "Politisches Gewicht in Verwaltungsgremien"
|
||||
|
||||
beispiele_ja:
|
||||
- "Haupt- und Personalamt (IT-Standards für alle)"
|
||||
- "Stadtkämmerei (IT-Budget-Allokation)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Standesamt (kein übergreifender Einfluss)"
|
||||
|
||||
dimension_2_abhaengigkeit:
|
||||
|
||||
id: "A"
|
||||
name: "Abhängigkeit"
|
||||
leitfrage: "Steht das Amt ohne IT still?"
|
||||
|
||||
indikatoren:
|
||||
- "Kernprozesse sind IT-abhängig"
|
||||
- "Externe Schnittstellen setzen funktionierende IT voraus"
|
||||
- "IT-Ausfall führt zu unmittelbarem Leistungsausfall"
|
||||
|
||||
beispiele_ja:
|
||||
- "Amt für Bürgerservice (alle Prozesse IT-basiert)"
|
||||
- "Stadtkasse (Zahlungsverkehr)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Kulturamt (kann temporär analog arbeiten)"
|
||||
|
||||
dimension_3_relevanz:
|
||||
|
||||
id: "R"
|
||||
name: "Relevanz"
|
||||
leitfrage: "Ist das Amt gerade besonders wichtig für die Gesamtverwaltung?"
|
||||
|
||||
indikatoren:
|
||||
- "Hohe politische oder öffentliche Sichtbarkeit"
|
||||
- "Beteiligung an strategischen Projekten"
|
||||
- "Aktuelle Krisensituation oder Transformationsphase"
|
||||
|
||||
charakteristik: |
|
||||
Diese Dimension ist dynamisch und kann sich über Zeit ändern.
|
||||
Sie erfordert regelmäßige Überprüfung im Portfolio-Review.
|
||||
|
||||
beispiele_ja:
|
||||
- "Amt für Digitalisierung (strategisches Projekt)"
|
||||
- "Amt für öffentliche Ordnung (bei Großveranstaltungen)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Forstamt (stabile Situation, geringe Sichtbarkeit)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GEWICHTUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gewichtung:
|
||||
|
||||
governance_referenz: "GOV-SHM-008"
|
||||
|
||||
logik: |
|
||||
Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt
|
||||
beeinflussen können – sei es durch Budget-Entscheidungen,
|
||||
Standard-Setzung oder politisches Gewicht.
|
||||
|
||||
Gewichtung: Einfluss > Abhängigkeit = Relevanz
|
||||
|
||||
begruendung: |
|
||||
Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen
|
||||
von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist
|
||||
strategisch wichtiger als zu Ämtern, die "nur" abhängig sind.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KOMBINATIONSLOGIK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kombinationslogik:
|
||||
|
||||
governance_referenz: "GOV-SHM-009"
|
||||
|
||||
prio_stufen:
|
||||
|
||||
- stufe: "Key"
|
||||
kombination: "Alle drei ODER Einfluss + eine weitere"
|
||||
beschreibung: "Strategisch wichtigste Stakeholder"
|
||||
|
||||
- stufe: "Aktiv"
|
||||
kombination: "Zwei (ohne Einfluss) ODER nur Einfluss"
|
||||
beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung"
|
||||
|
||||
- stufe: "Standard"
|
||||
kombination: "Eine (Abhängigkeit oder Relevanz)"
|
||||
beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf"
|
||||
|
||||
- stufe: "Basis"
|
||||
kombination: "Keine Dimension erfüllt"
|
||||
beschreibung: "Stakeholder mit reaktiver Betreuung"
|
||||
|
||||
kombinationstabelle: |
|
||||
|
||||
│ E │ A │ R │ Prio-Stufe │
|
||||
├───┼───┼───┼────────────┤
|
||||
│ ✓ │ ✓ │ ✓ │ Key │
|
||||
│ ✓ │ ✓ │ – │ Key │
|
||||
│ ✓ │ – │ ✓ │ Key │
|
||||
│ – │ ✓ │ ✓ │ Aktiv │
|
||||
│ ✓ │ – │ – │ Aktiv │
|
||||
│ – │ ✓ │ – │ Standard │
|
||||
│ – │ – │ ✓ │ Standard │
|
||||
│ – │ – │ – │ Basis │
|
||||
|
||||
Legende: E = Einfluss, A = Abhängigkeit, R = Relevanz
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# BETREUUNGSMODUS
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
betreuungsmodus:
|
||||
|
||||
governance_referenz: "GOV-SHM-010"
|
||||
|
||||
beschreibung: |
|
||||
Der Betreuungsmodus wird aus der Prio-Stufe abgeleitet und
|
||||
definiert die Art und Intensität der Stakeholder-Betreuung.
|
||||
|
||||
modi:
|
||||
|
||||
- prio_stufe: "Key"
|
||||
modus: "Proaktiv/Dediziert"
|
||||
beschreibung: |
|
||||
Regelmäßige Turnusgespräche (z.B. halbjährlich),
|
||||
dedizierter Stakeholder-Manager,
|
||||
aktive Bedarfserhebung,
|
||||
Einladung zu strategischen Abstimmungen
|
||||
|
||||
- prio_stufe: "Aktiv"
|
||||
modus: "Regelmäßig"
|
||||
beschreibung: |
|
||||
Teilnahme am Cluster-Advisory-Board,
|
||||
anlassbezogene Gespräche,
|
||||
Einladung zu relevanten Themen
|
||||
|
||||
- prio_stufe: "Standard"
|
||||
modus: "Eingebunden"
|
||||
beschreibung: |
|
||||
Teilnahme am Cluster-Advisory-Board,
|
||||
reaktive Betreuung bei Anfragen
|
||||
|
||||
- prio_stufe: "Basis"
|
||||
modus: "Reaktiv"
|
||||
beschreibung: |
|
||||
Keine proaktive Betreuung,
|
||||
nur bei eingehenden Anfragen,
|
||||
Information über allgemeine Kanäle
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ÜBERPRÜFUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
ueberpruefung:
|
||||
|
||||
governance_referenz: "GOV-SHM-012"
|
||||
|
||||
beschreibung: |
|
||||
Die Priorisierung wird periodisch überprüft, insbesondere
|
||||
die Dimension "Relevanz", die sich über Zeit ändern kann.
|
||||
|
||||
zyklus: |
|
||||
Im Rahmen der Koordinations- und Steuerungsstruktur
|
||||
(shm_koordinations-und-steuerungsstruktur.yaml):
|
||||
- REV-2-Standard (Q1/Q3): Portfolio-Analyse
|
||||
- REV-2-Erweitert (Q2/Q4): Portfolio-Analyse + Verbesserungsplanung
|
||||
|
||||
voc_integration: |
|
||||
Die Portfolio-Überprüfung nutzt VoC-Erkenntnisse (shm_voice-of-customer.yaml)
|
||||
zu Beziehungsqualität, Zufriedenheit und Bedarfsentwicklung, um
|
||||
Priorisierungen und Betreuungsmodi anzupassen.
|
||||
|
||||
stabilität_der_dimensionen:
|
||||
einfluss: "Relativ stabil (Organisationsstruktur)"
|
||||
abhaengigkeit: "Relativ stabil (Prozessstruktur)"
|
||||
relevanz: "Dynamisch (politische Themen, strategische Projekte)"
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNG SPM
|
||||
# =============================================================================
|
||||
|
||||
verknuepfung_spm:
|
||||
|
||||
beschreibung: |
|
||||
Das SHM-Stakeholder-Portfolio ist mit dem SPM-Service-Portfolio
|
||||
über harmonisierte Terminologie und Governance-Brücken verknüpft.
|
||||
|
||||
governance_referenz: "GOV-SHM-005"
|
||||
|
||||
terminologie_mapping:
|
||||
|
||||
beschreibung: |
|
||||
Die IT-Anforderungsprofile im SHM korrespondieren mit den
|
||||
Service-Kategorien im SPM. Die Terminologie wurde bewusst
|
||||
harmonisiert.
|
||||
|
||||
mapping:
|
||||
- shm_profil: "Basis"
|
||||
spm_kategorie: "A – Basis-Services"
|
||||
- shm_profil: "Erweitert"
|
||||
spm_kategorie: "B – Erweiterte Services"
|
||||
- shm_profil: "Spezial"
|
||||
spm_kategorie: "C – Spezial-Services"
|
||||
|
||||
governance_bruecke: |
|
||||
Die Verknüpfung ermöglicht eine systematische Governance-Zuordnung:
|
||||
|
||||
SHM: Amt hat Profil "Erweitert"
|
||||
↓
|
||||
SPM: Amt nutzt wahrscheinlich Kategorie-B-Services
|
||||
↓
|
||||
Governance: Amt ist potenziell in Kundenvertretungen für B-Services
|
||||
|
||||
sla_befugnis: |
|
||||
Die SLA-Befugnis im Amts-Steckbrief folgt der gleichen Logik wie
|
||||
im SPM (P-02 SLM): Primär Amtsleitung, alternativ delegierte Person
|
||||
mit dokumentierter Entscheidungsbefugnis.
|
||||
|
||||
Governance-Referenz: GOV-SHM-013
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2025-12-03"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: "Initiale Erstellung basierend auf Phase-1-Konzeptentwicklung"
|
||||
governance_basis: "GOV-SHM-001 bis GOV-SHM-014"
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2025-12-10"
|
||||
autor: "Cross-Check Phase 5"
|
||||
aenderung: |
|
||||
- Überprüfungs-Abschnitt erweitert:
|
||||
- Veraltete Phase-7-Referenz aktualisiert auf
|
||||
shm_koordinations-und-steuerungsstruktur.yaml
|
||||
- VoC-Integration ergänzt (Nutzung von VoC-Erkenntnissen für
|
||||
Portfolio-Überprüfung)
|
||||
- Zyklus präzisiert (E2-Standard und E2-Erweitert)
|
||||
|
||||
- version: "1.2"
|
||||
datum: "2026-01-23"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
- Dimension 1 (Funktion) erweitert um Primär-/Sekundärfunktionslogik:
|
||||
- Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung
|
||||
- Entscheidungshilfe bei Mehrdeutigkeit
|
||||
- Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien
|
||||
- Dokumentation möglicher und ausgeschlossener Kombinationen
|
||||
- Operative Anwendung mit Steuerungsprinzip
|
||||
- Dokumentationspflicht bei Sekundärfunktion
|
||||
governance_referenz: "GOV-SHM-027"
|
||||
|
||||
- version: "1.3"
|
||||
datum: "2026-01-23"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Betreuungsstatus-Konzept (GOV-SHM-028):
|
||||
- Neuer Abschnitt 'betreuungsstatus_konzept' eingefügt
|
||||
- Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND
|
||||
- Dokumentation der Deckelungslogik für effektiven Betreuungsmodus
|
||||
- Entscheidungsbefugnis bei Leitung SHM
|
||||
- Review im Portfolio-Review (E2-Standard/Erweitert)
|
||||
- Ergänzung im Drei-Ebenen-Modell
|
||||
governance_referenz: "GOV-SHM-028"
|
||||
|
||||
- version: "1.4"
|
||||
datum: "2026-01-26"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
IT-Anforderungsprofil präzisiert (dimension_2_it_profil):
|
||||
- Neues Attribut 'typische_services' bei allen drei Profilen ergänzt
|
||||
- BASIS: Standard-Arbeitsplatz, E-Mail/Kalender, zentrale Systeme
|
||||
- ERWEITERT: Mobile Hardware (VPN-Notebook, EC-Cash), Außendienst-
|
||||
Zugriffe, Fachverfahren, DMS/Workflow
|
||||
- SPEZIAL: Exklusive Fachsoftware, Spezialhardware, individuelle
|
||||
Schnittstellen, besondere Homeoffice-Lösungen
|
||||
- Charakteristik ERWEITERT ergänzt um Außendienst-Beschreibung
|
||||
- Charakteristik SPEZIAL ergänzt um Homeoffice-Einschränkung
|
||||
Loading…
Add table
Add a link
Reference in a new issue