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,668 @@
|
|||
meta:
|
||||
typ: "methodisches_framework"
|
||||
methode: "demand_klassifizierung"
|
||||
methode_name: "Demand-Klassifizierung: Mehrdimensionales Modell"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "klassifizierung"
|
||||
- "demand-management"
|
||||
- "entscheidungsunterstuetzung"
|
||||
- "routing-logik"
|
||||
- "gremien-zuordnung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: "Instrument zur besseren Koordination und Entscheidungsfindung in der Organisation"
|
||||
|
||||
funktionen:
|
||||
- id: "F01"
|
||||
name: "Strukturierung"
|
||||
beschreibung: "Überführung unterschiedlicher Anforderungen in ein einheitliches Schema"
|
||||
|
||||
- id: "F02"
|
||||
name: "Kommunikation"
|
||||
beschreibung: "Etablierung einer gemeinsamen Fachsprache zwischen allen Beteiligten"
|
||||
|
||||
- id: "F03"
|
||||
name: "Entscheidungsunterstützung"
|
||||
beschreibung: "Aufbereitung relevanter Informationen für Gremien"
|
||||
zielgruppen: ["dsr", "mission_board"]
|
||||
|
||||
- id: "F04"
|
||||
name: "Transparenz"
|
||||
beschreibung: "Sichtbarmachung von Abhängigkeiten und Bewertungsmechanismen"
|
||||
|
||||
- id: "F05"
|
||||
name: "Steuerung"
|
||||
beschreibung: "Identifikation von Handlungsschwerpunkten im Portfolio"
|
||||
|
||||
# ========================================
|
||||
# 2. KLASSIFIZIERUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
klassifizierungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Dimensionen zur systematischen Einordnung von Demands"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: TREIBER
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_treiber:
|
||||
id: "treiber"
|
||||
name: "Treiber (Impulsquelle)"
|
||||
leitfrage: "Woher kommt der Impuls für diesen Demand?"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "extern_regulatorisch"
|
||||
name: "Extern-Regulatorisch"
|
||||
beschreibung: "Gesetzliche Vorgaben, Compliance-Anforderungen, Aufsichtsbehörden"
|
||||
ursprung: "stadtextern"
|
||||
|
||||
charakteristika:
|
||||
- "Gesetzliche Vorgaben"
|
||||
- "OZG-Umsetzung"
|
||||
- "Compliance-Anforderungen"
|
||||
- "DSGVO-Anpassungen"
|
||||
- "Aufsichtsbehörden"
|
||||
- "IT-Sicherheitsgesetz"
|
||||
- "Barrierefreiheitsrichtlinien"
|
||||
|
||||
beispiele:
|
||||
- "Bürgerportal-Erweiterung (OZG)"
|
||||
- "DSGVO-Compliance-Maßnahme"
|
||||
- "Umsetzung IT-Sicherheitsgesetz"
|
||||
|
||||
handlungslogik: "Pflichtaufgabe, nicht verhandelbar"
|
||||
|
||||
- stufe: "extern_fachlich"
|
||||
name: "Extern-Fachlich"
|
||||
beschreibung: "Anforderungen von anderen Ämtern, Politik, Bürger:innen"
|
||||
ursprung: "stadtextern"
|
||||
|
||||
charakteristika:
|
||||
- "Anforderungen von anderen Ämtern (auch OB)"
|
||||
- "Politik"
|
||||
- "Bürger:innen"
|
||||
- "Strategische Themen anderer Ämter ohne regulatorischen Hintergrund"
|
||||
|
||||
beispiele:
|
||||
- "Anfrage Bürgermeisteramt für neue Plattform"
|
||||
- "Politischer Auftrag zur Digitalisierung"
|
||||
- "Bürger:innen-Initiative"
|
||||
|
||||
handlungslogik: "Aushandlung nötig, politisch sensibel"
|
||||
|
||||
- stufe: "intern_strategisch"
|
||||
name: "Intern-Strategisch"
|
||||
beschreibung: "Digitalisierungsstrategie, Organisationsziele, Innovationsinitiativen"
|
||||
ursprung: "digit_intern"
|
||||
|
||||
charakteristika:
|
||||
- "Digitalisierungsstrategie"
|
||||
- "KI-Strategie"
|
||||
- "Cloud-Migration"
|
||||
- "Organisationsziele"
|
||||
- "Innovationsinitiativen"
|
||||
|
||||
beispiele:
|
||||
- "Prozessautomatisierung"
|
||||
- "Smart-City-Vorhaben"
|
||||
- "KI-Pilotprojekt"
|
||||
|
||||
handlungslogik: "Gestaltungsspielraum vorhanden"
|
||||
|
||||
qualifizierung_hinweis: |
|
||||
Interne Demands durchlaufen einen Fast Track im SHM (10-15min Validation).
|
||||
Die Vorqualifizierung kann weniger detailliert sein als bei externen Demands.
|
||||
DPM kann bei Bedarf Nachforderungen über die Rückkopplungsschleife stellen
|
||||
(siehe shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm).
|
||||
|
||||
innovationsvorhaben_hinweis: |
|
||||
Innovationsvorhaben, die innerhalb einer Organisationseinheit erprobt werden,
|
||||
liegen außerhalb des DIGITOM-Steuerungskreises und erzeugen keinen Demand.
|
||||
|
||||
Ein Demand entsteht, sobald eine der folgenden Bedingungen eintritt:
|
||||
- Das Vorhaben benötigt Ressourcen (Personal, Budget, Infrastruktur) anderer Abteilungen
|
||||
- Das Vorhaben soll in den Regelbetrieb überführt werden (neuer Service)
|
||||
- Das Vorhaben erfordert eine strategische Entscheidung des Mission Boards
|
||||
|
||||
Ab diesem Moment gilt: Das Vorhaben ist ein interner Demand mit Treiber
|
||||
"intern_strategisch" und durchläuft denselben Prozess wie alle anderen Demands.
|
||||
Es gibt keinen gesonderten Innovationstrack innerhalb des DIGITOM.
|
||||
|
||||
- stufe: "intern_operativ"
|
||||
name: "Intern-Operativ"
|
||||
beschreibung: "Effizienzsteigerung, Betriebsoptimierung, technische Notwendigkeiten"
|
||||
ursprung: "digit_intern"
|
||||
|
||||
charakteristika:
|
||||
- "Performance-Verbesserung"
|
||||
- "Bugfixes"
|
||||
- "Wartungsfenster"
|
||||
- "Lizenzmanagement"
|
||||
- "Effizienzsteigerung"
|
||||
- "Betriebsoptimierung"
|
||||
|
||||
beispiele:
|
||||
- "Performance-Optimierung Service"
|
||||
- "Bugfix kritischer Fehler"
|
||||
- "Lizenzmanagement-Tool"
|
||||
|
||||
handlungslogik: "Operative Exzellenz"
|
||||
|
||||
qualifizierung_hinweis: |
|
||||
Interne Demands durchlaufen einen Fast Track im SHM (10-15min Validation).
|
||||
Die Vorqualifizierung kann weniger detailliert sein als bei externen Demands.
|
||||
DPM kann bei Bedarf Nachforderungen über die Rückkopplungsschleife stellen
|
||||
(siehe shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm).
|
||||
|
||||
interpretationshinweise:
|
||||
hierarchie: |
|
||||
Bei Mehrfachzuordnung gilt die Hierarchie:
|
||||
Extern-Regulatorisch > Extern-Fachlich > Intern-Strategisch > Intern-Operativ
|
||||
|
||||
systemgrenze: "\"Extern\" bedeutet: Impuls kommt von außerhalb DIGITs Systemgrenze"
|
||||
|
||||
politische_auftraege: "Politische Aufträge sind meist \"Extern-Fachlich\", es sei denn, sie basieren auf Gesetzen"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: TRAGWEITE
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_tragweite:
|
||||
id: "tragweite"
|
||||
name: "Tragweite (Veränderungstiefe)"
|
||||
leitfrage: "Wie tiefgreifend ist die Veränderung für Nutzer:innen und Organisation?"
|
||||
detail_matrix_referenz: "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "neugestaltung"
|
||||
name: "Neugestaltung (Transformativ)"
|
||||
beschreibung: "Grundlegende Neugestaltung"
|
||||
|
||||
indikatoren:
|
||||
- "Flächendeckende Schulungen"
|
||||
- "Systemablösung"
|
||||
- "Paradigmenwechsel"
|
||||
- "Komplett neue Arbeitsweise"
|
||||
- "Organisationsumbau"
|
||||
- "Kein Rückfall möglich"
|
||||
- "> 70% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "Einführung komplett neues Fachverfahren"
|
||||
- "Organisationsweite Prozessdigitalisierung"
|
||||
- "Systemablösung mit neuem Paradigma"
|
||||
|
||||
- stufe: "ausbau"
|
||||
name: "Ausbau (Evolutionär)"
|
||||
beschreibung: "Ausbau mit neuen Fähigkeiten"
|
||||
|
||||
indikatoren:
|
||||
- "Punktuelle Schulungen erforderlich"
|
||||
- "Neue Module"
|
||||
- "API-Erweiterungen"
|
||||
- "Prozessdigitalisierung"
|
||||
- "Neue Funktionen, aber bekannte Logik"
|
||||
- "Rückfall theoretisch möglich"
|
||||
- "20-70% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "Erweiterung bestehendes System um neue Funktionen"
|
||||
- "Neue Schnittstellen zu Drittsystemen"
|
||||
- "Digitalisierung einzelner Prozesse"
|
||||
|
||||
- stufe: "optimierung"
|
||||
name: "Optimierung (Inkrementell)"
|
||||
beschreibung: "Optimierung im Bestehenden"
|
||||
|
||||
indikatoren:
|
||||
- "Keine neuen Schulungen nötig"
|
||||
- "UI-Verbesserungen"
|
||||
- "Bugfixes"
|
||||
- "Kleinere Features"
|
||||
- "Nutzer:innen merken kaum Veränderung"
|
||||
- "Rückfall jederzeit möglich"
|
||||
- "< 20% der Nutzer betroffen"
|
||||
|
||||
beispiele:
|
||||
- "UI-Redesign ohne funktionale Änderungen"
|
||||
- "Performance-Verbesserungen"
|
||||
- "Bugfixes"
|
||||
|
||||
interpretationshinweise:
|
||||
gesamtbetrachtung: "Die Tragweite bezieht sich auf die Gesamtveränderung, nicht nur auf technische Aspekte"
|
||||
perspektive: "Bei Unsicherheit: Aus Nutzer:innen-Perspektive bewerten"
|
||||
change_management: "\"Transformativ\" impliziert meist Change-Management-Bedarf"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: SYSTEMEBENE
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_systemebene:
|
||||
id: "systemebene"
|
||||
name: "Systemebene (Technisch-fachliche Verortung)"
|
||||
leitfrage: "Auf welcher Ebene der IT-Landschaft wirkt der Demand?"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "infrastruktur"
|
||||
name: "Infrastruktur"
|
||||
beschreibung: "Technische Basiskomponenten ohne direkten Fachbezug"
|
||||
|
||||
beispiele:
|
||||
- "Server"
|
||||
- "Storage"
|
||||
- "Netzwerk"
|
||||
- "Virtualisierung"
|
||||
- "Backup"
|
||||
|
||||
- stufe: "produkt"
|
||||
name: "Produkt"
|
||||
beschreibung: "Bündelung von Ressourcen, die eigenständig Mehrwert liefern"
|
||||
|
||||
beispiele:
|
||||
- "CMS-Plattform"
|
||||
- "Formular-Engine"
|
||||
- "Datenbank-Cluster"
|
||||
|
||||
- stufe: "service"
|
||||
name: "Service"
|
||||
beschreibung: "Anwendung von Produkten in Service-Beziehungen"
|
||||
hinweis: "Service als konkrete Anwendung von Produkten für Nutzer:innen"
|
||||
|
||||
- stufe: "fachverfahren"
|
||||
name: "Fachverfahren"
|
||||
beschreibung: "Spezifische Geschäftsanwendungen für Fachdomänen"
|
||||
|
||||
beispiele:
|
||||
- "Einwohnermeldewesen"
|
||||
- "Kita-Platz-Vergabe"
|
||||
- "Bauakten-Management"
|
||||
|
||||
- stufe: "daten_integration"
|
||||
name: "Daten & Integration"
|
||||
beschreibung: "Schnittstellen, Datenhaltung, Austauschformate"
|
||||
|
||||
beispiele:
|
||||
- "XÖV-Standards"
|
||||
- "Data Warehouse"
|
||||
- "ETL-Prozesse"
|
||||
|
||||
- stufe: "querschnittskomponente"
|
||||
name: "Querschnitts-Komponente"
|
||||
beschreibung: "Übergreifende technische Komponente für multiple Fachverfahren"
|
||||
|
||||
beispiele:
|
||||
- "IAM"
|
||||
- "Monitoring"
|
||||
- "Logging"
|
||||
- "API-Gateway"
|
||||
- "Verschlüsselung"
|
||||
|
||||
interpretationshinweise:
|
||||
mehrfachbetroffenheit: "Ein Demand kann mehrere Ebenen betreffen → Hauptebene identifizieren"
|
||||
stakeholder_implikation: "Die Ebene bestimmt oft die involvierten Stakeholder"
|
||||
schwerpunkt: "Bei Unklarheit: Wo liegt der Schwerpunkt der Veränderung?"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: KOMPLEXITÄT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_komplexitaet:
|
||||
id: "komplexitaet"
|
||||
name: "Komplexität (Lösungsunsicherheit)"
|
||||
leitfrage: "Wie viel Unsicherheit besteht bezüglich Lösung und Umsetzung?"
|
||||
detail_matrix_referenz: "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
|
||||
auspraegungen:
|
||||
- stufe: "moderat"
|
||||
name: "Moderat"
|
||||
|
||||
indikatoren:
|
||||
- "1-2 beteiligte Teams DIGIT-intern"
|
||||
- "Bekannte Technologie"
|
||||
- "Klare Lösung erkennbar"
|
||||
- "< 50 PT Aufwand"
|
||||
- "Geringes Risiko"
|
||||
- "Keine externen Abhängigkeiten"
|
||||
|
||||
konsequenz: "Direkte Umsetzung möglich"
|
||||
|
||||
- stufe: "komplex"
|
||||
name: "Komplex"
|
||||
|
||||
indikatoren:
|
||||
- "3-4 beteiligte Teams DIGIT-intern"
|
||||
- "Analyse erforderlich"
|
||||
- "Lösungsoptionen vorhanden"
|
||||
- "50-200 PT Aufwand"
|
||||
- "Mittleres Risiko"
|
||||
- "1-2 externe Partner/Abhängigkeiten"
|
||||
|
||||
konsequenz: "Vorprojekt empfohlen"
|
||||
|
||||
- stufe: "hochkomplex"
|
||||
name: "Hochkomplex"
|
||||
|
||||
indikatoren:
|
||||
- "5+ Stakeholder"
|
||||
- "Neue Technologien"
|
||||
- "Grundsätzliche Unsicherheit"
|
||||
- "> 200 PT Aufwand"
|
||||
- "Hohes Risiko"
|
||||
- "2+ externe Partner/Abhängigkeiten"
|
||||
|
||||
konsequenz: "Exploration zwingend erforderlich"
|
||||
|
||||
interpretationshinweise:
|
||||
nichtlinearitaet: "Komplexität steigt exponentiell mit der Anzahl der Abhängigkeiten - nicht linear mit dem Aufwand"
|
||||
vorsichtsprinzip: "Bei Unsicherheit zwischen zwei Stufen: Die höhere Komplexität wählen (Vorsichtsprinzip)"
|
||||
zielkonflikte: "\"Hochkomplex\" ist oft ein Signal für grundsätzliche Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
# ========================================
|
||||
# 3. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 KLASSIFIZIERUNGSPROZESS
|
||||
# ----------------------------------
|
||||
|
||||
klassifizierungsprozess:
|
||||
beschreibung: "Strukturierter Ablauf zur Sicherstellung von Qualität und Nachvollziehbarkeit"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "S1"
|
||||
name: "Initiale Einordnung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: |
|
||||
Der:die zuständige DPM nimmt basierend auf den vorliegenden Informationen
|
||||
aus der Bedarfsqualifizierung vom SHM eine erste Einordnung in allen vier
|
||||
Klassifizierungs-Dimensionen vor.
|
||||
input: "bedarfs_steckbrief_von_shm"
|
||||
output: "initiale_klassifizierung_4_dimensionen"
|
||||
|
||||
- schritt_id: "S2"
|
||||
name: "Plausibilitätsprüfung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Prüfung auf Konsistenz und Vollständigkeit"
|
||||
|
||||
typische_prueffragen:
|
||||
- "Passt die Komplexitätseinstufung zur identifizierten Tragweite?"
|
||||
- "Sind alle relevanten Stakeholder berücksichtigt?"
|
||||
- "Gibt es Widersprüche zwischen den Dimensionen?"
|
||||
|
||||
- schritt_id: "S3"
|
||||
name: "Validierung bei Unsicherheit"
|
||||
verantwortlich: "dpm"
|
||||
trigger: "unklarheiten_nach_plausibilitaetspruefung"
|
||||
beschreibung: "Gezieltes Einbeziehen von Fachexpert:innen"
|
||||
art: "kurze Konsultation, nicht formaler Prozess"
|
||||
|
||||
typische_konsultationen:
|
||||
- rolle: "it_architektur"
|
||||
bei: "technische_komplexitaet_unklar"
|
||||
- rolle: "fachexpertinnen"
|
||||
bei: "fachliche_tragweite_unklar"
|
||||
- rolle: "spm"
|
||||
bei: "service_impact_unklar"
|
||||
|
||||
- schritt_id: "S4"
|
||||
name: "Dokumentation"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Validierte Klassifizierung in Demand-Entscheidungsvorlage überführen"
|
||||
|
||||
dokumentationspflicht:
|
||||
- "Einordnungen in allen 4 Dimensionen"
|
||||
- "Begründungen je Dimension"
|
||||
- "Ergänzende Klassifizierungs-Matrix (bei Tragweite & Komplexität)"
|
||||
- "Eventuelle Dissens-Punkte aus Validierung"
|
||||
|
||||
output: "dokumentierte_klassifizierung"
|
||||
|
||||
- schritt_id: "S5"
|
||||
name: "Routing-Entscheidung"
|
||||
verantwortlich: "dpm"
|
||||
beschreibung: "Zuordnung zum passenden Gremium basierend auf Klassifizierung"
|
||||
input: "dokumentierte_klassifizierung"
|
||||
output: "routing_entscheidung"
|
||||
|
||||
mechanismus: "Definierte Automatismen greifen, Raum für begründete Abweichungen im Indifferenzraum"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 ROUTING-LOGIK
|
||||
# ----------------------------------
|
||||
|
||||
routing_logik:
|
||||
beschreibung: "Die Klassifizierung bestimmt die Entscheidungsebene"
|
||||
|
||||
routing_regeln:
|
||||
- routing_ziel: "mission_board"
|
||||
gremium_name: "Mission Board"
|
||||
beschreibung: "Strategisch relevante, hochkomplexe oder transformative Demands"
|
||||
|
||||
bedingungen:
|
||||
operator: "OR"
|
||||
regeln:
|
||||
- dimension: "komplexitaet"
|
||||
operator: "="
|
||||
wert: "hochkomplex"
|
||||
|
||||
- dimension: "tragweite"
|
||||
operator: "="
|
||||
wert: "neugestaltung"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "treiber"
|
||||
operator: "="
|
||||
wert: "extern_regulatorisch"
|
||||
- dimension: "komplexitaet"
|
||||
operator: ">="
|
||||
wert: "komplex"
|
||||
|
||||
- routing_ziel: "dsr_mit_delegationsoption"
|
||||
gremium_name: "DSR mit Delegationsoption ans Mission Board"
|
||||
beschreibung: "Grenzfälle, die DSR entscheiden kann, aber Option zur Delegation hat"
|
||||
|
||||
bedingungen:
|
||||
operator: "OR"
|
||||
regeln:
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "tragweite"
|
||||
operator: "="
|
||||
wert: "ausbau"
|
||||
- dimension: "komplexitaet"
|
||||
operator: "="
|
||||
wert: "komplex"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "systemebene"
|
||||
operator: "="
|
||||
wert: "infrastruktur"
|
||||
- dimension: "tragweite"
|
||||
operator: ">="
|
||||
wert: "ausbau"
|
||||
|
||||
- kombination:
|
||||
operator: "AND"
|
||||
bedingungen:
|
||||
- dimension: "systemebene"
|
||||
operator: "="
|
||||
wert: "querschnittskomponente"
|
||||
- dimension: "tragweite"
|
||||
operator: ">="
|
||||
wert: "ausbau"
|
||||
|
||||
- dimension: "treiber"
|
||||
operator: "="
|
||||
wert: "extern_fachlich"
|
||||
|
||||
- routing_ziel: "dsr"
|
||||
gremium_name: "DSR"
|
||||
beschreibung: "Standard-Demands ohne strategische Implikation"
|
||||
|
||||
bedingungen:
|
||||
beschreibung: "Alle anderen Kombinationen, die nicht MB oder DSR-mit-Delegation triggern"
|
||||
typische_faelle:
|
||||
- "Operative Optimierungen"
|
||||
- "Moderate Komplexität"
|
||||
- "Inkrementelle Veränderungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 DELEGATIONSOPTION
|
||||
# ----------------------------------
|
||||
|
||||
delegationsoption:
|
||||
name: "Flexibler Umgang mit Grenzfällen"
|
||||
|
||||
zweck: |
|
||||
In der Praxis gibt es immer wieder Demands, die sich nicht eindeutig zuordnen lassen.
|
||||
Für diese Fälle sieht das Modell eine Delegationsoption vor – die Möglichkeit,
|
||||
Entscheidungen gezielt an das Mission Board weiterzugeben.
|
||||
|
||||
typische_anwendungsfaelle:
|
||||
- "Politisch unklare Themen, deren Auswirkungen schwer abschätzbar sind"
|
||||
- "Anforderungen, die sowohl fachliche als auch strategische Aspekte haben"
|
||||
- "Komplett neue Themen, für die es noch keine Erfahrungswerte gibt"
|
||||
|
||||
funktionsweise:
|
||||
- schritt: "DSR hat grundsätzlich Befugnis, Grenzfälle selbst zu entscheiden"
|
||||
- schritt: "Bei Unsicherheit kann DSR die Entscheidung ans Mission Board delegieren"
|
||||
- schritt: "Gründe für Delegation werden dokumentiert"
|
||||
- schritt: "Einmal pro Quartal prüft DPM, welche Fälle delegiert wurden und warum"
|
||||
|
||||
qualitaetssicherung:
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "dpm"
|
||||
analyse: "Muster in Delegationen identifizieren, ggf. Routing-Regeln anpassen"
|
||||
|
||||
# ========================================
|
||||
# 4. QUALITÄTSSICHERUNG UND WEITERENTWICKLUNG
|
||||
# ========================================
|
||||
|
||||
qualitaetssicherung:
|
||||
|
||||
kontroll_mechanismen:
|
||||
- name: "Quartals-Reviews"
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "dpm"
|
||||
aktivitaet: "Analyse der Routing-Entscheidungen und bei Bedarf Anpassung der Kriterien"
|
||||
|
||||
- name: "Gremien-Rückmeldung"
|
||||
quellen: ["dsr", "mission_board"]
|
||||
gegenstand: "Feedback zur Treffsicherheit der Klassifizierung"
|
||||
verwendung: "Continuous Improvement der Klassifizierungskriterien"
|
||||
|
||||
kontinuierliche_anpassung:
|
||||
prinzip: "Klassifizierungsmodell ist nicht statisch, sondern entwickelt sich bei Bedarf weiter"
|
||||
|
||||
anpassungstypen:
|
||||
- typ: "Neue Kategorien"
|
||||
beschreibung: "Können bei Bedarf ergänzt werden"
|
||||
trigger: "Neue Demand-Typen, die nicht abgebildet sind"
|
||||
|
||||
- typ: "Schwellenwerte"
|
||||
beschreibung: "Werden basierend auf Erfahrungen justiert"
|
||||
beispiel: "PT-Grenzen für Komplexität, Nutzer-%-Grenzen für Tragweite"
|
||||
|
||||
- typ: "Interpretationshilfen"
|
||||
beschreibung: "Werden kontinuierlich präzisiert"
|
||||
quelle: "Learnings aus konkreten Klassifizierungsfällen"
|
||||
|
||||
- typ: "Best Practices"
|
||||
beschreibung: "Werden dokumentiert und geteilt"
|
||||
zielgruppe: "Alle, die klassifizieren (primär DPM)"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATIONSSTANDARD
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
beschreibung: "Jede Klassifizierung wird standardisiert dokumentiert (als Teil der Demand-Entscheidungsvorlage)"
|
||||
|
||||
template_struktur:
|
||||
demand_titel: "[Titel des Demands]"
|
||||
|
||||
klassifizierung:
|
||||
- dimension: "treiber"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "tragweite"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "systemebene"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Kurz und prägnant]"
|
||||
|
||||
- dimension: "komplexitaet"
|
||||
auspraegung: "[Ausprägung]"
|
||||
begruendung: "[Unsicherheitsfaktoren]"
|
||||
|
||||
routing:
|
||||
zielgremium: "[Mission Board | DSR mit Delegationsoption | DSR]"
|
||||
begruendung: "[Basierend auf Routing-Logik]"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
detail_matrizen:
|
||||
- titel: "Klassifizierungsmatrix Komplexität"
|
||||
pfad: "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
beschreibung: "Erweiterte Kriterien für Komplexitätsbewertung"
|
||||
|
||||
- titel: "Klassifizierungsmatrix Tragweite"
|
||||
pfad: "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
beschreibung: "Erweiterte Kriterien für Tragweitenbewertung"
|
||||
|
||||
prozess_kontext:
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen"
|
||||
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Verantwortlichkeiten für Klassifizierung"
|
||||
|
||||
# ========================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# ========================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2026-01-22"
|
||||
aenderung: |
|
||||
- qualifizierung_hinweis bei intern_strategisch und intern_operativ ergänzt:
|
||||
Hinweis auf SHM Fast Track (10-15min Validation) und
|
||||
DPM-Rückkopplungsschleife für Nachforderungen
|
||||
- Querverweis auf shm_d2p-integration.yaml#rueckkopplungsschleife_dpm_shm
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "[ursprüngliches Abnahmedatum]"
|
||||
aenderung: "Initiale Erstellung und Abnahme"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Konzept_DPM_Abnahme20230925"
|
||||
|
|
@ -0,0 +1,403 @@
|
|||
meta:
|
||||
typ: "review_framework"
|
||||
framework_name: "Demand-Portfolio Review"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen: true
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
kontext_tags:
|
||||
- "review"
|
||||
- "demand-portfolio"
|
||||
- "governance"
|
||||
- "kpi"
|
||||
- "kontinuierliche-verbesserung"
|
||||
- "quartalsweise"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND ZIELSETZUNG
|
||||
# ========================================
|
||||
|
||||
zweck_und_zielsetzung:
|
||||
kernaussage: >
|
||||
Das quartalsweise Demand-Portfolio Review dient der systematischen Analyse
|
||||
der Demand-Portfolio-Dynamik und der kontinuierlichen Verbesserung des
|
||||
Demand-Management-Prozesses. Es identifiziert Muster, bewertet die
|
||||
Systemgesundheit und leitet strategische Erkenntnisse für das Mission Board ab.
|
||||
|
||||
kernziele:
|
||||
- id: "KZ-1"
|
||||
name: "Mustererkennung"
|
||||
beschreibung: "Identifikation wiederkehrender Themen und Herausforderungen"
|
||||
|
||||
- id: "KZ-2"
|
||||
name: "Workflow-Optimierung"
|
||||
beschreibung: "Ableitung von Verbesserungspotenzialen"
|
||||
|
||||
- id: "KZ-3"
|
||||
name: "Strategische Rueckkopplung"
|
||||
beschreibung: "Erkenntnisse fuer uebergeordnete Steuerungsentscheidungen"
|
||||
|
||||
- id: "KZ-4"
|
||||
name: "Qualitaetssicherung"
|
||||
beschreibung: "Ueberpruefung der Governance-Effektivitaet"
|
||||
|
||||
# ========================================
|
||||
# 2. TEILNEHMER:INNEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
teilnehmer_verantwortlichkeiten:
|
||||
|
||||
rollen:
|
||||
- rolle_id: "al_planung"
|
||||
name: "AL Planung"
|
||||
funktion: "Leitung"
|
||||
verantwortung:
|
||||
- "Einberufung"
|
||||
- "Moderation"
|
||||
- "Ergebniskonsolidierung"
|
||||
- "MB-Berichterstattung"
|
||||
|
||||
- rolle_id: "dpm"
|
||||
name: "DPM"
|
||||
funktion: "Datenverantwortung"
|
||||
verantwortung:
|
||||
- "Datenaufbereitung"
|
||||
- "Portfolio-Analyse"
|
||||
- "Priorisierungs-Retrospektive"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
name: "PPM"
|
||||
funktion: "Projekt-Perspektive"
|
||||
verantwortung:
|
||||
- "Projekt-Pipeline-Analyse"
|
||||
- "Ressourcenauslastung"
|
||||
- "Umsetzungs-Feedback"
|
||||
|
||||
- rolle_id: "spm"
|
||||
name: "SPM"
|
||||
funktion: "Service-Perspektive"
|
||||
verantwortung:
|
||||
- "Service-Impact-Analyse"
|
||||
- "Betriebsbereitschaft"
|
||||
- "Transition-Erfahrungen"
|
||||
|
||||
- rolle_id: "shm"
|
||||
name: "SHM"
|
||||
funktion: "Stakeholder-Perspektive"
|
||||
verantwortung:
|
||||
- "Stakeholder-Trends"
|
||||
- "Bedarfsmuster"
|
||||
- "Kommunikations-Feedback"
|
||||
|
||||
# ========================================
|
||||
# 3. TURNUS UND ZEITPLANUNG
|
||||
# ========================================
|
||||
|
||||
turnus_zeitplanung:
|
||||
|
||||
regelmaessigkeit:
|
||||
frequenz: "quartalsweise"
|
||||
zeitpunkt: "erste Monatshaelfte nach Quartalsende"
|
||||
dauer: "3 Stunden (inkl. Pausen)"
|
||||
vorlaufzeit_unterlagen: "1 Woche vor Termin"
|
||||
|
||||
zeitlicher_ablauf:
|
||||
- zeitpunkt: "T-14 Tage"
|
||||
verantwortlich: "AL Planung"
|
||||
aktivitaeten:
|
||||
- "Prozess initiieren"
|
||||
- "Reminder verschicken"
|
||||
- "Datensammlung beginnen"
|
||||
|
||||
- zeitpunkt: "T-10 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Aktualisierung Portfolio-Uebersichten"
|
||||
|
||||
- zeitpunkt: "T-7 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Input zu Beobachtungen/Mustern an DPM"
|
||||
|
||||
- zeitpunkt: "T-3 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung Analysebericht (Draft) an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T-1 Tag"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Durchsicht der Unterlagen"
|
||||
|
||||
- zeitpunkt: "T-0 Tage"
|
||||
verantwortlich: "DSR + AL-P"
|
||||
aktivitaeten:
|
||||
- "Review-Durchfuehrung"
|
||||
|
||||
- zeitpunkt: "T+7 Tage"
|
||||
verantwortlich: "DPM"
|
||||
aktivitaeten:
|
||||
- "Verteilung des Review-Berichts an DSR + AL-P"
|
||||
|
||||
- zeitpunkt: "T+14 Tage"
|
||||
verantwortlich: "AL Planung / DPM"
|
||||
aktivitaeten:
|
||||
- "MB-Berichterstattung (Praesentation + Review-Bericht)"
|
||||
|
||||
# ========================================
|
||||
# 4. VORBEREITUNG
|
||||
# ========================================
|
||||
|
||||
vorbereitung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 DATENSAMMLUNG
|
||||
# ----------------------------------
|
||||
|
||||
datensammlung:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Aufbereitung der Demand-Portfolio-Daten anhand des Demand-KPI-Frameworks"
|
||||
referenz:
|
||||
dokument: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 VORANALYSE
|
||||
# ----------------------------------
|
||||
|
||||
voranalyse:
|
||||
verantwortlich: "DPM"
|
||||
beschreibung: "Strukturierte Voranalyse"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "VA-1"
|
||||
name: "KPI-Auswertung"
|
||||
inhalte:
|
||||
- "Aufbereitung aller KPIs gemaess Demand-KPI-Framework"
|
||||
- "Vergleich mit Vorquartal (Trends)"
|
||||
- "Identifikation von Ausreissern und Auffaelligkeiten"
|
||||
|
||||
- id: "VA-2"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Clustering der Demand-Themen"
|
||||
- "Analyse wiederkehrender Ablehnungsgruende"
|
||||
- "Identifikation systematischer Verzoegerungen"
|
||||
- "Stakeholder-Verhaltensmuster"
|
||||
|
||||
- id: "VA-3"
|
||||
name: "Deep-Dive Vorbereitung"
|
||||
inhalte:
|
||||
- "Liste lange liegender Demands mit Handlungsempfehlung"
|
||||
- "Analyse der Wiedervorlagen"
|
||||
- "Dokumentation kritischer Einzelfaelle"
|
||||
- "Prozess-Bottleneck-Analyse"
|
||||
|
||||
- id: "VA-4"
|
||||
name: "Optimierungs-Massnahmen-Review"
|
||||
inhalte:
|
||||
- "Status offener Optimierungsmassnahmen aus dem Massnahmenkatalog"
|
||||
- "Wirksamkeit umgesetzter Massnahmen"
|
||||
- "Neue Optimierungspotenziale"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 UNTERLAGENERSTELLUNG
|
||||
# ----------------------------------
|
||||
|
||||
unterlagenerstellung:
|
||||
versand: "T-3 Tage"
|
||||
name: "Review-Package"
|
||||
|
||||
bestandteile:
|
||||
|
||||
- id: "UP-1"
|
||||
name: "Management Summary"
|
||||
umfang: "1 Seite"
|
||||
inhalte:
|
||||
- "Quartals-Highlights"
|
||||
- "Kritische Entwicklungen"
|
||||
- "Top-3 Handlungsbedarfe"
|
||||
|
||||
- id: "UP-2"
|
||||
name: "KPI-Dashboard"
|
||||
inhalte:
|
||||
- "Alle Metriken mit Trend und Bewertung"
|
||||
- "Grafische Aufbereitung der Entwicklung"
|
||||
- "Kommentierung von Auffaelligkeiten"
|
||||
|
||||
- id: "UP-3"
|
||||
name: "Demand-Portfolio-Uebersicht"
|
||||
inhalte:
|
||||
- "Aktueller Bestand nach Status"
|
||||
- "Demand-Pipeline-Visualisierung"
|
||||
- "Thematische Verteilung"
|
||||
|
||||
- id: "UP-4"
|
||||
name: "Detailanalysen"
|
||||
inhalte:
|
||||
- "Durchlaufzeit-Analyse"
|
||||
- "Entscheidungsanalyse"
|
||||
- "Engpass-Dokumentation"
|
||||
|
||||
- id: "UP-5"
|
||||
name: "Anhaenge"
|
||||
inhalte:
|
||||
- "Standard-Agenda mit Zeitplan"
|
||||
- "Status Massnahmenkatalog"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATION UND BERICHTERSTATTUNG
|
||||
# ========================================
|
||||
|
||||
dokumentation_berichterstattung:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 REVIEW-ERGEBNISDOKUMENT
|
||||
# ----------------------------------
|
||||
|
||||
review_ergebnisdokument:
|
||||
name: "Review-Ergebnisbericht"
|
||||
|
||||
struktur:
|
||||
|
||||
- id: "EB-1"
|
||||
name: "Executive Summary"
|
||||
inhalte:
|
||||
- "Top-3-Erkenntnisse"
|
||||
- "Kritische Handlungsfelder"
|
||||
- "Empfohlene Sofortmassnahmen"
|
||||
|
||||
- id: "EB-2"
|
||||
name: "Portfolio-Performance"
|
||||
inhalte:
|
||||
- "KPIs mit Trend"
|
||||
- "Demand-Zusammensetzung"
|
||||
- "Durchlauf-Analyse"
|
||||
|
||||
- id: "EB-3"
|
||||
name: "Musteranalyse"
|
||||
inhalte:
|
||||
- "Identifizierte Trends"
|
||||
- "Wiederkehrende Herausforderungen"
|
||||
- "Positive Entwicklungen"
|
||||
|
||||
- id: "EB-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
inhalte:
|
||||
- "Priorisierte Massnahmenliste"
|
||||
- "Verantwortlichkeiten und Zeitrahmen"
|
||||
- "Erwarteter Impact"
|
||||
|
||||
- id: "EB-5"
|
||||
name: "Anhang"
|
||||
inhalte:
|
||||
- "Detaildaten"
|
||||
- "Einzelfallanalysen"
|
||||
- "Prozessverbesserungsvorschlaege"
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 MISSION BOARD PRAESENTATION
|
||||
# ----------------------------------
|
||||
|
||||
mission_board_praesentation:
|
||||
format: "Informationspunkt in naechster MB-Sitzung"
|
||||
umfang: "10-15 Minuten Praesentation + Diskussion"
|
||||
|
||||
inhalt:
|
||||
- "Portfolio-Entwicklung im Ueberblick"
|
||||
- "Zentrale Erkenntnisse und Muster"
|
||||
- "Kritische Handlungsbedarfe"
|
||||
- "Empfehlungen fuer strategische Anpassungen"
|
||||
|
||||
# ========================================
|
||||
# 6. KONTINUIERLICHE VERBESSERUNG
|
||||
# ========================================
|
||||
|
||||
kontinuierliche_verbesserung:
|
||||
|
||||
optimierung_review_prozess:
|
||||
aktivitaeten:
|
||||
- "Jaehrliche Evaluation der Review-Methodik"
|
||||
- "Anpassung der KPIs"
|
||||
- "Integration neuer Analysedimensionen bei Bedarf"
|
||||
|
||||
lessons_learned_integration:
|
||||
aktivitaeten:
|
||||
- "Systematische Erfassung von Prozessverbesserungen"
|
||||
- "Best Practice Dokumentation"
|
||||
- "Wissenstransfer in die Organisation"
|
||||
|
||||
# ========================================
|
||||
# 7. WERKZEUGE UND VORLAGEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_vorlagen:
|
||||
|
||||
benoetigte_unterlagen:
|
||||
- id: "WV-1"
|
||||
name: "Demand-Portfolio-Export"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-2"
|
||||
name: "DSR-Protokolle des Quartals"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-3"
|
||||
name: "MB-Entscheidungsprotokolle"
|
||||
status: "erforderlich"
|
||||
|
||||
- id: "WV-4"
|
||||
name: "Stakeholder-Feedback-Sammlung"
|
||||
status: "erforderlich"
|
||||
|
||||
# ========================================
|
||||
# 8. PILOTPHASE-SPEZIFIKA
|
||||
# ========================================
|
||||
|
||||
pilotphase_spezifika:
|
||||
|
||||
waehrend_pilotphase:
|
||||
charakteristiken:
|
||||
- aspekt: "Keine festen Benchmarks"
|
||||
beschreibung: "Sammlung von Baseline-Daten"
|
||||
|
||||
- aspekt: "Experimenteller Charakter"
|
||||
beschreibung: "Iterative Anpassung der Methodik"
|
||||
|
||||
- aspekt: "Fokus auf Lernen"
|
||||
beschreibung: "Identifikation sinnvoller KPIs"
|
||||
|
||||
- aspekt: "Dokumentation"
|
||||
beschreibung: "Besonders sorgfaeltige Erfassung fuer spaetere Evaluation"
|
||||
|
||||
nach_2_3_reviews:
|
||||
aktivitaeten:
|
||||
- "Definition realistischer Zielwerte"
|
||||
- "Festlegung kritischer Schwellenwerte"
|
||||
- "Standardisierung der Analysemethoden"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
|
||||
interne_dokumente:
|
||||
- titel: "Demand-KPI-Framework"
|
||||
seite: 58
|
||||
relevanz: "Grundlage fuer Datensammlung und KPI-Auswertung"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.1_demand-portfolio-management_documentation/dpm_demand-portfolio_governance.yaml"
|
||||
relevanz: "Uebergeordnetes Governance-Framework"
|
||||
|
||||
- titel: "DSR-Geschaeftsordnung"
|
||||
relevanz: "Operative Regelungen fuer DSR"
|
||||
|
||||
- titel: "Massnahmenkatalog"
|
||||
relevanz: "Tracking von Optimierungsmassnahmen"
|
||||
|
|
@ -0,0 +1,490 @@
|
|||
meta:
|
||||
typ: "governance_framework"
|
||||
framework_name: "Demand-Portfolio Governance"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "governance"
|
||||
- "demand-portfolio"
|
||||
- "steuerung"
|
||||
- "entscheidungsarchitektur"
|
||||
- "portfolio-management"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck_und_geltungsbereich:
|
||||
zweck:
|
||||
kernaussage: "Orchestriert den Fluss von Bedarfen durch die DIGIT-Organisation"
|
||||
|
||||
fluss:
|
||||
start: "Erste Erfassung eines Stakeholder-Wunsches"
|
||||
ende: "Integration als laufender Service"
|
||||
|
||||
ergaenzung_zu: "DSR-Geschäftsordnung"
|
||||
ergaenzungs_perspektive: "Übergreifende Steuerungsperspektive"
|
||||
|
||||
zentrale_klaerungen:
|
||||
- thema: "Rolle des Demand-Portfolio-Managements"
|
||||
klarstellung: "Zentrale Priorisierungsinstanz"
|
||||
|
||||
- thema: "Portfolio-Überwachung"
|
||||
klarstellung: "Mechanismen zur Portfolio-Überwachung definiert"
|
||||
|
||||
verweis_portfolio_kontext:
|
||||
dokument: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
inhalt: "Details zu den drei Portfolios und Kernprozessen (Demand-Lifecycle (Change) & Service-Lifecycle (Run))"
|
||||
|
||||
# ========================================
|
||||
# 2. GOVERNANCE-ARCHITEKTUR
|
||||
# ========================================
|
||||
|
||||
governance_architektur:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 ENTSCHEIDUNGSEBENEN
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungsebenen:
|
||||
beschreibung: "DIGITOM definiert vier Entscheidungsinstanzen mit unterschiedlichen Kompetenzen"
|
||||
anzahl: 4
|
||||
|
||||
ebenen:
|
||||
- ebene_id: "vision_board"
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Verantwortet das Operating Model"
|
||||
- "Setzt strategische Leitplanken für die Digitalisierung"
|
||||
|
||||
entscheidungen:
|
||||
- "Grundlegende Governance-Änderungen"
|
||||
- "Investitionsschwerpunkte"
|
||||
|
||||
hierarchie_stufe: 4
|
||||
|
||||
- ebene_id: "mission_board"
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch-strategisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "MB-Demands"
|
||||
beispiele: ["transformative Anforderungen", "hochkomplexe Anforderungen"]
|
||||
- typ: "Gesamtressourcenallokation"
|
||||
beschreibung: "Steuert die Gesamtressourcenallokation"
|
||||
- typ: "Konfliktlösung"
|
||||
beschreibung: "Löst Konflikte zwischen Abteilungen"
|
||||
|
||||
informations_input:
|
||||
- quelle: "quartals_portfolio_reviews"
|
||||
frequenz: "quartalsweise"
|
||||
von: "abteilungsleitung_planung"
|
||||
|
||||
hierarchie_stufe: 3
|
||||
|
||||
- ebene_id: "abteilungsleitung_planung"
|
||||
name: "Abteilungsleitung Planung"
|
||||
kurzform: "AL-P"
|
||||
ebene: "taktisch"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Quartalsweise Portfolio-Reviews"
|
||||
- "Disziplinarische Führung des DPM"
|
||||
|
||||
funktion: "Brücke zwischen operativer Portfolio-Steuerung und taktischer Entscheidungsebene"
|
||||
|
||||
aufgaben:
|
||||
- "Portfolio-Muster und -Trends analysieren"
|
||||
- "Erkenntnisse ableiten"
|
||||
- "Berichten ans Mission Board"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei strategischer Relevanz"
|
||||
an: "vision_board"
|
||||
|
||||
hierarchie_stufe: 2
|
||||
|
||||
- ebene_id: "dsr"
|
||||
name: "Demand & Stakeholder Runde"
|
||||
kurzform: "DSR"
|
||||
ebene: "operativ-taktisch"
|
||||
|
||||
entscheidungen:
|
||||
- typ: "DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
delegation:
|
||||
kann_delegieren_an: "mission_board"
|
||||
bedingung: "bei entsprechendem Klassifizierungsmuster"
|
||||
|
||||
hierarchie_stufe: 1
|
||||
|
||||
referenz:
|
||||
dokument: "dsr-geschaeftsordnung.yaml"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
|
||||
- ebene_id: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
kurzform: "DPM"
|
||||
ebene: "operativ"
|
||||
typ: "fachrolle"
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Klassifizierung aller Demands im Portfolio"
|
||||
- "Analyse aller Demands im Portfolio"
|
||||
- "Bewertung aller Demands im Portfolio"
|
||||
- "Priorisierung aller Demands im Portfolio"
|
||||
|
||||
output: "Entscheidungsvorlage für jeweiliges Entscheidungsgremium"
|
||||
|
||||
governance_prinzip:
|
||||
trennung: "Entscheidungsgremium ≠ DPM"
|
||||
|
||||
sicherstellung:
|
||||
- aspekt: "Fachlich-objektive Arbeit"
|
||||
durch: "dpm"
|
||||
umfasst: ["Klassifizierung", "Analyse", "Bewertung", "Priorisierung"]
|
||||
|
||||
- aspekt: "Multiperspektivische Freigabe"
|
||||
durch: ["dsr", "mission_board"]
|
||||
umfasst: "Finale Entscheidung unter Berücksichtigung aller Perspektiven"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
- abschnitt: "Schnittstellen und Verantwortlichkeiten"
|
||||
siehe: "Abschnitt 5 in diesem Dokument"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 ENTSCHEIDUNGS-ROUTING
|
||||
# ----------------------------------
|
||||
|
||||
entscheidungs_routing:
|
||||
beschreibung: "Systematische Zuordnung von Demands zu Entscheidungsebenen"
|
||||
|
||||
basis: "Klassifizierungslogik auf vier Dimensionen"
|
||||
|
||||
dimensionen:
|
||||
- id: "treiber"
|
||||
name: "Treiber"
|
||||
bedeutung: "Impulsquelle"
|
||||
|
||||
- id: "tragweite"
|
||||
name: "Tragweite"
|
||||
bedeutung: "Veränderungstiefe"
|
||||
|
||||
- id: "systemebene"
|
||||
name: "Systemebene"
|
||||
bedeutung: "Technisch-fachliche Verortung"
|
||||
|
||||
- id: "komplexitaet"
|
||||
name: "Komplexität"
|
||||
bedeutung: "Lösungsunsicherheit"
|
||||
|
||||
routing_optionen:
|
||||
- ziel: "mission_board"
|
||||
beschreibung: "Direkt an Mission Board"
|
||||
trigger: ["hochkomplex", "transformativ"]
|
||||
|
||||
- ziel: "dsr_mit_delegationsoption"
|
||||
beschreibung: "An DSR mit Option zur Delegation ans Mission Board"
|
||||
trigger: "entsprechendes Klassifizierungsmuster"
|
||||
|
||||
- ziel: "dsr"
|
||||
beschreibung: "An DSR ohne Delegationsoption"
|
||||
trigger: "inkrementelle Themen"
|
||||
|
||||
prinzip: |
|
||||
Entscheidungen werden auf der zuständigen Organisationsebene getroffen:
|
||||
- Hochkomplexe und transformative Demands → Mission Board
|
||||
- Inkrementelle Themen → Demand & Stakeholder-Runde
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Klassifizierung"
|
||||
abschnitt: "3.2 Routing-Logik: Die Klassifizierung bestimmt die Entscheidungsebene"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 3. DEMAND-PORTFOLIO-STEUERUNG UND REVIEWS
|
||||
# ========================================
|
||||
|
||||
portfolio_steuerung:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 STEUERUNGSEBENE DSR
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_dsr:
|
||||
ebene: "Demand & Stakeholder-Runde"
|
||||
|
||||
aufgaben:
|
||||
- id: "DSR-E1"
|
||||
name: "Entscheidung über DSR-Demands"
|
||||
optionen: ["Freigabe", "Ablehnung", "Zurückstellung"]
|
||||
|
||||
- id: "DSR-E2"
|
||||
name: "Delegations-Entscheidung"
|
||||
beschreibung: "Entscheidung über Delegation von Demands ans Mission Board"
|
||||
|
||||
- id: "DSR-I1"
|
||||
name: "Feedback-Aufnahme"
|
||||
beschreibung: "Aufnahme von Feedback zu laufenden Umsetzungen"
|
||||
|
||||
- id: "DSR-P1"
|
||||
name: "Problemklärung"
|
||||
beschreibung: "Klärung akuter Problemstellungen"
|
||||
|
||||
referenzen:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
- dokument: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 STEUERUNGSEBENE MISSION BOARD
|
||||
# ----------------------------------
|
||||
|
||||
steuerungsebene_mission_board:
|
||||
ebene: "Mission Board"
|
||||
|
||||
aufgaben:
|
||||
- id: "MB-E1"
|
||||
name: "Freigabe von MB-Demands"
|
||||
beschreibung: "Entscheidung über hochkomplexe und transformative Demands"
|
||||
|
||||
- id: "MB-K1"
|
||||
name: "Ressourcenkonflikte lösen"
|
||||
beschreibung: "Auflösung von Ressourcenkonflikten zwischen Abteilungen"
|
||||
|
||||
- id: "MB-S1"
|
||||
name: "Gesamtportfolio steuern"
|
||||
beschreibung: "Steuerung des Gesamtportfolios aus Demands und Projekten"
|
||||
|
||||
referenz:
|
||||
dokument: "Geschäftsordnung des Mission Boards"
|
||||
hinweis: "Detaillierte Arbeitsweise"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 PORTFOLIO-REVIEWS (QUARTALSWEISE)
|
||||
# ----------------------------------
|
||||
|
||||
quartals_portfolio_reviews:
|
||||
frequenz: "quartalsweise"
|
||||
verantwortlich: "abteilungsleitung_planung"
|
||||
|
||||
teilnehmende:
|
||||
- "dpm"
|
||||
- "ppm"
|
||||
- "spm"
|
||||
- "shm"
|
||||
|
||||
berichterstattung:
|
||||
an: "mission_board"
|
||||
form: "Informationspunkt in der nächsten Sitzung"
|
||||
|
||||
zweck:
|
||||
hauptzweck: "Systematische Analyse der Portfolio-Dynamik"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit anhand KPIs bewerten"
|
||||
- "Verbesserungspotenziale ableiten"
|
||||
|
||||
nutzung_durch_al_p:
|
||||
zweck: "Abteilungsleitung Planung nutzt Erkenntnisse für"
|
||||
|
||||
nutzungen:
|
||||
- "Trends und wiederkehrende Herausforderungen erkennen"
|
||||
- "Effektivität der Governance bewerten"
|
||||
- "Anpassungsbedarfe identifizieren"
|
||||
- "Empfehlungen für Mission Board formulieren"
|
||||
|
||||
kern_inhalte:
|
||||
- id: "REV-1"
|
||||
name: "Portfolio-Überblick"
|
||||
aspekte: ["Volumen", "Durchsatz", "Themencluster"]
|
||||
|
||||
- id: "REV-2"
|
||||
name: "KPI-Analyse"
|
||||
beschreibung: "Analyse der definierten KPIs"
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Musteranalyse"
|
||||
aspekte: ["Engpässe", "Ablehnungsgründe", "Verzögerungen"]
|
||||
|
||||
- id: "REV-4"
|
||||
name: "Handlungsempfehlungen"
|
||||
beschreibung: "Ableitung von Handlungsempfehlungen"
|
||||
|
||||
charakter:
|
||||
output_typ: "strategische Erkenntnisse"
|
||||
nicht: "operative Entscheidungen"
|
||||
|
||||
eskalation:
|
||||
bedingung: "bei Bedarf für kritische Themen"
|
||||
pfad: "Mission Board → Vision Board"
|
||||
|
||||
referenz:
|
||||
dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Detaillierte Agenda, Analysevorlagen und Durchführungshinweise"
|
||||
|
||||
# ========================================
|
||||
# 4. DEMAND-PORTFOLIO KPIs
|
||||
# ========================================
|
||||
|
||||
demand_portfolio_kpis:
|
||||
zweck: "Systematische Analyse der Demand-Portfolio-Dynamik und kontinuierliche Verbesserung"
|
||||
|
||||
verwendung:
|
||||
kontext: "Quartalsweises Demand-Portfolio Review"
|
||||
|
||||
aktivitaeten:
|
||||
- "Muster identifizieren"
|
||||
- "Systemgesundheit bewerten"
|
||||
- "Strategische Erkenntnisse für Mission Board ableiten"
|
||||
|
||||
entwicklungsansatz:
|
||||
phase: "pilotphase"
|
||||
vorgehen: "Erste KPIs werden als Benchmarks erhoben und sukzessive weiterentwickelt"
|
||||
|
||||
referenzen:
|
||||
- dokument: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
inhalt: "Definition und Erhebungsmethodik"
|
||||
|
||||
- dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# 5. SCHNITTSTELLEN UND VERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen_verantwortlichkeiten:
|
||||
|
||||
rollenmatrix:
|
||||
beschreibung: "DIGITOM nutzt ein differenziertes RACI-Modell mit unterschiedlichen Verantwortungslogiken"
|
||||
|
||||
referenz:
|
||||
dokument: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
|
||||
informationsfluesse:
|
||||
beschreibung: "Governance basiert auf definierten Informationsflüssen"
|
||||
|
||||
fluesse:
|
||||
- richtung: "bottom_up"
|
||||
name: "Bottom-up"
|
||||
beschreibung: "Demands fließen von Stakeholdern über SHM und DPM in die Entscheidungsgremien"
|
||||
pfad: "Stakeholder → SHM → DPM → DSR/MB"
|
||||
|
||||
- richtung: "top_down"
|
||||
name: "Top-down"
|
||||
beschreibung: "Strategische Vorgaben fließen vom Vision Board über Mission Board zur operativen Umsetzung"
|
||||
pfad: "Vision Board → Mission Board → operative Umsetzung"
|
||||
|
||||
- richtung: "horizontal"
|
||||
name: "Horizontal"
|
||||
beschreibung: "Abstimmung zwischen DPM, PPM und SPM zur Portfolio-Synchronisation"
|
||||
zwischen: ["dpm", "ppm", "spm"]
|
||||
zweck: "Portfolio-Synchronisation"
|
||||
|
||||
# ========================================
|
||||
# 6. PILOT-EVALUATION
|
||||
# ========================================
|
||||
|
||||
pilot_evaluation:
|
||||
zeitpunkt: "nach Pilotbetrieb"
|
||||
|
||||
status:
|
||||
evaluationskriterien: "in Erarbeitung"
|
||||
dokumentation: "separat"
|
||||
|
||||
referenz:
|
||||
dokument: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
||||
# ========================================
|
||||
# SYSTEMISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
systemische_einordnung:
|
||||
framework_charakter:
|
||||
typ: "übergeordnetes Governance-Framework"
|
||||
funktion: "Orchestrierung"
|
||||
scope: "Ende-zu-Ende (Stakeholder-Wunsch bis laufender Service)"
|
||||
|
||||
beziehung_zu_anderen_dokumenten:
|
||||
ergaenzt:
|
||||
- dokument: "DSR-Geschäftsordnung"
|
||||
art: "operative Regelungen"
|
||||
ergaenzung: "um übergreifende Steuerungsperspektive"
|
||||
|
||||
definiert_kontext_fuer:
|
||||
- dokument: "Demand-Klassifizierung"
|
||||
aspekt: "Routing-Logik erhält Governance-Kontext"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
aspekt: "Verantwortlichkeiten in Governance-Architektur eingebettet"
|
||||
|
||||
- dokument: "Rollenbeschreibung DPM"
|
||||
aspekt: "Rolle in Governance-System verortet"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
governance_dokumente:
|
||||
- titel: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Operative Regelungen für DSR"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten"
|
||||
|
||||
methodische_dokumente:
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Routing-Logik und Klassifizierungskriterien"
|
||||
|
||||
- titel: "Demand-Portfolio Review - Framework"
|
||||
pfad: "#01.3_prozesse/demand-portfolio-review-framework.yaml"
|
||||
relevanz: "KPIs und Review-Prozess"
|
||||
|
||||
prozess_dokumente:
|
||||
- titel: "DSR Standard-Agenda"
|
||||
pfad: "#01.3_prozesse/dsr-standard-agenda.yaml"
|
||||
relevanz: "Operativer Ablauf DSR"
|
||||
|
||||
rollen_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Zentrale Rolle im Governance-System"
|
||||
|
||||
externe_referenzen:
|
||||
- titel: "DIGITOM-Portfolio-Governance + Kernprozesse"
|
||||
beschreibung: "Details zu drei Portfolios und Kernprozessen"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Geschäftsordnung Mission Board"
|
||||
beschreibung: "Detaillierte Arbeitsweise des Mission Board"
|
||||
status: "separates Dokument"
|
||||
|
||||
- titel: "Pilot Dokumentation"
|
||||
url: "https://teamwork.freiburg.intern/spaces/DT/pages/340299158/Pilotkonzept+DPM"
|
||||
typ: "confluence"
|
||||
|
|
@ -0,0 +1,481 @@
|
|||
meta:
|
||||
typ: "bewertungsmethodik"
|
||||
methode: "demand_bewertung"
|
||||
titel: "Bewertungskriterien für das Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf:
|
||||
- "#01.4_methodik/klassifizierungsmatrix-komplexitaet.yaml"
|
||||
- "#01.4_methodik/klassifizierungsmatrix-tragweite.yaml"
|
||||
fuehrt_zu: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "bewertung"
|
||||
- "qualitative-analyse"
|
||||
- "cluster-bewertung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: "Die Demand-Bewertung dient als Koordinationsinstrument für Priorisierungsentscheidungen"
|
||||
|
||||
zentrale_funktionen:
|
||||
- id: "F01"
|
||||
name: "Ressourcenallokation"
|
||||
beschreibung: "Fundierte Entscheidungsgrundlage bei begrenzten Kapazitäten zur optimalen Verteilung von Personal, Budget und Zeit"
|
||||
|
||||
- id: "F02"
|
||||
name: "Strategische Ausrichtung"
|
||||
beschreibung: "Sicherstellung, dass priorisierte Demands den größtmöglichen Beitrag zu den Organisationszielen leisten"
|
||||
|
||||
- id: "F03"
|
||||
name: "Transparenz"
|
||||
beschreibung: "Nachvollziehbare Dokumentation von Bewertungen und Entscheidungen für alle beteiligten Stakeholder"
|
||||
|
||||
- id: "F04"
|
||||
name: "Portfolio-Balance"
|
||||
beschreibung: "Ausgewogene Mischung aus strategischen Initiativen, operativen Verbesserungen und regulatorischen Anforderungen"
|
||||
|
||||
grundprinzipien:
|
||||
- prinzip: "Qualitative Bewertung"
|
||||
beschreibung: "Keine mathematischen Scoring-Modelle, sondern begründete qualitative Einschätzungen"
|
||||
|
||||
- prinzip: "Kontextbezug"
|
||||
beschreibung: "Bewertung erfolgt situationsspezifisch, nicht nach starrem Schema"
|
||||
|
||||
- prinzip: "Konsensorientierung"
|
||||
beschreibung: "Unterschiedliche Einschätzungen werden dialogisch geklärt"
|
||||
|
||||
# ========================================
|
||||
# 2. ÜBERSICHT DER BEWERTUNGSKRITERIEN
|
||||
# ========================================
|
||||
|
||||
bewertungskriterien:
|
||||
anzahl: 9
|
||||
cluster_anzahl: 3
|
||||
beschreibung: "Neun Kriterien gruppiert in drei thematische Cluster"
|
||||
|
||||
cluster_uebersicht:
|
||||
- cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
fokus: "Wertbeitrag des Demands"
|
||||
kriterien_ids: ["strategische_passung", "nutzen", "integrationswirkung"]
|
||||
|
||||
- cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
fokus: "Handlungsdruck und Risiko"
|
||||
kriterien_ids: ["organisationsrelevanz", "zeitliche_dringlichkeit", "risiko_nicht_umsetzung"]
|
||||
|
||||
- cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
fokus: "Realisierbarkeit und Ressourcenbedarf"
|
||||
kriterien_ids: ["technische_machbarkeit", "organisatorische_umsetzbarkeit", "ressourceneffizienz"]
|
||||
|
||||
# ========================================
|
||||
# 3. BEWERTUNGSKRITERIEN IM DETAIL
|
||||
# ========================================
|
||||
|
||||
kriterien_detail:
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 1: NUTZEN & WIRKUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_1_nutzen_wirkung:
|
||||
cluster_id: "cluster_1"
|
||||
name: "Nutzen & Wirkung"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "strategische_passung"
|
||||
name: "Strategische Passung"
|
||||
kernfrage: "Wie gut unterstützt der Demand die Strategie?"
|
||||
fokus: "Strategiebeitrag & Innovation"
|
||||
|
||||
beschreibung: |
|
||||
Die strategische Passung bewertet den Beitrag des Demands zu den
|
||||
übergeordneten Zielen der Organisation und ihrer digitalen Transformation.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Übereinstimmung mit der Digitalisierungsstrategie der Verwaltung"
|
||||
- "Beitrag zu definierten Schwerpunktthemen und Leitprojekten"
|
||||
- "Unterstützung der Verwaltungsmodernisierung"
|
||||
- "Förderung zukunftsfähiger Verwaltungsstrukturen"
|
||||
- "Innovationspotenzial: Erschließung neuer Möglichkeiten oder Technologien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Kein erkennbarer Bezug zu strategischen Zielen"
|
||||
punkte_3: "Teilweise Übereinstimmung, unterstützt Einzelaspekte"
|
||||
punkte_5: "Kernbestandteil der Strategie mit hohem Innovationsgrad"
|
||||
|
||||
- kriterium_id: "nutzen"
|
||||
name: "Nutzen"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft der Demand?"
|
||||
fokus: "Public Value & Effizienz"
|
||||
|
||||
beschreibung: |
|
||||
Der Nutzen misst den konkreten Mehrwert des Demands in verschiedenen
|
||||
Dimensionen mit besonderem Fokus auf den Public Value.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Public Value"
|
||||
aspekte:
|
||||
- "Verbesserung der Lebensqualität für Bürger:innen"
|
||||
- "Steigerung der Servicequalität und Zugänglichkeit"
|
||||
- "Beitrag zur Daseinsvorsorge und Gemeinwohl"
|
||||
|
||||
- titel: "Effizienzsteigerung"
|
||||
aspekte:
|
||||
- "Prozessoptimierung und Automatisierung"
|
||||
- "Reduktion von Bearbeitungszeiten"
|
||||
- "Ressourceneinsparung und Fehlerminimierung"
|
||||
|
||||
- titel: "Qualitätsverbesserung"
|
||||
aspekte:
|
||||
- "Erhöhung der Datenqualität"
|
||||
- "Verbesserung der Entscheidungsgrundlagen"
|
||||
- "Steigerung der Servicequalität"
|
||||
|
||||
- titel: "Befähigung"
|
||||
aspekte:
|
||||
- "Schaffung neuer Handlungsmöglichkeiten"
|
||||
- "Kompetenzaufbau in der Organisation"
|
||||
- "Grundlage für weitere Digitalisierungsschritte"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Nutzen nur in Einzelaspekten erkennbar"
|
||||
punkte_3: "Mehrere Nutzendimensionen werden adressiert"
|
||||
punkte_5: "Umfassender Nutzen mit hohem Public Value"
|
||||
|
||||
- kriterium_id: "integrationswirkung"
|
||||
name: "Integrationswirkung"
|
||||
kernfrage: "Welche Synergien und Standards entstehen?"
|
||||
fokus: "Architektur & Wiederverwendung"
|
||||
|
||||
beschreibung: |
|
||||
Die Integrationswirkung bewertet den Beitrag zur Verbesserung der
|
||||
Gesamtarchitektur und Schaffung von Synergien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Schaffung wiederverwendbarer Komponenten oder Standards"
|
||||
- "Reduktion technischer Schulden und Komplexität"
|
||||
- "Harmonisierung von Prozessen und Schnittstellen"
|
||||
- "Beitrag zur Architekturkonvergenz"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Isolierte Einzellösung ohne Synergieeffekte"
|
||||
punkte_3: "Lokale Verbesserungen mit begrenztem Wiederverwendungspotenzial"
|
||||
punkte_5: "Grundlegende Plattform oder Standard mit breiter Nutzbarkeit"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
# ----------------------------------
|
||||
|
||||
cluster_2_druck_notwendigkeit:
|
||||
cluster_id: "cluster_2"
|
||||
name: "Druck & Notwendigkeit"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "organisationsrelevanz"
|
||||
name: "Organisationsrelevanz"
|
||||
kernfrage: "Wie wichtig ist der Demand für die Verwaltung?"
|
||||
fokus: "Interne Priorität & Unterstützung"
|
||||
|
||||
beschreibung: |
|
||||
Die Organisationsrelevanz erfasst die Bedeutung des Demands innerhalb
|
||||
der DIGIT-Strukturen und -Prozesse.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Priorität in den Abteilungen und Führungsebenen"
|
||||
- "Betroffenheit kritischer Prozesse"
|
||||
- "Anzahl betroffener Organisationseinheiten"
|
||||
- "Unterstützung durch Schlüsselpersonen"
|
||||
- "Verbindlichkeit durch Gremienbeschlüsse"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Einzelinteresse ohne breite Unterstützung"
|
||||
punkte_3: "Bereichsübergreifende Relevanz mit moderater Priorität"
|
||||
punkte_5: "Organisationsweite Priorität mit starker Führungsunterstützung"
|
||||
|
||||
- kriterium_id: "zeitliche_dringlichkeit"
|
||||
name: "Zeitliche Dringlichkeit"
|
||||
kernfrage: "Bis wann muss umgesetzt werden?"
|
||||
fokus: "Fristen & Handlungsdruck"
|
||||
|
||||
beschreibung: |
|
||||
Die zeitliche Dringlichkeit erfasst externe und interne Zeitvorgaben.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Harte Fristen"
|
||||
aspekte:
|
||||
- "Gesetzliche Umsetzungsfristen"
|
||||
- "Vertragsablauf oder Kündigungsfristen"
|
||||
- "Technische End-of-Life-Termine"
|
||||
|
||||
- titel: "Weiche Fristen"
|
||||
aspekte:
|
||||
- "Politische Zusagen und Termine"
|
||||
- "Budgetjahre und Fördermittelfristen"
|
||||
- "Koordination mit anderen Vorhaben"
|
||||
|
||||
- titel: "Handlungsdruck"
|
||||
aspekte:
|
||||
- "Akkumulierter Problemdruck"
|
||||
- "Erwartungshaltung der Stakeholder"
|
||||
- "Verfügbare Zeitfenster für Umsetzung"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Flexible Zeithorizonte (> 18 Monate)"
|
||||
punkte_3: "Mittelfristiger Handlungsbedarf (6-18 Monate)"
|
||||
punkte_5: "Sofortiger Handlungsbedarf (< 6 Monate)"
|
||||
|
||||
- kriterium_id: "risiko_nicht_umsetzung"
|
||||
name: "Risiko bei Nicht-Umsetzung"
|
||||
kernfrage: "Was passiert ohne Realisierung?"
|
||||
fokus: "Rechtliche, operative & Reputationsrisiken"
|
||||
|
||||
beschreibung: |
|
||||
Diese Kategorie analysiert die negativen Konsequenzen einer
|
||||
Nicht-Realisierung des Demands.
|
||||
|
||||
bewertungsaspekte:
|
||||
- titel: "Rechtliche Risiken"
|
||||
aspekte:
|
||||
- "Drohende Sanktionen oder Bußgelder"
|
||||
- "Verletzung gesetzlicher Vorgaben"
|
||||
- "Haftungsrisiken für die Verwaltung"
|
||||
|
||||
- titel: "Operative Risiken"
|
||||
aspekte:
|
||||
- "Gefährdung der Handlungsfähigkeit"
|
||||
- "Systemausfälle oder Sicherheitslücken"
|
||||
- "Prozessunterbrechungen"
|
||||
|
||||
- titel: "Reputationsrisiken"
|
||||
aspekte:
|
||||
- "Vertrauensverlust bei Bürger:innen"
|
||||
- "Negative Außenwirkung"
|
||||
- "Politische Konsequenzen"
|
||||
|
||||
- titel: "Opportunitätskosten"
|
||||
aspekte:
|
||||
- "Entgangene Fördermittel"
|
||||
- "Verpasste Einsparpotenziale"
|
||||
- "Wettbewerbsnachteile"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Marginale Auswirkungen absehbar"
|
||||
punkte_3: "Mittelfristig spürbare negative Effekte"
|
||||
punkte_5: "Kritische Risiken mit unmittelbaren Konsequenzen"
|
||||
|
||||
# ----------------------------------
|
||||
# CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
# ----------------------------------
|
||||
|
||||
cluster_3_machbarkeit_aufwand:
|
||||
cluster_id: "cluster_3"
|
||||
name: "Machbarkeit & Aufwand"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "technische_machbarkeit"
|
||||
name: "Technische Machbarkeit"
|
||||
kernfrage: "Ist die Lösung technisch realisierbar?"
|
||||
fokus: "Technologie & Architektur"
|
||||
|
||||
beschreibung: |
|
||||
Die technische Machbarkeit prüft die Realisierbarkeit mit verfügbaren
|
||||
Mitteln und Technologien.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit erprobter Technologien und Lösungsansätze"
|
||||
- "Kompatibilität mit der Bestandslandschaft"
|
||||
- "Erfüllbarkeit von Sicherheits- und Datenschutzanforderungen"
|
||||
- "Skalierbarkeit und Performance-Anforderungen"
|
||||
- "Verfügbarkeit technischer Expertise"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Erhebliche technische Herausforderungen, Neuland"
|
||||
punkte_3: "Lösbar mit vertretbarem Aufwand und bekannten Ansätzen"
|
||||
punkte_5: "Standardlösung mit minimalem technischen Risiko"
|
||||
|
||||
- kriterium_id: "organisatorische_umsetzbarkeit"
|
||||
name: "Organisatorische Umsetzbarkeit"
|
||||
kernfrage: "Sind die organisatorischen Voraussetzungen gegeben?"
|
||||
fokus: "Change & Ressourcen"
|
||||
|
||||
beschreibung: |
|
||||
Die organisatorische Umsetzbarkeit bewertet die Rahmenbedingungen für
|
||||
eine erfolgreiche Realisierung.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Verfügbarkeit notwendiger Kompetenzen und Ressourcen"
|
||||
- "Veränderungsbereitschaft in betroffenen Bereichen"
|
||||
- "Klarheit der Zuständigkeiten und Verantwortlichkeiten"
|
||||
- "Tragfähigkeit des geplanten Betriebsmodells"
|
||||
- "Unterstützung durch relevante Stakeholder"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
punkte_1: "Grundlegende organisatorische Hindernisse"
|
||||
punkte_3: "Umsetzbar mit moderaten Anpassungen"
|
||||
punkte_5: "Optimale organisatorische Voraussetzungen"
|
||||
|
||||
- kriterium_id: "ressourceneffizienz"
|
||||
name: "Ressourceneffizienz"
|
||||
kernfrage: "Steht der Aufwand im Verhältnis zum Nutzen?"
|
||||
fokus: "Kosten-Nutzen-Relation"
|
||||
|
||||
beschreibung: |
|
||||
Die Ressourceneffizienz bewertet das Verhältnis von Aufwand zu
|
||||
erwartetem Nutzen.
|
||||
|
||||
bewertungsaspekte:
|
||||
- "Investitionsvolumen in Relation zum erwarteten Nutzen"
|
||||
- "Folgekosten und Betriebsaufwände"
|
||||
- "Personalbindung und Opportunitätskosten"
|
||||
- "Wiederverwendbarkeit von Ergebnissen"
|
||||
- "Skaleneffekte und Synergien"
|
||||
|
||||
orientierung_bewertungsskala:
|
||||
hinweis: "Inverse Skala"
|
||||
punkte_1: "Sehr ungünstiges Aufwand-Nutzen-Verhältnis"
|
||||
punkte_3: "Angemessener Ressourceneinsatz"
|
||||
punkte_5: "Exzellentes Aufwand-Nutzen-Verhältnis"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 PROJEKT-PORTFOLIO-ABGLEICH
|
||||
# ----------------------------------
|
||||
|
||||
projekt_portfolio_abgleich:
|
||||
beschreibung: |
|
||||
Vor der Bewertung erfolgt ein systematischer Abgleich mit dem bestehenden
|
||||
Projekt-Portfolio. Der DPM initiiert diesen Abgleich in Zusammenarbeit mit dem PPM.
|
||||
|
||||
szenarien:
|
||||
- szenario: "integration_laufendes_projekt"
|
||||
name: "Szenario 1: Integration in laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird direkt an das Projektteam übergeben"
|
||||
- "Integration in bestehende Projektstrukturen"
|
||||
- "Keine separate Bewertung erforderlich"
|
||||
|
||||
- szenario: "abhaengigkeit_laufendes_projekt"
|
||||
name: "Szenario 2: Abhängigkeit von laufendem Projekt"
|
||||
massnahmen:
|
||||
- "Demand wird zurückgestellt bis Projektabschluss"
|
||||
- "Aufnahme ins Backlog mit Wiedervorlage"
|
||||
- "Bewertung erfolgt nach Projektabschluss"
|
||||
|
||||
- szenario: "beeinflussung_laufendes_projekt"
|
||||
name: "Szenario 3: Beeinflussung durch laufendes Projekt"
|
||||
massnahmen:
|
||||
- "Neubewertung des Bedarfs im Projektkontext"
|
||||
- "Abstimmung mit Stakeholder über angepassten Bedarf"
|
||||
- "Bewertung auf Basis der veränderten Ausgangslage"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 CLUSTER-BASIERTE BEWERTUNG
|
||||
# ----------------------------------
|
||||
|
||||
cluster_bewertung:
|
||||
beschreibung: |
|
||||
Die operative Bewertung erfolgt als strukturierter Prozess, der die neun
|
||||
Kriterien über ihre drei Cluster handhabbar macht.
|
||||
|
||||
bewertungsprozess:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Projekt-Portfolio-Abgleich als Vorstufe"
|
||||
referenz: "siehe 4.1"
|
||||
|
||||
- schritt: 2
|
||||
name: "Clusterweise Bewertung"
|
||||
beschreibung: "Die Bewertung erfolgt clusterweise, um thematisch zusammenhängende Aspekte im Kontext zu betrachten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vergabe von Orientierungswerten"
|
||||
skala: "1-5 Punkte"
|
||||
|
||||
- schritt: 4
|
||||
name: "Mustererkennung"
|
||||
fokus: "Innerhalb und zwischen Clustern"
|
||||
|
||||
- schritt: 5
|
||||
name: "Qualitative Interpretation"
|
||||
output: "Cluster-Fazit mit Handlungsimplikationen"
|
||||
|
||||
ergebnisdokumentation:
|
||||
beschreibung: "Für jedes Cluster entsteht ein Fazit, das die Einzelwerte interpretiert und Handlungsimplikationen ableitet"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 DOKUMENTATIONSFORMAT
|
||||
# ----------------------------------
|
||||
|
||||
dokumentationsformat:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
CLUSTER 1: NUTZEN & WIRKUNG
|
||||
|
||||
Strategische Passung: [○○○○○] [(x/5)]
|
||||
Nutzen: [○○○○○] [(x/5)]
|
||||
Integrationswirkung: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 1 Fazit: [Qualitative Einschätzung der Stärken und Schwächen]
|
||||
|
||||
CLUSTER 2: DRUCK & NOTWENDIGKEIT
|
||||
|
||||
Organisationsrelevanz: [○○○○○] [(x/5)]
|
||||
Risiko bei Nicht-Umsetzung:[○○○○○] [(x/5)]
|
||||
Zeitliche Dringlichkeit: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 2 Fazit: [Interpretation des Handlungsdrucks]
|
||||
|
||||
CLUSTER 3: MACHBARKEIT & AUFWAND
|
||||
|
||||
Technische Machbarkeit: [○○○○○] [(x/5)]
|
||||
Organisatorische Umsetzbarkeit: [○○○○○] [(x/5)]
|
||||
Ressourceneffizienz: [○○○○○] [(x/5)]
|
||||
|
||||
Cluster 3 Fazit: [Einschätzung der Realisierbarkeit]
|
||||
|
||||
GESAMTBEURTEILUNG: [Zusammenfassende Bewertung mit konkreter Handlungsempfehlung]
|
||||
|
||||
# ========================================
|
||||
# 5. MULTI-STAKEHOLDER-PERSPEKTIVE
|
||||
# ========================================
|
||||
|
||||
multi_stakeholder_perspektive:
|
||||
beschreibung: "Integration unterschiedlicher Stakeholder-Perspektiven in die Demand-Bewertung (DIGIT-intern)"
|
||||
|
||||
funktionen:
|
||||
- "Früherkennung von Konflikten: Divergierende Bewertungen identifizieren potenzielle Widerstände vor der Umsetzung"
|
||||
- "Vollständigeres Bild: Verschiedene Blickwinkel decken blinde Flecken in der Bewertung auf"
|
||||
- "Erhöhte Akzeptanz: Einbeziehung verschiedener Perspektiven schafft Commitment für spätere Entscheidungen"
|
||||
- "Risikominimierung: Fundamentale Interessenskonflikte werden sichtbar bevor Ressourcen gebunden werden"
|
||||
|
||||
dokumentation:
|
||||
beschreibung: "Divergierende Einschätzungen werden mit Begründung erfasst"
|
||||
|
||||
template: |
|
||||
MULTI-STAKEHOLDER PERSPEKTIVE
|
||||
|
||||
KRITERIUM: [Bewertungskriterium, das divergent ist]
|
||||
|
||||
[Stakeholder A] [○○○○○] [(x/5)] [Begründung Stakeholder A]
|
||||
[Stakeholder B] [○○○○○] [(x/5)] [Begründung Stakeholder B]
|
||||
|
||||
Handlungsbedarf: [Beschreibung]
|
||||
|
|
@ -0,0 +1,421 @@
|
|||
meta:
|
||||
typ: "priorisierungsmethodik"
|
||||
methode: "demand_priorisierung"
|
||||
titel: "Priorisierungsverfahren im Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
basiert_auf: "#01.4_methodik/demand-bewertung.yaml"
|
||||
erzeugt: "handlungsempfehlungen_fuer_gremien"
|
||||
|
||||
kontext_tags:
|
||||
- "priorisierung"
|
||||
- "eisenhower-matrix"
|
||||
- "handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND FUNKTION
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Das Priorisierungsverfahren bildet den finalen Schritt der Demand-Bewertung
|
||||
und überführt die qualitative Analyse in konkrete Handlungsempfehlungen.
|
||||
|
||||
funktionen:
|
||||
- "Entscheidungsvorbereitung: Strukturierte Aufbereitung für Gremienentscheidungen"
|
||||
- "Ressourcenoptimierung: Fokussierung auf die wirkungsvollsten Demands bei begrenzten Kapazitäten"
|
||||
- "Transparenz: Nachvollziehbare Darstellung von Prioritäten für alle Stakeholder"
|
||||
- "Handlungsorientierung: Klare Strategien für unterschiedliche Demand-Typen"
|
||||
|
||||
methodik: |
|
||||
Die Priorisierung erfolgt mittels einer erweiterten Eisenhower-Matrix, die
|
||||
durch eine Farbcodierung zur Entscheidungsgrundlage wird.
|
||||
|
||||
# ========================================
|
||||
# 2. DIE ERWEITERTE EISENHOWER-MATRIX
|
||||
# ========================================
|
||||
|
||||
eisenhower_matrix:
|
||||
|
||||
# ----------------------------------
|
||||
# 2.1 GRUNDSTRUKTUR
|
||||
# ----------------------------------
|
||||
|
||||
grundstruktur:
|
||||
beschreibung: "Die Matrix strukturiert Demands anhand zweier primärer Dimensionen"
|
||||
|
||||
dimension_y:
|
||||
name: "Wichtigkeit"
|
||||
beschreibung: "Der strategische und operative Wert des Demands"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Nutzen & Wirkung\""
|
||||
bewertet: "Langfristigen Beitrag zu Organisationszielen"
|
||||
|
||||
dimension_x:
|
||||
name: "Dringlichkeit"
|
||||
beschreibung: "Der zeitliche und situative Handlungsdruck"
|
||||
ableitung: "Abgeleitet aus dem Bewertungscluster \"Druck & Notwendigkeit\""
|
||||
bewertet: "Notwendigkeit zeitnaher Umsetzung"
|
||||
|
||||
einordnung: |
|
||||
Die Einordnung erfolgt nicht mechanisch über Schwellenwerte, sondern durch
|
||||
interpretative Zuordnung basierend auf den qualitativen Cluster-Bewertungen.
|
||||
|
||||
# ----------------------------------
|
||||
# 2.2 DIE VIER QUADRANTEN
|
||||
# ----------------------------------
|
||||
|
||||
quadranten:
|
||||
- quadrant_id: "q1"
|
||||
name: "Quadrant 1: Sofort angehen"
|
||||
achsen: "Wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Handlungsdruck bei gleichzeitig hoher strategischer Relevanz"
|
||||
- "Kritische Abhängigkeiten oder externe Anforderungen"
|
||||
- "Signifikante Risiken bei Verzögerung"
|
||||
- "Unmittelbare Auswirkungen auf Kernprozesse"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Regulatorische Vorgaben mit festen Fristen"
|
||||
- "Sicherheitskritische Anforderungen"
|
||||
- "Ausfälle geschäftskritischer Systeme"
|
||||
- "Verbindliche politische Zusagen"
|
||||
|
||||
- quadrant_id: "q2"
|
||||
name: "Quadrant 2: Strategisch planen"
|
||||
achsen: "Wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Hoher Wertbeitrag ohne unmittelbaren Zeitdruck"
|
||||
- "Strukturverändernde Vorhaben mit Zukunftspotenzial"
|
||||
- "Befähigung für weitere Entwicklungsschritte"
|
||||
- "Nachhaltige Verbesserung der Leistungsfähigkeit"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "IT-Architekturmodernisierungen"
|
||||
- "Strategische Digitalisierungsinitiativen"
|
||||
- "Kompetenzaufbau und Befähigungsprojekte"
|
||||
- "Grundlegende Prozessoptimierungen"
|
||||
|
||||
- quadrant_id: "q3"
|
||||
name: "Quadrant 3: Effizient abarbeiten"
|
||||
achsen: "Nicht wichtig & Dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Zeitlicher Druck ohne strategische Bedeutung"
|
||||
- "Lokale oder temporäre Problemstellungen"
|
||||
- "Erfüllung operativer Notwendigkeiten"
|
||||
- "Vermeidung kurzfristiger Störungen"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Kleinere Compliance-Anpassungen"
|
||||
- "Behebung operativer Engpässe"
|
||||
- "Erfüllung von Einzelanfragen mit Terminvorgabe"
|
||||
- "Technische Wartungsarbeiten"
|
||||
|
||||
- quadrant_id: "q4"
|
||||
name: "Quadrant 4: Kritisch prüfen"
|
||||
achsen: "Nicht wichtig & Nicht dringend"
|
||||
|
||||
charakteristika:
|
||||
- "Geringer Wertbeitrag ohne Handlungsdruck"
|
||||
- "Isolierte Verbesserungswünsche"
|
||||
- "Optionale Erweiterungen"
|
||||
- "Unclear Business Case"
|
||||
|
||||
typische_demand_kategorien:
|
||||
- "Nice-to-have Features"
|
||||
- "Einzelinteressen ohne breiten Nutzen"
|
||||
- "Technologiegetriebene Experimente"
|
||||
- "Redundante Anforderungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 2.3 DRITTE DIMENSION: FARBCODIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
farbcodierung:
|
||||
beschreibung: |
|
||||
Die Farbcodierung visualisiert die Umsetzungskomplexität basierend auf dem
|
||||
Cluster-Fazit "Machbarkeit & Aufwand". Sie erfolgt durch qualitative Interpretation.
|
||||
|
||||
ableitung: "Aus Cluster 3: Machbarkeit & Aufwand"
|
||||
|
||||
farben:
|
||||
- farbe: "gruen"
|
||||
symbol: "🟢"
|
||||
name: "Grün - Gut machbar"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt keine kritischen Hindernisse. Die Umsetzung ist
|
||||
mit vorhandenen Mitteln und etablierten Vorgehensweisen möglich.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch mit Bordmitteln umsetzbar, Organisation vorbereitet, Ressourcen im Rahmen"
|
||||
- "Bewährte Lösungsansätze vorhanden, moderate Komplexität, gute Akzeptanz erwartet"
|
||||
|
||||
- farbe: "gelb"
|
||||
symbol: "🟡"
|
||||
name: "Gelb - Herausfordernd"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit identifiziert überwindbare Hürden. Die Umsetzung erfordert
|
||||
zusätzlichen Aufwand, besondere Koordination oder externe Unterstützung.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technisch machbar aber komplex, erhöhter Koordinationsaufwand, Ressourcen knapp"
|
||||
- "Neue Technologie erforderlich, Change-Management notwendig, externe Expertise benötigt"
|
||||
|
||||
- farbe: "rot"
|
||||
symbol: "🔴"
|
||||
name: "Rot - Kritisch"
|
||||
beschreibung: |
|
||||
Das Cluster-Fazit zeigt fundamentale Hindernisse. Mindestens ein Aspekt wirkt
|
||||
blockierend (Dominanz-Prinzip) oder die Gesamtkonstellation ist hochproblematisch.
|
||||
|
||||
interpretationsbeispiele:
|
||||
- "Technologie noch nicht ausgereift, massive organisatorische Widerstände, Ressourcen nicht darstellbar"
|
||||
- "Grundlegende Architekturprobleme, fehlendes Know-how, prohibitive Kosten"
|
||||
|
||||
# ========================================
|
||||
# 3. HANDLUNGSSTRATEGIEN
|
||||
# ========================================
|
||||
|
||||
handlungsstrategien:
|
||||
beschreibung: |
|
||||
Die Kombination aus Quadrant (Was ist zu tun?) und Farbe (Wie komplex ist es?)
|
||||
bestimmt die spezifische Handlungsstrategie.
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 1: SOFORT ANGEHEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_1_strategien:
|
||||
quadrant: "q1"
|
||||
name: "Sofort angehen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direkte Aufbereitung für DSR-Entscheidung"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Sprint-Organisation mit dediziertem Team"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Identifikation kritischer Erfolgsfaktoren und Risiken"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Task-Force mit Expertenbeteiligung und engem Monitoring"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Sofortige Eskalation mit Lösungsoptionen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Krisenstab unter Führungsebene mit externen Ressourcen"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 2: STRATEGISCH PLANEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_2_strategien:
|
||||
quadrant: "q2"
|
||||
name: "Strategisch planen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Integration in Quartalsplanung vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Aufnahme in kurzfristige Roadmap"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Initiierung einer Machbarkeitsstudie empfehlen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Mittelfristige Planung mit Vorbereitungsphase"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Grundlagenanalyse und Transformationsplan anregen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Langfriststrategie mit fundamentalen Vorarbeiten"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 3: EFFIZIENT ABARBEITEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_3_strategien:
|
||||
quadrant: "q3"
|
||||
name: "Effizient abarbeiten"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "Direktzuweisung an operative Teams vorschlagen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Delegation mit Standardvorgehen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Alternative Lösungswege aufzeigen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Pragmatische Alternativlösung oder Workaround"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Notwendigkeit grundsätzlich hinterfragen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Ablehnung oder Verschiebung nach Q4"
|
||||
|
||||
# ----------------------------------
|
||||
# QUADRANT 4: KRITISCH PRÜFEN
|
||||
# ----------------------------------
|
||||
|
||||
quadrant_4_strategien:
|
||||
quadrant: "q4"
|
||||
name: "Kritisch prüfen"
|
||||
|
||||
strategien:
|
||||
- farbe: "gruen"
|
||||
dpm_handlung:
|
||||
- "In Backlog aufnehmen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Bei Kapazitäten als Lernprojekt nutzen"
|
||||
|
||||
- farbe: "gelb"
|
||||
dpm_handlung:
|
||||
- "Periodische Neubewertung vorsehen"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Zurückstellung mit jährlicher Überprüfung"
|
||||
|
||||
- farbe: "rot"
|
||||
dpm_handlung:
|
||||
- "Ablehnungsempfehlung vorbereiten"
|
||||
|
||||
dpm_empfehlung_gremien:
|
||||
- "Definitive Ablehnung aus Portfoliosicht"
|
||||
|
||||
# ========================================
|
||||
# 4. OPERATIVE ANWENDUNG
|
||||
# ========================================
|
||||
|
||||
operative_anwendung:
|
||||
prozess:
|
||||
schritt_1:
|
||||
name: "Ableitung der Dimensionen"
|
||||
aktivitaeten:
|
||||
- dimension: "wichtigkeit"
|
||||
quelle: "Cluster \"Nutzen & Wirkung\""
|
||||
- dimension: "dringlichkeit"
|
||||
quelle: "Cluster \"Druck & Notwendigkeit\""
|
||||
- dimension: "farbe"
|
||||
quelle: "Cluster \"Machbarkeit & Aufwand\""
|
||||
|
||||
schritt_2:
|
||||
name: "Qualitative Einordnung"
|
||||
aktivitaeten:
|
||||
- "Interpretation der Cluster-Fazits"
|
||||
- "Keine mechanische Punkteaggregation"
|
||||
- "Begründete Zuordnung zu Quadranten und Farbe"
|
||||
|
||||
schritt_3:
|
||||
name: "Strategieableitung"
|
||||
aktivitaeten:
|
||||
- "Handlungsempfehlung gemäß Matrix"
|
||||
- "Berücksichtigung der Farbcodierung"
|
||||
- "Anpassung an organisatorischen Kontext"
|
||||
|
||||
schritt_4:
|
||||
name: "Dokumentation"
|
||||
aktivitaeten:
|
||||
- "Transparente Darstellung der Einordnung"
|
||||
- "Nachvollziehbare Begründung"
|
||||
- "Klare Handlungsempfehlung"
|
||||
|
||||
# ========================================
|
||||
# 5. DOKUMENTATIONSSTANDARD
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
|
||||
# ----------------------------------
|
||||
# 5.1 PRIORISIERUNGSDOKUMENTATION
|
||||
# ----------------------------------
|
||||
|
||||
priorisierungsdokumentation:
|
||||
template: |
|
||||
DEMAND: [Titel]
|
||||
|
||||
PRIORISIERUNG:
|
||||
|
||||
Wichtigkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 1]
|
||||
|
||||
Dringlichkeit: [Ausprägung]
|
||||
Begründung: [Basierend auf Cluster 2]
|
||||
|
||||
Machbarkeit: [Ausprägung] + [Ampel]
|
||||
Begründung: [Basierend auf Cluster 3]
|
||||
|
||||
Einordnung: [Quadrant]
|
||||
|
||||
HANDLUNGSEMPFEHLUNG:
|
||||
|
||||
DPM-Aktion: [Was tut der DPM]
|
||||
|
||||
Gremienempfehlung: [Was empfiehlt der DPM]
|
||||
|
||||
Nächste Schritte: [Konkrete Maßnahmen]
|
||||
|
||||
# ----------------------------------
|
||||
# 5.2 DEMAND-PORTFOLIO-ÜBERSICHT
|
||||
# ----------------------------------
|
||||
|
||||
portfolio_dashboard:
|
||||
beschreibung: "Aggregierte Darstellung für DSR/MB"
|
||||
|
||||
template_struktur: |
|
||||
DEMAND-PORTFOLIO DASHBOARD
|
||||
|
||||
Quadrant 🟢 🟡 🔴 Gesamt Hinweise
|
||||
-------------------------------------------------------
|
||||
Q1 Sofort 2 1 1 4 ! Rot → MB-Delegation
|
||||
Q2 Planen 3 2 0 5 ✓ Ausgewogen
|
||||
Q3 Abarbeiten 4 1 0 5 ✓ Gut delegierbar
|
||||
Q4 Prüfen 1 1 2 4 ! Rote ablehnen
|
||||
-------------------------------------------------------
|
||||
Gesamt: 10 5 3 18
|
||||
|
||||
interpretation:
|
||||
gruen_dominant: "Gut umsetzbare Demands dominieren - positive Portfoliogesundheit"
|
||||
gelb_haeufung: "Viele Herausforderungen - Ressourcenplanung kritisch"
|
||||
rot_in_q1: "Kritische Demands mit Druck - MB-Eskalation prüfen"
|
||||
rot_in_q4: "Eindeutige Ablehnungskandidaten"
|
||||
|
||||
# ========================================
|
||||
# VISUALISIERUNG FÜR GREMIEN
|
||||
# ========================================
|
||||
|
||||
visualisierung:
|
||||
hinweis: "Die Matrix wird typischerweise als 2x2-Grid mit farbigen Punkten für Demands visualisiert"
|
||||
|
||||
best_practices:
|
||||
- "Demands als Punkte mit Beschriftung in der Matrix platzieren"
|
||||
- "Farbcodierung für schnelle Erfassung der Machbarkeit"
|
||||
- "Clustering ähnlicher Demands erkennbar machen"
|
||||
- "Bewegung von Demands zwischen Quadranten im Zeitverlauf zeigen"
|
||||
|
|
@ -0,0 +1,401 @@
|
|||
meta:
|
||||
typ: "geschaeftsordnung"
|
||||
gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
aliases: ["DSR", "Demand-Runde", "Stakeholder-Runde"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
abstimmung:
|
||||
sparring_mit: ["shm", "spm"]
|
||||
abgestimmt_mit: ["DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "governance"
|
||||
- "entscheidungsgremium"
|
||||
- "demand-lifecycle"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK UND GELTUNGSBEREICH
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
verankerung: "Steuerungs- und Entscheidungsgremium im DIGITOM"
|
||||
|
||||
funktion: |
|
||||
Brücke zwischen Bedarfserfassung (Stakeholder-Management) und
|
||||
Projektinitiierung (Projekt-Portfolio-Management).
|
||||
|
||||
regelungsumfang:
|
||||
- "Arbeitsweise der DSR"
|
||||
- "Entscheidungsverfahren"
|
||||
- "Schnittstellen im Demand-Lifecycle"
|
||||
|
||||
geltungsbereich:
|
||||
inkludiert:
|
||||
- typ: "DSR-Demands"
|
||||
beschreibung: "Demands ohne automatische MB-Trigger gemäß Demand-Klassifizierung"
|
||||
|
||||
- typ: "DSR-Demands mit Delegationsoption"
|
||||
beschreibung: "Demands mit Option zur Delegation ans Mission Board"
|
||||
|
||||
rolle_bei_mb_demands: "vorbereitendes und empfehlendes Gremium"
|
||||
|
||||
# ========================================
|
||||
# 2. AUFGABEN UND KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
aufgaben:
|
||||
charakter: "hybrides Gremium mit zwei Funktionsbereichen"
|
||||
|
||||
entscheidungsfunktion:
|
||||
gueltig_fuer: "DSR-Demands"
|
||||
|
||||
entscheidungsoptionen:
|
||||
- option: "freigabe_zur_umsetzung"
|
||||
beschreibung: "Freigabe zur Umsetzungsplanung und Übergabe an PPM"
|
||||
naechster_schritt: "Projekt-Initiierung durch PPM"
|
||||
|
||||
- option: "ablehnung"
|
||||
beschreibung: "Ablehnung und Weitergabe ans SHM für Stakeholder-Kommunikation"
|
||||
naechster_schritt: "SHM kommuniziert Ablehnung"
|
||||
|
||||
- option: "delegation_mission_board"
|
||||
trigger: ["strategische_relevanz", "kompetenzueberschreitung"]
|
||||
beschreibung: "Delegation ans Mission Board"
|
||||
naechster_schritt: "Mission Board entscheidet"
|
||||
|
||||
- option: "vertagung_fehlende_grundlagen"
|
||||
trigger: "fehlende_entscheidungsgrundlagen"
|
||||
beschreibung: "Weitere Aufarbeitung durch DPM erforderlich"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- option: "vertagung_einwand"
|
||||
trigger: "begruendeter_einwand"
|
||||
beschreibung: "Weitere Aufarbeitung durch einwendende Rolle (Konsent-Prinzip)"
|
||||
verantwortlich: "einwendende_rolle"
|
||||
|
||||
informations_und_abstimmungsfunktion:
|
||||
aktivitaeten:
|
||||
- name: "Informationsaustausch"
|
||||
gegenstand:
|
||||
- "offene Demands"
|
||||
- "laufende Projekte (durch DSR freigegeben)"
|
||||
|
||||
- name: "Abstimmung"
|
||||
themen:
|
||||
- "Abhängigkeiten zwischen Demands/Projekten"
|
||||
- "Ressourcen-Bedarfe für DSR-freigegebene Projekte"
|
||||
|
||||
# ========================================
|
||||
# 3. ZUSAMMENSETZUNG
|
||||
# ========================================
|
||||
|
||||
zusammensetzung:
|
||||
stimmberechtigte_mitglieder:
|
||||
anzahl: 4
|
||||
|
||||
rationale: |
|
||||
Vollständiger Demand-Lifecycle abgebildet: Bedarfserfassung (SHM) →
|
||||
Qualifizierung (DPM) → Service-Impact-Analyse (SPM) → Projekt-Integration (PPM)
|
||||
|
||||
mitglieder:
|
||||
- rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Management"
|
||||
funktion: "vorsitz"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
funktion: "mitglied"
|
||||
stimmberechtigt: true
|
||||
|
||||
vertretungsregelung:
|
||||
flexibel: true
|
||||
beschreibung: "Mitglieder benennen ihre Vertretungen flexibel"
|
||||
vertretungs_kompetenzen: "Vertretungen sind stimmberechtigt und haben volle Kompetenzen der vertretenen Rolle"
|
||||
|
||||
zusaetzliche_teilnehmende:
|
||||
erlaubt: true
|
||||
status: "beratend"
|
||||
stimmberechtigt: false
|
||||
|
||||
typische_teilnehmende:
|
||||
- "Owner betroffener Services"
|
||||
- "Owner betroffener Produkte"
|
||||
- "Owner betroffener Infrastruktur-Komponenten"
|
||||
- "Fachexperten (z.B. IT-Architektur)"
|
||||
|
||||
einladung_durch: "dpm"
|
||||
|
||||
# ========================================
|
||||
# 4. ARBEITSWEISE
|
||||
# ========================================
|
||||
|
||||
arbeitsweise:
|
||||
sitzungsrhythmus:
|
||||
pilotphase:
|
||||
frequenz: "woechentlich"
|
||||
termin: "fester Termin"
|
||||
dauer_minuten: 90
|
||||
|
||||
regelzeit:
|
||||
hinweis: "wird nach Pilotphase definiert"
|
||||
|
||||
sondersitzungen:
|
||||
erfragen_durch: "jedes Mitglied"
|
||||
einberufung_durch: "dpm"
|
||||
|
||||
vorbereitung_und_dokumentation:
|
||||
vorbereitung:
|
||||
verantwortlich: "dpm"
|
||||
unterlagen_vorlauf_stunden: 24
|
||||
beschreibung: "Unterlagen müssen 24h vor Sitzung verfügbar sein"
|
||||
|
||||
protokollfuehrung:
|
||||
verantwortlich: "dpm"
|
||||
typ: "Entscheidungsprotokoll"
|
||||
basis: "Demand-Portfolio-Übersicht"
|
||||
|
||||
ablage:
|
||||
ort: "Confluence"
|
||||
zugriff: "DIGIT-weit"
|
||||
|
||||
kommunikation:
|
||||
timing: "unmittelbar nach Sitzung"
|
||||
gegenstand: "Entscheidungen werden kommuniziert"
|
||||
|
||||
agenda_struktur:
|
||||
referenz: "dsr-standard-agenda.yaml"
|
||||
hinweis: "Detaillierte Agenda-Struktur in separatem Dokument definiert"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSVERFAHREN
|
||||
# ========================================
|
||||
|
||||
entscheidungsverfahren:
|
||||
prinzip: "konsent_mit_alternativzwang"
|
||||
|
||||
konsent_ablauf:
|
||||
schritt_1:
|
||||
name: "Vorschlag einbringen"
|
||||
akteur: "dpm"
|
||||
inhalt: "DPM bringt Entscheidungsvorschlag ein"
|
||||
|
||||
schritt_2:
|
||||
name: "Verständnisfragen klären"
|
||||
bedingung: "sofern vorhanden"
|
||||
|
||||
schritt_3:
|
||||
name: "Einwände prüfen"
|
||||
regel: "Ohne schwerwiegenden, begründeten Einwand gilt Vorschlag als angenommen"
|
||||
|
||||
bei_einwand:
|
||||
verantwortung: "einwendende Rolle"
|
||||
verpflichtung: "muss Entscheidungsvorlage überarbeiten und konstruktive Alternative einbringen"
|
||||
|
||||
bei_mehreren_einwaenden:
|
||||
prozess: "gemeinsame Erarbeitung des Alternativ-Vorschlags"
|
||||
|
||||
iteratives_verfahren:
|
||||
beschreibung: "Überarbeitete Entscheidungsvorlage unterliegt selbst wieder dem Konsent-Prinzip"
|
||||
|
||||
eskalation:
|
||||
trigger: "nach zwei Iterationen ohne Einigung (bei drittem Einwand)"
|
||||
option: "DPM kann ans Mission Board eskalieren"
|
||||
|
||||
beschlussfaehigkeit:
|
||||
bedingung: "alle vier Rollen durch Mitglieder oder Vertretungen besetzt"
|
||||
|
||||
entscheidungen_unter_auflagen:
|
||||
erlaubt: true
|
||||
beschreibung: "DSR kann Demands unter Auflagen freigeben"
|
||||
status: "verbindlicher Teil des Beschlusses"
|
||||
|
||||
erfuellung:
|
||||
zeitpunkt: "vor/während der Umsetzung"
|
||||
ueberwachung_durch: "ppm"
|
||||
|
||||
bei_nicht_erfuellung:
|
||||
massnahme: "Umsetzung stoppen"
|
||||
naechster_schritt: "Vorlage an DSR zur Neuentscheidung"
|
||||
|
||||
virtuelle_hybride_asynchrone:
|
||||
virtuell_hybrid:
|
||||
status: "gleichwertig zu Präsenzsitzungen"
|
||||
|
||||
asynchron:
|
||||
status: "in Entwicklung"
|
||||
hinweis: "Werden bei Bedarf während Pilotphase entwickelt und getestet"
|
||||
moegliche_mechanismen:
|
||||
- "Kommentierungsfunktion"
|
||||
- "Voting"
|
||||
|
||||
entscheidungsvarianten_nach_demand_typ:
|
||||
mb_demand:
|
||||
beschreibung: "Mission Board-Demand (wird durch DSR vorbereitet)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung"
|
||||
|
||||
dsr_demand_mit_delegation:
|
||||
beschreibung: "DSR-Demand mit Delegationsoption ans Mission Board"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Delegationsempfehlung/Begründung"
|
||||
|
||||
dsr_demand:
|
||||
beschreibung: "DSR-Demand (DSR entscheidet final)"
|
||||
einwaende_moeglich_zu:
|
||||
- "Klassifizierung"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Empfehlung/Begründung: Freigabe oder Ablehnung"
|
||||
|
||||
# ========================================
|
||||
# 6. RESSOURCENMOBILISIERUNG UND PROJEKTUMSETZUNG
|
||||
# ========================================
|
||||
|
||||
ressourcenmobilisierung:
|
||||
beschreibung: "Prozess nach Freigabe eines DSR-Demands"
|
||||
|
||||
projektinitiierung:
|
||||
schritt_1:
|
||||
name: "Projekt-Aufnahme"
|
||||
beschreibung: "Demand wird formal als Projekt ins Projekt-Portfolio aufgenommen"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
schritt_2:
|
||||
name: "Sponsoring"
|
||||
regelfall: "SPM übernimmt Sponsor:innen-Rolle bei service-/produkt-/infrastrukturbezogenen DSR-Demands"
|
||||
verantwortlich: "spm"
|
||||
|
||||
projektleitung_und_ressourcen:
|
||||
projektleitung_benennung:
|
||||
verantwortlich: "spm"
|
||||
prozess: "SPM benennt abgestimmte Projektleitung und meldet an PPM"
|
||||
regelfall: "Owner des betroffenen Services/Produkts wird Projektleitung"
|
||||
|
||||
scope_definition:
|
||||
verantwortlich: ["spm", "projektleitung"]
|
||||
prozess: "SPM definiert gemeinsam mit Projektleitung den Scope"
|
||||
|
||||
ressourcenmobilisierung:
|
||||
verantwortlich: "projektleitung"
|
||||
prozess: "Projektleitung mobilisiert Ressourcen"
|
||||
|
||||
bei_konflikten:
|
||||
eskalation_ueber: "ppm_oder_spm"
|
||||
eskalation_an: "dsr"
|
||||
weitere_eskalation_moeglich_an: "mission_board"
|
||||
|
||||
monitoring_und_steuerung:
|
||||
projekt_monitoring:
|
||||
verantwortlich: "ppm"
|
||||
umfang: "alle Projekte im Portfolio"
|
||||
|
||||
status_reporting:
|
||||
von: "ppm"
|
||||
an: "dsr"
|
||||
frequenz: "regelmäßig"
|
||||
gegenstand: "Projekte, die durch DSR beauftragt wurden"
|
||||
|
||||
bei_konflikten:
|
||||
inhaltliche_konflikte:
|
||||
klaerung_in: "dsr"
|
||||
eskalation_moeglich_an: "mission_board"
|
||||
|
||||
projektabschluss:
|
||||
inhaltliche_abnahme:
|
||||
verantwortlich: "spm"
|
||||
|
||||
formaler_abschluss:
|
||||
verantwortlich: "ppm"
|
||||
prozess: "Projekt formal im Portfolio schließen"
|
||||
|
||||
# ========================================
|
||||
# 7. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
- ausloeser: "DSR Freigabe (DSR-Demand)"
|
||||
von: "dsr"
|
||||
zu: "ppm"
|
||||
zweck: "Projektaufnahme, Umsetzung starten"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
- "Auflagen"
|
||||
verantwortlich: ["dpm", "ppm"]
|
||||
|
||||
- ausloeser: "Service-Betroffenheit, Sponsoring & Owner-Einbindung"
|
||||
zwischen: ["dsr", "spm"]
|
||||
art: "bidirektional"
|
||||
zweck: "Sponsoring, Owner-Einbindung"
|
||||
artefakte:
|
||||
- "Protokoll"
|
||||
- "Owner-Liste"
|
||||
verantwortlich: "spm"
|
||||
|
||||
- ausloeser: "Delegation ans MB"
|
||||
von: "dsr"
|
||||
zu: "mission_board"
|
||||
zweck: "Strategische Entscheidung herbeiführen"
|
||||
artefakte:
|
||||
- "MB Vorlage"
|
||||
- "DSR Empfehlung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Rückmeldungen an Stakeholder"
|
||||
kontext: "Freigaben/Zurückstellungen mit Auflagen, Übergabe in Projekt-/Umsetzungssteuerung, Reporting"
|
||||
von: ["dsr", "ppm", "spm"]
|
||||
zu: "shm"
|
||||
zweck: "Entscheidung/Begründung kommunizieren"
|
||||
artefakte:
|
||||
- "Beschluss"
|
||||
verantwortlich: "shm"
|
||||
|
||||
themen:
|
||||
- "Wiedervorlagen"
|
||||
- "Steckbrief-/User-Story-Bezug"
|
||||
|
||||
- ausloeser: "Architektur-Grundsatzfrage"
|
||||
von: "dsr"
|
||||
zu: "it_architektur_board"
|
||||
zweck: "Klärung technischer Leitplanken"
|
||||
artefakte:
|
||||
- "Kurzlage/Fragestellung"
|
||||
verantwortlich: "dpm"
|
||||
|
||||
- ausloeser: "Projekt Reporting"
|
||||
von: "ppm"
|
||||
zu: ["dsr", "mission_board"]
|
||||
zweck: "Status, Risiken, Ressourcenlage kommunizieren"
|
||||
artefakte:
|
||||
- "Projekt-Portfolio Bericht"
|
||||
verantwortlich: "ppm"
|
||||
|
||||
# ========================================
|
||||
# 8. KONFLIKTBEHANDLUNG
|
||||
# ========================================
|
||||
|
||||
konfliktbehandlung:
|
||||
regelung: "Verantwortlichkeiten in Konfliktsituationen sind in RACI-Matrix geregelt"
|
||||
referenz: "raci-matrix-demand-portfolio-management.yaml"
|
||||
|
|
@ -0,0 +1,460 @@
|
|||
meta:
|
||||
typ: "funktionsbeschreibung"
|
||||
funktion_id: "dpm"
|
||||
funktion_name: "Demand-Portfolio-Management"
|
||||
aliases: ["DPM", "Demand-Portfolio-Funktion"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "funktion"
|
||||
- "systemische-perspektive"
|
||||
- "orchestrierung"
|
||||
- "neutralitaet"
|
||||
|
||||
# ========================================
|
||||
# ABKÜRZUNGSVERZEICHNIS
|
||||
# ========================================
|
||||
|
||||
abkuerzungen:
|
||||
dpm: "Demand-Portfolio-Management"
|
||||
dsr: "Demand & Stakeholder-Runde"
|
||||
mb: "Mission Board"
|
||||
vb: "Vision Board"
|
||||
shm: "Stakeholder-Management"
|
||||
spm: "Service-Portfolio-Management"
|
||||
ppm: "Projekt-Portfolio-Management"
|
||||
al_p: "Abteilungsleitung Planung"
|
||||
pl: "Projektleitung"
|
||||
pzm: "Prozess-Management"
|
||||
ita: "IT-Architektur-Board"
|
||||
sh: "Stakeholder"
|
||||
kpi: "Key Performance Indicator (Kennzahl)"
|
||||
raci: "Responsible / Accountable / Consulted / Informed"
|
||||
d2p: "Demand-to-Project (Prozess)"
|
||||
|
||||
# ========================================
|
||||
# 1. ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
wozu_existiert_diese_funktion:
|
||||
kurz: "Koordiniert den Fluss aller Demands im DIGIT vom vorqualifizierten Demand bis zur entscheidungsreifen Vorlage"
|
||||
|
||||
ausfuehrlich: |
|
||||
Das Demand-Portfolio-Management (DPM) übernimmt Demands aus dem Stakeholder-Management (SHM),
|
||||
klassifiziert, analysiert, bewertet und priorisiert sie und bringt sie als strukturierte
|
||||
Entscheidungsvorlagen in die zuständigen Gremien Demand & Stakeholder Runde (DSR) und
|
||||
Mission Board (MB) ein.
|
||||
|
||||
wertbeitrag:
|
||||
- "Transparenz"
|
||||
- "Vergleichbarkeit"
|
||||
- "Entscheidungsfähigkeit"
|
||||
|
||||
kritisches_merkmal: "Getrennt von der eigentlichen Freigabeentscheidung der Gremien"
|
||||
|
||||
hauptziel:
|
||||
beschreibung: "Ein kohärentes, strategiekonformes und entscheidungsfähiges Demand-Portfolio sicherstellen"
|
||||
|
||||
erreicht_durch:
|
||||
- id: "Z1"
|
||||
aktivitaet: "Systematische Überführung"
|
||||
beschreibung: "Vorqualifizierte Demands systematisch in Entscheidungsvorlagen überführen"
|
||||
umfasst:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
|
||||
- id: "Z2"
|
||||
aktivitaet: "Informationsfluss orchestrieren"
|
||||
beschreibung: "Informationsfluss zwischen SHM, DPM und Entscheidungsgremien orchestrieren"
|
||||
richtungen:
|
||||
- "Bottom-up"
|
||||
- "Top-down"
|
||||
- "Horizontal"
|
||||
|
||||
- id: "Z3"
|
||||
aktivitaet: "Trennung wahren"
|
||||
beschreibung: "Trennung von fachlicher Bewertung (DPM) und Entscheidung (DSR/MB) wahren"
|
||||
effekt: "Objektivität und Akzeptanz als neutrale Koordinationsinstanz stärken"
|
||||
|
||||
- id: "Z4"
|
||||
aktivitaet: "Portfolio-Erkenntnisse aufbereiten"
|
||||
beschreibung: "Demand-Portfolio-Erkenntnisse regelmäßig aufbereiten (Reviews)"
|
||||
effekt: "Bessere Koordination durch Mission Board und Abteilungsleitung Planung ermöglichen"
|
||||
|
||||
- id: "Z5"
|
||||
aktivitaet: "Zielbeitrag sichtbar machen"
|
||||
beschreibung: "Zielbeitrag anhand klarer KPIs sichtbar machen"
|
||||
|
||||
# ========================================
|
||||
# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG
|
||||
# ========================================
|
||||
|
||||
funktionsverstaendnis:
|
||||
charakterisierung:
|
||||
typ: "Bewertungs- und Orchestrierungsfunktion"
|
||||
|
||||
beschreibung: |
|
||||
Die neutrale Instanz, die Demands strukturiert bewertet, priorisiert und als
|
||||
Entscheidungsvorlagen in die zuständigen Gremien einbringt. Die Funktion hält
|
||||
Methodik, Routing und Demand-Portfolio-Transparenz zusammen – getrennt von der
|
||||
finalen Entscheidung und der operativen Umsetzung.
|
||||
|
||||
grundprinzipien:
|
||||
verantwortung_bleibt_wo_sie_hingehoert:
|
||||
beschreibung: "Klare Trennung zwischen Vorbereitung und Entscheidung"
|
||||
|
||||
entscheidungen:
|
||||
wo: "Gremien (DSR, MB)"
|
||||
was: "Freigabe, Ablehnung oder Delegation"
|
||||
dpm_rolle: "Bereitet vor, präsentiert, führt Beschlüsse nach – entscheidet aber nicht anstelle der Gremien"
|
||||
|
||||
linien_budget_verantwortung:
|
||||
wo: "MB und Fachbereiche"
|
||||
dpm_rolle: "Stellt Systematik und Entscheidungsreife sicher"
|
||||
|
||||
partnerschaft_statt_kontrolle:
|
||||
beschreibung: "DPM arbeitet auf Augenhöhe mit anderen Portfolio-Funktionen"
|
||||
|
||||
partnerschaften:
|
||||
- partner: "shm"
|
||||
beziehung: "SHM speist vorqualifizierte Demands ein"
|
||||
|
||||
- partner: "dpm"
|
||||
beziehung: "DPM qualifiziert und bündelt"
|
||||
|
||||
- partner: "spm"
|
||||
beziehung: "SPM bewertet Service-Auswirkungen"
|
||||
|
||||
- partner: "ppm"
|
||||
beziehung: "PPM integriert in das Projektportfolio"
|
||||
|
||||
institutionalisierung: "Diese Partnerschaft ist im DSR institutionalisiert (stimmberechtigte Kernrollen)"
|
||||
|
||||
arbeitsweise: "Folgt definierten Informationsflüssen (Bottom-up, Top-down, Horizontal) und fördert schnelle, anschlussfähige Entscheidungen statt 'Kontrolle'"
|
||||
|
||||
systematische_bewertung_transparenz:
|
||||
verantwortung_dpm:
|
||||
- "Klassifizierung"
|
||||
- "Analyse"
|
||||
- "Bewertung"
|
||||
- "Priorisierung"
|
||||
- "Erstellung Entscheidungsvorlagen"
|
||||
- "Sauberes Entscheidungs-Routing (je nach Tragweite, Komplexität, Systemebene, Treiber)"
|
||||
|
||||
transparenz: "DPM stellt Transparenz über ein zentrales Demand-Portfolio her und bereitet Reviews für MB/AL-Planung vor"
|
||||
|
||||
nicht_teil_des_mandats:
|
||||
- "Operative Projektentscheidungen"
|
||||
- "Umsetzungsleistungen"
|
||||
|
||||
abgrenzung_zu_angrenzenden_funktionen:
|
||||
- funktion: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
tut: "Erfasst und klärt den Bedarf mit Stakeholdern"
|
||||
uebergabe: "Übergibt vorqualifiziert an DPM"
|
||||
|
||||
- funktion: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
tut: "Klassifiziert, analysiert, bewertet, priorisiert, routet"
|
||||
uebergabe: "Bringt Vorlagen in DSR/MB ein"
|
||||
|
||||
- funktion: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
tut: "Prüft Service-Fit/-Impact und katalogseitige Konsequenzen"
|
||||
|
||||
- funktion: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
tut: "Integriert freigegebene Demands in das Projektportfolio"
|
||||
und: "Steuert Projektumsetzungen"
|
||||
|
||||
# ========================================
|
||||
# 3. VERANTWORTUNGSBEREICHE
|
||||
# ========================================
|
||||
|
||||
verantwortungsbereiche:
|
||||
|
||||
# ----------------------------------
|
||||
# 3.1 DEMAND-PORTFOLIO-MANAGEMENT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_1_portfolio_management:
|
||||
id: "VB1"
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
was:
|
||||
- "Zentrales Demand-Portfolio führen und aktuell halten"
|
||||
- "Trends und Muster analysieren"
|
||||
- "Demand-Portfolio-Methodiken optimieren"
|
||||
- "Entlang Vision-Board-Leitplanken bewerten und priorisieren"
|
||||
|
||||
warum:
|
||||
- "Strategiekonforme, ressourcenfähige Auswahl durch MB ermöglichen"
|
||||
- "DPM liefert die strukturierte Grundlage, MB trifft die Allokationsentscheidungen"
|
||||
- "Objektivität sichern durch Trennung von Bewertung (DPM) und Entscheidung (DSR/MB)"
|
||||
|
||||
wie:
|
||||
routinen:
|
||||
- frequenz: "woechentlich"
|
||||
was: "DSR"
|
||||
|
||||
- frequenz: "quartalsweise"
|
||||
was: "Demand-Portfolio-Review"
|
||||
|
||||
reporting:
|
||||
an: "mb"
|
||||
format: "MB-Kurzpräsentation"
|
||||
inhalte:
|
||||
- "Demand-Portfolio-Entwicklung"
|
||||
- "Muster"
|
||||
- "Handlungsbedarfe"
|
||||
- "Empfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.2 KLASSIFIZIERUNG, ANALYSE, BEWERTUNG, PRIORISIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
bereich_2_qualifizierung:
|
||||
id: "VB2"
|
||||
name: "Demand-Klassifizierung, Analyse, Bewertung und Priorisierung"
|
||||
|
||||
was:
|
||||
- "Klassifizierung nach vordefinierten Dimensionen"
|
||||
- "Unzureichend qualifizierte Demands zurückweisen"
|
||||
- "Dubletten konsolidieren"
|
||||
- "Fachexpert:innen einbeziehen"
|
||||
- "Anwendung von Kategorien & Bewertungskriterien"
|
||||
- "Nutzung Bedarfs-Steckbrief und Demand-Entscheidungsvorlage"
|
||||
|
||||
warum:
|
||||
- "Klaren Prozess und Verfahren gegenüber Stakeholder sicherstellen"
|
||||
- "Entscheidungsfähigkeit herstellen und Vergleichbarkeit sichern"
|
||||
|
||||
wie:
|
||||
methodik:
|
||||
beschreibung: "Standardisierte Klassifizierung/Bewertung/Priorisierung"
|
||||
referenz: "DPM-Framework"
|
||||
|
||||
interaktion:
|
||||
- mit: "shm"
|
||||
was: "Rückfragen/Nachforderungen"
|
||||
|
||||
- mit: ["spm", "ppm", "ita"]
|
||||
was: "Abstimmung bei Service-, Projekt- oder Technikfragen"
|
||||
|
||||
dokumentation:
|
||||
- "Laufende Statuspflege im Ticketsystem"
|
||||
- "Statuspflege in weiteren genutzten Tools im Demand-Portfolio"
|
||||
- "Portfolio-Abgleich"
|
||||
|
||||
# ----------------------------------
|
||||
# 3.3 GREMIENARBEIT
|
||||
# ----------------------------------
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
id: "VB3"
|
||||
name: "Gremienarbeit"
|
||||
|
||||
was:
|
||||
- "DSR vorbereiten, in der Sitzung präsentieren, Beschlüsse dokumentieren"
|
||||
- "MB-Vorstellung MB-relevanter Demands"
|
||||
- "Nachbearbeitung und Umsetzungsvorbereitung gemäß Beschlüssen"
|
||||
|
||||
warum:
|
||||
- "Klare, effiziente Entscheidungen im Konsent-Verfahren"
|
||||
- "Eskalationsfähigkeit zum MB bei Uneinigkeit oder Kompetenzüberschreitung"
|
||||
|
||||
wie:
|
||||
rhythmus_rolle:
|
||||
- frequenz: "woechentlich"
|
||||
gremium: "dsr"
|
||||
|
||||
- frequenz: "ad_hoc"
|
||||
was: "Sondersitzungen auf Antrag"
|
||||
|
||||
arbeitsweise:
|
||||
- "Standard-Agenda"
|
||||
- "Unterlagen vorab"
|
||||
- "Confluence-Ablage"
|
||||
- "Unmittelbare Ergebnis-Kommunikation"
|
||||
|
||||
outputs:
|
||||
- "Beschlussprotokolle"
|
||||
- "Aktualisierte Demand-Portfolio-/Ticket-Einträge"
|
||||
- "Übergabe an PPM bei Freigabe"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
beschreibung: "Input/Output/Typische Abstimmungswege"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.1 INPUTS
|
||||
# ----------------------------------
|
||||
|
||||
inputs:
|
||||
beschreibung: "Was das DPM empfängt"
|
||||
|
||||
quellen:
|
||||
- von: "vision_board"
|
||||
inhalt: "Strategische Leitplanken und Top-down-Vorgaben, die den Priorisierungsrahmen für Demands setzen"
|
||||
|
||||
- von: "mission_board"
|
||||
inhalt: "Beschlüsse und Prioritäten für MB-relevante Demands; Rückfragen oder Arbeitsaufträge an DPM bei Vertagung/Delegation"
|
||||
|
||||
- von: "shm"
|
||||
inhalt: "Übergabe vorqualifizierter Demands inkl. Bedarfs-Steckbrief; Nachlieferungen bei Rückfragen; Statuswechsel 'an DPM übergeben' mit SHM-Einschätzung"
|
||||
|
||||
- von: "spm"
|
||||
inhalt: "Input zu Service-Fit und -Konsequenzen; Abstimmung, wenn direkte Service-Umsetzung möglich oder Service-Impact zu prüfen ist"
|
||||
|
||||
- von: "ppm"
|
||||
inhalt: "Informationen zu laufenden/geplanten Projekten zur Überschneidungsprüfung; Abgleich bei potenziellen Projekt-Kollisionen"
|
||||
|
||||
- von: "ita"
|
||||
inhalt: "Strategische/technische Grundsatz-Inputs zur Machbarkeit und Architekturrahmen"
|
||||
|
||||
- von: "fachexpertinnen"
|
||||
inhalt: "Punktuelle Expertise für Bewertung/Qualifizierung (fachlich/technisch)"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.2 OUTPUTS
|
||||
# ----------------------------------
|
||||
|
||||
outputs:
|
||||
beschreibung: "Was das DPM weitergibt"
|
||||
|
||||
ziele:
|
||||
- an: "dsr"
|
||||
inhalt: "Standardisierte Entscheidungsvorlage je Demand (Klassifizierung, Optionen, Empfehlung, Auswirkungen, Risiken), Vorstellung in der Sitzung, Beschluss-/Aufgabenüberführung"
|
||||
|
||||
- an: "mb"
|
||||
inhalt: "Entscheidungsvorlage für MB-relevante Demands inkl. Priorisierungsempfehlung, strategischer Fit, Ressourcen-/Portfolio-Auswirkungen, Alternativen; Kurzbericht Entscheidung/Nachverfolgung"
|
||||
|
||||
- an: "shm"
|
||||
inhalt: "Rückmeldung zum Bewertungsergebnis (z.B. Nachlieferung benötigt, Konsolidierung mit ähnlichen Demands, Routing in DSR/MB, Ablehnungs-/Delegationsbegründung); aktualisierte Steckbrief-Anforderungen"
|
||||
|
||||
- an: "spm"
|
||||
inhalt: "Klärungsanfragen zu Service-Fit/-Impact, dokumentierte Ergebnisse für Entscheidungsvorlage; Hinweise auf Servicekatalog-Anpassungen"
|
||||
|
||||
- an: "ppm"
|
||||
inhalt: "Übergabe freigegebener Demands in die Projektpipeline inkl. Beschlussreferenz, Priorität, Abhängigkeiten, initialer Projektsteckbrief/Startkonditionen"
|
||||
|
||||
- an: ["ita", "fachexpertinnen"]
|
||||
inhalt: "Gezielte Architektur-/Fachabfragen zur Entscheidungsreife; zusammengefasste Einschätzungen für die Vorlage (Machbarkeit, Standards, Risiken)"
|
||||
|
||||
- an: "al_p"
|
||||
inhalt: "Quartalsweiser Demand-Portfolio-Report: KPI-Dashboard, Muster/Trends, Handlungs-/Priorisierungsempfehlungen"
|
||||
|
||||
# ----------------------------------
|
||||
# 4.3 TYPISCHE ABSTIMMUNGSWEGE
|
||||
# ----------------------------------
|
||||
|
||||
typische_abstimmungswege:
|
||||
beschreibung: "Standardisierte Interaktionsformate"
|
||||
|
||||
formate:
|
||||
- format: "dsr_regulaer"
|
||||
name: "DSR – Regulär"
|
||||
frequenz: "woechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Vorstellung der Entscheidungsvorlagen durch DPM"
|
||||
- "Gemeinsame Bewertung/Klassifizierung"
|
||||
- "Beschluss (Freigabe, Ablehnung, Zurückstellung, Delegation ans MB)"
|
||||
- "Protokoll und Ticket-Update"
|
||||
|
||||
- format: "sonder_dsr"
|
||||
name: "Sonder-DSR"
|
||||
frequenz: "ad_hoc"
|
||||
|
||||
inhalt:
|
||||
- "Kurzfristige Klärung dringlicher Themen oder Konflikte"
|
||||
- "Einberufung auf Anfrage eines DSR-Mitglieds"
|
||||
- "Entscheidung über Einberufung liegt beim DPM"
|
||||
- "Eskalationsweg bei Bedarf"
|
||||
|
||||
- format: "mission_board"
|
||||
name: "Mission Board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
|
||||
inhalt:
|
||||
- "Finale Entscheidung zu MB-relevanten Demands"
|
||||
- "Priorisierung/Ressourcen"
|
||||
- "DPM liefert MB-Vorlage"
|
||||
- "PPM/SHM übernehmen Folgekommunikation und Statusupdates"
|
||||
|
||||
- format: "shm_dpm_klaerung"
|
||||
name: "SHM ↔ DPM – Klärungsschleifen"
|
||||
frequenz: "laufend"
|
||||
|
||||
inhalt:
|
||||
- "Nachforderungen bei unvollständigen Demands"
|
||||
- "Persönliche Kurzabstimmungen/E-Mail"
|
||||
- "SHM aktualisiert Steckbrief/Ticket"
|
||||
|
||||
- format: "dpm_spm_service"
|
||||
name: "DPM ↔ SPM – Service-Fit/Impact"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Abgleich Service-Bezug"
|
||||
- "Direkte Umsetzung kleiner Demands mit SPM/Service Manager"
|
||||
- "Ergebnissicherung für die Entscheidungsvorlage"
|
||||
|
||||
- format: "dpm_ppm_projekt"
|
||||
name: "DPM ↔ PPM – Projekt-Abgleich/Übergabe"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
inhalt:
|
||||
- "Prüfen von Überschneidungen mit laufenden/geplanten Projekten"
|
||||
- "Übergabe freigegebener Demands in die Projektpipeline"
|
||||
- "Status-Reporting zurück an DSR/MB"
|
||||
|
||||
- format: "dpm_ita_grundsatz"
|
||||
name: "DPM ↔ IT-Architektur-Board"
|
||||
frequenz: "bei_grundsatzfragen"
|
||||
|
||||
inhalt:
|
||||
- "Technische Leitplanken/Machbarkeit klären"
|
||||
- "Kurzlage/Fragestellung aus DSR/DPM"
|
||||
|
||||
- format: "portfolio_review"
|
||||
name: "Demand-Portfolio-Review"
|
||||
frequenz: "quartalsweise"
|
||||
|
||||
inhalt:
|
||||
- "Muster-/Trendanalysen"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
verwandte_dokumente:
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch"
|
||||
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen für DPM-Funktion"
|
||||
|
||||
- titel: "RACI-Matrix DPM"
|
||||
pfad: "#01.2_governance/raci-matrix-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten über Phasen hinweg"
|
||||
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Methodischer Kern der DPM-Funktion"
|
||||
|
|
@ -0,0 +1,329 @@
|
|||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "komplexitaet"
|
||||
titel: "Klassifizierungsmatrix Komplexität"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "komplexitaet"
|
||||
- "loesungsunsicherheit"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands.
|
||||
Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell
|
||||
und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert
|
||||
zu bewerten.
|
||||
|
||||
grundverstaendnis: |
|
||||
Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit,
|
||||
sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch
|
||||
einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen
|
||||
Interessen involviert sind.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
bewertungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: STAKEHOLDER & KOORDINATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_stakeholder_koordination:
|
||||
id: "stakeholder_koordination"
|
||||
name: "Stakeholder & Koordination"
|
||||
leitfrage: "Wie viele Akteure müssen koordiniert werden?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "beteiligte_teams"
|
||||
name: "Beteiligte Teams"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Teams"
|
||||
komplex: "3-4 Teams"
|
||||
hochkomplex: "5+ Teams"
|
||||
|
||||
- kriterium_id: "stakeholder_gruppen"
|
||||
name: "Stakeholder-Gruppen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Gruppen"
|
||||
komplex: "3-5 Gruppen"
|
||||
hochkomplex: "6+ Gruppen"
|
||||
|
||||
- kriterium_id: "entscheidungsebene"
|
||||
name: "Entscheidungsebene"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Arbeitsebene"
|
||||
komplex: "Abteilungsleitung"
|
||||
hochkomplex: "Amtsleitung/Politik"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_loesungsraum_unsicherheit:
|
||||
id: "loesungsraum_unsicherheit"
|
||||
name: "Lösungsraum & Unsicherheit"
|
||||
leitfrage: "Wie klar ist der Weg zur Lösung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "loesungsklarheit"
|
||||
name: "Lösungsklarheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Eindeutige Lösung"
|
||||
komplex: "2-3 Optionen"
|
||||
hochkomplex: "Unklar/Exploration nötig"
|
||||
|
||||
- kriterium_id: "technologie_reife"
|
||||
name: "Technologie-Reife"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Bewährt im DIGIT"
|
||||
komplex: "Neu für DIGIT"
|
||||
hochkomplex: "Innovativ/Experimentell"
|
||||
|
||||
- kriterium_id: "anforderungsstabilitaet"
|
||||
name: "Anforderungsstabilität"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Stabil & klar"
|
||||
komplex: "Teilweise unklar"
|
||||
hochkomplex: "Volatil/Undefiniert"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_abhaengigkeiten_integration:
|
||||
id: "abhaengigkeiten_integration"
|
||||
name: "Abhängigkeiten & Integration"
|
||||
leitfrage: "Wie vernetzt ist der Demand?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "externe_partner"
|
||||
name: "Externe Partner"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "1-2 Partner"
|
||||
hochkomplex: "3+ Partner"
|
||||
|
||||
- kriterium_id: "system_schnittstellen"
|
||||
name: "System-Schnittstellen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Systeme"
|
||||
komplex: "3-4 Systeme"
|
||||
hochkomplex: "5+ Systeme"
|
||||
|
||||
- kriterium_id: "zeitliche_abhaengigkeiten"
|
||||
name: "Zeitliche Abhängigkeiten"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Flexibel planbar"
|
||||
komplex: "Teilweise gebunden"
|
||||
hochkomplex: "Kritische Verkettung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: RISIKEN & UNWÄGBARKEITEN
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_risiken_unwaegbarkeiten:
|
||||
id: "risiken_unwaegbarkeiten"
|
||||
name: "Risiken & Unwägbarkeiten"
|
||||
leitfrage: "Wie beherrschbar sind die Risiken?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "budget_unsicherheit"
|
||||
name: "Budget-Unsicherheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Verlässlich planbar"
|
||||
komplex: "Bandbreiten-Schätzung"
|
||||
hochkomplex: "Unkalkulierbar"
|
||||
|
||||
- kriterium_id: "termin_risiko"
|
||||
name: "Termin-Risiko"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Gering"
|
||||
komplex: "Mittel"
|
||||
hochkomplex: "Hoch/Unklar"
|
||||
|
||||
- kriterium_id: "compliance_risiken"
|
||||
name: "Compliance-Risiken"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "Handhabbar"
|
||||
hochkomplex: "Kritisch/Unklar"
|
||||
|
||||
# ========================================
|
||||
# SIGNALE FÜR HOCHKOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
signale_hochkomplexitaet:
|
||||
beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten"
|
||||
|
||||
signale:
|
||||
- id: "paradoxe_anforderungen"
|
||||
signal: "Paradoxe Anforderungen"
|
||||
beispiel: "\"Soll alles können, darf nichts kosten\""
|
||||
interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
- id: "moving_targets"
|
||||
signal: "Moving Targets"
|
||||
beschreibung: "Anforderungen ändern sich während der Analyse"
|
||||
interpretation: "Instabile Ausgangslage, hohe Unsicherheit"
|
||||
|
||||
- id: "interessenskomplexitaet"
|
||||
signal: "Interessenskomplexität"
|
||||
beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen"
|
||||
interpretation: "Verdeckte Agenden, schwierige Konsensfindung"
|
||||
|
||||
- id: "regulatorische_grauzonen"
|
||||
signal: "Regulatorische Grauzonen"
|
||||
beschreibung: "Rechtslage unklar oder im Wandel"
|
||||
interpretation: "Compliance-Risiko, Neuorientierung erforderlich"
|
||||
|
||||
- id: "praezedenzfall"
|
||||
signal: "Präzedenzfall"
|
||||
beschreibung: "Erstmalige Herausforderung ohne Referenz"
|
||||
interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungsverfahren:
|
||||
beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung"
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Dimension-Scoring"
|
||||
beschreibung: "Jede der vier Dimensionen separat bewerten"
|
||||
output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Komplexitäts-Aggregation"
|
||||
beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen"
|
||||
logik: "siehe aggregationslogik unten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Kontextuelle Anpassung"
|
||||
beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren"
|
||||
|
||||
aggregationslogik:
|
||||
titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\""
|
||||
|
||||
regeln:
|
||||
- bedingung: "1 Dimension = \"Hochkomplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Ein hochkomplexer Aspekt dominiert"
|
||||
|
||||
- bedingung: "3 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Kumulative Komplexität führt zu Hochkomplexität"
|
||||
|
||||
- bedingung: "2 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Komplex"
|
||||
rationale: "Moderate kumulative Komplexität"
|
||||
|
||||
- bedingung: "ansonsten"
|
||||
ergebnis: "Moderat"
|
||||
rationale: "Überschaubare Komplexität"
|
||||
|
||||
# ========================================
|
||||
# KONSEQUENZEN DER BEWERTUNG
|
||||
# ========================================
|
||||
|
||||
konsequenzen:
|
||||
- komplexitaet: "moderat"
|
||||
konsequenz: "Direkte Umsetzung"
|
||||
typische_massnahmen:
|
||||
- "Standardprozess"
|
||||
- "Keine Sonderanalysen"
|
||||
|
||||
- komplexitaet: "komplex"
|
||||
konsequenz: "Strukturierte Analyse"
|
||||
typische_massnahmen:
|
||||
- "Vorprojekt empfohlen"
|
||||
- "Experteneinbindung"
|
||||
- "Risikomanagement"
|
||||
|
||||
- komplexitaet: "hochkomplex"
|
||||
konsequenz: "Sondierung zwingend"
|
||||
typische_massnahmen:
|
||||
- "Machbarkeitsstudie"
|
||||
- "Pilot/PoC"
|
||||
- "Steering Committee"
|
||||
|
||||
# ========================================
|
||||
# UMGANG MIT KOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
umgang_mit_komplexitaet:
|
||||
bei_hochkomplexitaet:
|
||||
massnahmen:
|
||||
- id: "M1"
|
||||
name: "Komplexitätsreduktion prüfen"
|
||||
frage: "Kann der Demand geteilt werden?"
|
||||
ziel: "Reduzierung auf handhabbare Teilprobleme"
|
||||
|
||||
- id: "M2"
|
||||
name: "Sondierung priorisieren"
|
||||
prinzip: "Keine vorschnellen Lösungsversprechen"
|
||||
ziel: "Exploration vor Commitment"
|
||||
|
||||
- id: "M3"
|
||||
name: "Stakeholder-Zielausrichtung"
|
||||
aktivitaet: "Frühzeitige Erwartungsklärung"
|
||||
ziel: "Konvergenz der Interessen"
|
||||
|
||||
- id: "M4"
|
||||
name: "Iteratives Vorgehen"
|
||||
prinzip: "Schritt-für-Schritt statt \"Big Bang\""
|
||||
ziel: "Schrittweise Komplexitätsreduktion"
|
||||
|
||||
komplexitaetsfallen_vermeiden:
|
||||
beschreibung: "Typische Denkfehler im Umgang mit Komplexität"
|
||||
|
||||
fallen:
|
||||
- falle: "Schein-Einfachheit"
|
||||
beispiel: "\"Wir brauchen nur Tool X\""
|
||||
gegenmassnahme: "Immer nach dem \"Warum\" fragen"
|
||||
|
||||
- falle: "Komplexitäts-Paralysis"
|
||||
beschreibung: "Nicht alles Komplexe ist unlösbar"
|
||||
gegenmassnahme: "Handlungsfähigkeit bewahren"
|
||||
|
||||
- falle: "Oversimplification"
|
||||
beschreibung: "Komplexität nicht wegdefinieren"
|
||||
gegenmassnahme: "Realistische Einschätzung"
|
||||
|
||||
- falle: "Analysis-Paralysis"
|
||||
beschreibung: "Irgendwann muss entschieden werden"
|
||||
gegenmassnahme: "Entscheidungszeitpunkt definieren"
|
||||
|
|
@ -0,0 +1,295 @@
|
|||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "tragweite"
|
||||
titel: "Klassifizierungsmatrix Tragweite"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "tragweite"
|
||||
- "veraenderungstiefe"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix dient der detaillierten Einordnung von Demands in die
|
||||
Dimension "Tragweite". Sie erweitert die Grunddefinitionen aus dem
|
||||
Klassifizierungsmodell um konkrete Bewertungskriterien und unterstützt DPMs
|
||||
bei der Einschätzung der Veränderungstiefe.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSPERSPEKTIVEN
|
||||
# ========================================
|
||||
|
||||
bewertungsperspektiven:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier komplementäre Perspektiven zur Bewertung der Tragweite"
|
||||
prinzip: "Dominanz-Prinzip: Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 1: NUTZER:INNEN
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_1_nutzerinnen:
|
||||
id: "nutzerinnen"
|
||||
name: "Nutzer:innen-Perspektive"
|
||||
leitfrage: "Wie stark verändert sich die Arbeitsweise der Endanwender:innen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "schulungsbedarf"
|
||||
name: "Schulungsbedarf"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Schulungen nötig"
|
||||
ausbau: "Punktuelle Schulungen"
|
||||
neugestaltung: "Flächendeckende Schulungen"
|
||||
|
||||
- kriterium_id: "verhaltensaenderung"
|
||||
name: "Verhaltensänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Minimale Anpassung"
|
||||
ausbau: "Neue Funktionen lernen"
|
||||
neugestaltung: "Neue Arbeitsweisen"
|
||||
|
||||
- kriterium_id: "nutzer_impact"
|
||||
name: "Nutzer-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% merken Veränderung"
|
||||
ausbau: "20-70% betroffen"
|
||||
neugestaltung: "> 70% der Nutzer betroffen"
|
||||
|
||||
- kriterium_id: "rueckfallmoeglichkeit"
|
||||
name: "Rückfallmöglichkeit"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Jederzeit möglich"
|
||||
ausbau: "Mit Aufwand möglich"
|
||||
neugestaltung: "Nicht mehr möglich"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 2: TECHNISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_2_technisch:
|
||||
id: "technisch"
|
||||
name: "Technische Perspektive"
|
||||
leitfrage: "Wie tiefgreifend sind die technischen Veränderungen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "betroffenheit_anwendungen"
|
||||
name: "Betroffenheit von Anwendungen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 20% Anwendungen betroffen"
|
||||
ausbau: "20-70% Anwendungen betroffen"
|
||||
neugestaltung: "> 70% Anwendungen betroffen"
|
||||
|
||||
- kriterium_id: "systemgrenzen"
|
||||
name: "Systemgrenzen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Innerhalb eines Systems"
|
||||
ausbau: "Systemübergreifend"
|
||||
neugestaltung: "Systemlandschaft-Umbau"
|
||||
|
||||
- kriterium_id: "technologie_stack"
|
||||
name: "Technologie-Stack"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Bestehende Technologien"
|
||||
ausbau: "Ergänzung neuer Technologie"
|
||||
neugestaltung: "Technologiewechsel"
|
||||
|
||||
- kriterium_id: "datenmigration"
|
||||
name: "Datenmigration"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine erforderlich"
|
||||
ausbau: "Teilmigration"
|
||||
neugestaltung: "Vollmigration"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 3: ORGANISATORISCH
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_3_organisatorisch:
|
||||
id: "organisatorisch"
|
||||
name: "Organisatorische Perspektive"
|
||||
leitfrage: "Wie stark verändern sich Prozesse und Strukturen?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "prozessaenderung"
|
||||
name: "Prozessänderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Optimierung im Detail"
|
||||
ausbau: "Prozesserweiterung"
|
||||
neugestaltung: "Prozess-Neudesign"
|
||||
|
||||
- kriterium_id: "rollenveraenderung"
|
||||
name: "Rollenveränderung"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine"
|
||||
ausbau: "Neue/veränderte Aufgaben"
|
||||
neugestaltung: "Neue Rollen/Stellen"
|
||||
|
||||
- kriterium_id: "aemter_uebergreifend"
|
||||
name: "Ämter-übergreifend"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Ein Amt"
|
||||
ausbau: "2-3 Ämter"
|
||||
neugestaltung: "Gesamtorganisation"
|
||||
|
||||
- kriterium_id: "abteilungs_uebergreifend_digit"
|
||||
name: "Abteilungs-übergreifend (DIGIT)"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Eine Abteilung"
|
||||
ausbau: "2-3 Abteilungen"
|
||||
neugestaltung: "Gesamt-DIGIT"
|
||||
|
||||
- kriterium_id: "governance_impact"
|
||||
name: "Governance-Impact"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Keine Änderung"
|
||||
ausbau: "Anpassung nötig"
|
||||
neugestaltung: "Neue Governance"
|
||||
|
||||
# ----------------------------------
|
||||
# PERSPEKTIVE 4: FINANZIELL
|
||||
# ----------------------------------
|
||||
|
||||
perspektive_4_finanziell:
|
||||
id: "finanziell"
|
||||
name: "Finanzielle Perspektive"
|
||||
leitfrage: "Welche finanziellen Auswirkungen hat die Veränderung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "investitionsvolumen_extern"
|
||||
name: "Externes Investitionsvolumen"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "< 50.000 €"
|
||||
ausbau: "50.000 - 200.000 €"
|
||||
neugestaltung: "> 200.000 €"
|
||||
|
||||
- kriterium_id: "folgekosten"
|
||||
name: "Folgekosten"
|
||||
|
||||
auspraegungen:
|
||||
optimierung: "Marginal"
|
||||
ausbau: "Moderat"
|
||||
neugestaltung: "Erheblich"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungslogik:
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Perspektiven-Bewertung"
|
||||
beschreibung: "Jede der vier Perspektiven wird separat bewertet"
|
||||
output: "4 Einzelbewertungen (Optimierung/Ausbau/Neugestaltung)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Dominanz-Prinzip"
|
||||
beschreibung: "Die höchste Einstufung einer Perspektive bestimmt die Gesamt-Tragweite"
|
||||
rationale: "Ein transformativer Aspekt reicht, um den gesamten Demand als transformativ einzustufen"
|
||||
|
||||
- schritt: 3
|
||||
name: "Begründungspflicht"
|
||||
beschreibung: "Bei Abweichungen zwischen Perspektiven ist eine explizite Begründung erforderlich"
|
||||
ziel: "Nachvollziehbarkeit und Lerneffekte"
|
||||
|
||||
# ========================================
|
||||
# GRENZFÄLLE UND INTERPRETATIONSHILFEN
|
||||
# ========================================
|
||||
|
||||
grenzfaelle:
|
||||
typische_indikatoren_neugestaltung:
|
||||
beschreibung: "Signale für transformative/neugestaltende Demands"
|
||||
|
||||
indikatoren:
|
||||
- "Ablösung von Altsystemen"
|
||||
- "Gesetzlich getriebene Paradigmenwechsel"
|
||||
- "Einführung völlig neuer Geschäftsmodelle"
|
||||
- "Fundamentale Änderung der Nutzer:innen-Interaktion"
|
||||
|
||||
abgrenzung_optimierung_vs_ausbau:
|
||||
optimierung_inkrementell:
|
||||
beschreibung: "Verbesserung des Bestehenden ohne neue Konzepte"
|
||||
beispiele:
|
||||
- "UI-Verbesserungen"
|
||||
- "Performance-Optimierung"
|
||||
- "Bugfixes"
|
||||
|
||||
ausbau_evolutionaer:
|
||||
beschreibung: "Hinzufügen neuer Fähigkeiten zum bestehenden System"
|
||||
beispiele:
|
||||
- "Neue Module"
|
||||
- "API-Erweiterungen"
|
||||
- "Prozessdigitalisierung"
|
||||
|
||||
umgang_mit_unsicherheit:
|
||||
beschreibung: "Vorgehen bei unklarer Einordnung"
|
||||
|
||||
massnahmen:
|
||||
- schritt: 1
|
||||
name: "Workshop mit betroffenen Stakeholdern"
|
||||
ziel: "Verschiedene Perspektiven integrieren"
|
||||
|
||||
- schritt: 2
|
||||
name: "Pilot-Phase zur Validierung der Tragweite"
|
||||
ziel: "Empirische Klärung"
|
||||
|
||||
- schritt: 3
|
||||
name: "Vorsichtsprinzip"
|
||||
regel: "Im Zweifel: Höhere Kategorie wählen"
|
||||
rationale: "Unterschätzung vermeiden"
|
||||
|
||||
# ========================================
|
||||
# DOKUMENTATIONSANFORDERUNG
|
||||
# ========================================
|
||||
|
||||
dokumentationsstandard:
|
||||
template:
|
||||
struktur: |
|
||||
TRAGWEITEN-ANALYSE
|
||||
|
||||
Nutzer:innen: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Technisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Organisatorisch: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
Finanziell: [Ausprägung]
|
||||
Begründung: [Kurz und prägnant]
|
||||
|
||||
GESAMTTRAGWEITE: [Kategorie]
|
||||
|
||||
BEGRÜNDUNG: [Warum diese Einordnung, insb. bei Divergenz]
|
||||
|
||||
hinweis: "Bei divergierenden Perspektiven muss erklärt werden, warum eine Perspektive dominiert"
|
||||
|
|
@ -0,0 +1,668 @@
|
|||
meta:
|
||||
typ: "raci_matrix"
|
||||
scope: "Demand-Portfolio-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
kontext_tags:
|
||||
- "verantwortlichkeiten"
|
||||
- "raci"
|
||||
- "demand-lifecycle"
|
||||
- "governance"
|
||||
- "prozess"
|
||||
|
||||
# ========================================
|
||||
# GOVERNANCE-PRINZIPIEN
|
||||
# ========================================
|
||||
|
||||
governance_prinzipien:
|
||||
beschreibung: "Differenzierter Ansatz, der Agilität mit notwendiger Governance-Kontrolle balanciert"
|
||||
|
||||
prinzipien:
|
||||
- id: "GP1"
|
||||
name: "Fachexpertise = Verantwortung"
|
||||
regel: "A/R zusammen"
|
||||
beschreibung: "Wo Fachkompetenz entscheidend ist, liegen Ausführung und Verantwortung in einer Hand"
|
||||
begruendung: "Empowerment der Experten, schnelle Entscheidungen, klare Ownership"
|
||||
|
||||
- id: "GP2"
|
||||
name: "Governance-Gates"
|
||||
regel: "A≠R getrennt"
|
||||
beschreibung: "Bei Kontrollpunkten und Gremienentscheidungen wird bewusst getrennt"
|
||||
begruendung: "Vier-Augen-Prinzip, Checks & Balances, Verwaltungssicherheit"
|
||||
|
||||
- id: "GP3"
|
||||
name: "Klare Übergänge"
|
||||
regel: "A≠R an Schnittstellen"
|
||||
beschreibung: "Bei Phasenübergängen erfolgt explizite Verantwortungsübergabe"
|
||||
begruendung: "Eindeutige Verantwortungswechsel, Vermeidung von Lücken"
|
||||
|
||||
# ========================================
|
||||
# RACI-LEGENDE
|
||||
# ========================================
|
||||
|
||||
raci_legende:
|
||||
R:
|
||||
name: "Responsible"
|
||||
beschreibung: "Führt die Aktivität aus, ist operativ verantwortlich"
|
||||
|
||||
A:
|
||||
name: "Accountable"
|
||||
beschreibung: "Hat die finale Verantwortung und Entscheidungsbefugnis"
|
||||
|
||||
C:
|
||||
name: "Consulted"
|
||||
beschreibung: "Wird vor der Entscheidung konsultiert, gibt fachlichen Input"
|
||||
|
||||
I:
|
||||
name: "Informed"
|
||||
beschreibung: "Wird über das Ergebnis informiert"
|
||||
|
||||
# ========================================
|
||||
# ROLLEN
|
||||
# ========================================
|
||||
|
||||
rollen:
|
||||
- rolle_id: "sh"
|
||||
rolle_name: "Stakeholder"
|
||||
fokus: "Bedarfsträger"
|
||||
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
fokus: "Bedarfserfassung und Stakeholder-Kommunikation"
|
||||
|
||||
- rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Management"
|
||||
fokus: "Qualifizierung, Bewertung, Priorisierung"
|
||||
|
||||
- rolle_id: "dsr"
|
||||
rolle_name: "Demand & Stakeholder Runde"
|
||||
fokus: "Entscheidungsinstanz für DSR-Demands (nach Demand-Klassifizierung)"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- rolle_id: "mb"
|
||||
rolle_name: "Mission Board"
|
||||
fokus: "Entscheidungsinstanz für MB-Demands (nach Demand-Klassifizierung)"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
fokus: "Service-Impact und Sponsoring"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
fokus: "Projektinitiierung und -steuerung"
|
||||
|
||||
- rolle_id: "al_p"
|
||||
rolle_name: "Abteilungsleitung Planung"
|
||||
fokus: "Quartals-Reviews und DPM-Führung"
|
||||
|
||||
- rolle_id: "pzm"
|
||||
rolle_name: "Prozess-Management"
|
||||
fokus: "Methodische Governance und Quality Gates"
|
||||
|
||||
- rolle_id: "ita"
|
||||
rolle_name: "IT-Architektur-Board"
|
||||
fokus: "Technische Bewertung"
|
||||
|
||||
- rolle_id: "vb"
|
||||
rolle_name: "Vision Board"
|
||||
fokus: "Strategische Governance"
|
||||
|
||||
- rolle_id: "pl"
|
||||
rolle_name: "Projektleitung"
|
||||
fokus: "Projektdurchführung"
|
||||
|
||||
# ========================================
|
||||
# RACI-ZUORDNUNGEN NACH PHASEN
|
||||
# ========================================
|
||||
|
||||
raci_matrix:
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 1: INITIIERUNG UND ERFASSUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_1_initiierung:
|
||||
phase_id: "phase_1"
|
||||
phase_name: "Initiierung und Erfassung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "1.1"
|
||||
name: "Bedarfsidentifikation"
|
||||
zuordnung:
|
||||
sh: "A/R"
|
||||
shm: "I"
|
||||
|
||||
- aktivitaet_id: "1.2"
|
||||
name: "Bedarfsmeldung"
|
||||
zuordnung:
|
||||
sh: "R"
|
||||
shm: "A"
|
||||
dpm: "I"
|
||||
|
||||
- aktivitaet_id: "1.3"
|
||||
name: "Initiale Qualifizierung"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "A/R"
|
||||
|
||||
- aktivitaet_id: "1.4"
|
||||
name: "Service-Katalog-Prüfung"
|
||||
zuordnung:
|
||||
shm: "A/R"
|
||||
spm: "C"
|
||||
|
||||
- aktivitaet_id: "1.5"
|
||||
name: "Bedarfsklärungsgespräch (optional)"
|
||||
zuordnung:
|
||||
sh: "R"
|
||||
shm: "A/R"
|
||||
|
||||
- aktivitaet_id: "1.6"
|
||||
name: "User Story Erstellung"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "A/R"
|
||||
dpm: "C"
|
||||
|
||||
- aktivitaet_id: "1.7"
|
||||
name: "Demand-Übergabe"
|
||||
beschreibung: "Quality Gate 1: Übergabe von SHM an DPM"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "R"
|
||||
dpm: "A"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 2: QUALIFIZIERUNG UND PRIORISIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_2_qualifizierung:
|
||||
phase_id: "phase_2"
|
||||
phase_name: "Qualifizierung und Priorisierung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "2.1"
|
||||
name: "Vollständigkeitsprüfung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
|
||||
- aktivitaet_id: "2.2"
|
||||
name: "Demand-Klassifizierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
ita: "C"
|
||||
|
||||
- aktivitaet_id: "2.3"
|
||||
name: "Demand-Analyse"
|
||||
zuordnung:
|
||||
dpm: "A/R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
ita: "C"
|
||||
|
||||
- aktivitaet_id: "2.4"
|
||||
name: "Demand-Bewertung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "2.5"
|
||||
name: "Demand-Priorisierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "2.6"
|
||||
name: "Entscheidungsvorlage erstellen"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 3: ENTSCHEIDUNG UND FREIGABE
|
||||
# ----------------------------------
|
||||
|
||||
phase_3_entscheidung:
|
||||
phase_id: "phase_3"
|
||||
phase_name: "Entscheidung und Freigabe"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "3.1"
|
||||
name: "DSR-Vorbereitung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.2"
|
||||
name: "DSR-Präsentation"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.3"
|
||||
name: "DSR-Entscheidung (DSR-Demand)"
|
||||
beschreibung: "Entscheidung über DSR-Demands"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "C"
|
||||
dpm: "R/C"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
hinweis: "DPM ist Teil der DSR-Entscheidung (C) und dokumentiert (R)"
|
||||
|
||||
- aktivitaet_id: "3.4"
|
||||
name: "MB-Delegation"
|
||||
beschreibung: "Delegation eines Demands von DSR ans Mission Board"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R/C"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
hinweis: "DPM ist Teil der Entscheidung und dann verantwortlich, den delegierten Demand ins MB einzubringen"
|
||||
|
||||
- aktivitaet_id: "3.5"
|
||||
name: "MB-Vorbereitung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.6"
|
||||
name: "MB-Präsentation"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.7"
|
||||
name: "MB-Entscheidung (MB-Demand)"
|
||||
beschreibung: "Finale Entscheidung des Mission Board über MB-Demands"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "I"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
|
||||
- aktivitaet_id: "3.8"
|
||||
name: "Auflagen-Definition"
|
||||
beschreibung: "Definition von Auflagen bei bedingter Freigabe"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
hinweis: "DSR für DSR-Demands, MB für MB-Demands"
|
||||
|
||||
- aktivitaet_id: "3.9"
|
||||
name: "Sponsor-Benennung (DSR-Demand)"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "A"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.10"
|
||||
name: "Sponsor-Benennung (MB-Demand)"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
mb: "A/R"
|
||||
spm: "I"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "3.11"
|
||||
name: "Kommunikation Entscheidung"
|
||||
beschreibung: "Kommunikation der Entscheidung an Stakeholder"
|
||||
zuordnung:
|
||||
sh: "I"
|
||||
shm: "A/R"
|
||||
dpm: "I"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 4: PROJEKTINITIIERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_4_projektinitiierung:
|
||||
phase_id: "phase_4"
|
||||
phase_name: "Projektinitiierung (Übergang)"
|
||||
beschreibung: "Übergang von Demand zu Projekt"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "4.1"
|
||||
name: "Projektauftrag erstellen (DSR-Demand)"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "4.2"
|
||||
name: "Projektleitung benennen"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
|
||||
- aktivitaet_id: "4.3"
|
||||
name: "Ressourcenmobilisierung"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "C"
|
||||
mb: "C"
|
||||
spm: "R"
|
||||
ppm: "C"
|
||||
hinweis: "DSR und MB werden nur bei Ressourcenkonflikten konsultiert"
|
||||
|
||||
- aktivitaet_id: "4.4"
|
||||
name: "Demand-Archivierung"
|
||||
beschreibung: "Demand wird als 'in Projekt überführt' archiviert"
|
||||
zuordnung:
|
||||
dpm: "A/R"
|
||||
ppm: "I"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 5: GOVERNANCE UND MONITORING
|
||||
# ----------------------------------
|
||||
|
||||
phase_5_governance:
|
||||
phase_id: "phase_5"
|
||||
phase_name: "Governance und Monitoring"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "5.1"
|
||||
name: "Auflagenerfüllung"
|
||||
beschreibung: "Überwachung der Erfüllung von Auflagen aus Freigabe"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
spm: "C"
|
||||
ppm: "A/R"
|
||||
|
||||
- aktivitaet_id: "5.2"
|
||||
name: "Projekt Status-Reporting an DSR"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "I"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "A/R"
|
||||
|
||||
- aktivitaet_id: "5.3"
|
||||
name: "Portfolio-Dashboard"
|
||||
beschreibung: "Pflege und Bereitstellung des Demand-Portfolio-Dashboards"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "A/R"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "C"
|
||||
|
||||
- aktivitaet_id: "5.4"
|
||||
name: "Quartals-Review"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
|
||||
- aktivitaet_id: "5.5"
|
||||
name: "MB-Review Berichterstattung"
|
||||
beschreibung: "Berichterstattung an Mission Board über Portfolio-Review"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
mb: "C"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "A"
|
||||
|
||||
- aktivitaet_id: "5.6"
|
||||
name: "Prozess-Compliance"
|
||||
beschreibung: "Sicherstellung der Einhaltung von Prozess-Standards"
|
||||
zuordnung:
|
||||
dpm: "R"
|
||||
al_p: "C"
|
||||
pzm: "A"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 6: ESKALATIONS- UND SONDERFÄLLE
|
||||
# ----------------------------------
|
||||
|
||||
phase_6_eskalation:
|
||||
phase_id: "phase_6"
|
||||
phase_name: "Eskalations- und Sonderfälle"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "6.1"
|
||||
name: "Sonder-DSR einberufen"
|
||||
zuordnung:
|
||||
shm: "R"
|
||||
dpm: "A/R"
|
||||
mb: "I"
|
||||
spm: "R"
|
||||
ppm: "R"
|
||||
hinweis: "Jedes DSR-Mitglied kann Sonder-DSR anfragen (R). DPM entscheidet über Einberufung (A/R)"
|
||||
|
||||
- aktivitaet_id: "6.2"
|
||||
name: "Fachliche Konflikte"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "(A)"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: DSR → MB → VB. (A) in Klammern zeigt Eskalationsinstanz"
|
||||
|
||||
- aktivitaet_id: "6.3"
|
||||
name: "Ressourcenkonflikte"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "A"
|
||||
mb: "(A)"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: DSR → MB → VB"
|
||||
|
||||
- aktivitaet_id: "6.4"
|
||||
name: "Strategische Konflikte"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "C"
|
||||
dsr: "R"
|
||||
mb: "A"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
vb: "(A)"
|
||||
hinweis: "Eskalation: MB → VB"
|
||||
|
||||
- aktivitaet_id: "6.5"
|
||||
name: "Methodische Konflikte"
|
||||
beschreibung: "Konflikte über Prozesse, Methoden, Standards"
|
||||
zuordnung:
|
||||
dpm: "R"
|
||||
al_p: "C"
|
||||
pzm: "A"
|
||||
|
||||
- aktivitaet_id: "6.6"
|
||||
name: "Unauflösbare Konflikte"
|
||||
beschreibung: "Konflikte, die auf lower Ebenen nicht lösbar sind"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "R"
|
||||
mb: "A"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "C"
|
||||
|
||||
eskalations_prozess:
|
||||
beschreibung: "Bei Konflikten gilt folgender Prozess"
|
||||
stufen:
|
||||
- stufe: 1
|
||||
name: "Versuch Lösung"
|
||||
beschreibung: "Verantwortliche Instanz (R) versucht Lösung"
|
||||
|
||||
- stufe: 2
|
||||
name: "Eskalation"
|
||||
beschreibung: "Ohne Klärung findet eine Eskalation an nächsthöhere Instanz"
|
||||
pfade:
|
||||
- von: "dsr"
|
||||
zu: "mb"
|
||||
- von: "mb"
|
||||
zu: "vb"
|
||||
|
||||
# ----------------------------------
|
||||
# PHASE 7: KONTINUIERLICHE VERBESSERUNG
|
||||
# ----------------------------------
|
||||
|
||||
phase_7_verbesserung:
|
||||
phase_id: "phase_7"
|
||||
phase_name: "Kontinuierliche Verbesserung"
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet_id: "7.1"
|
||||
name: "Prozess-Optimierung"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "C"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
|
||||
- aktivitaet_id: "7.2"
|
||||
name: "KPI-Definition"
|
||||
beschreibung: "Definition und Anpassung von Portfolio-KPIs"
|
||||
zuordnung:
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
vb: "I"
|
||||
|
||||
- aktivitaet_id: "7.3"
|
||||
name: "Lessons Learned"
|
||||
beschreibung: "Systematische Auswertung von Erfahrungen"
|
||||
zuordnung:
|
||||
sh: "C"
|
||||
shm: "C"
|
||||
dpm: "R"
|
||||
dsr: "C"
|
||||
mb: "I"
|
||||
spm: "C"
|
||||
ppm: "C"
|
||||
al_p: "A"
|
||||
pzm: "C"
|
||||
vb: "I"
|
||||
|
||||
- aktivitaet_id: "7.4"
|
||||
name: "Framework-Updates"
|
||||
beschreibung: "Anpassung von Governance-Frameworks und Methoden"
|
||||
zuordnung:
|
||||
shm: "I"
|
||||
dpm: "C"
|
||||
dsr: "I"
|
||||
mb: "I"
|
||||
spm: "I"
|
||||
ppm: "I"
|
||||
al_p: "I"
|
||||
pzm: "A/R"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNGSHINWEISE
|
||||
# ========================================
|
||||
|
||||
anwendungshinweise:
|
||||
mehrfachzuordnung:
|
||||
beschreibung: "A/R bedeutet: Eine Rolle ist sowohl Responsible als auch Accountable"
|
||||
anwendung: "Bei Fachexpertise = Verantwortung (Prinzip 1)"
|
||||
|
||||
eskalations_kennzeichnung:
|
||||
beschreibung: "(A) in Klammern zeigt Eskalationsinstanz bei Konflikten"
|
||||
anwendung: "Wenn aktuelle Ebene nicht lösen kann, eskaliert zu dieser Instanz"
|
||||
|
||||
optionale_aktivitaeten:
|
||||
beschreibung: "Manche Aktivitäten sind optional (z.B. Bedarfsklärungsgespräch)"
|
||||
kennzeichnung: "Mit '(optional)' im Namen markiert"
|
||||
|
||||
bedingte_zuordnungen:
|
||||
beschreibung: "Manche Zuordnungen gelten nur unter bestimmten Bedingungen"
|
||||
beispiel: "Sponsor-Benennung unterscheidet sich für DSR-Demands vs. MB-Demands"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
prozess_kontext:
|
||||
- titel: "Demand-Klassifizierung"
|
||||
pfad: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
relevanz: "Definiert Routing zu DSR vs. MB"
|
||||
|
||||
- titel: "DSR-Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Detaillierte Arbeitsweise der DSR"
|
||||
|
||||
- titel: "Rollenbeschreibung DPM"
|
||||
pfad: "#01.1_funktion/rollenbeschreibung-dpm.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten des DPM"
|
||||
|
|
@ -0,0 +1,493 @@
|
|||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "dpm"
|
||||
rolle_name: "Demand-Portfolio-Manager:in"
|
||||
aliases: ["DPM", "Portfolio-Manager", "Demand-Manager"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
ueberprueft_durch: "DPM-Teammitglied"
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
hinweis: "anpassen auf Basis der weiteren Workstream-Ergebnisse"
|
||||
|
||||
kontext_tags:
|
||||
- "demand-management"
|
||||
- "portfolio-steuerung"
|
||||
- "qualifizierung"
|
||||
- "bewertung"
|
||||
- "priorisierung"
|
||||
|
||||
# ========================================
|
||||
# 1. ROLLENZWECK
|
||||
# ========================================
|
||||
|
||||
rollenzweck:
|
||||
kurz: "Zentrale Instanz für Qualifizierung, Bewertung und Portfolio-Steuerung aller Demands im DIGIT"
|
||||
|
||||
ausfuehrlich: |
|
||||
Der:die Demand-Portfolio-Manager:in transformiert vorqualifizierte Demands in
|
||||
Demand-Entscheidungsvorlagen und schafft die Grundlage für optimale
|
||||
Ressourcensteuerung durch die verantwortlichen Gremien.
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "nach erfolgter Bedarfsklärung durch Stakeholder-Management"
|
||||
fuer: "alle Demands"
|
||||
bis: "Aufbereitung für Entscheidungsgremien"
|
||||
|
||||
entscheidungsgremien:
|
||||
- gremium_id: "dsr"
|
||||
gremium_name: "Demand & Stakeholder-Runde"
|
||||
- gremium_id: "mission_board"
|
||||
gremium_name: "Mission Board"
|
||||
|
||||
# ========================================
|
||||
# 2. ORGANISATORISCHE EINORDNUNG
|
||||
# ========================================
|
||||
|
||||
organisatorische_einordnung:
|
||||
zuordnung:
|
||||
abteilung: "Abteilung Planung"
|
||||
abteilungskuerzel: "AL-P"
|
||||
|
||||
auspraegungen:
|
||||
beschreibung: "Spezialisierungen nach Themenfeld oder Kapazität möglich, aber nicht strukturell vorgegeben"
|
||||
hinweis: |
|
||||
Die frühere Unterscheidung in DPM Core-IT und DPM Non-Core-IT entfällt.
|
||||
Alle Demands – unabhängig von ihrer Herkunft (Betrieb oder Innovation) –
|
||||
durchlaufen denselben Prozess. Spezialisierungen können bei Bedarf
|
||||
themenfeld- oder kapazitätsbezogen entstehen.
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "Abteilungsleitung Planung"
|
||||
berichtet_an_rolle_id: "al_p"
|
||||
|
||||
arbeitsmodell:
|
||||
typ: "Vollzeitfunktion"
|
||||
vertretung: "gegenseitige Vertretungsregelung zwischen DPM-Mitarbeitenden"
|
||||
|
||||
# ========================================
|
||||
# 3. KERNVERANTWORTLICHKEITEN
|
||||
# ========================================
|
||||
|
||||
kernverantwortlichkeiten:
|
||||
bereich_1_portfolio_management:
|
||||
name: "Demand-Portfolio-Management"
|
||||
|
||||
aufgaben:
|
||||
- id: "PM-01"
|
||||
titel: "Portfolio-Aufbau und -Pflege"
|
||||
beschreibung: "Aufbau und Pflege eines transparenten Demand-Portfolios"
|
||||
frequenz: "kontinuierlich"
|
||||
output: "aktuelles_demand_portfolio"
|
||||
|
||||
- id: "PM-02"
|
||||
titel: "Strategische Portfolio-Analyse"
|
||||
beschreibung: "Strategische Analyse des Demand-Portfolios und Identifizierung von Trends für das Mission Board"
|
||||
frequenz: "quartalsweise"
|
||||
output: "portfolio_trend_analyse"
|
||||
empfaenger: "mission_board"
|
||||
|
||||
- id: "PM-03"
|
||||
titel: "Portfolio-Optimierung"
|
||||
beschreibung: "Kontinuierliche Optimierung der Demand-Portfolio-Zusammensetzung"
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
- id: "PM-04"
|
||||
titel: "Strategiekonformität sicherstellen"
|
||||
beschreibung: "Bewertung und Priorisierung von Demands gemäß der strategischen Leitplanken des Vision Board"
|
||||
referenz_zu: "vision_board"
|
||||
frequenz: "pro_demand"
|
||||
|
||||
bereich_2_demand_qualifizierung:
|
||||
name: "Demand-Qualifizierung, Bewertung und Priorisierung"
|
||||
|
||||
aufgaben:
|
||||
- id: "QBP-01"
|
||||
titel: "Demand-Übernahme"
|
||||
beschreibung: "Übernahme vorqualifizierter Demands vom Stakeholder-Management"
|
||||
von_rolle: "shm"
|
||||
trigger: "demand_uebergabe_quality_gate_1"
|
||||
|
||||
- id: "QBP-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands nach vordefinierten Dimensionen"
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
output: "demand_kategorie"
|
||||
|
||||
- id: "QBP-03"
|
||||
titel: "Demand-Analyse"
|
||||
beschreibung: "Analyse von Demands nach fachlichen und technischen Aspekten und Abhängigkeiten"
|
||||
aspekte:
|
||||
- "fachliche Anforderungen"
|
||||
- "technische Machbarkeit"
|
||||
- "Abhängigkeiten zu anderen Demands/Projekten"
|
||||
output: "analyse_ergebnis"
|
||||
|
||||
- id: "QBP-04"
|
||||
titel: "Demand-Bewertung"
|
||||
beschreibung: "Bewertung und Clusterung von Demands nach qualitativen Bewertungskategorien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
|
||||
- id: "QBP-05"
|
||||
titel: "Demand-Priorisierung"
|
||||
beschreibung: "Priorisierung von Demands nach definiertem Standard und Ableitung von Handlungsempfehlungen"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
|
||||
- id: "QBP-06"
|
||||
titel: "Entscheidungsvorlagen erstellen"
|
||||
beschreibung: "Erstellung von Demand-Entscheidungsvorlagen für Entscheidungsgremien"
|
||||
output: "demand_entscheidungsvorlage"
|
||||
empfaenger: ["dsr", "mission_board"]
|
||||
|
||||
bereich_3_gremienarbeit:
|
||||
name: "Gremienarbeit"
|
||||
|
||||
aufgaben:
|
||||
- id: "GR-01"
|
||||
titel: "DSR-Vorbereitung"
|
||||
beschreibung: "Vorbereitung und Präsentation/Diskussion in der Demand & Stakeholder-Runde (DSR) zur Entscheidung"
|
||||
gremium: "dsr"
|
||||
rolle_in_gremium: "vorsitz"
|
||||
frequenz: "woechentlich"
|
||||
aktivitaeten:
|
||||
- "Agenda erstellen"
|
||||
- "Materialien vorbereiten"
|
||||
- "Präsentation vorbereiten"
|
||||
- "Moderation durchführen"
|
||||
|
||||
- id: "GR-02"
|
||||
titel: "Portfolio-Überblick Mission Board"
|
||||
beschreibung: "Demand-Portfolio Überblick im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "zweiwoechentlich"
|
||||
output: "portfolio_status_update"
|
||||
|
||||
- id: "GR-03"
|
||||
titel: "Entscheidungsvorlagen präsentieren"
|
||||
beschreibung: "Vorstellung der Demand-Entscheidungsvorlagen im Mission Board"
|
||||
gremium: "mission_board"
|
||||
frequenz: "bei_bedarf"
|
||||
|
||||
- id: "GR-04"
|
||||
titel: "Entscheidungsfähigkeit sicherstellen"
|
||||
beschreibung: "Sicherstellung der Entscheidungsfähigkeit durch Bereitstellung der Demand-Entscheidungsvorlage"
|
||||
kritikalitaet: "hoch"
|
||||
qualitaetskriterium: "vollständige und präzise Entscheidungsgrundlagen"
|
||||
|
||||
- id: "GR-05"
|
||||
titel: "Gremienbeschlüsse umsetzen"
|
||||
beschreibung: "Umsetzung und Nachbearbeitung auf Basis von Gremienbeschlüssen"
|
||||
aktivitaeten:
|
||||
- "Statusänderungen im Portfolio"
|
||||
- "Kommunikation an Stakeholder (via SHM)"
|
||||
- "Übergabe an PPM (bei Freigabe)"
|
||||
- "Dokumentation"
|
||||
|
||||
# ========================================
|
||||
# 4. SCHNITTSTELLEN UND ZUSAMMENARBEIT
|
||||
# ========================================
|
||||
|
||||
schnittstellen:
|
||||
primaer:
|
||||
- rolle_id: "shm"
|
||||
rolle_name: "Stakeholder-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_shm_zu_dpm"
|
||||
themen:
|
||||
- "Übernahme vorqualifizierter Demands"
|
||||
- "Rückfragen bei Unvollständigkeit"
|
||||
frequenz: "kontinuierlich"
|
||||
artefakte:
|
||||
input: "bedarfs_steckbrief"
|
||||
output: "rueckfragen_oder_uebernahmebestaetigung"
|
||||
|
||||
- rolle_id: "ppm"
|
||||
rolle_name: "Projekt-Portfolio-Management"
|
||||
art: "sequenziell"
|
||||
richtung: "von_dpm_zu_ppm"
|
||||
themen:
|
||||
- "Übergabe freigegebener Demands zur (Vor-)Projektumsetzung"
|
||||
trigger: "demand_freigabe_durch_gremium"
|
||||
artefakte:
|
||||
input: "freigegebener_demand"
|
||||
output: "projektaufnahme_bestaetigung"
|
||||
|
||||
- rolle_id: "spm"
|
||||
rolle_name: "Service-Portfolio-Management"
|
||||
art: "koordinativ"
|
||||
richtung: "bidirektional"
|
||||
themen:
|
||||
- "Abstimmung zu Service-Bezug"
|
||||
- "Klärung: direkte Umsetzung vs. Projekt"
|
||||
frequenz: "bei_bedarf_pro_demand"
|
||||
kontext: "Besonders relevant bei Demands mit Service-Impact"
|
||||
|
||||
sekundaer:
|
||||
- rolle_id: "it_architektur"
|
||||
rolle_name: "IT-Architektur"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Klärung strategischer Grundsatzfragen"
|
||||
- "Klärung technischer Grundsatzfragen"
|
||||
frequenz: "bei_bedarf"
|
||||
trigger: "komplexe_technische_anforderungen"
|
||||
|
||||
- bezeichnung: "Fachexpert:innen"
|
||||
art: "konsultativ"
|
||||
themen:
|
||||
- "Einholung spezifischer Expertise"
|
||||
frequenz: "bei_bedarf"
|
||||
beispiele:
|
||||
- "Datenschutzexpert:innen"
|
||||
- "Sicherheitsexpert:innen"
|
||||
- "Fachbereichsexpert:innen"
|
||||
|
||||
# ========================================
|
||||
# 5. ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ========================================
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
eigenstaendige_entscheidungen:
|
||||
beschreibung: "Entscheidungen, die der DPM ohne Gremienabstimmung treffen kann"
|
||||
|
||||
liste:
|
||||
- id: "ENT-01"
|
||||
titel: "Demand-Rückweisung"
|
||||
beschreibung: "Rückweisung unzureichend vorqualifizierter Demands an das Stakeholder-Management zur konkreten Nachbearbeitung"
|
||||
bedingung: "unzureichende_qualitaet_oder_vollstaendigkeit"
|
||||
rueckweisung_an: "shm"
|
||||
|
||||
- id: "ENT-02"
|
||||
titel: "Demand-Klassifizierung"
|
||||
beschreibung: "Klassifizierung von Demands gemäß der vordefinierten Dimensionen"
|
||||
bindend: true
|
||||
kann_ueberstimmt_werden_von: ["dsr", "mission_board"]
|
||||
methode_referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "ENT-03"
|
||||
titel: "Demand-Konsolidierung"
|
||||
beschreibung: "Konsolidierung ähnlicher oder zusammengehöriger Demands"
|
||||
rationale: "Vermeidung von Redundanzen und Synergienutzung"
|
||||
|
||||
- id: "ENT-04"
|
||||
titel: "Expert:innen-Einbindung"
|
||||
beschreibung: "Einbeziehung von Fachexpert:innen"
|
||||
kontext: "Bei Bedarf für fundierte Analyse und Bewertung"
|
||||
|
||||
empfehlungen_fuer_gremien:
|
||||
beschreibung: "DPM bereitet Entscheidungen vor, finales Votum liegt bei Gremien"
|
||||
|
||||
liste:
|
||||
- id: "EMP-01"
|
||||
titel: "Bewertungsprofile"
|
||||
beschreibung: "Bewertungsprofile mit qualitativen Cluster-Fazits als Diskussionsgrundlage für Gremien"
|
||||
methode_referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
output: "bewertungsprofil"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
- id: "EMP-02"
|
||||
titel: "Priorisierungs-Empfehlung"
|
||||
beschreibung: "Priorisierung- und Handlungsempfehlung für Demands"
|
||||
methode_referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
output: "priorisierungs_empfehlung"
|
||||
entscheidung_durch: ["dsr", "mission_board"]
|
||||
|
||||
qualitaetssicherung:
|
||||
beschreibung: "Recht und Pflicht zur Sicherstellung methodischer und prozessualer Qualität"
|
||||
|
||||
liste:
|
||||
- id: "QS-01"
|
||||
titel: "Standards durchsetzen"
|
||||
beschreibung: "Standards für Demand-Dokumentationen und -Bewertung durchzusetzen"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-02"
|
||||
titel: "Methodentreue einfordern"
|
||||
beschreibung: "Methodentreue bei allen Prozessbeteiligten einzufordern"
|
||||
gueltig_fuer: "alle_prozessbeteiligten"
|
||||
|
||||
- id: "QS-03"
|
||||
titel: "Transparenz sicherstellen"
|
||||
beschreibung: "Transparenz durch vollständige Demand-Portfolio-Dokumentation sicherzustellen"
|
||||
output: "vollstaendiges_demand_portfolio"
|
||||
|
||||
- id: "QS-04"
|
||||
titel: "Verbesserungen vorschlagen"
|
||||
beschreibung: "Verbesserungen für Prozesse und Methoden basierend auf Erfahrungswerten vorzuschlagen"
|
||||
empfaenger: ["al_p", "mission_board"]
|
||||
frequenz: "kontinuierlich"
|
||||
|
||||
# ========================================
|
||||
# 6. WERKZEUGE UND METHODEN
|
||||
# ========================================
|
||||
|
||||
werkzeuge_und_methoden:
|
||||
it_werkzeuge:
|
||||
- id: "TOOL-01"
|
||||
name: "Ticketsystem"
|
||||
zweck: "Zentrale Dokumentation und Statusverfolgung"
|
||||
verwendung: "alle_demands"
|
||||
|
||||
- id: "TOOL-02"
|
||||
name: "Demand-Portfolio-Datenbank"
|
||||
zweck: "Transparente Übersicht aller Demands"
|
||||
features:
|
||||
- "Portfolio-Übersicht"
|
||||
- "Status-Tracking"
|
||||
- "Reporting-Funktionen"
|
||||
|
||||
standardvorlagen:
|
||||
- id: "TPL-01"
|
||||
name: "Demand-Entscheidungsvorlage"
|
||||
verwendung: "für_gremienpraesentation"
|
||||
zielgruppe: ["dsr", "mission_board"]
|
||||
|
||||
- id: "TPL-02"
|
||||
name: "Bedarfs-Steckbrief"
|
||||
verwendung: "input_von_shm"
|
||||
status: "wird_geprueft_und_erweitert"
|
||||
|
||||
methoden:
|
||||
- id: "METH-01"
|
||||
name: "Demand-Kategorien"
|
||||
beschreibung: "Standardisierte Methodik zur Qualifizierung und Kategorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
|
||||
- id: "METH-02"
|
||||
name: "Bewertungskriterien"
|
||||
beschreibung: "Standardisierte Methodik zur Bewertung von Demands"
|
||||
referenz: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
- id: "METH-03"
|
||||
name: "Priorisierungsmethodik"
|
||||
beschreibung: "Standardisierte Methodik zur Priorisierung von Demands"
|
||||
referenz: "#01.4_methodik/demand-priorisierung.yaml"
|
||||
|
||||
# ========================================
|
||||
# 7. ERFORDERLICHE KOMPETENZEN
|
||||
# ========================================
|
||||
|
||||
erforderliche_kompetenzen:
|
||||
fachlich:
|
||||
- id: "FK-01"
|
||||
kompetenz: "IT-Landschaft"
|
||||
beschreibung: "Fundiertes Verständnis der IT-Landschaft und digitalen Services"
|
||||
niveau: "fundiert"
|
||||
|
||||
- id: "FK-02"
|
||||
kompetenz: "Demand-Portfolio-Management"
|
||||
beschreibung: "Expertise in Demand-Portfolio-Management und Business-Analyse"
|
||||
niveau: "expertise"
|
||||
|
||||
- id: "FK-03"
|
||||
kompetenz: "Projektmanagement"
|
||||
beschreibung: "Kenntnisse in Projektmanagement"
|
||||
niveau: "kenntnisse"
|
||||
|
||||
- id: "FK-04"
|
||||
kompetenz: "Verwaltungsprozesse"
|
||||
beschreibung: "Verwaltungsspezifisches Prozessverständnis"
|
||||
niveau: "verstaendnis"
|
||||
kontext: "Öffentliche Verwaltung, kommunale Strukturen"
|
||||
|
||||
methodisch:
|
||||
- id: "MK-01"
|
||||
kompetenz: "Analytisches Denken"
|
||||
beschreibung: "Analytisches und strategisches Denkvermögen"
|
||||
anwendung: "Demand-Analyse, Portfolio-Trends identifizieren"
|
||||
|
||||
- id: "MK-02"
|
||||
kompetenz: "Strukturierte Arbeitsweise"
|
||||
beschreibung: "Strukturierte Arbeitsweise und Komplexitätsmanagement"
|
||||
anwendung: "Parallele Bearbeitung vieler Demands"
|
||||
|
||||
- id: "MK-03"
|
||||
kompetenz: "Präsentation und Moderation"
|
||||
beschreibung: "Präsentations- und Moderationskompetenz"
|
||||
anwendung: "Gremienarbeit, DSR-Vorsitz"
|
||||
|
||||
- id: "MK-04"
|
||||
kompetenz: "Konfliktlösung"
|
||||
beschreibung: "Konfliktlösungsfähigkeit"
|
||||
anwendung: "Dissens in DSR, konkurrierende Stakeholder-Interessen"
|
||||
|
||||
sozial:
|
||||
- id: "SK-01"
|
||||
kompetenz: "Kommunikation"
|
||||
beschreibung: "Exzellente Kommunikationsfähigkeit über alle Hierarchieebenen"
|
||||
kritikalitaet: "hoch"
|
||||
kontext: "Von Fachexpert:innen bis Amtsleitung"
|
||||
|
||||
- id: "SK-02"
|
||||
kompetenz: "Diplomatisches Geschick"
|
||||
beschreibung: "Diplomatisches Geschick und Neutralität"
|
||||
anwendung: "Vermittlung zwischen divergierenden Interessen"
|
||||
kritikalitaet: "hoch"
|
||||
|
||||
- id: "SK-03"
|
||||
kompetenz: "Teamfähigkeit"
|
||||
beschreibung: "Teamfähigkeit und Serviceorientierung"
|
||||
kontext: "Zusammenarbeit mit SHM, SPM, PPM"
|
||||
|
||||
- id: "SK-04"
|
||||
kompetenz: "Durchsetzungsvermögen"
|
||||
beschreibung: "Durchsetzungsvermögen bei gleichzeitiger Kompromissbereitschaft"
|
||||
anwendung: "Methodentreue einfordern vs. pragmatische Lösungen finden"
|
||||
|
||||
# ========================================
|
||||
# 8. ERFOLGSFAKTOREN
|
||||
# ========================================
|
||||
|
||||
erfolgsfaktoren:
|
||||
beschreibung: "Kritische Rahmenbedingungen für erfolgreiche Rollenausübung"
|
||||
|
||||
faktoren:
|
||||
- id: "EF-01"
|
||||
titel: "Klare Prozessdefinition"
|
||||
beschreibung: "Umfängliche Nutzung des Demand-to-Project-Prozesses"
|
||||
abhaengigkeit: "Alle Beteiligten halten sich an definierten Prozess"
|
||||
risiko_bei_fehlen: "Umgehung des DPM, inkonsistente Demand-Behandlung"
|
||||
|
||||
- id: "EF-02"
|
||||
titel: "Management-Unterstützung"
|
||||
beschreibung: "Rückendeckung durch Amtsleitung und Gremien"
|
||||
abhaengigkeit: "Amtsleitung stärkt DPM-Rolle aktiv"
|
||||
risiko_bei_fehlen: "DPM-Entscheidungen werden nicht akzeptiert"
|
||||
|
||||
- id: "EF-03"
|
||||
titel: "Systemunterstützung"
|
||||
beschreibung: "Funktionsfähige IT-Werkzeuge und Vorlagen"
|
||||
abhaengigkeit: "Ticketsystem, Portfolio-Datenbank, Templates verfügbar"
|
||||
risiko_bei_fehlen: "Manuelle Arbeit, Intransparenz, Ineffizienz"
|
||||
|
||||
- id: "EF-04"
|
||||
titel: "Akzeptanz"
|
||||
beschreibung: "Anerkennung als neutrale Koordinationsinstanz"
|
||||
abhaengigkeit: "Stakeholder vertrauen auf Objektivität des DPM"
|
||||
risiko_bei_fehlen: "Politisierung von Entscheidungen, Umgehung"
|
||||
|
||||
# ========================================
|
||||
# REFERENZEN
|
||||
# ========================================
|
||||
|
||||
referenzen:
|
||||
beschreibung: "Weiterführende Dokumente zur DPM-Rolle"
|
||||
|
||||
dokumente:
|
||||
- titel: "Demand-Portfolio Governance"
|
||||
pfad: "#01.2_governance/demand-portfolio-governance.yaml"
|
||||
relevanz: "Governance-Rahmen für DPM-Arbeit"
|
||||
|
||||
- titel: "RACI-Matrix Demand-Portfolio-Management"
|
||||
pfad: "#01.2_governance/raci-matrix-demand-portfolio-management.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten im Prozess"
|
||||
|
||||
- titel: "Demand & Stakeholder-Runde (DSR) Geschäftsordnung"
|
||||
pfad: "#01.2_governance/dsr-geschaeftsordnung.yaml"
|
||||
relevanz: "Arbeitsweise des wichtigsten Gremiums für DPM"
|
||||
|
|
@ -0,0 +1,123 @@
|
|||
phase:
|
||||
id: 1
|
||||
titel: "Initiierung und Erfassung"
|
||||
ziel: "Identifikation von Bedarfen durch Stakeholder und Überführung in qualifizierte Bedarfssteckbriefe durch das Stakeholder-Management, inklusive Abgrenzung zum bestehenden Service-Katalog."
|
||||
verantwortlich_rolle: "Stakeholder-Management (SHM)"
|
||||
|
||||
schema_referenzen:
|
||||
bedarfs_steckbrief:
|
||||
pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml"
|
||||
version: "1.1"
|
||||
bedarfsbewertung:
|
||||
pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||||
beschreibung: "Routing-Logik und Entscheidungsbaum"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "1.1"
|
||||
titel: "Bedarfsidentifikation"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Ein Stakeholder erkennt einen fachlichen Bedarf, der nicht durch die bestehende Arbeitsumgebung abgedeckt ist."
|
||||
input: "Fachlicher Auslöser (z.B. Gesetzesänderung, Prozessoptimierung)"
|
||||
output: "Initialer Bedarfsgedanke"
|
||||
raci_referenz: "1.1"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.2"
|
||||
titel: "Bedarfsmeldung"
|
||||
akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Der Stakeholder meldet den Bedarf über definierte Kanäle (z.B. Service Desk Ticket, direkte Ansprache) an DIGIT."
|
||||
input: "Initialer Bedarfsgedanke"
|
||||
output: "Unqualifizierte Bedarfsmeldung (Ticket)"
|
||||
system: "Ticketsystem"
|
||||
raci_referenz: "1.2"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.3"
|
||||
titel: "Initiale Qualifizierung (Triage)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Erste Sichtung der Meldung. Prüfung auf Vollständigkeit der Basisinformationen und Zuständigkeit."
|
||||
input: "Unqualifizierte Bedarfsmeldung"
|
||||
output: "Qualifizierungsstatus"
|
||||
raci_referenz: "1.3"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.4"
|
||||
titel: "Service-Katalog-Prüfung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
support_akteur: "Service-Portfolio-Management (SPM)"
|
||||
beschreibung: "Abgleich des Bedarfs mit dem existierenden Service-Katalog. Entscheidung, ob es sich um einen Standard-Request handelt."
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Bedarf durch bestehenden Service-Katalog abdeckbar?"
|
||||
option_ja: "Routing in Request Fulfilment Prozess (Out of Demand Scope)"
|
||||
option_nein: "Weiter in Demand-Prozess (Schritt 1.5)"
|
||||
routing_pfad_bei_ja:
|
||||
id: "ROUTE-REQ"
|
||||
name: "Request Fulfilment"
|
||||
ziel: "Service Desk"
|
||||
steckbrief_erforderlich: false
|
||||
hinweis: "Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung"
|
||||
raci_referenz: "1.4"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.5"
|
||||
titel: "Bedarfsklärungsgespräch"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
partner_akteur: "Stakeholder (SH)"
|
||||
beschreibung: "Strukturiertes Interview zur Erhebung der funktionalen und nicht-funktionalen Anforderungen, des Nutzens und der Rahmenbedingungen."
|
||||
input: "Qualifizierte Meldung"
|
||||
output: "Protokollierte Anforderungen"
|
||||
artefakte: "Bedarfs-Steckbrief (Draft)"
|
||||
raci_referenz: "1.5"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.6"
|
||||
titel: "User Story Erstellung"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: "Übersetzung der Anforderungen in strukturierte User Stories (Wer möchte was warum?) zur Sicherstellung der fachlichen Perspektive."
|
||||
input: "Protokollierte Anforderungen"
|
||||
output: "Fertiger Bedarfs-Steckbrief"
|
||||
artefakte:
|
||||
- "Bedarfs-Steckbrief (Final)"
|
||||
- "Leitfaden User Stories"
|
||||
raci_referenz: "1.6"
|
||||
citation: [506]
|
||||
|
||||
- schritt_id: "1.7"
|
||||
titel: "Bedarfs-Routing (Quality Gate 1)"
|
||||
akteur: "Stakeholder-Management (SHM)"
|
||||
beschreibung: |
|
||||
Routing-Entscheidung basierend auf Bedarfsbewertung.
|
||||
Je nach Ergebnis erfolgt Übergabe an unterschiedliche Empfänger.
|
||||
input: "Bedarfs-Steckbrief (Final oder reduziert je nach Routing)"
|
||||
system: "Ticketsystem / Demand-Portfolio-Datenbank"
|
||||
raci_referenz: "1.7"
|
||||
citation: [506]
|
||||
|
||||
routing_optionen:
|
||||
- routing_id: "ROUTE-DPM"
|
||||
name: "Demand Portfolio Management"
|
||||
empfaenger: "Demand-Portfolio-Management (DPM)"
|
||||
bedingung: "Neuer Service oder grundlegende Neugestaltung erforderlich"
|
||||
output: "Demand (Status: an_dpm_uebergeben)"
|
||||
steckbrief_vollstaendig: true
|
||||
trigger_next_phase: "Phase 2: Qualifizierung und Priorisierung"
|
||||
quality_gate: true
|
||||
|
||||
- routing_id: "ROUTE-SPM"
|
||||
name: "Service Portfolio Management (Change)"
|
||||
empfaenger: "Service-Portfolio-Management (SPM)"
|
||||
bedingung: "Änderung an bestehendem Service"
|
||||
output: "Change Request (Status: an_spm_uebergeben)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Reduzierter Steckbrief ausreichend"
|
||||
|
||||
- routing_id: "ROUTE-SO"
|
||||
name: "Service-Owner-Klärung"
|
||||
empfaenger: "Service Owner (über Service-Portfolio / SPM)"
|
||||
bedingung: "Routing unklar – bilaterale Klärung mit Service Owner"
|
||||
output: "Klärungsfall (Status: in_so_klaerung)"
|
||||
steckbrief_vollstaendig: false
|
||||
hinweis: "Wenn Service Owner identifizierbar: direkte bilaterale Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR."
|
||||
referenz: "GOV-SHM-029"
|
||||
|
||||
validierungsprofile_referenz: "shm_schema_bedarfssteckbrief.yaml#validierungsprofile"
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
phase:
|
||||
id: 2
|
||||
titel: "Qualifizierung und Priorisierung"
|
||||
ziel: "Systematische Analyse, Bewertung und Priorisierung des Demands zur Herstellung der Entscheidungsreife für das zuständige Gremium."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "2.1"
|
||||
titel: "Vollständigkeitsprüfung (Quality Gate 2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Prüfung des übergebenen Bedarfs-Steckbriefs auf formale Vollständigkeit und inhaltliche Plausibilität."
|
||||
input: "Bedarfs-Steckbrief (Final)"
|
||||
entscheidungspunkt:
|
||||
frage: "Ist der Steckbrief ausreichend qualifiziert?"
|
||||
option_ja: "Weiter zur Klassifizierung (Schritt 2.2)"
|
||||
option_nein: "Rückweisung an Stakeholder-Management zur Nachbesserung"
|
||||
raci_referenz: "2.1"
|
||||
citation: [376, 196]
|
||||
|
||||
- schritt_id: "2.2"
|
||||
titel: "Demand-Klassifizierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Einordnung des Demands in die vier Steuerungsdimensionen: Treiber, Tragweite, Systemebene, Komplexität."
|
||||
input: "Bedarfs-Steckbrief"
|
||||
output: "Klassifizierter Demand mit initialem Routing-Vorschlag"
|
||||
artefakte: "Klassifizierungsmatrix"
|
||||
raci_referenz: "2.2"
|
||||
citation: [376, 1048]
|
||||
|
||||
- schritt_id: "2.3"
|
||||
titel: "Inhaltliche Analyse & Abhängigkeitsprüfung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
support_akteure:
|
||||
- "IT-Architektur-Board (bei Architekturrelevanz)"
|
||||
- "Projekt-Portfolio-Management (PPM) (für Portfolio-Check)"
|
||||
- "Service-Portfolio-Management (SPM) (für Service-Impact)"
|
||||
beschreibung: "Tiefenprüfung der Anforderungen, Identifikation technischer/fachlicher Abhängigkeiten zu anderen Demands/Projekten und Ersteinschätzung des Lösungsraums."
|
||||
input: "Klassifizierter Demand"
|
||||
output: "Analyseergebnisse & identifizierte Abhängigkeiten"
|
||||
raci_referenz: "2.3"
|
||||
citation: [376, 113]
|
||||
|
||||
- schritt_id: "2.4"
|
||||
titel: "Demand-Bewertung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Qualitative Bewertung anhand der drei Cluster: Nutzen & Wirkung, Druck & Notwendigkeit, Machbarkeit & Aufwand."
|
||||
input: "Analyseergebnisse"
|
||||
output: "Bewertungs-Scores je Cluster"
|
||||
raci_referenz: "2.4"
|
||||
citation: [376, 1309]
|
||||
|
||||
- schritt_id: "2.5"
|
||||
titel: "Priorisierung"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Überführung der Bewertungsergebnisse in die Priorisierungs-Matrix (Wichtigkeit vs. Dringlichkeit) zur Ermittlung der Handlungsempfehlung."
|
||||
input: "Bewertungs-Scores"
|
||||
output: "Priorisierter Demand (Quadrant + Machbarkeits-Ampel)"
|
||||
artefakte: "Priorisierungs-Matrix"
|
||||
raci_referenz: "2.5"
|
||||
citation: [376, 1593]
|
||||
|
||||
- schritt_id: "2.6"
|
||||
titel: "Erstellung Entscheidungsvorlage"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Zusammenführung aller Ergebnisse in eine standardisierte Vorlage für das Entscheidungsgremium inklusive finalem Routing-Vorschlag."
|
||||
input: "Priorisierter Demand"
|
||||
output: "Entscheidungsreife Vorlage"
|
||||
artefakte: "Demand-Entscheidungsvorlage"
|
||||
trigger_next_phase: "Phase 3: Entscheidung und Freigabe"
|
||||
raci_referenz: "2.6"
|
||||
citation: [376, 1770]
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
phase:
|
||||
id: 3
|
||||
titel: "Entscheidung und Freigabe"
|
||||
ziel: "Herbeiführung einer verbindlichen Entscheidung (Freigabe, Ablehnung, Delegation) durch das zuständige Gremium inklusive Definition notwendiger Rahmenbedingungen."
|
||||
verantwortlich_rolle: "Demand-Portfolio-Management (DPM)"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "3.1"
|
||||
titel: "DSR-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Finale Qualitätssicherung der Vorlage und Versand der Unterlagen an DSR-Mitglieder (min. 24h vor Sitzung)."
|
||||
input: "Entscheidungsreife Vorlage"
|
||||
output: "Versendete Sitzungsunterlagen"
|
||||
raci_referenz: "3.1"
|
||||
citation: [378, 461]
|
||||
|
||||
- schritt_id: "3.2"
|
||||
titel: "DSR-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = DSR oder DSR mit Delegationsoption"
|
||||
akteur: "Demand & Stakeholder Runde (DSR)"
|
||||
moderator: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Präsentation des Demands und Entscheidungsfindung im Konsent-Verfahren."
|
||||
entscheidungspunkt:
|
||||
frage: "DSR-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_delegation: "Weiter zu Schritt 3.3 (MB-Vorbereitung)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung erforderlich)"
|
||||
raci_referenz: "3.2, 3.3, 3.4"
|
||||
citation: [378, 470]
|
||||
|
||||
- schritt_id: "3.3"
|
||||
titel: "MB-Vorbereitung (Async)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR (aus 3.2)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Aufbereitung der Entscheidungsvorlage für die strategische Perspektive des Mission Boards."
|
||||
input: "Vorlage (ggf. mit Delegationsvotum der DSR)"
|
||||
output: "MB-Sitzungsunterlagen"
|
||||
raci_referenz: "3.5"
|
||||
citation: [378]
|
||||
|
||||
- schritt_id: "3.4"
|
||||
titel: "MB-Sitzung (Sync)"
|
||||
bedingung: "Falls Routing = Mission Board ODER Delegation durch DSR"
|
||||
akteur: "Mission Board (MB)"
|
||||
support_akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Strategische Diskussion und finale Entscheidung über MB-relevante Demands."
|
||||
entscheidungspunkt:
|
||||
frage: "MB-Entscheidungsergebnis?"
|
||||
option_freigabe: "Weiter zu Schritt 3.5 (Finalisierung)"
|
||||
option_ablehnung: "Weiter zu Schritt 3.6 (Kommunikation)"
|
||||
option_vertagung: "Zurück zu Phase 2 (Nachbesserung) oder 3.3 (Wiedervorlage)"
|
||||
raci_referenz: "3.6, 3.7"
|
||||
citation: [378, 381]
|
||||
|
||||
- schritt_id: "3.5"
|
||||
titel: "Entscheidungs-Finalisierung"
|
||||
bedingung: "Nur bei Freigabe (durch DSR oder MB)"
|
||||
akteur: "Entscheidungsgremium (DSR/MB)"
|
||||
beschreibung: "Festlegung verbindlicher Auflagen für die Umsetzung und Benennung eines fachlichen Sponsors."
|
||||
output: "Vollständiger Gremienbeschluss mit Auflagen & Sponsor"
|
||||
raci_referenz: "3.8, 3.9, 3.10"
|
||||
citation: [381, 482]
|
||||
|
||||
- schritt_id: "3.6"
|
||||
titel: "Kommunikation & Routing (Quality Gate 3)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Formale Dokumentation des Beschlusses, Information an Stakeholder (via SHM) und Routing in die nächste Phase."
|
||||
input: "Gremienbeschluss"
|
||||
output: "Aktualisierter Demand-Status"
|
||||
trigger_next_phase: "Phase 4: Projektinitiierung (bei Freigabe) ODER Archivierung (bei Ablehnung)"
|
||||
raci_referenz: "3.11"
|
||||
citation: [381]
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
phase:
|
||||
id: 4
|
||||
titel: "Projektinitiierung (Übergang)"
|
||||
ziel: "Geordnete Übergabe des freigegebenen Demands in die Verantwortung des Projekt-Portfolio-Managements zur Initialisierung der Umsetzung."
|
||||
verantwortlich_rolle: "Projekt-Portfolio-Management (PPM) [Übergang von DPM]"
|
||||
|
||||
schritte:
|
||||
- schritt_id: "4.1"
|
||||
titel: "Projektauftrag erstellen"
|
||||
bedingung: "Nur bei freigegebenen Demands (aus Phase 3)"
|
||||
akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
support_akteure:
|
||||
- "Demand-Portfolio-Management (DPM) (Übergabe Historie)"
|
||||
- "Stakeholder-Management (SHM) (Stakeholder-Kontext)"
|
||||
beschreibung: "Formaler Start der Projektinitiierung. Überführung der Demand-Daten (Steckbrief, Beschluss, Auflagen) in einen initialen Projektauftrag."
|
||||
input: "Gremienbeschluss & Demand-Akte"
|
||||
output: "Initialer Projektauftrag"
|
||||
raci_referenz: "4.1"
|
||||
citation: [385]
|
||||
|
||||
- schritt_id: "4.2"
|
||||
titel: "Benennung Projektleitung"
|
||||
akteur: "Service-Portfolio-Management (SPM)"
|
||||
support_akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
beschreibung: "Identifikation und formale Benennung der Projektleitung, idealerweise aus dem Umfeld des zukünftigen Service Owners."
|
||||
input: "Projektauftrag"
|
||||
output: "Benannte Projektleitung"
|
||||
raci_referenz: "4.2"
|
||||
citation: [385, 500]
|
||||
|
||||
- schritt_id: "4.3"
|
||||
titel: "Ressourcenmobilisierung"
|
||||
akteur: "Projekt-Portfolio-Management (PPM)"
|
||||
partner_akteur: "Projektleitung (PL)"
|
||||
beschreibung: "Initiale Zusammenstellung des Projektteams und Sicherstellung der Verfügbarkeit gemäß Gremienbeschluss."
|
||||
input: "Benannte Projektleitung & Ressourcen-Bedarf"
|
||||
output: "Initiales Projektteam"
|
||||
raci_referenz: "4.3"
|
||||
citation: [385, 501]
|
||||
|
||||
- schritt_id: "4.4"
|
||||
titel: "Demand-Archivierung (Abschluss DPM)"
|
||||
akteur: "Demand-Portfolio-Management (DPM)"
|
||||
beschreibung: "Formaler Abschluss des Demand-Prozesses. Der Demand gilt als 'umgesetzt' in ein Projekt. Sicherstellung der Traceability (Demand -> Projekt)."
|
||||
input: "Bestätigung Projektstart"
|
||||
output: "Demand (Status: Abgeschlossen / In Umsetzung)"
|
||||
trigger_next_lifecycle: "Start Service-Lifecycle (Design Phase)"
|
||||
raci_referenz: "4.4"
|
||||
citation: [385]
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,184 @@
|
|||
metadata:
|
||||
name: "Design"
|
||||
yasm_referenz: "LP2: Design new or changed services"
|
||||
version: "3.0"
|
||||
status: "draft"
|
||||
erstellt: "2026-01-22"
|
||||
aktualisiert: "2026-02-18"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Strategische und architektonische Gestaltung neuer oder wesentlich
|
||||
geänderter Services. Umfasst Service-Definition, Architektur-Design
|
||||
und Implementation Blueprint.
|
||||
|
||||
Diese Phase entspricht YASM LP2 (Design new or changed services) und
|
||||
fokussiert auf die Planung und das Design, NICHT auf die Implementierung.
|
||||
|
||||
aenderungen:
|
||||
- version: "3.0"
|
||||
datum: "2026-02-18"
|
||||
beschreibung: >
|
||||
Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase
|
||||
verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1
|
||||
ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design.
|
||||
|
||||
- version: "2.1"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft"
|
||||
(g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR
|
||||
Beginn der Transition geprüft werden, um Ressourcenverschwendung zu
|
||||
vermeiden. Alle Prüfdimensionen nun explizit dokumentiert.
|
||||
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_
|
||||
umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2026-01-22"
|
||||
beschreibung: "Initiale Erstellung nach YASM LP2"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Demand Lifecycle Phase 4"
|
||||
artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)"
|
||||
beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert"
|
||||
ausgang:
|
||||
- ziel: "Transition"
|
||||
artefakt: "Service Design Document + Implementation Blueprint"
|
||||
beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase"
|
||||
|
||||
hinweis: >
|
||||
Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung).
|
||||
Nach YASM LP2 werden hier alle strategischen und architektonischen
|
||||
Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt
|
||||
als erste Aktivität der Transition-Phase (tr_01).
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_01
|
||||
name: "Definieren der erforderlichen Service-Eigenschaften"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Definition (Utility & Warranty)"
|
||||
ehemals: "sd_01"
|
||||
|
||||
beschreibung: >
|
||||
Grundlegende Definition des neuen oder geänderten Services aus
|
||||
fachlicher Perspektive.
|
||||
|
||||
umfasst:
|
||||
- "Definition von Zweck, Nutzen, Zielgruppen"
|
||||
- "Definition der Utility & Warranty des Services"
|
||||
- "Ableitung der SLA-/SLO-Anforderungen"
|
||||
- "Ermittlung unterstützender Services und Abhängigkeiten"
|
||||
- "Identifikation fachlicher und technischer Anforderungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: architektur
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_02
|
||||
name: "Designen der erforderlichen Service- und Service-Management-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Service Architecture Design"
|
||||
ehemals: "sd_02"
|
||||
|
||||
beschreibung: >
|
||||
Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell.
|
||||
|
||||
umfasst:
|
||||
- "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)"
|
||||
- "Design der Betriebs- und Supportprozesse"
|
||||
- "Sicherheits-, Compliance- und Datenschutzanforderungen"
|
||||
- "Monitoring & Reporting-Anforderungen"
|
||||
- "Tool-/Konfigurationsanforderungen"
|
||||
- "Rollenmodell (Support, Betrieb, Governance)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: architektur
|
||||
raci: R
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_03
|
||||
name: "Beschreiben des Vorgehens zur Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Implementation Blueprint"
|
||||
ehemals: "sd_03"
|
||||
|
||||
beschreibung: >
|
||||
Planen, WIE der Service organisatorisch eingeführt wird
|
||||
(nicht technisch deployt wird).
|
||||
|
||||
umfasst:
|
||||
- "Plan für organisatorische Integration"
|
||||
- "Definition aller Rollenübergaben"
|
||||
- "Anpassung von Richtlinien, Prozessen, Toolkonfiguration"
|
||||
- "Definition benötigter Trainings / Kommunikation"
|
||||
- "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: ds_04
|
||||
name: "Vorbereiten der Service-Implementierung"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP2: Organizational Integration Planning"
|
||||
ehemals: "sd_04"
|
||||
|
||||
beschreibung: >
|
||||
Finalisieren aller organisatorischen Voraussetzungen für die
|
||||
spätere Übergabe in den Betrieb.
|
||||
|
||||
umfasst:
|
||||
- "Abstimmung mit Betrieb & Support"
|
||||
- "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind"
|
||||
- "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht"
|
||||
- "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
|
|
@ -0,0 +1,277 @@
|
|||
metadata:
|
||||
name: "Operation"
|
||||
yasm_referenz: "LP4: Operate the services (LP4.1-LP4.5)"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Laufender Betrieb eines aktivierten Services. Beginnt mit Early Life Support
|
||||
(ELS) nach Go-Live und umfasst die strukturelle Grundlage (Leitlinien),
|
||||
operative Durchführung, Ressourcensteuerung, Monitoring,
|
||||
Qualitätsberichterstattung und proaktive Problemerkennung.
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Betrieb"
|
||||
zu "Operation". Aktivitäts-IDs von sb_ auf op_ umgestellt. Early Life
|
||||
Support (ehemals st_04) als op_01 integriert.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-11-26"
|
||||
beschreibung: "Initiale Erstellung"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Transition"
|
||||
artefakt: "Aktivierter Service"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_11)"
|
||||
ausgang:
|
||||
- ziel: "Support"
|
||||
artefakt: "Alarme, Events, Betriebsinformationen"
|
||||
- ziel: "Review"
|
||||
artefakt: "Service-Qualitätsbericht, Betriebsdaten"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_01
|
||||
name: "Early Life Support (ELS)"
|
||||
typ: aktivitaet
|
||||
ehemals: "st_04"
|
||||
|
||||
beschreibung: >
|
||||
Phase erhöhter Aufmerksamkeit unmittelbar nach dem Go-Live.
|
||||
Der Service ist produktiv, wird aber intensiver beobachtet und
|
||||
betreut als im Normalbetrieb.
|
||||
|
||||
umfasst:
|
||||
- "Erhöhte Monitoring-Bereitschaft"
|
||||
- "Direkte Eskalationswege zum Projektteam (Phase 1: 4h Reaktionszeit)"
|
||||
- "Schnelles Troubleshooting"
|
||||
- "Aufarbeitung erster Incidents"
|
||||
- "Feedback-Sammlung von Nutzern"
|
||||
- "Stabilisierung bis zum Normalbetrieb"
|
||||
- "ELS-Exit-Entscheidung (SO) nach Erfüllung der Exit-Kriterien"
|
||||
|
||||
dauer:
|
||||
mindestdauer: "2 Wochen"
|
||||
regeldauer: "4 Wochen"
|
||||
maximaldauer: "8 Wochen (Eskalations-Trigger)"
|
||||
|
||||
exit_kriterien:
|
||||
- id: "EXIT-01"
|
||||
name: "Stabilität"
|
||||
beschreibung: "Keine kritischen Störungen in den letzten 2 Wochen"
|
||||
- id: "EXIT-02"
|
||||
name: "Support-Normalisierung"
|
||||
beschreibung: "Ticket-Aufkommen auf erwartetem Normalniveau"
|
||||
- id: "EXIT-03"
|
||||
name: "Mängelfreiheit"
|
||||
beschreibung: "Keine offenen fundamentalen Mängel"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet ELS-Erfolg und ELS-Exit-Entscheidung"
|
||||
- rolle: support_manager
|
||||
raci: R
|
||||
- rolle: operations_manager
|
||||
raci: R
|
||||
- rolle: projektteam
|
||||
raci: C
|
||||
kontext: "Während der ELS-Phase auf Abruf verfügbar"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Informiert über ELS-Ende"
|
||||
|
||||
hinweis: >
|
||||
Der SO entscheidet eigenständig über den ELS-Exit (mit Informationspflicht
|
||||
an SPM). Bei Überschreitung der Maximaldauer erfolgt automatische
|
||||
SOR-Eskalation.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_02
|
||||
name: "Bereitstellen von Leitlinien für den Service-Betrieb"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_01"
|
||||
|
||||
beschreibung: >
|
||||
Dies ist die strukturelle Grundlage für den täglichen Servicebetrieb.
|
||||
|
||||
umfasst:
|
||||
- "Betriebshandbuch bereitstellen und pflegen"
|
||||
- "Definition der Betriebsprozesse & Arbeitsanweisungen"
|
||||
- "Sicherstellen, dass Rollen, Eskalationswege und Kommunikationsregeln klar sind"
|
||||
- "Bereitstellen der notwendigen Informationen für die Betriebsführung (z.B. Standard Changes, Known Errors, Konfigurationsvorgaben)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Trägt die inhaltliche Verantwortung für funktionale Vorgaben"
|
||||
- rolle: operations_manager
|
||||
raci: R
|
||||
kontext: "Führt aus, pflegt das Handbuch, operationalisiert Vorgaben"
|
||||
- rolle: spm
|
||||
raci: C/I
|
||||
kontext: "Prüft Portfolio-Konsistenz"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_03
|
||||
name: "Durchführen laufender Betriebsaufgaben"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_02"
|
||||
|
||||
beschreibung: >
|
||||
Dies sind die täglich wiederkehrenden Betriebsaktivitäten, die zur
|
||||
Erbringung des Services notwendig sind.
|
||||
|
||||
umfasst:
|
||||
- "Benutzerverwaltung & Berechtigungen"
|
||||
- "Backup/Restore"
|
||||
- "Technische Routineaufgaben"
|
||||
- "Konfigurationspflege"
|
||||
- "Pflege von Logs, Diensten und Überwachungsobjekten"
|
||||
- "Einhaltung der Security- und Compliance-Anforderungen"
|
||||
- "Umsetzung freigegebener Standard-Changes"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: operations_manager
|
||||
raci: A
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Primär ausführend"
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
kontext: "Fachliche Steuerung"
|
||||
- rolle: lieferant
|
||||
raci: C/I
|
||||
kontext: "Wenn ausgelagerte Komponenten"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Transparenz im Portfolio"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_04
|
||||
name: "Ressourcen, Dienstleister und Budget managen"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_03"
|
||||
|
||||
beschreibung: >
|
||||
Die Aktivität stellt sicher, dass der Servicebetrieb über die notwendigen
|
||||
Mittel verfügt, damit der Service stabil und wirtschaftlich erbracht
|
||||
werden kann.
|
||||
|
||||
umfasst:
|
||||
- "Sicherstellen, dass ausreichende personelle und technische Ressourcen für den Betrieb verfügbar sind"
|
||||
- "Koordination mit externen Dienstleistern hinsichtlich vereinbarter Leistungen"
|
||||
- "Überwachung des laufenden Betriebsbudgets und Kontrolle relevanter Kosten"
|
||||
- "Abstimmung mit Supplier-, Finanz- und Vertragsmanagement bei Abweichungen"
|
||||
- "Sicherstellen, dass notwendige Betriebsleistungen (z.B. Wartung, Bereitstellung von Lizenzen) erbracht werden"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: operations_manager
|
||||
raci: A
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Steuert Ressourcen, überwacht Dienstleisterleistungen und kontrolliert Budgetverbrauch"
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
kontext: "Definiert Bedarf, priorisiert Maßnahmen und bewertet Auswirkungen auf die Servicequalität"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Erhält Informationen zu Ressourcen-, Lieferanten- und Budgetlage für Portfolioentscheidungen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_05
|
||||
name: "Überwachen der Services"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_04"
|
||||
|
||||
beschreibung: >
|
||||
Strukturierte Überwachung des Services anhand definierter KPIs und Metriken.
|
||||
|
||||
umfasst:
|
||||
- "Überwachen der Verfügbarkeit, Performance, Auslastung"
|
||||
- "Überwachen der Schnittstellen und Konfigurationsobjekte"
|
||||
- "Identifikation von Trends oder drohenden Störungen"
|
||||
- "Verknüpfung mit Events, Alerts, Dashboards"
|
||||
- "Erstellen von Monitoring-Regeln im Betrieb"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: operations_manager
|
||||
raci: A
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Laufendes Monitoring"
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
kontext: "Definiert Metriken und Schwellenwerte"
|
||||
- rolle: service_support_team
|
||||
raci: I
|
||||
kontext: "Reagiert auf Alarme in Ticketprozessen"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Erhält konsolidierte Daten für Portfolio-Steuerung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_06
|
||||
name: "Erstellen des Service-Qualitätsbericht"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_05"
|
||||
|
||||
beschreibung: >
|
||||
Regelmäßige Erstellung formaler Berichte über die erreichte Servicequalität.
|
||||
|
||||
umfasst:
|
||||
- "SLA-/SLO-Auswertung"
|
||||
- "Auswertung technischer KPIs (Verfügbarkeit, Response Time etc.)"
|
||||
- "Abgleich gegen definierte Qualitätsziele"
|
||||
- "Identifikation von Verbesserungspotenzialen"
|
||||
- "Zuarbeit für Service Review & SPM"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Ist verantwortlich für Interpretation & Freigabe des Berichts"
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Technische Daten sammeln, aufbereiten"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Nutzt die Daten für Portfolio-Steuerung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: op_07
|
||||
name: "Proaktive Problem Identifikation"
|
||||
typ: aktivitaet
|
||||
ehemals: "sb_06"
|
||||
|
||||
beschreibung: >
|
||||
Dies geht über Monitoring hinaus und ist die aktive Suche nach
|
||||
strukturellen Problemen.
|
||||
|
||||
umfasst:
|
||||
- "Trendanalysen aus Monitoringdaten"
|
||||
- "Analyse von Engpässen, Ressourcenproblemen"
|
||||
- "Technische Analyse von Systemmustern"
|
||||
- "Erkennen potenzieller SLA-Verletzungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Fachliche Priorisierung der Problemfelder"
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Führt die proaktive Analyse durch"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Für strukturelle Portfolio-Entscheidungen"
|
||||
|
|
@ -0,0 +1,268 @@
|
|||
metadata:
|
||||
name: "Review"
|
||||
yasm_referenz: "LP5: Improve the services"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Periodische und anlassbezogene Bewertung der Service-Performance.
|
||||
Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung
|
||||
von Verbesserungsmaßnahmen bis hin zur Stilllegung.
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review"
|
||||
zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt.
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2025-12-17"
|
||||
beschreibung: |
|
||||
- Referenz auf spm_konzept_service-review.yaml hinzugefügt
|
||||
- Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001)
|
||||
- Output-Präzisierung für Handlungsempfehlungen ergänzt
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-11-26"
|
||||
beschreibung: "Initiale Erstellung"
|
||||
|
||||
referenzen:
|
||||
konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Operation"
|
||||
artefakt: "Service-Qualitätsbericht, Monitoring-Daten"
|
||||
- quelle: "Support"
|
||||
artefakt: "Support-KPIs, Problem Records, Incident-Trends"
|
||||
ausgang:
|
||||
- ziel: "Operation"
|
||||
artefakt: "Freigegebene Verbesserungsmaßnahmen"
|
||||
bedingung: "Bei Service Improvement"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Demand für strukturelle Änderung"
|
||||
bedingung: "Bei Service Redesign / Erweiterung"
|
||||
- ziel: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan, Decommissioning-Auftrag"
|
||||
bedingung: "Bei Service außer Betrieb nehmen"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_01
|
||||
name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_01"
|
||||
|
||||
beschreibung: >
|
||||
Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs,
|
||||
um mittelfristige Verbesserungen anzustoßen.
|
||||
|
||||
umfasst:
|
||||
- "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)"
|
||||
- "Identifikation wiederkehrender Tickets und systemischer Ursachen"
|
||||
- "Abgleich mit Problem Records"
|
||||
- "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Priorisiert und bestätigt Maßnahmen"
|
||||
- rolle: problem_manager
|
||||
raci: R
|
||||
kontext: "Führt taktische Analyse durch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_02
|
||||
name: "Service Performance & Improvement Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_02"
|
||||
|
||||
beschreibung: >
|
||||
Operativer Review des Servicezustands basierend auf Qualitätsberichten,
|
||||
Supportdaten und Problem-Analysen.
|
||||
|
||||
konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
methodik:
|
||||
beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung"
|
||||
dimensionen:
|
||||
- "SR-D1: Leistungserbringung"
|
||||
- "SR-D2: Betriebsstabilität"
|
||||
- "SR-D3: Nutzerzufriedenheit"
|
||||
- "SR-D4: Zukunftsfähigkeit"
|
||||
bewertungsskala: "Grün / Gelb / Rot"
|
||||
|
||||
umfasst:
|
||||
- "Abgleich der Service-Leistung gegen Ziele und SLAs"
|
||||
- "Bewertung des Gesamterfüllungsgrades der Serviceerbringung"
|
||||
- "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe"
|
||||
- "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)"
|
||||
- "Vorbereitung für SOR-Review"
|
||||
- "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist"
|
||||
|
||||
output_praezisierung:
|
||||
handlungsempfehlung:
|
||||
optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"]
|
||||
dokumentation: "Service-Definition -> service_review"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Review durch"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_03
|
||||
name: "SOR: Periodischer Service Review"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_03"
|
||||
|
||||
beschreibung: >
|
||||
Die SOR bewertet regelmäßig die Serviceleistung und trifft operative
|
||||
Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Sichtung des Service Performance & Improvement Reviews"
|
||||
- "Bewertung der Stabilität & Betriebsreife"
|
||||
- "Priorisierung operativer Verbesserungen"
|
||||
- "Freigabe kleinerer Verbesserungsmaßnahmen"
|
||||
- "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist"
|
||||
- "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Trifft Entscheidungen"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Berichtet & präsentiert"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: ep_weiter
|
||||
name: "Weiter wie bisher"
|
||||
bedingung: "Service stabil, keine Maßnahmen erforderlich"
|
||||
ziel_aktivitaet: null
|
||||
ziel_phase: "Operation"
|
||||
|
||||
- id: ep_improvement
|
||||
name: "Verbesserung nötig (klein)"
|
||||
bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung"
|
||||
ziel_aktivitaet: "rv_04"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_redesign
|
||||
name: "Strukturelle Überarbeitung nötig"
|
||||
bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht"
|
||||
ziel_aktivitaet: "rv_05"
|
||||
ziel_phase: null
|
||||
|
||||
- id: ep_retirement
|
||||
name: "Service End-of-Life"
|
||||
bedingung: "Service soll stillgelegt werden"
|
||||
ziel_aktivitaet: "rv_06"
|
||||
ziel_phase: null
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_04
|
||||
name: "Service Improvement"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_04"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Planung und Steuerung von kleineren
|
||||
Verbesserungsmaßnahmen innerhalb des Service.
|
||||
|
||||
umfasst:
|
||||
- "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen"
|
||||
- "Aufwandsschätzung und Priorisierung"
|
||||
- "Festlegen der Zielmetriken für Verbesserung"
|
||||
- "Zuweisung der Verantwortlichkeiten"
|
||||
- "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A/R
|
||||
kontext: "Führt Improvements, steuert Maßnahmen"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Für portfolio-relevante Anpassungen"
|
||||
- rolle: problem_manager
|
||||
raci: C
|
||||
kontext: "Für Problem-bezogene Maßnahmen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Operation"
|
||||
beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_05
|
||||
name: "Service Redesign / Erweiterung"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_05"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service
|
||||
auf Basis von SOR- oder Review-Entscheidungen.
|
||||
|
||||
umfasst:
|
||||
- "Überarbeitung der Service-Definitionen"
|
||||
- "Anpassung von Komponenten, Prozessen oder Rollen"
|
||||
- "Identifikation von Anforderungen für Entwicklungsprozess"
|
||||
- "Übergabe an Demand-Lifecycle-Prozess"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Redesign"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Anpassungen"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Neuer Demand"
|
||||
beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: rv_06
|
||||
name: "Service außer Betrieb nehmen"
|
||||
typ: aktivitaet
|
||||
ehemals: "sr_06"
|
||||
|
||||
beschreibung: >
|
||||
Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.
|
||||
|
||||
umfasst:
|
||||
- "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)"
|
||||
- "Bewertung durch SOR"
|
||||
- "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)"
|
||||
- "Koordination mit Portfolio (SPM)"
|
||||
- "Übergabe an Projekt-/Transitionsthemen falls notwendig"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Entscheidet"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Führt Retire-Plan aus"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Aktualisiert Portfolio"
|
||||
|
||||
ausgang:
|
||||
ziel_phase: "Demand-Lifecycle (DPM)"
|
||||
artefakt: "Retirement-Plan / Decommissioning-Auftrag"
|
||||
beschreibung: "Stilllegung wird als Demand/Projekt koordiniert"
|
||||
|
|
@ -0,0 +1,367 @@
|
|||
metadata:
|
||||
name: "Support"
|
||||
yasm_referenz: "LP4: Operate the services (LP4.6-LP4.7)"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Bearbeitung von Nutzeranfragen und Incidents im 1st/2nd Level,
|
||||
Wissensmanagement, Problemerkennung und Root-Cause-Analyse.
|
||||
Bindeglied zwischen Anwendern, Betrieb und Problemmanagement.
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Support"
|
||||
zu "Support". Aktivitäts-IDs von ss_ auf sp_ umgestellt.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-11-26"
|
||||
beschreibung: "Initiale Erstellung"
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Transition"
|
||||
artefakt: "Aktivierter Service"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_11)"
|
||||
- quelle: "Nutzer/Anwender"
|
||||
artefakt: "Incidents, Service Requests"
|
||||
- quelle: "Operation"
|
||||
artefakt: "Alerts, Events"
|
||||
ausgang:
|
||||
- ziel: "Review"
|
||||
artefakt: "Support-KPIs, Incident-Trends"
|
||||
- ziel: "Transition"
|
||||
artefakt: "Change-Bedarf aus Problem Records"
|
||||
|
||||
# =============================================================================
|
||||
# ARTEFAKTE
|
||||
# =============================================================================
|
||||
|
||||
artefakte:
|
||||
|
||||
- id: problem_record
|
||||
name: "Problem Record"
|
||||
beschreibung: >
|
||||
Der zentrale Container für alle Erkenntnisse der Problembehandlung.
|
||||
inhalte:
|
||||
- "Beschreibung des Problems"
|
||||
- "Bekannte Workarounds"
|
||||
- "Symptome und Diagnosewege"
|
||||
- "Ursache (Root Cause), wenn gefunden"
|
||||
- "Change-Bedarf"
|
||||
- "Statusverfolgung und Priorisierung"
|
||||
verantwortung:
|
||||
- rolle: problem_manager
|
||||
raci: A
|
||||
- rolle: second_level_agent
|
||||
raci: R
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_01
|
||||
name: "Bereitstellen von Leitlinien für den Service-Support"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_01"
|
||||
|
||||
beschreibung: >
|
||||
Dies umfasst das Bereitstellen aller strukturellen Rahmenbedingungen,
|
||||
damit Service-Support effizient arbeiten kann.
|
||||
|
||||
umfasst:
|
||||
- "Definition von Unterstützungsprozessen (z.B. Incident-Modell, Request-Modell)"
|
||||
- "Vorgaben zu Eskalationen, Reaktionszeiten, Rollen"
|
||||
- "Festlegung von Tool-Konfigurationen (Ticketklassen, Kategorien, Templates)"
|
||||
- "Definition der Zugriffsmöglichkeiten (Remote-Zugänge, Adminrechte, Security-Policies)"
|
||||
- "Sicherstellen eines konsistenten Wissensmanagements"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet fachliche Vorgaben"
|
||||
- rolle: support_manager
|
||||
raci: R
|
||||
kontext: "Führt aus, pflegt Leitlinien"
|
||||
- rolle: spm
|
||||
raci: C/I
|
||||
kontext: "Einbindung bei Portfolio-Relevanz"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_02
|
||||
name: "Wissensdatenbank"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_02"
|
||||
|
||||
beschreibung: >
|
||||
Ein strukturierter, gepflegter Wissensspeicher für Support-Lösungen,
|
||||
Betriebsinfos, Workarounds, Standardanfragen.
|
||||
|
||||
umfasst:
|
||||
- "Speichern von Lösungen zu Incidents"
|
||||
- "Dokumentation von Workarounds (vom Problem Management)"
|
||||
- "FAQ, Standard-Requests, Benutzeranleitungen"
|
||||
- "Pflege & Aktualisierung bei Bedarf"
|
||||
- "Bereitstellen als zentrales Arbeitsmittel für 1st & 2nd Level Support"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_support_team
|
||||
raci: R
|
||||
kontext: "Pflegen Inhalte"
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet fachliche Richtigkeit"
|
||||
- rolle: problem_manager
|
||||
raci: C
|
||||
kontext: "Liefert Workarounds / Known Errors"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_03
|
||||
name: "Überwachen / Verteilung von Incidents und Service Requests"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_03"
|
||||
|
||||
beschreibung: >
|
||||
Koordination der eingehenden Störungen/Anfragen, Priorisierung, Routing
|
||||
und Sicherstellen, dass Tickets korrekt aufgenommen und an zuständige
|
||||
Teams verteilt werden. Ticket-Queue Koordination.
|
||||
|
||||
umfasst:
|
||||
- "Sichtung neuer Tickets"
|
||||
- "Automatisches Routing über Regeln oder manuelles Routing"
|
||||
- "Prioritäts- und Impact-Bewertung"
|
||||
- "Sicherstellung von SLA-Konformität (Reaktionszeiten)"
|
||||
- "Eskalation bei Bedarf (funktional/zeitlich)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: queue_koordinator
|
||||
raci: R
|
||||
kontext: "Erledigt initiale Sichtung & Routing"
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
kontext: "Organisatorische Verantwortung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_04
|
||||
name: "Bearbeiten von Requests"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_04"
|
||||
|
||||
beschreibung: >
|
||||
Behandlung aller Standard-Serviceanfragen von Nutzern
|
||||
(z.B. Passwort zurücksetzen, Berechtigungen, Informationen).
|
||||
|
||||
umfasst:
|
||||
- "Klassifizierung und Bearbeitung gemäß Request-Katalog"
|
||||
- "Prüfung von Berechtigungen"
|
||||
- "Erfüllung standardisierter Anfragen"
|
||||
- "Dokumentation der Erledigung"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: first_level_agent
|
||||
raci: R
|
||||
kontext: "Bearbeitet einfache Standard-Requests"
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
kontext: "Verantwortet Qualität & Prozess"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_05
|
||||
name: "Lösen von Incidents im 1st Level Support"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_05"
|
||||
|
||||
beschreibung: >
|
||||
Schnelle Lösung typischer Störungen, die mit bekanntem Wissen
|
||||
gelöst werden können.
|
||||
|
||||
umfasst:
|
||||
- "Erstdiagnose"
|
||||
- "Nutzung der Wissensdatenbank"
|
||||
- "Anwenderunterstützung"
|
||||
- "Workarounds anwenden"
|
||||
- "Dokumentieren der Lösung"
|
||||
- "Entscheidung, ob Weiterleitung an 2nd Level nötig ist"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: first_level_agent
|
||||
raci: R
|
||||
kontext: "Führt aus"
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
kontext: "Stellt Leitlinien & Qualität sicher"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_06
|
||||
name: "Lösen von Incidents im 2nd Level Support"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_06"
|
||||
|
||||
beschreibung: >
|
||||
Bearbeitung aller Incidents, die nicht im 1st Level lösbar sind;
|
||||
tiefergehende Diagnostik und technische Lösung.
|
||||
|
||||
umfasst:
|
||||
- "Komplexe technische Diagnosen"
|
||||
- "Enge Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten"
|
||||
- "Ggf. Einbezug Spezialisten oder Hersteller"
|
||||
- "Rückmeldung an 1st Level / Anwender"
|
||||
- "Dokumentation der Lösung"
|
||||
- "Entscheidung, ob Incident ungelöst → Problem Record"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: second_level_agent
|
||||
raci: R
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
- rolle: lieferant
|
||||
raci: C
|
||||
kontext: "Bei externen Komponenten"
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
kontext: "Informiert über schwerwiegende Incidents"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_07
|
||||
name: "Incident Record (Gelöst) / Request Record (Gelöst)"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_07"
|
||||
|
||||
beschreibung: >
|
||||
Abschluss der Bearbeitung eines Tickets inklusive Dokumentation
|
||||
und Qualitätssicherung.
|
||||
|
||||
umfasst:
|
||||
- "Validierung, ob Problem wirklich gelöst"
|
||||
- "Kommunikation an den Endnutzer"
|
||||
- "Aktualisieren der Dokumentationen / FAQs"
|
||||
- "Klassifikation für Trendanalysen"
|
||||
- "Übergabe an 'Schließen von Incidents'"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: first_level_agent
|
||||
raci: R
|
||||
- rolle: second_level_agent
|
||||
raci: R
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_08
|
||||
name: "Schließen von Incidents & Service Requests"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_08"
|
||||
|
||||
beschreibung: >
|
||||
Finaler Ticketabschluss inkl. Dokumentation, Reporting und
|
||||
Einordnung für spätere Verbesserungen.
|
||||
|
||||
umfasst:
|
||||
- "Ticket final schließen"
|
||||
- "Prüfung vollständiger Dokumentation"
|
||||
- "Ticketklassifizierung / Zuordnung von KPIs"
|
||||
- "Rückmeldung an Monitoring/Reporting"
|
||||
- "Identifikation wiederkehrender Incidents"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: first_level_agent
|
||||
raci: R
|
||||
- rolle: second_level_agent
|
||||
raci: R
|
||||
- rolle: support_manager
|
||||
raci: A
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_09
|
||||
name: "Anlegen Problem Record für nicht lösbare Incidents"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_09"
|
||||
|
||||
beschreibung: >
|
||||
Wenn ein Incident auch im 2nd Level nicht lösbar ist, wird eine
|
||||
strukturelle Ursache vermutet.
|
||||
|
||||
umfasst:
|
||||
- "'Nicht lösbar'-Entscheidung"
|
||||
- "Dokumentation der Symptome"
|
||||
- "Eröffnen eines Problem Records"
|
||||
- "Übergabe an Root-Cause-Analyse"
|
||||
|
||||
erzeugt:
|
||||
- artefakt: problem_record
|
||||
|
||||
mitarbeit:
|
||||
- rolle: second_level_agent
|
||||
raci: R
|
||||
- rolle: problem_manager
|
||||
raci: A
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_10
|
||||
name: "Wiederkehrende Incidents analysieren & Problem Record anlegen"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_10"
|
||||
|
||||
beschreibung: >
|
||||
Ein reaktiver Weg, Probleme strukturiert zu erkennen, wenn dieselbe
|
||||
Störung mehrfach auftritt.
|
||||
|
||||
umfasst:
|
||||
- "Clustering wiederkehrender Incidents"
|
||||
- "Analyse möglicher gemeinsamer Ursachen"
|
||||
- "Entscheidung: Problem Record notwendig"
|
||||
- "Übergabe an Problem Management"
|
||||
|
||||
erzeugt:
|
||||
- artefakt: problem_record
|
||||
|
||||
mitarbeit:
|
||||
- rolle: support_manager
|
||||
raci: R
|
||||
- rolle: problem_manager
|
||||
raci: A
|
||||
- rolle: second_level_agent
|
||||
raci: C
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: sp_11
|
||||
name: "Operative Root-Cause-Analyse durchführen & Workaround bereitstellen"
|
||||
typ: aktivitaet
|
||||
ehemals: "ss_11"
|
||||
|
||||
beschreibung: >
|
||||
Start der Problembehandlung zur Identifikation der eigentlichen
|
||||
Ursache und Schaffung eines Workarounds.
|
||||
|
||||
umfasst:
|
||||
- "Root-Cause-Analyse"
|
||||
- "Erstellen eines Workarounds"
|
||||
- "Eintrag in die Wissensdatenbank"
|
||||
- "Entscheidung über Change-Bedarf"
|
||||
|
||||
aktualisiert:
|
||||
- artefakt: problem_record
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: problem_manager
|
||||
raci: R
|
||||
- rolle: second_level_agent
|
||||
raci: C
|
||||
- rolle: lieferant
|
||||
raci: C/I
|
||||
|
|
@ -0,0 +1,578 @@
|
|||
metadata:
|
||||
name: "Transition"
|
||||
yasm_referenz: "LP3: Build new or changed services"
|
||||
version: "2.0"
|
||||
status: "draft"
|
||||
erstellt: "2026-01-30"
|
||||
aktualisiert: "2026-02-18"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Technische Realisierung und Überführung des Services in den produktiven
|
||||
Betrieb. Umfasst Entry-Gate (Gate 1), Build/Konfiguration, Test,
|
||||
Deployment und Go-Live-Freigabe.
|
||||
|
||||
Diese Phase konsolidiert die ehemaligen Phasen "Service Entwicklung" und
|
||||
"Service Transition" und entspricht YASM LP3 (Build new or changed services).
|
||||
|
||||
aenderungen:
|
||||
- version: "2.0"
|
||||
datum: "2026-02-18"
|
||||
beschreibung: >
|
||||
Gate 1 aus Design-Phase hierher verschoben als tr_01 (Entry-Gate der
|
||||
Transition). Alle Aktivitäts-IDs um +1 verschoben: ehemals tr_01-tr_11
|
||||
wird zu tr_02-tr_12. Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist
|
||||
nun tr_12 (ehemals tr_11). Die Transition-Phase enthält nun alle 3 Gates.
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2026-01-30"
|
||||
beschreibung: >
|
||||
Konsolidierung auf 5-Phasen-Modell: Zusammenführung von
|
||||
"Service Entwicklung" (se_01-se_07) und "Service Transition" (st_01-st_04)
|
||||
zu einer Phase "Transition" (tr_01-tr_11). Gate 2 (Entry-Prüfung) und
|
||||
Gate 3 (Go-Live-Freigabe) integriert. ELS verschoben nach Operation.
|
||||
|
||||
schnittstellen:
|
||||
eingang:
|
||||
- quelle: "Design"
|
||||
artefakt: "Service Design Document + Implementation Blueprint"
|
||||
trigger: "Abschluss der Design-Phase (ds_04)"
|
||||
ausgang:
|
||||
- ziel: "Operation"
|
||||
artefakt: "Aktivierter Service"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_12)"
|
||||
- ziel: "Support"
|
||||
artefakt: "Aktivierter Service mit Support-Dokumentation"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_12)"
|
||||
|
||||
hinweis: >
|
||||
Die Transition-Phase enthält drei Gates: Gate 1 (tr_01) als Entry-Gate,
|
||||
Gate 2 (tr_09) prüft die Übergabefähigkeit nach dem Build, Gate 3 (tr_12)
|
||||
gibt den Go-Live frei. Early Life Support (ELS) wurde in die Operation-Phase
|
||||
verschoben.
|
||||
|
||||
# =============================================================================
|
||||
# GATE 1: ENTRY-GATE (TRANSITION ENTRY)
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_01
|
||||
name: "Gate 1: Entwicklung oder Konfiguration?"
|
||||
typ: gate
|
||||
gate_nummer: 1
|
||||
yasm_referenz: "LP3 Entry Gate"
|
||||
ehemals: "ds_05"
|
||||
|
||||
beschreibung: >
|
||||
Entscheidung, ob die Service-Komponenten entwickelt oder nur
|
||||
konfiguriert werden müssen. Dies ist Gate 1 im Service-Lifecycle:
|
||||
das Entry-Gate der Transition-Phase.
|
||||
|
||||
WICHTIG: Diese Entscheidung erfordert SOR-Approval, da sie Budget-
|
||||
und Ressourcenimplikationen hat.
|
||||
|
||||
umfasst:
|
||||
- "Aufwandsschätzung (Build vs. Configure)"
|
||||
- "Bewertung technischer Risiken"
|
||||
- "Budget-Abgleich"
|
||||
- "ggf. Lieferanten-Einbindung (Beschaffung)"
|
||||
- "SOR-Vorlage für Gate-Freigabe"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: entwicklung
|
||||
name: "Entwicklung"
|
||||
beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich"
|
||||
folgeaktivitaet: tr_02
|
||||
governance: "SOR-Approval erforderlich"
|
||||
|
||||
- id: konfiguration
|
||||
name: "Konfiguration"
|
||||
beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst"
|
||||
folgeaktivitaet: tr_05
|
||||
governance: "SOR-Approval erforderlich"
|
||||
hinweis: "Überspringt Entwicklungsaktivitäten (tr_02-tr_04), startet direkt bei Konfiguration"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Freigabe-Entscheidung für Eintritt in Transition"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Antragsteller und fachliche Empfehlung"
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
kontext: "Aufwandsschätzung und Ressourcenplanung"
|
||||
- rolle: architektur
|
||||
raci: R
|
||||
kontext: "Technische Bewertung"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Portfolio-Perspektive"
|
||||
- rolle: lieferant
|
||||
raci: I
|
||||
kontext: "Information für Beschaffungsplanung"
|
||||
|
||||
pruef_dimensionen:
|
||||
- id: g1_dim_01
|
||||
name: "Design-Vollständigkeit"
|
||||
beschreibung: "Ist das Service Design Document vollständig und schlüssig?"
|
||||
showstopper: true
|
||||
|
||||
- id: g1_dim_02
|
||||
name: "Budget-Verfügbarkeit"
|
||||
beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?"
|
||||
showstopper: true
|
||||
|
||||
- id: g1_dim_03
|
||||
name: "Projektressourcen"
|
||||
beschreibung: "Können Ressourcen (intern/extern) für die Transition mobilisiert werden?"
|
||||
showstopper: true
|
||||
|
||||
- id: g1_dim_04
|
||||
name: "Betriebs- und Support-Bereitschaft"
|
||||
beschreibung: >
|
||||
Haben Betrieb und Support grundsätzlich die Kapazität und Bereitschaft,
|
||||
diesen Service nach Abschluss der Transition zu übernehmen?
|
||||
|
||||
WICHTIG: Dies ist eine prinzipielle Prüfung VOR Beginn der Transition.
|
||||
Ohne grundsätzliches Commitment darf die Transition nicht starten,
|
||||
da sonst Ressourcen für einen Service aufgewendet werden, der nicht
|
||||
betrieben werden kann.
|
||||
|
||||
Die operative Bestätigung (konkreter Termin, Personal eingeplant)
|
||||
erfolgt an Gate 3.
|
||||
showstopper: true
|
||||
werte:
|
||||
- "bestaetigt"
|
||||
- "unter_vorbehalt"
|
||||
- "nicht_gegeben"
|
||||
hinweis: "Bei 'nicht_gegeben' ist Gate 1 nicht passierbar."
|
||||
|
||||
- id: g1_dim_05
|
||||
name: "Risikobewertung"
|
||||
beschreibung: "Sind Risiken identifiziert und bewertet?"
|
||||
showstopper: false
|
||||
|
||||
governance_hinweis: >
|
||||
Die SOR-Freigabe an Gate 1 stellt sicher, dass:
|
||||
1. Das Design vollständig und schlüssig ist
|
||||
2. Budget für die gewählte Implementierungsstrategie verfügbar ist
|
||||
3. Ressourcen (intern/extern) für Transition mobilisiert werden können
|
||||
4. Betrieb und Support grundsätzlich zur Übernahme bereit sind
|
||||
5. Risiken identifiziert und bewertet sind
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – BUILD (ehemals Service Entwicklung)
|
||||
# =============================================================================
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_02
|
||||
name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.1: Coordinate build and acquisition activities"
|
||||
ehemals: "se_01 / tr_01"
|
||||
|
||||
beschreibung: >
|
||||
Steuern der Entwicklungsaktivitäten im Projekt.
|
||||
|
||||
umfasst:
|
||||
- "Abstimmung mit Lieferanten"
|
||||
- "Ressourcenplanung"
|
||||
- "Termin- und Budgetnachführung"
|
||||
- "Sicherstellung von Change-Kontrollen"
|
||||
- "Definition von Build- und Konfigurationspaketen"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: projektleitung
|
||||
raci: A
|
||||
- rolle: architektur
|
||||
raci: C
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
- rolle: lieferant
|
||||
raci: C/I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_03
|
||||
name: "Entwickeln von Anwendungen und Systemen"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.2: Develop applications and systems"
|
||||
ehemals: "se_02 / tr_02"
|
||||
|
||||
beschreibung: >
|
||||
Realisierung der technischen Service-Komponenten.
|
||||
|
||||
umfasst:
|
||||
- "Softwareentwicklung"
|
||||
- "Customizing"
|
||||
- "Schnittstellenentwicklung"
|
||||
- "Infrastrukturaufbau"
|
||||
- "Versionierung & Dokumentation"
|
||||
- "Testdaten & Migrationspfade vorbereiten"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
kontext: "Interne Entwicklung"
|
||||
- rolle: lieferant
|
||||
raci: R
|
||||
kontext: "Externe Entwicklung"
|
||||
- rolle: projektleitung
|
||||
raci: A
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
- rolle: architektur
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_04
|
||||
name: "Entgegennehmen der Service-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.3: Accept service components"
|
||||
ehemals: "se_03 / tr_03"
|
||||
|
||||
beschreibung: >
|
||||
Qualitätssicherung beim Übergang vom Entwicklungs- zur Testphase.
|
||||
|
||||
umfasst:
|
||||
- "Eingangskontrolle"
|
||||
- "Prüfung von Vollständigkeit / Qualität"
|
||||
- "Sicherstellung der Dokumentationen"
|
||||
- "Übergabe an Testmanagement"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
- rolle: testmanagement
|
||||
raci: R
|
||||
- rolle: lieferant
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_05
|
||||
name: "Konfiguration der Service-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.4: Configure service components"
|
||||
ehemals: "se_04 / tr_04"
|
||||
|
||||
beschreibung: >
|
||||
Einrichtung der Konfigurationsparameter, Settings, Rollen, Zugänge.
|
||||
|
||||
umfasst:
|
||||
- "Setup von Parametern, Policies, Templates"
|
||||
- "Toolkonfiguration (ITSM-Systeme, Monitoring)"
|
||||
- "Anpassung bestehender Komponenten"
|
||||
- "Verknüpfung mit Service-Katalog / Portfolio"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
|
||||
hinweis: >
|
||||
Diese Aktivität wird bei Gate-1-Entscheidung "Konfiguration"
|
||||
als Einstiegspunkt verwendet (überspringt tr_02-tr_04).
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_06
|
||||
name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.5: Document the services"
|
||||
ehemals: "se_05 / tr_05"
|
||||
|
||||
beschreibung: >
|
||||
Alle Betriebsunterlagen werden erstellt oder aktualisiert.
|
||||
|
||||
umfasst:
|
||||
- "Service Operation Manual"
|
||||
- "Supportanleitungen"
|
||||
- "Monitoring-Spezifikationen"
|
||||
- "Eskalationswege"
|
||||
- "Standard Changes"
|
||||
- "Konfigurations-/Betriebsrichtlinien"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: projektteam
|
||||
raci: R
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_07
|
||||
name: "Testen der Service-Komponenten"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.6: Test the services"
|
||||
ehemals: "se_06 / tr_06"
|
||||
|
||||
beschreibung: >
|
||||
Verifizierung, dass alle Servicekomponenten funktionsfähig und
|
||||
bereit für den Betrieb sind.
|
||||
|
||||
umfasst:
|
||||
- "Funktionstests"
|
||||
- "Integrationstests"
|
||||
- "Abnahmetests"
|
||||
- "Nachweis der Betriebsreife"
|
||||
- "Testprotokolle & Freigaben"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: testmanagement
|
||||
raci: R
|
||||
- rolle: projektleitung
|
||||
raci: A
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
- rolle: lieferant
|
||||
raci: C/I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_08
|
||||
name: "Formale Übergabe (Build abgeschlossen)"
|
||||
typ: aktivitaet
|
||||
yasm_referenz: "LP3.7: Prepare for service activation"
|
||||
ehemals: "se_07 / tr_07"
|
||||
|
||||
beschreibung: >
|
||||
Der Build ist abgeschlossen. Alle Artefakte werden für die
|
||||
Entry-Prüfung (Gate 2) bereitgestellt.
|
||||
|
||||
umfasst:
|
||||
- "Bereitstellung aller Betriebsunterlagen"
|
||||
- "Bereitstellung der Testprotokolle"
|
||||
- "Dokumentierter Übergabe-Termin"
|
||||
- "Vorbereitung Gate-2-Antrag"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: projektleitung
|
||||
raci: A
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Fachliche Freigabe"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Für Portfolio-Aktualisierung"
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
kontext: "Übernahmebereitschaft prüfen"
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
kontext: "Support-Bereitschaft prüfen"
|
||||
|
||||
# =============================================================================
|
||||
# GATE 2: ENTRY-PRÜFUNG
|
||||
# =============================================================================
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_09
|
||||
name: "Gate 2: Entry-Prüfung nach Build"
|
||||
typ: gate
|
||||
gate_nummer: 2
|
||||
ehemals: "tr_08"
|
||||
|
||||
beschreibung: >
|
||||
Validierung der Übergabefähigkeit nach Abschluss des Builds.
|
||||
Der Service Owner prüft, ob alle Voraussetzungen für die
|
||||
Deploy-Aktivitäten erfüllt sind.
|
||||
|
||||
Dies ist eine SO-Einzelentscheidung (keine Gremienentscheidung).
|
||||
|
||||
umfasst:
|
||||
- "Prüfung der Übergabe-Vollständigkeit (alle Artefakte vorhanden)"
|
||||
- "Prüfung des Abnahme-Status (Auftraggeber-Abnahme liegt vor)"
|
||||
- "Ressourcen-Outlook (Betrieb und Support prinzipiell vorbereitet)"
|
||||
- "Pilot-Entscheidung (falls erforderlich)"
|
||||
- "Dokumentation im Transition-Steckbrief"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: freigabe
|
||||
name: "Freigabe"
|
||||
beschreibung: "Weiter zu Deploy-Aktivitäten"
|
||||
folgeaktivitaet: tr_10
|
||||
|
||||
- id: freigabe_mit_auflagen
|
||||
name: "Freigabe mit Auflagen"
|
||||
beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden"
|
||||
folgeaktivitaet: tr_10
|
||||
|
||||
- id: zurueck
|
||||
name: "Zurück an Build"
|
||||
beschreibung: "Nachbesserung erforderlich"
|
||||
folgeaktivitaet: tr_02
|
||||
hinweis: "Je nach Mängelart kann auch bei tr_05-tr_07 eingestiegen werden"
|
||||
|
||||
- id: ablehnung
|
||||
name: "Ablehnung"
|
||||
beschreibung: "Endgültige Ablehnung des Service-Vorhabens"
|
||||
folgeaktivitaet: null
|
||||
hinweis: "Erfordert SOR-Eskalation"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Gate-Keeper"
|
||||
- rolle: projektleitung
|
||||
raci: R
|
||||
kontext: "Liefert Übergabe-Nachweis"
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
kontext: "Bestätigt Übernahmebereitschaft"
|
||||
- rolle: service_support_team
|
||||
raci: C
|
||||
kontext: "Bestätigt Support-Bereitschaft"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Bei Eskalation: Beratung"
|
||||
|
||||
governance_hinweis: >
|
||||
Gate 2 ist eine operative Entscheidung des Service Owners.
|
||||
Bei Unklarheit kann der SO das SPM zur Beratung hinzuziehen.
|
||||
Ablehnung erfordert SOR-Eskalation.
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – DEPLOY (ehemals Service Transition)
|
||||
# =============================================================================
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_10
|
||||
name: "Ausrollen der Service-Komponenten"
|
||||
typ: aktivitaet
|
||||
ehemals: "st_02 / tr_09"
|
||||
|
||||
beschreibung: >
|
||||
Technische Bereitstellung/Deployment des Services in die produktive Umgebung.
|
||||
|
||||
umfasst:
|
||||
- "Deployment von Anwendungen, Systemen, Komponenten"
|
||||
- "Konfiguration produktiver Systeme"
|
||||
- "Migration von Daten"
|
||||
- "Aktivierung von Monitoring"
|
||||
- "Sicherstellen von Zugängen, Rollen, Berechtigungen"
|
||||
- "Schnittstellen-Integration"
|
||||
- "Technische Abnahmetests"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
- rolle: spm
|
||||
raci: C
|
||||
- rolle: lieferant
|
||||
raci: C/I
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_11
|
||||
name: "Vorbereiten der Service-Aktivierung"
|
||||
typ: aktivitaet
|
||||
ehemals: "st_03 / tr_10"
|
||||
|
||||
beschreibung: >
|
||||
Prüfung der Betriebsbereitschaft und Vorbereitung des Go-Live-Antrags
|
||||
für Gate 3.
|
||||
|
||||
umfasst:
|
||||
- "Review der Betriebsdokumentation"
|
||||
- "Prüfung der Überwachungsregeln"
|
||||
- "Prüfung der Rollen- und Eskalationswege"
|
||||
- "Sicherstellen von Zugriffen & Toolanbindung"
|
||||
- "Vorbereitung der Go-Live-Kommunikation"
|
||||
- "Validierung der Service-Funktionalität mit Supportteams"
|
||||
- "Vorbereitung Gate-3-Antrag (SOR-Vorlage)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Fachliche Freigabe"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
|
||||
# =============================================================================
|
||||
# GATE 3: GO-LIVE-FREIGABE
|
||||
# =============================================================================
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: tr_12
|
||||
name: "Gate 3: Go-Live-Freigabe"
|
||||
typ: gate
|
||||
gate_nummer: 3
|
||||
ehemals: "st_01 / tr_11"
|
||||
|
||||
beschreibung: >
|
||||
Portfolio-Freigabe und formale Aktivierung des Services.
|
||||
Die SOR prüft die Betriebsreife aus Portfolio-Perspektive und
|
||||
beschließt die Aufnahme ins Service-Portfolio.
|
||||
|
||||
Dies ist das Exit-Gate aus der Transition-Phase.
|
||||
|
||||
umfasst:
|
||||
- "Prüfung der Portfolio-Konsistenz (strategische Ausrichtung)"
|
||||
- "Prüfung der Betriebsreife (SO-Bestätigung)"
|
||||
- "Prüfung der Support-Bereitschaft"
|
||||
- "Prüfung der SLA/SLO-Vereinbarung"
|
||||
- "Prüfung der Auflagen-Erfüllung aus Gate 2"
|
||||
- "Bewertung der Geschäftskritikalität"
|
||||
- "Beschluss: Go-Live / Go-Live mit Auflagen / Zurück / Ablehnung"
|
||||
- "Formale Aufnahme ins Service-Portfolio"
|
||||
|
||||
entscheidungspfade:
|
||||
- id: go_live
|
||||
name: "Go-Live"
|
||||
beschreibung: "Service wird aktiviert, Übergang zu Operation"
|
||||
folgeaktivitaet: op_01
|
||||
folge_phase: "Operation"
|
||||
|
||||
- id: go_live_mit_auflagen
|
||||
name: "Go-Live mit Auflagen"
|
||||
beschreibung: "Service wird aktiviert, definierte Punkte müssen nachgearbeitet werden"
|
||||
folgeaktivitaet: op_01
|
||||
folge_phase: "Operation"
|
||||
|
||||
- id: zurueck
|
||||
name: "Zurück an Transition"
|
||||
beschreibung: "Nachbesserung erforderlich"
|
||||
folgeaktivitaet: tr_10
|
||||
hinweis: "Je nach Mängelart kann auch bei tr_09 eingestiegen werden"
|
||||
|
||||
- id: ablehnung
|
||||
name: "Ablehnung"
|
||||
beschreibung: "Endgültige Ablehnung des Service-Vorhabens"
|
||||
folgeaktivitaet: null
|
||||
|
||||
mitarbeit:
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Endgültiger Beschluss (Konsent-Verfahren)"
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Antragsteller"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Portfolio-Perspektive"
|
||||
- rolle: projektleitung
|
||||
raci: C
|
||||
- rolle: operations_manager
|
||||
raci: C
|
||||
- rolle: support_manager
|
||||
raci: C
|
||||
|
||||
governance_hinweis: >
|
||||
Gate 3 ist eine SOR-Entscheidung nach dem Konsent-Prinzip.
|
||||
Die SOR-Freigabe bewirkt gleichzeitig:
|
||||
1. Aufnahme ins Service-Portfolio
|
||||
2. Aktivierung des Katalog-Eintrags
|
||||
3. Formale Bestätigung des Service Owners
|
||||
|
|
@ -0,0 +1,407 @@
|
|||
metadata:
|
||||
name: "Rollendefinitionen Service-Lifecycle"
|
||||
version: "1.1"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-31"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
beschreibung: >
|
||||
Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden.
|
||||
Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen.
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.1"
|
||||
datum: "2026-01-31"
|
||||
aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen"
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten"
|
||||
|
||||
# =============================================================================
|
||||
# RACI-Legende (für Referenz in Prozess-YAMLs)
|
||||
# =============================================================================
|
||||
raci_legende:
|
||||
R: "Responsible – führt die Aktivität operativ aus"
|
||||
A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)"
|
||||
C: "Consulted – wird vor Entscheidung/Durchführung einbezogen"
|
||||
I: "Informed – wird über Ergebnis informiert"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENKATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
rollen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GOVERNANCE & STRATEGISCHE STEUERUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
governance:
|
||||
|
||||
- id: spm
|
||||
name: "Service-Portfolio-Manager"
|
||||
kurzbezeichnung: "SPM"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme,
|
||||
Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung,
|
||||
Priorisierung und Wirtschaftlichkeit.
|
||||
verantwortlichkeiten:
|
||||
- "Strategische Portfolio-Steuerung"
|
||||
- "Entscheidungen zu Service-Aufnahme und -Stilllegung"
|
||||
- "Sicherstellung der Wirtschaftlichkeit"
|
||||
- "Portfolio-Konsistenz und Standards"
|
||||
- "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)"
|
||||
- "Identifikation portfolio-uebergreifender Muster aus Reviews"
|
||||
- "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)"
|
||||
- "Vollstaendigkeitspruefung der SOR-Vorlagen"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: sor
|
||||
name: "Service Operations Runde"
|
||||
kurzbezeichnung: "SOR"
|
||||
typ: "Gremium"
|
||||
beschreibung: >
|
||||
Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche
|
||||
Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken
|
||||
und organisatorische Abstimmung.
|
||||
verantwortlichkeiten:
|
||||
- "Freigabe von Service-Aktivierungen"
|
||||
- "Bewertung der Betriebsreife"
|
||||
- "Entscheidung über wesentliche Anpassungen"
|
||||
- "Risikobewertung und organisatorische Abstimmung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Review"
|
||||
|
||||
- id: service_owner
|
||||
name: "Service Owner"
|
||||
kurzbezeichnung: "SO"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert
|
||||
Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer
|
||||
Service-Inhalt und -Wert.
|
||||
verantwortlichkeiten:
|
||||
- "End-to-End-Verantwortung fuer den Service"
|
||||
- "Definition von Anforderungen und Qualitaetszielen"
|
||||
- "Steuerung der Weiterentwicklung"
|
||||
- "Fachliche Freigaben und Priorisierungen"
|
||||
- "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002"
|
||||
- "Improvement-Tracking in der Service-Definition (GOV-SR-005)"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MANAGEMENT-ROLLEN (Operative Führung)
|
||||
# ---------------------------------------------------------------------------
|
||||
management:
|
||||
|
||||
- id: al_basis_cloud
|
||||
name: "Abteilungsleitung Basis & Cloud"
|
||||
kurzbezeichnung: "AL B&C"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert
|
||||
die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung
|
||||
von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Infrastruktur-Betrieb"
|
||||
- "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Infrastrukturbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR"
|
||||
themengruppen:
|
||||
- "Netzwerk"
|
||||
- "Cloud"
|
||||
- "Deployment"
|
||||
- "Infrastruktur-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: al_applikationen
|
||||
name: "Abteilungsleitung Applikationen"
|
||||
kurzbezeichnung: "AL App"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet den stabilen, sicheren und effizienten Betrieb der
|
||||
Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen).
|
||||
Koordiniert die Betriebsteams im Anwendungsbereich und stellt die
|
||||
Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR.
|
||||
verantwortlichkeiten:
|
||||
- "Gesamtverantwortung für Anwendungs-Betrieb"
|
||||
- "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)"
|
||||
- "SLA- und Policy-Einhaltung im Anwendungsbereich"
|
||||
- "Ressourcenplanung und -priorisierung"
|
||||
- "Betriebsreife-Bewertung für Anwendungs-Services in der SOR"
|
||||
themengruppen:
|
||||
- "SAP"
|
||||
- "Ennaio"
|
||||
- "Fachverfahren"
|
||||
- "Anwendungs-Betrieb"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
gremien:
|
||||
- gremium: "SOR"
|
||||
funktion: "ständiges Mitglied"
|
||||
stimmberechtigt: true
|
||||
governance_referenz: "GOV-SOR-005"
|
||||
|
||||
- id: support_manager
|
||||
name: "Support Manager"
|
||||
kurzbezeichnung: "Sup Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level).
|
||||
Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes
|
||||
Incident/Request-Handling.
|
||||
verantwortlichkeiten:
|
||||
- "Organisation des Service-Supports"
|
||||
- "Qualitätssicherung im Support"
|
||||
- "Prozess- und Leitlinienentwicklung"
|
||||
- "Wissensmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
- id: problem_manager
|
||||
name: "Problem Manager"
|
||||
kurzbezeichnung: "Prob Mgr"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Identifiziert wiederkehrende oder strukturelle Störungen, führt
|
||||
Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für
|
||||
dauerhafte Fehlerbehebung und Workarounds.
|
||||
verantwortlichkeiten:
|
||||
- "Identifikation struktureller Störungen"
|
||||
- "Durchführung von Root-Cause-Analysen"
|
||||
- "Steuerung von Problemlösungen"
|
||||
- "Bereitstellung von Workarounds"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
- "Service Review"
|
||||
|
||||
- id: projektleitung
|
||||
name: "Projektleitung"
|
||||
kurzbezeichnung: "PL"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen,
|
||||
Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und
|
||||
qualitätsgesicherte Lieferung der Projektartefakte.
|
||||
verantwortlichkeiten:
|
||||
- "Planung und Steuerung von Entwicklungsprojekten"
|
||||
- "Ressourcen- und Lieferantenkoordination"
|
||||
- "Termin- und Qualitätssicherung"
|
||||
- "Lieferung der Projektartefakte"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# TEAMS (Kollektive Rollen)
|
||||
# ---------------------------------------------------------------------------
|
||||
teams:
|
||||
|
||||
- id: betriebsteam
|
||||
name: "Betriebsteam"
|
||||
kurzbezeichnung: "Betrieb"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Führt alle laufenden Betriebsaktivitäten für den Service aus - von
|
||||
anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung.
|
||||
Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und
|
||||
tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität
|
||||
des Betriebs.
|
||||
verantwortlichkeiten:
|
||||
- "Durchführung laufender Betriebsaufgaben"
|
||||
- "Monitoring und Überwachung"
|
||||
- "Ausführung von Standard-Changes"
|
||||
- "Deployment und Rollout von Komponenten"
|
||||
- "Betreuung technischer Infrastruktur"
|
||||
- "Tiefgehende Diagnosen und Fehleranalyse"
|
||||
- "Systempflege und -wartung"
|
||||
- "Sicherstellung von Stabilität und Verfügbarkeit"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Betrieb"
|
||||
|
||||
- id: service_support_team
|
||||
name: "Service-Support Team"
|
||||
kurzbezeichnung: "Support"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle
|
||||
Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen
|
||||
Anwendern, Betrieb und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung von Nutzeranfragen"
|
||||
- "Incident-Bearbeitung (1st/2nd Level)"
|
||||
- "Schnelle Wiederherstellung"
|
||||
- "Schnittstelle zu Betrieb und Problemmanagement"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Support"
|
||||
|
||||
- id: projektteam
|
||||
name: "Projektteam"
|
||||
kurzbezeichnung: "Projekt"
|
||||
typ: "Team"
|
||||
beschreibung: >
|
||||
Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und
|
||||
Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe
|
||||
und Betriebsbefähigung.
|
||||
verantwortlichkeiten:
|
||||
- "Entwicklung und Konfiguration"
|
||||
- "Testdurchführung"
|
||||
- "Dokumentation"
|
||||
- "Unterstützung bei Übergabe und Betriebsbefähigung"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# INDIVIDUELLE OPERATIVE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
operative_rollen:
|
||||
|
||||
- id: queue_koordinator
|
||||
name: "Queue Koordinator"
|
||||
kurzbezeichnung: "Queue Koord"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen
|
||||
und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und
|
||||
effizienten Ticketfluss sicher.
|
||||
verantwortlichkeiten:
|
||||
- "Überwachung des Ticketaufkommens"
|
||||
- "Ticketverteilung und Routing"
|
||||
- "Priorisierung und SLA-Überwachung"
|
||||
- "Sicherstellung des Ticketflusses"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: first_level_agent
|
||||
name: "1st Level Agent"
|
||||
kurzbezeichnung: "L1"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst
|
||||
Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den
|
||||
2nd Level bei Bedarf.
|
||||
verantwortlichkeiten:
|
||||
- "Entgegennahme von Incidents und Requests"
|
||||
- "Lösung von Standardfällen"
|
||||
- "Saubere Dokumentation"
|
||||
- "Fachgerechte Eskalation"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: second_level_agent
|
||||
name: "2nd Level Agent"
|
||||
kurzbezeichnung: "L2"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere
|
||||
Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb,
|
||||
Herstellern und Problemmanagement.
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung komplexer Störungen"
|
||||
- "Tiefere Analysen und Diagnosen"
|
||||
- "Lösungsbereitstellung"
|
||||
- "Kooperation mit Betrieb und Herstellern"
|
||||
lifecycle_relevanz:
|
||||
- "Service Support"
|
||||
|
||||
- id: testmanagement
|
||||
name: "Testmanagement"
|
||||
kurzbezeichnung: "Test Mgmt"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression)
|
||||
während Service-Entwicklung und Transition. Sichert die Qualität und
|
||||
Betriebsreife neuer Service-Komponenten.
|
||||
verantwortlichkeiten:
|
||||
- "Testplanung und -organisation"
|
||||
- "Verantwortung für Testdurchführung"
|
||||
- "Qualitätssicherung neuer Komponenten"
|
||||
- "Nachweis der Betriebsreife"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
- id: architektur
|
||||
name: "Architektur"
|
||||
kurzbezeichnung: "Arch"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: >
|
||||
Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen;
|
||||
bewertet Designvarianten und Risiken. Sichert technische Konsistenz und
|
||||
Zukunftsfähigkeit des Service.
|
||||
verantwortlichkeiten:
|
||||
- "Definition technischer Standards"
|
||||
- "Entwicklung von Zielarchitekturen"
|
||||
- "Bewertung von Designvarianten und Risiken"
|
||||
- "Sicherstellung technischer Konsistenz"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# EXTERNE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
externe:
|
||||
|
||||
- id: lieferant
|
||||
name: "Lieferant / Hersteller / Entwickler"
|
||||
kurzbezeichnung: "Lieferant"
|
||||
typ: "Externe Rolle"
|
||||
beschreibung: >
|
||||
Stellt externe System-, Software- oder Infrastrukturkomponenten bereit
|
||||
oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse
|
||||
und Komponentensupport eingebunden.
|
||||
verantwortlichkeiten:
|
||||
- "Bereitstellung externer Komponenten"
|
||||
- "Entwicklung spezifischer Anpassungen"
|
||||
- "Unterstützung bei Fehleranalyse"
|
||||
- "Komponentensupport"
|
||||
lifecycle_relevanz:
|
||||
- "Service Entwicklung"
|
||||
- "Service Transition"
|
||||
- "Service Support"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-MAPPING (für schnelle Referenz)
|
||||
# =============================================================================
|
||||
rollen_index:
|
||||
# Kurzreferenz: id -> name
|
||||
spm: "Service-Portfolio-Manager"
|
||||
sor: "Service Operations Runde"
|
||||
service_owner: "Service Owner"
|
||||
al_basis_cloud: "Abteilungsleitung Basis & Cloud"
|
||||
al_applikationen: "Abteilungsleitung Applikationen"
|
||||
support_manager: "Support Manager"
|
||||
problem_manager: "Problem Manager"
|
||||
projektleitung: "Projektleitung"
|
||||
betriebsteam: "Betriebsteam"
|
||||
service_support_team: "Service-Support Team"
|
||||
projektteam: "Projektteam"
|
||||
queue_koordinator: "Queue Koordinator"
|
||||
first_level_agent: "1st Level Agent"
|
||||
second_level_agent: "2nd Level Agent"
|
||||
testmanagement: "Testmanagement"
|
||||
architektur: "Architektur"
|
||||
lieferant: "Lieferant / Hersteller / Entwickler"
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
# =============================================================================
|
||||
# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT)
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "K-BL"
|
||||
name: "Service-Betrieb Light-Weight Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-15"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "konzept"
|
||||
|
||||
beschreibung: >
|
||||
Minimales Strukturkonzept für den Service-Betrieb. Definiert
|
||||
Betriebsrollen und grundlegende Verantwortungsabgrenzungen,
|
||||
um Anschlussfähigkeit an die operative Organisation herzustellen.
|
||||
|
||||
scope_hinweis: >
|
||||
BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine
|
||||
vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase.
|
||||
|
||||
referenzen:
|
||||
blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml"
|
||||
rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# BEGRÜNDUNG
|
||||
# =============================================================================
|
||||
|
||||
begruendung:
|
||||
workshop_befund: >
|
||||
Ohne minimale Strukturelemente für den Service-Betrieb fehlt die
|
||||
Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft
|
||||
muss sich im Modell wiederfinden, sonst keine Legitimation.
|
||||
|
||||
systemtheoretisch: >
|
||||
Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur,
|
||||
die von der Organisation als "Management-Theater" abgekoppelt wird.
|
||||
|
||||
# =============================================================================
|
||||
# GLIEDERUNG (zu entwickeln)
|
||||
# =============================================================================
|
||||
|
||||
gliederung:
|
||||
|
||||
- abschnitt: "Scope und Abgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Was dieses Konzept ist (Strukturanker)"
|
||||
- "Was dieses Konzept nicht ist (kein Betriebshandbuch)"
|
||||
- "Verweis auf Blueprint für Aktivitäten"
|
||||
|
||||
- abschnitt: "Betriebsrollen (Minimum)"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Operations Manager"
|
||||
- "Betriebsteam"
|
||||
- "Technical Lead (optional)"
|
||||
referenz: "spm_rollen.yaml → management, operativ"
|
||||
|
||||
- abschnitt: "Verantwortungsabgrenzung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Service Owner vs. Operations Manager"
|
||||
- "Betrieb vs. Support (Incident-Handling)"
|
||||
- "Proaktiv vs. Reaktiv"
|
||||
|
||||
- abschnitt: "Schnittstelle zu Support"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Eskalationswege bei Incidents"
|
||||
- "Problem-Identifikation"
|
||||
- "Wissenstransfer"
|
||||
|
||||
- abschnitt: "Monitoring-Verantwortung"
|
||||
status: "ausstehend"
|
||||
inhalte:
|
||||
- "Wer definiert Schwellwerte?"
|
||||
- "Wer reagiert auf Alerts?"
|
||||
- "Wer erstellt Qualitätsberichte?"
|
||||
|
||||
# =============================================================================
|
||||
# EXPLIZITE NICHT-INHALTE
|
||||
# =============================================================================
|
||||
|
||||
nicht_inhalte:
|
||||
themen:
|
||||
- "Detaillierte Betriebsprozesse"
|
||||
- "Monitoring-Tool-Auswahl"
|
||||
- "Kapazitätsplanung"
|
||||
- "Change-Management im Betrieb"
|
||||
hinweis: "Diese Themen werden in Phase X vertieft."
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-15"
|
||||
aenderung: "Placeholder erstellt mit Gliederungsskelett"
|
||||
autor: "DIGITOM-Projekt"
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,844 @@
|
|||
# =============================================================================
|
||||
# KONZEPT: CHANGE ENABLEMENT (P-03)
|
||||
# =============================================================================
|
||||
# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/03_practices/
|
||||
# Dateiname: spm_practice_change-enablement.yaml
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "P-03"
|
||||
name: "Change Enablement"
|
||||
version: "1.3"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-17"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "practice-konzept"
|
||||
itil4_referenz: "Change Enablement Practice"
|
||||
|
||||
beschreibung: |
|
||||
Rahmenkonzept für die kontrollierte Durchführung von Service-Änderungen.
|
||||
Definiert Change-Typen, Klassifizierungslogik, Autorisierungsverfahren
|
||||
und Schnittstellen zu angrenzenden Prozessen.
|
||||
|
||||
Ziel: Erfolgreiche Changes ermöglichen bei angemessener Risikokontrolle.
|
||||
Prinzip: So wenig Governance wie nötig, so viel wie erforderlich.
|
||||
|
||||
referenzen:
|
||||
service_transition: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
|
||||
problem_management: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml"
|
||||
shm_bedarfsbewertung: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||||
dpm_klassifizierung: "#01_demand-portfolio-management/#01.1_documentation/dpm_demand-klassifizierung.yaml"
|
||||
governance_log: "spm_governance-entscheidungen-log.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# 1. EINORDNUNG UND SCOPE
|
||||
# =============================================================================
|
||||
|
||||
einordnung:
|
||||
|
||||
zweck: |
|
||||
Change Enablement stellt sicher, dass Service-Änderungen kontrolliert,
|
||||
risikobewusst und effizient durchgeführt werden. Die Practice balanciert
|
||||
zwischen Agilität (schnelle Umsetzung) und Stabilität (Schutz des Betriebs).
|
||||
|
||||
itil4_definition: |
|
||||
"The purpose of the change enablement practice is to maximize the number
|
||||
of successful service and product changes by ensuring that risks have been
|
||||
properly assessed, authorizing changes to proceed, and managing the
|
||||
change schedule."
|
||||
|
||||
scope:
|
||||
|
||||
in_scope:
|
||||
- "Änderungen an bestehenden Services"
|
||||
- "Service-Erweiterungen und -Optimierungen"
|
||||
- "Technische Updates mit Service-Bezug"
|
||||
- "Konfigurationsänderungen an Service-Komponenten"
|
||||
- "Changes aus Problem Management (permanente Lösungen)"
|
||||
|
||||
out_of_scope:
|
||||
- typ: "Neue Services"
|
||||
routing: "Service Transition (vollständiger Lifecycle)"
|
||||
referenz: "konzept_service-transition.yaml"
|
||||
|
||||
- typ: "Demands (neue Services / grundlegende Neugestaltung)"
|
||||
routing: "Demand Portfolio Management"
|
||||
referenz: "dpm_funktionsbeschreibung.yaml"
|
||||
|
||||
- typ: "Service Requests"
|
||||
routing: "Request Management (Katalog-basiert)"
|
||||
referenz: "sub-practice_request-management.yaml"
|
||||
|
||||
- typ: "Infrastruktur ohne Service-Bezug"
|
||||
routing: "Produkt-Ebene (nicht in aktueller Phase)"
|
||||
hinweis: "Siehe Abgrenzung Produkt"
|
||||
|
||||
abgrenzung_produkt:
|
||||
governance_referenz: "GOV-CE-002"
|
||||
|
||||
vermerk: |
|
||||
Infrastruktur-Änderungen ohne direkten Service-Bezug (z.B. Netzwerk-
|
||||
Wartung, Basis-Infrastruktur) sind der Produkt-Ebene zuzuordnen.
|
||||
|
||||
Da die Produkt-Konzeption in der aktuellen Projektphase nicht im Fokus
|
||||
steht (Priorisierung Kunden-/Service-Sicht), wird dieser Bereich
|
||||
bewusst ausgeklammert.
|
||||
|
||||
Merke: Bei späterer Produkt-Konzeption ist Change Enablement für
|
||||
Produkte/Infrastruktur zu ergänzen.
|
||||
|
||||
praktische_regel: |
|
||||
Frage: "Hat diese Änderung Auswirkungen auf einen Service im Katalog?"
|
||||
- Ja → Change Enablement (dieses Konzept)
|
||||
- Nein → Operativer Betrieb oder Produkt-Management
|
||||
|
||||
# =============================================================================
|
||||
# 2. CHANGE-TYPEN
|
||||
# =============================================================================
|
||||
|
||||
change_typen:
|
||||
|
||||
uebersicht:
|
||||
beschreibung: |
|
||||
DIGITOM unterscheidet vier Change-Typen, die sich in Risiko,
|
||||
Autorisierungsverfahren und Dokumentationsaufwand unterscheiden.
|
||||
|
||||
typen:
|
||||
- "Standard Change (pre-authorized)"
|
||||
- "Normal Change (SO-Entscheidung)"
|
||||
- "Major Change (SOR-autorisierungspflichtig)"
|
||||
- "Emergency Change (Sofortumsetzung)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# STANDARD CHANGE
|
||||
# ---------------------------------------------------------------------------
|
||||
standard_change:
|
||||
|
||||
definition: |
|
||||
Ein Standard Change ist ein wiederkehrender, risikoarmer Change,
|
||||
der vollständig dokumentiert ist und ohne zusätzliche Genehmigung
|
||||
durchgeführt werden kann.
|
||||
|
||||
merkmale:
|
||||
- "Wiederkehrend und vorhersehbar"
|
||||
- "Risiko bekannt und gering"
|
||||
- "Ablauf standardisiert und dokumentiert"
|
||||
- "Ergebnis vorhersehbar"
|
||||
|
||||
voraussetzungen:
|
||||
- "Change-Modell existiert und ist dokumentiert"
|
||||
- "Change-Modell wurde einmalig durch SO genehmigt"
|
||||
- "Rollback-Verfahren ist definiert"
|
||||
|
||||
change_modell:
|
||||
|
||||
beschreibung: |
|
||||
Ein Change-Modell dokumentiert das Verfahren für einen Standard Change.
|
||||
Es wird einmalig erstellt und genehmigt. Danach ist der Change
|
||||
pre-authorized – jede Ausführung benötigt keine weitere Genehmigung.
|
||||
|
||||
verantwortung_erstellung: "Service Owner"
|
||||
verantwortung_genehmigung: "Service Owner"
|
||||
|
||||
inhalt:
|
||||
- name: "Change-Bezeichnung"
|
||||
beschreibung: "Eindeutiger Name für den Standard Change"
|
||||
- name: "Anwendungsbereich"
|
||||
beschreibung: "Wann/wo wird dieser Change angewendet?"
|
||||
- name: "Auslöser"
|
||||
beschreibung: "Was triggert diesen Change?"
|
||||
- name: "Durchführungsschritte"
|
||||
beschreibung: "Schritt-für-Schritt-Anleitung"
|
||||
- name: "Beteiligte Rollen"
|
||||
beschreibung: "Wer führt durch, wer wird informiert?"
|
||||
- name: "Risikobewertung"
|
||||
beschreibung: "Bekannte Risiken und Mitigationen"
|
||||
- name: "Rollback-Verfahren"
|
||||
beschreibung: "Wie wird rückgängig gemacht?"
|
||||
- name: "Erwartete Dauer"
|
||||
beschreibung: "Typischer Zeitaufwand"
|
||||
|
||||
transparenz: |
|
||||
SO dokumentiert Change-Modelle für seinen Service.
|
||||
SPM erhält Kopie zur Kenntnis (nicht zur Genehmigung).
|
||||
Dies dient der Portfolio-Transparenz, nicht der Kontrolle.
|
||||
|
||||
autorisierung: |
|
||||
Keine weitere Genehmigung bei Ausführung erforderlich.
|
||||
Die Genehmigung erfolgte einmalig bei Freigabe des Change-Modells.
|
||||
|
||||
beispiele:
|
||||
- "Passwort-Reset nach definiertem Verfahren"
|
||||
- "Software-Update auf freigegebene Version"
|
||||
- "Benutzer-Berechtigung gemäß Berechtigungskonzept"
|
||||
- "Regelmäßige Wartungsarbeiten nach Wartungsplan"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# NORMAL CHANGE
|
||||
# ---------------------------------------------------------------------------
|
||||
normal_change:
|
||||
|
||||
definition: |
|
||||
Ein Normal Change ist eine Service-Änderung, die weder als Standard
|
||||
Change pre-authorized ist, noch die Kriterien für einen Major Change
|
||||
erfüllt. Er erfordert eine Einzelfallentscheidung durch den Service Owner.
|
||||
|
||||
merkmale:
|
||||
- "Nicht wiederkehrend oder nicht standardisierbar"
|
||||
- "Risiko überschaubar, aber nicht trivial"
|
||||
- "Service-Identität bleibt erhalten"
|
||||
- "Keine Transition-Gates erforderlich"
|
||||
|
||||
change_authority: "Service Owner"
|
||||
|
||||
verfahren:
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Change Request"
|
||||
beschreibung: "Anforderung wird dokumentiert (Ticket, E-Mail, etc.)"
|
||||
verantwortlich: "Anfordernde Rolle"
|
||||
|
||||
- schritt: 2
|
||||
name: "Klassifizierung"
|
||||
beschreibung: "SO prüft: Standard? Normal? Major?"
|
||||
verantwortlich: "Service Owner"
|
||||
|
||||
- schritt: 3
|
||||
name: "Bewertung"
|
||||
beschreibung: "SO bewertet Risiko, Aufwand, Auswirkungen"
|
||||
verantwortlich: "Service Owner"
|
||||
|
||||
- schritt: 4
|
||||
name: "Entscheidung"
|
||||
beschreibung: "SO entscheidet: Freigabe / Ablehnung / Rückfragen"
|
||||
verantwortlich: "Service Owner"
|
||||
|
||||
- schritt: 5
|
||||
name: "Umsetzung"
|
||||
beschreibung: "Change wird implementiert"
|
||||
verantwortlich: "Betriebsteam / Projektteam"
|
||||
|
||||
- schritt: 6
|
||||
name: "Abschluss"
|
||||
beschreibung: "SO bestätigt erfolgreiche Umsetzung"
|
||||
verantwortlich: "Service Owner"
|
||||
|
||||
cross_service:
|
||||
governance_referenz: "GOV-CE-003"
|
||||
|
||||
erkennung: |
|
||||
Der Service Owner ist verantwortlich für die Erkennung von
|
||||
Cross-Service-Impact. Er kennt seinen Service und dessen
|
||||
Abhängigkeiten am besten.
|
||||
|
||||
eskalation: |
|
||||
Bei Normal Changes mit potenziellem Cross-Service-Impact
|
||||
bezieht der SO den SPM als "Zweite Augen" ein.
|
||||
|
||||
SPM prüft aus Portfolio-Perspektive:
|
||||
- Gibt es Auswirkungen auf andere Services?
|
||||
- Sind andere Service Owner zu informieren/einzubeziehen?
|
||||
- Ist eine SOR-Befassung erforderlich?
|
||||
|
||||
schwellenwert: |
|
||||
SO-Ermessen: "Im Zweifel SPM einbeziehen."
|
||||
|
||||
Keine formalen Schwellenwerte im MVP. Die operative Erfahrung
|
||||
wird zeigen, ob Präzisierung nötig ist.
|
||||
|
||||
verfahren_bei_cross_service:
|
||||
- "SO identifiziert potenziellen Cross-Service-Impact"
|
||||
- "SO informiert SPM (formlos, z.B. kurze E-Mail/Teams)"
|
||||
- "SPM gibt Einschätzung: 'Go' oder 'Abstimmung mit SO X nötig'"
|
||||
- "Bei Bedarf: Bilaterale Abstimmung zwischen betroffenen SOs"
|
||||
- "Bei Dissens oder Unklarheit: Eskalation an SOR"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MAJOR CHANGE
|
||||
# ---------------------------------------------------------------------------
|
||||
major_change:
|
||||
|
||||
definition: |
|
||||
Ein Major Change ist eine signifikante Service-Änderung, die die
|
||||
Service-Identität berührt und daher eine SOR-Autorisierung erfordert.
|
||||
Nach der Autorisierung durchläuft der Major Change den regulären
|
||||
Service-Lifecycle (Design/Transition) je nach Einstiegspunkt.
|
||||
|
||||
governance_referenz: "GOV-TR-003"
|
||||
|
||||
merkmale:
|
||||
- "Verändert wesentliche Service-Eigenschaften"
|
||||
- "Höheres Risiko für Betrieb und Stakeholder"
|
||||
- "Erfordert initiale Governance-Entscheidung durch SOR (Autorisierung)"
|
||||
- "Durchläuft nach Autorisierung regulären Lifecycle (Design/Transition) je nach Einstiegspunkt"
|
||||
|
||||
kriterien:
|
||||
beschreibung: |
|
||||
Ein Change gilt als Major, wenn mindestens eines der folgenden
|
||||
Kriterien erfüllt ist. Die Bewertung erfolgt durch den SO nach
|
||||
dem Prinzip "Informed Judgment".
|
||||
|
||||
liste:
|
||||
- id: "MAJ-01"
|
||||
kriterium: "Änderung der Service-Definition"
|
||||
beschreibung: "Der Scope, die Zielgruppe oder die Kernfunktionalität des Service ändert sich."
|
||||
beispiele:
|
||||
- "Service wird auf neue Nutzergruppe ausgeweitet"
|
||||
- "Kernfunktion wird hinzugefügt oder entfernt"
|
||||
- "Service-Scope wird signifikant erweitert/eingeschränkt"
|
||||
|
||||
- id: "MAJ-02"
|
||||
kriterium: "Änderung der SLA/SLO-Vereinbarungen"
|
||||
beschreibung: "Die vereinbarten Service Levels ändern sich."
|
||||
beispiele:
|
||||
- "Verfügbarkeitsziel wird angepasst"
|
||||
- "Support-Zeiten werden geändert"
|
||||
- "Performance-Ziele werden neu definiert"
|
||||
|
||||
- id: "MAJ-03"
|
||||
kriterium: "Signifikante Architektur-Änderung"
|
||||
beschreibung: "Die technische Grundstruktur des Service ändert sich wesentlich."
|
||||
beispiele:
|
||||
- "Wechsel der Basis-Plattform"
|
||||
- "Neue kritische Abhängigkeit zu anderem System"
|
||||
- "Grundlegende Änderung des Technologie-Stacks"
|
||||
bei_unsicherheit: |
|
||||
Bei Unsicherheit, ob eine Architektur-Änderung "signifikant" ist:
|
||||
Architektur-Rolle konsultieren.
|
||||
|
||||
- id: "MAJ-04"
|
||||
kriterium: "DPM-Komplexität 'komplex' oder 'hochkomplex'"
|
||||
beschreibung: |
|
||||
Der Change resultiert aus einem Demand, der im DPM als
|
||||
komplex oder hochkomplex klassifiziert wurde.
|
||||
referenz: "dpm_demand-klassifizierung.yaml"
|
||||
hinweis: |
|
||||
Dieses Kriterium greift, wenn ein Demand durch DPM bearbeitet
|
||||
wurde und als Umsetzungsauftrag an SPM übergeht.
|
||||
|
||||
verfahren: |
|
||||
Major Changes erfordern EINE SOR-Autorisierung. Danach durchlaufen
|
||||
sie den regulären Service-Lifecycle. Der Ablauf ist:
|
||||
|
||||
1. SO klassifiziert Change als Major
|
||||
2. SO stellt Major Change der SOR vor (Autorisierung)
|
||||
3. SOR entscheidet: Autorisierung / Autorisierung mit Auflagen / Ablehnung
|
||||
- Als Teil der Autorisierung legt SOR den Einstiegspunkt fest
|
||||
(Design oder Transition), je nach Reifegrad der Änderung
|
||||
4. Bei Autorisierung: Major Change durchläuft regulären Lifecycle
|
||||
ab dem festgelegten Einstiegspunkt
|
||||
5. Alle weiteren Gates (Gate 1, Gate 2, Gate 3) sind reguläre
|
||||
Lifecycle-Gates – keine gesonderte Major-Change-Entscheidung
|
||||
|
||||
Wichtig: Die SOR hat bei einem Major Change genau EINE Entscheidung:
|
||||
die initiale Autorisierung (oder Ablehnung). Danach ist der Major Change
|
||||
eine Änderung an einem bestehenden Service und durchläuft als solcher
|
||||
die vorgesehenen Lifecycle-Stufen und -Gates.
|
||||
Dies unterscheidet ihn vom Normal Change, bei dem der SO allein entscheidet.
|
||||
|
||||
Details siehe konzept_service-transition.yaml
|
||||
|
||||
referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# EMERGENCY CHANGE
|
||||
# ---------------------------------------------------------------------------
|
||||
emergency_change:
|
||||
governance_referenz: "GOV-CE-001"
|
||||
|
||||
definition: |
|
||||
Ein Emergency Change ist eine Änderung, die aufgrund kritischer
|
||||
Sicherheits- oder Verfügbarkeitsprobleme sofort umgesetzt werden muss.
|
||||
Das normale Genehmigungsverfahren wird zugunsten der Geschwindigkeit
|
||||
verkürzt.
|
||||
|
||||
merkmale:
|
||||
- "Kritische Dringlichkeit (Sicherheit oder Verfügbarkeit)"
|
||||
- "Sofortumsetzung erforderlich"
|
||||
- "Dokumentation erfolgt nachträglich"
|
||||
- "SO wird informiert, nicht um Genehmigung gefragt"
|
||||
|
||||
ausloeser:
|
||||
- "Kritische Sicherheitslücke (z.B. aktiv ausgenutzte Schwachstelle)"
|
||||
- "Service-Ausfall mit hohem Business-Impact"
|
||||
- "Datenverlust-Risiko"
|
||||
- "Compliance-Verstoß mit sofortigem Handlungsbedarf"
|
||||
|
||||
verfahren:
|
||||
|
||||
autorisierung: |
|
||||
Sofortumsetzung durch Betrieb/Support ohne vorherige Genehmigung.
|
||||
Die Entscheidung zur Sofortumsetzung trifft die handelnde Rolle
|
||||
(z.B. Operations Manager, Support Manager, L2-Agent).
|
||||
|
||||
so_rolle: |
|
||||
Der Service Owner wird informiert, nicht um Genehmigung gefragt.
|
||||
Information erfolgt parallel zur oder unmittelbar nach der Umsetzung.
|
||||
|
||||
dokumentation: |
|
||||
Nachträgliche Dokumentation innerhalb von 24 Stunden:
|
||||
- Was wurde geändert?
|
||||
- Warum war Sofortumsetzung erforderlich?
|
||||
- Wer hat entschieden/umgesetzt?
|
||||
- Welche Auswirkungen hatte der Change?
|
||||
|
||||
nachbereitung: |
|
||||
Nach Abschluss des Emergency Change:
|
||||
- SO prüft: Ist Nacharbeit erforderlich?
|
||||
- Bei Bedarf: Normal Change für "saubere" Lösung
|
||||
- Bei wiederkehrendem Muster: Problem Record erstellen
|
||||
|
||||
abgrenzung: |
|
||||
Nicht jeder dringende Change ist ein Emergency Change.
|
||||
|
||||
Emergency = "Muss JETZT passieren, sonst kritischer Schaden"
|
||||
Dringend = "Sollte schnell passieren" → Beschleunigter Normal Change
|
||||
|
||||
# =============================================================================
|
||||
# 3. KLASSIFIZIERUNGSVERFAHREN
|
||||
# =============================================================================
|
||||
|
||||
klassifizierung:
|
||||
|
||||
verantwortung: "Service Owner"
|
||||
|
||||
prinzip: |
|
||||
Die Klassifizierung erfolgt nach dem Prinzip "Informed Judgment".
|
||||
Der SO trifft eine fachliche Einschätzung basierend auf seinem
|
||||
Service-Wissen. Es gibt keine mechanischen Schwellenwerte.
|
||||
|
||||
entscheidungslogik:
|
||||
|
||||
beschreibung: |
|
||||
Der SO durchläuft folgende Prüffragen, um den Change-Typ zu bestimmen.
|
||||
|
||||
prueffragen:
|
||||
- reihenfolge: 1
|
||||
frage: "Ist das ein dokumentierter, pre-authorized Standard Change?"
|
||||
wenn_ja: "→ Standard Change"
|
||||
wenn_nein: "→ Weiter zu Frage 2"
|
||||
|
||||
- reihenfolge: 2
|
||||
frage: "Erfordert die Situation Sofortumsetzung (Sicherheit/Verfügbarkeit)?"
|
||||
wenn_ja: "→ Emergency Change"
|
||||
wenn_nein: "→ Weiter zu Frage 3"
|
||||
|
||||
- reihenfolge: 3
|
||||
frage: "Erfüllt der Change ein Major-Kriterium (MAJ-01 bis MAJ-04)?"
|
||||
wenn_ja: "→ Major Change"
|
||||
wenn_nein: "→ Normal Change"
|
||||
|
||||
flussdiagramm: |
|
||||
Change Request
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ Standard Change-Modell │──► Ja ──► STANDARD
|
||||
│ vorhanden? │
|
||||
└─────────────────────────────┘
|
||||
│ Nein
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ Kritische Dringlichkeit? │──► Ja ──► EMERGENCY
|
||||
│ (Sicherheit/Verfügbarkeit) │
|
||||
└─────────────────────────────┘
|
||||
│ Nein
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ Major-Kriterium erfüllt? │──► Ja ──► MAJOR
|
||||
│ (MAJ-01 bis MAJ-04) │
|
||||
└─────────────────────────────┘
|
||||
│ Nein
|
||||
▼
|
||||
NORMAL
|
||||
|
||||
hochstufung:
|
||||
beschreibung: |
|
||||
Der SO kann einen Change jederzeit hochstufen, wenn sich während
|
||||
der Bearbeitung herausstellt, dass die initiale Klassifizierung
|
||||
nicht angemessen war.
|
||||
|
||||
regel: |
|
||||
- Normal → Major: SO stellt Change der SOR zur Autorisierung vor
|
||||
- Standard → Normal: SO übernimmt Einzelfallentscheidung
|
||||
- Jede Stufe → Emergency: Bei kritischem Sicherheits-/Verfügbarkeitsproblem
|
||||
|
||||
dokumentation: |
|
||||
Hochstufung wird im Change Request dokumentiert mit Begründung.
|
||||
|
||||
dokumentation:
|
||||
beschreibung: |
|
||||
Die Klassifizierung wird im Change Request / Ticket dokumentiert.
|
||||
|
||||
mindestangaben:
|
||||
- "Change-Typ (Standard/Normal/Major/Emergency)"
|
||||
- "Bei Normal/Major: Kurzbegründung"
|
||||
- "Bei Major: Referenz auf erfülltes Kriterium (MAJ-01 bis MAJ-04)"
|
||||
|
||||
# =============================================================================
|
||||
# 4. SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLE: SHM-ROUTING
|
||||
# ---------------------------------------------------------------------------
|
||||
shm_routing:
|
||||
|
||||
beschreibung: |
|
||||
SHM führt eine Ersteinschätzung durch (Request / Change / Demand).
|
||||
Diese Ersteinschätzung ist eine Orientierung, nicht verbindlich.
|
||||
Die verbindliche Klassifizierung erfolgt durch den SO.
|
||||
|
||||
zwei_stufen_modell:
|
||||
stufe_1:
|
||||
name: "SHM-Ersteinschätzung"
|
||||
verantwortlich: "Stakeholder-Manager"
|
||||
ergebnis: "Routing zu Service Desk / SO / DPM"
|
||||
charakter: "Orientierung"
|
||||
|
||||
stufe_2:
|
||||
name: "SO-Klassifizierung"
|
||||
verantwortlich: "Service Owner"
|
||||
ergebnis: "Standard / Normal / Major / Emergency"
|
||||
charakter: "Verbindlich"
|
||||
|
||||
korrektur: |
|
||||
Wenn SO feststellt, dass SHM-Routing nicht passt:
|
||||
- Change ist eigentlich Demand → SO gibt zurück an SHM/DPM
|
||||
- Demand ist eigentlich Change → SO übernimmt und klassifiziert
|
||||
|
||||
referenz: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLE: SERVICE TRANSITION
|
||||
# ---------------------------------------------------------------------------
|
||||
service_transition:
|
||||
|
||||
beschreibung: |
|
||||
Nach SOR-Autorisierung durchläuft ein Major Change den regulären
|
||||
Service-Lifecycle ab dem von der SOR festgelegten Einstiegspunkt
|
||||
(Design oder Transition). Die Lifecycle-Gates sind dabei reguläre
|
||||
Gates – keine gesonderte Major-Change-Governance.
|
||||
|
||||
trigger: "SOR autorisiert Major Change und legt Einstiegspunkt fest"
|
||||
|
||||
uebergabe:
|
||||
verantwortlich: "Service Owner"
|
||||
aktion: "SO führt Major Change ab festgelegtem Einstiegspunkt im regulären Lifecycle durch"
|
||||
artefakt: "Change Request wird zum Transition-/Design-Steckbrief erweitert"
|
||||
|
||||
rueckweg: |
|
||||
Die regulären Lifecycle-Gates (Gate 1, 2, 3) gelten unverändert.
|
||||
Bei Rückweisung an einem Gate: reguläres Gate-Verfahren.
|
||||
|
||||
referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLE: PROBLEM MANAGEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
problem_management:
|
||||
|
||||
beschreibung: |
|
||||
Problem Management identifiziert strukturelle Ursachen für Incidents.
|
||||
Permanente Lösungen werden über Change Enablement umgesetzt.
|
||||
|
||||
ablauf:
|
||||
- schritt: 1
|
||||
beschreibung: "Problem Manager identifiziert permanente Lösung"
|
||||
verantwortlich: "Problem Manager / Service Owner"
|
||||
|
||||
- schritt: 2
|
||||
beschreibung: "Change Request wird erstellt"
|
||||
verantwortlich: "Problem Manager"
|
||||
inhalt:
|
||||
- "Verweis auf Problem Record"
|
||||
- "Beschreibung der Ursache"
|
||||
- "Vorgeschlagene Lösung"
|
||||
|
||||
- schritt: 3
|
||||
beschreibung: "SO klassifiziert den Change"
|
||||
verantwortlich: "Service Owner"
|
||||
|
||||
- schritt: 4
|
||||
beschreibung: "Change wird gemäß Typ bearbeitet"
|
||||
verantwortlich: "Je nach Change-Typ"
|
||||
|
||||
- schritt: 5
|
||||
beschreibung: "Problem Record wird nach erfolgreicher Umsetzung geschlossen"
|
||||
verantwortlich: "Problem Manager"
|
||||
|
||||
referenz: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLE: DPM (ABGRENZUNG CHANGE VS. DEMAND)
|
||||
# ---------------------------------------------------------------------------
|
||||
dpm_abgrenzung:
|
||||
|
||||
beschreibung: |
|
||||
Die Abgrenzung zwischen Change und Demand basiert auf der Frage:
|
||||
"Bleibt der Service im Kern derselbe?"
|
||||
|
||||
kriterium: "Service-Identität"
|
||||
|
||||
proxy_fragen:
|
||||
beschreibung: |
|
||||
Da "Service-Identität" abstrakt ist, helfen folgende Proxy-Fragen:
|
||||
|
||||
fragen:
|
||||
- "Braucht es einen neuen Katalog-Eintrag?"
|
||||
- "Ist ein neuer Service Owner erforderlich?"
|
||||
- "Muss eine neue Service-Definition erstellt werden?"
|
||||
|
||||
entscheidungsregel: |
|
||||
- Mindestens eine Proxy-Frage mit "Ja" → Demand (→ DPM)
|
||||
- Alle Proxy-Fragen mit "Nein" → Change (ggf. Major)
|
||||
|
||||
grauzone: |
|
||||
Bei Unsicherheit:
|
||||
- SO bespricht mit SPM
|
||||
- Im Zweifel: Als Major Change starten, bei Gate 1 kann SOR
|
||||
entscheiden, ob Rückgabe an DPM erforderlich
|
||||
|
||||
# =============================================================================
|
||||
# 5. GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
governance:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# CHANGE AUTHORITY MATRIX
|
||||
# ---------------------------------------------------------------------------
|
||||
change_authority_matrix:
|
||||
|
||||
beschreibung: |
|
||||
Die Change Authority ist die Rolle/Instanz, die einen Change autorisiert.
|
||||
Sie variiert je nach Change-Typ und Risiko.
|
||||
|
||||
matrix:
|
||||
- change_typ: "Standard"
|
||||
authority: "Pre-authorized (via Change-Modell)"
|
||||
genehmigung_durch: "Entfällt (einmalig bei Modell-Freigabe)"
|
||||
|
||||
- change_typ: "Normal"
|
||||
authority: "Service Owner"
|
||||
genehmigung_durch: "SO-Einzelentscheidung"
|
||||
|
||||
- change_typ: "Normal (Cross-Service)"
|
||||
authority: "Service Owner + SPM"
|
||||
genehmigung_durch: "SO-Entscheidung nach SPM-Konsultation"
|
||||
|
||||
- change_typ: "Major"
|
||||
authority: "SOR"
|
||||
genehmigung_durch: "SOR-Autorisierung (einmalig, inkl. Festlegung Einstiegspunkt)"
|
||||
hinweis: "EIN Entscheidungspunkt: initiale Autorisierung. Danach regulärer Lifecycle mit regulären Gates."
|
||||
|
||||
- change_typ: "Emergency"
|
||||
authority: "Betrieb/Support"
|
||||
genehmigung_durch: "Sofortumsetzung, nachträgliche Dokumentation"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# WARTUNGSFENSTER KRITISCHE SERVICES
|
||||
# ---------------------------------------------------------------------------
|
||||
wartungsfenster_kritische_services:
|
||||
|
||||
governance_referenz: "GOV-CE-004"
|
||||
|
||||
beschreibung: |
|
||||
Für Services mit Kritikalitätsstufe 'geschaeftskritisch' (gemäß
|
||||
Service-Definition) gelten besondere Anforderungen an die Change-Planung.
|
||||
|
||||
referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet"
|
||||
|
||||
anforderungen:
|
||||
- id: "WF-01"
|
||||
beschreibung: "Wartungsarbeiten bevorzugt außerhalb der Kernarbeitszeiten"
|
||||
hinweis: "Kernarbeitszeiten gemäß Service-Definition (verfuegbarkeit.servicezeit)"
|
||||
|
||||
- id: "WF-02"
|
||||
beschreibung: "Vorabkommunikation an betroffene Nutzergruppen (mind. 48h)"
|
||||
ausnahme: "Emergency Changes sind hiervon ausgenommen"
|
||||
|
||||
- id: "WF-03"
|
||||
beschreibung: "Rollback-Plan muss vor Durchführung dokumentiert sein"
|
||||
hinweis: "Gilt auch für Normal Changes an kritischen Services"
|
||||
|
||||
- id: "WF-04"
|
||||
beschreibung: "Bei Major Changes: Abstimmung mit Service Owner und ggf. Kundenvertretung"
|
||||
hinweis: "Erhöhte Sorgfaltspflicht bei geschäftskritischen Services"
|
||||
|
||||
impact_auf_klassifizierung: |
|
||||
Die Geschäftskritikalität eines Services beeinflusst nicht die
|
||||
Change-Typ-Klassifizierung (Standard/Normal/Major/Emergency),
|
||||
sondern die Umsetzungsmodalitäten (Zeitfenster, Kommunikation, Rollback).
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ESKALATION
|
||||
# ---------------------------------------------------------------------------
|
||||
eskalation:
|
||||
|
||||
bei_unsicherheit:
|
||||
beschreibung: |
|
||||
Wenn der SO bei der Klassifizierung oder Bewertung unsicher ist,
|
||||
kann er formlos Rücksprache mit SPM halten.
|
||||
verfahren: "Formlos (Gespräch, E-Mail, Teams)"
|
||||
ergebnis: "SPM gibt Einschätzung, SO entscheidet"
|
||||
|
||||
bei_cross_service:
|
||||
beschreibung: |
|
||||
Bei Changes mit Cross-Service-Impact wird SPM einbezogen.
|
||||
verfahren: "SO informiert SPM, SPM gibt Einschätzung"
|
||||
bei_dissens: "Eskalation an SOR"
|
||||
|
||||
bei_so_dpm_unklarheit:
|
||||
beschreibung: |
|
||||
Wenn unklar ist, ob etwas ein Change oder Demand ist.
|
||||
verfahren: "SO bespricht mit SPM und/oder DPM (ROUTE-SO)"
|
||||
bei_dissens: "Klärung bilateral mit Service Owner (GOV-SHM-029) oder Eskalation an DSR"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# TRANSPARENZ
|
||||
# ---------------------------------------------------------------------------
|
||||
transparenz:
|
||||
|
||||
change_modelle:
|
||||
regel: "SPM erhält Kopie aller Change-Modelle zur Kenntnis"
|
||||
zweck: "Portfolio-Transparenz, nicht Genehmigung"
|
||||
frequenz: "Bei Erstellung/Änderung eines Change-Modells"
|
||||
|
||||
major_changes:
|
||||
regel: "Alle Major Changes werden in SOR behandelt"
|
||||
dokumentation: "SOR-Protokoll"
|
||||
|
||||
reporting:
|
||||
mvp_status: "Kein formales Change-Reporting im MVP"
|
||||
hinweis: "Kann bei Bedarf später ergänzt werden"
|
||||
|
||||
# =============================================================================
|
||||
# 6. ABSCHLUSS
|
||||
# =============================================================================
|
||||
|
||||
abschluss:
|
||||
|
||||
kriterium: |
|
||||
Ein Change gilt als abgeschlossen, wenn der Service Owner die
|
||||
erfolgreiche Umsetzung bestätigt hat.
|
||||
|
||||
bestaetigung:
|
||||
verantwortlich: "Service Owner"
|
||||
form: "Dokumentiert im Change Request / Ticket"
|
||||
inhalt:
|
||||
- "Change wurde wie geplant umgesetzt"
|
||||
- "Service funktioniert wie erwartet"
|
||||
- "Keine unerwarteten Auswirkungen"
|
||||
|
||||
bei_problemen: |
|
||||
Wenn nach Umsetzung Probleme auftreten:
|
||||
- Rollback prüfen (wenn möglich und sinnvoll)
|
||||
- Incident erstellen (wenn Service-Störung)
|
||||
- Ggf. weiteren Change initiieren (Korrektur)
|
||||
|
||||
post_implementation_review:
|
||||
mvp_status: "Nicht formalisiert"
|
||||
beschreibung: |
|
||||
Im MVP gibt es keinen formalen Post-Implementation-Review-Prozess.
|
||||
Der SO bestätigt den Abschluss und beobachtet den Service.
|
||||
|
||||
Bei wiederkehrenden Problemen nach Changes kann ein formaler
|
||||
PIR-Prozess später ergänzt werden.
|
||||
|
||||
# =============================================================================
|
||||
# 8. OFFENE PUNKTE / WEITERENTWICKLUNG
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-CE-001"
|
||||
thema: "Change Schedule"
|
||||
beschreibung: |
|
||||
ITIL4 sieht einen Change Schedule zur Koordination vor.
|
||||
Im MVP nicht implementiert.
|
||||
prioritaet: "niedrig"
|
||||
trigger_fuer_ergaenzung: "Wenn Koordinationsprobleme auftreten"
|
||||
|
||||
- id: "OPEN-CE-002"
|
||||
thema: "Post-Implementation Review"
|
||||
beschreibung: |
|
||||
Formaler PIR-Prozess ist im MVP nicht vorgesehen.
|
||||
prioritaet: "niedrig"
|
||||
trigger_fuer_ergaenzung: "Wenn wiederkehrende Probleme nach Changes auftreten"
|
||||
|
||||
- id: "OPEN-CE-003"
|
||||
thema: "Produkt/Infrastruktur-Changes"
|
||||
beschreibung: |
|
||||
Changes ohne Service-Bezug sind ausgeklammert (GOV-CE-002).
|
||||
prioritaet: "mittel"
|
||||
trigger_fuer_ergaenzung: "Bei Produkt-Konzeption in späterer Phase"
|
||||
|
||||
- id: "OPEN-CE-004"
|
||||
thema: "Formale Cross-Service-Schwellenwerte"
|
||||
beschreibung: |
|
||||
Aktuell SO-Ermessen. Ggf. später Präzisierung basierend auf Erfahrung.
|
||||
prioritaet: "niedrig"
|
||||
trigger_fuer_ergaenzung: "Wenn operative Probleme auftreten"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.3"
|
||||
datum: "2026-02-19"
|
||||
aenderung: |
|
||||
Major-Change-Governance vereinfacht (Kundenvorschlag):
|
||||
- SOR hat bei Major Changes genau EINE Entscheidung (initiale Autorisierung)
|
||||
- Bisheriges Zwei-Entscheidungspunkte-Modell (Entry + Gate 3) aufgelöst
|
||||
- Nach SOR-Autorisierung: Major Change durchläuft regulären Lifecycle
|
||||
(Design/Transition) je nach Einstiegspunkt
|
||||
- SOR legt als Teil der Autorisierung den Einstiegspunkt fest
|
||||
- Alle Lifecycle-Gates (Gate 1, 2, 3) sind reguläre Gates
|
||||
- Change Authority Matrix, Verfahren, Schnittstelle Transition angepasst
|
||||
autor: "DIGITOM-Projekt"
|
||||
kontext: "Vereinfachung auf Basis Kunden-Annotation: Major Change kann diverse Wege nehmen"
|
||||
|
||||
- version: "1.2"
|
||||
datum: "2026-01-31"
|
||||
aenderung: |
|
||||
Korrektur Major-Change-Routing:
|
||||
- Verfahren präzisiert: SOR-Autorisierung vor Entry in Transition erforderlich
|
||||
- Change Authority Matrix ergänzt: Zwei Entscheidungspunkte (Entry + Gate 3)
|
||||
- Klarstellung: Major Change unterscheidet sich vom Normal Change durch
|
||||
die obligatorische SOR-Autorisierung, nicht nur durch die Gate-3-Freigabe
|
||||
autor: "DIGITOM-Projekt"
|
||||
kontext: "Konzeptionelle Korrektur auf Basis Review"
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2026-01-28"
|
||||
aenderung: |
|
||||
Ergänzung Wartungsfenster kritische Services:
|
||||
- Neuer Abschnitt 'wartungsfenster_kritische_services' (GOV-CE-004)
|
||||
- Anforderungen WF-01 bis WF-04 für geschäftskritische Services
|
||||
- Referenz auf Service-Kritikalität aus spm_schema_service-definition.yaml
|
||||
autor: "DIGITOM-Projekt"
|
||||
kontext: "Integration Geschäftskritikalität in Change-Planung"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-17"
|
||||
aenderung: |
|
||||
Initiale Erstellung des Change Enablement Konzepts.
|
||||
|
||||
Inhalt:
|
||||
- Change-Typen (Standard, Normal, Major, Emergency)
|
||||
- Klassifizierungsverfahren
|
||||
- Change Authority Matrix
|
||||
- Schnittstellen (SHM, Transition, Problem Management, DPM)
|
||||
- Governance-Entscheidungen GOV-CE-001 bis GOV-CE-003
|
||||
|
||||
Konsolidiert aus:
|
||||
- GOV-TR-003 (Major-Kriterien)
|
||||
- Klärungen CE-01 bis CE-03
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,814 @@
|
|||
# =============================================================================
|
||||
# PRACTICE: SERVICE CATALOG MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "P-01"
|
||||
name: "Service Catalog Management"
|
||||
version: "0.2"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-27"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "practice-konzept"
|
||||
|
||||
funktion:
|
||||
id: "SPM"
|
||||
name: "Service-Portfolio-Management"
|
||||
|
||||
taxonomie_referenz: "00_meta/digitom_taxonomie.yaml"
|
||||
|
||||
beschreibung: >
|
||||
Service Catalog Management stellt sicher, dass für jeden Service eine
|
||||
klare, aktuelle, vollständige und verlässliche Beschreibung existiert –
|
||||
und alle Stakeholder auf dieselbe Wahrheit zugreifen. Die Practice
|
||||
fungiert als Informations-Governance über alle Services und bildet die
|
||||
Brücke zwischen Service-Portfolio (strategisch), Service-Definition
|
||||
(operativ) und Service Level Management (qualitativ).
|
||||
|
||||
itil4_referenz: "Service Catalogue Management Practice"
|
||||
|
||||
lifecycle_phasen:
|
||||
- design
|
||||
- transition
|
||||
- operation
|
||||
- review
|
||||
|
||||
practice_owner: "Service-Portfolio-Manager (SPM)"
|
||||
|
||||
konsolidierung_hinweis: >
|
||||
Im MVP ist die Practice Owner-Rolle für SCM mit der SPM-Rolle
|
||||
konsolidiert, um Rolleninflation zu vermeiden. Langfristig kann
|
||||
eine Trennung sinnvoll sein.
|
||||
|
||||
schnittstellen:
|
||||
intern:
|
||||
- modul: "P-02 Service Level Management"
|
||||
art: "erhält von"
|
||||
beschreibung: "SLS/SLA-Referenzen zur Publikation im Katalog"
|
||||
|
||||
- modul: "B-01 Service Transition"
|
||||
art: "bidirektional"
|
||||
beschreibung: "Katalogaufnahme als Teil des Transition-Prozesses"
|
||||
|
||||
- modul: "B-03 Service Review"
|
||||
art: "bidirektional"
|
||||
beschreibung: "Review-Ergebnisse können Katalogänderungen triggern"
|
||||
|
||||
extern:
|
||||
- partner: "Stakeholder-Management (SHM)"
|
||||
kontext: "Qualitätssicherung Kundenverständlichkeit"
|
||||
status: "SHM-Modul in Entwicklung"
|
||||
|
||||
- partner: "ITSM-Tool (Request-Katalog)"
|
||||
kontext: "Stammdatenlieferung für Service-Requests"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# KERNKONZEPTE
|
||||
# =============================================================================
|
||||
|
||||
kernkonzepte:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ZENTRALE ARTEFAKTE
|
||||
# ---------------------------------------------------------------------------
|
||||
artefakte:
|
||||
beschreibung: >
|
||||
SCM verwaltet zwei zentrale Artefakte, die in einer
|
||||
Master-Derivat-Beziehung stehen.
|
||||
|
||||
artefakte:
|
||||
- name: "Service-Definition"
|
||||
typ: "Master-Dokument"
|
||||
beschreibung: >
|
||||
Internes Dokument mit allen relevanten Informationen zu einem
|
||||
Service. Single Source of Truth für DIGIT.
|
||||
schema: "02.5_informationsmodell/spm_schema_service-definition.yaml"
|
||||
verantwortung_erstellung: "Service Owner"
|
||||
verantwortung_validierung: "SPM (als SCM Practice Owner)"
|
||||
|
||||
- name: "Service-Steckbrief"
|
||||
typ: "Derivat"
|
||||
beschreibung: >
|
||||
Kundenorientierter Auszug aus der Service-Definition.
|
||||
Wird im Service-Katalog publiziert.
|
||||
schema: "02.5_informationsmodell/spm_schema_service-steckbrief.yaml"
|
||||
verantwortung_ableitung: "Service Owner"
|
||||
verantwortung_freigabe: "SPM"
|
||||
verantwortung_publikation: "SPM"
|
||||
|
||||
beziehung: >
|
||||
Der Service-Steckbrief wird aus der Service-Definition abgeleitet.
|
||||
Änderungen an der Service-Definition können Aktualisierungen des
|
||||
Steckbriefs erfordern. Das Mapping ist im Schema dokumentiert.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE-KATALOG
|
||||
# ---------------------------------------------------------------------------
|
||||
service_katalog:
|
||||
beschreibung: >
|
||||
Der Service-Katalog ist kein einzelnes Tool, sondern ein logisches
|
||||
Konstrukt: die offizielle, konsolidierte Sicht auf alle angebotenen
|
||||
Services des DIGIT mit ihren wesentlichen Merkmalen.
|
||||
Diese Sicht wird in geeigneten Werkzeugen (z. B. Intranet-Portal,
|
||||
ITSM-Tool, Dokumentation) für unterschiedliche Zielgruppen
|
||||
bereitgestellt.
|
||||
|
||||
inhalt: "Alle Service-Steckbriefe für Services im Status 'Live'"
|
||||
|
||||
nicht_enthalten:
|
||||
- "Services in der Pipeline (noch nicht live)"
|
||||
- "Stillgelegte Services (retired)"
|
||||
- "Interne Services (Kategorie I) – per Definition nicht im Katalog (GOV-SPM-I-001, GOV-SPM-I-003)"
|
||||
|
||||
ausschlussregel_kategorie_I:
|
||||
beschreibung: |
|
||||
Der Service-Katalog enthält ausschließlich Kundenservices der
|
||||
Kategorien A, B und C. Interne Services (Kategorie I) werden
|
||||
NICHT im Katalog publiziert. Die Sichtbarkeit ist vollständig
|
||||
aus der Service-Kategorie ableitbar – ein separates Attribut
|
||||
service_sichtbarkeit existiert nicht.
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003, VAL-007"
|
||||
|
||||
publikationskanaele:
|
||||
beschreibung: >
|
||||
Der Katalog kann über verschiedene Kanäle zugänglich gemacht werden.
|
||||
Die konkrete Implementierung ist nicht Teil dieser Practice-Definition.
|
||||
|
||||
stakeholder_einbindung:
|
||||
beschreibung: >
|
||||
Das Stakeholder-Management (SHM) unterstützt bei der Formulierung
|
||||
kundenverständlicher Texte und bei der Priorisierung von
|
||||
Verbesserungsbedarfen aus Sicht der Ämter.
|
||||
Im MVP ist dies optional, im Zielbild standardmäßig vorgesehen.
|
||||
|
||||
anforderungen:
|
||||
- "Barrierefreier Zugang für alle Zielgruppen"
|
||||
- "Durchsuchbarkeit"
|
||||
- "Aktualität (zeitnahe Publikation von Änderungen)"
|
||||
- "Kategorie-basierte Sichtbarkeitssteuerung"
|
||||
|
||||
moegliche_kanaele:
|
||||
- "Intranet-Seite"
|
||||
- "Self-Service-Portal"
|
||||
- "ITSM-Tool (Request-Katalog-View)"
|
||||
- "PDF-Export (für Offline-Nutzung)"
|
||||
|
||||
verantwortung_inhalt: "SPM"
|
||||
verantwortung_betrieb: "TBD (abhängig von Kanal)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KATALOG-VIEWS
|
||||
# ---------------------------------------------------------------------------
|
||||
katalog_views:
|
||||
beschreibung: >
|
||||
Der Katalog unterstützt unterschiedliche Sichten für
|
||||
unterschiedliche Zielgruppen.
|
||||
|
||||
views:
|
||||
- name: "Nutzer-View"
|
||||
zielgruppe: "Alle Mitarbeitenden"
|
||||
fokus: "Was gibt es? Was bekomme ich? Wie beantrage ich?"
|
||||
inhalte:
|
||||
- "Alle Basis-Services (Kategorie A)"
|
||||
- "Alle Erweiterten Services (Kategorie B)"
|
||||
- "Spezial-Services nur wenn berechtigt (Kategorie C)"
|
||||
|
||||
- name: "Entscheider-View"
|
||||
zielgruppe: "Amtsleitungen, Kundenvertretungen"
|
||||
fokus: "Welche Services nutzt mein Amt? Welche Qualität? Welche Kosten?"
|
||||
inhalte:
|
||||
- "Alle Services mit SLA/SLS-Referenzen"
|
||||
- "Service-Owner-Kontakte"
|
||||
- "Berechtigungslogik"
|
||||
|
||||
- name: "Request-View"
|
||||
zielgruppe: "Mitarbeitende (im ITSM-Tool)"
|
||||
fokus: "Was kann ich bestellen/beantragen?"
|
||||
inhalte:
|
||||
- "Bestellbare Services"
|
||||
- "Beantragungswege"
|
||||
- "Voraussetzungen"
|
||||
hinweis: "Diese View wird im ITSM-Tool realisiert, nicht im Katalog selbst"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KATEGORIEN IM KATALOG
|
||||
# ---------------------------------------------------------------------------
|
||||
kategorien_logik:
|
||||
beschreibung: >
|
||||
Die Service-Kategorien A/B/C (definiert in P-02 SLM) haben
|
||||
direkte Auswirkungen auf die Katalogdarstellung.
|
||||
|
||||
kategorie_a:
|
||||
name: "Basis-Services"
|
||||
katalog_sichtbarkeit: "Für alle sichtbar"
|
||||
katalog_darstellung: "Vollständiger Steckbrief"
|
||||
service_level_anzeige: "SLS-Referenz"
|
||||
beantragung_hinweis: "Automatische Bereitstellung, keine Beantragung nötig"
|
||||
|
||||
kategorie_b:
|
||||
name: "Erweiterte Services"
|
||||
katalog_sichtbarkeit: "Für alle sichtbar"
|
||||
katalog_darstellung: "Vollständiger Steckbrief"
|
||||
service_level_anzeige: "SLS-Referenz"
|
||||
beantragung_hinweis: "Beantragung über definierten Weg"
|
||||
|
||||
kategorie_c:
|
||||
name: "Spezial-Services"
|
||||
katalog_sichtbarkeit: "Eingeschränkt (nur berechtigte Ämter)"
|
||||
katalog_darstellung: "Reduzierter Steckbrief oder Verweis"
|
||||
service_level_anzeige: "Verweis auf bilaterales SLA"
|
||||
beantragung_hinweis: "Kontakt über Service Owner"
|
||||
|
||||
kategorie_i:
|
||||
name: "Interne Services"
|
||||
katalog_sichtbarkeit: "NICHT im Katalog (per Definition)"
|
||||
katalog_darstellung: "Kein Steckbrief – nur Service-Definition (intern)"
|
||||
service_level_anzeige: "OLA (intern, nicht publiziert)"
|
||||
beantragung_hinweis: "Kein Beantragungsweg – rein interne Steuerung"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABGRENZUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
abgrenzung:
|
||||
beschreibung: "Was SCM NICHT ist"
|
||||
|
||||
nicht_ziele:
|
||||
- aspekt: "Request-Katalog / Ticketing"
|
||||
abgrenzung: >
|
||||
SCM liefert Stammdaten an das ITSM-Tool.
|
||||
Die Request-Abwicklung ist Aufgabe von P-05 Request Management.
|
||||
|
||||
- aspekt: "IT-Serviceportal"
|
||||
abgrenzung: >
|
||||
SCM definiert Inhalte und Struktur.
|
||||
Der Portal-Betrieb ist eine separate Verantwortung.
|
||||
|
||||
- aspekt: "Technische Dokumentation"
|
||||
abgrenzung: >
|
||||
SCM fokussiert auf kundenrelevante Informationen.
|
||||
Technische Details gehören in Betriebshandbücher.
|
||||
|
||||
- aspekt: "Governance-Gremium"
|
||||
abgrenzung: >
|
||||
SCM ist ein Prozess, kein Gremium.
|
||||
Entscheidungen werden in SOR/MB getroffen.
|
||||
|
||||
- aspekt: "Service-Portfolio-Steuerung"
|
||||
abgrenzung: >
|
||||
SCM publiziert den Katalog (Live-Services).
|
||||
Die Portfolio-Steuerung (Pipeline, Retire) liegt bei SPM.
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: TRANSITION
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_transition:
|
||||
beschreibung: >
|
||||
Aktivitäten zur Aufnahme neuer Services in den Katalog,
|
||||
typischerweise am Ende der Service-Transition-Phase.
|
||||
|
||||
aktivitaeten:
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_01
|
||||
name: "Service-Definition validieren"
|
||||
|
||||
beschreibung: >
|
||||
Prüfung der vom Service Owner erstellten Service-Definition
|
||||
auf Vollständigkeit, Konsistenz und Konformität mit dem Schema.
|
||||
|
||||
ausloeser:
|
||||
- "Neuer Service erreicht Transition-Phase"
|
||||
- "Wesentliche Service-Änderung (aus Demand)"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Definition (Entwurf)"
|
||||
quelle: "Service Owner"
|
||||
- artefakt: "SLS/SLA-Referenz"
|
||||
quelle: "P-02 Service Level Management"
|
||||
|
||||
umfasst:
|
||||
- "Prüfung gegen Schema (Pflichtfelder, Datentypen)"
|
||||
- "Prüfung Konsistenz mit Service-Kategorie"
|
||||
- "Prüfung SLS/SLA-Referenz vorhanden und korrekt"
|
||||
- "Prüfung Abhängigkeiten dokumentiert"
|
||||
- "Rückmeldung an Service Owner bei Mängeln"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Definition (validiert)"
|
||||
ziel: "scm_02"
|
||||
- artefakt: "Validierungsprotokoll"
|
||||
ziel: "Dokumentation"
|
||||
|
||||
qualitaets_gate:
|
||||
name: "Service-Definition vollständig"
|
||||
kriterien:
|
||||
- "Alle Pflichtfelder ausgefüllt"
|
||||
- "Schema-Validierung erfolgreich"
|
||||
- "SLS/SLA-Referenz vorhanden"
|
||||
|
||||
raci:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Liefert Service-Definition, behebt Mängel"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Verantwortet Validierung (als SCM Practice Owner)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_02
|
||||
name: "Service-Steckbrief erstellen"
|
||||
|
||||
beschreibung: >
|
||||
Ableitung des kundenorientierten Service-Steckbriefs
|
||||
aus der validierten Service-Definition.
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Definition (validiert)"
|
||||
quelle: "scm_01"
|
||||
|
||||
umfasst:
|
||||
- "Extraktion der kundenrelevanten Attribute"
|
||||
- "Transformation in kundenverständliche Sprache"
|
||||
- "Ableitung kategorie-spezifischer Hinweise"
|
||||
- "Erstellung Datenschutz-Hinweis"
|
||||
- "Verknüpfung mit Dokumenten (SLS, Handbücher)"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Steckbrief (Entwurf)"
|
||||
ziel: "scm_03"
|
||||
|
||||
raci:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Erstellt Steckbrief-Entwurf"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Verantwortet Prozess"
|
||||
- rolle: shm
|
||||
raci: C
|
||||
kontext: "Prüft Kundenverständlichkeit (optional)"
|
||||
|
||||
hinweis_shm: >
|
||||
Die Einbindung von SHM zur Qualitätssicherung der
|
||||
Kundenverständlichkeit ist empfohlen, aber im MVP optional.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_03
|
||||
name: "Service-Steckbrief freigeben"
|
||||
|
||||
beschreibung: >
|
||||
Formale Freigabe des Service-Steckbriefs zur Publikation.
|
||||
Die Freigabe-Instanz hängt von der Art der Aufnahme ab.
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Steckbrief (Entwurf)"
|
||||
quelle: "scm_02"
|
||||
|
||||
umfasst:
|
||||
- "Finale Qualitätsprüfung"
|
||||
- "Prüfung Konsistenz mit Service-Definition"
|
||||
- "Freigabe-Entscheidung"
|
||||
|
||||
freigabe_logik:
|
||||
beschreibung: >
|
||||
Die Freigabe des Steckbriefs ist Teil der Service-Transition-Freigabe.
|
||||
Bei isolierten Steckbrief-Änderungen gilt die Änderungs-Governance.
|
||||
|
||||
neuer_service: "SOR (als Teil der Transition-Freigabe)"
|
||||
aenderung_major: "SOR"
|
||||
aenderung_minor: "SPM"
|
||||
aenderung_redaktionell: "SO"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Steckbrief (freigegeben)"
|
||||
ziel: "scm_04"
|
||||
|
||||
raci:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Erstellt und pflegt Steckbrief"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Accountable für redaktionelle/minor-Freigaben und Governance-Konsistenz"
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Accountable für Freigaben mit größerem Impact (z. B. neue Services, Major-Änderungen)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_04
|
||||
name: "Service-Steckbrief publizieren"
|
||||
|
||||
beschreibung: >
|
||||
Veröffentlichung des freigegebenen Service-Steckbriefs
|
||||
im Service-Katalog und ggf. im ITSM-Tool.
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Steckbrief (freigegeben)"
|
||||
quelle: "scm_03"
|
||||
|
||||
umfasst:
|
||||
- "Eintrag in Service-Katalog"
|
||||
- "Konfiguration Sichtbarkeit (nach Kategorie)"
|
||||
- "Synchronisation mit ITSM-Tool (falls vorhanden)"
|
||||
- "Benachrichtigung relevanter Stakeholder"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Steckbrief (publiziert)"
|
||||
ziel: "Service-Katalog"
|
||||
|
||||
raci:
|
||||
- rolle: spm
|
||||
raci: A/R
|
||||
kontext: "Führt Publikation durch"
|
||||
- rolle: service_owner
|
||||
raci: I
|
||||
kontext: "Wird über Publikation informiert"
|
||||
|
||||
hinweis_itsm: >
|
||||
Die Synchronisation mit dem ITSM-Tool ist abhängig von der
|
||||
Tool-Auswahl. Im MVP kann dies ein manueller Schritt sein.
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: BETRIEB
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_betrieb:
|
||||
beschreibung: >
|
||||
Aktivitäten zur laufenden Pflege des Service-Katalogs.
|
||||
|
||||
aktivitaeten:
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_05
|
||||
name: "Katalogänderung bearbeiten"
|
||||
|
||||
beschreibung: >
|
||||
Bearbeitung von Änderungsbedarfen an Service-Definitionen
|
||||
und Service-Steckbriefen.
|
||||
|
||||
ausloeser:
|
||||
- "Service Owner meldet Änderungsbedarf"
|
||||
- "SLS/SLA-Änderung (aus P-02)"
|
||||
- "Organisatorische Änderung (z.B. neuer Service Owner)"
|
||||
- "Feedback von Nutzern/Kunden"
|
||||
|
||||
umfasst:
|
||||
- "Klassifikation der Änderung (redaktionell/minor/major)"
|
||||
- "Aktualisierung Service-Definition"
|
||||
- "Aktualisierung Service-Steckbrief"
|
||||
- "Durchlaufen des Freigabeprozesses (nach Änderungstyp)"
|
||||
- "Publikation der Änderung"
|
||||
|
||||
aenderungstypen:
|
||||
- typ: "redaktionell"
|
||||
beispiele:
|
||||
- "Korrektur Tippfehler"
|
||||
- "Aktualisierung Kontaktdaten"
|
||||
- "Formatierungsanpassung"
|
||||
entscheidung: "Service Owner (autonom)"
|
||||
freigabe: "Keine separate Freigabe nötig"
|
||||
|
||||
- typ: "inhaltlich_minor"
|
||||
beispiele:
|
||||
- "Ergänzung FAQ oder Dokument-Link"
|
||||
- "Klarstellung Leistungsumfang (ohne Änderung)"
|
||||
- "Aktualisierung Voraussetzungen"
|
||||
entscheidung: "Service Owner + SPM (bilateral)"
|
||||
freigabe: "SPM"
|
||||
|
||||
- typ: "inhaltlich_major"
|
||||
beispiele:
|
||||
- "Änderung Leistungsumfang"
|
||||
- "Änderung Service Levels"
|
||||
- "Änderung Zielgruppe oder Kategorie"
|
||||
entscheidung: "SOR"
|
||||
freigabe: "SOR"
|
||||
hinweis: "Meist gekoppelt an Service-Definition-Änderung"
|
||||
|
||||
raci:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Initiiert und beschreibt Änderungsbedarf"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Accountable für minor/standard-Kataloganpassungen und übergreifende Konsistenz"
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Accountable für Major-Änderungen mit Portfolio-/Governance-Relevanz"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_06
|
||||
name: "Service aus Katalog entfernen"
|
||||
|
||||
beschreibung: >
|
||||
Entfernung eines stillgelegten Services aus dem Katalog
|
||||
(Übergang von "Live" zu "Retired").
|
||||
|
||||
ausloeser:
|
||||
- "Service-Stilllegung beschlossen (B-03 Service Review)"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Stilllegungsbeschluss"
|
||||
quelle: "SOR oder Mission Board"
|
||||
|
||||
umfasst:
|
||||
- "Kennzeichnung als 'stillgelegt' im Katalog"
|
||||
- "Kommunikation an betroffene Nutzer/Ämter"
|
||||
- "Übergangszeit definieren (falls nötig)"
|
||||
- "Endgültige Entfernung aus öffentlichem Katalog"
|
||||
- "Archivierung der Service-Definition"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Definition (archiviert)"
|
||||
ziel: "Archiv"
|
||||
- artefakt: "Katalog aktualisiert"
|
||||
|
||||
raci:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Koordiniert Kommunikation"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Verantwortet Katalogaktualisierung"
|
||||
- rolle: shm
|
||||
raci: C
|
||||
kontext: "Unterstützt Kundenkommunikation"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: REVIEW
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_review:
|
||||
beschreibung: >
|
||||
Aktivitäten zur regelmäßigen Überprüfung des gesamten Katalogs.
|
||||
|
||||
aktivitaeten:
|
||||
# -------------------------------------------------------------------------
|
||||
- id: scm_07
|
||||
name: "Jährlichen Katalog-Review durchführen"
|
||||
|
||||
beschreibung: >
|
||||
Systematische Überprüfung aller Service-Definitionen und
|
||||
Service-Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz.
|
||||
|
||||
frequenz: "Jährlich"
|
||||
|
||||
ausloeser:
|
||||
- "Jährlicher Review-Zyklus"
|
||||
- "Wesentliche organisatorische Änderungen"
|
||||
- "Neue Compliance-Anforderungen"
|
||||
|
||||
umfasst:
|
||||
- "Prüfung aller Service-Definitionen auf Aktualität"
|
||||
- "Prüfung Konsistenz mit tatsächlicher Service-Erbringung"
|
||||
- "Prüfung SLS/SLA-Referenzen aktuell"
|
||||
- "Prüfung Kontaktdaten aktuell"
|
||||
- "Identifikation verwaister Services (kein aktiver SO)"
|
||||
- "Identifikation Inkonsistenzen"
|
||||
- "Ableitung Maßnahmenliste"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Katalog-Review-Bericht"
|
||||
ziel: "SOR / Mission Board"
|
||||
- artefakt: "Maßnahmenliste"
|
||||
ziel: "Service Owner (zur Umsetzung)"
|
||||
|
||||
raci:
|
||||
- rolle: spm
|
||||
raci: A/R
|
||||
kontext: "Führt Review durch, erstellt Bericht"
|
||||
- rolle: service_owner
|
||||
raci: C
|
||||
kontext: "Liefert Informationen zu ihren Services"
|
||||
- rolle: sor
|
||||
raci: I
|
||||
kontext: "Erhält Bericht, entscheidet bei Eskalation"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-ENTSCHEIDUNGEN
|
||||
# =============================================================================
|
||||
|
||||
governance_entscheidungen:
|
||||
|
||||
- id: "GOV-006"
|
||||
datum: "2025-11-27"
|
||||
frage: "Wer ist Practice Owner für Service Catalog Management?"
|
||||
entscheidung: >
|
||||
Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM.
|
||||
Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden.
|
||||
begruendung: >
|
||||
SPM und SCM operieren beide auf Portfolio-Ebene und haben
|
||||
natürliche Nähe. Eine Trennung ist langfristig möglich,
|
||||
aber für die Einführungsphase nicht nötig.
|
||||
status: "final"
|
||||
|
||||
- id: "GOV-007"
|
||||
datum: "2025-11-27"
|
||||
frage: "Wer erstellt die Service-Definition?"
|
||||
entscheidung: >
|
||||
Der Service Owner ist verantwortlich (Accountable) für die Erstellung
|
||||
der Service-Definition. SPM validiert und gibt frei.
|
||||
begruendung: >
|
||||
ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung
|
||||
für den Service. Die Service-Definition ist Teil dieser Verantwortung.
|
||||
SCM stellt Methodik, Templates und Qualitätssicherung bereit.
|
||||
status: "final"
|
||||
|
||||
- id: "GOV-008"
|
||||
datum: "2025-11-27"
|
||||
frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?"
|
||||
entscheidung: |
|
||||
Dreistufige Governance nach Impact:
|
||||
1. Redaktionelle Änderungen: Service Owner (autonom)
|
||||
2. Inhaltlich-minor: Service Owner + SPM (bilateral)
|
||||
3. Inhaltlich-major / Neuaufnahme: SOR
|
||||
|
||||
Strukturelle Änderungen (Kategorie-Wechsel, Stilllegung): Mission Board
|
||||
begruendung: >
|
||||
Vermeidet Überlastung des SOR/MB mit Kleinstthemen.
|
||||
Operative Themen werden operativ gelöst.
|
||||
Nur portfolio-relevante Entscheidungen eskalieren.
|
||||
status: "final"
|
||||
|
||||
- id: "GOV-009"
|
||||
datum: "2025-11-27"
|
||||
frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?"
|
||||
entscheidung: >
|
||||
SHM wird eingebunden für die Prüfung der Kundenverständlichkeit
|
||||
von Service-Steckbriefen. Im MVP ist dies optional (Empfehlung),
|
||||
da das SHM-Modul noch in Entwicklung ist.
|
||||
begruendung: >
|
||||
SHM hat die Kompetenz für Kundenperspektive und -sprache.
|
||||
Die Schnittstelle sollte etabliert werden, sobald SHM
|
||||
operativ ist.
|
||||
status: "draft"
|
||||
abhaengig_von: "Finalisierung SHM-Modul"
|
||||
|
||||
- id: "GOV-010"
|
||||
datum: "2025-11-27"
|
||||
frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?"
|
||||
entscheidung: >
|
||||
SCM (SPM) verantwortet den Inhalt des Katalogs.
|
||||
Der Betrieb des Publikationskanals ist eine separate Verantwortung,
|
||||
die im MVP noch zu klären ist (Webteam, IT-Betrieb, o.ä.).
|
||||
begruendung: >
|
||||
Trennung von Inhalt (SCM) und Betrieb (Technik).
|
||||
Vermeidet, dass SCM zur Portal-Betriebs-Instanz wird.
|
||||
status: "draft"
|
||||
offene_frage: "Wer ist konkret für Portal-Betrieb zuständig?"
|
||||
|
||||
# =============================================================================
|
||||
# METRIKEN
|
||||
# =============================================================================
|
||||
|
||||
metriken:
|
||||
|
||||
prozess_metriken:
|
||||
- name: "Katalog-Abdeckung"
|
||||
beschreibung: >-
|
||||
Anteil der Live-Services, für die ein freigegebener Service-Steckbrief
|
||||
im Service-Katalog publiziert ist.
|
||||
ziel: "100%"
|
||||
messung: "Anzahl publizierte Steckbriefe / Anzahl Services mit Status 'Live'"
|
||||
|
||||
- name: "Steckbrief-Aktualität"
|
||||
beschreibung: "Anteil der Steckbriefe, die im letzten Jahr geprüft wurden"
|
||||
ziel: "100%"
|
||||
messung: "Anzahl Steckbriefe mit Review < 12 Monate / Gesamtanzahl"
|
||||
|
||||
- name: "Durchlaufzeit Katalogaufnahme"
|
||||
beschreibung: "Zeit von Transition-Start bis Katalogpublikation"
|
||||
ziel: "< 10 Arbeitstage"
|
||||
messung: "Durchschnitt über alle Neuaufnahmen"
|
||||
|
||||
qualitaets_metriken:
|
||||
- name: "Schema-Konformität"
|
||||
beschreibung: "Anteil der Service-Definitionen ohne Validierungsfehler"
|
||||
ziel: "100%"
|
||||
|
||||
- name: "Verständlichkeits-Score"
|
||||
beschreibung: "Bewertung der Steckbriefe durch SHM/Nutzer"
|
||||
ziel: "Definition ausstehend"
|
||||
hinweis: "Einführung nach SHM-Operationalisierung"
|
||||
|
||||
# =============================================================================
|
||||
# TOOLING-ANFORDERUNGEN
|
||||
# =============================================================================
|
||||
|
||||
tooling:
|
||||
|
||||
service_katalog_ablage:
|
||||
beschreibung: >
|
||||
Speicherort für Service-Definitionen und Service-Steckbriefe.
|
||||
Im MVP kann dies ein strukturiertes Verzeichnis sein.
|
||||
|
||||
anforderungen:
|
||||
- "Versionierung"
|
||||
- "Zugriffssteuerung (SO kann eigene Services bearbeiten)"
|
||||
- "Such- und Filterfunktion"
|
||||
|
||||
optionen:
|
||||
- "Confluence/Wiki"
|
||||
- "SharePoint"
|
||||
- "Git-Repository"
|
||||
- "Dediziertes ITSM-/CMDB-Tool"
|
||||
|
||||
mvp_loesung: "TBD"
|
||||
|
||||
itsm_integration:
|
||||
beschreibung: >
|
||||
Schnittstelle zum ITSM-Tool für den Request-Katalog.
|
||||
|
||||
anforderungen:
|
||||
- "Service-ID als eindeutiger Schlüssel"
|
||||
- "Unidirektionale Synchronisation (SCM → ITSM)"
|
||||
- "Kategorie-basierte Sichtbarkeitssteuerung"
|
||||
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
hinweis: >
|
||||
Im MVP kann die Synchronisation manuell erfolgen.
|
||||
Eine automatisierte Schnittstelle ist Ziel, aber nicht MVP-kritisch.
|
||||
|
||||
cmdb_integration:
|
||||
beschreibung: >
|
||||
Schnittstelle zur CMDB für Abhängigkeitsinformationen.
|
||||
|
||||
status: "Placeholder"
|
||||
|
||||
hinweis: >
|
||||
CMDB ist nicht Teil des MVP. Abhängigkeiten werden manuell
|
||||
in der Service-Definition gepflegt. Langfristig sollte eine
|
||||
bidirektionale Synchronisation etabliert werden.
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-P01-001"
|
||||
beschreibung: "Template Service-Definition erstellen (Markdown)"
|
||||
prioritaet: "hoch"
|
||||
ziel_ordner: "02.6_arbeitsmaterialien"
|
||||
abhaengig_von: "Finalisierung Schema"
|
||||
|
||||
- id: "OPEN-P01-002"
|
||||
beschreibung: "Template Service-Steckbrief erstellen (Markdown/HTML)"
|
||||
prioritaet: "hoch"
|
||||
ziel_ordner: "02.6_arbeitsmaterialien"
|
||||
abhaengig_von: "Finalisierung Schema"
|
||||
|
||||
- id: "OPEN-P01-003"
|
||||
beschreibung: "Checkliste Katalog-Review erstellen"
|
||||
prioritaet: "mittel"
|
||||
ziel_ordner: "02.6_arbeitsmaterialien"
|
||||
|
||||
- id: "OPEN-P01-004"
|
||||
beschreibung: "Klärung Publikationskanal und Betriebsverantwortung"
|
||||
prioritaet: "mittel"
|
||||
status: "Abstimmung mit IT-Betrieb/Webteam nötig"
|
||||
|
||||
- id: "OPEN-P01-005"
|
||||
beschreibung: "SHM-Einbindung operationalisieren"
|
||||
prioritaet: "niedrig"
|
||||
abhaengig_von: "Finalisierung SHM-Modul"
|
||||
|
||||
- id: "OPEN-P01-006"
|
||||
beschreibung: "ITSM-Tool-Integration spezifizieren"
|
||||
prioritaet: "niedrig"
|
||||
abhaengig_von: "Tool-Auswahl"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.4"
|
||||
datum: "2026-03-09"
|
||||
aenderung: |
|
||||
- Kategorie I (Interne Services) in kategorien_logik und Katalog-Ausschlussregel ergänzt
|
||||
- Expliziter Hinweis: Katalog enthält ausschließlich Kategorie A, B, C
|
||||
- nicht_enthalten-Liste aktualisiert (Verweis auf GOV-SPM-I-001, GOV-SPM-I-003)
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "PENDING-SPM-001, DC-001, DC-003"
|
||||
|
||||
- version: "0.3"
|
||||
datum: "2026-01-31"
|
||||
aenderung: "Metrik 'Katalog-Abdeckung' präzisiert: Bezug auf Steckbriefe statt Definitionen"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "Begriffskonsistenz Portfolio/Katalog vs. Definition/Steckbrief"
|
||||
|
||||
- version: "0.2"
|
||||
datum: "2026-01-30"
|
||||
aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-11-27"
|
||||
aenderung: "Initiale Practice-Konzeption"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,832 @@
|
|||
# =============================================================================
|
||||
# PRACTICE: SERVICE LEVEL MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "P-02"
|
||||
name: "Service Level Management"
|
||||
version: "0.2"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-26"
|
||||
aktualisiert: "2026-01-30"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "practice-konzept"
|
||||
|
||||
funktion:
|
||||
id: "SPM"
|
||||
name: "Service-Portfolio-Management"
|
||||
|
||||
taxonomie_referenz: "00_meta/digitom_taxonomie.yaml"
|
||||
|
||||
beschreibung: >
|
||||
Etabliert ein gemeinsames Verständnis von Servicequalität zwischen
|
||||
DIGIT und seinen Kunden. Umfasst Definition, Vereinbarung, Überwachung
|
||||
und Review von Service Levels – differenziert nach Service-Kategorien.
|
||||
|
||||
itil4_referenz: "Service Level Management Practice"
|
||||
|
||||
lifecycle_phasen:
|
||||
- design
|
||||
- transition
|
||||
- operation
|
||||
- review
|
||||
|
||||
schnittstellen:
|
||||
intern:
|
||||
- modul: "P-01 Service Catalog Management"
|
||||
art: "liefert an"
|
||||
beschreibung: "SLS wird im Service-Katalog publiziert"
|
||||
|
||||
- modul: "P-07 Monitoring & Event Management"
|
||||
art: "erhält von"
|
||||
beschreibung: "Messdaten für Service-Level-Überwachung"
|
||||
|
||||
- modul: "B-02 Service Betrieb"
|
||||
art: "bidirektional"
|
||||
beschreibung: "Qualitätsbericht als Input, SLA-Ziele als Vorgabe"
|
||||
|
||||
- modul: "B-03 Service Review"
|
||||
art: "bidirektional"
|
||||
beschreibung: "Interner Review als Vorbereitung für externen SLA-Review"
|
||||
|
||||
extern:
|
||||
- partner: "Kundenvertretung Basisservices"
|
||||
kontext: "SLA-Partner für Kategorie A"
|
||||
zusammensetzung: "Amtsleitungen oder delegierte Vertreter"
|
||||
|
||||
- partner: "Kundenvertretungen (servicespezifisch)"
|
||||
kontext: "SLA-Partner für Kategorie B"
|
||||
zusammensetzung: "Amtsleitungen nutzender Ämter oder delegierte Vertreter"
|
||||
|
||||
- partner: "Amtsleitungen (bilateral)"
|
||||
kontext: "SLA-Partner für Kategorie C"
|
||||
|
||||
# =============================================================================
|
||||
# KERNKONZEPTE
|
||||
# =============================================================================
|
||||
|
||||
kernkonzepte:
|
||||
|
||||
service_kategorien:
|
||||
beschreibung: >
|
||||
Das Service-Portfolio wird in drei Kategorien stratifiziert,
|
||||
die unterschiedliche SLA-Governance-Modelle erfordern.
|
||||
|
||||
kategorien:
|
||||
- id: "A"
|
||||
name: "Basis-Services"
|
||||
charakteristik: "Flächendeckend, umlagefinanziert, nicht abwählbar"
|
||||
sla_partner: "Kundenvertretung Basisservices"
|
||||
sla_partner_zusammensetzung: |
|
||||
- Pflichtvertreter: Amtsleitungen strategischer Querschnittsämter
|
||||
- Weitere Vertreter: Amtsleitungen oder delegierte Vertreter
|
||||
(Option: Rotation/Wahl)
|
||||
- Mitglieder müssen Entscheidungsbefugnis haben oder diese
|
||||
dokumentiert delegiert bekommen haben
|
||||
sla_typ: "Zentrales SLA + SLS je Service"
|
||||
beispiele: "Arbeitsplatz, E-Mail, Netzwerk, zentrale Plattformen"
|
||||
|
||||
- id: "B"
|
||||
name: "Erweiterte Services"
|
||||
charakteristik: "Optional, bedarfsgesteuert, erweiternd"
|
||||
sla_partner: "Kundenvertretung [Servicename]"
|
||||
sla_partner_zusammensetzung: |
|
||||
- Mitglieder: Amtsleitungen der nutzenden Ämter oder deren
|
||||
delegierte Vertreter mit dokumentierter Entscheidungsbefugnis
|
||||
- Jedes nutzende Amt hat Anspruch auf Vertretung
|
||||
sla_typ: "SLA je Service mit Kundenvertretung + SLS"
|
||||
beispiele: "DMS-Module, CMS, Workflow-Systeme"
|
||||
|
||||
- id: "C"
|
||||
name: "Spezial-Services"
|
||||
charakteristik: "Individuell, hochgradig domänenspezifisch"
|
||||
sla_partner: "Amtsleitung des nutzenden Amtes"
|
||||
sla_partner_zusammensetzung: |
|
||||
- Amtsleiter:in oder delegierte Person mit dokumentierter
|
||||
Entscheidungsbefugnis
|
||||
sla_typ: "Bilaterales SLA (ohne separates SLS)"
|
||||
beispiele: "Kassensysteme, Fachverfahren, Speziallösungen"
|
||||
|
||||
- id: "I"
|
||||
name: "Interne Services"
|
||||
charakteristik: "Intern, kein direkter Kundenbezug, nicht im Katalog"
|
||||
sla_partner: "Keine externe Kundenvertretung"
|
||||
sla_partner_zusammensetzung: |
|
||||
- Interne Vereinbarung zwischen DIGIT-Einheiten
|
||||
- Service Owner des Internen Services + nutzende Einheit(en)
|
||||
sla_typ: "OLA (Operational Level Agreement)"
|
||||
beispiele: "Active Directory, Netzwerk-Backbone, zentrale Datenbanken"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-002"
|
||||
|
||||
governance:
|
||||
verantwortlich: "Service-Portfolio-Manager (SLM Practice Owner)"
|
||||
entscheidung: "Mission Board (finale Eskalations- und Portfoliosteuerung)"
|
||||
referenz: "GOV-001"
|
||||
|
||||
dokument_typen:
|
||||
|
||||
ola:
|
||||
name: "Operational Level Agreement (OLA)"
|
||||
beschreibung: |
|
||||
Interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne
|
||||
Services (Kategorie I). Funktionales Äquivalent eines SLA, jedoch
|
||||
ohne externen Kundenbezug. Das OLA definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen
|
||||
Betriebseinheiten.
|
||||
|
||||
abgrenzung_sla: |
|
||||
- SLA: Vereinbarung zwischen DIGIT und externem Kunden-Gremium/Amt
|
||||
(Kategorie A, B, C). Wird im Rahmen des Kundenforums reviewed.
|
||||
- OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I).
|
||||
Kein externer Kundenbezug, keine Katalog-Publikation.
|
||||
|
||||
inhalte:
|
||||
- "Leistungsbeschreibung des Internen Services"
|
||||
- "Qualitätsziele (Verfügbarkeit, Performance)"
|
||||
- "Verantwortlichkeiten (liefernde und nutzende Einheit)"
|
||||
- "Eskalationswege (intern)"
|
||||
- "Review-Mechanismus"
|
||||
- "Laufzeit und Änderungsverfahren"
|
||||
|
||||
pilotphase_hinweis: |
|
||||
Während der Pilotphase bleibt das OLA-Feld in der Service-Definition
|
||||
für Interne Services leer. Die Befüllung erfolgt nach Abschluss der
|
||||
Pilotphase auf Basis operativer Erfahrungen. Die Begründung ist
|
||||
einmalig in der Pilot-Scope-Dokumentation festgehalten.
|
||||
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
sla:
|
||||
name: "Service Level Agreement"
|
||||
beschreibung: >
|
||||
Governance-Instrument zwischen DIGIT und Kunden-Gremium/Usergroup.
|
||||
Definiert Rahmen, Verantwortlichkeiten, Eskalationswege,
|
||||
Review-Mechanismen. Kein Vertrag im juristischen Sinne,
|
||||
sondern formalisiertes Leistungsversprechen.
|
||||
|
||||
inhalte:
|
||||
- "Vertragsparteien und Geltungsbereich"
|
||||
- "Referenzierte Services und SLS"
|
||||
- "Rollen und Verantwortlichkeiten"
|
||||
- "Kommunikations- und Eskalationswege"
|
||||
- "Review- und Änderungsverfahren"
|
||||
- "Laufzeit und Kündigungslogik"
|
||||
|
||||
sls:
|
||||
name: "Service Level Specification"
|
||||
beschreibung: >
|
||||
Öffentliche, servicebezogene Leistungsbeschreibung.
|
||||
Gilt für alle Nutzer des Services gleichermaßen.
|
||||
Wird im Service-Katalog publiziert.
|
||||
Bei Kategorie C kann die SLS in das bilaterale SLA integriert
|
||||
sein; in diesem Fall verweist der Service-Katalog auf das SLA
|
||||
als Quelle der Service-Levels.
|
||||
|
||||
inhalte:
|
||||
- "Service-Beschreibung und Leistungsumfang"
|
||||
- "Zielgruppe und Voraussetzungen"
|
||||
- "Verfügbarkeitszeiten und Service-Fenster"
|
||||
- "Performance-Ziele (Reaktions-, Lösungszeiten)"
|
||||
- "Qualitätsmetriken und Messmethodik"
|
||||
- "Ausnahmen und Einschränkungen"
|
||||
- "Support-Kanäle und Kontaktwege"
|
||||
|
||||
template: "02.5_arbeitsmaterialien/template_sls.md"
|
||||
|
||||
kundenvertretung:
|
||||
beschreibung: >
|
||||
Formalisierte Vertretung der Kundenseite für SLA-Vereinbarungen.
|
||||
Keine Anwendergruppe, sondern Entscheidungsgremium.
|
||||
|
||||
grundsatz: |
|
||||
Mitglieder der Kundenvertretung müssen Entscheidungsbefugnis
|
||||
für ihr Amt haben oder diese dokumentiert delegiert bekommen haben.
|
||||
|
||||
berechtigte_personen:
|
||||
primaer: "Amtsleiter:in"
|
||||
alternativ:
|
||||
- "Abteilungsleiter:in (mit Delegation)"
|
||||
- "Verwaltungsleiter:in des Amtes (mit Delegation)"
|
||||
- "Andere Person mit dokumentierter Entscheidungsbefugnis"
|
||||
|
||||
delegation:
|
||||
anforderung: "Schriftliche Delegation durch Amtsleitung"
|
||||
inhalt:
|
||||
- "Name der delegierten Person"
|
||||
- "Umfang der Entscheidungsbefugnis"
|
||||
- "Gültigkeitszeitraum"
|
||||
dokumentation: "Hinterlegung bei DIGIT (SPM)"
|
||||
|
||||
typen:
|
||||
- typ: "Kundenvertretung Basisservices"
|
||||
kategorie: "A"
|
||||
zusammensetzung:
|
||||
pflicht: "Strategische Querschnittsämter (zu definieren)"
|
||||
weitere: "Rotation oder Wahl aus Fachämtern"
|
||||
entscheidungsmodus: "Konsens, bei Dissens qualifizierte Mehrheit"
|
||||
|
||||
- typ: "Kundenvertretung [Servicename]"
|
||||
kategorie: "B"
|
||||
zusammensetzung: "Alle nutzenden Ämter (oder deren Vertreter)"
|
||||
entscheidungsmodus: "Qualifizierte Mehrheit"
|
||||
|
||||
integration_mit_shm:
|
||||
beschreibung: |
|
||||
Die Kundenvertretungen sind mit den Stakeholder-Management-Formaten
|
||||
zu einem integrierten "Kundenforum"-Konzept zusammengeführt.
|
||||
|
||||
Das Kundenforum kombiniert:
|
||||
- SLA-Review und Service-Kommunikation (SLM-Verantwortung)
|
||||
- Beziehungspflege, Feedback und Bedarfssammlung (SHM-Verantwortung)
|
||||
|
||||
Die Moderation erfolgt gemeinsam durch Service Owner und
|
||||
Stakeholder-Manager.
|
||||
|
||||
governance_referenz: "GOV-012"
|
||||
|
||||
verweis: |
|
||||
Details zur Ausgestaltung siehe:
|
||||
#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml
|
||||
Abschnitt: kollektive_formate.integriertes_kundenforum
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: TRANSITION
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_transition:
|
||||
|
||||
- id: slm_01
|
||||
name: "Service-Level-Anforderungen erheben"
|
||||
|
||||
beschreibung: >
|
||||
Systematische Erfassung der Qualitätserwartungen aus Kundensicht
|
||||
als Grundlage für die SLS-Definition.
|
||||
|
||||
ausloeser:
|
||||
- "Neuer Service in Transition-Phase"
|
||||
- "Wesentliche Service-Änderung (aus Demand)"
|
||||
|
||||
umfasst:
|
||||
- "Analyse der Anforderungen aus Service-Design/Demand"
|
||||
- "Erhebung von Kundenerwartungen (Utility, Warranty, Experience)"
|
||||
- "Abgleich mit bestehenden SLS-Standards (falls vorhanden)"
|
||||
- "Identifikation kategorie-spezifischer Anforderungen"
|
||||
- "Dokumentation der Anforderungen"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Design-Dokumentation"
|
||||
quelle: "Service Entwicklung"
|
||||
- artefakt: "Demand-Spezifikation"
|
||||
quelle: "DPM"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Level-Anforderungen (dokumentiert)"
|
||||
ziel: "slm_02"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet die Anforderungserhebung"
|
||||
- rolle: stakeholder_manager
|
||||
raci: R
|
||||
kontext: "Führt Erhebung mit Kunden durch"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Konsistenz"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_02
|
||||
name: "Service Level Specification (SLS) erstellen"
|
||||
|
||||
beschreibung: >
|
||||
Übersetzung der Anforderungen in eine formale, messbare
|
||||
Leistungsbeschreibung.
|
||||
|
||||
umfasst:
|
||||
- "Definition der Service Levels (Verfügbarkeit, Performance, etc.)"
|
||||
- "Festlegung der Metriken und Messmethodik"
|
||||
- "Abstimmung mit Betriebsteam zur Messbarkeit"
|
||||
- "Erstellung des SLS-Dokuments nach Template"
|
||||
- "Interne Qualitätssicherung"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Level-Anforderungen"
|
||||
quelle: "slm_01"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "SLS-Entwurf"
|
||||
ziel: "slm_03"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet SLS-Inhalt"
|
||||
- rolle: betriebsteam
|
||||
raci: C
|
||||
kontext: "Validiert technische Messbarkeit"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Konsistenz mit Portfolio-Standards"
|
||||
|
||||
hinweis: >
|
||||
Bei Kategorie C entfällt ein separates SLS-Dokument – die Service
|
||||
Levels werden direkt im bilateralen SLA definiert. Für Transparenz
|
||||
im Service-Katalog wird in diesem Fall auf das SLA als Quelle der
|
||||
Service-Levels verwiesen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_03
|
||||
name: "SLA abstimmen und fixieren"
|
||||
|
||||
beschreibung: >
|
||||
Abstimmung des SLA mit dem relevanten Kunden-Gremium
|
||||
entsprechend der Service-Kategorie.
|
||||
|
||||
umfasst:
|
||||
- "Vorbereitung der SLA-Vorlage (kategorie-spezifisch)"
|
||||
- "Vorstellung und Diskussion mit SLA-Partner"
|
||||
- "Abstimmung bei Abweichungen von Standard-Levels"
|
||||
- "Dokumentation von Sondervereinbarungen"
|
||||
- "Einigung auf finale Fassung"
|
||||
|
||||
differenzierung_nach_kategorie:
|
||||
kategorie_a:
|
||||
sla_partner: "Kundenvertretung Basisservices"
|
||||
teilnehmer: "Amtsleitungen oder delegierte Vertreter mit Entscheidungsbefugnis"
|
||||
modus: "Abstimmung im Gremium, Konsensprinzip"
|
||||
kategorie_b:
|
||||
sla_partner: "Kundenvertretung [Servicename]"
|
||||
teilnehmer: "Amtsleitungen der nutzenden Ämter oder delegierte Vertreter"
|
||||
modus: "Abstimmung in Kundenvertretung, qualifizierte Mehrheit"
|
||||
kategorie_c:
|
||||
sla_partner: "Amtsleitung des nutzenden Amtes"
|
||||
teilnehmer: "Amtsleiter:in oder delegierte Person"
|
||||
modus: "Bilaterale Verhandlung"
|
||||
|
||||
eingang:
|
||||
- artefakt: "SLS-Entwurf"
|
||||
quelle: "slm_02"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Abgestimmter SLA-Entwurf"
|
||||
ziel: "slm_04"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Führt Abstimmung, moderiert Usergroup"
|
||||
- rolle: stakeholder_manager
|
||||
raci: C
|
||||
kontext: "Unterstützt bei Kundeninteraktion"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Verantwortet Governance-Konformität"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_04
|
||||
name: "SLA genehmigen und aktivieren"
|
||||
|
||||
beschreibung: >
|
||||
Formale Freigabe des SLA und Aktivierung der Service Levels
|
||||
für den produktiven Betrieb.
|
||||
|
||||
umfasst:
|
||||
- "Prüfung auf Vollständigkeit und Konsistenz"
|
||||
- "Interne Freigabe (SOR)"
|
||||
- "Unterzeichnung durch SLA-Partner"
|
||||
- "Publikation der SLS im Service-Katalog"
|
||||
- "Aktivierung des Monitorings"
|
||||
- "Kommunikation an Stakeholder"
|
||||
|
||||
governance:
|
||||
standard_sla: "SOR-Freigabe (Accountable für Standard-SLAs)"
|
||||
abweichung_von_standard: "Mission Board-Freigabe (Accountable für Major-/Abweichungs-SLAs)"
|
||||
referenz: "GOV-001"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Abgestimmter SLA-Entwurf"
|
||||
quelle: "slm_03"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Aktives SLA"
|
||||
ziel: "Service Betrieb"
|
||||
- artefakt: "Publizierte SLS"
|
||||
ziel: "Service-Katalog"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Bereitet Freigabe vor"
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Genehmigt Standard-SLAs (standard_sla)"
|
||||
- rolle: mission_board
|
||||
raci: A
|
||||
kontext: "Genehmigt Abweichungen/Major-SLAs (abweichung_von_standard)"
|
||||
- rolle: spm
|
||||
raci: R
|
||||
kontext: "Koordiniert Freigabeprozess"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: BETRIEB
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_betrieb:
|
||||
|
||||
- id: slm_05
|
||||
name: "Service Levels messen und überwachen"
|
||||
|
||||
beschreibung: >
|
||||
Kontinuierliche Erfassung der vereinbarten Metriken und
|
||||
Vergleich mit den SLA-Zielen.
|
||||
|
||||
umfasst:
|
||||
- "Automatisierte Erfassung technischer Metriken"
|
||||
- "Erhebung von Experience-Daten (wo definiert)"
|
||||
- "Aggregation und Aufbereitung der Messwerte"
|
||||
- "Abgleich mit SLA-Zielen"
|
||||
- "Identifikation von Abweichungen und Trends"
|
||||
|
||||
frequenz: "Kontinuierlich (automatisiert) + periodische Auswertung"
|
||||
|
||||
schnittstelle:
|
||||
- modul: "P-07 Monitoring & Event Management"
|
||||
beschreibung: "Liefert technische Messdaten"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Betreibt Monitoring, liefert Daten"
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Interpretation"
|
||||
- rolle: spm
|
||||
raci: I
|
||||
kontext: "Erhält aggregierte Daten für Portfolio"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_06
|
||||
name: "SLA-Performance reporten"
|
||||
|
||||
beschreibung: >
|
||||
Periodische Aufbereitung der Messergebnisse für interne
|
||||
und externe Stakeholder.
|
||||
|
||||
umfasst:
|
||||
- "Erstellung des Service-Qualitätsberichts"
|
||||
- "Visualisierung der SLA-Zielerreichung"
|
||||
- "Kommentierung von Abweichungen"
|
||||
- "Ableitung von Handlungsempfehlungen"
|
||||
- "Bereitstellung für Review-Prozesse"
|
||||
|
||||
frequenz: "Monatlich (intern), Quartalsweise (extern)"
|
||||
|
||||
report_typen:
|
||||
- typ: "Interner Qualitätsbericht"
|
||||
zielgruppe: "SOR, Service Owner"
|
||||
frequenz: "Monatlich"
|
||||
- typ: "Kunden-Report"
|
||||
zielgruppe: "Usergroup, Kunden-Gremium"
|
||||
frequenz: "Quartalsweise oder nach SLA-Vereinbarung"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Monitoring-Daten"
|
||||
quelle: "slm_05"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Service-Qualitätsbericht"
|
||||
ziel: "Service Review (B-03)"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Bericht und Interpretation"
|
||||
- rolle: betriebsteam
|
||||
raci: R
|
||||
kontext: "Liefert Daten, erstellt technischen Teil"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Konsistenz"
|
||||
|
||||
hinweis: >
|
||||
Verknüpfung mit op_06 (Service-Qualitätsbericht) im Blueprint.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_07
|
||||
name: "SLA-Verletzung eskalieren"
|
||||
|
||||
beschreibung: >
|
||||
Definierter Umgang mit systematischen oder kritischen
|
||||
Abweichungen von vereinbarten Service Levels.
|
||||
|
||||
ausloeser:
|
||||
- "Systematische SLA-Verletzung (>X Monate)"
|
||||
- "Kritische Einzelverletzung mit hohem Impact"
|
||||
- "Kundenbeschwerde zu Servicequalität"
|
||||
|
||||
umfasst:
|
||||
- "Identifikation und Dokumentation der Verletzung"
|
||||
- "Ursachenanalyse auf Service-Level (Abgleich mit bestehendem Problem-Management)"
|
||||
- "Bewertung der Kundenauswirkung"
|
||||
- "Eskalation gemäß Governance"
|
||||
- "Definition von Sofortmaßnahmen"
|
||||
|
||||
eskalationspfad:
|
||||
stufe_1:
|
||||
instanz: "Service Owner"
|
||||
aktion: "Analyse, Sofortmaßnahmen"
|
||||
stufe_2:
|
||||
instanz: "SOR"
|
||||
aktion: "Ressourcenentscheidung, Priorisierung"
|
||||
stufe_3:
|
||||
instanz: "Mission Board"
|
||||
aktion: "Verpflichtende Verbesserungsmaßnahmen"
|
||||
stufe_4:
|
||||
instanz: "Amtsleitung → OB-Ebene"
|
||||
aktion: "Politische Eskalation (ultima ratio)"
|
||||
|
||||
governance_referenz: "GOV-002"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Identifiziert, analysiert, eskaliert"
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Entscheidet über Maßnahmen"
|
||||
- rolle: mission_board
|
||||
raci: A
|
||||
kontext: "Bei Eskalation Stufe 3"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Dokumentiert, tracked Maßnahmen"
|
||||
|
||||
# =============================================================================
|
||||
# AKTIVITÄTEN – PHASE: REVIEW
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_review:
|
||||
|
||||
- id: slm_08
|
||||
name: "Internen SLA-Review durchführen"
|
||||
|
||||
beschreibung: >
|
||||
DIGIT-interne Bewertung der SLA-Performance als Vorbereitung
|
||||
für den externen Review mit Kunden.
|
||||
|
||||
umfasst:
|
||||
- "Analyse der SLA-Zielerreichung über Review-Periode"
|
||||
- "Bewertung von Trends und Mustern"
|
||||
- "Identifikation von Anpassungsbedarf"
|
||||
- "Vorbereitung von Änderungsvorschlägen"
|
||||
- "Abstimmung in der SOR"
|
||||
|
||||
frequenz: "Jährlich (oder nach SLA-Vereinbarung)"
|
||||
|
||||
verknuepfung:
|
||||
blueprint_aktivitaet: "rv_02 Service Performance & Improvement Review"
|
||||
beschreibung: >
|
||||
Der interne SLA-Review ist Teil des Service Reviews im Blueprint.
|
||||
SLA-spezifische Aspekte werden hier detailliert.
|
||||
|
||||
eingang:
|
||||
- artefakt: "Service-Qualitätsberichte (kumuliert)"
|
||||
quelle: "slm_06"
|
||||
- artefakt: "Eskalations-Dokumentation"
|
||||
quelle: "slm_07"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Interner Review-Bericht mit Änderungsvorschlägen"
|
||||
ziel: "slm_09"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: A
|
||||
kontext: "Verantwortet Review"
|
||||
- rolle: sor
|
||||
raci: C
|
||||
kontext: "Validiert Bewertung und Vorschläge"
|
||||
- rolle: spm
|
||||
raci: R
|
||||
kontext: "Konsolidiert Portfolio-Sicht"
|
||||
|
||||
governance_referenz: "GOV-003"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_09
|
||||
name: "Externen SLA-Review mit Kunden durchführen"
|
||||
|
||||
beschreibung: >
|
||||
Gemeinsamer Review mit dem SLA-Partner zur Validierung
|
||||
der Servicequalität und Abstimmung von Anpassungen.
|
||||
|
||||
umfasst:
|
||||
- "Präsentation der SLA-Performance"
|
||||
- "Erhebung von Kundenfeedback"
|
||||
- "Diskussion von Verbesserungsvorschlägen"
|
||||
- "Abstimmung von SLA/SLS-Änderungen"
|
||||
- "Dokumentation der Ergebnisse"
|
||||
|
||||
frequenz: "Jährlich (im Rahmen der Pilotierung zu validieren)"
|
||||
|
||||
integration_kundenforum: |
|
||||
Diese Aktivität wird im Rahmen des integrierten Kundenforums
|
||||
durchgeführt. Das Kundenforum kombiniert den SLA-Review mit
|
||||
SHM-Themen (Beziehungspflege, Bedarfssammlung).
|
||||
|
||||
Für Kategorie A: Kundenforum Basisservices (jährlich)
|
||||
Für Kategorie B: Kundenforum [Servicename] (jährlich)
|
||||
Für Kategorie C: Bilaterales Format (unverändert)
|
||||
|
||||
differenzierung_nach_kategorie:
|
||||
kategorie_a:
|
||||
format: "Review-Meeting der Kundenvertretung Basisservices"
|
||||
teilnehmer: "Amtsleitungen oder delegierte Vertreter"
|
||||
frequenz: "1x jährlich"
|
||||
kategorie_b:
|
||||
format: "Review-Meeting der Kundenvertretung [Servicename]"
|
||||
teilnehmer: "Amtsleitungen der nutzenden Ämter oder delegierte Vertreter"
|
||||
frequenz: "1x jährlich"
|
||||
kategorie_c:
|
||||
format: "Bilaterales Review-Gespräch"
|
||||
teilnehmer: "Amtsleitung oder delegierte Person"
|
||||
frequenz: "1x jährlich oder nach Bedarf"
|
||||
|
||||
eingang:
|
||||
- artefakt: "Interner Review-Bericht"
|
||||
quelle: "slm_08"
|
||||
|
||||
ausgang:
|
||||
- artefakt: "Review-Protokoll mit vereinbarten Änderungen"
|
||||
ziel: "slm_10"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Führt Review durch, moderiert"
|
||||
- rolle: stakeholder_manager
|
||||
raci: C
|
||||
kontext: "Unterstützt Kundeninteraktion"
|
||||
- rolle: spm
|
||||
raci: A
|
||||
kontext: "Verantwortet Governance-Konformität"
|
||||
|
||||
governance_referenz: "GOV-003"
|
||||
|
||||
hinweis: >
|
||||
Diese Aktivität muss noch im Blueprint (B-03 service_review.yaml)
|
||||
als neue Aktivität ergänzt werden.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: slm_10
|
||||
name: "SLA-Änderung durchführen"
|
||||
|
||||
beschreibung: >
|
||||
Formaler Prozess zur Anpassung bestehender SLAs und SLS
|
||||
basierend auf Review-Ergebnissen.
|
||||
|
||||
ausloeser:
|
||||
- "Review-Ergebnis mit Änderungsbedarf"
|
||||
- "Wesentliche Service-Änderung"
|
||||
- "Änderung der Kundenanforderungen"
|
||||
- "Änderung der Service-Kategorie"
|
||||
|
||||
umfasst:
|
||||
- "Bewertung des Änderungsumfangs"
|
||||
- "Erstellung der Änderungsdokumentation"
|
||||
- "Genehmigung gemäß Governance"
|
||||
- "Aktualisierung von SLA und SLS"
|
||||
- "Kommunikation an Stakeholder"
|
||||
- "Anpassung des Monitorings"
|
||||
|
||||
klassifizierung:
|
||||
minor:
|
||||
beschreibung: "Redaktionelle Anpassungen, Klarstellungen"
|
||||
genehmigung: "Service Owner"
|
||||
standard:
|
||||
beschreibung: "Anpassung innerhalb der Standard-Level-Bandbreite"
|
||||
genehmigung: "SOR"
|
||||
major:
|
||||
beschreibung: "Abweichung von Standards, neue Service Levels"
|
||||
genehmigung: "Mission Board"
|
||||
|
||||
mitarbeit:
|
||||
- rolle: service_owner
|
||||
raci: R
|
||||
kontext: "Erstellt Änderung, führt durch"
|
||||
- rolle: sor
|
||||
raci: A
|
||||
kontext: "Genehmigt Standard-Änderungen"
|
||||
- rolle: mission_board
|
||||
raci: A
|
||||
kontext: "Genehmigt Major-Änderungen"
|
||||
- rolle: spm
|
||||
raci: C
|
||||
kontext: "Prüft Portfolio-Konsistenz"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-REFERENZEN
|
||||
# =============================================================================
|
||||
|
||||
governance_referenzen:
|
||||
|
||||
- id: "GOV-001"
|
||||
frage: "Wer entscheidet Service-Kategorisierung?"
|
||||
kurzfassung: "R: SPM, A: Mission Board"
|
||||
|
||||
- id: "GOV-002"
|
||||
frage: "Eskalation bei SLA-Verletzung?"
|
||||
kurzfassung: "SO → SOR → Mission Board → AL/OB"
|
||||
|
||||
- id: "GOV-003"
|
||||
frage: "Interner vs. externer Review?"
|
||||
kurzfassung: "Zwei-Stufen-Logik: Intern (SOR) vor Extern (Kunde)"
|
||||
|
||||
- id: "GOV-004"
|
||||
frage: "SLA-Partner Kategorie A?"
|
||||
kurzfassung: "Kundengremium Basisversorgung (Anforderung definiert)"
|
||||
|
||||
- id: "GOV-005"
|
||||
frage: "Wer darf als SLA-Partner agieren?"
|
||||
kurzfassung: "Amtsleitungen oder delegierte Vertreter mit dokumentierter Entscheidungsbefugnis"
|
||||
|
||||
# =============================================================================
|
||||
# METRIKEN UND ERFOLGSKRITERIEN
|
||||
# =============================================================================
|
||||
|
||||
metriken:
|
||||
|
||||
prozess_metriken:
|
||||
- name: "SLA-Abdeckung"
|
||||
beschreibung: "Anteil Services mit aktivem SLA/SLS"
|
||||
ziel: "100% für Kategorie A und B"
|
||||
|
||||
- name: "SLA-Review-Durchführung"
|
||||
beschreibung: "Anteil durchgeführter Reviews im Zyklus"
|
||||
ziel: "100%"
|
||||
|
||||
- name: "Zeit bis SLA-Aktivierung"
|
||||
beschreibung: "Durchlaufzeit von Transition-Start bis aktives SLA"
|
||||
ziel: "Definition ausstehend"
|
||||
|
||||
ergebnis_metriken:
|
||||
- name: "SLA-Zielerreichung"
|
||||
beschreibung: "Anteil eingehaltener Service Levels"
|
||||
ziel: "Definition je Service"
|
||||
|
||||
- name: "Kundenzufriedenheit"
|
||||
beschreibung: "Bewertung der Servicequalität durch Kunden"
|
||||
ziel: "Definition ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-P02-001"
|
||||
beschreibung: "Blueprint-Ergänzung: Aktivität 'Externer SLA-Review' in rv_xx"
|
||||
prioritaet: "hoch"
|
||||
abhaengig_von: "Finalisierung P-02"
|
||||
|
||||
- id: "OPEN-P02-002"
|
||||
beschreibung: "Template-Entwicklung: SLS, SLA Kat. A/B/C"
|
||||
prioritaet: "mittel"
|
||||
ziel_ordner: "02.5_arbeitsmaterialien"
|
||||
|
||||
- id: "OPEN-P02-003"
|
||||
beschreibung: "Metriken-Katalog: Standard-Service-Levels je Kategorie"
|
||||
prioritaet: "mittel"
|
||||
|
||||
- id: "OPEN-P02-004"
|
||||
beschreibung: "Klärung: Konkrete Besetzung Kundengremium Basisversorgung"
|
||||
prioritaet: "niedrig"
|
||||
status: "Anforderung definiert, Abstimmung mit Verwaltung ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.3"
|
||||
datum: "2026-03-09"
|
||||
aenderung: |
|
||||
- OLA als neuer Dokumententyp unter dokument_typen ergänzt
|
||||
- Abgrenzung SLA (extern) vs. OLA (intern) dokumentiert
|
||||
- Kategorie I (Interne Services) in service_kategorien aufgenommen
|
||||
- Pilotphase-Hinweis: OLA-Felder bleiben zunächst leer
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "PENDING-SPM-001, DC-002"
|
||||
|
||||
- version: "0.2"
|
||||
datum: "2026-01-30"
|
||||
aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation), Aktivitäts-IDs (sb_05 → op_06, sr_02 → rv_02)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-11-26"
|
||||
aenderung: "Initiale Practice-Konzeption"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
||||
|
|
@ -0,0 +1,391 @@
|
|||
# =============================================================================
|
||||
# SERVICE-SUPPORT-MANAGEMENT: DESIGN-ZIELDIMENSIONEN
|
||||
# =============================================================================
|
||||
# Quelle: "Vorschläge Service Desk nach Lösungssäulen" (A3-Dokument)
|
||||
# Status: Abgestimmte Zieldimension für Konzeptentwicklung
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SSM-DESIGN"
|
||||
name: "Design-Zieldimensionen Service-Support-Management"
|
||||
version: "0.2"
|
||||
status: "referenz"
|
||||
erstellt: "2025-12-07"
|
||||
quelle: "Lösungssäulen-Vision (6 Seiten, A3)"
|
||||
|
||||
beschreibung: >
|
||||
Dieses Dokument übersetzt die abgestimmte Vision für den Service Desk
|
||||
in strukturierte Design-Anforderungen. Es dient als Leitplanke für
|
||||
die Entwicklung der Sub-Practices und Governance-Regeln.
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 1: GOVERNANCE & VERANTWORTLICHKEITEN
|
||||
# =============================================================================
|
||||
|
||||
saeulen:
|
||||
|
||||
- id: LS-01
|
||||
name: "Governance & Verantwortlichkeiten"
|
||||
untertitel: "Schnittstellendefinitionen zum 2nd Level"
|
||||
|
||||
eskalationskriterien:
|
||||
beschreibung: "Klare Kriterien, wann First Level an Second Level eskaliert"
|
||||
kriterien:
|
||||
- "Technische Berechtigungen fehlen"
|
||||
- "Definierte Zeitgrenzen überschritten"
|
||||
- "Spezialistenwissen erforderlich"
|
||||
- "Kunde fordert Eskalation"
|
||||
|
||||
uebergabedokumentation:
|
||||
beschreibung: "Pflichtinhalte bei Ticket-Übergabe an 2nd Level"
|
||||
pflichtfelder:
|
||||
- "Problembeschreibung"
|
||||
- "Bereits durchgeführte Schritte"
|
||||
- "Gesammelte Diagnosedaten"
|
||||
- "Vermutete Ursache"
|
||||
- "Kontaktdaten des Anwenders inkl. Geräte-IDs"
|
||||
|
||||
rueckgaberegeln:
|
||||
beschreibung: "Wann darf 2nd Level Tickets zurückgeben?"
|
||||
second_level_kann_zurueckgeben_bei:
|
||||
- "Unvollständiger Übergabedokumentation"
|
||||
- "Fehlendem Lösungsversuch First Level"
|
||||
- "Falscher Kategorisierung"
|
||||
|
||||
entscheidungsverfahren:
|
||||
service_owner_rolle: "Grenzwächter"
|
||||
verantwortlichkeiten:
|
||||
- "Monitoring der Service-bezogenen Tickets"
|
||||
- "Identifikation von Umgehungsmustern"
|
||||
- "Qualitätssicherung der Übergaben"
|
||||
- "Mediation bei Schnittstellenkonflikten"
|
||||
befugnisse:
|
||||
- "Direkter Zugriff auf alle Service-Tickets"
|
||||
- "Teilnahme an Eskalationsgesprächen"
|
||||
- "Veto-Recht bei Prozessumgehungen"
|
||||
- "Eskalation an SPM"
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 2: ROLLENVERSTÄNDNIS UND VERANTWORTUNGSTIEFE
|
||||
# =============================================================================
|
||||
|
||||
- id: LS-02
|
||||
name: "Rollenverständnis und Verantwortungstiefe"
|
||||
untertitel: "Enablement und eigenverantwortliches Arbeiten"
|
||||
|
||||
enablement_philosophie:
|
||||
bezeichnung: "Eigenverantwortliches Arbeiten"
|
||||
beschreibung: |
|
||||
Der First Level Agent ist ein eigenverantwortlicher Problemlöser,
|
||||
kein "Ticket-Schubser". Der Agent entscheidet selbst über sein
|
||||
Vorgehen, die SLA gibt den zeitlichen Rahmen vor.
|
||||
|
||||
Version 0.2: Das bisherige "Explorationsbudget" als eigenständiges
|
||||
Konzept entfällt. Die SLA gibt den Rahmen vor, innerhalb dessen
|
||||
der Agent arbeitet. Die Enablement-Philosophie bleibt erhalten.
|
||||
prinzipien:
|
||||
- "Agent entscheidet eigenverantwortlich über sein Vorgehen"
|
||||
- "Die SLA gibt den zeitlichen Rahmen vor"
|
||||
- "Eskalation ist eine Option, keine Pflicht bei Unklarheit"
|
||||
- "Dokumentation von Erkenntnissen ist erwünscht"
|
||||
|
||||
befaehigung_durch_service_owner:
|
||||
beschreibung: >
|
||||
Die Service Owner tragen die Verantwortung, den First Level
|
||||
systematisch zu befähigen.
|
||||
massnahmen:
|
||||
- "Bereitstellung von Grundlagendokumentation"
|
||||
- "Gemeinsame Erarbeitung von Arbeitsdokumentation"
|
||||
- "Regelmäßige Schulungen und Updates"
|
||||
- "Vergabe notwendiger Berechtigungen"
|
||||
- "Kontinuierliche Weiterentwicklung der Service-spezifischen Kenntnisse"
|
||||
|
||||
hinweis_version_0_2: |
|
||||
Das frühere Konzept "Exploration Budget" (definierte Zeiten für
|
||||
tiefere Exploration, z.B. 10% der Arbeitszeit) wurde gestrichen.
|
||||
|
||||
Begründung:
|
||||
- Die SLA gibt bereits den zeitlichen Rahmen vor
|
||||
- Ein separates Budget war redundant zur SLA-Steuerung
|
||||
- Die Enablement-Philosophie erfordert keine eigene Zeitsteuerung
|
||||
|
||||
Die kulturelle Botschaft (Agent darf eigenverantwortlich arbeiten)
|
||||
bleibt erhalten, wird aber nicht mehr über ein separates
|
||||
"Budget" operationalisiert."
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 3: ORGANISATION & TEAMSTRUKTUR
|
||||
# =============================================================================
|
||||
|
||||
- id: LS-03
|
||||
name: "Organisation & Teamstruktur"
|
||||
untertitel: "Rollenübersicht"
|
||||
|
||||
rollenhierarchie:
|
||||
ebene_service_management:
|
||||
- "Service Portfolio Manager"
|
||||
- "Service Owner"
|
||||
ebene_service_desk:
|
||||
- "Service Desk Manager"
|
||||
- "Queue Koordinator"
|
||||
- "1st Agent"
|
||||
- "2nd Agent"
|
||||
|
||||
koordinator_rolle:
|
||||
beschreibung: "Drei Ausprägungen der Koordinator-Rolle"
|
||||
|
||||
varianten:
|
||||
- name: "Koordinator als Facilitator"
|
||||
charakteristik:
|
||||
- "Koordinator beobachtet nur und gibt Hinweise"
|
||||
- "Keine Zuweisung, nur Bitten"
|
||||
- "Team kann 'Nein' sagen"
|
||||
- "Intervention nur mit Team-Konsens"
|
||||
|
||||
- name: "Koordinator als Controller"
|
||||
charakteristik:
|
||||
- "Koordinator weist zu, wenn nötig"
|
||||
- "Team muss folgen (bis auf begründete Ausnahmen)"
|
||||
- "Klare Hierarchie in Überlast-Situationen"
|
||||
- "Koordinator = operative Führungskraft"
|
||||
|
||||
- name: "Koordinator mit situativer Macht"
|
||||
charakteristik:
|
||||
- "Normal: Koordinator als Facilitator"
|
||||
- "Überlast: Koordinator bekommt Durchgriffsrechte"
|
||||
- "Krise: Koordinator als direktiver Lead"
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 4: TICKETSTEUERUNG & ARBEITSORGANISATION
|
||||
# =============================================================================
|
||||
|
||||
- id: LS-04
|
||||
name: "Ticketsteuerung & Arbeitsorganisation"
|
||||
untertitel: "Poolbasierte Steuerungslogik & Ticketübernahme"
|
||||
|
||||
pool_modell:
|
||||
beschreibung: |
|
||||
3 Pools zur Ticket-Steuerung. Die Pool-Zuordnung erfolgt primär
|
||||
über die Priorität. Die SLA gibt den verbindlichen Zeitrahmen vor.
|
||||
|
||||
Version 0.2: Reduktion von 4 auf 3 Pools. Der bisherige "Analyse-Pool"
|
||||
entfällt – ANALYSE-Tickets werden im Standard-Pool bearbeitet.
|
||||
|
||||
pools:
|
||||
- id: "POOL-1"
|
||||
name: "Sofort-Pool"
|
||||
eingang: "Priorität P1 (alle Charakteristiken)"
|
||||
kriterien:
|
||||
- "Kompletter Systemausfall"
|
||||
- "Mehr als 10 Nutzer:innen betroffen"
|
||||
- "Sicherheitsvorfälle"
|
||||
- "Geschäftskritische Prozesse blockiert"
|
||||
regel: "Muss innerhalb von 15 Minuten gezogen werden"
|
||||
eskalation: "Nach 15 Minuten automatische Alarmierung des Queue-Koordinators"
|
||||
|
||||
- id: "POOL-2"
|
||||
name: "Standard-Pool"
|
||||
eingang: "Priorität P2/P3/P4 mit Charakteristik STANDARD oder ANALYSE"
|
||||
typische_tickets:
|
||||
- "Passwort-Resets (STANDARD)"
|
||||
- "Berechtigungsanfragen (STANDARD)"
|
||||
- "Account-Entsperrungen (STANDARD)"
|
||||
- "Software-Installation aus Katalog (STANDARD)"
|
||||
- "Drucker-Probleme (STANDARD)"
|
||||
- "Unklare Fehlerbeschreibungen (ANALYSE)"
|
||||
- "Intermittierende Probleme (ANALYSE)"
|
||||
- "Performance-Beschwerden (ANALYSE)"
|
||||
regel: "Maximal 30 Tickets im Pool, dann Kapazitätsalarm"
|
||||
bearbeitung: "FIFO nach Priorität, SLA gibt Zeitrahmen vor"
|
||||
|
||||
- id: "POOL-3"
|
||||
name: "Projekt-Pool"
|
||||
eingang: "Charakteristik PROJEKT (unabhängig von Priorität)"
|
||||
typische_aufgaben:
|
||||
- "Neue Arbeitsplatz-Einrichtung"
|
||||
- "Umzüge"
|
||||
- "Komplexe Berechtigungsstrukturen"
|
||||
- "Größere Software-Deployments"
|
||||
regel: "Kann geplant und terminiert werden"
|
||||
koordination: "Abstimmung mit betroffenen Stakeholdern"
|
||||
kpi: "Aus operativen KPIs exkludiert"
|
||||
|
||||
commitment_prinzip:
|
||||
grundregel: "Ticket gezogen = Ticket owned"
|
||||
legitime_ausgaenge:
|
||||
- ausgang: "gelöst"
|
||||
beschreibung: "Ticket wird mit Lösung geschlossen"
|
||||
- ausgang: "eskaliert"
|
||||
beschreibung: "Formale Weitergabe mit dokumentierter Begründung"
|
||||
- ausgang: "geparkt"
|
||||
beschreibung: "Mit konkretem Grund (wartet auf Nutzer:in, wartet auf System, etc.)"
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 5: WISSENSVERANTWORTUNG
|
||||
# =============================================================================
|
||||
|
||||
- id: LS-05
|
||||
name: "Wissensverantwortung"
|
||||
untertitel: "3-Schichten-Modell"
|
||||
|
||||
schichten:
|
||||
- ebene: 1
|
||||
name: "Grundlagendokumentation"
|
||||
verantwortung: "Service Owner"
|
||||
charakteristika:
|
||||
- "Stabile, grundlegende Service-Dokumentation"
|
||||
- "Beschreibt WAS der Service tut und WIE er funktioniert"
|
||||
- "Änderungen nur bei Service-Updates oder strukturellen Anpassungen"
|
||||
- "Qualitätsgesichert und verbindlich"
|
||||
inhalte:
|
||||
- "Service-Beschreibung und Scope"
|
||||
- "Technische Architektur und Abhängigkeiten"
|
||||
- "Basis-Troubleshooting-Prozesse"
|
||||
- "Eskalationswege und Ansprechpartner"
|
||||
- "SLAs und kritische Schwellwerte"
|
||||
prozess:
|
||||
- "Service Owner erstellt und pflegt diese Dokumentation"
|
||||
- "Updates werden proaktiv an Service Desk kommuniziert"
|
||||
- "Versionierung und Change-Log sind verpflichtend"
|
||||
|
||||
- ebene: 2
|
||||
name: "Arbeitsdokumentation"
|
||||
verantwortung: "Service Owner + Service Desk Team (Co-Creation)"
|
||||
charakteristika:
|
||||
- "Operative Übersetzung der Grundlagendokumentation"
|
||||
- "Praxisorientierte Handlungsanweisungen"
|
||||
- "Regelmäßige Updates basierend auf Erfahrungen"
|
||||
- "Gemeinsam erarbeitet und validiert"
|
||||
inhalte:
|
||||
- "Step-by-Step Anleitungen für häufige Szenarien"
|
||||
- "Checklisten und Entscheidungsbäume"
|
||||
- "Workarounds für bekannte Probleme"
|
||||
- "Quick-Reference-Guides"
|
||||
- "Tool-spezifische Anleitungen"
|
||||
prozess:
|
||||
- "Quartalsweise gemeinsame Workshop-Sessions"
|
||||
- "Service Owner moderiert, Service Desk bringt Praxiserfahrung ein"
|
||||
- "Qualitätssicherung durch beide Seiten"
|
||||
- "Direkte Integration in Ticketsystem wo möglich"
|
||||
|
||||
- ebene: 3
|
||||
name: "Operative Erkenntnisse"
|
||||
verantwortung: "Service Desk Team (Wiki-Prinzip)"
|
||||
charakteristika:
|
||||
- "Dynamische, schnell änderbare Wissensbasis"
|
||||
- "Bottom-up aus täglicher Arbeit"
|
||||
- "Peer-Review statt zentrale Kontrolle"
|
||||
- "Experimenteller Charakter erlaubt"
|
||||
inhalte:
|
||||
- "Lösungen für spezielle Edge-Cases"
|
||||
- "Tipps und Tricks aus der Praxis"
|
||||
- "Temporäre Workarounds"
|
||||
- "Beobachtungen und Muster"
|
||||
- "'Lessons Learned' aus schwierigen Tickets"
|
||||
prozess:
|
||||
- "Jeder Service Agent kann Einträge erstellen/editieren"
|
||||
- "Monatliches Review-Meeting zur Qualitätssicherung"
|
||||
- "Bewährte Erkenntnisse wandern in Ebene 2"
|
||||
- "Veraltete Einträge werden archiviert"
|
||||
|
||||
# =============================================================================
|
||||
# LÖSUNGSSÄULE 6: QUALITÄT UND VERBESSERUNGSLOGIK
|
||||
# =============================================================================
|
||||
|
||||
- id: LS-06
|
||||
name: "Qualität und Verbesserungslogik"
|
||||
untertitel: "Hybrid-Modell mit Fokus Lernen"
|
||||
|
||||
kpis:
|
||||
primaer:
|
||||
- name: "First Contact Resolution Rate"
|
||||
ziel_phase_1: ">40%"
|
||||
ziel_phase_3: ">60%"
|
||||
- name: "Durchschnittliche Lösungszeit nach Pool-Typ"
|
||||
- name: "SLA-Erfüllungsgrad (wenn definiert)"
|
||||
- name: "Tickets pro Agent und Tag"
|
||||
- name: "Eskalationsrate"
|
||||
- name: "Kundenzufriedenheit (wenn messbar)"
|
||||
|
||||
sekundaer:
|
||||
- "Wiki-Beiträge pro Monat"
|
||||
- "Peer-Support-Anfragen"
|
||||
- "Wiederöffnungsrate"
|
||||
- "Backlog-Entwicklung"
|
||||
|
||||
austauschformate:
|
||||
- "Service Owner Reviews"
|
||||
- "Team Retrospektiven"
|
||||
|
||||
kontinuierliche_verbesserung:
|
||||
durch_service_owner:
|
||||
beschreibung: "Service Owner tragen Verantwortung für:"
|
||||
aufgaben:
|
||||
- "Regelmäßige Qualitätssicherung der Dokumentation"
|
||||
- "Identifikation von Automatisierungspotential"
|
||||
- "Schulungsplanung basierend auf Fehlermustern"
|
||||
- "Proaktive Service-Verbesserungen"
|
||||
|
||||
durch_fehlerkultur:
|
||||
prinzipien:
|
||||
- "Fehler sind Lernchancen"
|
||||
- "Dokumentation statt Schuldzuweisung"
|
||||
- "Systematische Ursachenanalyse"
|
||||
- "Präventionsmaßnahmen entwickeln"
|
||||
|
||||
prozess_bei_kritischen_fehlern:
|
||||
- schritt: 1
|
||||
aktion: "Sofortige Schadensbegrenzung"
|
||||
- schritt: 2
|
||||
aktion: "Sachliche Dokumentation"
|
||||
- schritt: 3
|
||||
aktion: "Ursachenanalyse im Team"
|
||||
- schritt: 4
|
||||
aktion: "Maßnahmenableitung"
|
||||
- schritt: 5
|
||||
aktion: "Nachverfolgung der Wirksamkeit"
|
||||
|
||||
# =============================================================================
|
||||
# MAPPING AUF SUB-PRACTICES
|
||||
# =============================================================================
|
||||
|
||||
mapping_sub_practices:
|
||||
beschreibung: >
|
||||
Zuordnung der Lösungssäulen-Elemente zu den zu entwickelnden Sub-Practices
|
||||
|
||||
incident_management:
|
||||
relevante_saeulen: [LS-01, LS-04, LS-06]
|
||||
schwerpunkte:
|
||||
- "Eskalationskriterien (LS-01)"
|
||||
- "Pool-Modell für Incident-Priorisierung (LS-04)"
|
||||
- "Commitment-Prinzip (LS-04)"
|
||||
- "KPIs: Lösungszeit, Eskalationsrate (LS-06)"
|
||||
|
||||
request_management:
|
||||
relevante_saeulen: [LS-04, LS-05]
|
||||
schwerpunkte:
|
||||
- "Standard Service-Pool (LS-04)"
|
||||
- "Projektpool für komplexe Requests (LS-04)"
|
||||
- "Arbeitsdokumentation für Request-Typen (LS-05)"
|
||||
|
||||
service_desk:
|
||||
relevante_saeulen: [LS-02, LS-03, LS-05]
|
||||
schwerpunkte:
|
||||
- "Koordinator-Rolle und Modelle (LS-03)"
|
||||
- "Enablement-Philosophie / Eigenverantwortliches Arbeiten (LS-02)"
|
||||
- "3-Schichten-Wissensmodell (LS-05)"
|
||||
- "Befähigung durch Service Owner (LS-02)"
|
||||
|
||||
problem_management:
|
||||
relevante_saeulen: [LS-05, LS-06]
|
||||
schwerpunkte:
|
||||
- "Erkenntnisse aus Ebene 3 → Problem-Kandidaten (LS-05)"
|
||||
- "Fehlerkultur und Ursachenanalyse (LS-06)"
|
||||
- "Kontinuierliche Verbesserung (LS-06)"
|
||||
|
||||
governance_uebergreifend:
|
||||
relevante_saeulen: [LS-01, LS-03]
|
||||
schwerpunkte:
|
||||
- "Service Owner als Grenzwächter (LS-01)"
|
||||
- "Übergabe- und Rückgaberegeln (LS-01)"
|
||||
- "Rollenhierarchie und Befugnisse (LS-03)"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,960 @@
|
|||
# =============================================================================
|
||||
# SERVICE-SUPPORT-MANAGEMENT: KLASSIFIKATION & PRIORISIERUNG
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SSM-KLASSIFIKATION"
|
||||
name: "Ticket-Klassifikation und Priorisierung"
|
||||
version: "0.4"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-07"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: >
|
||||
Querschnitts-Dokument für die Klassifikation und Priorisierung aller
|
||||
Support-Tickets (Incidents und Requests). Definiert die Entscheidungslogik
|
||||
für Prioritätszuweisung, Pool-Zuordnung sowie die zugehörigen SLA-Rahmen.
|
||||
|
||||
Version 0.4: Überarbeitung der Impact- und Urgency-Kriterien.
|
||||
Impact basiert nun primär auf qualitativen Kriterien (Sicherheit,
|
||||
Kritikalitätsstufe, Bürger-Betroffenheit, Leitungsebene) statt auf
|
||||
Nutzeranzahl. Urgency fokussiert auf zeitliche Aspekte mit präzisierten
|
||||
Kriterien für externe Fristen und rechtliche Vorgaben.
|
||||
|
||||
gilt_fuer:
|
||||
- "sub-practice_incident-management.yaml"
|
||||
- "sub-practice_request-management.yaml"
|
||||
|
||||
design_referenz: "ssm_design-zieldimensionen.yaml"
|
||||
relevante_saeulen: ["LS-01", "LS-04"]
|
||||
|
||||
governance_referenz:
|
||||
- "SSM-G-02: Priorisierungs-Autorität"
|
||||
- "SSM-G-04: DoR-Verbindlichkeit"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDPRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
grundprinzipien:
|
||||
|
||||
beschreibung: >
|
||||
Die Klassifikation und Priorisierung folgt einem klaren Modell:
|
||||
Die Priorität (abgeleitet aus Impact × Urgency) bestimmt die
|
||||
SLA-Verbindlichkeit und die Pool-Zuordnung. Die Charakteristik
|
||||
ist ein beschreibendes Attribut für Reporting und Analyse.
|
||||
|
||||
steuerungslogik:
|
||||
- dimension: "Priorität"
|
||||
funktion: "SLA-Steuerung und Pool-Zuordnung"
|
||||
beantwortet: "WANN muss reagiert/gelöst werden? In welchem Pool?"
|
||||
basis: "Impact × Urgency"
|
||||
|
||||
- dimension: "Charakteristik"
|
||||
funktion: "Beschreibendes Attribut (Label)"
|
||||
beantwortet: "Welche Art von Ticket ist es?"
|
||||
nutzen:
|
||||
- "Reporting (Anteil unklarer Tickets)"
|
||||
- "Wissenslücken identifizieren"
|
||||
- "Dokumentationsbedarf erkennen"
|
||||
hinweis: "Keine Steuerungsfunktion für Pool-Zuordnung"
|
||||
|
||||
autoritaet:
|
||||
wer_priorisiert: "Service Desk (First Level)"
|
||||
grundlage: "Impact-Urgency-Matrix (verbindlich)"
|
||||
eskalation_bei_widerspruch: "Queue-Koordinator / Teamleitung"
|
||||
kunde_kann: "Dringlichkeit melden"
|
||||
kunde_kann_nicht: "Priorität festlegen"
|
||||
|
||||
governance_entscheidung: "SSM-G-02"
|
||||
|
||||
# =============================================================================
|
||||
# TICKET-TYPEN
|
||||
# =============================================================================
|
||||
|
||||
ticket_typen:
|
||||
|
||||
beschreibung: >
|
||||
Grundlegende Unterscheidung der Ticket-Typen. Die Klassifikation erfolgt
|
||||
bei Ticket-Erfassung und bestimmt den anzuwendenden Prozess.
|
||||
|
||||
typen:
|
||||
- id: "INCIDENT"
|
||||
name: "Störung"
|
||||
definition: >
|
||||
Ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services.
|
||||
Der normale Betrieb ist beeinträchtigt.
|
||||
beispiele:
|
||||
- "Anwendung stürzt ab"
|
||||
- "Drucker druckt nicht"
|
||||
- "Kein Netzwerkzugang"
|
||||
- "Performance-Probleme"
|
||||
- "Fehlermeldungen"
|
||||
prozess: "sub-practice_incident-management.yaml"
|
||||
|
||||
- id: "REQUEST"
|
||||
name: "Service-Anfrage"
|
||||
definition: >
|
||||
Formelle Anfrage eines Nutzers für etwas, das bereitgestellt werden
|
||||
soll. Kein Ausfall oder Störung, sondern geplante Leistungserbringung.
|
||||
beispiele:
|
||||
- "Passwort zurücksetzen"
|
||||
- "Neue Software installieren"
|
||||
- "Berechtigung anfordern"
|
||||
- "Hardware bestellen"
|
||||
- "Informationsanfrage"
|
||||
prozess: "sub-practice_request-management.yaml"
|
||||
|
||||
- id: "PROJEKT"
|
||||
name: "Projekt-Ticket"
|
||||
definition: >
|
||||
Planbare, umfangreiche Aufgabe, die nicht im normalen Support-Flow
|
||||
bearbeitet werden kann. Erfordert Koordination und Terminierung.
|
||||
beispiele:
|
||||
- "Neuer Arbeitsplatz einrichten (komplett)"
|
||||
- "Abteilungsumzug"
|
||||
- "Komplexe Berechtigungsstruktur aufbauen"
|
||||
- "Größeres Software-Deployment"
|
||||
prozess: "Separater Prozess / Projektpool"
|
||||
|
||||
hinweis: >
|
||||
Projekt-Tickets werden NICHT in operativen KPIs (MTTR, FCR) gezählt.
|
||||
Governance-Entscheidung SSM-G-07.
|
||||
|
||||
entscheidungsbaum_typ:
|
||||
frage_1: "Liegt eine Störung/Beeinträchtigung eines laufenden Services vor?"
|
||||
wenn_ja: "→ INCIDENT"
|
||||
wenn_nein:
|
||||
frage_2: "Ist die Anfrage standardisiert und in absehbarer Zeit erledigbar?"
|
||||
wenn_ja: "→ REQUEST"
|
||||
wenn_nein:
|
||||
frage_3: "Erfordert die Anfrage Planung, Koordination oder >1 Tag Aufwand?"
|
||||
wenn_ja: "→ PROJEKT"
|
||||
wenn_nein: "→ REQUEST"
|
||||
|
||||
# =============================================================================
|
||||
# IMPACT-URGENCY-MATRIX
|
||||
# =============================================================================
|
||||
|
||||
impact_urgency_matrix:
|
||||
|
||||
beschreibung: >
|
||||
Die Priorität ergibt sich aus der Kombination von Impact (Auswirkung)
|
||||
und Urgency (Dringlichkeit). Die Matrix ist verbindlich anzuwenden.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# IMPACT-DEFINITION
|
||||
# ---------------------------------------------------------------------------
|
||||
impact:
|
||||
beschreibung: "Ausmaß der Auswirkung auf den Geschäftsbetrieb"
|
||||
|
||||
stufen:
|
||||
- stufe: "HOCH"
|
||||
code: "I-H"
|
||||
beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Sicherheitsvorfall (Datenverlust, Breach, Malware-Verdacht)"
|
||||
- "ODER Service mit Kritikalitätsstufe 'geschaeftskritisch' betroffen"
|
||||
- "ODER Bürger durch Ausfall direkt betroffen"
|
||||
- "ODER definierte Leitungsebene betroffen"
|
||||
beispiele:
|
||||
- "Ransomware-Verdacht"
|
||||
- "SAP nicht erreichbar"
|
||||
- "freiburg.de nicht erreichbar"
|
||||
- "Bürgerdienstleistung kann nicht erbracht werden"
|
||||
- "Wartezeit am Schalter durch IT-Ausfall"
|
||||
- "Netzwerk-Backbone ausgefallen"
|
||||
hinweise:
|
||||
buerger_kriterium: >
|
||||
Bürger-Betroffenheit umfasst sowohl direkte Interaktion
|
||||
(Schalter, Termin, telefonische Erreichbarkeit) als auch
|
||||
Bürger-facing Services (Website, Online-Formulare, Portal).
|
||||
leitungsebene: >
|
||||
Die relevanten Leitungsebenen werden im lebenden Arbeitsdokument
|
||||
für geschäftskritische Applikationen definiert. Dieses wird
|
||||
regelmäßig geprüft und aktualisiert; Entscheidungen erfolgen
|
||||
durch die SOR.
|
||||
|
||||
- stufe: "NORMAL"
|
||||
code: "I-N"
|
||||
beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Mehrere Nutzer betroffen (>1) oder ganze Teams/Bereiche"
|
||||
- "ODER Service mit Kritikalitätsstufe 'wichtig' betroffen"
|
||||
beispiele:
|
||||
- "Outlook stürzt bei mehreren Nutzern ab"
|
||||
- "Drucker für ganzes Team funktioniert nicht"
|
||||
- "Fachverfahren mit Tagesgeschäft-Relevanz gestört"
|
||||
- "E-Mail-System eingeschränkt verfügbar"
|
||||
|
||||
- stufe: "NIEDRIG"
|
||||
code: "I-L"
|
||||
beschreibung: "Folgende Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Einzelner Nutzer betroffen ODER Service mit Kritikalitätsstufe 'unterstuetzend'"
|
||||
- "Komforteinschränkung ohne Auswirkung auf Arbeitsfähigkeit"
|
||||
beispiele:
|
||||
- "Schriftart in Outlook zurückgesetzt"
|
||||
- "Desktop-Hintergrund fehlt"
|
||||
- "Nicht-kritische Funktion nicht verfügbar"
|
||||
- "Raumbuchungssystem gestört"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# URGENCY-DEFINITION
|
||||
# ---------------------------------------------------------------------------
|
||||
urgency:
|
||||
beschreibung: "Zeitliche Dringlichkeit der Lösung – wie schnell muss gelöst werden, um Schaden zu vermeiden?"
|
||||
|
||||
stufen:
|
||||
- stufe: "HOCH"
|
||||
code: "U-H"
|
||||
beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Akute Auswirkung auf gesamte Arbeitsfähigkeit, kein Workaround möglich, sofortige Lösung erforderlich"
|
||||
- "ODER zeitkritischer Prozess (externe Frist, rechtliche Vorgabe, Termin mit Bürger oder externen Partnern)"
|
||||
beispiele:
|
||||
- "Präsentation in 1 Stunde, Laptop startet nicht"
|
||||
- "Fristgebundener Vorgang blockiert (rechtliche Frist)"
|
||||
- "Bürger wartet am Schalter"
|
||||
- "Termin mit externem Partner steht unmittelbar bevor"
|
||||
|
||||
- stufe: "NORMAL"
|
||||
code: "U-N"
|
||||
beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Keine unmittelbaren Auswirkungen auf Arbeitsfähigkeit"
|
||||
- "ODER temporärer Workaround existiert"
|
||||
- "ODER keine Deadline, aber zeitnahe Lösung notwendig"
|
||||
beispiele:
|
||||
- "Drucker defekt, anderer Drucker verfügbar"
|
||||
- "Software benötigt, aber nicht heute"
|
||||
- "Eingeschränkte Funktionalität, Kernarbeit möglich"
|
||||
|
||||
- stufe: "NIEDRIG"
|
||||
code: "U-L"
|
||||
beschreibung: "Alle folgenden Kriterien erfüllt"
|
||||
kriterien:
|
||||
- "Keine Auswirkung auf Arbeitsfähigkeit"
|
||||
- "Kann warten, Nutzer hat explizit keine Eile"
|
||||
beispiele:
|
||||
- "Verbesserungsvorschlag"
|
||||
- "Langfristige Anfrage"
|
||||
- "Kosmetische Anpassung ohne Dringlichkeit"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MATRIX
|
||||
# ---------------------------------------------------------------------------
|
||||
matrix:
|
||||
beschreibung: "Ableitung der Priorität aus Impact × Urgency"
|
||||
|
||||
# URGENCY
|
||||
# HOCH NORMAL NIEDRIG
|
||||
# IMPACT
|
||||
# HOCH P1 P2 P3
|
||||
# NORMAL P2 P3 P4
|
||||
# NIEDRIG P3 P4 P4
|
||||
|
||||
mapping:
|
||||
- impact: "HOCH"
|
||||
urgency: "HOCH"
|
||||
prioritaet: "P1"
|
||||
|
||||
- impact: "HOCH"
|
||||
urgency: "NORMAL"
|
||||
prioritaet: "P2"
|
||||
|
||||
- impact: "HOCH"
|
||||
urgency: "NIEDRIG"
|
||||
prioritaet: "P3"
|
||||
|
||||
- impact: "NORMAL"
|
||||
urgency: "HOCH"
|
||||
prioritaet: "P2"
|
||||
|
||||
- impact: "NORMAL"
|
||||
urgency: "NORMAL"
|
||||
prioritaet: "P3"
|
||||
|
||||
- impact: "NORMAL"
|
||||
urgency: "NIEDRIG"
|
||||
prioritaet: "P4"
|
||||
|
||||
- impact: "NIEDRIG"
|
||||
urgency: "HOCH"
|
||||
prioritaet: "P3"
|
||||
|
||||
- impact: "NIEDRIG"
|
||||
urgency: "NORMAL"
|
||||
prioritaet: "P4"
|
||||
|
||||
- impact: "NIEDRIG"
|
||||
urgency: "NIEDRIG"
|
||||
prioritaet: "P4"
|
||||
|
||||
# =============================================================================
|
||||
# SERVICE-KRITIKALITÄTS-MAPPING
|
||||
# =============================================================================
|
||||
|
||||
service_kritikalitaet_mapping:
|
||||
|
||||
beschreibung: >
|
||||
Verknüpfung zwischen Service-Kritikalität (aus Service-Definition)
|
||||
und Impact-Bewertung im Incident Management. Ermöglicht eine
|
||||
konsistente, service-basierte Priorisierung.
|
||||
|
||||
referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet"
|
||||
|
||||
grundprinzip: >
|
||||
Die im Service-Portfolio hinterlegte Kritikalitätsstufe eines Services
|
||||
dient als Vorschlagswert für die Impact-Bewertung bei Störungen.
|
||||
Der Agent kann bei abweichender Einschätzung (z.B. nur Teilausfall,
|
||||
Workaround verfügbar) manuell korrigieren.
|
||||
|
||||
mapping:
|
||||
- service_kritikalitaet: "geschaeftskritisch"
|
||||
impact_vorschlag: "HOCH"
|
||||
beschreibung: >
|
||||
Bei Störung eines geschäftskritischen Services wird
|
||||
Impact HOCH automatisch vorgeschlagen.
|
||||
agent_aktion: "Prüfen, ob Totalausfall vorliegt. Bei Teilausfall ggf. Abstufung."
|
||||
|
||||
- service_kritikalitaet: "wichtig"
|
||||
impact_vorschlag: "NORMAL"
|
||||
beschreibung: >
|
||||
Bei Störung eines wichtigen Services wird Impact NORMAL
|
||||
vorgeschlagen.
|
||||
agent_aktion: "Prüfen, ob weitere HOCH-Kriterien vorliegen (Sicherheit, Bürger, Leitungsebene)."
|
||||
|
||||
- service_kritikalitaet: "unterstuetzend"
|
||||
impact_vorschlag: "NIEDRIG"
|
||||
beschreibung: >
|
||||
Bei Störung eines unterstützenden Services wird Impact NIEDRIG
|
||||
vorgeschlagen, sofern keine anderen Faktoren vorliegen.
|
||||
agent_aktion: "Standardfall, Hochstufung nur bei besonderen Umständen."
|
||||
|
||||
hinweis_itsm: >
|
||||
Im ITSM-Tool sollte der Impact basierend auf dem betroffenen Service
|
||||
automatisch vorbelegt werden. Voraussetzung ist die Verknüpfung von
|
||||
Tickets mit Service-Stammdaten (Service-Katalog-Integration).
|
||||
Der Agent behält die Möglichkeit zur manuellen Korrektur mit Begründung.
|
||||
|
||||
hinweis_unbekannter_service: >
|
||||
Falls der betroffene Service nicht identifiziert werden kann oder
|
||||
nicht im Katalog geführt wird, erfolgt die Impact-Bewertung
|
||||
ausschließlich nach den Standard-Kriterien (Betroffenenzahl,
|
||||
Prozessblockade, etc.).
|
||||
|
||||
# =============================================================================
|
||||
# PRIORITÄTSSTUFEN
|
||||
# =============================================================================
|
||||
|
||||
prioritaetsstufen:
|
||||
|
||||
beschreibung: >
|
||||
Definition der vier Prioritätsstufen mit SLA-Zielen. Die Priorität
|
||||
bestimmt die verbindlichen Reaktions- und Lösungszeiten.
|
||||
|
||||
stufen:
|
||||
- id: "P1"
|
||||
name: "Kritisch"
|
||||
beschreibung: "Geschäftskritische Störung, sofortige Reaktion erforderlich"
|
||||
|
||||
sla_ziele:
|
||||
reaktionszeit: "15 Minuten"
|
||||
loesungszeit_ziel: "4 Stunden"
|
||||
loesungszeit_max: "8 Stunden"
|
||||
|
||||
eskalation:
|
||||
bei_ueberschreitung_reaktion: "Sofort an Queue-Koordinator"
|
||||
bei_ueberschreitung_loesung_50: "Service Owner informieren"
|
||||
bei_ueberschreitung_loesung_100: "Teamleitung + Service Owner"
|
||||
|
||||
behandlung:
|
||||
unterbrechung_erlaubt: true
|
||||
dedizierte_bearbeitung: true
|
||||
status_update_frequenz: "30 Minuten"
|
||||
|
||||
- id: "P2"
|
||||
name: "Hoch"
|
||||
beschreibung: "Erhebliche Beeinträchtigung, zeitnahe Reaktion erforderlich"
|
||||
|
||||
sla_ziele:
|
||||
reaktionszeit: "1 Stunde"
|
||||
loesungszeit_ziel: "8 Stunden"
|
||||
loesungszeit_max: "16 Stunden (2 AT)"
|
||||
|
||||
eskalation:
|
||||
bei_ueberschreitung_reaktion: "Queue-Koordinator informieren"
|
||||
bei_ueberschreitung_loesung_50: "Queue-Koordinator"
|
||||
bei_ueberschreitung_loesung_100: "Teamleitung"
|
||||
|
||||
behandlung:
|
||||
unterbrechung_erlaubt: false
|
||||
priorisierte_bearbeitung: true
|
||||
status_update_frequenz: "2 Stunden"
|
||||
|
||||
- id: "P3"
|
||||
name: "Normal"
|
||||
beschreibung: "Beeinträchtigung mit Workaround, normale Bearbeitung"
|
||||
|
||||
sla_ziele:
|
||||
reaktionszeit: "4 Stunden"
|
||||
loesungszeit_ziel: "3 Arbeitstage"
|
||||
loesungszeit_max: "5 Arbeitstage"
|
||||
|
||||
eskalation:
|
||||
bei_ueberschreitung_reaktion: "Automatische Queue-Warnung"
|
||||
bei_ueberschreitung_loesung_50: "Keine automatische Eskalation"
|
||||
bei_ueberschreitung_loesung_100: "Queue-Koordinator"
|
||||
|
||||
behandlung:
|
||||
unterbrechung_erlaubt: false
|
||||
priorisierte_bearbeitung: false
|
||||
status_update_frequenz: "1x täglich bei Nachfrage"
|
||||
|
||||
- id: "P4"
|
||||
name: "Niedrig"
|
||||
beschreibung: "Geringe Auswirkung, Bearbeitung nach Kapazität"
|
||||
|
||||
sla_ziele:
|
||||
reaktionszeit: "1 Arbeitstag"
|
||||
loesungszeit_ziel: "5 Arbeitstage"
|
||||
loesungszeit_max: "10 Arbeitstage"
|
||||
|
||||
eskalation:
|
||||
bei_ueberschreitung_reaktion: "Keine automatische Eskalation"
|
||||
bei_ueberschreitung_loesung_50: "Keine automatische Eskalation"
|
||||
bei_ueberschreitung_loesung_100: "Automatische Queue-Warnung"
|
||||
|
||||
behandlung:
|
||||
unterbrechung_erlaubt: false
|
||||
priorisierte_bearbeitung: false
|
||||
status_update_frequenz: "Bei Abschluss"
|
||||
|
||||
hinweis_sla: >
|
||||
Die SLA-Ziele sind Rahmenparameter. Verbindliche Service Levels werden
|
||||
in SLAs/SLS je Service definiert und können abweichen. Bei Abweichung
|
||||
gilt die service-spezifische Vereinbarung.
|
||||
|
||||
referenz_slm: "spm_practice_service-level-management.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# TICKET-CHARAKTERISTIK
|
||||
# =============================================================================
|
||||
|
||||
ticket_charakteristik:
|
||||
|
||||
beschreibung: >
|
||||
Die Ticket-Charakteristik ist ein beschreibendes Attribut (Label),
|
||||
das die Art des Tickets dokumentiert. Sie dient dem Reporting und
|
||||
der Identifikation von Wissenslücken, hat aber keine Steuerungsfunktion
|
||||
für die Pool-Zuordnung.
|
||||
|
||||
Die Pool-Zuordnung erfolgt ausschließlich über die Priorität.
|
||||
|
||||
konzeptionelle_einordnung: |
|
||||
Version 0.2: Die Charakteristik ANALYSE war ursprünglich als
|
||||
Steuerungsgröße für einen separaten "Analyse-Pool" konzipiert.
|
||||
Diese Trennung wurde aufgegeben, da die SLA bereits den zeitlichen
|
||||
Rahmen vorgibt. Die Charakteristik bleibt als Label für Reporting erhalten.
|
||||
|
||||
charakteristiken:
|
||||
|
||||
- id: "STANDARD"
|
||||
name: "Standard-Ticket"
|
||||
beschreibung: >
|
||||
Bekanntes Muster, klare Lösung dokumentiert. Kann nach
|
||||
Standardverfahren bearbeitet werden.
|
||||
indikatoren:
|
||||
- "Ähnliche Tickets wurden bereits gelöst"
|
||||
- "Lösungsweg ist dokumentiert (Wissensdatenbank)"
|
||||
- "Keine Diagnose erforderlich"
|
||||
- "Aufwand schätzbar (<30 Min typisch)"
|
||||
beispiele:
|
||||
- "Passwort zurücksetzen"
|
||||
- "Standard-Berechtigung vergeben"
|
||||
- "Bekannter Drucker-Treiber-Reset"
|
||||
- "Software aus Katalog installieren"
|
||||
|
||||
- id: "ANALYSE"
|
||||
name: "Analyse-Ticket"
|
||||
beschreibung: >
|
||||
Unklare Ursache, Diagnose erforderlich. Lösungsweg nicht
|
||||
unmittelbar erkennbar. Dieses Label kennzeichnet Tickets,
|
||||
bei denen der Agent eigenständig Diagnosearbeit leisten muss.
|
||||
indikatoren:
|
||||
- "Ursache nicht sofort erkennbar"
|
||||
- "Intermittierendes Problem"
|
||||
- "Unspezifische Fehlerbeschreibung"
|
||||
- "Kein bekanntes Muster"
|
||||
beispiele:
|
||||
- "Outlook stürzt manchmal ab"
|
||||
- "PC ist langsam"
|
||||
- "Irgendwas funktioniert nicht richtig"
|
||||
- "Sporadische Fehlermeldung"
|
||||
|
||||
reporting_nutzen:
|
||||
- "Anteil unklarer Tickets messen"
|
||||
- "Wissenslücken in Dokumentation erkennen"
|
||||
- "Schulungsbedarf identifizieren"
|
||||
- "Service-Owner auf Dokumentationsbedarf hinweisen"
|
||||
|
||||
hinweis: |
|
||||
Die Charakteristik ANALYSE führt NICHT zu einem separaten Pool.
|
||||
ANALYSE-Tickets werden im Standard-Pool bearbeitet, die SLA gibt
|
||||
den zeitlichen Rahmen vor. Der Agent entscheidet eigenverantwortlich
|
||||
über sein Vorgehen (Enablement-Philosophie).
|
||||
|
||||
- id: "PROJEKT"
|
||||
name: "Projekt-Ticket"
|
||||
beschreibung: >
|
||||
Planbare, umfangreiche Aufgabe. Erfordert Koordination mit
|
||||
Stakeholdern und kann terminiert werden.
|
||||
indikatoren:
|
||||
- "Aufwand >1 Arbeitstag"
|
||||
- "Mehrere Beteiligte erforderlich"
|
||||
- "Terminabstimmung notwendig"
|
||||
- "Keine sofortige Bearbeitung erwartet"
|
||||
beispiele:
|
||||
- "Arbeitsplatz-Neueinrichtung"
|
||||
- "Büroumzug"
|
||||
- "Komplexe Berechtigungsstruktur"
|
||||
|
||||
hinweis: >
|
||||
Projekt-Tickets werden aus operativen KPIs exkludiert.
|
||||
Schwelle für Umklassifikation: >20 Arbeitstage Laufzeit.
|
||||
|
||||
# =============================================================================
|
||||
# POOL-MODELL
|
||||
# =============================================================================
|
||||
|
||||
pool_modell:
|
||||
|
||||
beschreibung: >
|
||||
Drei Pools zur Steuerung der Arbeitsorganisation. Die Pool-Zuordnung
|
||||
erfolgt primär über die Priorität. Die SLA gibt den verbindlichen
|
||||
Zeitrahmen vor.
|
||||
|
||||
Version 0.2: Reduktion von vier auf drei Pools. Der bisherige
|
||||
"Analyse-Pool" entfällt – ANALYSE-Tickets werden im Standard-Pool
|
||||
bearbeitet. Die Charakteristik ANALYSE bleibt als Label erhalten.
|
||||
|
||||
referenz: "LS-04 (Design-Zieldimensionen)"
|
||||
|
||||
design_entscheidung: |
|
||||
Die Trennung in Standard- und Analyse-Pool wurde aufgegeben, da:
|
||||
- Die SLA bereits den zeitlichen Rahmen vorgibt
|
||||
- Ein separates "Explorationsbudget" redundant zur SLA ist
|
||||
- Die Enablement-Philosophie (Agent darf eigenverantwortlich arbeiten)
|
||||
keine Pool-Trennung erfordert
|
||||
- Einfachere Steuerung mit weniger Pools
|
||||
|
||||
pools:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: "POOL-SOFORT"
|
||||
name: "Sofort-Pool"
|
||||
|
||||
beschreibung: >
|
||||
Kritische Tickets, die sofortige Aufmerksamkeit erfordern.
|
||||
Unterbrechung laufender Arbeit ist legitimiert.
|
||||
|
||||
eingangs_kriterien:
|
||||
- "Priorität P1 (alle Charakteristiken)"
|
||||
- "ODER Priorität P2 + Charakteristik STANDARD bei kritischer Queue-Lage"
|
||||
|
||||
regeln:
|
||||
max_liegezeit: "15 Minuten"
|
||||
aktion_bei_ueberschreitung: "Automatische Alarmierung Queue-Koordinator"
|
||||
bearbeitungsmodus: "Dediziert, keine parallele Arbeit"
|
||||
unterbrechung_laufender_arbeit: true
|
||||
|
||||
kapazitaet:
|
||||
warnung_bei: ">2 Tickets gleichzeitig"
|
||||
aktion: "Eskalation an Teamleitung, Ressourcen-Umverteilung"
|
||||
|
||||
commitment:
|
||||
grundregel: "Ticket gezogen = Ticket owned bis Lösung oder Eskalation"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: "POOL-STANDARD"
|
||||
name: "Standard-Pool"
|
||||
|
||||
beschreibung: >
|
||||
Alle nicht-kritischen Tickets (P2/P3/P4), unabhängig von der
|
||||
Charakteristik (STANDARD oder ANALYSE). Bearbeitung nach
|
||||
FIFO-Prinzip, priorisiert nach Prioritätsstufe. Die SLA gibt
|
||||
den verbindlichen Zeitrahmen vor.
|
||||
|
||||
eingangs_kriterien:
|
||||
- "Priorität P2/P3/P4 (alle Charakteristiken außer PROJEKT)"
|
||||
|
||||
typische_tickets:
|
||||
- "Passwort-Resets (STANDARD)"
|
||||
- "Standard-Berechtigungsanfragen (STANDARD)"
|
||||
- "Account-Entsperrungen (STANDARD)"
|
||||
- "Software-Installation aus Katalog (STANDARD)"
|
||||
- "Drucker-Probleme mit bekannter Lösung (STANDARD)"
|
||||
- "Unklare Fehlerbeschreibungen (ANALYSE)"
|
||||
- "Intermittierende Probleme (ANALYSE)"
|
||||
- "Performance-Beschwerden (ANALYSE)"
|
||||
|
||||
regeln:
|
||||
max_tickets_im_pool: 30
|
||||
aktion_bei_ueberschreitung: "Kapazitätsalarm an Queue-Koordinator"
|
||||
bearbeitungsmodus: "FIFO nach Priorität"
|
||||
zeitrahmen: "SLA gibt Reaktions- und Lösungszeit vor"
|
||||
|
||||
enablement_philosophie: |
|
||||
Der Agent entscheidet eigenverantwortlich über sein Vorgehen:
|
||||
- Bei STANDARD-Tickets: Dokumentierte Lösung anwenden
|
||||
- Bei ANALYSE-Tickets: Eigenständige Diagnose, Eskalation wenn nötig
|
||||
Die SLA gibt den Rahmen vor, innerhalb dessen der Agent arbeitet.
|
||||
|
||||
commitment:
|
||||
grundregel: "Ticket gezogen = Ticket owned"
|
||||
legitime_ausgaenge:
|
||||
- "gelöst: Ticket wird mit Lösung geschlossen"
|
||||
- "eskaliert: Formale Weitergabe mit dokumentierter Begründung"
|
||||
- "geparkt: Mit konkretem Grund (wartet auf Nutzer, wartet auf System)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
- id: "POOL-PROJEKT"
|
||||
name: "Projekt-Pool"
|
||||
|
||||
beschreibung: >
|
||||
Planbare Aufgaben, die nicht im normalen Queue-Flow bearbeitet
|
||||
werden. Terminierung mit betroffenen Stakeholdern.
|
||||
|
||||
eingangs_kriterien:
|
||||
- "Charakteristik PROJEKT (unabhängig von Priorität)"
|
||||
- "ODER Umklassifikation bei Laufzeit >20 Arbeitstage"
|
||||
|
||||
typische_tickets:
|
||||
- "Neue Arbeitsplatz-Einrichtung"
|
||||
- "Umzüge"
|
||||
- "Komplexe Berechtigungsstrukturen"
|
||||
- "Größere Software-Deployments"
|
||||
|
||||
regeln:
|
||||
queue_steuerung: false
|
||||
terminierung: "Abstimmung mit betroffenen Stakeholdern"
|
||||
kapazitaetsplanung: "Durch Queue-Koordinator / Teamleitung"
|
||||
|
||||
kpi_behandlung:
|
||||
in_operativen_kpis: false
|
||||
separate_auswertung: true
|
||||
begruendung: "Verzerrt MTTR-Metriken, andere Steuerungslogik"
|
||||
|
||||
# =============================================================================
|
||||
# ABLEITUNGSLOGIK: PRIORITÄT × CHARAKTERISTIK → POOL
|
||||
# =============================================================================
|
||||
|
||||
ableitungslogik:
|
||||
|
||||
beschreibung: >
|
||||
Die Pool-Zuordnung erfolgt primär über die Priorität.
|
||||
Die Charakteristik (STANDARD/ANALYSE) ist ein beschreibendes Label
|
||||
ohne Einfluss auf die Pool-Zuordnung.
|
||||
|
||||
Version 0.2: Vereinfachte Logik ohne Analyse-Pool.
|
||||
|
||||
# TICKET-CHARAKTERISTIK
|
||||
# STANDARD ANALYSE PROJEKT
|
||||
# PRIORITÄT
|
||||
# P1 SOFORT SOFORT (nicht möglich)
|
||||
# P2 STANDARD STANDARD (nicht möglich)
|
||||
# P3 STANDARD STANDARD PROJEKT
|
||||
# P4 STANDARD STANDARD PROJEKT
|
||||
|
||||
logik:
|
||||
beschreibung: |
|
||||
1. P1 → Sofort-Pool (unabhängig von Charakteristik)
|
||||
2. P2/P3/P4 + PROJEKT → Projekt-Pool
|
||||
3. P2/P3/P4 + STANDARD oder ANALYSE → Standard-Pool
|
||||
|
||||
mapping:
|
||||
- prioritaet: "P1"
|
||||
pool: "POOL-SOFORT"
|
||||
hinweis: "Alle P1-Tickets, unabhängig von Charakteristik"
|
||||
|
||||
- prioritaet: "P2"
|
||||
charakteristik: "STANDARD oder ANALYSE"
|
||||
pool: "POOL-STANDARD"
|
||||
|
||||
- prioritaet: "P2"
|
||||
charakteristik: "PROJEKT"
|
||||
pool: null
|
||||
hinweis: "P2 + PROJEKT ist selten. Prüfen und ggf. umklassifizieren."
|
||||
|
||||
- prioritaet: "P3"
|
||||
charakteristik: "STANDARD oder ANALYSE"
|
||||
pool: "POOL-STANDARD"
|
||||
|
||||
- prioritaet: "P3"
|
||||
charakteristik: "PROJEKT"
|
||||
pool: "POOL-PROJEKT"
|
||||
|
||||
- prioritaet: "P4"
|
||||
charakteristik: "STANDARD oder ANALYSE"
|
||||
pool: "POOL-STANDARD"
|
||||
|
||||
- prioritaet: "P4"
|
||||
charakteristik: "PROJEKT"
|
||||
pool: "POOL-PROJEKT"
|
||||
|
||||
# =============================================================================
|
||||
# KLASSIFIKATIONSPROZESS
|
||||
# =============================================================================
|
||||
|
||||
klassifikationsprozess:
|
||||
|
||||
beschreibung: >
|
||||
Ablauf der Ticket-Klassifikation bei Erfassung. Der Prozess ist
|
||||
verbindlich für alle Tickets anzuwenden.
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Ticket-Typ bestimmen"
|
||||
aktion: "Entscheidungsbaum Typ anwenden"
|
||||
ergebnis: "INCIDENT / REQUEST / PROJEKT"
|
||||
verantwortlich: "First Level Agent"
|
||||
|
||||
- schritt: 2
|
||||
name: "Impact bewerten"
|
||||
aktion: "Impact-Kriterien prüfen"
|
||||
ergebnis: "HOCH / NORMAL / NIEDRIG"
|
||||
verantwortlich: "First Level Agent"
|
||||
|
||||
- schritt: 3
|
||||
name: "Urgency bewerten"
|
||||
aktion: "Urgency-Kriterien prüfen"
|
||||
ergebnis: "HOCH / NORMAL / NIEDRIG"
|
||||
verantwortlich: "First Level Agent"
|
||||
|
||||
- schritt: 4
|
||||
name: "Priorität ableiten"
|
||||
aktion: "Matrix anwenden"
|
||||
ergebnis: "P1 / P2 / P3 / P4"
|
||||
verantwortlich: "System (automatisch) oder First Level Agent"
|
||||
|
||||
- schritt: 5
|
||||
name: "Charakteristik bestimmen"
|
||||
aktion: "Indikatoren prüfen"
|
||||
ergebnis: "STANDARD / ANALYSE / PROJEKT"
|
||||
verantwortlich: "First Level Agent"
|
||||
|
||||
- schritt: 6
|
||||
name: "Pool zuweisen"
|
||||
aktion: "Ableitungslogik anwenden"
|
||||
ergebnis: "Pool-Zuordnung"
|
||||
verantwortlich: "System (automatisch) oder Queue-Koordinator"
|
||||
|
||||
qualitaetssicherung:
|
||||
stichproben: "Queue-Koordinator prüft stichprobenartig Klassifikationen"
|
||||
korrektur: "Umklassifikation bei Fehlern, Feedback an Agent"
|
||||
eskalation: "Bei systematischen Fehlern → Schulungsbedarf"
|
||||
|
||||
# =============================================================================
|
||||
# UMKLASSIFIKATION
|
||||
# =============================================================================
|
||||
|
||||
umklassifikation:
|
||||
|
||||
beschreibung: >
|
||||
Regeln für die nachträgliche Änderung von Klassifikationen.
|
||||
|
||||
erlaubte_aenderungen:
|
||||
- szenario: "Neue Informationen ändern Impact/Urgency"
|
||||
aktion: "Priorität anpassen, Pool ggf. wechseln"
|
||||
berechtigt: "Bearbeitender Agent, Queue-Koordinator"
|
||||
dokumentation: "Grund im Ticket vermerken"
|
||||
|
||||
- szenario: "Analyse ergibt bekanntes Muster"
|
||||
aktion: "Charakteristik ANALYSE → STANDARD"
|
||||
berechtigt: "Bearbeitender Agent"
|
||||
dokumentation: "Nicht erforderlich"
|
||||
|
||||
- szenario: "Ticket entwickelt sich zum Projekt"
|
||||
aktion: "Charakteristik → PROJEKT, Pool-Wechsel"
|
||||
berechtigt: "Queue-Koordinator, Teamleitung"
|
||||
dokumentation: "Grund im Ticket vermerken"
|
||||
|
||||
- szenario: "Langläufer (>20 AT)"
|
||||
aktion: "Automatische Kennzeichnung als Langläufer"
|
||||
berechtigt: "System (automatisch)"
|
||||
konsequenz: "Aus operativen KPIs exkludiert"
|
||||
governance: "SSM-G-07"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
governance:
|
||||
|
||||
entscheidungen:
|
||||
- id: "KLASS-G-01"
|
||||
thema: "Verbindlichkeit der Matrix"
|
||||
entscheidung: >
|
||||
Die Impact-Urgency-Matrix ist verbindlich anzuwenden.
|
||||
Abweichungen nur durch Queue-Koordinator oder Teamleitung.
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "KLASS-G-02"
|
||||
thema: "Charakteristik ANALYSE als Label"
|
||||
entscheidung: |
|
||||
Die Charakteristik ANALYSE ist ein beschreibendes Attribut (Label)
|
||||
ohne Steuerungsfunktion für die Pool-Zuordnung. ANALYSE-Tickets
|
||||
werden im Standard-Pool bearbeitet.
|
||||
|
||||
Nutzen des Labels:
|
||||
- Reporting (Übersicht über Anteil unklarer Tickets)
|
||||
- Identifikation von Wissenslücken
|
||||
- Hinweis auf Dokumentationsbedarf
|
||||
version: "0.2 - ersetzt bisherige Explorative-Diagnose-Regelung"
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "KLASS-G-03"
|
||||
thema: "Drei-Pool-Modell"
|
||||
entscheidung: |
|
||||
Das Pool-Modell umfasst drei Pools:
|
||||
- Sofort-Pool (P1)
|
||||
- Standard-Pool (P2/P3/P4, alle Charakteristiken außer PROJEKT)
|
||||
- Projekt-Pool (Charakteristik PROJEKT)
|
||||
|
||||
Der bisherige Analyse-Pool entfällt. Die SLA gibt den zeitlichen
|
||||
Rahmen vor, ein separates Explorationsbudget ist nicht erforderlich.
|
||||
version: "0.2"
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "KLASS-G-04"
|
||||
thema: "Projekt-Schwelle"
|
||||
entscheidung: >
|
||||
Tickets >20 Arbeitstage Laufzeit werden als Langläufer
|
||||
klassifiziert und aus operativen KPIs exkludiert.
|
||||
referenz: "SSM-G-07"
|
||||
status: "vorgeschlagen"
|
||||
|
||||
raci:
|
||||
- aktivitaet: "Klassifikation durchführen"
|
||||
r: "First Level Agent"
|
||||
a: "Queue-Koordinator"
|
||||
c: "-"
|
||||
i: "-"
|
||||
|
||||
- aktivitaet: "Klassifikation prüfen/korrigieren"
|
||||
r: "Queue-Koordinator"
|
||||
a: "Service Desk Manager"
|
||||
c: "First Level Agent"
|
||||
i: "-"
|
||||
|
||||
- aktivitaet: "Matrix pflegen/anpassen"
|
||||
r: "Service Desk Manager"
|
||||
a: "Service-Portfolio-Manager"
|
||||
c: "Queue-Koordinator, Service Owner"
|
||||
i: "First Level Agents"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- modul: "sub-practice_incident-management.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Incident-Prozess nutzt Klassifikation für Priorisierung und Pool-Zuweisung"
|
||||
|
||||
- modul: "sub-practice_request-management.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Request-Prozess nutzt Klassifikation für Priorisierung und Pool-Zuweisung"
|
||||
|
||||
- modul: "spm_practice_service-level-management.yaml"
|
||||
art: "liefert an"
|
||||
beschreibung: "SLA-Rahmen für Prioritätsstufen"
|
||||
|
||||
- modul: "ssm_schema_ticket.yaml"
|
||||
art: "definiert Attribute für"
|
||||
beschreibung: "Priorität, Charakteristik, Pool als Ticket-Attribute"
|
||||
|
||||
- modul: "sub-practice_service-desk.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Triage-Prozess nutzt Klassifikation und Pool-Zuweisung"
|
||||
|
||||
- modul: "ssm_governance.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Zeitbasierte Eskalation referenziert Pool-Schwellwerte"
|
||||
|
||||
- modul: "spm_schema_service-definition.yaml"
|
||||
art: "erhält von"
|
||||
beschreibung: "Service-Kritikalitätsstufe für Impact-Vorschlag bei Incidents"
|
||||
|
||||
extern:
|
||||
- partner: "ITSM-Tool"
|
||||
kontext: "Umsetzung der Matrix, automatische Pool-Zuweisung, Eskalations-Trigger"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.4"
|
||||
datum: "2026-01-29"
|
||||
aenderung: |
|
||||
Überarbeitung Impact- und Urgency-Kriterien:
|
||||
|
||||
Impact HOCH:
|
||||
- Entfernt: ">10 Nutzer" als eigenständiges Kriterium (Vertrauen auf Kritikalitätsstufe)
|
||||
- Neu: "Bürger durch Ausfall direkt betroffen" mit Beispielen
|
||||
- Präzisiert: Leitungsebene mit Verweis auf lebendes Arbeitsdokument (SOR-Entscheidung)
|
||||
- Hinweise zu Bürger-Kriterium und Leitungsebene ergänzt
|
||||
|
||||
Impact NORMAL:
|
||||
- Geändert: ">1 Nutzer oder Teams/Bereiche" (statt 2-10)
|
||||
- Neu: Kritikalitätsstufe 'wichtig' als Kriterium
|
||||
|
||||
Impact NIEDRIG:
|
||||
- Neu: Kritikalitätsstufe 'unterstuetzend' als Kriterium
|
||||
- Konsolidiert: Komfort + Einzelnutzer
|
||||
|
||||
Urgency HOCH:
|
||||
- Konsolidiert: Arbeitsfähigkeit + Workaround in einem Kriterium
|
||||
- Präzisiert: "externe Frist, rechtliche Vorgabe, Termin mit Externen"
|
||||
|
||||
Urgency NIEDRIG:
|
||||
- Entfernt: Komfort (nur noch bei Impact)
|
||||
- Fokus auf zeitliche Aspekte
|
||||
|
||||
Service-Kritikalitäts-Mapping:
|
||||
- Angepasst: Entfernung ">10 Betroffene"-Hinweis bei 'wichtig'
|
||||
autor: "DIGITOM-Projekt"
|
||||
kontext: "Präzisierung der Priorisierungslogik für 1st Level Support"
|
||||
|
||||
- version: "0.3"
|
||||
datum: "2026-01-28"
|
||||
aenderung: |
|
||||
Integration Service-Kritikalität:
|
||||
- Impact-Kriterium HOCH: Ergänzung "Service mit Kritikalitätsstufe 'geschaeftskritisch'"
|
||||
- Neuer Abschnitt 'service_kritikalitaet_mapping' für systematische Verknüpfung
|
||||
- Schnittstelle zu spm_schema_service-definition.yaml dokumentiert
|
||||
autor: "DIGITOM-Projekt"
|
||||
kontext: "Konsistente Incident-Priorisierung basierend auf Service-Portfolio"
|
||||
|
||||
- version: "0.2"
|
||||
datum: "2026-01-28"
|
||||
aenderung: |
|
||||
Vereinfachung des Pool-Modells:
|
||||
- Reduktion von vier auf drei Pools (Analyse-Pool entfällt)
|
||||
- Charakteristik ANALYSE wird zum beschreibenden Label (keine Pool-Steuerung)
|
||||
- Explorationsbudget entfällt als eigenständiges Konzept (SLA gibt Rahmen vor)
|
||||
- Pool-Zuordnung erfolgt primär über Priorität
|
||||
- Enablement-Philosophie bleibt erhalten (Agent entscheidet eigenverantwortlich)
|
||||
autor: "DIGITOM-Projekt"
|
||||
governance: "Konzeptionelle Vereinfachung nach Review"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-07"
|
||||
aenderung: "Initiale Erstellung"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,500 @@
|
|||
# =============================================================================
|
||||
# SERVICE-SUPPORT-MANAGEMENT: ROLLEN
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SSM-ROLLEN"
|
||||
name: "Rollen Service-Support-Management"
|
||||
version: "0.2"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-07"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: |
|
||||
Konsolidierte Rollendefinitionen für das Service-Support-Management.
|
||||
Erweitert und konkretisiert die generischen Rollen aus
|
||||
spm_rollen.yaml für den Support-Kontext.
|
||||
|
||||
referenz_basis: "02_spm_service-lifecycle-blueprint/spm_rollen.yaml"
|
||||
|
||||
design_referenz: "ssm_design-zieldimensionen.yaml"
|
||||
relevante_saeulen: ["LS-03"]
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENKATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
rollenkategorien:
|
||||
|
||||
- kategorie: "Operative Rollen"
|
||||
beschreibung: "Rollen in der direkten Ticket-Bearbeitung"
|
||||
rollen: ["first_level_agent", "second_level_agent"]
|
||||
|
||||
- kategorie: "Koordinations-Rollen"
|
||||
beschreibung: "Rollen in der Steuerung und Koordination"
|
||||
rollen: ["queue_koordinator"]
|
||||
|
||||
- kategorie: "Management-Rollen"
|
||||
beschreibung: "Rollen mit Führungs- und Prozessverantwortung"
|
||||
rollen: ["support_manager", "service_owner"]
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENDEFINITIONEN
|
||||
# =============================================================================
|
||||
|
||||
rollen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# OPERATIVE ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
- id: "first_level_agent"
|
||||
name: "First Level Agent"
|
||||
kurzform: "L1-Agent"
|
||||
kategorie: "Operative Rollen"
|
||||
|
||||
beschreibung: |
|
||||
Bearbeiter im First Level Support. Erster Ansprechpartner für
|
||||
Nutzer, verantwortlich für Ticket-Erfassung, Erstdiagnose und
|
||||
Lösung dokumentierter Störungen.
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Ticket-Erfassung und Qualifizierung (DoR-Prüfung)"
|
||||
- "Klassifikation und Priorisierung nach Matrix"
|
||||
- "KB-Konsultation und Erstdiagnose"
|
||||
- "Lösung von Incidents im L1-Scope"
|
||||
- "Bearbeitung von Standard-Requests"
|
||||
- "Dokumentation aller Aktivitäten im Ticket"
|
||||
- "Eskalation an L2 mit vollständiger DoH"
|
||||
- "Erstellung von KB-Artikeln (Ebene 3)"
|
||||
|
||||
befugnisse:
|
||||
- "Ticket-Annahme und Selbstzuweisung (Standard-/Sofort-Pool)"
|
||||
- "Priorisierung nach Impact-Urgency-Matrix"
|
||||
- "Funktionale Eskalation an L2"
|
||||
- "Änderung von KB-Artikeln Ebene 3"
|
||||
|
||||
einschraenkungen:
|
||||
- "Keine Priorisierungs-Abweichung von Matrix ohne Genehmigung"
|
||||
- "Keine Ticket-Rückgabe ohne Empfänger-Akzeptanz"
|
||||
- "Keine Änderung von KB-Artikeln Ebene 1/2"
|
||||
|
||||
scope_definition:
|
||||
kann_loesen_wenn:
|
||||
- "KB-Artikel oder dokumentierte Lösung vorhanden"
|
||||
- "Erforderliche technische Berechtigung vorhanden"
|
||||
- "Lösung liegt im definierten L1-Scope"
|
||||
eskaliert_wenn:
|
||||
- "Keine passende Dokumentation vorhanden"
|
||||
- "Berechtigung fehlt"
|
||||
- "Explorative Diagnose (90-120 Min) ausgeschöpft ohne Fortschritt"
|
||||
- "P1 nicht in 15 Min lösbar"
|
||||
|
||||
qualifikation:
|
||||
- "Grundkenntnisse der unterstützten Services"
|
||||
- "ITSM-Tool-Schulung"
|
||||
- "Kommunikationsfähigkeit"
|
||||
- "KB-Nutzung und -Pflege"
|
||||
|
||||
yasm_entsprechung: "1st Level Support"
|
||||
itil4_entsprechung: "Service Desk Agent"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
- id: "second_level_agent"
|
||||
name: "Second Level Agent"
|
||||
kurzform: "L2-Agent"
|
||||
kategorie: "Operative Rollen"
|
||||
|
||||
beschreibung: |
|
||||
Spezialist im Second Level Support. Bearbeitet komplexe
|
||||
Incidents, die im L1 nicht lösbar sind. Tiefergehende
|
||||
technische Diagnose und Lösung.
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Bearbeitung eskalierter Incidents"
|
||||
- "Tiefergehende technische Diagnose"
|
||||
- "Lösung komplexer Störungen"
|
||||
- "Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten"
|
||||
- "Erstellung von Problem Records bei Bedarf"
|
||||
- "Dokumentation von Lösungen und Workarounds"
|
||||
- "Erstellung/Pflege von KB-Artikeln (Ebene 2 und 3)"
|
||||
- "Unterstützung bei Major Incidents"
|
||||
- "Problem Records erstellen (bei Erkennung in Incident-Bearbeitung)"
|
||||
- "Root-Cause-Analyse durchführen (bei Delegation durch Service Owner)"
|
||||
- "Known-Error-Artikel erstellen und pflegen"
|
||||
|
||||
befugnisse:
|
||||
- "Ticket-Annahme aus L2-Pool"
|
||||
- "Eskalation an L3/Externe"
|
||||
- "Problem Record erstellen"
|
||||
- "Change Request initiieren"
|
||||
- "KB-Artikel Ebene 2 erstellen (mit SO-Freigabe)"
|
||||
- "KB-Artikel Ebene 3 erstellen und ändern"
|
||||
|
||||
einschraenkungen:
|
||||
- "Keine Ticket-Rückgabe an L1 ohne Akzeptanz + Begründung"
|
||||
- "Keine Freigabe von KB-Artikeln Ebene 1"
|
||||
|
||||
qualifikation:
|
||||
- "Vertiefte technische Kenntnisse in Fachgebiet"
|
||||
- "Diagnose- und Problemlösungskompetenz"
|
||||
- "Erfahrung mit Root-Cause-Analyse"
|
||||
|
||||
spezialisierungen:
|
||||
beschreibung: |
|
||||
L2-Agents können nach Fachgebiet spezialisiert sein.
|
||||
Die Zuweisung erfolgt über Domain-Pools.
|
||||
beispiele:
|
||||
- "Netzwerk & Infrastruktur"
|
||||
- "Client & Workplace"
|
||||
- "Fachverfahren (SAP, GIS, etc.)"
|
||||
- "E-Mail & Collaboration"
|
||||
|
||||
yasm_entsprechung: "2nd Level Support"
|
||||
itil4_entsprechung: "Technical Support Specialist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KOORDINATIONS-ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
- id: "queue_koordinator"
|
||||
name: "Queue-Koordinator"
|
||||
kurzform: "QK"
|
||||
kategorie: "Koordinations-Rollen"
|
||||
|
||||
beschreibung: |
|
||||
Verantwortlich für die operative Steuerung der Ticket-Queues.
|
||||
Überwacht Workload, priorisiert innerhalb der Pools und
|
||||
koordiniert bei Engpässen oder Konflikten.
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Überwachung der Ticket-Queues und SLA-Status"
|
||||
- "Aktive Zuweisung im Analyse-Pool"
|
||||
- "Priorisierung bei Konflikten innerhalb eines Pools"
|
||||
- "Entscheidung bei Übergabe-Konflikten"
|
||||
- "Erste Eskalationsstufe für operative Probleme"
|
||||
- "Qualitätssicherung: Stichproben-Review von DoH und KB-Artikeln"
|
||||
- "Koordination bei Kapazitätsengpässen"
|
||||
- "Leitung des monatlichen KB-Reviews (Ebene 3)"
|
||||
- "Wiederkehrende Incident-Muster in Queues erkennen"
|
||||
- "Service Owner auf erkannte Muster hinweisen"
|
||||
|
||||
befugnisse:
|
||||
- "Ticket-Umpriorisierung (mit Begründung)"
|
||||
- "Ticket-Zuweisung und -Umzuweisung"
|
||||
- "Eskalation an Teamleitung"
|
||||
- "Wiedereröffnung geschlossener Tickets"
|
||||
- "Freigabe von Abweichungen von Standard-Prozess"
|
||||
|
||||
einschraenkungen:
|
||||
- "Keine eigene Ticket-Bearbeitung (Fokus auf Koordination)"
|
||||
- "Keine SLA-Änderungen"
|
||||
|
||||
modelle:
|
||||
beschreibung: |
|
||||
Je nach Teamgröße und -struktur kann die Rolle unterschiedlich
|
||||
besetzt werden.
|
||||
varianten:
|
||||
- modell: "Dediziert"
|
||||
beschreibung: "Eigenständige Rolle, keine Ticket-Bearbeitung"
|
||||
empfohlen_ab: "Team > 10 Agents"
|
||||
- modell: "Rotierend"
|
||||
beschreibung: "Wechselnde Besetzung durch erfahrene Agents"
|
||||
empfohlen_fuer: "Kleinere Teams"
|
||||
- modell: "Teilzeit"
|
||||
beschreibung: "Kombiniert mit L2-Tätigkeit"
|
||||
empfohlen_fuer: "Mittlere Teams"
|
||||
|
||||
design_referenz: "LS-03 (Organisation & Teamstruktur)"
|
||||
|
||||
qualifikation:
|
||||
- "Erfahrung im First oder Second Level Support (mind. 2 Jahre)"
|
||||
- "Überblick über alle unterstützten Services"
|
||||
- "Priorisierungs- und Entscheidungskompetenz"
|
||||
- "Kommunikationsfähigkeit und Durchsetzungsvermögen"
|
||||
- "ITSM-Tool: Fortgeschrittene Kenntnisse (Reporting, Queue-Mgmt)"
|
||||
- "Verständnis von SLA-Strukturen und Eskalationswegen"
|
||||
|
||||
yasm_entsprechung: "-"
|
||||
itil4_entsprechung: "Queue Manager / Shift Lead"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MANAGEMENT-ROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
- id: "support_manager"
|
||||
name: "Support Manager"
|
||||
kurzform: "SM"
|
||||
kategorie: "Management-Rollen"
|
||||
|
||||
beschreibung: |
|
||||
Gesamtverantwortung für den Service-Support-Bereich.
|
||||
Prozess-Owner für Incident, Request und Problem Management.
|
||||
Führungsverantwortung für das Support-Team.
|
||||
|
||||
verantwortlichkeiten:
|
||||
- "Prozess-Ownership für SSM-Practices"
|
||||
- "Führung des Support-Teams"
|
||||
- "Kapazitätsplanung und Ressourcenmanagement"
|
||||
- "Eskalationsstufe für nicht lösbare Konflikte"
|
||||
- "Reporting und KPI-Verantwortung"
|
||||
- "Kontinuierliche Prozessverbesserung"
|
||||
- "Schnittstelle zu Service Ownern"
|
||||
- "Budget-Verantwortung für Support-Bereich"
|
||||
|
||||
befugnisse:
|
||||
- "Prozess-Änderungen (mit Governance-Dokumentation)"
|
||||
- "Ressourcen-Allokation"
|
||||
- "SLA-Verhandlung (in Abstimmung mit Service Owner)"
|
||||
- "Eskalation an Abteilungsleitung"
|
||||
|
||||
accountable_fuer:
|
||||
- "Incident Management (P-04)"
|
||||
- "Request Management (P-05)"
|
||||
- "Problem Management (P-06)"
|
||||
- "Service Desk (P-SD)"
|
||||
- "KB Ebene 3 Qualität"
|
||||
|
||||
einschraenkungen:
|
||||
- "Keine operative Ticket-Bearbeitung (Fokus auf Steuerung)"
|
||||
- "SLA-Änderungen nur in Abstimmung mit Service Owner"
|
||||
- "Prozess-Änderungen erfordern Governance-Dokumentation"
|
||||
- "Budget-Entscheidungen über definiertem Schwellwert erfordern Genehmigung"
|
||||
|
||||
qualifikation:
|
||||
- "Mehrjährige Erfahrung im IT-Service-Management"
|
||||
- "Führungserfahrung (Team > 5 Personen)"
|
||||
- "ITIL Foundation oder vergleichbare Zertifizierung"
|
||||
- "Kenntnisse in Prozessmanagement und -optimierung"
|
||||
- "Erfahrung mit KPI-Definition und Reporting"
|
||||
- "Kommunikations- und Konfliktlösungskompetenz"
|
||||
|
||||
yasm_entsprechung: "Service Desk Manager"
|
||||
itil4_entsprechung: "Service Desk Manager"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
- id: "service_owner"
|
||||
name: "Service Owner"
|
||||
kurzform: "SO"
|
||||
kategorie: "Management-Rollen"
|
||||
|
||||
beschreibung: |
|
||||
End-to-End-Verantwortung für einen spezifischen Service.
|
||||
Im Support-Kontext: Fachliche Eskalationsinstanz und
|
||||
Verantwortlicher für Service-spezifische Dokumentation.
|
||||
|
||||
verantwortlichkeiten_support:
|
||||
- "Fachliche Eskalationsinstanz bei Major Incidents"
|
||||
- "Verantwortung für KB Ebene 1 (Grundlagendokumentation)"
|
||||
- "Co-Creation KB Ebene 2 (Arbeitsdokumentation)"
|
||||
- "SLA-Vereinbarung und -Überwachung für den Service"
|
||||
- "Entscheidung bei Service-spezifischen Priorisierungskonflikten"
|
||||
- "Kommunikation bei schwerwiegenden Service-Störungen"
|
||||
- "Process Owner für Problem Management im eigenen Service-Bereich"
|
||||
- "Koordination und ggf. Durchführung von Root-Cause-Analysen"
|
||||
- "Sicherstellung der Workaround-Dokumentation"
|
||||
- "Entscheidung über permanente Lösungen (Change-Initiierung)"
|
||||
- "Problem-Priorisierung und -Überwachung"
|
||||
|
||||
befugnisse_support:
|
||||
- "Fachliche Eskalationsentscheidung bei Major Incidents"
|
||||
- "Freigabe von KB-Artikeln Ebene 1 und 2"
|
||||
- "Priorisierungs-Override für Service-spezifische Tickets (mit Begründung)"
|
||||
- "Change-Initiierung aus Problem Management"
|
||||
- "SLA-Vereinbarung und -Anpassung für den Service"
|
||||
- "Delegation von Problem-Management-Aufgaben an L2-Agents"
|
||||
- "Problem Records priorisieren und schließen"
|
||||
|
||||
einschraenkungen_support:
|
||||
- "Keine operative Ticket-Bearbeitung (außer im MVP als Teil des L2-Teams)"
|
||||
- "Keine Pool-Steuerung (Verantwortung Queue-Koordinator)"
|
||||
- "Keine Änderung von SSM-Prozessen ohne Abstimmung mit Support Manager"
|
||||
|
||||
qualifikation_support:
|
||||
- "Tiefes Fachwissen zum verantworteten Service"
|
||||
- "Verständnis der End-to-End-Servicekette"
|
||||
- "Kommunikationsfähigkeit (intern und zu Kunden/Ämtern)"
|
||||
- "Grundverständnis von ITSM-Prozessen"
|
||||
|
||||
schnittstelle_support:
|
||||
von_support: "Eskalationen, Problem Records, Verbesserungsvorschläge"
|
||||
an_support: "Service-Updates, Dokumentation, SLA-Änderungen"
|
||||
|
||||
referenz: "spm_rollen.yaml → service_owner"
|
||||
|
||||
yasm_entsprechung: "Service Owner"
|
||||
itil4_entsprechung: "Service Owner"
|
||||
|
||||
# =============================================================================
|
||||
# KONTEXTABHÄNGIGE FUNKTIONEN
|
||||
# =============================================================================
|
||||
|
||||
kontextabhaengige_funktionen:
|
||||
|
||||
beschreibung: |
|
||||
Folgende Funktionen erscheinen in RACI-Matrizen und Prozessbeschreibungen,
|
||||
sind aber keine festen SSM-Rollen. Sie werden je Kontext oder
|
||||
Katalog-Eintrag zugewiesen.
|
||||
|
||||
funktionen:
|
||||
|
||||
- funktion: "Genehmiger"
|
||||
beschreibung: |
|
||||
Zuständig für die Genehmigung von Service Requests. Wird je
|
||||
Katalog-Eintrag definiert. Die Genehmiger-Zuordnung ist Teil
|
||||
des Service-Katalogs, nicht der SSM-Rollendefinition.
|
||||
typische_genehmiger:
|
||||
- "Vorgesetzter des Antragstellers"
|
||||
- "IT-Sicherheitsbeauftragter"
|
||||
- "Amtsleitung / Budgetverantwortlicher"
|
||||
- "Service Owner (für Service-spezifische Genehmigungen)"
|
||||
referenz: "sub-practice_request-management.yaml → kernkonzepte.genehmigungsprinzipien"
|
||||
governance: "SSM-G-15"
|
||||
|
||||
- funktion: "Lieferant / L3-Support"
|
||||
beschreibung: |
|
||||
Externe Hersteller oder Dienstleister für Eskalation bei
|
||||
herstellerspezifischen Problemen oder vertraglich vereinbartem
|
||||
Support.
|
||||
einbindung:
|
||||
- "Eskalation durch L2 bei Herstellerfehlern"
|
||||
- "Vertraglich vereinbarter Support (SLA)"
|
||||
- "Lizenz- oder Wartungsverträge"
|
||||
referenz: "spm_rollen.yaml → externe.lieferant"
|
||||
|
||||
hinweis_teamleitung:
|
||||
beschreibung: |
|
||||
In Prozessbeschreibungen wird teilweise der Begriff "Teamleitung"
|
||||
verwendet. Im SSM-Kontext ist dies kontextabhängig zu verstehen:
|
||||
|
||||
mapping:
|
||||
- begriff: "Teamleitung"
|
||||
kontext: "Hierarchische Eskalation im Service Desk"
|
||||
entspricht: "Support Manager"
|
||||
|
||||
- begriff: "Gruppenleitung"
|
||||
kontext: "Organisatorische Einheit Service Desk"
|
||||
entspricht: "Support Manager oder dedizierte Gruppenleitung"
|
||||
|
||||
hinweis: |
|
||||
Die konkrete Besetzung hängt von der Organisationsstruktur bei
|
||||
DIGIT ab. Im MVP kann der Support Manager auch die Gruppenleitung sein.
|
||||
|
||||
# =============================================================================
|
||||
# RACI-REFERENZ
|
||||
# =============================================================================
|
||||
|
||||
raci_referenz:
|
||||
|
||||
beschreibung: |
|
||||
Die konsolidierte RACI-Matrix für alle SSM-Aktivitäten ist in
|
||||
ssm_governance.yaml → raci_konsolidiert definiert.
|
||||
|
||||
Dieses Dokument definiert die Rollen, nicht die Zuordnungen.
|
||||
|
||||
master_dokument: "ssm_governance.yaml"
|
||||
abschnitt: "raci_konsolidiert"
|
||||
|
||||
bereiche:
|
||||
- "incident_management"
|
||||
- "request_management"
|
||||
- "problem_management"
|
||||
- "wissensmanagement"
|
||||
- "service_desk"
|
||||
- "eskalation"
|
||||
- "reporting"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- modul: "spm_rollen.yaml"
|
||||
art: "erweitert"
|
||||
beschreibung: |
|
||||
SSM-spezifische Konkretisierung der SPM-Basisrollen.
|
||||
Übergeordnete Rollen (SPM, Mission Board) sind dort definiert
|
||||
und werden in ssm_governance.yaml für die Eskalationskette
|
||||
referenziert.
|
||||
|
||||
- modul: "sub-practice_incident-management.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "RACI-Zuordnungen in Incident-Aktivitäten"
|
||||
|
||||
- modul: "sub-practice_request-management.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "RACI-Zuordnungen in Request-Aktivitäten"
|
||||
|
||||
- modul: "ssm_wissensmanagement.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "KB-Governance je Ebene"
|
||||
|
||||
- modul: "sub-practice_service-desk.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Service Desk Organisationsmodell nutzt Rollen"
|
||||
|
||||
- modul: "ssm_governance.yaml"
|
||||
art: "wird referenziert von"
|
||||
beschreibung: "Eskalationskette basiert auf Rollenmodell"
|
||||
|
||||
extern:
|
||||
- partner: "Service-Portfolio-Management (SPM)"
|
||||
kontext: "Übergeordnete Steuerung, strategische Entscheidungen"
|
||||
rollen_dort: ["spm (Service-Portfolio-Manager)"]
|
||||
referenz: "spm_rollen.yaml"
|
||||
|
||||
- partner: "Mission Board"
|
||||
kontext: "Höchste Eskalationsstufe, strategische Grundsatzentscheidungen"
|
||||
referenz: "spm_rollen.yaml → sor (Service Operations Runde)"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-ROLLEN-001"
|
||||
thema: "Queue-Koordinator-Modell für DIGIT"
|
||||
beschreibung: "Welches Modell (dediziert/rotierend/teilzeit) passt für DIGIT?"
|
||||
prioritaet: "hoch"
|
||||
status: "Mit DIGIT abstimmen"
|
||||
|
||||
- id: "OPEN-ROLLEN-002"
|
||||
thema: "L2-Spezialisierungen"
|
||||
beschreibung: "Konkrete Domain-Pools für DIGIT definieren"
|
||||
prioritaet: "mittel"
|
||||
status: "Nach Service-Katalog-Analyse"
|
||||
|
||||
- id: "OPEN-ROLLEN-003"
|
||||
thema: "Genehmiger-Zuordnung je Katalog-Eintrag"
|
||||
beschreibung: |
|
||||
Die konkreten Genehmiger für jeden Katalog-Eintrag müssen
|
||||
im Rahmen der Service-Katalog-Implementierung definiert werden.
|
||||
prioritaet: "mittel"
|
||||
status: "Abhängig von SCM (P-01)"
|
||||
abhaengig_von: "spm_practice_service-catalog-management.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.2"
|
||||
datum: "2025-12-07"
|
||||
aenderung: |
|
||||
- Queue-Koordinator: Qualifikation ergänzt
|
||||
- Support Manager: Einschränkungen und Qualifikation ergänzt
|
||||
- Service Owner: Befugnisse und Einschränkungen für Support-Kontext ergänzt
|
||||
- Neuer Abschnitt: Kontextabhängige Funktionen (Genehmiger, Lieferant, Teamleitung)
|
||||
- Schnittstellen zu übergeordneten Rollen (SPM, MB) expliziert
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-07"
|
||||
aenderung: "Initiale Erstellung mit Minimal-Rollensatz"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,990 @@
|
|||
# =============================================================================
|
||||
# SSM SCHEMA: TICKET
|
||||
# =============================================================================
|
||||
# Modul: Service-Support-Management (SSM)
|
||||
# Typ: Schema (Informationsmodell)
|
||||
# Version: 0.1
|
||||
# Datum: 2025-12-07
|
||||
# Status: draft
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
schema_id: "SSM-S-01"
|
||||
name: "Ticket-Schema"
|
||||
typ: "Schema"
|
||||
|
||||
zweck: |
|
||||
Definiert die Datenstruktur für Support-Tickets (Incidents und Requests).
|
||||
Das Schema dient als Grundlage für:
|
||||
- ITSM-Tool-Konfiguration (Pflichtfelder, Feldtypen)
|
||||
- Definition of Ready (DoR) – Qualitätskriterien bei Ticket-Erfassung
|
||||
- Reporting und KPI-Auswertung
|
||||
- Prozess-Schnittstellen (Eskalation, Übergabe)
|
||||
|
||||
gilt_fuer:
|
||||
- "sub-practice_incident-management.yaml"
|
||||
- "sub-practice_request-management.yaml"
|
||||
- "sub-practice_service-desk.yaml"
|
||||
|
||||
klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml"
|
||||
rollen_referenz: "ssm_rollen.yaml"
|
||||
|
||||
design_prinzip: |
|
||||
Das Schema unterscheidet drei Attribut-Kategorien:
|
||||
1. Basis-Attribute: Für alle Ticket-Typen identisch
|
||||
2. Typ-spezifische Attribute: Nur für Incident oder Request
|
||||
3. Prozess-Attribute: Werden im Lifecycle befüllt (nicht bei Erfassung)
|
||||
|
||||
Pflichtfelder sind so definiert, dass sie die DoR (Definition of Ready)
|
||||
erfüllen, ohne den Erfassungsprozess zu überlasten.
|
||||
|
||||
# =============================================================================
|
||||
# BASIS-ATTRIBUTE (ALLE TICKET-TYPEN)
|
||||
# =============================================================================
|
||||
|
||||
basis_attribute:
|
||||
|
||||
beschreibung: |
|
||||
Diese Attribute gelten für alle Ticket-Typen (Incident, Request, Projekt).
|
||||
Sie werden bei Ticket-Erfassung oder im frühen Lifecycle befüllt.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# IDENTIFIKATION
|
||||
# ---------------------------------------------------------------------------
|
||||
identifikation:
|
||||
|
||||
beschreibung: "Eindeutige Identifikation und Grunddaten"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "ticket_id"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Eindeutiger Identifier, vom System vergeben"
|
||||
format: "INC-YYYYMMDD-XXXXX oder REQ-YYYYMMDD-XXXXX"
|
||||
beispiel: "INC-20251207-00423"
|
||||
|
||||
- name: "ticket_typ"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Grundlegende Ticket-Klassifikation"
|
||||
werte:
|
||||
- id: "INCIDENT"
|
||||
name: "Störung"
|
||||
- id: "REQUEST"
|
||||
name: "Service-Anfrage"
|
||||
- id: "PROJEKT"
|
||||
name: "Projekt-Ticket"
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen"
|
||||
|
||||
- name: "titel"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Kurze, aussagekräftige Zusammenfassung"
|
||||
max_laenge: 120
|
||||
beispiel: "Outlook stürzt beim Öffnen von Anhängen ab"
|
||||
qualitaetskriterium: |
|
||||
Der Titel muss das Problem/die Anfrage erkennbar machen,
|
||||
ohne die Beschreibung lesen zu müssen.
|
||||
|
||||
- name: "beschreibung"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Ausführliche Beschreibung des Problems oder der Anfrage"
|
||||
min_laenge: 50
|
||||
qualitaetskriterium: |
|
||||
Die Beschreibung muss ausreichend Kontext liefern, um
|
||||
ohne Rückfrage mit der Bearbeitung beginnen zu können.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MELDER & BETROFFENER
|
||||
# ---------------------------------------------------------------------------
|
||||
personen:
|
||||
|
||||
beschreibung: "Beteiligte Personen"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "melder"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
erfassung: "automatisch/manuell"
|
||||
beschreibung: "Person, die das Ticket erstellt hat"
|
||||
schema:
|
||||
- name: "person_id"
|
||||
typ: "string"
|
||||
beschreibung: "Referenz auf Verzeichnisdienst (AD)"
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
- name: "email"
|
||||
typ: "string"
|
||||
- name: "telefon"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
- name: "amt"
|
||||
typ: "string"
|
||||
beschreibung: "Organisationseinheit des Melders"
|
||||
- name: "standort"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
|
||||
- name: "betroffener"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: |
|
||||
Person, die von der Störung betroffen ist oder die Anfrage stellt.
|
||||
Kann identisch mit Melder sein (Standardfall).
|
||||
schema:
|
||||
- name: "person_id"
|
||||
typ: "string"
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
- name: "amt"
|
||||
typ: "string"
|
||||
default: "Melder"
|
||||
|
||||
- name: "vip_flag"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: |
|
||||
Kennzeichnung für besondere Behandlung (z.B. Amtsleitung, OB-Bereich).
|
||||
Beeinflusst nicht die Priorität, aber die Kommunikation.
|
||||
default: false
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KLASSIFIKATION
|
||||
# ---------------------------------------------------------------------------
|
||||
klassifikation:
|
||||
|
||||
beschreibung: "Klassifikations-Attribute gemäß Priorisierungs-Framework"
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "impact"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Auswirkung auf den Geschäftsbetrieb"
|
||||
werte:
|
||||
- id: "HOCH"
|
||||
code: "I-H"
|
||||
kriterien: ">10 Nutzer, geschäftskritisch, Security"
|
||||
- id: "NORMAL"
|
||||
code: "I-N"
|
||||
kriterien: "Einzelnutzer/kleine Gruppe, eingeschränkt"
|
||||
- id: "NIEDRIG"
|
||||
code: "I-L"
|
||||
kriterien: "Komfort, Workaround verfügbar"
|
||||
|
||||
- name: "urgency"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Zeitliche Dringlichkeit"
|
||||
werte:
|
||||
- id: "HOCH"
|
||||
code: "U-H"
|
||||
kriterien: "Sofort, kein Workaround, Deadline"
|
||||
- id: "NORMAL"
|
||||
code: "U-N"
|
||||
kriterien: "Zeitnah, temporärer Workaround"
|
||||
- id: "NIEDRIG"
|
||||
code: "U-L"
|
||||
kriterien: "Kann warten"
|
||||
|
||||
- name: "prioritaet"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Abgeleitet aus Impact × Urgency"
|
||||
werte:
|
||||
- id: "P1"
|
||||
name: "Kritisch"
|
||||
- id: "P2"
|
||||
name: "Hoch"
|
||||
- id: "P3"
|
||||
name: "Normal"
|
||||
- id: "P4"
|
||||
name: "Niedrig"
|
||||
ableitung: "ssm_klassifikation-priorisierung.yaml → impact_urgency_matrix"
|
||||
|
||||
- name: "charakteristik"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Bearbeitungscharakter des Tickets"
|
||||
werte:
|
||||
- id: "STANDARD"
|
||||
name: "Standard-Ticket"
|
||||
beschreibung: "Bekanntes Muster, klare Lösung"
|
||||
- id: "ANALYSE"
|
||||
name: "Analyse-Ticket"
|
||||
beschreibung: "Unklare Ursache, Diagnose erforderlich"
|
||||
- id: "PROJEKT"
|
||||
name: "Projekt-Ticket"
|
||||
beschreibung: "Planbar, umfangreich, Koordination nötig"
|
||||
|
||||
- name: "pool"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zugeordneter Bearbeitungs-Pool"
|
||||
werte:
|
||||
- id: "POOL-SOFORT"
|
||||
name: "Sofort-Pool"
|
||||
- id: "POOL-STANDARD"
|
||||
name: "Standard Service-Pool"
|
||||
- id: "POOL-ANALYSE"
|
||||
name: "Analyse-Pool"
|
||||
- id: "POOL-PROJEKT"
|
||||
name: "Projekt-Pool"
|
||||
ableitung: "ssm_klassifikation-priorisierung.yaml → ableitungslogik"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE-ZUORDNUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
service_zuordnung:
|
||||
|
||||
beschreibung: "Verknüpfung mit Service-Portfolio"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "service_id"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Referenz auf betroffenen Service (aus Service-Katalog)"
|
||||
referenz: "spm_schema_service-definition.yaml"
|
||||
beispiel: "SVC-EMAIL-001"
|
||||
|
||||
- name: "service_name"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Name des Services (abgeleitet aus service_id)"
|
||||
|
||||
- name: "service_komponente"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Betroffene Komponente innerhalb des Services"
|
||||
beispiel: "Outlook Client"
|
||||
|
||||
- name: "kategorie"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Thematische Kategorie (für Reporting)"
|
||||
beispiel: "E-Mail / Netzwerk / Hardware / Software"
|
||||
|
||||
- name: "unterkategorie"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Feingranulare Kategorie"
|
||||
beispiel: "Outlook / Exchange / Spam"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# STATUS & WORKFLOW
|
||||
# ---------------------------------------------------------------------------
|
||||
status:
|
||||
|
||||
beschreibung: "Status-Informationen und Workflow-Steuerung"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "status"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Aktueller Bearbeitungsstatus"
|
||||
werte:
|
||||
- id: "NEU"
|
||||
name: "Neu"
|
||||
beschreibung: "Ticket erfasst, noch nicht angenommen"
|
||||
- id: "ANGENOMMEN"
|
||||
name: "Angenommen"
|
||||
beschreibung: "Ticket von Bearbeiter übernommen"
|
||||
- id: "WARTEN_GENEHMIGUNG"
|
||||
name: "Warten auf Genehmigung"
|
||||
beschreibung: "Genehmigungsanfrage ausgelöst (nur bei Requests)"
|
||||
request_spezifisch: true
|
||||
- id: "IN_BEARBEITUNG"
|
||||
name: "In Bearbeitung"
|
||||
beschreibung: "Aktive Bearbeitung läuft"
|
||||
- id: "WARTEN_NUTZER"
|
||||
name: "Warten auf Nutzer"
|
||||
beschreibung: "Rückfrage an Melder/Betroffenen"
|
||||
- id: "WARTEN_EXTERN"
|
||||
name: "Warten auf Externe"
|
||||
beschreibung: "Warten auf Drittanbieter/Lieferant"
|
||||
- id: "WARTEN_CHANGE"
|
||||
name: "Warten auf Change"
|
||||
beschreibung: "Lösung erfordert genehmigten Change"
|
||||
- id: "GELOEST"
|
||||
name: "Gelöst"
|
||||
beschreibung: "Lösung implementiert, Bestätigung ausstehend"
|
||||
- id: "GESCHLOSSEN"
|
||||
name: "Geschlossen"
|
||||
beschreibung: "Ticket abgeschlossen"
|
||||
- id: "STORNIERT"
|
||||
name: "Storniert"
|
||||
beschreibung: "Ticket ohne Bearbeitung beendet"
|
||||
default: "NEU"
|
||||
hinweis: |
|
||||
Der Status WARTEN_GENEHMIGUNG ist Request-spezifisch und wird
|
||||
bei Incidents nicht verwendet.
|
||||
|
||||
- name: "substatus"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Optionaler Detail-Status"
|
||||
beispiel: "Wartet auf Rückruf / Termin vereinbart"
|
||||
|
||||
- name: "langlaeufer_flag"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Kennzeichnung für Tickets >20 AT Laufzeit"
|
||||
default: false
|
||||
governance: "SSM-G-04"
|
||||
|
||||
status_transitionen:
|
||||
|
||||
beschreibung: |
|
||||
Erlaubte Status-Übergänge. Das ITSM-Tool sollte diese
|
||||
Transitionen technisch durchsetzen.
|
||||
|
||||
referenz: "sub-practice_incident-management.yaml → status_lifecycle"
|
||||
|
||||
transitionen:
|
||||
NEU: ["ANGENOMMEN", "STORNIERT"]
|
||||
ANGENOMMEN: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"]
|
||||
WARTEN_GENEHMIGUNG: ["IN_BEARBEITUNG", "STORNIERT"]
|
||||
IN_BEARBEITUNG: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"]
|
||||
WARTEN_NUTZER: ["IN_BEARBEITUNG", "STORNIERT"]
|
||||
WARTEN_EXTERN: ["IN_BEARBEITUNG"]
|
||||
WARTEN_CHANGE: ["IN_BEARBEITUNG", "GELOEST"]
|
||||
GELOEST: ["GESCHLOSSEN", "IN_BEARBEITUNG"]
|
||||
GESCHLOSSEN: ["IN_BEARBEITUNG"]
|
||||
STORNIERT: []
|
||||
|
||||
hinweis_request_spezifisch: |
|
||||
Die Transition ANGENOMMEN → WARTEN_GENEHMIGUNG und alle Transitionen
|
||||
von WARTEN_GENEHMIGUNG sind nur bei Requests relevant.
|
||||
|
||||
einbahnstrassen:
|
||||
- von: "ANGENOMMEN"
|
||||
nicht_nach: "NEU"
|
||||
grund: "Ownership-Prinzip: Nach Annahme keine Rückgabe an Queue"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ZEITEN
|
||||
# ---------------------------------------------------------------------------
|
||||
zeiten:
|
||||
|
||||
beschreibung: "Zeitstempel für SLA-Messung und Reporting"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "erstellt_am"
|
||||
typ: "datetime"
|
||||
pflicht: true
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt der Ticket-Erstellung"
|
||||
|
||||
- name: "erste_reaktion_am"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt der ersten qualifizierten Reaktion"
|
||||
sla_relevant: true
|
||||
|
||||
- name: "angenommen_am"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt der Ticket-Übernahme"
|
||||
|
||||
- name: "geloest_am"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt der Lösungsbereitstellung"
|
||||
sla_relevant: true
|
||||
|
||||
- name: "geschlossen_am"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt des Ticket-Abschlusses"
|
||||
|
||||
- name: "sla_reaktion_ziel"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Berechnetes SLA-Ziel für Reaktionszeit"
|
||||
|
||||
- name: "sla_loesung_ziel"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Berechnetes SLA-Ziel für Lösungszeit"
|
||||
|
||||
- name: "wartezeit_gesamt"
|
||||
typ: "duration"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: |
|
||||
Summe aller Wartezeiten (WARTEN_NUTZER, WARTEN_EXTERN).
|
||||
Wird von SLA-Zeit abgezogen ("Clock Stop").
|
||||
|
||||
- name: "bearbeitungszeit_netto"
|
||||
typ: "duration"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Tatsächliche Bearbeitungszeit ohne Wartezeiten"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ZUWEISUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
zuweisung:
|
||||
|
||||
beschreibung: "Bearbeiter und Team-Zuordnung"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "zugewiesen_an"
|
||||
typ: "objekt"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Aktuell zuständiger Bearbeiter"
|
||||
schema:
|
||||
- name: "person_id"
|
||||
typ: "string"
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
- name: "team"
|
||||
typ: "string"
|
||||
|
||||
- name: "support_team"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Zuständiges Support-Team"
|
||||
werte:
|
||||
- id: "L1"
|
||||
name: "First Level Support"
|
||||
- id: "L2"
|
||||
name: "Second Level Support"
|
||||
- id: "L2-SPEC"
|
||||
name: "Spezialistengruppe"
|
||||
- id: "L3"
|
||||
name: "Third Level / Extern"
|
||||
|
||||
- name: "eskaliert_an"
|
||||
typ: "objekt"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Person/Gruppe bei Eskalation"
|
||||
schema:
|
||||
- name: "person_id"
|
||||
typ: "string"
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
- name: "eskalationsgrund"
|
||||
typ: "string"
|
||||
- name: "eskaliert_am"
|
||||
typ: "datetime"
|
||||
|
||||
# =============================================================================
|
||||
# INCIDENT-SPEZIFISCHE ATTRIBUTE
|
||||
# =============================================================================
|
||||
|
||||
incident_attribute:
|
||||
|
||||
beschreibung: |
|
||||
Zusätzliche Attribute, die nur für Incidents relevant sind.
|
||||
Diese ergänzen die Basis-Attribute.
|
||||
|
||||
gilt_fuer: "ticket_typ = INCIDENT"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "symptom"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Beobachtetes Symptom (was sieht der Nutzer?)"
|
||||
beispiel: "Fehlermeldung 'Verbindung zum Server unterbrochen'"
|
||||
|
||||
- name: "fehlermeldung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Exakter Wortlaut der Fehlermeldung"
|
||||
|
||||
- name: "reproduzierbar"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Ist das Problem reproduzierbar?"
|
||||
werte:
|
||||
- id: "IMMER"
|
||||
name: "Immer reproduzierbar"
|
||||
- id: "MANCHMAL"
|
||||
name: "Sporadisch"
|
||||
- id: "EINMALIG"
|
||||
name: "Bisher einmalig"
|
||||
- id: "UNBEKANNT"
|
||||
name: "Nicht getestet"
|
||||
|
||||
- name: "workaround_vorhanden"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Existiert ein temporärer Workaround?"
|
||||
default: false
|
||||
|
||||
- name: "workaround_beschreibung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Beschreibung des Workarounds (wenn vorhanden)"
|
||||
|
||||
- name: "ursache"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Ermittelte Ursache (nach Diagnose)"
|
||||
|
||||
- name: "loesung"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Beschreibung der durchgeführten Lösung"
|
||||
bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN"
|
||||
|
||||
- name: "first_call_resolution"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Wurde das Ticket im Erstkontakt gelöst?"
|
||||
kpi_relevant: true
|
||||
|
||||
- name: "problem_referenz"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Verknüpfung zu Problem-Ticket (wenn vorhanden)"
|
||||
beispiel: "PRB-20251207-00012"
|
||||
|
||||
- name: "known_error_referenz"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Referenz auf Known Error Database (KEDB)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# FEEDBACK-FELDER
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- name: "nutzer_feedback"
|
||||
beschreibung: |
|
||||
Optionales Feedback des Nutzers zur Lösungsqualität und
|
||||
Zufriedenheit mit der Bearbeitung. Wird bei Ticket-Abschluss
|
||||
oder nach Auto-Close erhoben.
|
||||
|
||||
typ: "objekt"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
|
||||
unterfelder:
|
||||
|
||||
- name: "zufriedenheit"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
werte:
|
||||
- id: "SEHR_ZUFRIEDEN"
|
||||
name: "Sehr zufrieden"
|
||||
- id: "ZUFRIEDEN"
|
||||
name: "Zufrieden"
|
||||
- id: "NEUTRAL"
|
||||
name: "Neutral"
|
||||
- id: "UNZUFRIEDEN"
|
||||
name: "Unzufrieden"
|
||||
- id: "SEHR_UNZUFRIEDEN"
|
||||
name: "Sehr unzufrieden"
|
||||
|
||||
- name: "kommentar"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
max_laenge: 1000
|
||||
beschreibung: "Freitext-Feedback des Nutzers"
|
||||
|
||||
- name: "feedback_datum"
|
||||
typ: "datetime"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Zeitpunkt der Feedback-Abgabe"
|
||||
|
||||
erhebung:
|
||||
zeitpunkt: "Nach Ticket-Abschluss oder Auto-Close"
|
||||
methode: "E-Mail mit Feedback-Link oder Portal-Popup"
|
||||
erinnerung: "Optional nach 3 Tagen"
|
||||
|
||||
auswertung:
|
||||
kpi: "Nutzerzufriedenheit (CSAT)"
|
||||
aggregation: "Monatlich pro Service-Bereich"
|
||||
reporting: "ssm_governance.yaml → reporting"
|
||||
|
||||
mvp_status: "OPTIONAL"
|
||||
hinweis: |
|
||||
Im MVP ist die Feedback-Erhebung optional und abhängig von
|
||||
der Tool-Unterstützung. Die Struktur ist definiert, die
|
||||
Implementierung kann nachgelagert erfolgen.
|
||||
|
||||
# =============================================================================
|
||||
# REQUEST-SPEZIFISCHE ATTRIBUTE
|
||||
# =============================================================================
|
||||
|
||||
request_attribute:
|
||||
|
||||
beschreibung: |
|
||||
Zusätzliche Attribute, die nur für Service Requests relevant sind.
|
||||
Diese ergänzen die Basis-Attribute.
|
||||
|
||||
gilt_fuer: "ticket_typ = REQUEST"
|
||||
|
||||
attribute:
|
||||
|
||||
- name: "request_typ"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Art der Anfrage"
|
||||
werte:
|
||||
- id: "BERECHTIGUNG"
|
||||
name: "Berechtigungsanfrage"
|
||||
- id: "SOFTWARE"
|
||||
name: "Software-Installation"
|
||||
- id: "HARDWARE"
|
||||
name: "Hardware-Anfrage"
|
||||
- id: "ACCOUNT"
|
||||
name: "Account-Management"
|
||||
- id: "INFORMATION"
|
||||
name: "Informationsanfrage"
|
||||
- id: "AENDERUNG"
|
||||
name: "Änderungsanfrage"
|
||||
- id: "SONSTIGE"
|
||||
name: "Sonstige Anfrage"
|
||||
|
||||
- name: "request_katalog_id"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Referenz auf Standard-Request im Request-Katalog"
|
||||
beispiel: "REQ-CAT-SW-001"
|
||||
|
||||
- name: "genehmigung_erforderlich"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Ist eine Genehmigung erforderlich?"
|
||||
ableitung: "Basierend auf request_typ und Katalog-Definition"
|
||||
|
||||
- name: "genehmiger"
|
||||
typ: "objekt"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Person, die die Genehmigung erteilt"
|
||||
schema:
|
||||
- name: "person_id"
|
||||
typ: "string"
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
- name: "genehmigt_am"
|
||||
typ: "datetime"
|
||||
- name: "kommentar"
|
||||
typ: "string"
|
||||
bedingung: "Pflicht wenn genehmigung_erforderlich = true"
|
||||
|
||||
- name: "genehmigung_status"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Status des Genehmigungsprozesses"
|
||||
werte:
|
||||
- id: "OFFEN"
|
||||
name: "Genehmigung ausstehend"
|
||||
- id: "GENEHMIGT"
|
||||
name: "Genehmigt"
|
||||
- id: "ABGELEHNT"
|
||||
name: "Abgelehnt"
|
||||
- id: "NICHT_ERFORDERLICH"
|
||||
name: "Keine Genehmigung erforderlich"
|
||||
|
||||
- name: "wunschtermin"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Vom Nutzer gewünschter Erledigungstermin"
|
||||
|
||||
- name: "kosten_relevant"
|
||||
typ: "boolean"
|
||||
pflicht: false
|
||||
erfassung: "automatisch"
|
||||
beschreibung: "Entstehen Kosten für das Amt?"
|
||||
ableitung: "Basierend auf Service-Kategorie und Request-Typ"
|
||||
|
||||
- name: "erfuellung"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
erfassung: "manuell"
|
||||
beschreibung: "Beschreibung der durchgeführten Erfüllung"
|
||||
bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN"
|
||||
|
||||
# =============================================================================
|
||||
# STATUS-MODELL
|
||||
# =============================================================================
|
||||
|
||||
status_modell:
|
||||
|
||||
beschreibung: |
|
||||
Definition der erlaubten Status-Übergänge. Nur die hier definierten
|
||||
Transitionen sind im System erlaubt.
|
||||
|
||||
transitionen:
|
||||
|
||||
- von: "NEU"
|
||||
nach: ["ANGENOMMEN", "STORNIERT"]
|
||||
bedingung: null
|
||||
|
||||
- von: "ANGENOMMEN"
|
||||
nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"]
|
||||
bedingung: "zugewiesen_an muss gesetzt sein"
|
||||
hinweis: "WARTEN_GENEHMIGUNG nur bei Requests"
|
||||
|
||||
- von: "WARTEN_GENEHMIGUNG"
|
||||
nach: ["IN_BEARBEITUNG", "STORNIERT"]
|
||||
bedingung: "Genehmigung erteilt → IN_BEARBEITUNG, abgelehnt → STORNIERT"
|
||||
ticket_typ: "Nur für REQUEST"
|
||||
|
||||
- von: "IN_BEARBEITUNG"
|
||||
nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST", "STORNIERT"]
|
||||
bedingung: null
|
||||
|
||||
- von: "WARTEN_NUTZER"
|
||||
nach: ["IN_BEARBEITUNG", "GELOEST", "STORNIERT"]
|
||||
bedingung: null
|
||||
timeout: "5 Arbeitstage"
|
||||
timeout_aktion: "Automatische Erinnerung, nach weiteren 5 AT → STORNIERT"
|
||||
|
||||
- von: "WARTEN_EXTERN"
|
||||
nach: ["IN_BEARBEITUNG", "GELOEST"]
|
||||
bedingung: null
|
||||
|
||||
- von: "WARTEN_CHANGE"
|
||||
nach: ["IN_BEARBEITUNG", "GELOEST"]
|
||||
bedingung: "Change-Ticket muss verknüpft sein"
|
||||
|
||||
- von: "GELOEST"
|
||||
nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"]
|
||||
bedingung: null
|
||||
timeout: "3 Arbeitstage"
|
||||
timeout_aktion: "Automatisch → GESCHLOSSEN"
|
||||
|
||||
- von: "GESCHLOSSEN"
|
||||
nach: ["IN_BEARBEITUNG"]
|
||||
bedingung: "Wiedereröffnung durch Queue-Koordinator, Begründung erforderlich"
|
||||
|
||||
- von: "STORNIERT"
|
||||
nach: []
|
||||
bedingung: "Endstatus, keine Wiedereröffnung"
|
||||
|
||||
# =============================================================================
|
||||
# DEFINITION OF READY (DoR)
|
||||
# =============================================================================
|
||||
|
||||
definition_of_ready:
|
||||
|
||||
beschreibung: |
|
||||
Mindestanforderungen, die ein Ticket erfüllen muss, bevor es zur
|
||||
Bearbeitung angenommen werden kann. Tickets, die die DoR nicht
|
||||
erfüllen, können zurückgewiesen werden.
|
||||
|
||||
governance: "SSM-G-04 (DoR-Verbindlichkeit)"
|
||||
|
||||
pflichtfelder_alle:
|
||||
- "titel"
|
||||
- "beschreibung"
|
||||
- "melder"
|
||||
- "betroffener"
|
||||
- "ticket_typ"
|
||||
- "impact"
|
||||
- "urgency"
|
||||
- "charakteristik"
|
||||
|
||||
pflichtfelder_incident:
|
||||
- "symptom ODER fehlermeldung"
|
||||
|
||||
pflichtfelder_request:
|
||||
- "request_typ"
|
||||
|
||||
qualitaetskriterien:
|
||||
|
||||
- id: "DoR-Q-01"
|
||||
name: "Verständlicher Titel"
|
||||
beschreibung: "Titel beschreibt Problem/Anfrage erkennbar (ohne Beschreibung lesen zu müssen)"
|
||||
pruefung: "manuell"
|
||||
|
||||
- id: "DoR-Q-02"
|
||||
name: "Ausreichende Beschreibung"
|
||||
beschreibung: "Beschreibung enthält genug Kontext für Bearbeitung ohne Rückfrage"
|
||||
pruefung: "manuell"
|
||||
mindestlaenge: "50 Zeichen"
|
||||
|
||||
- id: "DoR-Q-03"
|
||||
name: "Erreichbarkeit"
|
||||
beschreibung: "Melder ist erreichbar (Telefon oder E-Mail dokumentiert)"
|
||||
pruefung: "automatisch"
|
||||
|
||||
- id: "DoR-Q-04"
|
||||
name: "Service-Zuordnung (wenn möglich)"
|
||||
beschreibung: "Betroffener Service ist identifiziert"
|
||||
pruefung: "manuell"
|
||||
verbindlichkeit: "empfohlen"
|
||||
|
||||
rueckweisung:
|
||||
beschreibung: |
|
||||
Tickets, die die DoR nicht erfüllen, werden an den Melder
|
||||
zurückgewiesen mit der Aufforderung zur Nachbesserung.
|
||||
verantwortlich: "First Level Agent"
|
||||
dokumentation: "Rückweisungsgrund im Ticket vermerken"
|
||||
status_bei_rueckweisung: "WARTEN_NUTZER"
|
||||
|
||||
# =============================================================================
|
||||
# VALIDIERUNGSREGELN
|
||||
# =============================================================================
|
||||
|
||||
validierung:
|
||||
|
||||
regeln:
|
||||
|
||||
- id: "VAL-T-001"
|
||||
name: "Priorität-Pool-Konsistenz"
|
||||
beschreibung: "Pool muss zur Priorität × Charakteristik passen"
|
||||
regel: "Pool wird automatisch aus Ableitungslogik gesetzt"
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml"
|
||||
|
||||
- id: "VAL-T-002"
|
||||
name: "Lösungspflicht bei Abschluss"
|
||||
beschreibung: "Vor Schließen muss Lösung/Erfüllung dokumentiert sein"
|
||||
regel: |
|
||||
Status = GESCHLOSSEN erfordert:
|
||||
- Bei INCIDENT: loesung ist gesetzt
|
||||
- Bei REQUEST: erfuellung ist gesetzt
|
||||
|
||||
- id: "VAL-T-003"
|
||||
name: "Genehmigung bei Genehmigungspflicht"
|
||||
beschreibung: "Genehmigungspflichtige Requests brauchen Freigabe"
|
||||
regel: |
|
||||
Wenn genehmigung_erforderlich = true, dann
|
||||
genehmigung_status muss GENEHMIGT sein vor Status = IN_BEARBEITUNG
|
||||
|
||||
- id: "VAL-T-004"
|
||||
name: "SLA-Ziele bei Priorität"
|
||||
beschreibung: "SLA-Zielzeiten werden aus Priorität abgeleitet"
|
||||
regel: "Automatische Berechnung bei Ticket-Erstellung"
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml → prioritaetsstufen"
|
||||
|
||||
- id: "VAL-T-005"
|
||||
name: "Langläufer-Kennzeichnung"
|
||||
beschreibung: "Tickets >20 AT werden automatisch gekennzeichnet"
|
||||
regel: |
|
||||
Wenn (geschlossen_am - erstellt_am) > 20 Arbeitstage
|
||||
ODER aktuelles Datum - erstellt_am > 20 Arbeitstage,
|
||||
dann langlaeufer_flag = true
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- modul: "ssm_klassifikation-priorisierung.yaml"
|
||||
art: "referenziert"
|
||||
beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele"
|
||||
|
||||
- modul: "sub-practice_incident-management.yaml"
|
||||
art: "wird verwendet von"
|
||||
beschreibung: "Incident-Prozess arbeitet auf diesem Schema"
|
||||
|
||||
- modul: "sub-practice_request-management.yaml"
|
||||
art: "wird verwendet von"
|
||||
beschreibung: "Request-Prozess arbeitet auf diesem Schema"
|
||||
|
||||
- modul: "spm_schema_service-definition.yaml"
|
||||
art: "referenziert"
|
||||
beschreibung: "Service-Zuordnung über service_id"
|
||||
|
||||
- modul: "ssm_rollen.yaml"
|
||||
art: "referenziert"
|
||||
beschreibung: "Bearbeiter-Zuordnung"
|
||||
|
||||
extern:
|
||||
- partner: "ITSM-Tool"
|
||||
kontext: "Schema definiert Feldstruktur für Tool-Konfiguration"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
- partner: "Active Directory"
|
||||
kontext: "Personen-Lookup für Melder/Betroffener/Bearbeiter"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-SCHEMA-T-001"
|
||||
beschreibung: "Request-Katalog-Struktur definieren (referenziert von request_katalog_id)"
|
||||
prioritaet: "hoch"
|
||||
|
||||
- id: "OPEN-SCHEMA-T-002"
|
||||
beschreibung: "Kategorie/Unterkategorie-Taxonomie abstimmen"
|
||||
prioritaet: "mittel"
|
||||
|
||||
- id: "OPEN-SCHEMA-T-003"
|
||||
beschreibung: "CMDB-Integration: CI-Verknüpfung als Attribut ergänzen?"
|
||||
prioritaet: "niedrig"
|
||||
|
||||
- id: "OPEN-SCHEMA-T-004"
|
||||
beschreibung: "Attachment-Handling: Wie werden Screenshots, Logs etc. abgebildet?"
|
||||
prioritaet: "mittel"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.2"
|
||||
datum: "2025-12-07"
|
||||
aenderung: |
|
||||
- Feld 'nutzer_feedback' ergänzt (Zufriedenheit, Kommentar)
|
||||
- MVP-Status: Optional, Tool-abhängig
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Review-Finding K-03"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-07"
|
||||
aenderung: "Initiale Erstellung"
|
||||
autor: "DIGITOM-Projekt"
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,843 @@
|
|||
# =============================================================================
|
||||
# SUB-PRACTICE: PROBLEM MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "P-06"
|
||||
name: "Problem Management"
|
||||
version: "0.1"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-07"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
parent_practice: "practice_service-support-management"
|
||||
|
||||
itil4_referenz: "Problem Management Practice"
|
||||
yasm_referenz: "LP4.7.2, LP4.7.3, LP4.7.4, LP4.7.5"
|
||||
|
||||
hinweis_yasm: |
|
||||
LP4.7.1 (Proaktives Identifizieren) ist im MVP nicht im Scope.
|
||||
Nur reaktive Problem-Identifikation aus Incidents.
|
||||
|
||||
blueprint_referenz: "service-lifecycle_service-support.yaml"
|
||||
relevante_aktivitaeten: ["ss_09", "ss_10", "ss_11"]
|
||||
|
||||
design_referenz: "ssm_design-zieldimensionen.yaml"
|
||||
relevante_saeulen: ["LS-05", "LS-06"]
|
||||
|
||||
schema_referenz: "ssm_schema_ticket.yaml"
|
||||
rollen_referenz: "ssm_rollen.yaml"
|
||||
wissensmanagement_referenz: "ssm_wissensmanagement.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# ZWECK & SCOPE
|
||||
# =============================================================================
|
||||
|
||||
zweck:
|
||||
|
||||
definition: |
|
||||
Problem Management reduziert die Wahrscheinlichkeit und Auswirkungen
|
||||
von Incidents durch Identifikation der zugrundeliegenden Ursachen,
|
||||
Entwicklung von Workarounds und Initiierung nachhaltiger Lösungen.
|
||||
|
||||
ziele:
|
||||
- "Identifikation der Ursachen wiederkehrender oder schwerwiegender Incidents"
|
||||
- "Bereitstellung von Workarounds zur Reduktion von Incident-Auswirkungen"
|
||||
- "Dokumentation von Known Errors für schnellere Incident-Bearbeitung"
|
||||
- "Initiierung permanenter Lösungen über Change Management"
|
||||
- "Reduktion der Gesamtzahl von Incidents durch Ursachenbeseitigung"
|
||||
|
||||
mvp_scope:
|
||||
beschreibung: |
|
||||
Im MVP ist Problem Management auf reaktive Identifikation aus
|
||||
Incidents beschränkt. Proaktive Problem-Identifikation (Trend-Analyse,
|
||||
Monitoring-basiert) ist nicht im Scope.
|
||||
|
||||
im_scope:
|
||||
- "Reaktive Problem-Identifikation aus Incidents"
|
||||
- "Basis-Root-Cause-Analyse"
|
||||
- "Workaround-Dokumentation als Known Error"
|
||||
- "Change-Initiierung für permanente Lösungen"
|
||||
|
||||
nicht_im_scope:
|
||||
- "Proaktive Problem-Identifikation (LP4.7.1)"
|
||||
- "Systematische Trend-Analyse"
|
||||
- "Formale RCA-Methoden (5-Why, Ishikawa) – können genutzt werden, sind aber nicht vorgeschrieben"
|
||||
- "Separate Known Error Database (KEDB)"
|
||||
|
||||
governance: "SSM-G-19"
|
||||
|
||||
abgrenzung:
|
||||
|
||||
problem_vs_incident: |
|
||||
Ein Incident ist eine ungeplante Unterbrechung, die schnellstmöglich
|
||||
behoben werden muss (Symptombehandlung). Ein Problem ist die
|
||||
zugrundeliegende Ursache eines oder mehrerer Incidents.
|
||||
|
||||
Incident Management: "Wie stelle ich den Service wieder her?"
|
||||
Problem Management: "Warum ist der Service ausgefallen?"
|
||||
|
||||
problem_vs_change: |
|
||||
Problem Management identifiziert Ursachen und entwickelt Lösungsvorschläge.
|
||||
Die Implementierung permanenter Lösungen erfolgt über Change Enablement.
|
||||
Problem Management initiiert Changes, implementiert sie aber nicht selbst.
|
||||
|
||||
problem_vs_known_error: |
|
||||
Ein Problem ist eine identifizierte oder vermutete Ursache.
|
||||
Ein Known Error ist ein Problem, dessen Ursache analysiert wurde
|
||||
und für das ein dokumentierter Workaround existiert.
|
||||
|
||||
# =============================================================================
|
||||
# KERNKONZEPTE
|
||||
# =============================================================================
|
||||
|
||||
kernkonzepte:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ROLLENMODELL
|
||||
# ---------------------------------------------------------------------------
|
||||
rollenmodell:
|
||||
|
||||
beschreibung: |
|
||||
Im MVP gibt es keine dedizierte Problem-Manager-Rolle. Die Verantwortung
|
||||
ist auf bestehende Rollen verteilt, mit dem Service Owner als
|
||||
Process Owner für Problem Management in seinem Service-Bereich.
|
||||
|
||||
governance: "SSM-G-18"
|
||||
|
||||
begruendung: |
|
||||
ITIL4 warnt explizit davor, Problem Management als separate Funktion
|
||||
aufzubauen: "If it is set up as a separate team or group, there is
|
||||
a danger it will just become a dumping ground for everything the
|
||||
other support staff find too difficult."
|
||||
|
||||
Im MVP-Kontext von DIGIT ist der Service Owner ohnehin Teil des
|
||||
operativen Teams und kann die Koordination übernehmen.
|
||||
|
||||
verantwortlichkeiten:
|
||||
|
||||
service_owner:
|
||||
rolle: "Process Owner Problem Management (für seinen Service)"
|
||||
aufgaben:
|
||||
- "Wiederkehrende Muster im Blick behalten"
|
||||
- "Root-Cause-Analyse koordinieren und ggf. durchführen"
|
||||
- "Sicherstellen, dass Workarounds dokumentiert werden"
|
||||
- "Entscheidung über permanente Lösungen (Change)"
|
||||
- "Problem-Priorisierung und -Überwachung"
|
||||
- "Problem-Abschluss"
|
||||
kann_delegieren_an: "Second Level Agents (Experten)"
|
||||
|
||||
second_level_agent:
|
||||
rolle: "Operative Durchführung"
|
||||
aufgaben:
|
||||
- "Problem Record erstellen (bei Erkennung in Incident-Bearbeitung)"
|
||||
- "Root-Cause-Analyse durchführen (bei Delegation durch SO)"
|
||||
- "Workaround entwickeln und dokumentieren"
|
||||
- "Known-Error-Artikel erstellen"
|
||||
|
||||
queue_koordinator:
|
||||
rolle: "Muster-Erkennung"
|
||||
aufgaben:
|
||||
- "Wiederkehrende Incidents in Queues erkennen"
|
||||
- "Service Owner auf Muster hinweisen"
|
||||
- "Problem-Record-Erstellung anstoßen (via INC-12)"
|
||||
|
||||
support_manager:
|
||||
rolle: "Übergreifende Koordination"
|
||||
aufgaben:
|
||||
- "Koordination bei Service-übergreifenden Problemen"
|
||||
- "Eskalation bei Ressourcen-Konflikten"
|
||||
- "Reporting über Problem-Status"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PROBLEM-IDENTIFIKATION (REAKTIV)
|
||||
# ---------------------------------------------------------------------------
|
||||
problem_identifikation:
|
||||
|
||||
beschreibung: |
|
||||
Im MVP werden Probleme ausschließlich reaktiv aus dem Incident
|
||||
Management identifiziert. Es gibt zwei definierte Trigger.
|
||||
|
||||
trigger:
|
||||
|
||||
- id: "TRIGGER-01"
|
||||
name: "Nicht lösbarer Incident"
|
||||
quelle: "INC-11"
|
||||
beschreibung: |
|
||||
Ein Incident kann im L2 nicht gelöst werden, obwohl Diagnose
|
||||
durchgeführt wurde. Es wird eine strukturelle Ursache vermutet.
|
||||
kriterien:
|
||||
- "L2-Diagnose abgeschlossen ohne Lösung"
|
||||
- "Workaround implementiert, aber Ursache unbekannt"
|
||||
- "Strukturelle Ursache vermutet"
|
||||
|
||||
- id: "TRIGGER-02"
|
||||
name: "Wiederkehrende Incidents"
|
||||
quelle: "INC-12"
|
||||
beschreibung: |
|
||||
Mehrere ähnliche Incidents deuten auf ein zugrundeliegendes
|
||||
Problem hin.
|
||||
kriterien:
|
||||
- "≥3 ähnliche Incidents innerhalb von 5 Arbeitstagen"
|
||||
- "Gemeinsame Symptome oder betroffene Komponente"
|
||||
- "Queue-Koordinator oder L2 erkennt Muster"
|
||||
|
||||
nicht_im_mvp_scope:
|
||||
- "Proaktive Identifikation aus Monitoring-Daten"
|
||||
- "Trend-Analyse über Incident-Statistiken"
|
||||
- "Supplier- oder Partner-Informationen"
|
||||
- "Erkenntnisse aus Testing oder Entwicklung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PRIORISIERUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
priorisierung:
|
||||
|
||||
beschreibung: |
|
||||
Problems werden nicht über eine eigene Prioritäts-Matrix bewertet,
|
||||
sondern über eine einfache Ableitung aus Service-Kontext und
|
||||
Incident-Auswirkung.
|
||||
|
||||
modellentscheidung: |
|
||||
Diese Priorisierungslogik ist ein konzeptioneller Vorschlag für
|
||||
den MVP. Bei steigender Problem-Anzahl kann eine differenziertere
|
||||
Matrix erforderlich werden.
|
||||
|
||||
dringlichkeitsstufen:
|
||||
|
||||
- stufe: "HOCH"
|
||||
kriterien:
|
||||
- "Service-Kategorie C"
|
||||
- "ODER >5 verknüpfte Incidents"
|
||||
- "ODER kein Workaround verfügbar"
|
||||
erwartung: "Sofortige Bearbeitung, RCA innerhalb 5 AT"
|
||||
|
||||
- stufe: "MITTEL"
|
||||
kriterien:
|
||||
- "Service-Kategorie B"
|
||||
- "UND 3-5 verknüpfte Incidents"
|
||||
- "UND Workaround vorhanden"
|
||||
erwartung: "Bearbeitung innerhalb 10 AT"
|
||||
|
||||
- stufe: "NIEDRIG"
|
||||
kriterien:
|
||||
- "Service-Kategorie A"
|
||||
- "ODER <3 verknüpfte Incidents"
|
||||
- "UND Workaround vorhanden"
|
||||
erwartung: "Bearbeitung nach Kapazität"
|
||||
|
||||
hinweis: |
|
||||
Die Dringlichkeit kann vom Service Owner bei Bedarf angepasst
|
||||
werden (z.B. bei politischer Relevanz oder Außenwirkung).
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KNOWN ERROR KONZEPT
|
||||
# ---------------------------------------------------------------------------
|
||||
known_error:
|
||||
|
||||
beschreibung: |
|
||||
Ein Known Error ist ein Problem, dessen Ursache analysiert wurde
|
||||
(auch wenn nicht vollständig verstanden) und für das ein
|
||||
dokumentierter Workaround existiert.
|
||||
|
||||
governance: "SSM-G-20"
|
||||
|
||||
dokumentation:
|
||||
beschreibung: |
|
||||
Known Errors werden nicht in einer separaten KEDB geführt,
|
||||
sondern als KB-Artikel mit speziellem Typ in der bestehenden
|
||||
Wissensdatenbank dokumentiert.
|
||||
|
||||
kb_integration:
|
||||
artikel_typ: "KNOWN_ERROR"
|
||||
kb_ebene: "Ebene 2 (Arbeitsdokumentation)"
|
||||
referenz: "ssm_wissensmanagement.yaml"
|
||||
|
||||
pflichtfelder:
|
||||
- feld: "symptome"
|
||||
beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?"
|
||||
- feld: "workaround"
|
||||
beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?"
|
||||
- feld: "root_cause"
|
||||
beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)"
|
||||
- feld: "problem_referenz"
|
||||
beschreibung: "Verknüpfung zum Problem Record"
|
||||
- feld: "status"
|
||||
beschreibung: "AKTIV oder OBSOLET"
|
||||
werte: ["AKTIV", "OBSOLET"]
|
||||
|
||||
optionale_felder:
|
||||
- feld: "permanente_loesung"
|
||||
beschreibung: "Geplante Lösung, wenn bekannt"
|
||||
- feld: "change_referenz"
|
||||
beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit"
|
||||
- feld: "betroffene_services"
|
||||
beschreibung: "Liste der betroffenen Services"
|
||||
|
||||
lebenszyklus:
|
||||
- "Problem wird als KNOWN_ERROR markiert, wenn Workaround dokumentiert"
|
||||
- "Known-Error-Artikel wird erstellt/aktualisiert"
|
||||
- "Bei Incident-Bearbeitung: KB-Suche findet Known Error"
|
||||
- "Agent wendet Workaround an"
|
||||
- "Nach permanenter Lösung: Artikel-Status auf OBSOLET"
|
||||
|
||||
# =============================================================================
|
||||
# PROZESS-AKTIVITÄTEN
|
||||
# =============================================================================
|
||||
|
||||
aktivitaeten_uebersicht: |
|
||||
Problem Management im MVP besteht aus 4 Kernaktivitäten.
|
||||
Der Prozess ist schlank gehalten und fokussiert auf die
|
||||
wesentlichen Schritte von Erfassung bis Schließung.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PRB-01: PROBLEM ERFASSEN
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: "PRB-01"
|
||||
name: "Problem erfassen"
|
||||
phase: "Identifikation"
|
||||
blueprint_referenz: "ss_09, ss_10"
|
||||
yasm_referenz: "LP4.7.2"
|
||||
|
||||
beschreibung: |
|
||||
Erstellung eines Problem Records basierend auf einem der
|
||||
definierten Trigger. Dokumentation der Symptome und
|
||||
Verknüpfung mit auslösenden Incidents.
|
||||
|
||||
trigger:
|
||||
- "INC-11: Nicht lösbarer Incident"
|
||||
- "INC-12: Wiederkehrende Incidents identifiziert"
|
||||
|
||||
aktivitaeten:
|
||||
- "Problem Record im ITSM-Tool erstellen"
|
||||
- "Symptome und Auswirkungen dokumentieren"
|
||||
- "Auslösende Incidents verknüpfen"
|
||||
- "Betroffenen Service identifizieren"
|
||||
- "Service-Kategorie übernehmen"
|
||||
- "Erste Hypothese zur Ursache (wenn vorhanden)"
|
||||
- "Dringlichkeit ableiten"
|
||||
- "Service Owner informieren"
|
||||
|
||||
problem_record_felder:
|
||||
pflicht:
|
||||
- "problem_id (automatisch)"
|
||||
- "titel"
|
||||
- "symptom_beschreibung"
|
||||
- "betroffener_service"
|
||||
- "service_kategorie"
|
||||
- "verknuepfte_incidents (mindestens 1)"
|
||||
- "erstellt_von"
|
||||
- "erstellt_am"
|
||||
- "status (NEU)"
|
||||
- "dringlichkeit"
|
||||
optional:
|
||||
- "erste_hypothese"
|
||||
- "bekannter_workaround"
|
||||
- "betroffene_komponente"
|
||||
|
||||
output:
|
||||
- "Problem Record mit Status NEU"
|
||||
- "Verknüpfung zu auslösenden Incidents"
|
||||
- "Service Owner informiert"
|
||||
|
||||
raci:
|
||||
r: "Second Level Agent"
|
||||
a: "Service Owner"
|
||||
c: "Queue-Koordinator"
|
||||
i: "-"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PRB-02: PROBLEM ANALYSIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: "PRB-02"
|
||||
name: "Problem analysieren (Root-Cause-Analyse)"
|
||||
phase: "Analyse"
|
||||
blueprint_referenz: "ss_11"
|
||||
yasm_referenz: "LP4.7.3"
|
||||
|
||||
beschreibung: |
|
||||
Durchführung einer Root-Cause-Analyse zur Identifikation der
|
||||
zugrundeliegenden Ursache. Entwicklung eines Workarounds,
|
||||
wenn keine sofortige Lösung möglich ist.
|
||||
|
||||
vorbedingung: "Problem Record mit Status NEU"
|
||||
|
||||
aktivitaeten:
|
||||
- "Status auf IN_ANALYSE setzen"
|
||||
- "Verfügbare Informationen sammeln und sichten"
|
||||
- "Verknüpfte Incidents analysieren (Gemeinsamkeiten)"
|
||||
- "Hypothesen zur Ursache entwickeln"
|
||||
- "Hypothesen systematisch prüfen"
|
||||
- "Root Cause identifizieren oder eingrenzen"
|
||||
- "Workaround entwickeln (wenn Ursache nicht sofort behebbar)"
|
||||
- "Ergebnisse dokumentieren"
|
||||
|
||||
rca_methoden:
|
||||
beschreibung: |
|
||||
Im MVP sind keine formalen RCA-Methoden vorgeschrieben.
|
||||
Folgende Ansätze können bei Bedarf genutzt werden:
|
||||
optionale_methoden:
|
||||
- "5-Why-Analyse"
|
||||
- "Ishikawa-Diagramm (Fishbone)"
|
||||
- "Timeline-Analyse"
|
||||
- "Vergleichsanalyse (funktionierend vs. nicht funktionierend)"
|
||||
hinweis: "Pragmatisches Vorgehen ist im MVP ausreichend."
|
||||
|
||||
ergebnis_varianten:
|
||||
|
||||
root_cause_gefunden:
|
||||
beschreibung: "Ursache wurde identifiziert"
|
||||
naechster_schritt:
|
||||
workaround_reicht: "→ Status KNOWN_ERROR, KB-Artikel erstellen"
|
||||
permanente_loesung_noetig: "→ PRB-03 (Lösung initiieren)"
|
||||
|
||||
root_cause_nicht_gefunden:
|
||||
beschreibung: "Ursache konnte nicht eindeutig identifiziert werden"
|
||||
naechster_schritt:
|
||||
workaround_vorhanden: "→ Status KNOWN_ERROR, weiter beobachten"
|
||||
kein_workaround: "→ Problem bleibt IN_ANALYSE, Eskalation prüfen"
|
||||
|
||||
workaround_dokumentation:
|
||||
beschreibung: |
|
||||
Wenn ein Workaround entwickelt wurde, muss dieser als
|
||||
Known-Error-Artikel dokumentiert werden.
|
||||
verantwortlich: "Second Level Agent"
|
||||
freigabe: "Service Owner"
|
||||
referenz: "kernkonzepte.known_error"
|
||||
|
||||
output:
|
||||
- "Dokumentierte Analyseergebnisse"
|
||||
- "Root Cause (wenn identifiziert)"
|
||||
- "Workaround (wenn entwickelt)"
|
||||
- "Known-Error-Artikel (wenn Workaround dokumentiert)"
|
||||
- "Empfehlung für weiteres Vorgehen"
|
||||
|
||||
raci:
|
||||
r: "Second Level Agent / Service Owner"
|
||||
a: "Service Owner"
|
||||
c: "Lieferant (bei externen Komponenten)"
|
||||
i: "Support Manager"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PRB-03: LÖSUNG INITIIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: "PRB-03"
|
||||
name: "Lösung initiieren"
|
||||
phase: "Lösung"
|
||||
blueprint_referenz: "ss_11"
|
||||
yasm_referenz: "LP4.7.3, LP4.7.4"
|
||||
|
||||
beschreibung: |
|
||||
Initiierung einer permanenten Lösung, wenn ein Workaround
|
||||
nicht ausreicht oder die Ursache nachhaltig beseitigt werden soll.
|
||||
Die Implementierung erfolgt über Change Enablement.
|
||||
|
||||
vorbedingung: |
|
||||
- Root Cause identifiziert oder eingegrenzt
|
||||
- Entscheidung: Permanente Lösung erforderlich/wirtschaftlich sinnvoll
|
||||
|
||||
entscheidungskriterien:
|
||||
beschreibung: |
|
||||
Der Service Owner entscheidet, ob eine permanente Lösung
|
||||
angestrebt wird. Kriterien:
|
||||
kriterien:
|
||||
- "Workaround ist aufwändig oder fehleranfällig"
|
||||
- "Incident-Häufigkeit rechtfertigt Investition"
|
||||
- "Risiko bei Fortbestehen des Problems"
|
||||
- "Kosten-Nutzen-Verhältnis einer permanenten Lösung"
|
||||
hinweis: |
|
||||
Nicht jedes Problem muss permanent gelöst werden. Ein stabiler
|
||||
Workaround kann eine akzeptable Dauerlösung sein.
|
||||
|
||||
aktivitaeten:
|
||||
- "Lösungsoptionen bewerten"
|
||||
- "Kosten-Nutzen-Abschätzung (informell)"
|
||||
- "Entscheidung: Change oder alternative Maßnahme"
|
||||
- "Bei Change: Change Request erstellen"
|
||||
- "Problem Record mit Change verknüpfen"
|
||||
- "Status auf WARTEN_CHANGE setzen"
|
||||
- "Problem-Überwachung während Change-Implementierung"
|
||||
|
||||
change_initiierung:
|
||||
beschreibung: |
|
||||
Die meisten permanenten Lösungen erfordern einen Change.
|
||||
Problem Management erstellt den Change Request, die
|
||||
Implementierung erfolgt über Change Enablement.
|
||||
change_request_inhalt:
|
||||
- "Verweis auf Problem Record"
|
||||
- "Beschreibung der Ursache"
|
||||
- "Vorgeschlagene Lösung"
|
||||
- "Erwarteter Nutzen (reduzierte Incidents)"
|
||||
schnittstelle: "practice_change-enablement.yaml (Platzhalter)"
|
||||
|
||||
alternative_massnahmen:
|
||||
beschreibung: |
|
||||
Nicht alle Lösungen erfordern einen formalen Change.
|
||||
beispiele:
|
||||
- "Konfigurationsanpassung im Standard-Scope"
|
||||
- "Schulung/Kommunikation an Nutzer"
|
||||
- "Prozessanpassung"
|
||||
- "Lieferanten-Eskalation"
|
||||
|
||||
output:
|
||||
- "Entscheidung dokumentiert"
|
||||
- "Change Request (wenn erforderlich)"
|
||||
- "Problem Record Status WARTEN_CHANGE oder KNOWN_ERROR"
|
||||
|
||||
raci:
|
||||
r: "Service Owner"
|
||||
a: "Service Owner"
|
||||
c: "Support Manager"
|
||||
i: "Second Level Agent"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PRB-04: PROBLEM SCHLIESSEN
|
||||
# ---------------------------------------------------------------------------
|
||||
- id: "PRB-04"
|
||||
name: "Problem schließen"
|
||||
phase: "Abschluss"
|
||||
yasm_referenz: "LP4.7.5"
|
||||
|
||||
beschreibung: |
|
||||
Abschluss des Problem Records nach erfolgreicher Lösung
|
||||
oder bewusster Entscheidung, das Problem nicht weiter zu verfolgen.
|
||||
|
||||
schliessungsgruende:
|
||||
|
||||
loesung_implementiert:
|
||||
beschreibung: "Permanente Lösung wurde via Change implementiert"
|
||||
aktivitaeten:
|
||||
- "Validieren: Lösung wirksam? (keine neuen Incidents)"
|
||||
- "Known-Error-Artikel auf OBSOLET setzen"
|
||||
- "Verknüpfte Incidents prüfen"
|
||||
- "Problem Record auf GESCHLOSSEN setzen"
|
||||
- "Abschlussdokumentation"
|
||||
|
||||
workaround_akzeptiert:
|
||||
beschreibung: "Workaround ist Dauerlösung, keine weitere Aktion geplant"
|
||||
aktivitaeten:
|
||||
- "Entscheidung dokumentieren (warum keine permanente Lösung)"
|
||||
- "Known-Error-Artikel bleibt AKTIV"
|
||||
- "Problem Record auf GESCHLOSSEN setzen"
|
||||
- "Hinweis: Bei Änderung der Situation kann neu bewertet werden"
|
||||
|
||||
duplikat_oder_ungueltig:
|
||||
beschreibung: "Problem ist Duplikat oder war kein echtes Problem"
|
||||
aktivitaeten:
|
||||
- "Begründung dokumentieren"
|
||||
- "Ggf. mit anderem Problem Record verknüpfen"
|
||||
- "Problem Record auf GESCHLOSSEN setzen"
|
||||
|
||||
validierung_bei_loesung:
|
||||
beschreibung: |
|
||||
Nach Implementierung einer permanenten Lösung muss validiert
|
||||
werden, dass das Problem tatsächlich behoben ist.
|
||||
methoden:
|
||||
- "Monitoring der Incident-Rate für betroffenen Service"
|
||||
- "Beobachtungszeitraum (empfohlen: 2-4 Wochen)"
|
||||
- "Rückmeldung von L1/L2 zur Incident-Entwicklung"
|
||||
bei_misserfolg: "Zurück zu IN_ANALYSE"
|
||||
|
||||
output:
|
||||
- "Problem Record mit Status GESCHLOSSEN"
|
||||
- "Abschlussdokumentation"
|
||||
- "Known-Error-Artikel aktualisiert (OBSOLET wenn gelöst)"
|
||||
- "Lessons Learned (optional)"
|
||||
|
||||
raci:
|
||||
r: "Service Owner"
|
||||
a: "Service Owner"
|
||||
c: "-"
|
||||
i: "Support Manager"
|
||||
|
||||
# =============================================================================
|
||||
# STATUS-LIFECYCLE
|
||||
# =============================================================================
|
||||
|
||||
status_lifecycle:
|
||||
|
||||
beschreibung: |
|
||||
Vereinfachtes Status-Modell für Problem Records im MVP.
|
||||
Analog zum Ticket-Schema, aber auf Problem-Spezifika angepasst.
|
||||
|
||||
status_werte:
|
||||
|
||||
- id: "NEU"
|
||||
name: "Neu"
|
||||
beschreibung: "Problem Record erstellt, noch nicht in Analyse"
|
||||
|
||||
- id: "IN_ANALYSE"
|
||||
name: "In Analyse"
|
||||
beschreibung: "Root-Cause-Analyse läuft"
|
||||
|
||||
- id: "KNOWN_ERROR"
|
||||
name: "Known Error"
|
||||
beschreibung: |
|
||||
Ursache bekannt oder eingegrenzt, Workaround dokumentiert.
|
||||
Keine permanente Lösung geplant oder in Bewertung.
|
||||
|
||||
- id: "WARTEN_CHANGE"
|
||||
name: "Warten auf Change"
|
||||
beschreibung: "Permanente Lösung via Change in Arbeit"
|
||||
|
||||
- id: "GELOEST"
|
||||
name: "Gelöst"
|
||||
beschreibung: "Lösung implementiert, Validierung läuft"
|
||||
|
||||
- id: "GESCHLOSSEN"
|
||||
name: "Geschlossen"
|
||||
beschreibung: "Problem final abgeschlossen"
|
||||
|
||||
transitionen:
|
||||
|
||||
- von: "NEU"
|
||||
nach: ["IN_ANALYSE", "GESCHLOSSEN"]
|
||||
beschreibung: "Analyse starten oder als Duplikat/ungültig schließen"
|
||||
|
||||
- von: "IN_ANALYSE"
|
||||
nach: ["KNOWN_ERROR", "WARTEN_CHANGE", "GESCHLOSSEN"]
|
||||
beschreibung: "Analyse abgeschlossen mit verschiedenen Ergebnissen"
|
||||
|
||||
- von: "KNOWN_ERROR"
|
||||
nach: ["WARTEN_CHANGE", "IN_ANALYSE", "GESCHLOSSEN"]
|
||||
beschreibung: "Change initiieren, neu analysieren oder akzeptieren"
|
||||
|
||||
- von: "WARTEN_CHANGE"
|
||||
nach: ["GELOEST", "IN_ANALYSE"]
|
||||
beschreibung: "Change erfolgreich oder gescheitert"
|
||||
|
||||
- von: "GELOEST"
|
||||
nach: ["GESCHLOSSEN", "IN_ANALYSE"]
|
||||
beschreibung: "Validierung erfolgreich oder Problem tritt erneut auf"
|
||||
|
||||
- von: "GESCHLOSSEN"
|
||||
nach: ["IN_ANALYSE"]
|
||||
beschreibung: "Wiedereröffnung bei erneutem Auftreten"
|
||||
bedingung: "Nur mit Begründung durch Service Owner"
|
||||
|
||||
# =============================================================================
|
||||
# RACI-REFERENZ
|
||||
# =============================================================================
|
||||
|
||||
raci_referenz:
|
||||
|
||||
beschreibung: |
|
||||
Die verbindliche RACI-Matrix für Problem Management ist in
|
||||
ssm_governance.yaml → raci_konsolidiert.problem_management definiert.
|
||||
|
||||
Diese Kurzübersicht dient der schnellen Orientierung.
|
||||
|
||||
master_dokument: "ssm_governance.yaml"
|
||||
abschnitt: "raci_konsolidiert.problem_management"
|
||||
|
||||
hinweis_service_owner: |
|
||||
Der Service Owner ist Process Owner für Problem Management (SSM-G-18).
|
||||
Er kann operative Tätigkeiten (R) an Second Level Agents delegieren,
|
||||
bleibt aber immer Accountable (A).
|
||||
|
||||
kurzuebersicht:
|
||||
# L2 QK SM SO
|
||||
problem_erfassen: "R C - A"
|
||||
problem_analysieren: "R - I A/R"
|
||||
loesung_initiieren: "I - C A/R"
|
||||
problem_schliessen: "- - I A/R"
|
||||
known_error_erstellen: "R - - A"
|
||||
muster_erkennen: "C R - A"
|
||||
|
||||
hinweis: "L1 ist im Problem Management nicht direkt beteiligt"
|
||||
|
||||
# =============================================================================
|
||||
# KENNZAHLEN
|
||||
# =============================================================================
|
||||
|
||||
kennzahlen:
|
||||
|
||||
beschreibung: |
|
||||
Basis-KPIs für Problem Management im MVP. Fokus auf Wirksamkeit,
|
||||
nicht auf Prozess-Compliance.
|
||||
|
||||
kpis:
|
||||
|
||||
- id: "KPI-PRB-01"
|
||||
name: "Anzahl offener Probleme"
|
||||
beschreibung: "Aktuelle Anzahl nicht geschlossener Problem Records"
|
||||
messung: "Stichtag"
|
||||
ziel: "Kein festes Ziel, Trend beobachten"
|
||||
|
||||
- id: "KPI-PRB-02"
|
||||
name: "Problem-Lösungsrate"
|
||||
beschreibung: "Anteil der Probleme mit permanenter Lösung (nicht nur Workaround)"
|
||||
formel: "(Probleme mit Lösung) / (Geschlossene Probleme) × 100"
|
||||
ziel: "tbd"
|
||||
hinweis: "Nicht jedes Problem muss permanent gelöst werden"
|
||||
|
||||
- id: "KPI-PRB-03"
|
||||
name: "Known Errors mit aktivem Workaround"
|
||||
beschreibung: "Anzahl dokumentierter Known Errors"
|
||||
messung: "Stichtag"
|
||||
ziel: "Kein festes Ziel – zeigt Reife des Prozesses"
|
||||
|
||||
- id: "KPI-PRB-04"
|
||||
name: "Incident-Reduktion nach Problem-Lösung"
|
||||
beschreibung: "Reduktion der Incidents nach Implementierung einer Lösung"
|
||||
messung: "Vergleich Incident-Rate vor/nach Lösung"
|
||||
ziel: ">50% Reduktion"
|
||||
hinweis: "Nur messbar bei ausreichender Datenbasis"
|
||||
|
||||
todo: |
|
||||
- Zielwerte mit DIGIT abstimmen
|
||||
- Reporting-Frequenz festlegen (empfohlen: monatlich)
|
||||
- Baseline nach 3 Monaten Betrieb etablieren
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
|
||||
- modul: "sub-practice_incident-management.yaml"
|
||||
art: "erhält von"
|
||||
beschreibung: "Problem Records aus INC-11 und INC-12"
|
||||
aktivitaeten: ["INC-11", "INC-12"]
|
||||
|
||||
- modul: "ssm_wissensmanagement.yaml"
|
||||
art: "liefert an"
|
||||
beschreibung: "Known-Error-Artikel (Ebene 2)"
|
||||
artikel_typ: "KNOWN_ERROR"
|
||||
|
||||
- modul: "ssm_schema_ticket.yaml"
|
||||
art: "implementiert"
|
||||
beschreibung: "Problem Record Datenstruktur (analog zu Ticket)"
|
||||
|
||||
- modul: "spm_practice_service-level-management.yaml"
|
||||
art: "referenziert"
|
||||
beschreibung: "Service-Kategorien für Priorisierung"
|
||||
|
||||
- modul: "sub-practice_service-desk.yaml"
|
||||
art: "erhält von"
|
||||
beschreibung: "Problem Records werden oft durch Service Desk (via L2) erstellt"
|
||||
|
||||
- modul: "ssm_governance.yaml"
|
||||
art: "wird gesteuert durch"
|
||||
beschreibung: "Reporting-Struktur, Service Owner Reviews"
|
||||
|
||||
extern:
|
||||
|
||||
- partner: "Change Enablement"
|
||||
kontext: "Initiierung permanenter Lösungen via Change"
|
||||
status: "Schnittstelle zu P-03 (Platzhalter)"
|
||||
aktivitaet: "PRB-03"
|
||||
|
||||
- partner: "ITSM-Tool"
|
||||
kontext: "Problem Record Lifecycle"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
- partner: "Lieferanten"
|
||||
kontext: "RCA-Unterstützung bei externen Komponenten"
|
||||
status: "Fallweise"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-ENTSCHEIDUNGEN
|
||||
# =============================================================================
|
||||
|
||||
governance:
|
||||
|
||||
beschreibung: |
|
||||
Governance-Entscheidungen für Problem Management.
|
||||
Zur Übertragung ins zentrale Log.
|
||||
|
||||
entscheidungen:
|
||||
|
||||
- id: "SSM-G-18"
|
||||
name: "Keine dedizierte Problem-Manager-Rolle"
|
||||
entscheidung: |
|
||||
Im MVP gibt es keine dedizierte Problem-Manager-Rolle.
|
||||
Der Service Owner ist Process Owner für Problem Management
|
||||
in seinem Service-Bereich. Operative Tätigkeiten können an
|
||||
Second Level Agents delegiert werden.
|
||||
begruendung: |
|
||||
Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs-
|
||||
strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung
|
||||
für die Service-Qualität. ITIL4 warnt explizit davor, Problem
|
||||
Management als separate Funktion aufzubauen.
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-19"
|
||||
name: "Problem Management nur reaktiv im MVP"
|
||||
entscheidung: |
|
||||
Problem-Identifikation erfolgt im MVP ausschließlich reaktiv
|
||||
aus dem Incident Management (nicht lösbare oder wiederkehrende
|
||||
Incidents). Proaktive Problem-Identifikation (LP4.7.1) ist
|
||||
nicht im Scope.
|
||||
begruendung: |
|
||||
MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt
|
||||
die Datenbasis (Incident-Trends, Monitoring-Integration).
|
||||
Kann in späteren Ausbaustufen ergänzt werden.
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-20"
|
||||
name: "Known Errors als KB-Artikel"
|
||||
entscheidung: |
|
||||
Known Errors werden als KB-Artikel mit speziellem Typ
|
||||
(KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert.
|
||||
Es wird keine separate Known Error Database (KEDB) geführt.
|
||||
begruendung: |
|
||||
Integration in bestehendes Wissensmanagement, vermeidet
|
||||
Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen
|
||||
ohnehin in der KB – Known Errors werden so automatisch gefunden.
|
||||
status: "vorgeschlagen"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-PRB-001"
|
||||
thema: "Problem Record Schema"
|
||||
beschreibung: |
|
||||
Das Problem Record Schema muss analog zum Ticket Schema
|
||||
definiert werden. Kann als Erweiterung von ssm_schema_ticket.yaml
|
||||
oder als eigenes Schema erfolgen.
|
||||
prioritaet: "mittel"
|
||||
status: "Entscheidung ausstehend"
|
||||
|
||||
- id: "OPEN-PRB-002"
|
||||
thema: "Change-Schnittstelle"
|
||||
beschreibung: |
|
||||
Detaillierte Schnittstelle zu Change Enablement (P-03) definieren,
|
||||
sobald dieses Modul entwickelt ist.
|
||||
prioritaet: "mittel"
|
||||
status: "Abhängig von P-03 Entwicklung"
|
||||
abhaengig_von: "practice_change-enablement.yaml"
|
||||
|
||||
- id: "OPEN-PRB-003"
|
||||
thema: "Known-Error-Artikel-Template"
|
||||
beschreibung: |
|
||||
Template für Known-Error-Artikel in der KB erstellen und
|
||||
in ssm_wissensmanagement.yaml integrieren.
|
||||
prioritaet: "hoch"
|
||||
status: "Bei KB-Implementierung"
|
||||
|
||||
- id: "OPEN-PRB-004"
|
||||
thema: "Problem-Incident-Verknüpfung im Tool"
|
||||
beschreibung: |
|
||||
Technische Umsetzung der Verknüpfung zwischen Problem Records
|
||||
und Incidents im ITSM-Tool.
|
||||
prioritaet: "hoch"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-07"
|
||||
aenderung: "Initiale Erstellung als MVP-Version"
|
||||
autor: "DIGITOM-Projekt"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,790 @@
|
|||
# =============================================================================
|
||||
# SUB-PRACTICE: SERVICE DESK
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SD"
|
||||
name: "Service Desk"
|
||||
version: "0.2"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-07"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
parent_practice: "practice_service-support-management"
|
||||
|
||||
itil4_referenz: "Service Desk Practice"
|
||||
yasm_referenz: "LP4.6.1"
|
||||
|
||||
blueprint_referenz: "service-lifecycle_service-support.yaml"
|
||||
relevante_aktivitaeten: ["ss_01", "ss_02", "ss_03"]
|
||||
|
||||
design_referenz: "ssm_design-zieldimensionen.yaml"
|
||||
relevante_saeulen: ["LS-01", "LS-02", "LS-03", "LS-04"]
|
||||
|
||||
hinweis: |
|
||||
Der Service Desk ist keine Prozess-Practice wie Incident oder Request
|
||||
Management, sondern eine organisatorische Capability. Dieses Dokument
|
||||
beschreibt die organisatorischen Rahmenbedingungen, nicht die Prozesse.
|
||||
|
||||
# =============================================================================
|
||||
# ZWECK & SELBSTVERSTÄNDNIS
|
||||
# =============================================================================
|
||||
|
||||
zweck:
|
||||
|
||||
definition: |
|
||||
Der Service Desk ist der zentrale Zugangspunkt für alle IT-bezogenen
|
||||
Anfragen und Störungsmeldungen. Er fungiert als Single Point of Contact
|
||||
(SPOC) zwischen Nutzern und der IT-Organisation.
|
||||
|
||||
selbstverstaendnis:
|
||||
|
||||
enablement_paradigma:
|
||||
beschreibung: |
|
||||
Der Service Desk verfolgt ein Enablement-Paradigma: Der First Level
|
||||
agiert als aktiver Problemlöser und Befähiger, nicht als reiner
|
||||
Ticket-Verteiler ("Ticket-Schubser").
|
||||
|
||||
prinzipien:
|
||||
- "Agents gehen selbst auf Detektivsuche und schaffen Lösungen"
|
||||
- "Enge Zusammenarbeit mit Second Level und Service Ownern"
|
||||
- "Systematisches Lernen durch legitimierte Exploration"
|
||||
- "Befähigung der Nutzer, nicht nur Symptombehandlung"
|
||||
|
||||
governance: "SSM-G-03 (Explorative-Diagnose-Legitimation)"
|
||||
|
||||
kernfunktionen:
|
||||
- "Zentrale Anlaufstelle für alle IT-Anfragen"
|
||||
- "Qualifizierte Erstanalyse und Triage"
|
||||
- "First-Level-Resolution für definierte Standardfälle"
|
||||
- "Koordinierte Weiterleitung bei Eskalation"
|
||||
- "Proaktive Kommunikation mit Nutzern"
|
||||
- "Beitrag zum organisatorischen Wissensaufbau"
|
||||
|
||||
ziele:
|
||||
- "Schnelle und kompetente Erstreaktion auf Nutzeranfragen"
|
||||
- "Hohe First Contact Resolution Rate"
|
||||
- "Transparente Kommunikation über Ticket-Status"
|
||||
- "Kontinuierliche Befähigung des First Level"
|
||||
- "Systematische Erfassung aller IT-Kontakte"
|
||||
|
||||
# =============================================================================
|
||||
# SYSTEMGRENZE
|
||||
# =============================================================================
|
||||
|
||||
systemgrenze:
|
||||
|
||||
beschreibung: |
|
||||
Der Service Desk etabliert eine "harte Grenze" als formale Regel:
|
||||
Alle IT-Anfragen müssen durch den Service Desk. Diese Grenze gilt
|
||||
als Referenzpunkt, mit dem Verständnis, dass informelle Strukturen
|
||||
existieren werden.
|
||||
|
||||
harte_grenze:
|
||||
|
||||
prinzip: "Keine IT-Bearbeitung ohne Ticket"
|
||||
|
||||
konsequenzen:
|
||||
- "Alle Anfragen werden als Ticket erfasst"
|
||||
- "Auch mündliche Anfragen führen zu Ticket-Erstellung"
|
||||
- "Rückkanal immer über Ticketsystem"
|
||||
- "Dokumentation aller Aktivitäten im Ticket"
|
||||
|
||||
begruendung: |
|
||||
Die harte Grenze ermöglicht:
|
||||
- Vollständige Transparenz über IT-Aufwände
|
||||
- Messbarkeit und Steuerbarkeit
|
||||
- Nachvollziehbarkeit für Nutzer und IT
|
||||
- Basis für kontinuierliche Verbesserung
|
||||
|
||||
umgang_informelle_strukturen:
|
||||
|
||||
akzeptanz_der_realitaet:
|
||||
beschreibung: |
|
||||
Informelle Strukturen werden existieren. "Lieblings-Admins" werden
|
||||
direkt kontaktiert, VIPs werden Sonderwege suchen. Das Modell
|
||||
akzeptiert diese Realität, etabliert aber einen Reflexionsmechanismus.
|
||||
|
||||
beispiele:
|
||||
- "Direkter Anruf bei bekanntem L2-Kollegen"
|
||||
- "E-Mail direkt an Spezialisten statt Service Desk"
|
||||
- "Flurfunk-Anfragen"
|
||||
|
||||
reflexionsmechanismus:
|
||||
beschreibung: "Service Owner beobachten Umgehungen"
|
||||
bewertung:
|
||||
- "Einmalig oder systematisch?"
|
||||
- "Verursacht das Probleme?"
|
||||
- "Gibt es einen legitimen Grund?"
|
||||
|
||||
intervention_nur_bei: "Problematischen Mustern"
|
||||
|
||||
interventionsstufen:
|
||||
- stufe: 1
|
||||
aktion: "Gespräch mit beteiligten Personen"
|
||||
- stufe: 2
|
||||
aktion: "Formale Erinnerung an Prozesse"
|
||||
- stufe: 3
|
||||
aktion: "Eskalation an Führungsebene"
|
||||
- stufe: 4
|
||||
aktion: "Anpassung der Prozesse (wenn sinnvoll)"
|
||||
|
||||
# =============================================================================
|
||||
# KANALMANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
kanalmanagement:
|
||||
|
||||
beschreibung: |
|
||||
Definition der Eingangskanäle und wie Anfragen über diese Kanäle
|
||||
in das Ticketsystem überführt werden.
|
||||
|
||||
eingangskanal:
|
||||
|
||||
- kanal: "Service Portal"
|
||||
typ: "Self-Service"
|
||||
beschreibung: "Webformular im Intranet"
|
||||
ticket_erstellung: "Automatisch durch Nutzer"
|
||||
empfohlen: true
|
||||
vorteile:
|
||||
- "Strukturierte Erfassung"
|
||||
- "Reduziert Rückfragen"
|
||||
- "24/7 verfügbar"
|
||||
|
||||
- kanal: "E-Mail"
|
||||
typ: "Asynchron"
|
||||
beschreibung: "E-Mail an zentrale Service-Desk-Adresse"
|
||||
ticket_erstellung: "Automatisch oder durch Agent"
|
||||
hinweis: |
|
||||
E-Mails direkt an einzelne Agents sollen an die zentrale
|
||||
Adresse weitergeleitet werden.
|
||||
|
||||
- kanal: "Telefon"
|
||||
typ: "Synchron"
|
||||
beschreibung: "Anruf bei Service-Desk-Hotline"
|
||||
ticket_erstellung: "Durch Agent während/nach Gespräch"
|
||||
hinweis: |
|
||||
Agent erstellt Ticket während des Gesprächs oder unmittelbar
|
||||
danach. Keine Bearbeitung ohne Ticket-Dokumentation.
|
||||
|
||||
- kanal: "Persönlich (Walk-in)"
|
||||
typ: "Synchron"
|
||||
beschreibung: "Direkter Besuch während Bürozeiten"
|
||||
ticket_erstellung: "Durch Agent"
|
||||
hinweis: "Nur während definierter Servicezeiten"
|
||||
|
||||
ticket_pflicht:
|
||||
|
||||
regel: |
|
||||
Jede Anfrage, unabhängig vom Kanal, führt zu einem Ticket.
|
||||
Auch wenn die Lösung im Erstkontakt erfolgt, wird dokumentiert.
|
||||
|
||||
ausnahmen:
|
||||
- "Reine Informationsfragen, die in <2 Minuten beantwortet sind"
|
||||
- "Weiterleitung an andere Stelle (kein IT-Thema)"
|
||||
|
||||
bei_ausnahmen: "Kurze Notiz im Tagesprotokoll empfohlen"
|
||||
|
||||
# =============================================================================
|
||||
# SERVICEZEITEN & ERREICHBARKEIT
|
||||
# =============================================================================
|
||||
|
||||
servicezeiten:
|
||||
|
||||
status: "ANFORDERUNGEN"
|
||||
|
||||
hinweis: |
|
||||
Die konkreten Servicezeiten sind eine operative Entscheidung von DIGIT.
|
||||
Dieses Dokument definiert die Anforderungen und Rahmenbedingungen.
|
||||
|
||||
anforderungen:
|
||||
|
||||
kernservicezeit:
|
||||
beschreibung: "Zeitraum mit voller Service-Desk-Besetzung"
|
||||
empfehlung: "Mindestens Kernarbeitszeit der Stadtverwaltung"
|
||||
anforderung: "Telefonische Erreichbarkeit muss gewährleistet sein"
|
||||
|
||||
erweiterte_erreichbarkeit:
|
||||
beschreibung: "Zeitraum mit eingeschränkter Erreichbarkeit"
|
||||
optionen:
|
||||
- "E-Mail-Monitoring außerhalb Kernzeit"
|
||||
- "Rufbereitschaft für kritische Systeme"
|
||||
status: "Mit DIGIT zu klären"
|
||||
|
||||
mindestbesetzung:
|
||||
beschreibung: "Minimale Anzahl Agents während Kernzeit"
|
||||
anforderung: |
|
||||
Mindestens 2 Agents zur Abdeckung von:
|
||||
- Telefonkanal
|
||||
- Ticket-Bearbeitung
|
||||
- Vertretung bei Kurzabwesenheit
|
||||
|
||||
bei_unterschreitung: "Eskalation an Queue-Koordinator"
|
||||
|
||||
kommunikation:
|
||||
|
||||
anforderung: |
|
||||
Servicezeiten müssen den Nutzern klar kommuniziert werden.
|
||||
|
||||
kanaele:
|
||||
- "Intranet-Seite des Service Desk"
|
||||
- "Automatische Antwort bei E-Mail außerhalb Servicezeiten"
|
||||
- "Ansage bei Telefon außerhalb Servicezeiten"
|
||||
|
||||
offener_punkt: "OPEN-SD-001"
|
||||
|
||||
# =============================================================================
|
||||
# EINGANGSSTEUERUNG (TRIAGE)
|
||||
# =============================================================================
|
||||
|
||||
eingangssteuerung:
|
||||
|
||||
beschreibung: |
|
||||
Die Eingangssteuerung (Triage) ist der erste Schritt bei jeder Anfrage.
|
||||
Sie bestimmt den Ticket-Typ, die initiale Klassifikation und die
|
||||
Pool-Zuweisung.
|
||||
|
||||
triage_prozess:
|
||||
|
||||
schritt_1_ticket_typ:
|
||||
frage: "Um was für eine Anfrage handelt es sich?"
|
||||
entscheidung:
|
||||
stoerung: "→ Incident (P-04)"
|
||||
anfrage_im_katalog: "→ Request (P-05)"
|
||||
anfrage_nicht_im_katalog: "→ Demand (DPM)"
|
||||
ungewiss: "→ Als Incident erfassen, später umklassifizieren"
|
||||
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen"
|
||||
|
||||
schritt_2_klassifikation:
|
||||
beschreibung: "Impact, Urgency und Priorität bestimmen"
|
||||
|
||||
bei_incident:
|
||||
- "Impact bewerten (Hoch/Normal/Niedrig)"
|
||||
- "Urgency bewerten (Hoch/Normal/Niedrig)"
|
||||
- "Priorität aus Matrix ableiten"
|
||||
|
||||
bei_request:
|
||||
- "Katalog-Eintrag identifizieren"
|
||||
- "Service-Kategorie übernehmen"
|
||||
- "Genehmigungsanforderung prüfen"
|
||||
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml"
|
||||
|
||||
schritt_3_pool_zuweisung:
|
||||
beschreibung: "Ticket dem richtigen Pool zuweisen"
|
||||
|
||||
pools:
|
||||
- pool: "Sofort-Pool"
|
||||
kriterien: "P1 (alle Charakteristiken)"
|
||||
ziel: "Sofortige Bearbeitung"
|
||||
|
||||
- pool: "Standard-Pool"
|
||||
kriterien: "P2-P4 mit Charakteristik STANDARD oder ANALYSE"
|
||||
ziel: "Bearbeitung gemäß SLA"
|
||||
|
||||
- pool: "Projekt-Pool"
|
||||
kriterien: "Charakteristik PROJEKT (planbar, >1 Tag Aufwand)"
|
||||
ziel: "Koordinierte Bearbeitung"
|
||||
|
||||
hinweis: |
|
||||
Version 0.2: Der bisherige Analyse-Pool entfällt.
|
||||
ANALYSE-Tickets werden im Standard-Pool bearbeitet.
|
||||
Die Charakteristik ANALYSE bleibt als Label für Reporting erhalten.
|
||||
|
||||
referenz: "ssm_klassifikation-priorisierung.yaml → pool_modell"
|
||||
|
||||
schritt_4_erste_reaktion:
|
||||
beschreibung: "Nutzer über Ticket-Erstellung informieren"
|
||||
inhalt:
|
||||
- "Ticket-Nummer"
|
||||
- "Kurze Bestätigung des Anliegens"
|
||||
- "Erwartbare nächste Schritte"
|
||||
- "Kontaktmöglichkeit bei Rückfragen"
|
||||
|
||||
qualitaetsanforderung:
|
||||
|
||||
beschreibung: |
|
||||
Die Triage-Qualität bestimmt maßgeblich die Effizienz der
|
||||
nachfolgenden Bearbeitung. Fehlerhafte Klassifikation führt
|
||||
zu Verzögerungen und Nacharbeit.
|
||||
|
||||
schulungsbedarf: "Regelmäßige Schulung der Triage-Kriterien"
|
||||
|
||||
feedback_loop: |
|
||||
Bei häufigen Fehlklassifikationen: Anpassung der Kriterien
|
||||
oder zusätzliche Schulung.
|
||||
|
||||
# =============================================================================
|
||||
# QUEUE-KOORDINATION
|
||||
# =============================================================================
|
||||
|
||||
queue_koordination:
|
||||
|
||||
beschreibung: |
|
||||
Der Queue-Koordinator ist verantwortlich für die operative Steuerung
|
||||
der Ticket-Queues. Er überwacht Workload, priorisiert innerhalb der
|
||||
Pools und koordiniert bei Engpässen oder Konflikten.
|
||||
|
||||
rolle:
|
||||
referenz: "ssm_rollen.yaml → queue_koordinator"
|
||||
|
||||
besetzung:
|
||||
primaer: "Definierte Person (z.B. Gruppenleiter)"
|
||||
stellvertretung: "Muss für Abwesenheiten definiert sein"
|
||||
modell: "Kann dediziert, rotierend oder in Teilzeit sein"
|
||||
|
||||
offener_punkt: "OPEN-ROLLEN-001"
|
||||
|
||||
ueberwachungsaufgaben:
|
||||
|
||||
pool_monitoring:
|
||||
beschreibung: "Kontinuierliche Überwachung aller Pools"
|
||||
fokus:
|
||||
- "Anzahl Tickets pro Pool"
|
||||
- "Liegezeiten kritischer Tickets"
|
||||
- "Verteilung auf Agents"
|
||||
|
||||
werkzeug: "Dashboard (Echtzeit)"
|
||||
|
||||
kapazitaetssteuerung:
|
||||
beschreibung: "Balance zwischen Pools und Agents"
|
||||
aktivitaeten:
|
||||
- "Erkennen von Kapazitätsengpässen"
|
||||
- "Umverteilung bei Ungleichgewicht"
|
||||
- "Eskalation bei Überlast"
|
||||
|
||||
sla_ueberwachung:
|
||||
beschreibung: "Überwachung der SLA-Einhaltung"
|
||||
aktivitaeten:
|
||||
- "Frühwarnung bei SLA-Gefährdung"
|
||||
- "Priorisierung gefährdeter Tickets"
|
||||
- "Eskalation bei drohender Verletzung"
|
||||
|
||||
interventionsregeln:
|
||||
|
||||
beschreibung: |
|
||||
Der Queue-Koordinator greift aktiv ein, wenn definierte
|
||||
Schwellwerte erreicht werden.
|
||||
|
||||
trigger:
|
||||
|
||||
- situation: "Ticket >15 Min im Sofort-Pool"
|
||||
aktion: "Sofortige Intervention, Zuweisung erzwingen"
|
||||
eskalation: "Bei Ressourcenmangel → Support Manager"
|
||||
|
||||
- situation: "Ticket >30 Min im Sofort-Pool"
|
||||
aktion: "Alarmierung Support Manager"
|
||||
eskalation: "Automatisch"
|
||||
|
||||
- situation: "Agent hat 2 blockierte Tickets"
|
||||
aktion: "Prüfung: Warum blockiert? Unterstützung anbieten"
|
||||
eskalation: "Bei strukturellem Problem → Support Manager"
|
||||
|
||||
- situation: "Standard-Pool >20 Tickets"
|
||||
aktion: "Kapazitätsalarm, Priorisierung, ggf. Umverteilung"
|
||||
eskalation: "Bei anhaltendem Überlauf → Support Manager"
|
||||
|
||||
- situation: "Extreme Ungleichverteilung"
|
||||
aktion: "Ausgleich zwischen Agents"
|
||||
eskalation: "Keine, direkte Koordination"
|
||||
|
||||
- situation: "Übergabe nicht akzeptiert nach 4h"
|
||||
aktion: "Klärung mit beteiligten Agents"
|
||||
eskalation: "Bei Verweigerung → Support Manager"
|
||||
|
||||
interventionsstufen:
|
||||
|
||||
- stufe: 1
|
||||
name: "Anfrage"
|
||||
beschreibung: "Kannst du Ticket X übernehmen?"
|
||||
anwendung: "Normalfall"
|
||||
|
||||
- stufe: 2
|
||||
name: "Direktive Zuweisung"
|
||||
beschreibung: "Bitte übernimm Ticket X, weil..."
|
||||
anwendung: "Bei Dringlichkeit oder fehlender Reaktion"
|
||||
dokumentation: "Begründung im Ticket"
|
||||
|
||||
- stufe: 3
|
||||
name: "Eskalation"
|
||||
beschreibung: "Weiterleitung an Support Manager"
|
||||
anwendung: "Bei Verweigerung oder strukturellem Problem"
|
||||
|
||||
transparenz_dashboard:
|
||||
|
||||
beschreibung: |
|
||||
Ein zentrales, für alle sichtbares Dashboard zeigt in Echtzeit
|
||||
den Status der Queues und Agents.
|
||||
|
||||
inhalte:
|
||||
- "Anzahl Tickets pro Pool"
|
||||
- "Aktuelle Ticket-Verteilung pro Agent"
|
||||
- "Liegezeiten kritischer Tickets"
|
||||
- "Blockierte Tickets mit Grund"
|
||||
- "Tages-Statistiken (geschlossen, neu, eskaliert)"
|
||||
|
||||
anforderung: "Muss im ITSM-Tool oder separat implementiert werden"
|
||||
|
||||
offener_punkt: "OPEN-SD-002"
|
||||
|
||||
# =============================================================================
|
||||
# ARBEITSORGANISATION
|
||||
# =============================================================================
|
||||
|
||||
arbeitsorganisation:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SINGLE-PIECE-FLOW
|
||||
# ---------------------------------------------------------------------------
|
||||
single_piece_flow:
|
||||
|
||||
beschreibung: |
|
||||
Das Single-Piece-Flow-Prinzip begrenzt die gleichzeitige Bearbeitung
|
||||
auf maximal 2 Tickets pro Agent. Dies reduziert Context-Switching
|
||||
und verbessert Durchlaufzeiten.
|
||||
|
||||
regel:
|
||||
primaer_ticket: "Hauptfokus (80% der Zeit)"
|
||||
sekundaer_ticket: "Nur wenn Primär-Ticket blockiert ist"
|
||||
maximum: "2 Tickets gleichzeitig"
|
||||
|
||||
begruendung:
|
||||
- "Reduziert Context-Switching"
|
||||
- "Verbessert Durchlaufzeiten"
|
||||
- "Erhöht Lösungsqualität"
|
||||
- "Macht Fortschritt sichtbar"
|
||||
|
||||
ausnahmen:
|
||||
- "Kurzfristige Unterbrechung für P1-Ticket"
|
||||
- "Warten auf Nutzer-Rückmeldung (Clock-Stop)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# COMMITMENT-PRINZIP
|
||||
# ---------------------------------------------------------------------------
|
||||
commitment_prinzip:
|
||||
|
||||
beschreibung: |
|
||||
Das Commitment-Prinzip etabliert klare Ownership: Ein gezogenes
|
||||
Ticket gehört dem Agent bis zur Lösung oder formalen Übergabe.
|
||||
|
||||
grundregel: "Ticket gezogen = Ticket owned"
|
||||
|
||||
governance: "SSM-G-07"
|
||||
|
||||
legitime_ausgaenge:
|
||||
- ausgang: "GELÖST"
|
||||
beschreibung: "Ticket wird mit Lösung geschlossen"
|
||||
|
||||
- ausgang: "ESKALIERT"
|
||||
beschreibung: "Formale Weitergabe mit dokumentierter Begründung"
|
||||
anforderung: "Definition of Handover (DoH) muss erfüllt sein"
|
||||
referenz: "SSM-G-08"
|
||||
|
||||
- ausgang: "GEPARKT"
|
||||
beschreibung: "Wartet auf externe Aktion"
|
||||
gruende:
|
||||
- "WARTEN_NUTZER"
|
||||
- "WARTEN_EXTERN"
|
||||
- "WARTEN_CHANGE"
|
||||
|
||||
verboten:
|
||||
- "Stille Rückgabe in den Pool"
|
||||
- "Ownership-loses Ticket"
|
||||
- "Weitergabe ohne Dokumentation"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ENABLEMENT-PHILOSOPHIE (EIGENVERANTWORTLICHES ARBEITEN)
|
||||
# ---------------------------------------------------------------------------
|
||||
enablement_philosophie:
|
||||
|
||||
beschreibung: |
|
||||
Der Service Desk verfolgt eine Enablement-Philosophie: Agents sind
|
||||
eigenverantwortliche Problemlöser, nicht "Ticket-Schubser". Der Agent
|
||||
entscheidet selbst über sein Vorgehen, die SLA gibt den Rahmen vor.
|
||||
|
||||
konzept:
|
||||
- "Agent entscheidet eigenverantwortlich über sein Vorgehen"
|
||||
- "Die SLA gibt den zeitlichen Rahmen vor"
|
||||
- "Eskalation ist eine Option, keine Pflicht bei Unklarheit"
|
||||
- "Dokumentation von Erkenntnissen ist erwünscht (nicht verpflichtend)"
|
||||
|
||||
bei_standard_tickets:
|
||||
beschreibung: "Dokumentierte Lösung anwenden, schnelle Durchlaufzeit"
|
||||
|
||||
bei_analyse_tickets:
|
||||
beschreibung: |
|
||||
Agent führt eigenständige Diagnose durch. Die SLA gibt den
|
||||
zeitlichen Rahmen vor. Bei fehlender Lösung: Eskalation an L2.
|
||||
|
||||
Die Charakteristik ANALYSE ist ein Label für Reporting,
|
||||
keine Steuerungsgröße für einen separaten Pool.
|
||||
|
||||
hinweis: |
|
||||
Version 0.2: Das bisherige "Explorationsbudget" (90-120 Min) als
|
||||
eigenständiges Konzept entfällt. Die SLA gibt den Zeitrahmen vor,
|
||||
innerhalb dessen der Agent arbeitet. Die Enablement-Philosophie
|
||||
(Agent darf eigenverantwortlich arbeiten) bleibt erhalten.
|
||||
|
||||
referenz: "ssm_design-zieldimensionen.yaml → LS-02"
|
||||
|
||||
# =============================================================================
|
||||
# TEAM-ORGANISATION
|
||||
# =============================================================================
|
||||
|
||||
team_organisation:
|
||||
|
||||
status: "EMPFEHLUNG"
|
||||
|
||||
hinweis: |
|
||||
Die Team-Organisation ist eine operative Entscheidung von DIGIT.
|
||||
Die folgenden Strukturen sind Empfehlungen basierend auf dem
|
||||
Referenzmodell.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MEETING-STRUKTUR
|
||||
# ---------------------------------------------------------------------------
|
||||
meeting_struktur:
|
||||
|
||||
taeglich:
|
||||
name: "Stand-up"
|
||||
dauer: "15 Minuten"
|
||||
zeitpunkt: "Empfohlen: Beginn der Kernzeit"
|
||||
teilnehmer: "Alle anwesenden Agents, Queue-Koordinator"
|
||||
agenda:
|
||||
- "Pool-Status Review"
|
||||
- "Blockierte Tickets"
|
||||
- "Kapazitäten des Tages"
|
||||
- "Besondere Vorkommnisse"
|
||||
- "Kurze Abstimmungen"
|
||||
|
||||
woechentlich:
|
||||
name: "Team-Meeting"
|
||||
dauer: "60 Minuten"
|
||||
teilnehmer: "Gesamtes Team, Support Manager"
|
||||
agenda:
|
||||
- "Wochen-Review (Kennzahlen)"
|
||||
- "Prozess-Verbesserungen"
|
||||
- "Knowledge-Sharing"
|
||||
- "Ankündigungen"
|
||||
- "Team-Themen"
|
||||
|
||||
monatlich:
|
||||
name: "Service Owner Review"
|
||||
dauer: "2 Stunden"
|
||||
teilnehmer: "Service Owner, First Level Vertreter, ggf. Second Level"
|
||||
agenda:
|
||||
- "Service-spezifische Themen"
|
||||
- "Dokumentations-Review"
|
||||
- "Verbesserungspotentiale"
|
||||
- "Schulungsbedarfe"
|
||||
|
||||
governance: "Pflicht, siehe ssm_governance.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHICHTPLANUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
schichtplanung:
|
||||
|
||||
status: "ANFORDERUNGEN"
|
||||
|
||||
anforderungen:
|
||||
|
||||
mindestbesetzung:
|
||||
beschreibung: "Minimale Besetzung während Servicezeiten"
|
||||
anforderung: "Mindestens 2 Agents"
|
||||
begruendung: "Telefon + Ticket-Bearbeitung + Vertretung"
|
||||
|
||||
vertretungsregelung:
|
||||
beschreibung: "Abdeckung bei Abwesenheit"
|
||||
anforderungen:
|
||||
- "Urlaub muss mit Mindestvorlauf angekündigt werden"
|
||||
- "Krankheitsvertretung muss geregelt sein"
|
||||
- "Queue-Koordinator-Stellvertretung muss definiert sein"
|
||||
|
||||
peak_zeiten:
|
||||
beschreibung: "Erhöhte Besetzung zu Stoßzeiten"
|
||||
empfehlung: "Identifikation typischer Peak-Zeiten aus Ticket-Daten"
|
||||
anforderung: "Berücksichtigung bei Schichtplanung"
|
||||
|
||||
offener_punkt: "OPEN-SD-003"
|
||||
|
||||
# =============================================================================
|
||||
# QUALITÄTSSTANDARDS
|
||||
# =============================================================================
|
||||
|
||||
qualitaetsstandards:
|
||||
|
||||
status: "ANFORDERUNGEN"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REAKTIONSZEITEN
|
||||
# ---------------------------------------------------------------------------
|
||||
reaktionszeiten:
|
||||
|
||||
beschreibung: |
|
||||
Zielzeiten für die erste qualifizierte Reaktion auf Anfragen.
|
||||
Konkrete Werte sind mit SLM abzustimmen.
|
||||
|
||||
anforderungen:
|
||||
- kanal: "Telefon"
|
||||
ziel: "Annahme innerhalb 30 Sekunden (während Servicezeit)"
|
||||
|
||||
- kanal: "E-Mail"
|
||||
ziel: "Erste Reaktion innerhalb SLA-Reaktionszeit"
|
||||
|
||||
- kanal: "Portal"
|
||||
ziel: "Automatische Bestätigung sofort, Bearbeitung gem. Priorität"
|
||||
|
||||
referenz: "spm_practice_service-level-management.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KOMMUNIKATIONSSTANDARDS
|
||||
# ---------------------------------------------------------------------------
|
||||
kommunikationsstandards:
|
||||
|
||||
beschreibung: |
|
||||
Qualitätsanforderungen an die Kommunikation mit Nutzern.
|
||||
|
||||
prinzipien:
|
||||
- "Freundlich und professionell"
|
||||
- "Verständliche Sprache (kein IT-Jargon)"
|
||||
- "Proaktive Updates bei längerer Bearbeitung"
|
||||
- "Klare Aussagen zu nächsten Schritten"
|
||||
- "Erreichbarkeit für Rückfragen"
|
||||
|
||||
bei_eskalation:
|
||||
- "Nutzer über Eskalation informieren"
|
||||
- "Neuen Ansprechpartner nennen (wenn bekannt)"
|
||||
- "Erwartbare Bearbeitungszeit kommunizieren"
|
||||
|
||||
bei_wartezeit:
|
||||
- "Regelmäßige Status-Updates (mindestens alle 2 Arbeitstage)"
|
||||
- "Proaktive Information bei Verzögerungen"
|
||||
- "Transparenz über Gründe"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DOKUMENTATIONSSTANDARDS
|
||||
# ---------------------------------------------------------------------------
|
||||
dokumentationsstandards:
|
||||
|
||||
beschreibung: |
|
||||
Anforderungen an die Ticket-Dokumentation.
|
||||
|
||||
mindestanforderungen:
|
||||
- "Vollständige Problembeschreibung"
|
||||
- "Durchgeführte Diagnose-Schritte"
|
||||
- "Lösung oder Eskalationsgrund"
|
||||
- "Kommunikation mit Nutzer dokumentiert"
|
||||
|
||||
referenz: "ssm_schema_ticket.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
|
||||
- modul: "sub-practice_incident-management.yaml"
|
||||
art: "führt aus"
|
||||
beschreibung: "Service Desk führt Incident-Prozess operativ aus"
|
||||
|
||||
- modul: "sub-practice_request-management.yaml"
|
||||
art: "führt aus"
|
||||
beschreibung: "Service Desk führt Request-Prozess operativ aus"
|
||||
|
||||
- modul: "ssm_klassifikation-priorisierung.yaml"
|
||||
art: "verwendet"
|
||||
beschreibung: "Pool-System, Prioritäts-Matrix"
|
||||
|
||||
- modul: "ssm_rollen.yaml"
|
||||
art: "implementiert"
|
||||
beschreibung: "First Level Agent, Queue-Koordinator"
|
||||
|
||||
- modul: "ssm_wissensmanagement.yaml"
|
||||
art: "nutzt und pflegt"
|
||||
beschreibung: "KB-Nutzung und Ebene-3-Beiträge"
|
||||
|
||||
- modul: "ssm_governance.yaml"
|
||||
art: "wird gesteuert durch"
|
||||
beschreibung: "Eskalationslogik, Reporting"
|
||||
|
||||
extern:
|
||||
|
||||
- partner: "Second Level Support"
|
||||
kontext: "Funktionale Eskalation"
|
||||
schnittstelle: "Definition of Handover (DoH)"
|
||||
|
||||
- partner: "Service Owner"
|
||||
kontext: "Befähigung, Dokumentation, Service-Reviews"
|
||||
frequenz: "Monatlich"
|
||||
|
||||
- partner: "Nutzer / Anwender"
|
||||
kontext: "Alle IT-Anfragen und Störungsmeldungen"
|
||||
kanaele: ["Portal", "E-Mail", "Telefon", "Walk-in"]
|
||||
|
||||
- partner: "ITSM-Tool"
|
||||
kontext: "Ticket-Erfassung, Queue-Management, Dashboard"
|
||||
status: "Tool-Auswahl ausstehend"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-SD-001"
|
||||
thema: "Konkrete Servicezeiten"
|
||||
beschreibung: |
|
||||
Die konkreten Servicezeiten (Kernzeit, erweiterte Erreichbarkeit)
|
||||
müssen mit DIGIT festgelegt werden.
|
||||
prioritaet: "hoch"
|
||||
status: "Mit DIGIT zu klären"
|
||||
|
||||
- id: "OPEN-SD-002"
|
||||
thema: "Dashboard-Implementierung"
|
||||
beschreibung: |
|
||||
Das Transparenz-Dashboard muss im ITSM-Tool oder als separate
|
||||
Lösung implementiert werden.
|
||||
prioritaet: "mittel"
|
||||
status: "Abhängig von Tool-Auswahl"
|
||||
|
||||
- id: "OPEN-SD-003"
|
||||
thema: "Schichtplanung"
|
||||
beschreibung: |
|
||||
Konkrete Schichtplanung inkl. Vertretungsregelung muss mit
|
||||
DIGIT erarbeitet werden.
|
||||
prioritaet: "mittel"
|
||||
status: "Operative Planung"
|
||||
|
||||
- id: "OPEN-SD-004"
|
||||
thema: "Telefonie-Integration"
|
||||
beschreibung: |
|
||||
Integration der Telefonie (ACD, Warteschlange, Statistik) mit
|
||||
dem ITSM-Tool.
|
||||
prioritaet: "mittel"
|
||||
status: "Technische Klärung"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.2"
|
||||
datum: "2026-01-28"
|
||||
aenderung: |
|
||||
Anpassung an vereinfachtes Pool-Modell:
|
||||
- Triage: Drei-Pool-Struktur (Sofort, Standard, Projekt)
|
||||
- Analyse-Pool entfällt, ANALYSE-Tickets gehen in Standard-Pool
|
||||
- "Indifferenzraum" umbenannt zu "Enablement-Philosophie"
|
||||
- Explorationsbudget entfällt als eigenständiges Konzept
|
||||
- SLA gibt Zeitrahmen vor, Agent arbeitet eigenverantwortlich
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-07"
|
||||
aenderung: "Initiale Erstellung"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,952 @@
|
|||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG: SERVICE OWNER
|
||||
# =============================================================================
|
||||
# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/
|
||||
# Dateiname: rolle_service-owner.yaml
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "R-SO"
|
||||
name: "Service Owner"
|
||||
kurzform: "SO"
|
||||
version: "1.0"
|
||||
status: "entwurf"
|
||||
erstellt: "2025-12-17"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "rollenbeschreibung"
|
||||
|
||||
beschreibung: |
|
||||
Vollständige Rollenbeschreibung für den Service Owner.
|
||||
Konsolidiert Informationen aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*,
|
||||
GOV-007, GOV-008), Practice-Dokumenten (SLM, SCM, Change Enablement, SSM)
|
||||
und der Kurzreferenz in spm_rollen.yaml.
|
||||
|
||||
referenzen:
|
||||
kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml -> service_owner"
|
||||
support_kontext: "03_practices/spm_practice_service-support-management/ssm_rollen.yaml"
|
||||
vorlage_struktur: "#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml"
|
||||
service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml"
|
||||
slm: "03_practices/spm_practice_service-level-management.yaml"
|
||||
scm: "03_practices/spm_practice_service-catalog-management.yaml"
|
||||
change_enablement: "03_practices/spm_practice_change-enablement.yaml"
|
||||
governance_log: "spm_governance-entscheidungen-log.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "service-portfolio-management"
|
||||
- "service-ownership"
|
||||
- "lifecycle-management"
|
||||
- "service-review"
|
||||
- "change-authority"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENZWECK
|
||||
# =============================================================================
|
||||
|
||||
rollenzweck:
|
||||
|
||||
kurz: |
|
||||
Durchgängige Accountability für einen definierten Service über dessen
|
||||
gesamten Lifecycle – von der Übernahme in Transition bis zur Stilllegung.
|
||||
|
||||
ausfuehrlich: |
|
||||
Der Service Owner trägt die End-to-End-Verantwortung für seinen Service
|
||||
im Rahmen der definierten Governance-Strukturen. Diese Verantwortung
|
||||
bedeutet Lifecycle-Kontinuität, nicht Entscheidungsautonomie.
|
||||
|
||||
Die Rolle umfasst:
|
||||
- Fachliche Gesamtverantwortung für Service-Definition, -Qualität und -Entwicklung
|
||||
- Accountability für Service-Performance und SLA-Einhaltung
|
||||
- Change Authority für Normal Changes im eigenen Service-Scope
|
||||
- Operative Accountability für Problem Management im Service-Kontext
|
||||
- Vertretung des Service in Gremien (SOR, Kundenforum)
|
||||
|
||||
Der Service Owner agiert als "Unternehmer für seinen Service" –
|
||||
allerdings eingebettet in die kollektive Governance-Architektur des DIGIT
|
||||
(SOR, Mission Board) und gebunden an Portfolio-Entscheidungen des SPM.
|
||||
|
||||
itil4_referenz: |
|
||||
"The owner of a service is accountable for the delivery of that service.
|
||||
Their accountability for the service extends from when the organization
|
||||
adds it to its portfolio until its eventual retirement."
|
||||
(ITIL4 Direct, Plan and Improve, 7.3.1.4)
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "Formale Übernahme bei Gate 1 (Entry Transition)"
|
||||
fuer: "Service-Qualität, SLA-Einhaltung, Service-Weiterentwicklung"
|
||||
bis: "Abschluss der Stilllegung (Retirement)"
|
||||
governance_referenz: "GOV-TR-006"
|
||||
|
||||
# =============================================================================
|
||||
# ORGANISATORISCHE EINORDNUNG
|
||||
# =============================================================================
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
zuordnung:
|
||||
funktion: "Service-Portfolio-Management (SPM)"
|
||||
hinweis: |
|
||||
Die disziplinarische Zuordnung des SO ist kontextabhängig und
|
||||
nicht Gegenstand dieser Rollenbeschreibung. Der SO kann
|
||||
organisatorisch in verschiedenen Abteilungen angesiedelt sein.
|
||||
|
||||
berichtslinie:
|
||||
fachlich: "Service-Portfolio-Manager (SPM)"
|
||||
disziplinarisch: "[Kontextabhängig – offener Punkt für MVP]"
|
||||
|
||||
rollentyp:
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: |
|
||||
Jeder Service im Portfolio hat genau einen Service Owner.
|
||||
Eine Person kann mehrere Services verantworten (Kapazitätsfrage).
|
||||
|
||||
arbeitsmodell:
|
||||
status: "Offener Punkt für MVP"
|
||||
hinweis: |
|
||||
Kapazitätsfragen (wie viele Services pro SO?) und Arbeitsmodell
|
||||
(Voll-/Teilzeit) sind nicht Teil des MVP und werden später geklärt.
|
||||
|
||||
vertretung:
|
||||
allgemein: |
|
||||
Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen
|
||||
(Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung
|
||||
delegiert werden.
|
||||
transition_spezifisch: |
|
||||
Gate-Entscheidungen können bei kurzfristiger SO-Abwesenheit verschoben
|
||||
werden. Bei Dringlichkeit: Eskalation an SOR.
|
||||
governance_referenz: "GOV-TR-013"
|
||||
annahme_markierung: "ANNAHME – Generelle Vertretungslogik abgeleitet aus GOV-TR-013"
|
||||
|
||||
# =============================================================================
|
||||
# KERNAUFGABEN
|
||||
# =============================================================================
|
||||
|
||||
kernaufgaben:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE TRANSITION
|
||||
# ---------------------------------------------------------------------------
|
||||
service_transition:
|
||||
|
||||
name: "Service Transition Management"
|
||||
|
||||
beschreibung: |
|
||||
Übernahme neuer oder wesentlich geänderter Services aus der
|
||||
Service-Entwicklung in den produktiven Betrieb.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Gate 1 (Entry Transition) – SOR-Vorlage"
|
||||
raci: "R"
|
||||
beschreibung: "Vorbereitung und Einreichung der Gate-1-Vorlage bei SPM; Entscheidung liegt bei SOR"
|
||||
governance_referenz: "GOV-TR-011"
|
||||
|
||||
- aufgabe: "Accountability-Übernahme ab Gate 1"
|
||||
beschreibung: |
|
||||
Ab Gate 1 trägt SO die formale Accountability für den Service.
|
||||
In der Phase bis Gate 2 besteht eine Überlappungszone mit der
|
||||
Projektleitung (gemeinsame Verantwortung).
|
||||
governance_referenz: "GOV-TR-006"
|
||||
|
||||
- aufgabe: "Service-Definition erstellen"
|
||||
raci: "A/R"
|
||||
beschreibung: "Erstellung der vollständigen Service-Definition nach Schema"
|
||||
freigabe_durch: "SPM validiert, SOR gibt frei (bei Neuaufnahme)"
|
||||
governance_referenz: "GOV-007"
|
||||
|
||||
- aufgabe: "Gate 2 (Entry-Prüfung nach Build) – Entscheidung"
|
||||
raci: "A (Einzelentscheidung)"
|
||||
beschreibung: "SO prüft Übergabefähigkeit nach Build und entscheidet eigenständig über Freigabe/Zurückweisung"
|
||||
governance_referenz: "GOV-TR-012"
|
||||
|
||||
- aufgabe: "ELS-Management (Early Life Support)"
|
||||
raci: "A"
|
||||
beschreibung: |
|
||||
Verantwortung für intensivierte Betreuung nach Go-Live.
|
||||
Entscheidung über ELS-Exit als SO-Einzelentscheidung.
|
||||
governance_referenz: "GOV-TR-021"
|
||||
|
||||
- aufgabe: "Rollback-Entscheidung (ELS)"
|
||||
raci: "A (Einzelentscheidung)"
|
||||
beschreibung: |
|
||||
Bei fundamentalen Problemen während ELS kann SO eigenständig
|
||||
Rollback entscheiden.
|
||||
governance_referenz: "GOV-TR-029"
|
||||
|
||||
referenz: "spm_konzept_service-transition.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE REVIEW
|
||||
# ---------------------------------------------------------------------------
|
||||
service_review:
|
||||
|
||||
name: "Quartalsweiser Service Review"
|
||||
|
||||
beschreibung: |
|
||||
Regelmäßige Selbstbewertung des Service anhand des 4-Dimensionen-Modells.
|
||||
Ableitung von Handlungsempfehlungen und ggf. Einreichung bei SOR.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Service-Review durchführen"
|
||||
frequenz: "Quartalsweise"
|
||||
raci: "A/R"
|
||||
beschreibung: |
|
||||
Bewertung des Service anhand der vier Dimensionen:
|
||||
- SR-D1: Leistungserbringung (SLA-Erfüllung)
|
||||
- SR-D2: Betriebsstabilität (Incidents, Verfügbarkeit)
|
||||
- SR-D3: Nutzerzufriedenheit (Feedback, Beschwerden)
|
||||
- SR-D4: Zukunftsfähigkeit (technisch, strategisch)
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
- aufgabe: "Handlungsempfehlung ableiten"
|
||||
raci: "A/R"
|
||||
optionen:
|
||||
- "CONTINUE – Service läuft wie geplant"
|
||||
- "IMPROVEMENT – Verbesserungsmaßnahmen erforderlich"
|
||||
- "REDESIGN – Grundlegende Überarbeitung nötig"
|
||||
- "RETIRE – Stilllegung empfohlen"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
- aufgabe: "SPM informieren"
|
||||
frequenz: "Nach jedem Review"
|
||||
raci: "R"
|
||||
beschreibung: "Informationspflicht an SPM über Review-Ergebnis"
|
||||
governance_referenz: "GOV-SR-002"
|
||||
|
||||
- aufgabe: "SOR-Vorlage einreichen (bei Bedarf)"
|
||||
trigger:
|
||||
- "Mindestens eine Dimension auf ROT"
|
||||
- "IMPROVEMENT mit Ressourcenbedarf"
|
||||
- "REDESIGN oder RETIRE"
|
||||
raci: "R"
|
||||
governance_referenz: "GOV-SR-003"
|
||||
|
||||
- aufgabe: "Improvement-Maßnahmen definieren und tracken"
|
||||
raci: "A/R"
|
||||
beschreibung: "Dokumentation in der Service-Definition (Abschnitt 'laufende_verbesserungen')"
|
||||
governance_referenz: "GOV-SR-005"
|
||||
|
||||
- aufgabe: "Wirksamkeitsprüfung im Folge-Review"
|
||||
raci: "A/R"
|
||||
governance_referenz: "GOV-SR-005"
|
||||
|
||||
referenz: "spm_konzept_service-review.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE LEVEL MANAGEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
service_level_management:
|
||||
|
||||
name: "Service Level Management"
|
||||
|
||||
beschreibung: |
|
||||
Verantwortung für Definition, Vereinbarung, Überwachung und
|
||||
Review der Service Levels.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Service-Level-Anforderungen erheben"
|
||||
phase: "Transition"
|
||||
raci: "A"
|
||||
beschreibung: "Verantwortet die Anforderungserhebung aus Kundensicht"
|
||||
aktivitaets_id: "slm_01"
|
||||
|
||||
- aufgabe: "Service Level Specification (SLS) erstellen"
|
||||
phase: "Transition"
|
||||
raci: "A"
|
||||
beschreibung: "Verantwortet SLS-Inhalt (Übersetzung in messbare Levels)"
|
||||
aktivitaets_id: "slm_02"
|
||||
|
||||
- aufgabe: "SLA abstimmen und fixieren"
|
||||
phase: "Transition"
|
||||
raci: "R"
|
||||
beschreibung: "Führt Abstimmung mit SLA-Partner, moderiert Usergroup"
|
||||
aktivitaets_id: "slm_03"
|
||||
|
||||
- aufgabe: "SLA-Freigabe vorbereiten"
|
||||
phase: "Transition"
|
||||
raci: "R"
|
||||
beschreibung: "Bereitet SOR-/MB-Freigabe vor"
|
||||
aktivitaets_id: "slm_04"
|
||||
|
||||
- aufgabe: "Service Levels überwachen"
|
||||
phase: "Betrieb"
|
||||
raci: "A"
|
||||
beschreibung: "Verantwortet Interpretation der Messergebnisse"
|
||||
aktivitaets_id: "slm_05"
|
||||
|
||||
- aufgabe: "SLA-Performance reporten"
|
||||
phase: "Betrieb"
|
||||
raci: "A"
|
||||
frequenz: "Monatlich (intern), Quartalsweise (extern)"
|
||||
beschreibung: "Verantwortet Bericht und Interpretation"
|
||||
aktivitaets_id: "slm_06"
|
||||
|
||||
- aufgabe: "SLA-Verletzung eskalieren"
|
||||
phase: "Betrieb"
|
||||
raci: "R"
|
||||
beschreibung: "Identifiziert, analysiert, eskaliert (Stufe 1 im Eskalationspfad)"
|
||||
aktivitaets_id: "slm_07"
|
||||
|
||||
- aufgabe: "Internen SLA-Review durchführen"
|
||||
phase: "Review"
|
||||
raci: "A"
|
||||
frequenz: "Jährlich"
|
||||
aktivitaets_id: "slm_08"
|
||||
|
||||
- aufgabe: "Externen SLA-Review mit Kunden durchführen"
|
||||
phase: "Review"
|
||||
raci: "R"
|
||||
frequenz: "Jährlich"
|
||||
beschreibung: "Führt Review durch, moderiert Kundenforum gemeinsam mit SHM"
|
||||
aktivitaets_id: "slm_09"
|
||||
governance_referenz: "GOV-012"
|
||||
|
||||
referenz: "spm_practice_service-level-management.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICE CATALOG MANAGEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
service_catalog_management:
|
||||
|
||||
name: "Service Catalog Management"
|
||||
|
||||
beschreibung: |
|
||||
Verantwortung für die inhaltliche Pflege der Service-Definition
|
||||
und des Service-Steckbriefs im Katalog.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Service-Definition erstellen"
|
||||
raci: "A/R"
|
||||
beschreibung: "Inhaltliche Erstellung nach Schema"
|
||||
governance_referenz: "GOV-007"
|
||||
|
||||
- aufgabe: "Service-Definition zur Validierung einreichen"
|
||||
raci: "R"
|
||||
freigabe_durch: "SPM"
|
||||
aktivitaets_id: "scm_01"
|
||||
|
||||
- aufgabe: "Service-Steckbrief erstellen"
|
||||
raci: "R"
|
||||
beschreibung: "Ableitung des kundenorientierten Auszugs"
|
||||
aktivitaets_id: "scm_02"
|
||||
|
||||
- aufgabe: "Katalogänderungen initiieren"
|
||||
raci: "R"
|
||||
beschreibung: "Meldet Änderungsbedarf, beschreibt Änderung"
|
||||
aktivitaets_id: "scm_05"
|
||||
|
||||
- aufgabe: "Redaktionelle Katalogänderungen (autonom)"
|
||||
raci: "A/R"
|
||||
beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"]
|
||||
governance_referenz: "GOV-008"
|
||||
|
||||
- aufgabe: "Service-Stilllegung koordinieren"
|
||||
raci: "R"
|
||||
beschreibung: "Koordiniert Kommunikation bei Stilllegung"
|
||||
aktivitaets_id: "scm_06"
|
||||
|
||||
- aufgabe: "Jährlicher Katalog-Review (Zulieferung)"
|
||||
raci: "C"
|
||||
beschreibung: "Liefert Informationen zu eigenen Services"
|
||||
aktivitaets_id: "scm_07"
|
||||
|
||||
referenz: "spm_practice_service-catalog-management.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# CHANGE ENABLEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
change_enablement:
|
||||
|
||||
name: "Change Enablement"
|
||||
|
||||
beschreibung: |
|
||||
Change Authority für Normal Changes im eigenen Service-Scope.
|
||||
Klassifizierung und Bewertung von Change Requests.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Change Requests klassifizieren"
|
||||
raci: "A/R"
|
||||
beschreibung: "Prüfung: Standard? Normal? Major?"
|
||||
|
||||
- aufgabe: "Normal Changes bewerten und entscheiden"
|
||||
raci: "A (Change Authority)"
|
||||
beschreibung: "Risiko-, Aufwand- und Auswirkungsbewertung; Freigabe/Ablehnung"
|
||||
|
||||
- aufgabe: "Cross-Service-Impact erkennen"
|
||||
raci: "R"
|
||||
beschreibung: |
|
||||
SO ist verantwortlich für Erkennung von Cross-Service-Auswirkungen.
|
||||
Bei Cross-Service-Impact: SPM als "zweite Augen" einbeziehen.
|
||||
governance_referenz: "GOV-CE-003"
|
||||
|
||||
- aufgabe: "Standard Change-Modelle dokumentieren"
|
||||
raci: "A/R"
|
||||
beschreibung: |
|
||||
Dokumentation wiederkehrender, risikoarmer Changes für den
|
||||
eigenen Service. SPM erhält Kopie zur Kenntnis.
|
||||
|
||||
- aufgabe: "Change-Abschluss bestätigen"
|
||||
raci: "A/R"
|
||||
beschreibung: "Bestätigung der erfolgreichen Umsetzung"
|
||||
|
||||
referenz: "spm_practice_change-enablement.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PROBLEM MANAGEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
problem_management:
|
||||
|
||||
name: "Problem Management (Service-Kontext)"
|
||||
|
||||
beschreibung: |
|
||||
Operative Accountability für Problem Management im eigenen Service-Scope.
|
||||
Der SO ist NICHT Practice Owner (liegt beim SPM), sondern trägt die
|
||||
Verantwortung für die Durchführung im Service-Kontext.
|
||||
|
||||
designentscheidung: "D-01"
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Problem-Analyse verantworten"
|
||||
raci: "A"
|
||||
beschreibung: "Accountable für Root-Cause-Analyse, kann an L2 delegieren"
|
||||
aktivitaets_id: "PRB-02"
|
||||
|
||||
- aufgabe: "Lösungsinitiierung entscheiden"
|
||||
raci: "A/R"
|
||||
beschreibung: |
|
||||
Entscheidung: Permanente Lösung via Change oder alternative Maßnahme?
|
||||
Kosten-Nutzen-Abwägung.
|
||||
aktivitaets_id: "PRB-03"
|
||||
|
||||
- aufgabe: "Change Request aus Problem erstellen"
|
||||
raci: "A/R"
|
||||
beschreibung: "Bei Bedarf: Change Request mit Problem-Verweis erstellen"
|
||||
schnittstelle: "Change Enablement (P-03)"
|
||||
|
||||
- aufgabe: "Problem schließen"
|
||||
raci: "A/R"
|
||||
beschreibung: "Abschluss nach Lösung oder bewusster Akzeptanz"
|
||||
aktivitaets_id: "PRB-04"
|
||||
|
||||
- aufgabe: "Known Error dokumentieren"
|
||||
raci: "A"
|
||||
beschreibung: "Verantwortet Known-Error-Dokumentation"
|
||||
|
||||
- aufgabe: "Muster erkennen (Incident-Cluster)"
|
||||
raci: "A"
|
||||
beschreibung: "Verantwortet systematische Mustererkennung"
|
||||
|
||||
referenz: "sub-practice_problem-management.yaml"
|
||||
governance_referenz: "SSM-G-18"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# INCIDENT MANAGEMENT (ESKALATIONSROLLE)
|
||||
# ---------------------------------------------------------------------------
|
||||
incident_management:
|
||||
|
||||
name: "Incident Management (Eskalationsrolle)"
|
||||
|
||||
beschreibung: |
|
||||
Fachliche Eskalationsinstanz bei Major Incidents und komplexen
|
||||
Störungen im eigenen Service-Bereich.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "Fachliche Eskalation annehmen"
|
||||
raci: "A"
|
||||
trigger: "Major Incident oder L2-Eskalation"
|
||||
beschreibung: "Fachliche Klärung und Priorisierungsentscheidung"
|
||||
|
||||
- aufgabe: "Hierarchische Eskalation initiieren"
|
||||
raci: "R"
|
||||
beschreibung: "Bei Bedarf Eskalation an SOR"
|
||||
|
||||
referenz: "sub-practice_incident-management.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# WISSENSMANAGEMENT
|
||||
# ---------------------------------------------------------------------------
|
||||
wissensmanagement:
|
||||
|
||||
name: "Wissensmanagement (Service-Kontext)"
|
||||
|
||||
beschreibung: |
|
||||
Verantwortung für service-spezifische Wissensdokumentation.
|
||||
|
||||
aktivitaeten:
|
||||
|
||||
- aufgabe: "KB Ebene 1 verantworten"
|
||||
raci: "A"
|
||||
beschreibung: "Grundlagendokumentation zum Service"
|
||||
|
||||
- aufgabe: "KB Ebene 2 co-erstellen"
|
||||
raci: "C"
|
||||
beschreibung: "Arbeitsdokumentation gemeinsam mit Support-Team"
|
||||
|
||||
referenz: "ssm_rollen.yaml"
|
||||
governance_referenz: "SSM-G-09"
|
||||
|
||||
# =============================================================================
|
||||
# BEFUGNISSE
|
||||
# =============================================================================
|
||||
|
||||
befugnisse:
|
||||
|
||||
eigenstaendig:
|
||||
|
||||
- befugnis: "Gate 2 (Entry-Prüfung nach Build) – Freigabe"
|
||||
scope: "Eigener Service"
|
||||
beschreibung: "Operative Einzelentscheidung über Übergabefähigkeit nach Build"
|
||||
governance_referenz: "GOV-TR-012"
|
||||
|
||||
- befugnis: "ELS-Exit-Entscheidung"
|
||||
scope: "Eigener Service"
|
||||
beschreibung: "Beendigung des Early Life Support"
|
||||
mit_informationspflicht: "SPM"
|
||||
governance_referenz: "GOV-TR-021"
|
||||
|
||||
- befugnis: "Rollback während ELS"
|
||||
scope: "Eigener Service"
|
||||
beschreibung: "Bei fundamentalen Problemen"
|
||||
governance_referenz: "GOV-TR-029"
|
||||
|
||||
- befugnis: "Normal Changes genehmigen"
|
||||
scope: "Eigener Service"
|
||||
beschreibung: "Change Authority für Normal Changes"
|
||||
governance_referenz: "GOV-CE-001"
|
||||
|
||||
- befugnis: "Redaktionelle Katalogänderungen"
|
||||
scope: "Eigener Service"
|
||||
beispiele: ["Tippfehler", "Kontaktdaten"]
|
||||
governance_referenz: "GOV-008"
|
||||
|
||||
- befugnis: "Problem-Schließung"
|
||||
scope: "Eigener Service"
|
||||
beschreibung: "Abschluss von Problem Records"
|
||||
|
||||
- befugnis: "Service-Review durchführen und bewerten"
|
||||
scope: "Eigener Service"
|
||||
frequenz: "Quartalsweise"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
in_abstimmung:
|
||||
|
||||
- befugnis: "Minor Katalogänderungen"
|
||||
abstimmung_mit: "SPM (bilateral)"
|
||||
governance_referenz: "GOV-008"
|
||||
|
||||
- befugnis: "Cross-Service-Changes"
|
||||
abstimmung_mit: "SPM als 'zweite Augen'"
|
||||
governance_referenz: "GOV-CE-003"
|
||||
|
||||
- befugnis: "SLS/SLA-Inhalte"
|
||||
abstimmung_mit: "Betriebsteam (technische Messbarkeit), SPM (Portfolio-Konsistenz)"
|
||||
|
||||
ueber_gremien:
|
||||
|
||||
- befugnis: "Gate 1 (Entry Transition) – Go/No-Go"
|
||||
gremium: "SOR"
|
||||
so_rolle: "Antragsteller, Vorlage-Einreichung"
|
||||
governance_referenz: "GOV-TR-011"
|
||||
|
||||
- befugnis: "Gate 3 (Go-Live-Freigabe)"
|
||||
gremium: "SOR"
|
||||
so_rolle: "Antragsteller, Nachweisführung"
|
||||
governance_referenz: "GOV-TR-016"
|
||||
|
||||
- befugnis: "Major Katalogänderungen / Neuaufnahme"
|
||||
gremium: "SOR"
|
||||
governance_referenz: "GOV-008"
|
||||
|
||||
- befugnis: "SLA-Freigabe (Standard)"
|
||||
gremium: "SOR"
|
||||
|
||||
- befugnis: "SLA-Freigabe (Abweichungen/Major)"
|
||||
gremium: "Mission Board"
|
||||
governance_referenz: "GOV-001"
|
||||
|
||||
- befugnis: "Strukturelle Katalogänderungen"
|
||||
gremium: "Mission Board"
|
||||
beispiele: ["Kategorie-Wechsel", "Stilllegung"]
|
||||
governance_referenz: "GOV-008"
|
||||
|
||||
# =============================================================================
|
||||
# EINSCHRÄNKUNGEN / NICHT-AUFGABEN
|
||||
# =============================================================================
|
||||
|
||||
einschraenkungen:
|
||||
|
||||
nicht_aufgabe:
|
||||
|
||||
- was: "Portfolio-Entscheidungen"
|
||||
zustaendig: "SPM / SOR / Mission Board"
|
||||
klarstellung: |
|
||||
SO bringt Service-Perspektive ein, entscheidet aber nicht über
|
||||
Portfolio-Zusammensetzung, Service-Priorisierung oder Ressourcenallokation
|
||||
auf Portfolio-Ebene.
|
||||
|
||||
- was: "Major Changes / Transition-pflichtige Änderungen"
|
||||
zustaendig: "SOR (via Transition-Gates)"
|
||||
klarstellung: |
|
||||
Wenn eine Änderung die Service-Identität berührt oder Transition-Gates
|
||||
erfordert, liegt die Entscheidung bei SOR, nicht beim SO.
|
||||
governance_referenz: "GOV-CE-004"
|
||||
|
||||
- was: "Practice-Weiterentwicklung (methodisch)"
|
||||
zustaendig: "SPM (als Practice Owner)"
|
||||
klarstellung: |
|
||||
SO führt Practices für seinen Service aus, entwickelt aber nicht
|
||||
die Methodik weiter. Practice Ownership liegt beim SPM.
|
||||
designentscheidung: "D-01"
|
||||
|
||||
- was: "L1/L2-Support-Aktivitäten"
|
||||
zustaendig: "Service Desk, Support Manager, Support-Agenten"
|
||||
klarstellung: |
|
||||
SO ist Eskalationsinstanz, nicht operativer Support-Bearbeiter.
|
||||
|
||||
- was: "Betriebsführung / technische Operations"
|
||||
zustaendig: "Operations Manager, Betriebsteam"
|
||||
klarstellung: |
|
||||
SO verantwortet Service fachlich (Was wird geliefert?),
|
||||
nicht technisch-operativ (Wie wird es betrieben?).
|
||||
hinweis: "Abgrenzung zu Operations Manager in separatem Dokument zu klären"
|
||||
|
||||
- was: "SLA-Verhandlung (finale Entscheidung)"
|
||||
zustaendig: "SOR / Mission Board"
|
||||
klarstellung: |
|
||||
SO moderiert SLA-Abstimmung mit Kunden, aber finale SLA-Freigabe
|
||||
erfolgt durch SOR (Standard) oder MB (Abweichungen).
|
||||
|
||||
- was: "Budget-Entscheidungen über definierte Schwellwerte"
|
||||
zustaendig: "[Zu klären – offener Punkt]"
|
||||
status: "Offener Punkt für MVP"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
|
||||
- partner: "Service-Portfolio-Manager (SPM)"
|
||||
interaktion:
|
||||
- "Fachliche Berichtslinie"
|
||||
- "Service-Review-Ergebnisse kommunizieren"
|
||||
- "Service-Definition zur Validierung einreichen"
|
||||
- "Rücksprache bei Klassifizierungsfragen (Change/Demand)"
|
||||
- "SPM als 'zweite Augen' bei Cross-Service-Changes"
|
||||
frequenz: "Regelmäßig + bei Bedarf"
|
||||
|
||||
- partner: "Support Manager"
|
||||
interaktion:
|
||||
- "Eskalationsempfang (fachlich)"
|
||||
- "Abstimmung bei Problem Management"
|
||||
- "Koordination L2-Aktivitäten"
|
||||
frequenz: "Bei Bedarf"
|
||||
referenz: "ssm_governance.yaml"
|
||||
|
||||
- partner: "Operations Manager"
|
||||
interaktion:
|
||||
- "Abstimmung Service-Betrieb"
|
||||
- "Monitoring-Anforderungen"
|
||||
- "Kapazitäts- und Performance-Themen"
|
||||
frequenz: "Bei Bedarf"
|
||||
hinweis: "Detaillierte Abgrenzung in separatem Dokument zu klären"
|
||||
|
||||
- partner: "Betriebsteam"
|
||||
interaktion:
|
||||
- "Koordination Betriebsaktivitäten"
|
||||
- "Abstimmung bei SLS-Erstellung (technische Messbarkeit)"
|
||||
- "Monitoring-Daten und Reports"
|
||||
frequenz: "Laufend"
|
||||
fuehrungsverhaeltnis: "[Offener Punkt – disziplinarische Einordnung ungeklärt]"
|
||||
|
||||
- partner: "Projektleitung (in Transition)"
|
||||
interaktion:
|
||||
- "Überlappungszone Gate 1 bis Gate 2"
|
||||
- "Übergabe der Service-Verantwortung"
|
||||
frequenz: "Während Transition-Phase"
|
||||
governance_referenz: "GOV-TR-006"
|
||||
|
||||
extern:
|
||||
|
||||
- partner: "Stakeholder-Manager (SHM)"
|
||||
interaktion:
|
||||
- "Gemeinsame Moderation Kundenforum"
|
||||
- "Abstimmung bei Kundenfeedback"
|
||||
- "Unterstützung bei Kundeninteraktion (SLA-Review)"
|
||||
frequenz: "Bei Bedarf, Kundenforum jährlich"
|
||||
governance_referenz: "GOV-012"
|
||||
|
||||
- partner: "DIGIT-Mitarbeiter (interner Bedarf)"
|
||||
interaktion:
|
||||
- "Empfang interner Bedarfe für eigenen Service"
|
||||
- "Change-Qualifizierung: Ist es ein Change oder Demand?"
|
||||
- "Bei Change-Charakter: Bewertung und Umsetzung"
|
||||
- "Bei Demand-Charakter: Rückverweis an SHM/DPM"
|
||||
frequenz: "Bei Bedarf"
|
||||
hinweis: |
|
||||
Service Owner ist Ansprechpartner für interne Bedarfe, die einen
|
||||
bestehenden Service betreffen. SO entscheidet, ob es ein Change
|
||||
(SO-Verantwortung) oder Demand (DPM-Verantwortung) ist.
|
||||
|
||||
Der Eingang erfolgt über SHM Fast Track Routing (siehe
|
||||
shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern).
|
||||
referenz: "shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern"
|
||||
|
||||
- partner: "DPM (Demand-Portfolio-Management)"
|
||||
interaktion:
|
||||
- "Konsultation in Service-Entwicklung (vor Gate 1)"
|
||||
- "Rückfragen zu Demand-Spezifikationen"
|
||||
frequenz: "Bei Bedarf"
|
||||
hinweis: "Formale Accountability beginnt bei Gate 1, Einbindung vorher empfohlen"
|
||||
|
||||
- partner: "Kunden / SLA-Partner"
|
||||
interaktion:
|
||||
- "SLA-Abstimmung (Moderation)"
|
||||
- "Jährlicher externer SLA-Review"
|
||||
- "Service-bezogene Kommunikation"
|
||||
frequenz: "Jährlich (Review) + bei Bedarf"
|
||||
|
||||
# =============================================================================
|
||||
# GREMIENROLLEN
|
||||
# =============================================================================
|
||||
|
||||
gremienrollen:
|
||||
|
||||
- gremium: "SOR (Service Operations Runde)"
|
||||
rolle: "Stimmberechtigtes Mitglied"
|
||||
funktion: |
|
||||
Vertretung des eigenen Service bei portfolio-relevanten Entscheidungen.
|
||||
Stimmrecht bei Themen des eigenen Service.
|
||||
befugnisse:
|
||||
- "Stimmrecht bei Service-bezogenen Entscheidungen"
|
||||
- "Einreichung von Vorlagen (Gate 2, Review-Eskalationen, Major Changes)"
|
||||
- "Teilnahme an Portfolio-Diskussionen"
|
||||
anwesenheit: "Bei Themen des eigenen Service (Details siehe G-SOR Geschäftsordnung)"
|
||||
referenz: "G-SOR Geschäftsordnung (placeholder)"
|
||||
hinweis: |
|
||||
Portfolio-übergreifende Entscheidungen und Anwesenheitsregelung
|
||||
werden in der SOR-Geschäftsordnung definiert.
|
||||
|
||||
- gremium: "Mission Board"
|
||||
rolle: "Bei Bedarf (Eskalation)"
|
||||
funktion: "Eskalationsinstanz bei SOR-Dissens oder MB-pflichtigen Entscheidungen"
|
||||
beispiele:
|
||||
- "SLA-Abweichungen von Standard"
|
||||
- "Strukturelle Katalogänderungen"
|
||||
- "Ressourcenkonflikte"
|
||||
|
||||
- gremium: "Kundenforum"
|
||||
rolle: "Moderator (gemeinsam mit SHM)"
|
||||
funktion: |
|
||||
Moderation des integrierten Kundenforums für Service-bezogene Themen.
|
||||
SLM-Review + SHM-Beziehungspflege.
|
||||
frequenz: "Jährlich"
|
||||
governance_referenz: "GOV-012"
|
||||
|
||||
# =============================================================================
|
||||
# ANFORDERUNGSPROFIL
|
||||
# =============================================================================
|
||||
|
||||
anforderungsprofil:
|
||||
|
||||
fachlich:
|
||||
- "Tiefes Verständnis des verantworteten Service (funktional und technisch)"
|
||||
- "Kenntnisse des Service-Katalogs und der Service-Landschaft im DIGIT"
|
||||
- "Grundverständnis ITIL4 Service Management Practices"
|
||||
- "Verständnis des DIGITOM (SPM, DPM, SHM-Zusammenspiel)"
|
||||
- "Kenntnisse der relevanten SLAs und Service Levels"
|
||||
|
||||
methodisch:
|
||||
- "Service-Review und -Bewertung"
|
||||
- "Risiko- und Impact-Bewertung (Change Enablement)"
|
||||
- "Root-Cause-Analyse (Problem Management)"
|
||||
- "Stakeholder-Kommunikation und Moderation"
|
||||
- "Dokumentation und strukturierte Erfassung"
|
||||
|
||||
persoenlich:
|
||||
- "Ownership-Mentalität und Ergebnisorientierung"
|
||||
- "Entscheidungsfähigkeit unter Unsicherheit"
|
||||
- "Kommunikationsstärke (intern und extern)"
|
||||
- "Fähigkeit zur Priorisierung und zum Trade-off-Management"
|
||||
- "Kooperationsfähigkeit in Gremienstrukturen"
|
||||
- "Verbindlichkeit und Zuverlässigkeit"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE (FÜR MVP NICHT ADRESSIERT)
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
- id: "OPEN-SO-001"
|
||||
thema: "Budget-Verantwortung für laufenden Betrieb"
|
||||
beschreibung: |
|
||||
Welche Budget-Befugnisse hat der SO für den laufenden Service-Betrieb?
|
||||
Gibt es Schwellwerte, ab denen Abstimmung/Eskalation erforderlich ist?
|
||||
prioritaet: "mittel"
|
||||
status: "Für MVP nicht adressiert"
|
||||
|
||||
- id: "OPEN-SO-002"
|
||||
thema: "Disziplinarische Einordnung"
|
||||
beschreibung: |
|
||||
Wo ist der SO organisatorisch angesiedelt? Welche disziplinarische
|
||||
Berichtslinie gilt?
|
||||
prioritaet: "mittel"
|
||||
status: "Für MVP nicht adressiert"
|
||||
hinweis: "Kontextabhängig je nach Service und Organisation"
|
||||
|
||||
- id: "OPEN-SO-003"
|
||||
thema: "Arbeitsmodell / Kapazität"
|
||||
beschreibung: |
|
||||
Wie viele Services kann/soll ein SO verantworten?
|
||||
Ist SO Voll- oder Teilzeitrolle?
|
||||
prioritaet: "mittel"
|
||||
status: "Für MVP nicht adressiert"
|
||||
|
||||
- id: "OPEN-SO-004"
|
||||
thema: "Abgrenzung zu Operations Manager"
|
||||
beschreibung: |
|
||||
Detaillierte Domänenabgrenzung zwischen SO (fachlich) und
|
||||
Operations Manager (technisch-operativ).
|
||||
prioritaet: "hoch"
|
||||
status: "Grundlogik klar, Details in separatem Dokument zu klären"
|
||||
abhaengig_von: "Rolle Operations Manager"
|
||||
|
||||
- id: "OPEN-SO-005"
|
||||
thema: "Führungsverantwortung Betriebsteam"
|
||||
beschreibung: |
|
||||
Hat der SO fachliche und/oder disziplinarische Führungsverantwortung
|
||||
für das Betriebsteam?
|
||||
prioritaet: "mittel"
|
||||
status: "Für MVP nicht adressiert"
|
||||
zusammenhang: "OPEN-SO-002"
|
||||
|
||||
# =============================================================================
|
||||
# DESIGNENTSCHEIDUNGEN (DOKUMENTIERT)
|
||||
# =============================================================================
|
||||
|
||||
designentscheidungen:
|
||||
|
||||
- id: "D-01"
|
||||
datum: "2025-12-17"
|
||||
frage: "Ist SO Practice Owner für Problem Management?"
|
||||
entscheidung: |
|
||||
Nein. SO ist operativ accountable für Problem Management im eigenen
|
||||
Service-Scope, aber NICHT Practice Owner.
|
||||
Practice Ownership für alle Practices liegt beim SPM.
|
||||
begruendung: |
|
||||
Konsistent mit Taxonomie-Logik: SPM verantwortet Practices methodisch,
|
||||
SO führt sie für seinen Service aus. Vermeidet Rolleninflation.
|
||||
auswirkung_auf:
|
||||
- dokument: "rolle_service-owner.yaml"
|
||||
abschnitt: "kernaufgaben.problem_management"
|
||||
- dokument: "rolle_service-portfolio-manager.yaml"
|
||||
abschnitt: "practice_ownership"
|
||||
|
||||
- id: "D-02"
|
||||
datum: "2025-12-17"
|
||||
frage: "Wie wird 'End-to-End-Verantwortung' präzisiert?"
|
||||
entscheidung: |
|
||||
"Durchgängige Accountability über den Service-Lifecycle, im Rahmen
|
||||
der definierten Governance-Strukturen."
|
||||
begruendung: |
|
||||
Klarstellung, dass E2E Lifecycle-Kontinuität meint, nicht
|
||||
Entscheidungsautonomie. SO ist an Gates, Eskalationen und
|
||||
Portfolio-Governance gebunden.
|
||||
auswirkung_auf:
|
||||
- dokument: "rolle_service-owner.yaml"
|
||||
abschnitt: "rollenzweck"
|
||||
|
||||
- id: "D-03"
|
||||
datum: "2025-12-17"
|
||||
frage: "Wie wird die generelle Vertretungsregelung formuliert?"
|
||||
entscheidung: |
|
||||
"Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen
|
||||
(Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung
|
||||
delegiert werden."
|
||||
begruendung: |
|
||||
Pragmatische Lösung für MVP. Ableitung aus GOV-TR-013 (Transition-
|
||||
spezifische Vertretung) auf allgemeine Ebene. Als Annahme markiert.
|
||||
status: "ANNAHME"
|
||||
auswirkung_auf:
|
||||
- dokument: "rolle_service-owner.yaml"
|
||||
abschnitt: "organisatorische_einordnung.vertretung"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-REFERENZEN (KONSOLIDIERT)
|
||||
# =============================================================================
|
||||
|
||||
governance_referenzen:
|
||||
|
||||
transition:
|
||||
- "GOV-TR-011: Gate 1 als SOR-Entscheidung (Entry-Autorisierung)"
|
||||
- "GOV-TR-012: Gate 2 als SO-Einzelentscheidung (Entry-Prüfung nach Build)"
|
||||
- "GOV-TR-016: Gate 3 als SOR-Entscheidung (Go-Live-Freigabe)"
|
||||
- "GOV-TR-004: SO-Benennung spätestens bei Gate 1"
|
||||
- "GOV-TR-006: Accountability-Übernahme ab Gate 1"
|
||||
- "GOV-TR-013: Vertretungsregelung (Transition)"
|
||||
- "GOV-TR-021: ELS-Exit als SO-Einzelentscheidung"
|
||||
- "GOV-TR-029: Rollback-Kompetenz während ELS"
|
||||
|
||||
review:
|
||||
- "GOV-SR-001: Quartalsweiser Selbst-Review"
|
||||
- "GOV-SR-002: SPM-Informationspflicht"
|
||||
- "GOV-SR-003: SOR-Einbeziehung bei Auffälligkeiten"
|
||||
- "GOV-SR-005: Improvement-Tracking in der Service-Definition"
|
||||
|
||||
catalog_und_level:
|
||||
- "GOV-001: SLA-Freigabe-Governance"
|
||||
- "GOV-007: SO erstellt Service-Definition"
|
||||
- "GOV-008: Dreistufige Katalog-Änderungs-Governance"
|
||||
- "GOV-012: Integriertes Kundenforum (SO + SHM)"
|
||||
|
||||
change_enablement:
|
||||
- "GOV-CE-001: SO als Change Authority für Normal Changes"
|
||||
- "GOV-CE-003: Cross-Service-Impact-Erkennung"
|
||||
- "GOV-CE-004: Abgrenzung Change vs. Demand"
|
||||
|
||||
support:
|
||||
- "SSM-G-18: SO als Process Owner für Problem Management"
|
||||
- "SSM-G-09: KB-Verantwortung"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-15"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: "Placeholder erstellt mit Gliederungsskelett"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-17"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Vollständige Rollenbeschreibung erstellt:
|
||||
- Konsolidierung aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, etc.)
|
||||
- Integration der Practice-Verantwortlichkeiten (SLM, SCM, CE, SSM)
|
||||
- Dokumentation der Designentscheidungen D-01 bis D-03
|
||||
- Definition der offenen Punkte für MVP
|
||||
- Strukturierung analog SHM-Rollenbeschreibungen
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2026-01-22"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Erweiterung um interne Bedarfe:
|
||||
- Neue Schnittstelle: "DIGIT-Mitarbeiter (interner Bedarf)"
|
||||
- Beschreibung: Empfang interner Bedarfe für eigenen Service
|
||||
- Change-Qualifizierung: SO entscheidet Change vs. Demand
|
||||
- Verweis auf SHM Fast Track Routing
|
||||
- Rückverweis an SHM/DPM bei Demand-Charakter
|
||||
quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe"
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,657 @@
|
|||
# =============================================================================
|
||||
# SCHEMA: SERVICE-STECKBRIEF
|
||||
# =============================================================================
|
||||
#
|
||||
# Dieses Schema definiert die Struktur eines Service-Steckbriefs.
|
||||
# Der Service-Steckbrief ist die kundenorientierte Darstellung eines Services
|
||||
# im Service-Katalog – ein Auszug aus der Service-Definition.
|
||||
#
|
||||
# Abgrenzung:
|
||||
# - Service-Definition = internes Master-Dokument (spm_schema_service-definition.yaml)
|
||||
# - Service-Steckbrief = kundenorientierter Auszug (dieses Schema)
|
||||
#
|
||||
# Prinzip:
|
||||
# - Der Steckbrief enthält NUR Informationen, die für Kunden relevant sind
|
||||
# - Technische Details, interne Prozesse und Kostenstrukturen werden ausgeblendet
|
||||
# - Die Sprache ist bewusst nicht-technisch und verständlich
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
schema:
|
||||
name: "Service-Steckbrief"
|
||||
version: "0.3"
|
||||
status: "draft"
|
||||
erstellt: "2025-11-27"
|
||||
geaendert: "2026-01-31"
|
||||
projekt: "DIGITOM"
|
||||
|
||||
beschreibung: >
|
||||
Der Service-Steckbrief ist die offizielle, kundenorientierte Beschreibung
|
||||
eines Services im Service-Katalog. Er beantwortet die Fragen, die Ämter
|
||||
und Mitarbeitende typischerweise haben: Was ist der Service? Was bekomme
|
||||
ich? Was bekomme ich nicht? Wie gut ist er? Wie beantrage ich ihn?
|
||||
|
||||
ableitung_von: "spm_schema_service-definition.yaml"
|
||||
|
||||
verantwortung:
|
||||
inhalt: "Service Owner (liefert)"
|
||||
qualitaetssicherung: "Service-Portfolio-Manager (prüft Konsistenz und Verständlichkeit)"
|
||||
freigabe: "Service-Portfolio-Manager"
|
||||
publikation: "Service-Portfolio-Manager"
|
||||
|
||||
zielgruppe:
|
||||
primaer: "Mitarbeitende der Stadtverwaltung (Nutzer)"
|
||||
sekundaer: "Amtsleitungen und deren Delegierte (Kunden/Entscheider)"
|
||||
|
||||
publikationsort:
|
||||
beschreibung: >
|
||||
Der Service-Steckbrief wird im Service-Katalog publiziert.
|
||||
Der konkrete Publikationskanal (Intranet, Self-Service-Portal)
|
||||
ist implementierungsabhängig.
|
||||
anforderung: "Barrierefreier, durchsuchbarer Zugang für alle Zielgruppen"
|
||||
|
||||
# =============================================================================
|
||||
# ATTRIBUT-DEFINITIONEN
|
||||
# =============================================================================
|
||||
|
||||
attribute:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# IDENTIFIKATION
|
||||
# ---------------------------------------------------------------------------
|
||||
identifikation:
|
||||
beschreibung: "Eindeutige Identifikation und Grundinformationen"
|
||||
|
||||
attribute:
|
||||
- name: "service_id"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Eindeutiger Identifier (aus Service-Definition übernommen)"
|
||||
quelle: "service-definition.metadaten.service_id"
|
||||
sichtbarkeit: "Kann angezeigt werden, primär für Referenzzwecke"
|
||||
|
||||
- name: "service_name"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Offizieller Name des Services"
|
||||
quelle: "service-definition.identitaet.service_name"
|
||||
beispiel: "Digitaler Arbeitsplatz"
|
||||
|
||||
- name: "service_name_kurz"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "Kurzbezeichnung oder Akronym (falls gebräuchlich)"
|
||||
quelle: "service-definition.identitaet.service_name_kurz"
|
||||
beispiel: "DAP"
|
||||
|
||||
- name: "version"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Version des Steckbriefs"
|
||||
quelle: "service-definition.metadaten.version"
|
||||
|
||||
- name: "stand"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "Datum der letzten Aktualisierung"
|
||||
quelle: "service-definition.metadaten.geaendert_am"
|
||||
anzeige_format: "TT.MM.JJJJ"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ÜBERBLICK
|
||||
# ---------------------------------------------------------------------------
|
||||
ueberblick:
|
||||
beschreibung: "Schnelle Orientierung: Was ist das? Für wen?"
|
||||
|
||||
attribute:
|
||||
- name: "kurzbeschreibung"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Einzeilige Beschreibung (max. 200 Zeichen)"
|
||||
quelle: "service-definition.identitaet.kurzbeschreibung"
|
||||
hinweis: "Soll auch ohne Kontext verständlich sein"
|
||||
beispiel: "Standardisierter PC-Arbeitsplatz mit Office-Anwendungen und E-Mail für alle Mitarbeitenden"
|
||||
|
||||
- name: "nutzen"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
beschreibung: >
|
||||
Was bringt mir dieser Service? Welches Problem löst er?
|
||||
Formulierung aus Kundenperspektive, nicht aus IT-Sicht.
|
||||
quelle: "service-definition.identitaet.zweck"
|
||||
transformation: "Ggf. Umformulierung in kundenorientierte Sprache"
|
||||
beispiel: >
|
||||
Mit dem Digitalen Arbeitsplatz können Sie Ihre täglichen
|
||||
Büroaufgaben erledigen: E-Mails schreiben, Dokumente erstellen,
|
||||
an Videokonferenzen teilnehmen und auf zentrale Anwendungen zugreifen.
|
||||
|
||||
- name: "zielgruppe"
|
||||
typ: "list[string]"
|
||||
pflicht: true
|
||||
beschreibung: "Für wen ist dieser Service gedacht?"
|
||||
quelle: "service-definition.identitaet.zielgruppe"
|
||||
beispiel:
|
||||
- "Alle Mitarbeitenden der Stadtverwaltung"
|
||||
|
||||
- name: "service_kategorie"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
beschreibung: "Art des Services (beeinflusst Verfügbarkeit und Beantragung)"
|
||||
quelle: "service-definition.identitaet.service_kategorie"
|
||||
schema:
|
||||
- name: "kategorie_id"
|
||||
typ: "enum"
|
||||
werte: ["A", "B", "C"]
|
||||
- name: "kategorie_bezeichnung"
|
||||
typ: "string"
|
||||
beschreibung: "Kundenfreundliche Bezeichnung"
|
||||
mapping:
|
||||
A: "Basis-Service (für alle Mitarbeitenden)"
|
||||
B: "Erweiterungs-Service (optional buchbar)"
|
||||
C: "Spezial-Service (für bestimmte Ämter)"
|
||||
- name: "hinweis"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "Zusatzinformation zur Kategorie"
|
||||
beispiel_c: "Dieser Service ist exklusiv für das Amt für Soziales verfügbar."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# LEISTUNGSUMFANG
|
||||
# ---------------------------------------------------------------------------
|
||||
leistungsumfang:
|
||||
beschreibung: "Was bekomme ich? Was bekomme ich nicht?"
|
||||
|
||||
attribute:
|
||||
- name: "das_ist_enthalten"
|
||||
typ: "list[string]"
|
||||
pflicht: true
|
||||
beschreibung: "Konkrete Leistungen, die im Service enthalten sind"
|
||||
quelle: "service-definition.leistungsumfang.leistungen_inkludiert"
|
||||
hinweis: "Kundenverständlich formulieren, keine technischen Details"
|
||||
beispiel:
|
||||
- "Windows-PC oder Laptop"
|
||||
- "Microsoft Office (Word, Excel, PowerPoint, Outlook)"
|
||||
- "E-Mail-Postfach mit 5 GB Speicher"
|
||||
- "Zugang zum städtischen Netzwerk"
|
||||
- "Standarddrucker in Ihrem Gebäude"
|
||||
|
||||
- name: "das_ist_nicht_enthalten"
|
||||
typ: "list[string]"
|
||||
pflicht: true
|
||||
beschreibung: "Explizit nicht enthaltene Leistungen"
|
||||
quelle: "service-definition.leistungsumfang.leistungen_exkludiert"
|
||||
hinweis: "Vermeidet Missverständnisse und Enttäuschungen"
|
||||
beispiel:
|
||||
- "Spezialsoftware (z.B. CAD, Statistik) – siehe Erweiterungs-Services"
|
||||
- "Diensthandy – siehe Service 'Mobile Endgeräte'"
|
||||
- "Individuelle Software-Installationen"
|
||||
|
||||
- name: "voraussetzungen"
|
||||
typ: "list[string]"
|
||||
pflicht: false
|
||||
beschreibung: "Was muss gegeben sein, damit ich den Service nutzen kann?"
|
||||
quelle: "service-definition.leistungsumfang.voraussetzungen"
|
||||
beispiel:
|
||||
- "Gültiger Benutzeraccount (wird bei Dienstantritt automatisch erstellt)"
|
||||
- "Abgeschlossene IT-Sicherheitsunterweisung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SERVICEQUALITÄT
|
||||
# ---------------------------------------------------------------------------
|
||||
servicequalitaet:
|
||||
beschreibung: "Wie gut ist der Service? Wann ist er verfügbar?"
|
||||
|
||||
attribute:
|
||||
- name: "verfuegbarkeit"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
beschreibung: "Wann kann ich den Service nutzen?"
|
||||
quelle: "service-definition.qualitaet.verfuegbarkeit"
|
||||
schema:
|
||||
- name: "servicezeit"
|
||||
typ: "string"
|
||||
beschreibung: "Wann ist der Service verfügbar?"
|
||||
beispiel: "Montag bis Freitag, 6:00 bis 22:00 Uhr; Samstag 8:00 bis 14:00 Uhr"
|
||||
- name: "wartungsfenster"
|
||||
typ: "string"
|
||||
beschreibung: "Wann finden geplante Wartungen statt?"
|
||||
beispiel: "Sonntags zwischen 2:00 und 6:00 Uhr (der Service kann in dieser Zeit eingeschränkt sein)"
|
||||
|
||||
- name: "service_level_dokument"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
beschreibung: >
|
||||
Verweis auf die detaillierten Qualitätszusagen.
|
||||
Die Struktur unterscheidet sich je nach Service-Kategorie.
|
||||
quelle: "service-definition.qualitaet.service_level_referenz"
|
||||
schema:
|
||||
- name: "typ"
|
||||
typ: "enum"
|
||||
werte:
|
||||
- id: "SLS"
|
||||
anzeige: "Service Level Specification"
|
||||
beschreibung: "Detaillierte Qualitätsbeschreibung für diesen Service"
|
||||
- id: "SLA_integriert"
|
||||
anzeige: "Individuelle Vereinbarung"
|
||||
beschreibung: "Die Qualitätszusagen sind Teil der bilateralen Vereinbarung mit Ihrem Amt"
|
||||
- name: "dokument_titel"
|
||||
typ: "string"
|
||||
beschreibung: "Titel des referenzierten Dokuments"
|
||||
- name: "dokument_link"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "Link zum Dokument (falls öffentlich zugänglich)"
|
||||
- name: "hinweis"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beispiel_c: "Für Details wenden Sie sich an Ihre Amtsleitung oder den Service Owner."
|
||||
|
||||
- name: "qualitaets_highlights"
|
||||
typ: "list[string]"
|
||||
pflicht: false
|
||||
beschreibung: >
|
||||
Ausgewählte, kundenrelevante Qualitätsmerkmale aus der SLS.
|
||||
Keine vollständige Liste, sondern die wichtigsten Punkte.
|
||||
transformation: "Extraktion aus SLS, kundenverständlich formuliert"
|
||||
beispiel:
|
||||
- "Verfügbarkeit: 99,5% während der Servicezeiten"
|
||||
- "Bei Störungen: Reaktion innerhalb von 4 Stunden"
|
||||
- "Geplante Wartungen werden mindestens 3 Tage vorher angekündigt"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SUPPORT & KONTAKT
|
||||
# ---------------------------------------------------------------------------
|
||||
support:
|
||||
beschreibung: "Wie bekomme ich Hilfe? An wen wende ich mich?"
|
||||
|
||||
attribute:
|
||||
- name: "supportzeiten"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Wann ist der Support erreichbar?"
|
||||
quelle: "service-definition.qualitaet.verfuegbarkeit.supportzeit"
|
||||
beispiel: "Montag bis Freitag, 8:00 bis 17:00 Uhr"
|
||||
|
||||
- name: "kontaktwege"
|
||||
typ: "list[objekt]"
|
||||
pflicht: true
|
||||
beschreibung: "Wie erreiche ich den Support?"
|
||||
schema:
|
||||
- name: "kanal"
|
||||
typ: "string"
|
||||
beispiele: ["Telefon", "E-Mail", "Self-Service-Portal", "Vor Ort"]
|
||||
- name: "details"
|
||||
typ: "string"
|
||||
beispiele:
|
||||
- "0761 / 201-XXXX"
|
||||
- "servicedesk@digit.freiburg.de"
|
||||
- "https://selfservice.digit.freiburg.de"
|
||||
- name: "hinweis"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beispiel: "Für schnelle Hilfe bei Störungen"
|
||||
|
||||
- name: "service_owner_kontakt"
|
||||
typ: "objekt"
|
||||
pflicht: true
|
||||
beschreibung: "Ansprechperson für grundsätzliche Fragen zum Service"
|
||||
quelle: "service-definition.verantwortlichkeiten.service_owner"
|
||||
schema:
|
||||
- name: "name"
|
||||
typ: "string"
|
||||
quelle: "service_owner.person_name"
|
||||
- name: "rolle"
|
||||
typ: "string"
|
||||
wert: "Service Owner"
|
||||
- name: "kontakt"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "E-Mail (nur wenn explizit freigegeben)"
|
||||
hinweis: >
|
||||
Im Regelfall sollten Anfragen über den Service Desk laufen.
|
||||
Der direkte Kontakt zum SO ist für strategische Fragen
|
||||
und Amtsleitungen gedacht.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# BEANTRAGUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
beantragung:
|
||||
beschreibung: "Wie bekomme ich den Service?"
|
||||
|
||||
attribute:
|
||||
- name: "beantragungswege"
|
||||
typ: "list[objekt]"
|
||||
pflicht: true
|
||||
beschreibung: "Wie kann ich den Service anfordern?"
|
||||
quelle: "service-definition.betriebsmodell.request_wege"
|
||||
schema:
|
||||
- name: "weg"
|
||||
typ: "string"
|
||||
beispiele:
|
||||
- "Self-Service-Portal"
|
||||
- "Service Desk"
|
||||
- "Über Ihre Amtsleitung"
|
||||
- name: "link"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
- name: "hinweis"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beispiel: "Für Basis-Services ist keine Beantragung nötig – Sie erhalten den Service automatisch."
|
||||
|
||||
- name: "berechtigungslogik"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Wer darf den Service beantragen/nutzen?"
|
||||
transformation: "Ableitung aus service_kategorie und zielgruppe"
|
||||
beispiele:
|
||||
kategorie_a: "Alle Mitarbeitenden erhalten diesen Service automatisch bei Dienstantritt."
|
||||
kategorie_b: "Die Beantragung erfolgt über Ihre Amtsleitung. Es können Kosten für Ihr Amt entstehen."
|
||||
kategorie_c: "Dieser Service ist nur für berechtigte Ämter verfügbar. Bei Interesse wenden Sie sich an den Service Owner."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DATENSCHUTZ & HINWEISE
|
||||
# ---------------------------------------------------------------------------
|
||||
hinweise:
|
||||
beschreibung: "Wichtige Hinweise für Nutzer"
|
||||
|
||||
attribute:
|
||||
- name: "datenschutz_hinweis"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
beschreibung: "Kundenverständlicher Hinweis zum Datenschutz"
|
||||
quelle: "service-definition.compliance.datenschutz_klassifikation"
|
||||
transformation:
|
||||
keine_pbD: "In diesem Service werden keine personenbezogenen Daten verarbeitet."
|
||||
pbD_normal: "In diesem Service werden personenbezogene Daten verarbeitet. Die Verarbeitung erfolgt gemäß DSGVO und LDSG BW."
|
||||
pbD_hoch: "In diesem Service werden sensible personenbezogene Daten verarbeitet. Bitte beachten Sie die besonderen Schutzmaßnahmen in der Nutzungsanleitung."
|
||||
besondere_kategorien: "In diesem Service werden besonders schützenswerte Daten verarbeitet (z.B. Gesundheitsdaten). Die Nutzung erfordert besondere Sorgfalt. Details finden Sie in der Datenschutzdokumentation."
|
||||
|
||||
- name: "wichtige_hinweise"
|
||||
typ: "list[string]"
|
||||
pflicht: false
|
||||
beschreibung: "Sonstige wichtige Hinweise für Nutzer"
|
||||
beispiel:
|
||||
- "Bitte melden Sie sich am Ende des Arbeitstages ab, um Sicherheitsrisiken zu vermeiden."
|
||||
- "Private Nutzung ist nur im Rahmen der IT-Nutzungsrichtlinie gestattet."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# WEITERFÜHRENDE INFORMATIONEN
|
||||
# ---------------------------------------------------------------------------
|
||||
weiterführend:
|
||||
beschreibung: "Links zu weiteren Dokumenten und Ressourcen"
|
||||
|
||||
attribute:
|
||||
- name: "dokumente"
|
||||
typ: "list[objekt]"
|
||||
pflicht: false
|
||||
beschreibung: "Für Kunden relevante Dokumente"
|
||||
quelle: "service-definition.dokumentation.dokumente (gefiltert)"
|
||||
filter: "Nur Dokumente mit typ in ['sls', 'benutzerhandbuch', 'faq', 'schulungsunterlage']"
|
||||
schema:
|
||||
- name: "titel"
|
||||
typ: "string"
|
||||
- name: "typ"
|
||||
typ: "enum"
|
||||
werte:
|
||||
- id: "sls"
|
||||
anzeige: "Qualitätsbeschreibung"
|
||||
- id: "benutzerhandbuch"
|
||||
anzeige: "Benutzerhandbuch"
|
||||
- id: "faq"
|
||||
anzeige: "Häufige Fragen"
|
||||
- id: "schulungsunterlage"
|
||||
anzeige: "Schulungsmaterial"
|
||||
- name: "link"
|
||||
typ: "string"
|
||||
|
||||
- name: "verwandte_services"
|
||||
typ: "list[objekt]"
|
||||
pflicht: false
|
||||
beschreibung: "Services, die für Nutzer dieses Services relevant sein könnten"
|
||||
schema:
|
||||
- name: "service_id"
|
||||
typ: "string"
|
||||
- name: "service_name"
|
||||
typ: "string"
|
||||
- name: "beziehung"
|
||||
typ: "string"
|
||||
beispiele:
|
||||
- "Ergänzend verfügbar"
|
||||
- "Alternative für spezielle Anforderungen"
|
||||
- "Wird für diesen Service benötigt"
|
||||
|
||||
# =============================================================================
|
||||
# DARSTELLUNGSVARIANTEN (VIEWS)
|
||||
# =============================================================================
|
||||
|
||||
views:
|
||||
beschreibung: >
|
||||
Der Service-Steckbrief kann in verschiedenen Kontexten unterschiedlich
|
||||
dargestellt werden. Die Views definieren, welche Attribute in welchem
|
||||
Kontext angezeigt werden.
|
||||
|
||||
varianten:
|
||||
- name: "katalog_uebersicht"
|
||||
beschreibung: "Listenansicht im Service-Katalog"
|
||||
anzeige:
|
||||
- service_name
|
||||
- kurzbeschreibung
|
||||
- service_kategorie.kategorie_bezeichnung
|
||||
- zielgruppe (gekürzt)
|
||||
|
||||
- name: "katalog_detail"
|
||||
beschreibung: "Vollständige Detailansicht eines Services"
|
||||
anzeige: "Alle Attribute"
|
||||
|
||||
- name: "request_katalog"
|
||||
beschreibung: "Ansicht im ITSM-Tool für Service-Anfragen"
|
||||
anzeige:
|
||||
- service_name
|
||||
- kurzbeschreibung
|
||||
- das_ist_enthalten
|
||||
- das_ist_nicht_enthalten
|
||||
- beantragungswege
|
||||
- kontaktwege
|
||||
hinweis: >
|
||||
Diese View wird für die Integration mit dem ITSM-Tool benötigt.
|
||||
Die konkrete Implementierung hängt vom gewählten Tool ab.
|
||||
|
||||
- name: "entscheider_view"
|
||||
beschreibung: "Ansicht für Amtsleitungen (Steuerungsperspektive)"
|
||||
anzeige:
|
||||
- service_name
|
||||
- kurzbeschreibung
|
||||
- service_kategorie
|
||||
- service_level_dokument
|
||||
- service_owner_kontakt
|
||||
- berechtigungslogik
|
||||
zusaetzlich:
|
||||
- sla_referenz: "Link zum vollständigen SLA (falls vorhanden)"
|
||||
|
||||
# =============================================================================
|
||||
# VALIDIERUNGSREGELN
|
||||
# =============================================================================
|
||||
|
||||
validierung:
|
||||
|
||||
regeln:
|
||||
- id: "VAL-STB-001"
|
||||
beschreibung: "Kurzbeschreibung muss ohne Kontext verständlich sein"
|
||||
typ: "qualitativ"
|
||||
pruefung: "Review durch SHM oder SPM"
|
||||
|
||||
- id: "VAL-STB-002"
|
||||
beschreibung: "Keine technischen Fachbegriffe ohne Erklärung"
|
||||
typ: "qualitativ"
|
||||
pruefung: "Review durch SHM"
|
||||
|
||||
- id: "VAL-STB-003"
|
||||
beschreibung: "Mindestens ein Kontaktweg muss angegeben sein"
|
||||
typ: "formal"
|
||||
regel: "kontaktwege.length >= 1"
|
||||
|
||||
- id: "VAL-STB-004"
|
||||
beschreibung: "Bei Kategorie B/C muss Berechtigungslogik ausgefüllt sein"
|
||||
typ: "formal"
|
||||
regel: >
|
||||
Wenn service_kategorie in ['B', 'C'],
|
||||
dann berechtigungslogik darf nicht leer sein.
|
||||
|
||||
- id: "VAL-STB-005"
|
||||
beschreibung: "Service-Level-Dokument muss referenziert sein"
|
||||
typ: "formal"
|
||||
regel: "service_level_dokument.typ ist gesetzt"
|
||||
|
||||
qualitaetskriterien:
|
||||
beschreibung: >
|
||||
Qualitative Kriterien, die vor Publikation geprüft werden sollten.
|
||||
Verantwortung: SPM in Abstimmung mit SHM.
|
||||
|
||||
kriterien:
|
||||
- "Verständlichkeit: Ein fachfremder Mitarbeitender versteht den Steckbrief"
|
||||
- "Vollständigkeit: Alle Pflichtfelder sind ausgefüllt"
|
||||
- "Konsistenz: Informationen widersprechen nicht der Service-Definition"
|
||||
- "Aktualität: Informationen entsprechen dem aktuellen Stand"
|
||||
- "Barrierefreiheit: Texte sind in einfacher Sprache verfasst"
|
||||
|
||||
# =============================================================================
|
||||
# PFLEGEPROZESS
|
||||
# =============================================================================
|
||||
|
||||
pflege:
|
||||
|
||||
trigger:
|
||||
beschreibung: "Wann muss der Steckbrief aktualisiert werden?"
|
||||
ereignisse:
|
||||
- trigger: "Änderung der Service-Definition"
|
||||
aktion: "Prüfen, ob Steckbrief betroffen"
|
||||
verantwortung: "Service Owner"
|
||||
|
||||
- trigger: "SLS/SLA-Änderung"
|
||||
aktion: "Qualitäts-Highlights und Referenzen aktualisieren"
|
||||
verantwortung: "Service Owner"
|
||||
|
||||
- trigger: "Änderung Kontaktdaten"
|
||||
aktion: "Support-Abschnitt aktualisieren"
|
||||
verantwortung: "Service Owner"
|
||||
|
||||
- trigger: "Jährlicher Katalog-Review"
|
||||
aktion: "Vollständige Prüfung aller Steckbriefe"
|
||||
verantwortung: "SPM"
|
||||
|
||||
aenderungstypen:
|
||||
beschreibung: "Klassifikation von Änderungen für Governance-Routing"
|
||||
|
||||
typen:
|
||||
- typ: "redaktionell"
|
||||
beispiele:
|
||||
- "Korrektur Tippfehler"
|
||||
- "Aktualisierung Telefonnummer"
|
||||
- "Umformulierung ohne inhaltliche Änderung"
|
||||
entscheidung: "Service Owner (autonom)"
|
||||
publikation: "sofort"
|
||||
|
||||
- typ: "inhaltlich_minor"
|
||||
beispiele:
|
||||
- "Ergänzung FAQ-Link"
|
||||
- "Klarstellung Leistungsumfang (ohne Änderung)"
|
||||
- "Hinzufügen verwandter Service"
|
||||
entscheidung: "Service Owner + SPM (bilateral)"
|
||||
publikation: "nach Freigabe SPM"
|
||||
|
||||
- typ: "inhaltlich_major"
|
||||
beispiele:
|
||||
- "Änderung Leistungsumfang"
|
||||
- "Neue/geänderte Service Levels"
|
||||
- "Änderung Zielgruppe"
|
||||
entscheidung: "SOR"
|
||||
publikation: "nach SOR-Freigabe"
|
||||
hinweis: "Meist gekoppelt an Änderung der Service-Definition"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLE ZU ITSM-TOOL
|
||||
# =============================================================================
|
||||
|
||||
itsm_integration:
|
||||
beschreibung: >
|
||||
Der Service-Steckbrief dient als Stammdatenquelle für den Request-Katalog
|
||||
im ITSM-Tool. Diese Sektion definiert die Anforderungen an die Integration.
|
||||
|
||||
status: "Anforderungsdefinition (Tool noch nicht final)"
|
||||
|
||||
anforderungen:
|
||||
- id: "ITSM-REQ-001"
|
||||
beschreibung: "Service-ID muss als eindeutiger Schlüssel dienen"
|
||||
|
||||
- id: "ITSM-REQ-002"
|
||||
beschreibung: "Beantragungswege müssen in Request-Formulare überführbar sein"
|
||||
|
||||
- id: "ITSM-REQ-003"
|
||||
beschreibung: "Änderungen am Steckbrief müssen in das ITSM-Tool synchronisiert werden"
|
||||
hinweis: "Richtung: SCM → ITSM (unidirektional)"
|
||||
|
||||
- id: "ITSM-REQ-004"
|
||||
beschreibung: "Kategorie-basierte Sichtbarkeitssteuerung muss möglich sein"
|
||||
detail: >
|
||||
Kategorie A: Für alle sichtbar
|
||||
Kategorie B: Für alle sichtbar, Beantragung eingeschränkt
|
||||
Kategorie C: Nur für berechtigte Ämter sichtbar
|
||||
|
||||
datenhoheit: "SCM (Service-Steckbrief ist führend)"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
- id: "OPEN-STB-001"
|
||||
beschreibung: "Template für Service-Steckbrief erstellen (Markdown/HTML)"
|
||||
prioritaet: "hoch"
|
||||
ziel_ordner: "02.6_arbeitsmaterialien"
|
||||
|
||||
- id: "OPEN-STB-002"
|
||||
beschreibung: "Abstimmung mit SHM: Qualitätskriterien für Verständlichkeit"
|
||||
prioritaet: "mittel"
|
||||
abhaengig_von: "Finalisierung SHM-Rollenbeschreibung"
|
||||
|
||||
- id: "OPEN-STB-003"
|
||||
beschreibung: "ITSM-Tool-Auswahl: Konkrete Mapping-Spezifikation"
|
||||
prioritaet: "niedrig"
|
||||
status: "Wartet auf Tool-Entscheidung"
|
||||
|
||||
- id: "OPEN-STB-004"
|
||||
beschreibung: "Barrierefreiheit: Prüfung gegen BITV 2.0"
|
||||
prioritaet: "mittel"
|
||||
hinweis: "Relevant für Publikationsformat"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-11-27"
|
||||
aenderung: "Initiale Version erstellt"
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
||||
- version: "0.2"
|
||||
datum: "2025-12-17"
|
||||
aenderung: |
|
||||
- Neuer Abschnitt 'review_status' fuer Service-Review-Ergebnisse (GOV-SR-001)
|
||||
- Neuer Abschnitt 'laufende_verbesserungen' fuer Improvement-Tracking (GOV-SR-005)
|
||||
- Neuer Pflege-Trigger fuer quartalsweisen Service-Review
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "konzept_service-review.yaml"
|
||||
|
||||
- version: "0.3"
|
||||
datum: "2026-01-31"
|
||||
aenderung: |
|
||||
- Abschnitt 'review_status' entfernt (verschoben nach Service-Definition)
|
||||
- Abschnitt 'laufende_verbesserungen' entfernt (verschoben nach Service-Definition)
|
||||
- Pflege-Trigger fuer quartalsweisen Service-Review entfernt
|
||||
- Begruendung: Review- und Improvement-Informationen sind interne Steuerungsdaten,
|
||||
nicht kundenrelevant. Sie gehoeren in die Service-Definition (Single Source of Truth),
|
||||
nicht in den kundenorientierten Service-Steckbrief.
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht"
|
||||
|
|
@ -0,0 +1,633 @@
|
|||
# =============================================================================
|
||||
# SCHEMA: TRANSITION-STECKBRIEF
|
||||
# =============================================================================
|
||||
# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/
|
||||
# Dateiname: spm_schema_transition-steckbrief.yaml
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SCHEMA-TR-STECKBRIEF"
|
||||
name: "Schema Transition-Steckbrief"
|
||||
version: "0.3"
|
||||
status: "draft"
|
||||
erstellt: "2025-12-17"
|
||||
aktualisiert: "2026-02-18"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
dokumenttyp: "schema"
|
||||
|
||||
beschreibung: |
|
||||
Schema-Definition für den Transition-Steckbrief. Der Transition-
|
||||
Steckbrief ist ein temporäres Prozessdokument, das die Service
|
||||
Transition von Gate 1 (tr_01, Entry-Gate) bis zum ELS-Exit dokumentiert.
|
||||
|
||||
Nach Abschluss wird er als Anhang in den Service-Steckbrief überführt.
|
||||
|
||||
Hinweis zur Gate-Nummerierung: Gate 1 (tr_01) ist das Entry-Gate der
|
||||
Transition-Phase. Gate 2 (tr_09) ist die Entry-Prüfung nach Build,
|
||||
Gate 3 (tr_12) ist die Go-Live-Freigabe. Alle drei Gates gehören zur
|
||||
Transition-Phase und werden im Transition-Steckbrief dokumentiert.
|
||||
|
||||
mvp_hinweis: |
|
||||
Dieses Schema folgt dem MVP-Ansatz: Minimale Pflichtfelder,
|
||||
Freitext wo sinnvoll, keine Über-Strukturierung. Erweiterungen
|
||||
basierend auf operativer Erfahrung sind explizit vorgesehen.
|
||||
|
||||
referenzen:
|
||||
governance:
|
||||
- "GOV-TR-018: Einführung Transition-Steckbrief"
|
||||
- "GOV-TR-019: Überführung in Service-Steckbrief"
|
||||
- "GOV-TR-020: Begriffliches Mapping"
|
||||
konzept: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
|
||||
verwandtes_schema: "spm_schema_service-steckbrief.yaml"
|
||||
arbeitspakete:
|
||||
- "AP-01: Gate-Struktur"
|
||||
- "AP-02: Entscheidungskriterien"
|
||||
- "AP-03: Governance-Verfahren"
|
||||
- "AP-04: ELS-Konzept"
|
||||
- "AP-05: Rollback-Szenarien"
|
||||
|
||||
# =============================================================================
|
||||
# SCHEMA-DEFINITION
|
||||
# =============================================================================
|
||||
|
||||
schema:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HEADER
|
||||
# ---------------------------------------------------------------------------
|
||||
header:
|
||||
beschreibung: "Identifikation und Statusverfolgung"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "id"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Eindeutige ID des Transition-Steckbriefs"
|
||||
format: "TR-[SERVICE-ID]-[YYYY]"
|
||||
beispiel: "TR-SVC-001-2025"
|
||||
|
||||
- name: "service_referenz"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "ID des zugehörigen Service-Steckbriefs"
|
||||
beispiel: "SVC-001"
|
||||
|
||||
- name: "service_name"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Name des Services (für Lesbarkeit)"
|
||||
beispiel: "Dokumentenmanagement-System"
|
||||
|
||||
- name: "transition_typ"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Art der Transition"
|
||||
werte:
|
||||
- "neuer_service"
|
||||
- "wesentliche_aenderung"
|
||||
mvp_hinweis: "Für MVP nur diese zwei Typen. Differenzierung nach Service-Kategorie kann später ergänzt werden."
|
||||
|
||||
- name: "status"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Aktueller Status im Transition-Prozess"
|
||||
werte:
|
||||
- "angelegt"
|
||||
- "gate_2_offen"
|
||||
- "gate_2_passiert"
|
||||
- "pilot_aktiv"
|
||||
- "gate_3_offen"
|
||||
- "go_live"
|
||||
- "els_aktiv"
|
||||
- "abgeschlossen"
|
||||
- "abgebrochen"
|
||||
|
||||
- name: "transition_start"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "Datum des Gate-1-Eintritts (tr_01) in die Transition-Phase"
|
||||
|
||||
- name: "transition_ende"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "Datum des ELS-Exit (bei Abschluss)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GATE 2: ENTRY-PRÜFUNG NACH BUILD
|
||||
# ---------------------------------------------------------------------------
|
||||
gate_2:
|
||||
beschreibung: "Dokumentation der Entry-Prüfung nach Build (Gate-Keeper: Service Owner)"
|
||||
lifecycle_aktivitaet: "tr_09"
|
||||
referenz: "AP-01, AP-02"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "datum"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "Datum der Gate-2-Entscheidung"
|
||||
|
||||
- name: "entscheidung"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Ergebnis der Gate-2-Prüfung"
|
||||
werte:
|
||||
- "freigabe"
|
||||
- "freigabe_mit_auflagen"
|
||||
- "zurueckweisung"
|
||||
- "eskalation_an_sor"
|
||||
|
||||
# --- Prüfdimensionen ---
|
||||
- name: "pruefung_uebergabe_vollstaendigkeit"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Liegen alle Artefakte aus der Build-Phase vor? (Showstopper)"
|
||||
werte:
|
||||
- "erfuellt"
|
||||
- "nicht_erfuellt"
|
||||
referenz: "AP-02, G2-DIM-01"
|
||||
|
||||
- name: "pruefung_betriebsvorbereitung"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Sind Betrieb und Support informiert/vorbereitet?"
|
||||
werte:
|
||||
- "erfuellt"
|
||||
- "mit_auflagen"
|
||||
- "nicht_erfuellt"
|
||||
referenz: "AP-02, G2-DIM-02"
|
||||
|
||||
# --- Pilot-Entscheidung ---
|
||||
- name: "pilot_erforderlich"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Ist ein Pilot vor Go-Live erforderlich?"
|
||||
referenz: "AP-01, Pilot-Konzept"
|
||||
|
||||
- name: "pilot_begruendung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Begründung für Pilot-Entscheidung (bei ja oder bei bewusstem Verzicht)"
|
||||
max_zeichen: 500
|
||||
|
||||
# --- Auflagen ---
|
||||
- name: "auflagen"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Auflagen bei 'freigabe_mit_auflagen' (Beschreibung, Frist, Verantwortlicher)"
|
||||
hinweis: "Freitext für MVP. Strukturierte Auflagen-Liste kann später ergänzt werden."
|
||||
|
||||
# --- Begründung ---
|
||||
- name: "begruendung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Begründung bei Zurückweisung oder Eskalation"
|
||||
max_zeichen: 500
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# PILOT (optional)
|
||||
# ---------------------------------------------------------------------------
|
||||
pilot:
|
||||
beschreibung: "Dokumentation der Pilot-Phase (nur wenn pilot_erforderlich = true)"
|
||||
referenz: "AP-01, Teil C"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "status"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Status der Pilot-Phase"
|
||||
werte:
|
||||
- "nicht_erforderlich"
|
||||
- "geplant"
|
||||
- "aktiv"
|
||||
- "erfolgreich_abgeschlossen"
|
||||
- "mit_einschraenkungen_abgeschlossen"
|
||||
- "abgebrochen"
|
||||
|
||||
- name: "start_datum"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "Start der Pilot-Phase"
|
||||
|
||||
- name: "ende_datum"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "Ende der Pilot-Phase"
|
||||
|
||||
- name: "scope"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Pilot-Scope (Nutzergruppe, Funktionsumfang)"
|
||||
max_zeichen: 300
|
||||
mvp_hinweis: "Freitext für MVP. Strukturierte Scope-Definition kann später ergänzt werden."
|
||||
|
||||
- name: "ergebnis_zusammenfassung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Zusammenfassung der Pilot-Ergebnisse"
|
||||
max_zeichen: 500
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GATE 3: GO-LIVE-FREIGABE
|
||||
# ---------------------------------------------------------------------------
|
||||
gate_3:
|
||||
beschreibung: "Dokumentation der Go-Live-Freigabe (Gate-Keeper: SOR)"
|
||||
lifecycle_aktivitaet: "tr_12"
|
||||
referenz: "AP-01, AP-02, AP-03"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "datum"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "Datum der SOR-Sitzung mit Gate-2-Entscheidung"
|
||||
|
||||
- name: "sor_protokoll_referenz"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Referenz auf das SOR-Protokoll"
|
||||
beispiel: "SOR-2025-03-15"
|
||||
|
||||
- name: "entscheidung"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Ergebnis der Gate-3-Prüfung"
|
||||
werte:
|
||||
- "go_live"
|
||||
- "go_live_mit_auflagen"
|
||||
- "zurueck_an_transition"
|
||||
- "ablehnung"
|
||||
|
||||
# --- Prüfdimensionen ---
|
||||
- name: "pruefung_so_readiness"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Hat SO die Betriebsreife bestätigt? (Showstopper)"
|
||||
referenz: "AP-02, G3-DIM-01"
|
||||
|
||||
- name: "pruefung_dokumentation"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Ist Dokumentation vorhanden UND implementiert? (Showstopper)"
|
||||
referenz: "AP-02, G3-DIM-02"
|
||||
|
||||
- name: "pruefung_portfolio_passung"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Kein Widerspruch zu bestehenden Services? (Showstopper)"
|
||||
referenz: "AP-02, G3-DIM-03"
|
||||
|
||||
- name: "pruefung_ressourcen_commitment"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: |
|
||||
Haben Betrieb und Support die OPERATIVE Übernahme für den
|
||||
Go-Live-Termin bestätigt?
|
||||
|
||||
WICHTIG: Dies ist die operative Bestätigung (konkreter Termin,
|
||||
Personal eingeplant, Übergabe erfolgt). Die grundsätzliche
|
||||
Bereitschaft wurde bereits an Gate 1 geprüft.
|
||||
|
||||
Falls hier "nicht_bestaetigt" ausgewählt wird, ist zu prüfen,
|
||||
ob sich die Situation gegenüber Gate 1 verändert hat (z.B.
|
||||
unerwarteter Personalabgang, Priorisierungsänderungen).
|
||||
werte:
|
||||
- "bestaetigt"
|
||||
- "mit_auflagen"
|
||||
- "nicht_bestaetigt"
|
||||
referenz: "AP-02, G3-DIM-04"
|
||||
abgrenzung_gate_1: |
|
||||
Gate 1: Grundsätzliches Commitment ("Wir können/wollen diesen Service übernehmen")
|
||||
Gate 3: Operatives Commitment ("Wir sind JETZT bereit für die Übernahme")
|
||||
|
||||
- name: "pruefung_auflagen_gate_2"
|
||||
typ: "enum"
|
||||
pflicht: true
|
||||
beschreibung: "Auflagen aus Gate 2 erfüllt? (Showstopper wenn vorhanden)"
|
||||
werte:
|
||||
- "erfuellt"
|
||||
- "nicht_erfuellt"
|
||||
- "keine_auflagen"
|
||||
referenz: "AP-02, G3-DIM-05"
|
||||
|
||||
# --- Formalia ---
|
||||
- name: "so_bestaetigung_durch_sor"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "SO wurde durch SOR formal bestätigt"
|
||||
referenz: "GOV-TR-004"
|
||||
|
||||
# --- Auflagen ---
|
||||
- name: "auflagen"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Auflagen bei 'go_live_mit_auflagen' (Gate 3)"
|
||||
max_zeichen: 500
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ELS: EARLY LIFE SUPPORT
|
||||
# ---------------------------------------------------------------------------
|
||||
els:
|
||||
beschreibung: "Dokumentation der ELS-Phase"
|
||||
referenz: "AP-04"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "start"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "ELS-Start (= Go-Live-Datum)"
|
||||
|
||||
- name: "ende"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "ELS-Ende (Datum der SO-Entscheidung)"
|
||||
|
||||
- name: "dauer_wochen"
|
||||
typ: "integer"
|
||||
pflicht: false
|
||||
beschreibung: "Tatsächliche ELS-Dauer in Wochen (gerundet)"
|
||||
hinweis: "Wird bei Abschluss berechnet"
|
||||
|
||||
- name: "kritische_stoerungen_anzahl"
|
||||
typ: "integer"
|
||||
pflicht: true
|
||||
beschreibung: "Anzahl kritischer Störungen während ELS"
|
||||
default: 0
|
||||
referenz: "AP-04, Definition 'kritische Störung'"
|
||||
|
||||
- name: "exit_begruendung"
|
||||
typ: "text"
|
||||
pflicht: true
|
||||
beschreibung: "Begründung, warum Exit-Kriterien als erfüllt gelten"
|
||||
max_zeichen: 500
|
||||
beispiel: "Keine kritischen Störungen seit 3 Wochen, Support-Aufkommen normalisiert."
|
||||
|
||||
- name: "lessons_learned"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Wesentliche Erkenntnisse für Service Review"
|
||||
max_zeichen: 500
|
||||
mvp_hinweis: "Optional für MVP. Kann bei Bedarf verpflichtend werden."
|
||||
|
||||
- name: "eskalation_erfolgt"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Wurde an SOR eskaliert (bei Überschreitung Maximaldauer)?"
|
||||
default: false
|
||||
|
||||
- name: "eskalation_ergebnis"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "SOR-Entscheidung bei Eskalation"
|
||||
max_zeichen: 300
|
||||
hinweis: "Nur ausfüllen wenn eskalation_erfolgt = true"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABSCHLUSS-CHECKLISTE
|
||||
# ---------------------------------------------------------------------------
|
||||
abschluss_checkliste:
|
||||
beschreibung: "Checkliste zur Sicherstellung der Vollständigkeit bei Abschluss"
|
||||
referenz: "AP-07"
|
||||
|
||||
mvp_hinweis: |
|
||||
Für MVP als einfache Boolean-Checkliste. Kann später um
|
||||
Nachweise/Referenzen pro Punkt erweitert werden.
|
||||
|
||||
felder:
|
||||
|
||||
- name: "gate_2_passiert"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Gate 2 (Entry-Prüfung nach Build) wurde erfolgreich passiert"
|
||||
|
||||
- name: "pilot_abgeschlossen"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Pilot abgeschlossen (oder nicht erforderlich)"
|
||||
|
||||
- name: "gate_3_passiert"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Gate 3 (Go-Live-Freigabe) wurde erfolgreich passiert"
|
||||
|
||||
- name: "els_abgeschlossen"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "ELS wurde abgeschlossen"
|
||||
|
||||
- name: "service_im_katalog"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Service ist im Katalog aktiviert"
|
||||
|
||||
- name: "so_bestaetigt"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "SO wurde durch SOR bestätigt"
|
||||
|
||||
- name: "dokumentation_vollstaendig"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Betriebsdokumentation ist vollständig und implementiert"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SONDERFÄLLE: ABBRUCH / ROLLBACK
|
||||
# ---------------------------------------------------------------------------
|
||||
abbruch:
|
||||
beschreibung: "Dokumentation bei Abbruch oder Rollback (nur bei negativem Ausgang)"
|
||||
referenz: "AP-05"
|
||||
|
||||
mvp_hinweis: |
|
||||
Minimale Dokumentation für MVP. Detaillierte Abbruch-Analyse
|
||||
kann bei Bedarf ergänzt werden.
|
||||
|
||||
felder:
|
||||
|
||||
- name: "abbruch_erfolgt"
|
||||
typ: "boolean"
|
||||
pflicht: true
|
||||
beschreibung: "Wurde die Transition abgebrochen?"
|
||||
default: false
|
||||
|
||||
- name: "abbruch_zeitpunkt"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
beschreibung: "In welcher Phase erfolgte der Abbruch?"
|
||||
werte:
|
||||
- "vor_gate_2"
|
||||
- "nach_gate_2"
|
||||
- "waehrend_pilot"
|
||||
- "vor_gate_3"
|
||||
- "nach_gate_3"
|
||||
- "waehrend_els"
|
||||
|
||||
- name: "abbruch_typ"
|
||||
typ: "enum"
|
||||
pflicht: false
|
||||
beschreibung: "Art des Abbruchs"
|
||||
werte:
|
||||
- "zurueckweisung"
|
||||
- "rollback"
|
||||
- "termination"
|
||||
referenz: "AP-05"
|
||||
|
||||
- name: "abbruch_begruendung"
|
||||
typ: "text"
|
||||
pflicht: false
|
||||
beschreibung: "Begründung für den Abbruch"
|
||||
max_zeichen: 500
|
||||
|
||||
- name: "entscheider"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "Wer hat den Abbruch entschieden (SO/SOR)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# META
|
||||
# ---------------------------------------------------------------------------
|
||||
meta:
|
||||
beschreibung: "Metadaten zur Dokumentenverwaltung"
|
||||
|
||||
felder:
|
||||
|
||||
- name: "erstellt_von"
|
||||
typ: "string"
|
||||
pflicht: true
|
||||
beschreibung: "Wer hat den Steckbrief angelegt"
|
||||
|
||||
- name: "erstellt_am"
|
||||
typ: "date"
|
||||
pflicht: true
|
||||
beschreibung: "Erstellungsdatum"
|
||||
|
||||
- name: "letzte_aenderung_von"
|
||||
typ: "string"
|
||||
pflicht: false
|
||||
beschreibung: "Wer hat zuletzt geändert"
|
||||
|
||||
- name: "letzte_aenderung_am"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "Datum der letzten Änderung"
|
||||
|
||||
- name: "ueberfuehrt_am"
|
||||
typ: "date"
|
||||
pflicht: false
|
||||
beschreibung: "Datum der Überführung in Service-Steckbrief"
|
||||
hinweis: "Wird bei Status 'abgeschlossen' gesetzt"
|
||||
|
||||
# =============================================================================
|
||||
# MVP-ENTSCHEIDUNGEN UND ERWEITERUNGSPOTENTIAL
|
||||
# =============================================================================
|
||||
|
||||
mvp_entscheidungen:
|
||||
|
||||
beschreibung: |
|
||||
Folgende Vereinfachungen wurden für den MVP getroffen. Sie können
|
||||
basierend auf operativer Erfahrung angepasst werden.
|
||||
|
||||
entscheidungen:
|
||||
|
||||
- bereich: "Auflagen-Dokumentation"
|
||||
mvp: "Freitext-Feld"
|
||||
erweiterung: "Strukturierte Liste mit Auflagen-ID, Frist, Status, Verantwortlicher"
|
||||
trigger: "Wenn Auflagen-Tracking systematisch nötig wird"
|
||||
|
||||
- bereich: "Pilot-Scope"
|
||||
mvp: "Freitext-Feld"
|
||||
erweiterung: "Strukturiert: Nutzergruppe, Funktionsumfang, Erfolgskriterien, Exit-Kriterien"
|
||||
trigger: "Wenn Pilots häufiger und komplexer werden"
|
||||
|
||||
- bereich: "Abschluss-Checkliste"
|
||||
mvp: "Boolean-Felder"
|
||||
erweiterung: "Pro Punkt: Nachweis-Referenz, Datum, Prüfer"
|
||||
trigger: "Wenn Audit-Anforderungen steigen"
|
||||
|
||||
- bereich: "Kritische Störungen"
|
||||
mvp: "Nur Anzahl"
|
||||
erweiterung: "Liste mit Incident-IDs, Datum, Kurzbeschreibung"
|
||||
trigger: "Wenn Detailanalyse für Service Review nötig wird"
|
||||
|
||||
- bereich: "Transition-Typ"
|
||||
mvp: "neuer_service | wesentliche_aenderung"
|
||||
erweiterung: "Differenzierung nach Service-Kategorie (Basis, Standard, Premium)"
|
||||
trigger: "Wenn Portfolio-Vielfalt zunimmt"
|
||||
|
||||
- bereich: "Versionierung"
|
||||
mvp: "Keine explizite Versionierung des Steckbriefs"
|
||||
erweiterung: "Änderungshistorie mit Version, Datum, Autor, Änderung"
|
||||
trigger: "Wenn Nachvollziehbarkeit von Änderungen relevant wird"
|
||||
|
||||
# =============================================================================
|
||||
# VALIDIERUNGSREGELN
|
||||
# =============================================================================
|
||||
|
||||
validierung:
|
||||
|
||||
beschreibung: |
|
||||
Regeln zur Konsistenzprüfung. Können bei Tool-Implementierung
|
||||
genutzt werden.
|
||||
|
||||
regeln:
|
||||
|
||||
- regel: "Gate-2-Vollständigkeit"
|
||||
bedingung: "status != 'angelegt'"
|
||||
pruefung: "gate_2.datum UND gate_2.entscheidung müssen gesetzt sein"
|
||||
|
||||
- regel: "Pilot-Konsistenz"
|
||||
bedingung: "gate_2.pilot_erforderlich = true"
|
||||
pruefung: "pilot.status muss != 'nicht_erforderlich' sein"
|
||||
|
||||
- regel: "Gate-3-nach-Gate-2"
|
||||
bedingung: "gate_3.datum ist gesetzt"
|
||||
pruefung: "gate_2.entscheidung muss 'freigabe' oder 'freigabe_mit_auflagen' sein"
|
||||
|
||||
- regel: "ELS-nach-Gate-3"
|
||||
bedingung: "els.start ist gesetzt"
|
||||
pruefung: "gate_3.entscheidung muss 'go_live' oder 'go_live_mit_auflagen' sein"
|
||||
|
||||
- regel: "Abschluss-Vollständigkeit"
|
||||
bedingung: "status = 'abgeschlossen'"
|
||||
pruefung: "Alle Felder in abschluss_checkliste müssen true sein"
|
||||
|
||||
- regel: "Abbruch-Dokumentation"
|
||||
bedingung: "abbruch.abbruch_erfolgt = true"
|
||||
pruefung: "abbruch.abbruch_zeitpunkt UND abbruch.abbruch_begruendung müssen gesetzt sein"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.3"
|
||||
datum: "2026-01-30"
|
||||
aenderung: |
|
||||
Präzisierung Ressourcen-Commitment: Klarstellung der Zwei-Stufen-Prüfung.
|
||||
- Gate 1 (tr_01) prüft grundsätzliches Commitment (in service-lifecycle_transition.yaml)
|
||||
- Gate 3 prüft operatives Commitment (Beschreibung präzisiert)
|
||||
Hintergrund: Ressourcenfrage muss VOR Transition geklärt sein, um
|
||||
Ressourcenverschwendung zu vermeiden.
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "Konzeptionelle Überprüfung Ressourcenprüfung"
|
||||
|
||||
- version: "0.3"
|
||||
datum: "2026-02-18"
|
||||
aenderung: "Gate 1 in Transition verschoben (tr_01). Gate-IDs aktualisiert: Gate 2 = tr_09, Gate 3 = tr_12. Transition-Steckbrief dokumentiert nun alle 3 Gates."
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "service-lifecycle_transition.yaml v2.0"
|
||||
|
||||
- version: "0.2"
|
||||
datum: "2026-01-30"
|
||||
aenderung: "Anpassung an Service-Lifecycle 3.0 (5-Phasen-Konsolidierung): Gate-Nummerierung auf globale Nummerierung umgestellt (Gate 2 = tr_08, Gate 3 = tr_11). Terminologie aktualisiert (Design-Phase statt Service-Entwicklung)."
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
|
||||
|
||||
- version: "0.1"
|
||||
datum: "2025-12-17"
|
||||
aenderung: "Initiale Schema-Definition (MVP)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "AP-07, GOV-TR-018"
|
||||
|
|
@ -0,0 +1,165 @@
|
|||
# =============================================================================
|
||||
# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I)
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Entwurf (Pilotphase)
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-002
|
||||
#
|
||||
# Zweck:
|
||||
# Vorlage zur Erstellung eines Operational Level Agreements (OLA) für
|
||||
# Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase
|
||||
# befüllt, wenn operative Erfahrungswerte vorliegen.
|
||||
#
|
||||
# Abgrenzung:
|
||||
# - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C)
|
||||
# - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I)
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 1. IDENTIFIKATION
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
identifikation:
|
||||
ola_id: "" # z.B. "OLA-INT-001"
|
||||
ola_titel: "" # z.B. "OLA Active Directory Services"
|
||||
version: "" # z.B. "1.0"
|
||||
status: "" # Entwurf | Aktiv | In Review | Außer Kraft
|
||||
erstellungsdatum: "" # YYYY-MM-DD
|
||||
letzte_aktualisierung: "" # YYYY-MM-DD
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
|
||||
service_referenz:
|
||||
service_name: "" # Name des Internen Services
|
||||
service_id: "" # ID gemäß Service-Definition
|
||||
service_kategorie: "I" # Immer "I" für Interne Services
|
||||
service_owner: "" # Name / Rolle
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 2. VERTRAGSPARTEIEN (INTERN)
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
vertragsparteien:
|
||||
|
||||
liefernde_einheit:
|
||||
name: "" # z.B. "Team Infrastruktur"
|
||||
verantwortlich: "" # Name / Rolle des Ansprechpartners
|
||||
kontakt: "" # E-Mail / Telefon
|
||||
|
||||
nutzende_einheiten:
|
||||
- name: "" # z.B. "Team Applikationsbetrieb"
|
||||
verantwortlich: ""
|
||||
kontakt: ""
|
||||
abhängige_kundenservices: # Welche Kategorie A/B/C-Services hängen davon ab?
|
||||
- ""
|
||||
|
||||
hinweis: |
|
||||
Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden.
|
||||
Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices
|
||||
(Kategorie A/B/C) vom Internen Service abhängen.
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 3. LEISTUNGSBESCHREIBUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
leistungsbeschreibung:
|
||||
|
||||
kurzbeschreibung: "" # 2-3 Sätze: Was leistet der Service?
|
||||
|
||||
leistungsumfang:
|
||||
enthalten:
|
||||
- "" # Auflistung der enthaltenen Leistungen
|
||||
nicht_enthalten:
|
||||
- "" # Explizite Ausschlüsse
|
||||
|
||||
betriebszeiten:
|
||||
regulaer: "" # z.B. "Mo-Fr 07:00-18:00"
|
||||
erweitert: "" # z.B. "24/7 für kritische Systeme"
|
||||
wartungsfenster: "" # z.B. "Sonntag 02:00-06:00"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 4. QUALITÄTSZIELE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
qualitaetsziele:
|
||||
|
||||
verfuegbarkeit:
|
||||
zielwert: "" # z.B. "99,5 %"
|
||||
messperiode: "" # z.B. "Kalendermonat"
|
||||
messmethode: "" # z.B. "Monitoring-Tool X, Uptime-Berechnung"
|
||||
ausnahmen: "" # z.B. "Geplante Wartung ausgenommen"
|
||||
|
||||
performance:
|
||||
- metrik: "" # z.B. "Antwortzeit Authentifizierung"
|
||||
zielwert: "" # z.B. "< 200 ms (95. Perzentil)"
|
||||
messmethode: ""
|
||||
|
||||
kapazitaet:
|
||||
aktuell: "" # z.B. "500 gleichzeitige Nutzer"
|
||||
geplant: "" # z.B. "800 gleichzeitige Nutzer bis Q4/2026"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 5. ESKALATIONSWEGE
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
eskalationswege:
|
||||
|
||||
stufe_1:
|
||||
beschreibung: "Operativer Kontakt"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: "" # z.B. "30 Minuten während Betriebszeiten"
|
||||
|
||||
stufe_2:
|
||||
beschreibung: "Teamleitung / Service Owner"
|
||||
verantwortlich: ""
|
||||
reaktionszeit: ""
|
||||
|
||||
stufe_3:
|
||||
beschreibung: "Eskalation an SOR / Mission Board"
|
||||
ausloeser: |
|
||||
- Wiederholte Verfehlung der Qualitätsziele
|
||||
- Cross-Service-Impact auf Kundenservices
|
||||
referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 6. REVIEW-MECHANISMUS
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
review:
|
||||
|
||||
review_zyklus: "" # z.B. "Halbjährlich"
|
||||
naechster_review: "" # YYYY-MM-DD
|
||||
review_teilnehmer:
|
||||
- "" # Rollen / Namen
|
||||
|
||||
aenderungsverfahren: |
|
||||
Änderungen am OLA werden vom Service Owner des Internen Services
|
||||
initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen
|
||||
mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich
|
||||
(vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# 7. LAUFZEIT UND KÜNDIGUNG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
laufzeit:
|
||||
beginn: "" # YYYY-MM-DD
|
||||
laufzeit: "" # z.B. "Unbefristet, jährlicher Review"
|
||||
kuendigungsfrist: "" # z.B. "3 Monate zum Quartalsende"
|
||||
kuendigungsbedingungen: |
|
||||
Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den
|
||||
Internen Service durch den SOR voraus (vgl. GOV-SOR-006).
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung des OLA-Templates"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-002, OQ-001"
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# =============================================================================
|
||||
# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN
|
||||
# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente
|
||||
# =============================================================================
|
||||
#
|
||||
# Version: 1.0
|
||||
# Datum: 2026-03-09
|
||||
# Status: Final
|
||||
# Autor: DIGITOM-Projekt
|
||||
# Governance: GOV-SPM-I-005
|
||||
#
|
||||
# Zweck:
|
||||
# Dieser Leitfaden unterstützt die systematische Einordnung von
|
||||
# Infrastruktur-Komponenten als Interne Services (Kategorie I) oder
|
||||
# als passive Service-Komponenten. Er ist eine Orientierungshilfe,
|
||||
# kein Automatismus – die finale Entscheidung trifft das SPM/SOR.
|
||||
#
|
||||
# Kontext:
|
||||
# Mit der Einführung der Kategorie I (Interne Services) entsteht die
|
||||
# Frage, welche Infrastruktur-Komponenten als eigenständige Governance-
|
||||
# Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare
|
||||
# Kriterien für diese Abgrenzung.
|
||||
#
|
||||
# =============================================================================
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# DIE SIEBEN FRAGEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
fragen:
|
||||
|
||||
- nr: 1
|
||||
frage: "Gibt es einen identifizierbaren internen 'Kunden'?"
|
||||
erlaeuterung: |
|
||||
Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente
|
||||
als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs-
|
||||
beziehung (Lieferant → Nutzer)?
|
||||
beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt"
|
||||
beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit"
|
||||
|
||||
- nr: 2
|
||||
frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?"
|
||||
erlaeuterung: |
|
||||
Kann eine Person oder Rolle die Gesamtverantwortung für Qualität,
|
||||
Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist
|
||||
diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle
|
||||
abgrenzbar?
|
||||
beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen"
|
||||
beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung"
|
||||
|
||||
- nr: 3
|
||||
frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?"
|
||||
erlaeuterung: |
|
||||
Können Verfügbarkeit, Performance oder andere Qualitätsmetriken
|
||||
für diese Komponente eigenständig definiert und gemessen werden –
|
||||
unabhängig von den darüberliegenden Kundenservices?
|
||||
beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms"
|
||||
beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele"
|
||||
|
||||
- nr: 4
|
||||
frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?"
|
||||
erlaeuterung: |
|
||||
Wird die Komponente als Shared Service von mehr als einem
|
||||
Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen
|
||||
Mehrfachnutzungs-Charakter?
|
||||
beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt"
|
||||
beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service"
|
||||
|
||||
- nr: 5
|
||||
frage: "Gibt es operative Steuerungsnotwendigkeit?"
|
||||
erlaeuterung: |
|
||||
Erfordert die Komponente regelmäßige operative Entscheidungen
|
||||
(Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über
|
||||
den normalen Betrieb hinausgehen?
|
||||
beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform"
|
||||
beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung"
|
||||
|
||||
- nr: 6
|
||||
frage: "Ist die Komponente für Incident Management eigenständig relevant?"
|
||||
erlaeuterung: |
|
||||
Kann es Incidents geben, die primär dieser Komponente zugeordnet
|
||||
werden und nicht sofort einem darüberliegenden Kundenservice?
|
||||
Gibt es einen eigenen Incident-Kontext?
|
||||
beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident"
|
||||
beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet"
|
||||
|
||||
- nr: 7
|
||||
frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?"
|
||||
erlaeuterung: |
|
||||
Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit
|
||||
ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR)
|
||||
vorzulegen – analog zur Stilllegung eines Kundenservices?
|
||||
beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant"
|
||||
beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# AUSWERTUNGSSCHEMA
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
auswertung:
|
||||
|
||||
schema:
|
||||
- bereich: "5–7 × Ja"
|
||||
ergebnis: "Interner Service (Kategorie I)"
|
||||
beschreibung: |
|
||||
Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale
|
||||
eines eigenständigen Governance-Objekts und sollte als Interner
|
||||
Service mit eigener Service-Definition geführt werden.
|
||||
|
||||
- bereich: "3–4 × Ja"
|
||||
ergebnis: "Grenzfall – Entscheidung durch SPM/SOR"
|
||||
beschreibung: |
|
||||
Die Komponente zeigt einige Service-Merkmale, aber nicht alle.
|
||||
Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR
|
||||
zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde)
|
||||
und 2 (Owner-Rolle) haben dabei besonderes Gewicht.
|
||||
|
||||
- bereich: "0–2 × Ja"
|
||||
ergebnis: "Passive Service-Komponente"
|
||||
beschreibung: |
|
||||
Die Komponente ist ein Bestandteil eines übergeordneten Services
|
||||
und wird nicht als eigenständiges Governance-Objekt geführt.
|
||||
Sie erscheint ggf. als Abhängigkeit in der Service-Definition
|
||||
des nutzenden Services.
|
||||
|
||||
hinweis_grenzfaelle: |
|
||||
Der Leitfaden ist eine Orientierungshilfe, kein Automatismus.
|
||||
Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte
|
||||
zusätzlich berücksichtigt werden:
|
||||
- Strategische Bedeutung der Komponente für DIGIT
|
||||
- Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?)
|
||||
- Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?)
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# ANWENDUNGSBEISPIEL
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
anwendungsbeispiel:
|
||||
|
||||
komponente: "Active Directory Services"
|
||||
|
||||
bewertung:
|
||||
- frage_nr: 1
|
||||
antwort: "Ja"
|
||||
begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst"
|
||||
- frage_nr: 2
|
||||
antwort: "Ja"
|
||||
begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen"
|
||||
- frage_nr: 3
|
||||
antwort: "Ja"
|
||||
begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar"
|
||||
- frage_nr: 4
|
||||
antwort: "Ja"
|
||||
begruendung: "Wird von >10 Kundenservices genutzt"
|
||||
- frage_nr: 5
|
||||
antwort: "Ja"
|
||||
begruendung: "Migration zu Entra ID erfordert strategische Steuerung"
|
||||
- frage_nr: 6
|
||||
antwort: "Ja"
|
||||
begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident"
|
||||
- frage_nr: 7
|
||||
antwort: "Ja"
|
||||
begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung"
|
||||
|
||||
ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# REFERENZEN
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
referenzen:
|
||||
- "GOV-SPM-I-001: Einführung Kategorie I"
|
||||
- "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept"
|
||||
- "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)"
|
||||
- "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR"
|
||||
|
||||
# -----------------------------------------------------------------------------
|
||||
# CHANGELOG
|
||||
# -----------------------------------------------------------------------------
|
||||
|
||||
changelog:
|
||||
- version: "1.0"
|
||||
datum: "2026-03-09"
|
||||
aenderung: "Erstfassung als eigenständiges Arbeitsdokument"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "GOV-SPM-I-005, OQ-003"
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,215 @@
|
|||
metadata:
|
||||
version: "3.7"
|
||||
datum: "2026-03-09"
|
||||
quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
|
||||
basis: "ITIL4 / DIGITOM Begriffsüberleitung"
|
||||
hinweis: >
|
||||
Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
|
||||
ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
|
||||
eins in das DIGIT Service-Management Framework passen (Übernehmen),
|
||||
ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
|
||||
modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
|
||||
keinen erkennbaren Mehrwert bieten (Weglassen).
|
||||
|
||||
glossar:
|
||||
- begriff: "Anforderung"
|
||||
definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
|
||||
synonyme: ["Requirement", "Vorgabe"]
|
||||
|
||||
- begriff: "Anwender*in"
|
||||
definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
|
||||
synonyme: ["Nutzer*in", "User"]
|
||||
|
||||
- begriff: "Auftraggeber*in"
|
||||
definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
|
||||
|
||||
- begriff: "Bedarf"
|
||||
definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
|
||||
|
||||
- begriff: "Change"
|
||||
definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
|
||||
synonyme: ["Änderung"]
|
||||
|
||||
- begriff: "Configuration Item (CI)"
|
||||
definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
|
||||
|
||||
- begriff: "Demand"
|
||||
definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
|
||||
|
||||
- begriff: "Demand-Steckbrief"
|
||||
definition: |
|
||||
Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
|
||||
den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
|
||||
Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
|
||||
abgrenzung:
|
||||
- "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
|
||||
- "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
|
||||
|
||||
- begriff: "Emergency-Change"
|
||||
definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
|
||||
|
||||
- begriff: "Ergebnis"
|
||||
definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
|
||||
synonyme: ["Outcome"]
|
||||
|
||||
- begriff: "Gewährleistung"
|
||||
definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
|
||||
synonyme: ["Qualitätszusage", "Warranty"]
|
||||
|
||||
- begriff: "Geschäftskritikalität"
|
||||
definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
|
||||
synonyme: ["Business Criticality", "Service-Kritikalität"]
|
||||
|
||||
- begriff: "Governance"
|
||||
definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
|
||||
|
||||
- begriff: "Incident"
|
||||
definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
|
||||
synonyme: ["Vorfall", "Störung"]
|
||||
|
||||
- begriff: "Interner Service"
|
||||
definition: |
|
||||
Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
|
||||
DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
|
||||
sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
|
||||
Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
|
||||
eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
|
||||
Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
|
||||
Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
|
||||
abgrenzung:
|
||||
- "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
|
||||
- "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
|
||||
kategorie: "I"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
|
||||
|
||||
- begriff: "Initiative"
|
||||
definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
|
||||
synonyme: ["Chance", "Möglichkeit", "Opportunity"]
|
||||
|
||||
- begriff: "Key Performance Indicator (KPI)"
|
||||
definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
|
||||
|
||||
- begriff: "Kontinuierliche Verbesserung"
|
||||
definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
|
||||
|
||||
- begriff: "Kundenservice"
|
||||
definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
|
||||
|
||||
- begriff: "Kund*in"
|
||||
definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
|
||||
synonyme: ["Service-Konsument"]
|
||||
|
||||
- begriff: "Major-Change"
|
||||
definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
|
||||
synonyme: ["Wesentliche Änderung"]
|
||||
|
||||
- begriff: "Normal-Change"
|
||||
definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
|
||||
|
||||
- begriff: "Nutzen"
|
||||
definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
|
||||
synonyme: ["Utility"]
|
||||
|
||||
- begriff: "Problem (engl.)"
|
||||
definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
|
||||
synonyme: ["Ursache"]
|
||||
|
||||
- begriff: "Produkt"
|
||||
definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
|
||||
synonyme: ["Leistungsbaustein"]
|
||||
|
||||
- begriff: "Recovery Time Objective (RTO)"
|
||||
definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
|
||||
synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
|
||||
|
||||
- begriff: "Request-Katalog"
|
||||
definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
|
||||
|
||||
- begriff: "Request for Change (RFC)"
|
||||
definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
|
||||
synonyme: ["Change Request"]
|
||||
|
||||
- begriff: "Ressource"
|
||||
definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
|
||||
|
||||
- begriff: "Service"
|
||||
definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
|
||||
synonyme: ["Dienstleistung"]
|
||||
|
||||
- begriff: "Service Level"
|
||||
definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
|
||||
synonyme: ["Service-Qualitätsniveau"]
|
||||
|
||||
- begriff: "Operational Level Agreement (OLA)"
|
||||
definition: |
|
||||
Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
|
||||
(Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
|
||||
Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
|
||||
abgrenzung:
|
||||
- "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
|
||||
- "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
- begriff: "Service-Sichtbarkeit"
|
||||
definition: |
|
||||
Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
|
||||
Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
|
||||
Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
|
||||
Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
|
||||
Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
|
||||
governance_referenz: "GOV-SPM-I-003"
|
||||
|
||||
- begriff: "Service Level Agreement (SLA)"
|
||||
definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
|
||||
synonyme: ["Servicevereinbarung"]
|
||||
|
||||
- begriff: "Service Request"
|
||||
definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
|
||||
synonyme: ["Serviceanfrage"]
|
||||
|
||||
- begriff: "Service-Anbieter"
|
||||
definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
|
||||
synonyme: ["Dienstleister", "Service Provider"]
|
||||
|
||||
- begriff: "Service-Angebot"
|
||||
definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
|
||||
synonyme: ["Leistungsangebot"]
|
||||
|
||||
- begriff: "Service-Bereitstellung"
|
||||
definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
|
||||
synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
|
||||
|
||||
- begriff: "Service-Beziehung"
|
||||
definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
|
||||
|
||||
- begriff: "Service-Katalog"
|
||||
definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
|
||||
|
||||
- begriff: "Service-Portfolio"
|
||||
definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
|
||||
synonyme: ["IT-Service-Portfolio"]
|
||||
|
||||
- begriff: "Sponsor*in"
|
||||
definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
|
||||
|
||||
- begriff: "Stakeholder"
|
||||
definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
|
||||
synonyme: ["Anspruchsgruppen"]
|
||||
|
||||
- begriff: "Standard Operating Procedures (SOPs)"
|
||||
definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
|
||||
synonyme: ["Standardvorgehensweise"]
|
||||
|
||||
- begriff: "Standard-Change"
|
||||
definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
|
||||
|
||||
- begriff: "Vital Business Function (VBF)"
|
||||
definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
|
||||
synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
|
||||
|
||||
- begriff: "Wert"
|
||||
definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
|
||||
|
||||
- begriff: "Wissensmanagement"
|
||||
definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# Funktionsbeschreibung Stakeholder-Management (SHM)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 0, 10
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 0 und 10]
|
||||
817
#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml
Normal file
817
#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml
Normal file
|
|
@ -0,0 +1,817 @@
|
|||
# =============================================================================
|
||||
# SHM ROLLENBESCHREIBUNGEN
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Funktion: Rollen
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-10
|
||||
# Status: Entwurf
|
||||
# Entwicklungsphase: 6
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
dokument_id: "SHM-R-01"
|
||||
name: "SHM Rollenbeschreibungen"
|
||||
|
||||
enthaltene_rollen:
|
||||
- rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
- rolle_id: "shm-l"
|
||||
rolle_name: "Leitung Stakeholder Management"
|
||||
|
||||
beziehung_rollen: |
|
||||
Die Leitung Stakeholder Management ist disziplinarische Führungskraft
|
||||
der Stakeholder-Manager:innen und gleichzeitig Abteilungsleitung.
|
||||
|
||||
Operative Kundenbetreuung liegt bei den Stakeholder-Manager:innen.
|
||||
Strategische Steuerung, Reporting und Gremienvertretung auf
|
||||
Leitungsebene (MB) liegt bei der Leitung.
|
||||
|
||||
# =============================================================================
|
||||
# ROLLE 1: STAKEHOLDER-MANAGER:IN
|
||||
# =============================================================================
|
||||
|
||||
stakeholder_manager:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# META
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
aliases: ["SHM-Manager", "Kundenbetreuer:in"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Stakeholder-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: "[SHM-Leitung]"
|
||||
status: "entwurf"
|
||||
|
||||
kontext_tags:
|
||||
- "stakeholder-management"
|
||||
- "kundenbetreuung"
|
||||
- "bedarfserhebung"
|
||||
- "relationship-management"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ROLLENZWECK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rollenzweck:
|
||||
|
||||
kurz: |
|
||||
Zentrale Ansprechperson für zugewiesene Stakeholder (Ämter/Einheiten)
|
||||
und verantwortlich für Beziehungspflege, Bedarfserhebung und
|
||||
Interessenvertretung gegenüber DIGIT.
|
||||
|
||||
ausfuehrlich: |
|
||||
Der/die Stakeholder-Manager:in betreut einen definierten Kreis von
|
||||
Organisationseinheiten (Ämter, Eigenbetriebe, Referate etc.) und ist
|
||||
deren primäre Schnittstelle zu DIGIT. Die Rolle umfasst proaktive
|
||||
Beziehungspflege, systematische Bedarfserhebung, qualifiziertes
|
||||
Routing von Anforderungen sowie die Vertretung der Stakeholder-
|
||||
Perspektive in internen Gremien.
|
||||
|
||||
Der/die Stakeholder-Manager:in agiert als "Kundenanwalt" – nicht als
|
||||
neutraler Vermittler, sondern als aktiver Vertreter der
|
||||
Kundenperspektive innerhalb von DIGIT.
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "Für alle Interaktionen mit zugewiesenen Stakeholdern"
|
||||
fuer: "Beziehungsqualität, Bedarfserfassung, Routing-Entscheidung"
|
||||
bis: "Übergabe qualifizierter Demands an DPM, Changes an SPM bzw. Abschluss Service-Request"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ORGANISATORISCHE EINORDNUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
zuordnung:
|
||||
abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance"
|
||||
abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen
|
||||
funktion: "Stakeholder-Management (SHM)"
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "Leitung Stakeholder Management"
|
||||
berichtet_an_rolle_id: "shm-l"
|
||||
|
||||
arbeitsmodell:
|
||||
typ: "Vollzeitfunktion oder Teilfunktion"
|
||||
anmerkung: |
|
||||
Je nach Portfolio-Größe kann die Rolle auf mehrere Personen
|
||||
verteilt sein. Jede:r Stakeholder-Manager:in betreut einen
|
||||
definierten Kreis von Ämtern/Einheiten.
|
||||
vertretung: "Gegenseitige Vertretungsregelung zwischen Stakeholder-Manager:innen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KERNAUFGABEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kernaufgaben:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
beziehungspflege:
|
||||
|
||||
name: "Proaktive Beziehungspflege"
|
||||
|
||||
beschreibung: |
|
||||
Aufbau und Pflege stabiler, vertrauensvoller Beziehungen zu den
|
||||
zugewiesenen Stakeholdern. Der/die Stakeholder-Manager:in ist
|
||||
das "Gesicht von DIGIT" für diese Organisationseinheiten.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Turnus-Gespräche durchführen"
|
||||
frequenz: "Gemäß Betreuungsmodus (monatlich bis jährlich)"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
|
||||
- aufgabe: "Stakeholder-Steckbriefe pflegen"
|
||||
frequenz: "Laufend, mindestens jährliche Validierung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml"
|
||||
|
||||
- aufgabe: "Beziehungsqualität einschätzen und dokumentieren"
|
||||
frequenz: "Nach jedem Kontakt"
|
||||
referenz: "shm_stakeholder-portfolio.yaml"
|
||||
|
||||
- aufgabe: "Proaktive Kontaktaufnahme bei Veränderungen"
|
||||
trigger: "Neue Amtsleitung, Reorganisation, Projektstart"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder fühlen sich von DIGIT verstanden und gut betreut.
|
||||
Beziehungsqualität ist dokumentiert und steuerbar.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
bedarfserhebung:
|
||||
|
||||
name: "Bedarfserhebung und -qualifizierung"
|
||||
|
||||
beschreibung: |
|
||||
Systematische Erfassung, Klärung und Dokumentation von
|
||||
Stakeholder-Bedarfen. Der/die Stakeholder-Manager:in trennt
|
||||
den eigentlichen Bedarf von vorgeschlagenen Lösungen.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Bedarfe in Turnus-Gesprächen erheben"
|
||||
methode: "Aktives Zuhören, gezielte Fragen"
|
||||
|
||||
- aufgabe: "Bedarfssteckbrief erstellen"
|
||||
referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
- aufgabe: "User Stories erheben (bei komplexeren Bedarfen)"
|
||||
referenz: "leitfaden_user-stories.yaml"
|
||||
|
||||
- aufgabe: "Rückfragen klären, Nachforderungen einholen"
|
||||
bei: "Unvollständige oder unklare Bedarfsbeschreibung"
|
||||
|
||||
ergebnis: |
|
||||
Bedarfe sind verstanden, dokumentiert und für Routing vorbereitet.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
routing:
|
||||
|
||||
name: "Bedarfs-Routing"
|
||||
|
||||
beschreibung: |
|
||||
Kernentscheidung E2: Wohin gehört dieser Bedarf? Der/die
|
||||
Stakeholder-Manager:in ordnet Bedarfe dem richtigen Pfad zu.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Routing-Entscheidung treffen"
|
||||
pfade:
|
||||
- "Service-Katalog → Request an Service Desk"
|
||||
- "Change an bestehendem Service → Service Owner"
|
||||
- "Neuer Demand → DPM/DSR"
|
||||
- "Unklare Zuordnung → SOR"
|
||||
referenz: "shm_bedarfsbewertung.yaml"
|
||||
|
||||
- aufgabe: "Bedarfssteckbrief an Zielfunktion übergeben"
|
||||
validierung: "Gemäß Validierungsprofil des Routing-Pfads"
|
||||
|
||||
- aufgabe: "Stakeholder über Routing informieren"
|
||||
inhalt: "Wohin geht der Bedarf, was sind nächste Schritte"
|
||||
|
||||
ergebnis: |
|
||||
Bedarfe landen an der richtigen Stelle. Stakeholder wissen,
|
||||
was mit ihrem Anliegen passiert.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
eskalationsbehandlung:
|
||||
|
||||
name: "Reaktive Bedarfsbehandlung und Eskalation"
|
||||
|
||||
beschreibung: |
|
||||
Behandlung von Beschwerden, Problemen und eskalierenden
|
||||
Situationen. Der/die Stakeholder-Manager:in ist Erstanlaufstelle
|
||||
für Unzufriedenheit.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Beschwerden entgegennehmen und dokumentieren"
|
||||
haltung: "Sachlich, lösungsorientiert, Kundenperspektive ernst nehmen"
|
||||
|
||||
- aufgabe: "Eskalation an zuständige Funktion weiterleiten"
|
||||
pfade:
|
||||
- "Service-Qualität → Service Owner / SPM"
|
||||
- "Demand-Status → DPM"
|
||||
- "Projekt-Verzug → PPM"
|
||||
|
||||
- aufgabe: "Nachverfolgung und Statusupdate an Stakeholder"
|
||||
differenziert_nach: "Stakeholder-Priorität (Key/Aktiv vs. Standard/Basis)"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder-Anliegen werden ernst genommen und gelöst.
|
||||
Muster werden erkannt und aggregiert.
|
||||
|
||||
referenz: "shm_engagement-framework.yaml (Abschnitt Eskalation)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
voc_dokumentation:
|
||||
|
||||
name: "Voice of Customer Dokumentation"
|
||||
|
||||
beschreibung: |
|
||||
Systematische Erfassung von Stakeholder-Feedback als Grundlage
|
||||
für die VoC-Aggregation durch die Leitung.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Feedback in Turnus-Gesprächen dokumentieren"
|
||||
dimensionen:
|
||||
- "Zufriedenheit mit Services"
|
||||
- "Qualität der Zusammenarbeit"
|
||||
- "Bedarfserfüllung"
|
||||
- "Kommunikation"
|
||||
|
||||
- aufgabe: "Highlights identifizieren"
|
||||
typen: ["Lob", "Kritik", "Risiko", "Chance"]
|
||||
|
||||
- aufgabe: "Signale an Leitung SHM melden"
|
||||
bei: "Kritische Entwicklungen, eskalierende Unzufriedenheit"
|
||||
|
||||
ergebnis: |
|
||||
VoC-Datenbasis für Aggregation und Review ist gepflegt.
|
||||
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
gremienarbeit:
|
||||
|
||||
name: "Gremienarbeit (DSR)"
|
||||
|
||||
beschreibung: |
|
||||
Vertretung der Stakeholder-Perspektive in der Demand &
|
||||
Stakeholder-Runde (DSR).
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "An DSR-Sitzungen teilnehmen"
|
||||
rolle: "Kundenanwalt"
|
||||
|
||||
- aufgabe: "Stakeholder-Kontext zu Demands einbringen"
|
||||
inhalt: "Priorität, Historie, Beziehungsstatus, fachliche Perspektive"
|
||||
|
||||
- aufgabe: "Einwand-Recht ausüben"
|
||||
bei: "Demands, die gegen fundamentale Stakeholder-Interessen verstoßen"
|
||||
referenz: "GOV-SHM-021"
|
||||
|
||||
- aufgabe: "Kommunikationsstrategie bei Ablehnung abstimmen"
|
||||
mit: "DSR-Mitgliedern"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder-Perspektive fließt in Demand-Entscheidungen ein.
|
||||
|
||||
referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
|
||||
eigenstaendig:
|
||||
- befugnis: "Routing-Entscheidung (E2)"
|
||||
beschreibung: "Zuordnung Bedarf → Pfad (Katalog/Change/Demand/SOR)"
|
||||
einschraenkung: "Bei Unklarheit Abstimmung mit Leitung oder SOR"
|
||||
|
||||
- befugnis: "Betreuungsintensität operativ anpassen"
|
||||
beschreibung: "Zusätzliche Kontakte bei Bedarf, Gesprächsfrequenz erhöhen"
|
||||
einschraenkung: "Strukturelle Änderung der Priorisierung über Leitung"
|
||||
|
||||
- befugnis: "Eskalationspfad wählen"
|
||||
beschreibung: "Entscheidung, an welche Funktion eskaliert wird"
|
||||
|
||||
- befugnis: "Einwand in DSR erheben"
|
||||
beschreibung: "Volles Einwand-Recht als stimmberechtigtes Mitglied"
|
||||
|
||||
in_abstimmung:
|
||||
- befugnis: "Stakeholder-Priorisierung ändern"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
kontext: "Änderung des Betreuungsmodus (z.B. Standard → Aktiv)"
|
||||
|
||||
- befugnis: "Neue Stakeholder ins Portfolio aufnehmen"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
|
||||
- befugnis: "Eskalation an Vision Board"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
kontext: "Nur Leitung eskaliert an VB"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- partner: "Leitung SHM"
|
||||
interaktion: "Berichtslinie, E3-Team-Sync, Eskalation, Abstimmung"
|
||||
frequenz: "Wöchentlich (E3) + laufend"
|
||||
|
||||
- partner: "DPM (Demand-Portfolio-Manager:in)"
|
||||
interaktion: "Demand-Übergabe, Klärungsschleifen, DSR-Zusammenarbeit"
|
||||
frequenz: "Laufend"
|
||||
referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
- partner: "Service Owner / SPM"
|
||||
interaktion: "Change-Routing, Service-bezogene Rückfragen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "Service Desk"
|
||||
interaktion: "Request-Weiterleitung, Eskalationsempfang"
|
||||
frequenz: "Laufend"
|
||||
|
||||
extern:
|
||||
- partner: "Stakeholder (Ämter, Einheiten)"
|
||||
interaktion: "Turnus-Gespräche, Bedarfserhebung, Statusupdates"
|
||||
frequenz: "Gemäß Betreuungsmodus"
|
||||
|
||||
- partner: "Amtsleitungen / SLA-Partner"
|
||||
interaktion: "Strategische Abstimmung, SLA-bezogene Themen"
|
||||
frequenz: "Bei Bedarf, meist über Turnus-Gespräch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GREMIENROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gremienrollen:
|
||||
|
||||
- gremium: "DSR (Demand & Stakeholder-Runde)"
|
||||
rolle: "Stimmberechtigtes Mitglied"
|
||||
funktion: "Kundenanwalt – Vertretung der Stakeholder-Perspektive"
|
||||
befugnisse: ["Einwand-Recht", "Kontextinformation einbringen"]
|
||||
referenz: "DSR-Geschäftsordnung, GOV-SHM-021"
|
||||
|
||||
- gremium: "SOR (Service Operations Review)"
|
||||
rolle: "Teilnehmer bei Bedarf"
|
||||
funktion: "Klärung von Routing-Grenzfällen"
|
||||
referenz: "shm_sor-integration.yaml (Phase 9)"
|
||||
|
||||
- gremium: "Kundenforum (KF-01/02/03)"
|
||||
rolle: "Teilnehmer / Moderationsunterstützung"
|
||||
funktion: "Stakeholder-Interaktion in kollektiven Formaten"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
anforderungsprofil:
|
||||
|
||||
fachlich:
|
||||
- "Kenntnisse der Verwaltungsstruktur der Stadt Freiburg"
|
||||
- "Grundverständnis der DIGIT-Services und des Service-Katalogs"
|
||||
- "Verständnis des DIGITOM (DPM, SPM, SHM-Zusammenspiel)"
|
||||
- "ITIL4-Grundlagen (wünschenswert)"
|
||||
|
||||
methodisch:
|
||||
- "Gesprächsführung und aktives Zuhören"
|
||||
- "Bedarfsanalyse und Anforderungserhebung"
|
||||
- "Dokumentation und strukturierte Erfassung"
|
||||
- "Konfliktmanagement und Deeskalation"
|
||||
|
||||
persoenlich:
|
||||
- "Kundenorientierung und Empathie"
|
||||
- "Kommunikationsstärke (mündlich und schriftlich)"
|
||||
- "Verbindlichkeit und Zuverlässigkeit"
|
||||
- "Fähigkeit, auch unangenehme Botschaften zu vermitteln"
|
||||
- "Netzwerk-Kompetenz (internes Beziehungsmanagement)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABGRENZUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
abgrenzung:
|
||||
|
||||
nicht_aufgabe:
|
||||
- was: "Operative Problemlösung bei Incidents"
|
||||
zustaendig: "Service Desk / Service Owner"
|
||||
klarstellung: "SHM sorgt dafür, dass Probleme an der richtigen Stelle bearbeitet werden, löst sie aber nicht selbst."
|
||||
|
||||
- was: "Demand-Klassifizierung und -Priorisierung"
|
||||
zustaendig: "DPM"
|
||||
klarstellung: "SHM entscheidet OB etwas ein Demand ist, DPM WIE er priorisiert wird."
|
||||
|
||||
- was: "SLA-Verhandlung und -Abschluss"
|
||||
zustaendig: "SPM / Service Owner"
|
||||
klarstellung: "SHM kann Stakeholder-Perspektive einbringen, aber nicht verhandeln."
|
||||
|
||||
- was: "Strategische Portfolio-Steuerung"
|
||||
zustaendig: "Leitung SHM"
|
||||
klarstellung: "Operative Betreuung ja, strategische Weiterentwicklung liegt bei Leitung."
|
||||
|
||||
- was: "Vision Board / MB-Entscheidungen"
|
||||
zustaendig: "Leitung SHM (MB), Geschäftsführung (VB)"
|
||||
klarstellung: "Stakeholder-Manager:in bringt sich über DSR ein, nicht direkt in MB/VB."
|
||||
|
||||
# =============================================================================
|
||||
# ROLLE 2: LEITUNG STAKEHOLDER MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
leitung_shm:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# META
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "shm-l"
|
||||
rolle_name: "Leitung Stakeholder Management"
|
||||
aliases: ["SHM-Leitung", "Abteilungsleitung SHM"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Stakeholder-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: "[DIGIT-Leitung]"
|
||||
status: "entwurf"
|
||||
|
||||
kontext_tags:
|
||||
- "stakeholder-management"
|
||||
- "fuehrung"
|
||||
- "abteilungsleitung"
|
||||
- "strategie"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ROLLENZWECK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rollenzweck:
|
||||
|
||||
kurz: |
|
||||
Abteilungsleitung und disziplinarische Führungskraft der SHM-Funktion.
|
||||
Verantwortlich für strategische Steuerung, Qualitätssicherung und
|
||||
Vertretung der Stakeholder-Perspektive auf Leitungsebene.
|
||||
|
||||
ausfuehrlich: |
|
||||
Die Leitung Stakeholder Management führt die Abteilung
|
||||
"Digitale Schulen / QM, Service- und Prozessgovernance" und ist
|
||||
verantwortlich für die Gesamtperformance der SHM-Funktion.
|
||||
|
||||
Die Rolle umfasst:
|
||||
- Disziplinarische Führung der Stakeholder-Manager:innen
|
||||
- Strategische Steuerung des Stakeholder-Portfolios
|
||||
- Qualitätssicherung der Stakeholder-Beziehungen (VoC-Aggregation)
|
||||
- Vertretung der Stakeholder-Perspektive im Mission Board
|
||||
- Reporting an das Vision Board
|
||||
|
||||
Die Leitung agiert als Brücke zwischen operativer Kundenbetreuung
|
||||
und strategischer DIGIT-Steuerung.
|
||||
|
||||
verantwortung:
|
||||
fuer: "Gesamtperformance SHM, Stakeholder-Beziehungsqualität, Abteilungsführung"
|
||||
gegenueber: "DIGIT-Leitung / Vision Board"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ORGANISATORISCHE EINORDNUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
zuordnung:
|
||||
abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance"
|
||||
abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen
|
||||
position: "Abteilungsleitung"
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "DIGIT-Leitung / Vision Board"
|
||||
|
||||
fuehrt:
|
||||
- rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
fuehrungsart: "Disziplinarisch und fachlich"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KERNAUFGABEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kernaufgaben:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
fuehrung:
|
||||
|
||||
name: "Führung und Teamentwicklung"
|
||||
|
||||
aktivitaeten:
|
||||
- "Disziplinarische Führung der Stakeholder-Manager:innen"
|
||||
- "Ressourcenplanung und -allokation"
|
||||
- "Kompetenzentwicklung im Team"
|
||||
- "E3-Team-Sync leiten (zweiwöchentlich)"
|
||||
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
portfolio_steuerung:
|
||||
|
||||
name: "Strategische Portfolio-Steuerung"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Portfolio-Gesamtverantwortung"
|
||||
beschreibung: "Sicherstellen, dass alle Stakeholder angemessen betreut werden"
|
||||
|
||||
- aufgabe: "Priorisierung validieren und anpassen"
|
||||
frequenz: "Im Rahmen E2-Review"
|
||||
|
||||
- aufgabe: "Segmentierungslogik weiterentwickeln"
|
||||
bei: "Strukturelle Änderungen, neue Stakeholder-Typen"
|
||||
|
||||
- aufgabe: "Betreuungszuordnung steuern"
|
||||
beschreibung: "Welche:r Stakeholder-Manager:in betreut welche Ämter"
|
||||
|
||||
referenz: "shm_stakeholder-portfolio.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
voc_aggregation:
|
||||
|
||||
name: "Voice of Customer Aggregation"
|
||||
|
||||
beschreibung: |
|
||||
Aggregation der VoC-Daten aus dem Team zu einem Gesamtbild.
|
||||
Identifikation von Mustern, Trends und Handlungsbedarf.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "VoC-Cluster-Status bewerten"
|
||||
frequenz: "Quartalsweise (E2-Review)"
|
||||
output: "Ampel-Matrix pro Cluster"
|
||||
|
||||
- aufgabe: "Highlights konsolidieren"
|
||||
frequenz: "Quartalsweise"
|
||||
output: "Top-Highlights für Quartalsbericht"
|
||||
|
||||
- aufgabe: "Maßnahmen bei Cluster-Rot initiieren"
|
||||
mit: "Betroffene:r Stakeholder-Manager:in"
|
||||
|
||||
- aufgabe: "Strategische Erkenntnisse ableiten"
|
||||
frequenz: "Jährlich (E1-Review)"
|
||||
output: "Input für DIGIT-Strategie"
|
||||
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
review_reporting:
|
||||
|
||||
name: "Review und Reporting"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "E1-Jahresbericht erstellen"
|
||||
empfaenger: "Vision Board"
|
||||
inhalt: "SHM-Jahresbilanz, VoC-Gesamtbild, strategische Empfehlungen"
|
||||
referenz: "TPL-KSS-01"
|
||||
|
||||
- aufgabe: "E2-Quartals-Reviews leiten"
|
||||
frequenz: "Quartalsweise"
|
||||
varianten: ["Standard (Q1/Q3)", "Erweitert mit Retrospektive (Q2/Q4)"]
|
||||
referenz: "TPL-KSS-02"
|
||||
|
||||
- aufgabe: "E3-Team-Sync leiten"
|
||||
frequenz: "Zweiwöchentlich"
|
||||
referenz: "TPL-KSS-03"
|
||||
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
gremienarbeit:
|
||||
|
||||
name: "Gremienarbeit (MB, DSR, Kundenforum)"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Mission Board Teilnahme"
|
||||
rolle: "Vollwertiges Mitglied"
|
||||
funktion: "Stakeholder-Perspektive auf strategisch-taktischer Ebene"
|
||||
|
||||
- aufgabe: "DSR-Teilnahme (optional)"
|
||||
rolle: "Bei Bedarf, Eskalation, strategische Themen"
|
||||
anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen"
|
||||
|
||||
- aufgabe: "Kundenforum verantworten"
|
||||
formate: ["KF-01 Basisservices", "KF-02 Fachverfahren", "KF-03 Basis-Puls-Check"]
|
||||
rolle: "Gesamtverantwortung, ggf. Moderation"
|
||||
|
||||
referenz: "shm_d2p-integration.yaml, shm_engagement-framework.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
qualitaetssicherung:
|
||||
|
||||
name: "Qualitätssicherung SHM"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Beziehungsqualität im Portfolio überwachen"
|
||||
indikator: "Aggregierte Beziehungsqualitäts-Verteilung"
|
||||
|
||||
- aufgabe: "Methodische Standards sichern"
|
||||
was: "Turnus-Gespräche, Bedarfssteckbriefe, VoC-Dokumentation"
|
||||
|
||||
- aufgabe: "Eskalationen nachverfolgen"
|
||||
was: "Kritische Fälle, Muster erkennen"
|
||||
|
||||
- aufgabe: "Verbesserungsmaßnahmen steuern"
|
||||
quelle: "E2-Erweitert Review (Q2/Q4)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
|
||||
eigenstaendig:
|
||||
- befugnis: "Stakeholder-Priorisierung anpassen"
|
||||
beschreibung: "Änderung des Betreuungsmodus für einzelne Stakeholder"
|
||||
|
||||
- befugnis: "Betreuungszuordnung ändern"
|
||||
beschreibung: "Zuweisung Stakeholder → Stakeholder-Manager:in"
|
||||
|
||||
- befugnis: "Ressourcenallokation innerhalb SHM"
|
||||
beschreibung: "Verteilung der verfügbaren Kapazität"
|
||||
|
||||
- befugnis: "Maßnahmen bei VoC-Cluster-Rot"
|
||||
beschreibung: "Initiierung von Interventionen"
|
||||
|
||||
- befugnis: "E2-Review-Entscheidungen"
|
||||
beschreibung: "Anpassungen an SHM-Arbeitsweise, Priorisierung"
|
||||
|
||||
in_abstimmung:
|
||||
- befugnis: "Strukturelle SHM-Weiterentwicklung"
|
||||
abstimmung_mit: "Vision Board / DIGIT-Leitung"
|
||||
|
||||
- befugnis: "Ressourcenaufstockung"
|
||||
abstimmung_mit: "DIGIT-Leitung"
|
||||
|
||||
- befugnis: "Änderung der Segmentierungslogik"
|
||||
abstimmung_mit: "Vision Board (bei strategischer Relevanz)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- partner: "Stakeholder-Manager:innen"
|
||||
interaktion: "Führung, E3-Sync, Eskalationsempfang, Qualitätssicherung"
|
||||
frequenz: "Wöchentlich + laufend"
|
||||
|
||||
- partner: "Abteilungsleitung Planung (DPM)"
|
||||
interaktion: "Abstimmung SHM-DPM-Schnittstelle, DSR-Koordination"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "SPM-Leitung"
|
||||
interaktion: "Kundenforum-Koordination, SLA-bezogene Themen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "DIGIT-Leitung"
|
||||
interaktion: "Berichtslinie, strategische Abstimmung"
|
||||
frequenz: "Regelmäßig"
|
||||
|
||||
extern:
|
||||
- partner: "Vision Board"
|
||||
interaktion: "E1-Jahresbericht, strategische Eskalation"
|
||||
frequenz: "Jährlich (E1) + bei Bedarf"
|
||||
|
||||
- partner: "Amtsleitungen (bei Eskalation)"
|
||||
interaktion: "Direkte Klärung kritischer Stakeholder-Situationen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GREMIENROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gremienrollen:
|
||||
|
||||
- gremium: "Mission Board"
|
||||
rolle: "Vollwertiges Mitglied"
|
||||
funktion: "Vertretung der Stakeholder-Perspektive auf strategisch-taktischer Ebene"
|
||||
befugnisse: ["Stimmrecht", "Einbringung strategischer Stakeholder-Themen"]
|
||||
governance_referenz: "GOV-SHM-025"
|
||||
|
||||
- gremium: "DSR (Demand & Stakeholder-Runde)"
|
||||
rolle: "Optionale Teilnahme"
|
||||
funktion: "Bei Eskalation, strategischen Themen, Unterstützung"
|
||||
anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen"
|
||||
|
||||
- gremium: "Kundenforum (KF-01/02/03)"
|
||||
rolle: "Gesamtverantwortung"
|
||||
funktion: "Sicherstellung der Durchführung, ggf. Moderation"
|
||||
|
||||
- gremium: "Vision Board"
|
||||
rolle: "Berichterstatter (kein Mitglied)"
|
||||
funktion: "E1-Jahresbericht, strategische Eskalation"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
anforderungsprofil:
|
||||
|
||||
fachlich:
|
||||
- "Tiefes Verständnis der Verwaltungsstruktur und -kultur"
|
||||
- "Umfassendes Verständnis des DIGITOM"
|
||||
- "Kenntnisse in Service Management / ITIL4"
|
||||
- "Erfahrung mit Stakeholder-/Kundenmanagement"
|
||||
|
||||
methodisch:
|
||||
- "Führungskompetenz"
|
||||
- "Strategisches Denken und Handeln"
|
||||
- "Reporting und Management-Kommunikation"
|
||||
- "Qualitätsmanagement"
|
||||
- "Moderation von Gremien und Workshops"
|
||||
|
||||
persoenlich:
|
||||
- "Souveränität auf Leitungsebene"
|
||||
- "Diplomatisches Geschick"
|
||||
- "Durchsetzungsfähigkeit bei Wahrung der Kundenorientierung"
|
||||
- "Analytische Stärke (Mustererkennung, Aggregation)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABGRENZUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
abgrenzung:
|
||||
|
||||
nicht_aufgabe:
|
||||
- was: "Operative Stakeholder-Betreuung"
|
||||
zustaendig: "Stakeholder-Manager:in"
|
||||
klarstellung: "Leitung steuert, operative Betreuung liegt im Team."
|
||||
|
||||
- was: "DSR-Tagesgeschäft"
|
||||
zustaendig: "Stakeholder-Manager:in, DPM"
|
||||
klarstellung: "Leitung nimmt nur bei Bedarf teil."
|
||||
|
||||
- was: "Demand-Entscheidungen"
|
||||
zustaendig: "DSR, Mission Board"
|
||||
klarstellung: "Leitung bringt Stakeholder-Perspektive ein, entscheidet nicht über einzelne Demands."
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-ENTSCHEIDUNGEN (NEU)
|
||||
# =============================================================================
|
||||
|
||||
governance_entscheidungen:
|
||||
|
||||
- id: "GOV-SHM-025"
|
||||
datum: "2025-12-10"
|
||||
quelle_modul: "Rollenbeschreibungen (Phase 6)"
|
||||
|
||||
frage: |
|
||||
Ist die Leitung SHM Mitglied im Mission Board?
|
||||
|
||||
entscheidung: |
|
||||
Ja. Die Leitung Stakeholder Management ist vollwertiges Mitglied
|
||||
im Mission Board.
|
||||
|
||||
begruendung: |
|
||||
Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene
|
||||
vertreten sein. Während die operative DSR-Arbeit bei den
|
||||
Stakeholder-Manager:innen liegt, braucht das MB eine Person, die:
|
||||
- den Gesamt-Überblick über das Stakeholder-Portfolio hat
|
||||
- strategische Stakeholder-Themen einbringen kann
|
||||
- Entscheidungsauswirkungen auf Stakeholder bewerten kann
|
||||
|
||||
Dies präzisiert GOV-SHM-022: "SHM ist kein ständiges MB-Mitglied"
|
||||
bezieht sich auf die operative Rolle (Stakeholder-Manager:in),
|
||||
nicht auf die Leitungsrolle.
|
||||
|
||||
auswirkung_auf:
|
||||
- dokument: "shm_rollen.yaml"
|
||||
abschnitt: "leitung_shm.gremienrollen"
|
||||
- dokument: "shm_d2p-integration.yaml"
|
||||
abschnitt: "shm_rolle_mission_board"
|
||||
aenderung: "Präzisierung erforderlich"
|
||||
|
||||
status: "final"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2024-12-03"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: "Platzhalter erstellt"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-10"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Phase 6 abgeschlossen:
|
||||
- Rollenbeschreibung Stakeholder-Manager:in vollständig
|
||||
- Rollenbeschreibung Leitung SHM vollständig
|
||||
- Governance-Entscheidung GOV-SHM-025 (MB-Mitgliedschaft Leitung)
|
||||
File diff suppressed because it is too large
Load diff
1540
#03_stakeholder-management/#03.2_governance/shm_raci.yaml
Normal file
1540
#03_stakeholder-management/#03.2_governance/shm_raci.yaml
Normal file
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# SHM Lifecycle Blueprint
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 3
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: "Customer Journey (DSV)"
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 3]
|
||||
700
#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml
Normal file
700
#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml
Normal file
|
|
@ -0,0 +1,700 @@
|
|||
# =============================================================================
|
||||
# STAKEHOLDER-INFORMATIONS-MANAGEMENT-SYSTEM (SIMS)
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Konzept (Informationsmanagement)
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-11
|
||||
# Status: Entwurf
|
||||
# Entwicklungsphase: 10
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-K-05"
|
||||
name: "Stakeholder-Informations-Management-System (SIMS)"
|
||||
typ: "Konzept"
|
||||
|
||||
zweck: |
|
||||
Das SIMS ist das zentrale Informationssystem für die SHM-Funktion.
|
||||
Es dient der strukturierten Erfassung, Pflege und Auswertung aller
|
||||
stakeholderbezogenen Informationen, die für die Betreuung und
|
||||
Steuerung des Stakeholder-Portfolios erforderlich sind.
|
||||
|
||||
abgrenzung:
|
||||
was_sims_ist:
|
||||
- "Zentraler Ablageort für Stakeholder-Stammdaten"
|
||||
- "Dokumentationssystem für Interaktionen und Bedarfe"
|
||||
- "Grundlage für operative Steuerung und Reporting"
|
||||
|
||||
was_sims_nicht_ist:
|
||||
- "Kein Ticket-System (bleibt beim Service Desk)"
|
||||
- "Kein Demand-Management-Tool (bleibt bei DPM)"
|
||||
- "Kein CRM im vertrieblichen Sinne"
|
||||
|
||||
design_prinzipien:
|
||||
|
||||
- id: "DP-01"
|
||||
name: "Entscheidungsorientierung"
|
||||
beschreibung: |
|
||||
Jedes erfasste Attribut muss mindestens eine der SHM-Kernentscheidungen
|
||||
unterstützen (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung).
|
||||
Daten ohne Entscheidungsbezug werden nicht erfasst.
|
||||
|
||||
- id: "DP-02"
|
||||
name: "Single Source of Truth"
|
||||
beschreibung: |
|
||||
SIMS ist die führende Quelle für Stakeholder-Stammdaten innerhalb
|
||||
der SHM-Funktion. Redundante Datenhaltung ist zu vermeiden.
|
||||
|
||||
- id: "DP-03"
|
||||
name: "Minimale Komplexität"
|
||||
beschreibung: |
|
||||
Die Struktur wird so einfach wie möglich gehalten. Komplexität
|
||||
wird nur dort zugelassen, wo sie nachweislich Mehrwert schafft.
|
||||
|
||||
- id: "DP-04"
|
||||
name: "Plattformunabhängigkeit"
|
||||
beschreibung: |
|
||||
Das Konzept beschreibt fachliche Anforderungen, nicht technische
|
||||
Umsetzung. Die Wahl des Werkzeugs erfolgt separat.
|
||||
|
||||
konzept_referenzen:
|
||||
- dokument: "shm_schema_amtssteckbrief.yaml"
|
||||
beschreibung: "Attribut-Schema für Stakeholder-Stammdaten"
|
||||
- dokument: "shm_schema_bedarfssteckbrief.yaml"
|
||||
beschreibung: "Attribut-Schema für Bedarfsdokumentation"
|
||||
- dokument: "shm_engagement-framework.yaml"
|
||||
beschreibung: "Interaktionsformate und Dokumentationsanforderungen"
|
||||
- dokument: "shm_voice-of-customer.yaml"
|
||||
beschreibung: "Feedback-Dimensionen und Aggregationslogik"
|
||||
- dokument: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
beschreibung: "Review-Artefakte und Reporting-Anforderungen"
|
||||
|
||||
# =============================================================================
|
||||
# INFORMATIONSOBJEKTE
|
||||
# =============================================================================
|
||||
|
||||
informationsobjekte:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Informationsobjekte bilden den Kern des SIMS.
|
||||
Sie stehen in definierten Beziehungen zueinander.
|
||||
|
||||
objekte:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# AMTS-STECKBRIEF (Kernobjekt)
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-01"
|
||||
name: "Amts-Steckbrief"
|
||||
|
||||
beschreibung: |
|
||||
Zentrales Datenobjekt pro Stakeholder (Amt/Organisationseinheit).
|
||||
Enthält Stammdaten, Segmentierung, Priorisierung und Betreuungsstatus.
|
||||
|
||||
schema_referenz: "shm_schema_amtssteckbrief.yaml"
|
||||
|
||||
charakter: "Persistentes Stammdatenobjekt"
|
||||
|
||||
lebenszyklus:
|
||||
anlage: "Bei Aufnahme ins Portfolio"
|
||||
pflege: "Laufend durch zugeordneten Stakeholder-Manager"
|
||||
abschluss: "Bei Herauslösung aus Portfolio (selten)"
|
||||
|
||||
untergeordnete_elemente:
|
||||
- "Gesprächsprotokolle (als Anhänge/Untereinträge)"
|
||||
- "Interventionsdokumentation"
|
||||
- "VoC-Feedback-Einträge"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEDARFSSTECKBRIEF
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-02"
|
||||
name: "Bedarfssteckbrief"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation eines konkreten Stakeholder-Bedarfs. Entsteht aus
|
||||
der Bedarfsbewertung und dient als Übergabedokument an nachgelagerte
|
||||
Funktionen (Service Desk, SPM, DPM).
|
||||
|
||||
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
charakter: "Transaktionsobjekt mit Lebenszyklus"
|
||||
|
||||
lebenszyklus:
|
||||
anlage: "Bei Bedarfserfassung durch SHM"
|
||||
pflege: "Status-Updates bei Bearbeitung"
|
||||
abschluss: "Bei Erledigung oder Ablehnung"
|
||||
|
||||
beziehung_zu_amt: |
|
||||
Jeder Bedarfssteckbrief ist genau einem Amt zugeordnet.
|
||||
Ein Amt kann mehrere Bedarfssteckbriefe haben.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# GESPRÄCHSPROTOKOLL
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-03"
|
||||
name: "Gesprächsprotokoll"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation von Turnus-Gesprächen, Workshops und anderen
|
||||
Interaktionsformaten. Wird dem jeweiligen Amt zugeordnet.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "datum"
|
||||
beschreibung: "Datum des Gesprächs"
|
||||
- attribut: "format"
|
||||
beschreibung: "Art des Formats (TF-01, TF-02, SF-01, etc.)"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
- attribut: "teilnehmer"
|
||||
beschreibung: "Teilnehmer (DIGIT-seitig und Kundenseite)"
|
||||
- attribut: "themen"
|
||||
beschreibung: "Besprochene Themen (Stichworte)"
|
||||
- attribut: "vereinbarungen"
|
||||
beschreibung: "Konkrete Vereinbarungen mit Verantwortung/Termin"
|
||||
- attribut: "feedback_notizen"
|
||||
beschreibung: "VoC-relevante Aussagen (für Aggregation)"
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
aufbewahrung: |
|
||||
Protokolle bleiben dauerhaft dem Amt zugeordnet und ermöglichen
|
||||
die Nachvollziehbarkeit der Betreuungshistorie.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# INTERVENTIONSDOKUMENTATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-04"
|
||||
name: "Interventionsdokumentation"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation von Interventionen bei angespannter oder kritischer
|
||||
Beziehungsqualität. Enthält Ursachenanalyse, Maßnahmenplan und
|
||||
Verlauf.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "anlass"
|
||||
beschreibung: "Auslöser der Intervention"
|
||||
- attribut: "beziehungsqualitaet_start"
|
||||
beschreibung: "Bewertung bei Interventionsbeginn"
|
||||
- attribut: "ursachenanalyse"
|
||||
beschreibung: "Identifizierte Ursachen"
|
||||
- attribut: "massnahmen"
|
||||
beschreibung: "Vereinbarte Maßnahmen mit Verantwortung/Termin"
|
||||
- attribut: "status"
|
||||
beschreibung: "Aktiv / Abgeschlossen / Abgebrochen"
|
||||
- attribut: "ergebnis"
|
||||
beschreibung: "Bewertung bei Abschluss"
|
||||
|
||||
referenz: "shm_engagement-framework.yaml → beziehungsqualitaet"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# VOC-FEEDBACK-EINTRAG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-05"
|
||||
name: "VoC-Feedback-Eintrag"
|
||||
|
||||
beschreibung: |
|
||||
Einzelnes Feedback-Element aus Stakeholder-Interaktionen.
|
||||
Wird aggregiert für Cluster-Analyse und Reporting.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief oder eigenständig"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "quelle"
|
||||
beschreibung: "Feedback-Quelle (Q-01 bis Q-06)"
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
- attribut: "datum"
|
||||
beschreibung: "Erfassungsdatum"
|
||||
- attribut: "dimension"
|
||||
beschreibung: "Zuordnung zu D1-D4"
|
||||
- attribut: "subdimension"
|
||||
beschreibung: "Konkrete Subdimension"
|
||||
- attribut: "tendenz"
|
||||
beschreibung: "Positiv / Neutral / Negativ"
|
||||
- attribut: "kernaussage"
|
||||
beschreibung: "Zusammenfassung in 1-2 Sätzen"
|
||||
|
||||
aggregationslogik: |
|
||||
Einzelne Einträge werden gemäß shm_voice-of-customer.yaml
|
||||
zu Clustern aggregiert und in die Review-Struktur eingespeist.
|
||||
|
||||
# =============================================================================
|
||||
# STRUKTURKONZEPT
|
||||
# =============================================================================
|
||||
|
||||
strukturkonzept:
|
||||
|
||||
beschreibung: |
|
||||
Das SIMS gliedert sich in logische Bereiche, die unterschiedliche
|
||||
Informationstypen und Nutzungskontexte adressieren.
|
||||
|
||||
bereiche:
|
||||
|
||||
- id: "B-01"
|
||||
name: "Stakeholder-Portfolio"
|
||||
beschreibung: |
|
||||
Zentrale Ablage aller Amts-Steckbriefe mit zugeordneten
|
||||
Untereinträgen (Protokolle, Interventionen, Feedback).
|
||||
inhalt:
|
||||
- "Amts-Steckbriefe (IO-01)"
|
||||
- "Gesprächsprotokolle (IO-03)"
|
||||
- "Interventionsdokumentation (IO-04)"
|
||||
- "VoC-Feedback-Einträge (IO-05)"
|
||||
primaere_nutzer: "Stakeholder-Manager (operativ)"
|
||||
|
||||
- id: "B-02"
|
||||
name: "Bedarfsdokumentation"
|
||||
beschreibung: |
|
||||
Ablage aller Bedarfssteckbriefe mit Verlinkung zum
|
||||
zugehörigen Amt.
|
||||
inhalt:
|
||||
- "Bedarfssteckbriefe (IO-02)"
|
||||
primaere_nutzer: "Stakeholder-Manager, DPM (bei Übergabe)"
|
||||
|
||||
- id: "B-03"
|
||||
name: "Auswertungen und Reports"
|
||||
beschreibung: |
|
||||
Bereich für aggregierte Sichten, Dashboards und
|
||||
vorbereitete Reports (E1, E2).
|
||||
inhalt:
|
||||
- "Views (siehe Abschnitt views)"
|
||||
- "Report-Vorlagen"
|
||||
primaere_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "B-04"
|
||||
name: "Arbeitsmaterialien"
|
||||
beschreibung: |
|
||||
Ablage für Templates, Leitfäden und Checklisten,
|
||||
die im SHM-Alltag verwendet werden.
|
||||
inhalt:
|
||||
- "Gesprächsvorlagen"
|
||||
- "Checklisten"
|
||||
- "Leitfäden"
|
||||
primaere_nutzer: "Stakeholder-Manager"
|
||||
referenz: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
beziehungen:
|
||||
|
||||
beschreibung: |
|
||||
Die Informationsobjekte stehen in folgenden Beziehungen zueinander.
|
||||
|
||||
beziehungsmodell: |
|
||||
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ AMTS-STECKBRIEF │
|
||||
│ (IO-01) │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
|
||||
│ │ Gesprächs- │ │Interventions│ │ VoC-Feedback- │ │
|
||||
│ │ protokolle │ │dokumentation│ │ Einträge │ │
|
||||
│ │ (IO-03) │ │ (IO-04) │ │ (IO-05) │ │
|
||||
│ │ [0..*] │ │ [0..*] │ │ [0..*] │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
|
||||
└───────────────────────────┬─────────────────────────────────┘
|
||||
│
|
||||
│ 1:n
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ BEDARFSSTECKBRIEF │
|
||||
│ (IO-02) │
|
||||
│ [0..*] │
|
||||
└─────────────────────────────┘
|
||||
|
||||
kardinalitaeten:
|
||||
- "Amt 1 : n Bedarfssteckbrief"
|
||||
- "Amt 1 : n Gesprächsprotokoll"
|
||||
- "Amt 1 : n Interventionsdokumentation"
|
||||
- "Amt 1 : n VoC-Feedback-Eintrag"
|
||||
|
||||
# =============================================================================
|
||||
# VIEWS (AUSWERTUNGSPERSPEKTIVEN)
|
||||
# =============================================================================
|
||||
|
||||
views:
|
||||
|
||||
beschreibung: |
|
||||
Views sind vordefinierte Auswertungsperspektiven auf die SIMS-Daten.
|
||||
Sie unterstützen die operative Arbeit und das Management-Reporting.
|
||||
|
||||
hinweis: |
|
||||
Die folgenden Views sind ein initialer Vorschlag basierend auf den
|
||||
identifizierten Nutzungsszenarien. Sie sind im Rahmen der Einführung
|
||||
zu validieren und nach Praxiserprobung anzupassen.
|
||||
|
||||
kategorien:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# PORTFOLIO-MANAGEMENT
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Portfolio-Management"
|
||||
beschreibung: "Überblick und Steuerung des Stakeholder-Portfolios"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-PF-01"
|
||||
name: "Stakeholder nach Prio-Stufe"
|
||||
zweck: "Überblick Portfolioverteilung"
|
||||
filterkriterien: "Gruppierung nach Prio-Stufe (Key/Aktiv/Standard/Basis)"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-PF-02"
|
||||
name: "Meine Stakeholder"
|
||||
zweck: "Persönliche Arbeitsliste"
|
||||
filterkriterien: "Filter: Betreuungszuordnung = aktueller Nutzer"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-PF-03"
|
||||
name: "Stakeholder nach Dezernat"
|
||||
zweck: "Organisatorische Cluster-Sicht"
|
||||
filterkriterien: "Gruppierung nach Dezernat"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-PF-04"
|
||||
name: "Neuzugänge"
|
||||
zweck: "Onboarding-Pipeline"
|
||||
filterkriterien: "Filter: Anlage < 90 Tage oder Status = Neu"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEZIEHUNGSQUALITÄT
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Beziehungsqualität"
|
||||
beschreibung: "Monitoring der Beziehungsqualität und Interventionen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-BQ-01"
|
||||
name: "Beziehungs-Ampel"
|
||||
zweck: "Gesamtübersicht Beziehungsqualität"
|
||||
filterkriterien: "Alle Stakeholder mit Spalte Beziehungsqualität"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-BQ-02"
|
||||
name: "Interventionsbedarf"
|
||||
zweck: "Fokus auf Problemfälle"
|
||||
filterkriterien: "Filter: Beziehungsqualität = Angespannt ODER Kritisch"
|
||||
primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "V-BQ-03"
|
||||
name: "Aktive Maßnahmenpläne"
|
||||
zweck: "Nachverfolgung laufender Interventionen"
|
||||
filterkriterien: "Filter: Interventionsdokumentation.Status = Aktiv"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# ENGAGEMENT / TURNUS
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Engagement und Turnus"
|
||||
beschreibung: "Planung und Nachverfolgung von Stakeholder-Interaktionen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-EN-01"
|
||||
name: "Anstehende Turnus-Termine"
|
||||
zweck: "Terminplanung"
|
||||
filterkriterien: "Filter: Nächster Turnus ≤ 30 Tage"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-EN-02"
|
||||
name: "Überfällige Kontakte"
|
||||
zweck: "Eskalations-Früherkennung"
|
||||
filterkriterien: "Filter: Letzter Kontakt > Soll-Frequenz (abgeleitet aus Betreuungsmodus)"
|
||||
primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "V-EN-03"
|
||||
name: "Key-Stakeholder Jahresübersicht"
|
||||
zweck: "Strategische Betreuungsplanung"
|
||||
filterkriterien: "Filter: Prio = Key; Anzeige: alle geplanten Termine"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEDARFSDOKUMENTATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Bedarfsdokumentation"
|
||||
beschreibung: "Überblick und Nachverfolgung von Stakeholder-Bedarfen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-BD-01"
|
||||
name: "Offene Bedarfe pro Stakeholder"
|
||||
zweck: "Gesprächsvorbereitung"
|
||||
filterkriterien: "Gruppierung nach Amt; Filter: Status ≠ Abgeschlossen"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-BD-02"
|
||||
name: "Bedarfe nach Routing-Pfad"
|
||||
zweck: "Prozess-Monitoring"
|
||||
filterkriterien: "Gruppierung nach Routing (REQ/SPM/DPM/SOR)"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-BD-03"
|
||||
name: "Bedarfe in Wartestellung"
|
||||
zweck: "Follow-up-Liste"
|
||||
filterkriterien: "Filter: Status = Übergeben, wartend"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REVIEW / REPORTING
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Review und Reporting"
|
||||
beschreibung: "Aggregierte Sichten für E1/E2-Reviews"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-RV-01"
|
||||
name: "E2-Quartalsdaten"
|
||||
zweck: "Vorbereitung Quartalsbericht"
|
||||
filterkriterien: "Aggregation: Kontakte, Bedarfe, Interventionen im Quartal"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e2_quartals_review"
|
||||
|
||||
- id: "V-RV-02"
|
||||
name: "VoC-Cluster-Übersicht"
|
||||
zweck: "Feedback-Aggregation"
|
||||
filterkriterien: "Gruppierung nach Cluster; Anzeige: Ampel-Status"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_voice-of-customer.yaml → cluster"
|
||||
|
||||
- id: "V-RV-03"
|
||||
name: "E1-Jahresübersicht"
|
||||
zweck: "Vorbereitung Jahresbericht"
|
||||
filterkriterien: "Aggregation aller relevanten Metriken auf Jahresebene"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e1_jahres_review"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
beschreibung: |
|
||||
SIMS steht nicht isoliert, sondern hat konzeptionelle Schnittstellen
|
||||
zu anderen Informationssystemen und Funktionen. Diese Schnittstellen
|
||||
sind zunächst als Informationsflüsse zu verstehen, nicht als
|
||||
technische Integrationen.
|
||||
|
||||
schnittstellen:
|
||||
|
||||
- id: "SS-01"
|
||||
name: "DPM (Demand-Portfolio-Management)"
|
||||
|
||||
richtung: "SIMS → DPM"
|
||||
|
||||
beschreibung: |
|
||||
Bei Routing-Entscheidung ROUTE-DPM wird der Bedarfssteckbrief
|
||||
an DPM übergeben. DPM übernimmt dann die weitere Bearbeitung
|
||||
im Demand-Lifecycle.
|
||||
|
||||
uebergabeobjekt: "Bedarfssteckbrief (IO-02)"
|
||||
|
||||
informationsfluss:
|
||||
von_sims:
|
||||
- "Bedarfssteckbrief mit Stakeholder-Kontext"
|
||||
- "User Stories (falls erhoben)"
|
||||
von_dpm:
|
||||
- "Status-Updates zum Demand"
|
||||
- "Entscheidungen (DSR/MB)"
|
||||
|
||||
governance_referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
- id: "SS-02"
|
||||
name: "SPM (Service-Portfolio-Management)"
|
||||
|
||||
richtung: "Bidirektional"
|
||||
|
||||
beschreibung: |
|
||||
SPM liefert Service-Performance-Daten, die für Turnus-Gespräche
|
||||
und Beziehungsqualitäts-Bewertung relevant sind. SHM liefert
|
||||
Kundenfeedback und Bedarfe im Service-Kontext.
|
||||
|
||||
informationsfluss:
|
||||
von_spm:
|
||||
- "SLA-Einhaltung pro Amt/Service"
|
||||
- "Bekannte Service-Probleme"
|
||||
- "Service-Änderungen (für proaktive Kommunikation)"
|
||||
von_sims:
|
||||
- "VoC-Feedback zu Services"
|
||||
- "Bedarfssteckbriefe (bei ROUTE-SPM)"
|
||||
|
||||
hinweis: |
|
||||
Der Informationsfluss erfolgt im MVP manuell (Abfrage vor
|
||||
Turnus-Gespräch). Eine technische Integration ist optional.
|
||||
|
||||
- id: "SS-03"
|
||||
name: "Ticket-System (Service Desk)"
|
||||
|
||||
richtung: "Ticket-System → SIMS (lesend)"
|
||||
|
||||
beschreibung: |
|
||||
Für Turnus-Gespräche und Beziehungsqualitäts-Bewertung sind
|
||||
Informationen zu offenen Tickets pro Amt relevant.
|
||||
|
||||
informationsfluss:
|
||||
von_ticketsystem:
|
||||
- "Anzahl offener Tickets pro Amt"
|
||||
- "Eskalierte Tickets"
|
||||
- "Wiederkehrende Probleme"
|
||||
von_sims:
|
||||
- "(kein direkter Rückfluss)"
|
||||
|
||||
hinweis: |
|
||||
Im MVP erfolgt die Abfrage manuell. Eine automatisierte
|
||||
Einspielung ist bei entsprechendem Tooling möglich.
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
governance:
|
||||
|
||||
beschreibung: |
|
||||
Regeln für Datenpflege, Qualitätssicherung und Verantwortlichkeiten
|
||||
im SIMS.
|
||||
|
||||
datenpflege:
|
||||
|
||||
prinzip: |
|
||||
Jeder Datensatz hat genau einen Verantwortlichen für die Pflege.
|
||||
Die Verantwortung folgt der Betreuungszuordnung.
|
||||
|
||||
verantwortlichkeiten:
|
||||
|
||||
- objekt: "Amts-Steckbrief"
|
||||
verantwortlich: "Zugeordneter Stakeholder-Manager"
|
||||
aktualisierung: "Laufend, mindestens bei Turnus-Gespräch"
|
||||
|
||||
- objekt: "Bedarfssteckbrief"
|
||||
verantwortlich: "Erfassender Stakeholder-Manager"
|
||||
aktualisierung: "Bei Status-Änderungen"
|
||||
|
||||
- objekt: "Gesprächsprotokoll"
|
||||
verantwortlich: "Durchführender Stakeholder-Manager"
|
||||
aktualisierung: "Innerhalb von 5 Arbeitstagen nach Gespräch"
|
||||
|
||||
- objekt: "Interventionsdokumentation"
|
||||
verantwortlich: "Zugeordneter Stakeholder-Manager"
|
||||
aktualisierung: "Laufend während Intervention"
|
||||
|
||||
- objekt: "VoC-Feedback-Eintrag"
|
||||
verantwortlich: "Erfassender Stakeholder-Manager"
|
||||
aktualisierung: "Bei Erfassung (einmalig)"
|
||||
|
||||
qualitaetssicherung:
|
||||
|
||||
- id: "QS-01"
|
||||
name: "Vollständigkeitsprüfung Stammdaten"
|
||||
beschreibung: "Prüfung auf vollständige Pflichtfelder im Amts-Steckbrief"
|
||||
frequenz: "Quartalsweise (im Rahmen E2)"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml → validierung"
|
||||
|
||||
- id: "QS-02"
|
||||
name: "Aktualitätsprüfung"
|
||||
beschreibung: "Identifikation von Datensätzen ohne Aktualisierung > 12 Monate"
|
||||
frequenz: "Halbjährlich"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
|
||||
- id: "QS-03"
|
||||
name: "Konsistenzprüfung Prio/Betreuungsmodus"
|
||||
beschreibung: "Prüfung, ob Betreuungsmodus zur Prio-Stufe passt"
|
||||
frequenz: "Quartalsweise (im Rahmen E2)"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml → validierung VAL-003"
|
||||
|
||||
archivierung:
|
||||
|
||||
prinzip: |
|
||||
Abgeschlossene Objekte (erledigte Bedarfe, beendete Interventionen)
|
||||
werden nicht gelöscht, sondern archiviert. Sie bleiben für
|
||||
Nachvollziehbarkeit und Trendanalysen zugänglich.
|
||||
|
||||
aufbewahrungsfristen:
|
||||
- objekt: "Amts-Steckbrief"
|
||||
frist: "Dauerhaft (solange Amt im Portfolio)"
|
||||
- objekt: "Bedarfssteckbrief"
|
||||
frist: "5 Jahre nach Abschluss"
|
||||
- objekt: "Gesprächsprotokoll"
|
||||
frist: "5 Jahre"
|
||||
- objekt: "Interventionsdokumentation"
|
||||
frist: "5 Jahre nach Abschluss"
|
||||
- objekt: "VoC-Feedback-Eintrag"
|
||||
frist: "3 Jahre"
|
||||
|
||||
hinweis: |
|
||||
Die Fristen sind initiale Vorschläge und ggf. an organisatorische
|
||||
oder rechtliche Vorgaben anzupassen.
|
||||
|
||||
# =============================================================================
|
||||
# EINFÜHRUNGSHINWEISE
|
||||
# =============================================================================
|
||||
|
||||
einfuehrung:
|
||||
|
||||
beschreibung: |
|
||||
Hinweise für die Einführung des SIMS in den operativen Betrieb.
|
||||
|
||||
empfohlenes_vorgehen:
|
||||
|
||||
- phase: "1. Toolauswahl"
|
||||
beschreibung: |
|
||||
Auswahl eines geeigneten Werkzeugs basierend auf den
|
||||
fachlichen Anforderungen dieses Konzepts.
|
||||
kriterien:
|
||||
- "Unterstützung strukturierter Datenerfassung"
|
||||
- "Flexible View-/Filtermöglichkeiten"
|
||||
- "Verlinkung zwischen Objekten"
|
||||
- "Zugänglichkeit für alle SHM-Mitarbeitenden"
|
||||
|
||||
- phase: "2. Pilotierung"
|
||||
beschreibung: |
|
||||
Erprobung mit einer Teilmenge des Portfolios (z.B. ein Dezernat)
|
||||
vor vollständigem Rollout.
|
||||
ziel: "Validierung der Struktur und Views"
|
||||
|
||||
- phase: "3. Initiale Befüllung"
|
||||
beschreibung: |
|
||||
Migration/Erfassung der Bestandsdaten für alle Stakeholder.
|
||||
hinweis: "Qualität vor Vollständigkeit bei der Erstbefüllung"
|
||||
|
||||
- phase: "4. Schulung"
|
||||
beschreibung: |
|
||||
Einweisung aller Stakeholder-Manager in Struktur und Nutzung.
|
||||
|
||||
- phase: "5. Review und Anpassung"
|
||||
beschreibung: |
|
||||
Nach 6 Monaten Betrieb: Review der Views und Struktur,
|
||||
Anpassung basierend auf Praxiserfahrung.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-11"
|
||||
autor: "Konzept-Sprint Phase 10"
|
||||
aenderung: |
|
||||
Initiale Erstellung:
|
||||
- Meta-Informationen und Design-Prinzipien
|
||||
- Informationsobjekte IO-01 bis IO-05 definiert
|
||||
- Strukturkonzept mit 4 Bereichen
|
||||
- 16 Views in 5 Kategorien (als Vorschlag)
|
||||
- Konzeptionelle Schnittstellen zu DPM, SPM, Ticket-System
|
||||
- Governance (Datenpflege, QS, Archivierung)
|
||||
- Einführungshinweise
|
||||
|
|
@ -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
|
||||
1071
#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml
Normal file
1071
#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml
Normal file
File diff suppressed because it is too large
Load diff
1179
#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml
Normal file
1179
#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,854 @@
|
|||
# =============================================================================
|
||||
# SHM KOORDINATIONS- UND STEUERUNGSSTRUKTUR
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Methodik
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-10
|
||||
# Status: Final (Phase 5)
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-M-02"
|
||||
name: "Koordinations- und Steuerungsstruktur"
|
||||
typ: "Methodik"
|
||||
|
||||
vorheriger_name: "Performance & Review"
|
||||
|
||||
begruendung_umbenennung: |
|
||||
Der ursprüngliche Name "Performance & Review" war zu stark durch eine
|
||||
betriebswirtschaftliche Steuerungslogik geprägt (Effizienz, Kontrolle,
|
||||
quantifizierte KPIs). Für SHM im Verwaltungskontext ist das nicht passend.
|
||||
|
||||
Der neue Name "Koordinations- und Steuerungsstruktur" betont:
|
||||
- Koordination als zentralen Modus (nicht Kontrolle)
|
||||
- Steuerung als legitimer Verwaltungsbegriff
|
||||
- Struktur statt Framework (weniger technisch)
|
||||
|
||||
Die Integration von REV-3 (Operative Koordination) wird dadurch
|
||||
konzeptionell stimmig.
|
||||
|
||||
zweck: |
|
||||
Die Koordinations- und Steuerungsstruktur definiert, wie SHM seine
|
||||
Arbeit reflektiert, koordiniert und kontinuierlich verbessert. Sie
|
||||
verbindet operative Abstimmung mit taktischer Steuerung und
|
||||
strategischer Rechenschaft.
|
||||
|
||||
itil4_referenz:
|
||||
practice: "Continual Improvement"
|
||||
ergaenzende_konzepte:
|
||||
- konzept: "Voice of Customer"
|
||||
quelle: "ITIL 4 Drive Stakeholder Value (DSV)"
|
||||
- konzept: "Measurement and Reporting"
|
||||
quelle: "ITIL 4 Direct Plan Improve (DPI)"
|
||||
|
||||
governance_referenzen:
|
||||
- id: "GOV-SHM-023"
|
||||
thema: "Fokus auf Ergebnis-Indikatoren"
|
||||
dokument: "readme_shm_governance-entscheidungs-log.yaml"
|
||||
- id: "GOV-SHM-024"
|
||||
thema: "Abgrenzung SHM/SPM im Reporting"
|
||||
dokument: "readme_shm_governance-entscheidungs-log.yaml"
|
||||
|
||||
konzept_referenzen:
|
||||
- dokument: "shm_voice-of-customer.yaml"
|
||||
beschreibung: "VoC als zentraler Steuerungsindikator"
|
||||
- dokument: "shm_engagement-framework.yaml"
|
||||
beschreibung: "Interaktionsformate, die VoC-Quellen liefern"
|
||||
- dokument: "shm_stakeholder-portfolio.yaml"
|
||||
beschreibung: "Beziehungsqualität als Steuerungsindikator"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDPRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
grundprinzipien:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Prinzipien leiten die Gestaltung der Koordinations- und
|
||||
Steuerungsstruktur. Sie reflektieren den Charakter von SHM als
|
||||
beziehungsorientierte Funktion im Verwaltungskontext.
|
||||
|
||||
prinzipien:
|
||||
|
||||
- id: "PRIN-01"
|
||||
name: "Qualität vor Effizienz"
|
||||
beschreibung: |
|
||||
Die zentrale Frage ist nicht "Wie viel?" oder "Wie schnell?",
|
||||
sondern "Wie gut?". Die Qualität der Stakeholder-Beziehungen
|
||||
und die Wirksamkeit der Betreuung stehen im Vordergrund.
|
||||
implikation: |
|
||||
Review-Fragen fokussieren auf Beziehungsqualität und
|
||||
Stakeholder-Wahrnehmung, nicht auf Durchsatzzahlen.
|
||||
|
||||
- id: "PRIN-02"
|
||||
name: "Koordination vor Kontrolle"
|
||||
beschreibung: |
|
||||
SHM arbeitet mit Abstimmung, Austausch und gemeinsamer
|
||||
Problemlösung – nicht mit hierarchischer Überwachung.
|
||||
Die Steuerungsstruktur ermöglicht Koordination, nicht Kontrolle.
|
||||
implikation: |
|
||||
REV-3 (Team-Sync) ist ein Koordinationsformat, kein
|
||||
Kontroll-Meeting. Keine Rechenschaftspflicht nach oben.
|
||||
|
||||
- id: "PRIN-03"
|
||||
name: "Lernen vor Messen"
|
||||
beschreibung: |
|
||||
Ziel ist Erkenntnisgewinn und kontinuierliche Verbesserung,
|
||||
nicht das Erfüllen von Kennzahlen. Metriken dienen dem Lernen,
|
||||
nicht der Rechtfertigung.
|
||||
implikation: |
|
||||
Keine KPI-Dashboards mit Zielerreichungsquoten. Stattdessen
|
||||
qualitative Reflexion und Musteranalyse.
|
||||
|
||||
- id: "PRIN-04"
|
||||
name: "Qualitative Einschätzungen vor quantifizierten Kennzahlen"
|
||||
beschreibung: |
|
||||
Beziehungen sind mehrdimensional, kontextabhängig und dynamisch.
|
||||
Ihre Qualität lässt sich nicht sinnvoll auf eine Zahl reduzieren.
|
||||
Quantifizierung suggeriert eine Präzision, die bei Beziehungsarbeit
|
||||
nicht existiert – und erzeugt perverse Anreize: Was gemessen wird,
|
||||
wird optimiert, nicht notwendigerweise verbessert.
|
||||
implikation: |
|
||||
Berichte enthalten narrative Einschätzungen mit Kontext und
|
||||
Ursachenbezug. Zahlen werden nur dort verwendet, wo sie echten
|
||||
Informationsgewinn bieten (z.B. Verteilungen im Portfolio),
|
||||
nicht als Selbstzweck.
|
||||
beispiel:
|
||||
statt: "78% der Turnus-Gespräche durchgeführt"
|
||||
besser: |
|
||||
Turnus-Gespräche finden regelmäßig statt. Bei zwei Key-Stakeholdern
|
||||
kam es zu Verschiebungen wegen Personalwechsel auf Fachbereichsseite.
|
||||
abgrenzung: |
|
||||
Dies ist kein Plädoyer gegen jede Form von Strukturierung. Die
|
||||
Ampel-Matrix (VoC-Cluster) ist eine qualitative Verdichtung mit
|
||||
visuellem Ordnungsschema – keine Quantifizierung.
|
||||
|
||||
- id: "PRIN-05"
|
||||
name: "Stakeholder-Stimme als Kompass"
|
||||
beschreibung: |
|
||||
Die Wahrnehmung und das Feedback der Stakeholder sind der
|
||||
zentrale Gradmesser für den Erfolg von SHM. Das Voice-of-Customer-
|
||||
Konzept wird strukturell verankert.
|
||||
implikation: |
|
||||
VoC-Erkenntnisse sind Kernelement aller Review-Formate.
|
||||
Keine Bewertung ohne Stakeholder-Perspektive.
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# STEUERUNGSINDIKATOREN
|
||||
# =============================================================================
|
||||
|
||||
steuerungsindikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Basierend auf GOV-SHM-023 fokussiert die SHM-Steuerung auf
|
||||
Ergebnis-Indikatoren (Wirkung), nicht auf Prozess-Indikatoren
|
||||
(Aktivitäten).
|
||||
|
||||
primaere_indikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Diese Indikatoren werden in den Reviews (REV-1, REV-2) systematisch
|
||||
betrachtet und berichtet.
|
||||
|
||||
indikatoren:
|
||||
|
||||
- id: "IND-P-01"
|
||||
name: "Beziehungsqualität"
|
||||
quelle: "shm_stakeholder-portfolio.yaml"
|
||||
beschreibung: |
|
||||
Verteilung der Beziehungsqualitäts-Stufen (Exzellent, Gut,
|
||||
Angespannt, Kritisch) im Portfolio.
|
||||
betrachtung: "Verteilung und Veränderung"
|
||||
|
||||
- id: "IND-P-02"
|
||||
name: "VoC-Cluster-Ampeln"
|
||||
quelle: "shm_voice-of-customer.yaml"
|
||||
beschreibung: |
|
||||
Kritikalitätsbewertung der thematischen Cluster (D1-D4)
|
||||
in der Ampel-Matrix.
|
||||
betrachtung: "Status und Trend"
|
||||
|
||||
- id: "IND-P-03"
|
||||
name: "VoC-Highlights"
|
||||
quelle: "shm_voice-of-customer.yaml"
|
||||
beschreibung: |
|
||||
Qualitative Erkenntnisse aus dem Stakeholder-Feedback
|
||||
(positiv, kritisch, insight, trend).
|
||||
betrachtung: "Narrative Auswertung"
|
||||
|
||||
sekundaere_indikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Diese Indikatoren werden nicht im Review berichtet, können aber
|
||||
bei operativen Problemen intern herangezogen werden.
|
||||
|
||||
indikatoren:
|
||||
|
||||
- id: "IND-S-01"
|
||||
name: "Turnus-Gespräche Durchführungsquote"
|
||||
verwendung: "Nur bei Verdacht auf systematische Lücken"
|
||||
|
||||
- id: "IND-S-02"
|
||||
name: "Routing-Statistik"
|
||||
verwendung: "Nur bei Analyse von Bedarfsmustern"
|
||||
|
||||
- id: "IND-S-03"
|
||||
name: "Durchlaufzeiten Bedarfssteckbrief"
|
||||
verwendung: "Nur bei Engpass-Analyse"
|
||||
|
||||
# =============================================================================
|
||||
# ENTSCHEIDUNGSTYPEN
|
||||
# =============================================================================
|
||||
|
||||
entscheidungstypen:
|
||||
|
||||
beschreibung: |
|
||||
Die Koordinations- und Steuerungsstruktur unterstützt drei
|
||||
Entscheidungstypen auf unterschiedlichen Ebenen. Diese bilden
|
||||
das funktionale Fundament der Struktur.
|
||||
|
||||
Hinweis: Die ursprünglich separaten Typen (Portfolio-Qualität
|
||||
und Funktions-Weiterentwicklung) wurden zu einem konsolidierten
|
||||
REV-2-Format zusammengeführt (analog DPM-Portfolio-Review).
|
||||
|
||||
uebersicht:
|
||||
|
||||
- id: "REV-1"
|
||||
name: "Auftragserfüllung"
|
||||
ebene: "Strategisch"
|
||||
frequenz: "Jährlich + Halbjahres-Pulse"
|
||||
adressat: "Vision Board"
|
||||
|
||||
- id: "REV-2"
|
||||
name: "Portfolio-Qualität, Lernen & Verbesserung"
|
||||
ebene: "Taktisch"
|
||||
frequenz: "Quartalsweise"
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Operative Koordination"
|
||||
ebene: "Operativ"
|
||||
frequenz: "2-wöchentlich bis monatlich"
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
typen:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-1: AUFTRAGSERFÜLLUNG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-1"
|
||||
name: "Auftragserfüllung"
|
||||
|
||||
kernfrage: "Leistet SHM, wofür es da ist?"
|
||||
|
||||
beschreibung: |
|
||||
Strategische Bewertung, ob die Funktion SHM ihren Zweck im
|
||||
DIGITOM-Gesamtkontext erfüllt. Die Stakeholder-Stimme (Voice
|
||||
of Customer) ist hier ein zentraler Input.
|
||||
|
||||
adressat: "DIGIT-Leitung, Vision Board"
|
||||
|
||||
charakter: "Strategisch-legitimatorisch"
|
||||
|
||||
frequenz: "Jährlich"
|
||||
|
||||
zusaetzlich:
|
||||
name: "Pulse-Update"
|
||||
frequenz: "Halbjährlich (Q2)"
|
||||
umfang: "Kurzform (max. 2 Seiten)"
|
||||
zweck: "Standortbestimmung zwischen Jahresberichten"
|
||||
|
||||
betrachtungsweise: |
|
||||
Qualitative Gesamteinschätzung mit narrativer Begründung.
|
||||
Keine Scorecard, sondern strukturierter Bericht mit
|
||||
Einordnung und Handlungsempfehlungen.
|
||||
|
||||
typische_fragestellungen:
|
||||
- "Werden die Stakeholder-Beziehungen professionell gepflegt?"
|
||||
- "Funktioniert die Bedarfserkennung und -weiterleitung?"
|
||||
- "Wie nehmen die Ämter DIGIT als Partner wahr?"
|
||||
- "Trägt SHM zur strategischen Ausrichtung von DIGIT bei?"
|
||||
|
||||
voc_relevanz: |
|
||||
REV-1 integriert die aggregierte Stakeholder-Stimme als
|
||||
zentralen Erfolgsindikator. Die Frage "Erfüllen wir unseren
|
||||
Auftrag?" wird wesentlich durch "Was sagen die Stakeholder?"
|
||||
beantwortet.
|
||||
|
||||
voc_output: "Verdichtung REV-1 (Jahres-Review)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-2: PORTFOLIO-QUALITÄT, LERNEN & VERBESSERUNG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-2"
|
||||
name: "Portfolio-Qualität, Lernen & Verbesserung"
|
||||
|
||||
kernfrage: |
|
||||
Wie steht es um unsere Stakeholder-Beziehungen, was lernen wir
|
||||
daraus, und was müssen wir verbessern?
|
||||
|
||||
beschreibung: |
|
||||
Kombiniertes Format für Portfolio-Analyse und kontinuierliche
|
||||
Verbesserung. Quartalsweise Betrachtung des Stakeholder-Portfolios
|
||||
mit integrierter CI-Komponente. In Q2 und Q4 erweitertes Format
|
||||
mit Retrospektive und Verbesserungsplanung.
|
||||
|
||||
Diese Konsolidierung folgt dem bewährten Ansatz des DPM-Portfolio-
|
||||
Reviews, das Portfolio-Analyse und Prozessverbesserung ebenfalls
|
||||
in einem Format verbindet.
|
||||
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
charakter: "Taktisch-reflexiv"
|
||||
|
||||
frequenz: "Quartalsweise"
|
||||
|
||||
varianten:
|
||||
|
||||
- variante: "Standard (Q1, Q3)"
|
||||
dauer: "60-90 Minuten"
|
||||
fokus: "Portfolio-Analyse, VoC-Status, Maßnahmen-Tracking"
|
||||
ci_anteil: "Kurz (15 Min): Status offener Maßnahmen, neue Themen sammeln"
|
||||
|
||||
- variante: "Erweitert (Q2, Q4)"
|
||||
dauer: "2-3 Stunden"
|
||||
fokus: "Portfolio-Analyse + Retrospektive + Verbesserungsplanung"
|
||||
ci_anteil: "Deep-Dive: Was lief gut/schlecht? Strukturelle Verbesserungen"
|
||||
zusatz_q4: "Vorbereitung REV-1-Jahresbericht"
|
||||
|
||||
inhaltliche_dimensionen:
|
||||
|
||||
portfolio_analyse:
|
||||
- dimension: "Beziehungsqualitäts-Verteilung"
|
||||
beschreibung: "Verteilung EX/GU/AN/KR im Portfolio"
|
||||
- dimension: "VoC-Cluster-Status"
|
||||
beschreibung: "Ampel-Matrix D1-D4"
|
||||
- dimension: "Veränderungen"
|
||||
beschreibung: "Entwicklung gegenüber Vorquartal"
|
||||
- dimension: "Highlights"
|
||||
beschreibung: "Relevante Einzelerkenntnisse"
|
||||
- dimension: "Interventionen"
|
||||
beschreibung: "Laufende und neue Interventionsfälle"
|
||||
|
||||
ci_komponente:
|
||||
- dimension: "Maßnahmen-Status"
|
||||
beschreibung: "Review offener Verbesserungsmaßnahmen"
|
||||
- dimension: "Wirksamkeit"
|
||||
beschreibung: "Wurden umgesetzte Maßnahmen wirksam?"
|
||||
- dimension: "Neue Themen"
|
||||
beschreibung: "Erkannte Verbesserungspotenziale"
|
||||
- dimension: "Retrospektive (nur Q2/Q4)"
|
||||
beschreibung: "Was lief gut? Was war schwierig?"
|
||||
- dimension: "Schnittstellen-Feedback (nur Q2/Q4)"
|
||||
beschreibung: "Rückmeldungen von DPM, SPM, Service Desk"
|
||||
|
||||
output:
|
||||
- "SHM-Quartalsbericht (inkl. Maßnahmen-Status)"
|
||||
- "Bei Q2/Q4: Aktualisierter Verbesserungsplan"
|
||||
- "Input für DPM-Portfolio-Review"
|
||||
- "Bei Q4: Vorarbeit für REV-1-Jahresbericht"
|
||||
|
||||
voc_relevanz: |
|
||||
VoC informiert sowohl die Portfolio-Betrachtung als auch die
|
||||
Verbesserungsplanung:
|
||||
- Portfolio: Welche Beziehungen sind belastet? Welche Muster?
|
||||
- CI: Systematische Muster, die auf Prozessprobleme hindeuten
|
||||
|
||||
voc_output: "Verdichtung REV-2 (Quartals-Review)"
|
||||
|
||||
konsolidierungshinweis: |
|
||||
Dieses Format ersetzt die ursprünglich separaten Entscheidungstypen
|
||||
(vormals E2 für Portfolio-Qualität & Lernen und E4 für Funktions-Weiterentwicklung).
|
||||
Die Zusammenlegung reduziert Overhead und ist konsistent mit dem
|
||||
DPM-Portfolio-Review-Ansatz.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-3: OPERATIVE KOORDINATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Operative Koordination"
|
||||
|
||||
kernfrage: "Welche laufenden Themen müssen wir im Team abstimmen?"
|
||||
|
||||
beschreibung: |
|
||||
Regelmäßiger Austausch im SHM-Team zu laufenden Stakeholder-
|
||||
Themen. Fokus auf kollegiale Beratung, Wissenstransfer und
|
||||
gemeinsame Problemlösung.
|
||||
|
||||
adressat: "SHM-Team (Stakeholder-Manager untereinander)"
|
||||
|
||||
charakter: "Operativ-koordinierend"
|
||||
|
||||
frequenz: "2-wöchentlich oder monatlich"
|
||||
|
||||
betrachtungsweise: |
|
||||
Fall-basiert und anlassbezogen. Kein formaler Review,
|
||||
sondern Arbeits-Meeting mit Koordinationsfunktion.
|
||||
|
||||
typische_inhalte:
|
||||
- "Aktuelle Interventionsfälle (Angespannt/Kritisch)"
|
||||
- "Komplexe Bedarfssituationen"
|
||||
- "Übergaben bei Zuständigkeitswechsel"
|
||||
- "Erkenntnisse aus Gesprächen, die für andere relevant sind"
|
||||
- "Status-Updates zu laufenden Demands/Projekten bei Key-Stakeholdern"
|
||||
|
||||
abgrenzung: |
|
||||
REV-3 ist kein Review im klassischen Sinne, sondern ein
|
||||
Koordinationsmechanismus. Die Integration in die Steuerungs-
|
||||
struktur stellt sicher, dass operative Erkenntnisse in die
|
||||
taktische (REV-2) und strategische (REV-1) Ebene einfließen.
|
||||
|
||||
format:
|
||||
name: "SHM Team-Sync"
|
||||
dauer: "45-60 Minuten"
|
||||
moderation: "Rotierend oder SHM-Leitung"
|
||||
dokumentation: "Kurzprotokoll mit Entscheidungen und Follow-ups"
|
||||
|
||||
voc_relevanz: |
|
||||
Aktuelle Highlights (insbesondere Kritik-Highlights) fließen
|
||||
in die Team-Koordination ein. Interventionsfälle werden auf
|
||||
Basis von VoC-Signalen identifiziert.
|
||||
|
||||
voc_output: "Highlights (laufend)"
|
||||
|
||||
# =============================================================================
|
||||
# EINBETTUNG IN DIGIT-ZYKLEN
|
||||
# =============================================================================
|
||||
|
||||
einbettung_digit_zyklen:
|
||||
|
||||
beschreibung: |
|
||||
Die SHM-Reviews sind nicht isoliert, sondern in die übergreifenden
|
||||
DIGIT-Governance-Zyklen eingebettet.
|
||||
|
||||
ebenen:
|
||||
|
||||
strategische_ebene:
|
||||
gremium: "Vision Board"
|
||||
rhythmus: "Quartalsweise"
|
||||
funktion: "Definiert Strategie und jährliche strategische Fokusthemen"
|
||||
shm_einbettung: |
|
||||
REV-1 (Auftragserfüllung) wird im Vision Board verankert:
|
||||
- Jährlich: Vollständiger SHM-Jahresbericht als Input für Strategieplanung
|
||||
- Halbjährlich: Pulse-Update (Kurzform) zur Standortbestimmung
|
||||
|
||||
taktische_ebene:
|
||||
gremium: "SHM-Leitung / SOR bei Bedarf"
|
||||
rhythmus: "Quartalsweise (REV-2)"
|
||||
shm_einbettung: |
|
||||
REV-2 (Portfolio-Qualität, Lernen & Verbesserung) liegt auf der
|
||||
taktischen Ebene und wird durch SHM-Leitung verantwortet.
|
||||
|
||||
operative_ebene:
|
||||
gremium: "SHM-Team"
|
||||
rhythmus: "2-wöchentlich bis monatlich (REV-3)"
|
||||
shm_einbettung: |
|
||||
REV-3 (Operative Koordination) ist ein internes Team-Format.
|
||||
|
||||
# =============================================================================
|
||||
# EINBETTUNG IN ÜBERGREIFENDE DIGIT-REVIEWS
|
||||
# =============================================================================
|
||||
|
||||
einbettung_digit_reviews:
|
||||
|
||||
beschreibung: |
|
||||
SHM ist Teilnehmer an übergreifenden DIGIT-Review-Formaten und
|
||||
liefert dort Input aus seiner Perspektive.
|
||||
|
||||
dpm_portfolio_review:
|
||||
|
||||
name: "Demand-Portfolio Review"
|
||||
charakter: "DIGIT-übergreifendes Quartals-Review"
|
||||
frequenz: "Quartalsweise"
|
||||
zeitpunkt: "Erste Monatshälfte nach Quartalsende (ca. T+10 bis T+14)"
|
||||
teilnehmer: "AL Planung (Leitung), DPM, PPM, SPM, SHM"
|
||||
|
||||
shm_rolle: |
|
||||
SHM ist Teilnehmer und Input-Lieferant. Der SHM-Beitrag umfasst:
|
||||
- Stakeholder-Trends (VoC-Cluster-Entwicklung)
|
||||
- Bedarfsmuster (Erkenntnisse aus D3, Routing-Erfahrungen)
|
||||
- Kommunikations-Feedback (Highlights, Beziehungsqualität)
|
||||
|
||||
shm_input_quelle: "REV-2 (SHM Quartals-Review)"
|
||||
|
||||
sequenzierung: |
|
||||
REV-2 muss vor dem DPM-Portfolio-Review stattfinden, damit SHM
|
||||
vorbereitet ist und konsolidierten Input liefern kann.
|
||||
|
||||
Empfohlene Sequenz:
|
||||
- REV-2: Erste Woche nach Quartalsende
|
||||
- DPM-Portfolio-Review: Zweite Woche nach Quartalsende
|
||||
|
||||
referenz_dokument: "Konzept_DPM – Demand-Portfolio Review Framework"
|
||||
|
||||
# =============================================================================
|
||||
# KASKADIERUNGSLOGIK
|
||||
# =============================================================================
|
||||
|
||||
kaskadierungslogik:
|
||||
|
||||
beschreibung: |
|
||||
Informationen und Erkenntnisse fließen zwischen den Ebenen in
|
||||
beide Richtungen.
|
||||
|
||||
aufwaertsfluss:
|
||||
|
||||
- von: "REV-3 (Team-Sync)"
|
||||
nach: "REV-2 (Quartals-Review)"
|
||||
inhalt:
|
||||
- "Interventionsfälle, die eskaliert oder dokumentiert werden müssen"
|
||||
- "Erkenntnisse aus Einzelgesprächen"
|
||||
- "Muster, die im Tagesgeschäft auffallen"
|
||||
|
||||
- von: "REV-2 (Quartals-Review)"
|
||||
nach: "REV-1 (Jahres-Review)"
|
||||
inhalt:
|
||||
- "Quartals-Status und Trends"
|
||||
- "Konsolidierte VoC-Erkenntnisse"
|
||||
- "Handlungsbedarfe mit strategischer Relevanz"
|
||||
|
||||
- von: "REV-2 (Quartals-Review)"
|
||||
nach: "REV-2 erweitert (Q2/Q4)"
|
||||
inhalt:
|
||||
- "Muster, die auf strukturelle Probleme hindeuten"
|
||||
- "Wiederkehrende Themen aus mehreren Quartalen"
|
||||
|
||||
abwaertsfluss:
|
||||
|
||||
- von: "REV-1 / Vision Board"
|
||||
nach: "REV-2 / REV-3"
|
||||
inhalt:
|
||||
- "Strategische Prioritäten"
|
||||
- "Fokusthemen für die Stakeholder-Betreuung"
|
||||
- "Ressourcenentscheidungen"
|
||||
|
||||
- von: "REV-2 erweitert (Q2/Q4)"
|
||||
nach: "REV-3 (Team-Sync)"
|
||||
inhalt:
|
||||
- "Angepasste Prozesse oder Vorgehensweisen"
|
||||
- "Maßnahmen aus Verbesserungsplanung"
|
||||
- "Veränderte Prioritäten"
|
||||
|
||||
# =============================================================================
|
||||
# REVIEW-FORMATE IM DETAIL
|
||||
# =============================================================================
|
||||
|
||||
review_formate:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-1: JAHRES-REVIEW
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev1_jahres_review:
|
||||
|
||||
name: "SHM Jahres-Review"
|
||||
entscheidungstyp_referenz: "REV-1"
|
||||
zweck: "Strategische Bewertung der SHM-Funktion"
|
||||
frequenz: "Jährlich"
|
||||
zeitpunkt: "Q4 (vor Vision-Board-Strategieplanung)"
|
||||
|
||||
zusaetzlich_pulse_update:
|
||||
frequenz: "Halbjährlich"
|
||||
zeitpunkt: "Q2"
|
||||
umfang: "Kurzform (max. 2 Seiten)"
|
||||
|
||||
verantwortlichkeiten:
|
||||
erstellt: "SHM-Leitung"
|
||||
empfaengt: "Vision Board"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Jahresbericht"
|
||||
umfang: "Ca. 5-10 Seiten"
|
||||
gliederung:
|
||||
- abschnitt: "1. Management Summary"
|
||||
inhalt: "Kernaussagen, Gesamtbewertung"
|
||||
- abschnitt: "2. Stakeholder-Portfolio im Überblick"
|
||||
inhalt: "Bestandsübersicht, Beziehungsqualitäts-Verteilung"
|
||||
- abschnitt: "3. Voice of Customer – Gesamtbild"
|
||||
inhalt: "VoC-Cluster-Jahresübersicht, zentrale Erkenntnisse"
|
||||
- abschnitt: "4. Highlights des Jahres"
|
||||
inhalt: "Erfolge, Herausforderungen, besondere Fälle"
|
||||
- abschnitt: "5. Strategische Erkenntnisse"
|
||||
inhalt: "Implikationen für DIGIT-Strategie, Handlungsempfehlungen"
|
||||
- abschnitt: "6. Ausblick und Empfehlungen"
|
||||
inhalt: "Fokusthemen, Ressourcenbedarf, Risiken"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-01"
|
||||
name: "Vorlage SHM-Jahresbericht"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Hoch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-2: QUARTALS-REVIEW
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev2_quartals_review:
|
||||
|
||||
name: "SHM Quartals-Review"
|
||||
entscheidungstyp_referenz: "REV-2"
|
||||
zweck: "Portfolio-Analyse + Kontinuierliche Verbesserung"
|
||||
frequenz: "Quartalsweise"
|
||||
zeitpunkt: "Erste Woche nach Quartalsende (vor DPM-Portfolio-Review)"
|
||||
|
||||
varianten:
|
||||
|
||||
standard_q1_q3:
|
||||
|
||||
name: "Standard-Review"
|
||||
anwendung: "Q1, Q3"
|
||||
dauer: "60-90 Minuten"
|
||||
teilnehmer: "SHM-Leitung + Stakeholder-Manager"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Quartalsbericht"
|
||||
umfang: "Ca. 2-4 Seiten"
|
||||
gliederung:
|
||||
- "1. VoC-Cluster-Status (Ampel-Matrix)"
|
||||
- "2. Veränderungen ggü. Vorquartal"
|
||||
- "3. Highlights"
|
||||
- "4. Interventionen"
|
||||
- "5. Maßnahmen-Status"
|
||||
- "6. Handlungsbedarf"
|
||||
|
||||
erweitert_q2_q4:
|
||||
|
||||
name: "Erweiterter Review"
|
||||
anwendung: "Q2, Q4"
|
||||
dauer: "2-3 Stunden"
|
||||
teilnehmer: "SHM-Leitung + Stakeholder-Manager"
|
||||
charakter: "Workshop mit Retrospektive"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Quartalsbericht erweitert"
|
||||
umfang: "Ca. 4-6 Seiten"
|
||||
zusaetzliche_abschnitte:
|
||||
- "7. Retrospektive (Was lief gut/schlecht?)"
|
||||
- "8. Schnittstellen-Feedback"
|
||||
- "9. Verbesserungsplan (aktualisiert)"
|
||||
- "10. Bei Q4: Vorarbeit REV-1"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-02"
|
||||
name: "Vorlage SHM-Quartalsbericht"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Hoch"
|
||||
anforderungen:
|
||||
- "Modulare Struktur (Standard + Erweiterungs-Abschnitte)"
|
||||
- "VoC-Cluster-Matrix als visuelles Kernelement"
|
||||
- "Integrierter Maßnahmen-Tracker"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-3: TEAM-SYNC
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev3_team_sync:
|
||||
|
||||
name: "SHM Team-Sync"
|
||||
entscheidungstyp_referenz: "REV-3"
|
||||
zweck: "Operative Koordination im Team"
|
||||
frequenz: "2-wöchentlich oder monatlich"
|
||||
dauer: "45-60 Minuten"
|
||||
|
||||
verantwortlichkeiten:
|
||||
moderation: "Rotierend oder SHM-Leitung"
|
||||
teilnehmer: "Alle Stakeholder-Manager"
|
||||
|
||||
typische_agenda:
|
||||
- punkt: "Check-in"
|
||||
dauer: "5 Min"
|
||||
beschreibung: "Kurze Runde: Wie geht's?"
|
||||
- punkt: "Interventionsfälle"
|
||||
dauer: "15-20 Min"
|
||||
beschreibung: "Akute Situationen, kollegiale Beratung"
|
||||
- punkt: "Komplexe Bedarfssituationen"
|
||||
dauer: "15-20 Min"
|
||||
beschreibung: "Routing-Fragen, Abstimmungsbedarf"
|
||||
- punkt: "Wissenstransfer"
|
||||
dauer: "10 Min"
|
||||
beschreibung: "Erkenntnisse teilen, Best Practices"
|
||||
- punkt: "Kurz-Updates"
|
||||
dauer: "5 Min"
|
||||
beschreibung: "Termine, Ankündigungen"
|
||||
|
||||
artefakt:
|
||||
name: "Team-Sync-Protokoll"
|
||||
umfang: "Max. 1 Seite"
|
||||
inhalt:
|
||||
- "Datum, Teilnehmer"
|
||||
- "Besprochene Fälle (Stichworte)"
|
||||
- "Entscheidungen / Verabredungen"
|
||||
- "Follow-ups mit Verantwortung"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-03"
|
||||
name: "Vorlage Team-Sync-Protokoll"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Mittel"
|
||||
|
||||
# =============================================================================
|
||||
# TEMPLATE-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
template_uebersicht:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Templates werden für die Review-Struktur benötigt.
|
||||
Entwicklung erfolgt in Phase 10 (Arbeitsmaterialien).
|
||||
|
||||
templates:
|
||||
|
||||
- id: "TPL-KSS-01"
|
||||
name: "Vorlage SHM-Jahresbericht"
|
||||
fuer_format: "REV-1"
|
||||
prioritaet: "Hoch"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
- id: "TPL-KSS-02"
|
||||
name: "Vorlage SHM-Quartalsbericht"
|
||||
fuer_format: "REV-2"
|
||||
prioritaet: "Hoch"
|
||||
hinweis: "Modulare Struktur für Standard + Erweitert"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
- id: "TPL-KSS-03"
|
||||
name: "Vorlage Team-Sync-Protokoll"
|
||||
fuer_format: "REV-3"
|
||||
prioritaet: "Mittel"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
# =============================================================================
|
||||
# JAHRESKALENDER
|
||||
# =============================================================================
|
||||
|
||||
jahreskalender:
|
||||
|
||||
beschreibung: |
|
||||
Übersicht der Review-Formate im Jahresverlauf.
|
||||
|
||||
quartale:
|
||||
|
||||
quartal_1:
|
||||
zeitraum: "Januar - März"
|
||||
formate:
|
||||
- "REV-2 Standard (Q4 Vorjahr auswerten)"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Erster Review nach Jahreswechsel"
|
||||
|
||||
quartal_2:
|
||||
zeitraum: "April - Juni"
|
||||
formate:
|
||||
- "REV-2 Erweitert (Q1 + Retrospektive)"
|
||||
- "REV-1 Pulse-Update"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Halbjahres-Standortbestimmung"
|
||||
|
||||
quartal_3:
|
||||
zeitraum: "Juli - September"
|
||||
formate:
|
||||
- "REV-2 Standard (Q2 auswerten)"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "-"
|
||||
|
||||
quartal_4:
|
||||
zeitraum: "Oktober - Dezember"
|
||||
formate:
|
||||
- "REV-2 Erweitert (Q3 + Retrospektive + REV-1-Vorbereitung)"
|
||||
- "REV-1 Jahres-Review"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Jahresabschluss, Vorbereitung Strategieplanung"
|
||||
|
||||
visualisierung: |
|
||||
|
||||
┌─────────┬──────────────────────────────────────────────────────────┐
|
||||
│ Quartal │ Formate │
|
||||
├─────────┼──────────────────────────────────────────────────────────┤
|
||||
│ Q1 │ REV-2 Standard ──── REV-3 laufend ───────────────── │
|
||||
│ │ │
|
||||
│ Q2 │ REV-2 Erweitert ─ REV-1 Pulse ─ REV-3 laufend ───── │
|
||||
│ │ │
|
||||
│ Q3 │ REV-2 Standard ──── REV-3 laufend ───────────────── │
|
||||
│ │ │
|
||||
│ Q4 │ REV-2 Erweitert ─ REV-1 Jahres ─ REV-3 laufend ───── │
|
||||
└─────────┴──────────────────────────────────────────────────────────┘
|
||||
|
||||
# =============================================================================
|
||||
# ABGRENZUNG SHM / SPM IM REPORTING
|
||||
# =============================================================================
|
||||
|
||||
abgrenzung_spm:
|
||||
|
||||
beschreibung: |
|
||||
Basierend auf GOV-SHM-024 erfolgt eine klare Verantwortungstrennung
|
||||
zwischen SHM- und SPM-Reporting.
|
||||
|
||||
referenz: "readme_shm_governance-entscheidungs-log.yaml (GOV-SHM-024)"
|
||||
|
||||
shm_verantwortet:
|
||||
- dimension: "D1 – Beziehungsqualität"
|
||||
frage: "Wie läuft die Zusammenarbeit?"
|
||||
- dimension: "D3 – Bedarfserfüllung"
|
||||
frage: "Werden Anforderungen erkannt und bearbeitet?"
|
||||
- dimension: "D4 – Strategische Passung"
|
||||
frage: "Passt DIGIT zur Amtsstrategie?"
|
||||
- perspektive: "Portfolio-Perspektive"
|
||||
beschreibung: "Aggregierte Stakeholder-Sicht"
|
||||
|
||||
spm_verantwortet:
|
||||
- dimension: "D2 – Service-Qualität"
|
||||
frage: "Wie gut sind die Services?"
|
||||
- metrik: "SLA-Erfüllung"
|
||||
frage: "Werden vereinbarte Levels eingehalten?"
|
||||
- perspektive: "Service-Perspektive"
|
||||
beschreibung: "Einzelne Service-Performance"
|
||||
|
||||
gemeinsame_verantwortung:
|
||||
- format: "Auftraggeber-Forum"
|
||||
beschreibung: "Integriertes Format mit SHM- und SPM-Themen"
|
||||
- thema: "Eskalationen"
|
||||
beschreibung: "Wenn beide Bereiche betroffen sind"
|
||||
|
||||
schnittstellenregelung:
|
||||
|
||||
- schnittstelle: "VoC-Feedback zu D2"
|
||||
von: "SHM"
|
||||
an: "SPM / Service Owner"
|
||||
mechanismus: |
|
||||
SHM leitet D2-Feedback (Service-Qualität) an den zuständigen
|
||||
Service Owner weiter. Format: Kurz-Info mit Quelle und Kontext.
|
||||
|
||||
- schnittstelle: "Service-Performance-Daten"
|
||||
von: "SPM"
|
||||
an: "SHM"
|
||||
mechanismus: |
|
||||
SHM erhält Zugriff auf Service-Performance-Daten als Kontext
|
||||
für Stakeholder-Gespräche. Kein formaler Report, sondern
|
||||
Leserecht auf SLM-Dashboards/Berichte.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-10"
|
||||
autor: "Konzept-Sprint Phase 5"
|
||||
aenderung: |
|
||||
Initiale Erstellung basierend auf Working Document:
|
||||
- Modulname festgelegt (Koordinations- und Steuerungsstruktur)
|
||||
- Grundprinzipien definiert (PRIN-01 bis PRIN-05)
|
||||
- Steuerungsindikatoren spezifiziert (primär/sekundär)
|
||||
- Entscheidungstypen REV-1, REV-2, REV-3 modelliert
|
||||
- Ursprüngliche E2 und E4 zu konsolidiertem REV-2-Format zusammengeführt
|
||||
- Review-Struktur vollständig dokumentiert
|
||||
- Einbettung in DIGIT-Zyklen und DPM-Portfolio-Review ergänzt
|
||||
- Kaskadierungslogik definiert
|
||||
- Template-Übersicht für Phase 10 erstellt
|
||||
- Jahreskalender hinzugefügt
|
||||
- Abgrenzung SHM/SPM dokumentiert
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
# =============================================================================
|
||||
# SHM VOICE-OF-CUSTOMER (VoC) KONZEPT
|
||||
# =============================================================================
|
||||
#
|
||||
# Voice-of-Customer Methodik im Stakeholder-Management.
|
||||
# Status: Placeholder mit SPM-Schnittstelle
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
name: "Voice-of-Customer (VoC) Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-17"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: >
|
||||
Voice-of-Customer Methodik zur systematischen Erfassung und
|
||||
Aufbereitung von Kundenrueckmeldungen. Dieses Dokument ist ein
|
||||
Placeholder und enthaelt vorerst nur die SPM-Schnittstelle.
|
||||
|
||||
referenzen:
|
||||
service_review_konzept: "02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLE ZU SPM SERVICE-REVIEW
|
||||
# =============================================================================
|
||||
|
||||
spm_schnittstelle:
|
||||
|
||||
beschreibung: |
|
||||
Der VoC-Cluster D2 (Service-Qualitaet) liefert Input fuer die
|
||||
Service-Review-Dimension "Nutzerzufriedenheit" (SR-D3).
|
||||
|
||||
referenz: "spm_konzept_service-review.yaml -> bewertungsschema.dimensionen.SR-D3"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
nutzung_im_service_review:
|
||||
input_fuer_dimension: "SR-D3 Nutzerzufriedenheit"
|
||||
datenquelle: "VoC-Erkenntnisse aus SHM E2-Reports (Cluster D2)"
|
||||
verantwortlich: "SO bezieht SHM-Erkenntnisse in Review ein"
|
||||
|
||||
indikatoren_aus_shm:
|
||||
- "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)"
|
||||
- "Beschwerden und Eskalationen"
|
||||
- "VoC-Signale aus Stakeholder-Gespraechen"
|
||||
- "Informelle Rueckmeldungen via SM"
|
||||
|
||||
synchronisation:
|
||||
beschreibung: |
|
||||
SHM E2-Review liefert VoC-Erkenntnisse als Input fuer den
|
||||
quartalsweisen Service-Review.
|
||||
sequenz: "SHM E2-Review -> VoC-Erkenntnisse -> Service-Review nutzt D2-Cluster"
|
||||
|
||||
# =============================================================================
|
||||
# AENDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-17"
|
||||
aenderung: |
|
||||
- Placeholder erstellt mit SPM-Schnittstelle fuer Service-Review (GOV-SR-001)
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "spm_konzept_service-review.yaml"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# SHM-Integration in der Service-Operation-Runde
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 6
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 6]
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,567 @@
|
|||
# =============================================================================
|
||||
# SHM: ROUTING INTERNER DIGIT-BEDARFE
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Arbeitsmaterial / Übersicht
|
||||
# Version: 2.0
|
||||
# Datum: 2025-01-29
|
||||
# Status: Entwurf
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-AM-02"
|
||||
name: "Routing interner DIGIT-Bedarfe"
|
||||
typ: "Arbeitsmaterial"
|
||||
|
||||
zweck: |
|
||||
Diese Übersicht klärt die drei unterschiedlichen Bedarfstypen und ihre
|
||||
jeweiligen Prozesswege. Sie dient als Entscheidungshilfe für SHM und
|
||||
als Orientierung für DIGIT-Mitarbeiter.
|
||||
|
||||
**Kernaussage:** Es gibt drei Bedarfstypen mit unterschiedlichen Wegen:
|
||||
1. Externe Stakeholder-Bedarfe → Regelweg (vollständige Bedarfsbewertung)
|
||||
2. Interne DIGIT-Mitarbeiter-Bedarfe → Fast Track (10-15 min)
|
||||
3. Service-Lifecycle-Bedarfe → Bypass (direkt in Demand-Lifecycle)
|
||||
|
||||
referenzen:
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "funktionale_herleitung.geltungsbereich"
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "prozessablauf.schritt_0a_fast_track_intern"
|
||||
- dokument: "shm_d2p-integration.yaml"
|
||||
abschnitt: "abgrenzung_bedarfsquellen"
|
||||
- dokument: "PATCH_NOTES_interne_bedarfe_v1.1.md"
|
||||
beschreibung: "Konzeptdokumentation Fast Track"
|
||||
|
||||
governance_referenz: "GOV-SHM-026"
|
||||
|
||||
# =============================================================================
|
||||
# ÜBERSICHT: DREI BEDARFSTYPEN
|
||||
# =============================================================================
|
||||
|
||||
bedarfstypen_uebersicht:
|
||||
|
||||
visualisierung: |
|
||||
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ BEDARFSTYPEN IM DIGIT │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
|
||||
│ TYP 1: EXTERN │ │ TYP 2: INTERN │ │ TYP 3: LIFECYCLE │
|
||||
│ (Regelweg) │ │ (Fast Track) │ │ (Bypass) │
|
||||
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
|
||||
│ │ │
|
||||
Bedarfsträger: Bedarfsträger: Bedarfsträger:
|
||||
Externe Ämter, DIGIT-Mitarbeiter Service Owner,
|
||||
Dienststellen als Nutzer ISB, SOR, Leitung
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
|
||||
│ SHM Bedarfsbewertung│ │ SHM Fast Track │ │ Direkt DPM/SOR │
|
||||
│ - Schritt 0 │ │ - 3 Schritte │ │ - Kein SHM-Routing │
|
||||
│ - Prüfungen 1-3 │ │ - 10-15 Minuten │ │ - SHM informiert │
|
||||
│ - Vollständiger │ │ - Reduzierter │ │ bei Stakeholder- │
|
||||
│ Steckbrief │ │ Steckbrief │ │ Auswirkungen │
|
||||
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
|
||||
│ │ │
|
||||
└─────────────────────────┼─────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ DPM / DSR / MB │
|
||||
│ (einheitliche │
|
||||
│ Klassifizierung) │
|
||||
└─────────────────────┘
|
||||
|
||||
zusammenfassung_tabelle:
|
||||
|
||||
spalten:
|
||||
- "Bedarfstyp"
|
||||
- "Bedarfsträger"
|
||||
- "Eintrittskanal"
|
||||
- "Prozess"
|
||||
- "Aufwand SHM"
|
||||
- "Steckbrief"
|
||||
|
||||
zeilen:
|
||||
- bedarfstyp: "Extern (Regelweg)"
|
||||
bedarfstraeger: "Ämter, Dienststellen außerhalb DIGIT"
|
||||
eintrittskanal: "SHM"
|
||||
prozess: "Schritt 0 + Prüfungen 1-3"
|
||||
aufwand_shm: "2-4 Stunden"
|
||||
steckbrief: "Vollständig (ROUTE-DPM)"
|
||||
|
||||
- bedarfstyp: "Intern (Fast Track)"
|
||||
bedarfstraeger: "DIGIT-Mitarbeiter als Nutzer"
|
||||
eintrittskanal: "SHM (Self-Service-Portal)"
|
||||
prozess: "3-Schritte Fast Track"
|
||||
aufwand_shm: "10-15 Minuten"
|
||||
steckbrief: "Reduziert (ROUTE-DPM-INTERN)"
|
||||
|
||||
- bedarfstyp: "Service-Lifecycle (Bypass)"
|
||||
bedarfstraeger: "SO, ISB, SOR, DIGIT-Leitung"
|
||||
eintrittskanal: "Direkt SOR/DPM"
|
||||
prozess: "Kein SHM-Routing"
|
||||
aufwand_shm: "0 (nur Information)"
|
||||
steckbrief: "Vom Bedarfsträger erstellt"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 1: EXTERNE STAKEHOLDER-BEDARFE (REGELWEG)
|
||||
# =============================================================================
|
||||
|
||||
typ_1_externe_bedarfe:
|
||||
|
||||
name: "Externe Stakeholder-Bedarfe"
|
||||
kurzbezeichnung: "Regelweg"
|
||||
|
||||
definition: |
|
||||
Bedarfe, die von Stakeholdern außerhalb von DIGIT an DIGIT herangetragen
|
||||
werden. Der Stakeholder ist Bedarfsträger und Auftraggeber.
|
||||
|
||||
bedarfstraeger:
|
||||
- "Städtische Ämter (z.B. Bauamt, Sozialamt, Ordnungsamt)"
|
||||
- "Städtische Dienststellen"
|
||||
- "Eigenbetriebe"
|
||||
- "Andere kommunale Einrichtungen"
|
||||
|
||||
eintrittskanal: "SHM (Stakeholder-Management)"
|
||||
|
||||
prozess:
|
||||
beschreibung: "Vollständige Bedarfsbewertung gemäß shm_bedarfsbewertung.yaml"
|
||||
schritte:
|
||||
- "Schritt 0: Bedarfserhebung (User Stories)"
|
||||
- "Prüfung 1: Service-Katalog-Check"
|
||||
- "Prüfung 2: Change-Qualifizierung"
|
||||
- "Prüfung 3: Demand-Indikation"
|
||||
aufwand: "2-4 Stunden"
|
||||
steckbrief: "Vollständig (Validierungsprofil ROUTE-DPM)"
|
||||
|
||||
routing_optionen:
|
||||
- "ROUTE-REQ → Service Desk / Request Fulfilment"
|
||||
- "ROUTE-SPM → Service Owner (Change)"
|
||||
- "ROUTE-DPM → Demand Portfolio Management"
|
||||
- "ROUTE-SO → Service-Owner-Klärung (bei Unklarheit)"
|
||||
|
||||
beispiele:
|
||||
|
||||
- titel: "Bauamt benötigt neue Funktion im Fachverfahren"
|
||||
situation: |
|
||||
Das Bauamt meldet, dass im Bauantragsverfahren eine Funktion zur
|
||||
automatischen Flurstücksvalidierung fehlt.
|
||||
prozess: |
|
||||
SHM führt vollständige Bedarfsbewertung durch:
|
||||
- Schritt 0: User Stories mit Sachbearbeitern erarbeiten
|
||||
- Prüfung 1: Service existiert (Bauantragsverfahren)
|
||||
- Prüfung 2: Change am bestehenden Service → ROUTE-SPM
|
||||
ergebnis: "Vollständiger Bedarfssteckbrief an Service Owner"
|
||||
|
||||
- titel: "Sozialamt möchte digitale Antragsstellung"
|
||||
situation: |
|
||||
Das Sozialamt möchte Bürgeranträge online entgegennehmen können.
|
||||
Aktuell existiert kein entsprechender Service.
|
||||
prozess: |
|
||||
SHM führt vollständige Bedarfsbewertung durch:
|
||||
- Schritt 0: User Stories und Anforderungen erheben
|
||||
- Prüfung 1: Kein passender Service im Katalog
|
||||
- Prüfung 3: Demand-Indikation positiv → ROUTE-DPM
|
||||
ergebnis: "Vollständiger Bedarfssteckbrief an DPM"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 2: INTERNE DIGIT-MITARBEITER-BEDARFE (FAST TRACK)
|
||||
# =============================================================================
|
||||
|
||||
typ_2_interne_nutzer_bedarfe:
|
||||
|
||||
name: "Interne DIGIT-Mitarbeiter-Bedarfe"
|
||||
kurzbezeichnung: "Fast Track"
|
||||
|
||||
definition: |
|
||||
Bedarfe von DIGIT-Mitarbeitern, die als *Nutzer* von IT-Services
|
||||
auftreten – nicht in ihrer Funktion als Service Owner, ISB oder
|
||||
andere technische Rolle.
|
||||
|
||||
bedarfstraeger:
|
||||
- "DIGIT-Personalabteilung"
|
||||
- "DIGIT-Sekretariat"
|
||||
- "DIGIT-Sachbearbeiter (als Nutzer)"
|
||||
- "Andere DIGIT-interne Organisationseinheiten"
|
||||
- "Ggf. Stabsstelle Digital Freiburg (als Nutzer)"
|
||||
|
||||
abgrenzung_zu_service_lifecycle: |
|
||||
Der Fast Track gilt für DIGIT-Mitarbeiter als **Nutzer**.
|
||||
|
||||
Wenn ein Service Owner einen Bedarf für seinen **eigenen Service** hat,
|
||||
ist das ein Service-Lifecycle-Bedarf (Typ 3), kein Fast-Track-Fall.
|
||||
|
||||
Beispiel:
|
||||
- Personalabteilung braucht neue Zeiterfassung → Fast Track (Typ 2)
|
||||
- Service Owner DMS plant Redesign seines Service → Lifecycle (Typ 3)
|
||||
|
||||
eintrittskanal:
|
||||
primaer: "Self-Service-Portal (ITSM-Tool)"
|
||||
mvp: "E-Mail-Template an SHM"
|
||||
|
||||
prozess:
|
||||
beschreibung: "Vereinfachter 3-Schritte Fast Track (10-15 Minuten)"
|
||||
|
||||
schritt_1:
|
||||
name: "Basistriage"
|
||||
dauer: "3-5 Minuten"
|
||||
frage: "Ist es ein valider Bedarf?"
|
||||
|
||||
schritt_2:
|
||||
name: "Routing-Entscheidung"
|
||||
dauer: "5-7 Minuten"
|
||||
frage: "Wohin gehört der Bedarf?"
|
||||
optionen:
|
||||
- "Bestehender Service → Direkt an Service Owner"
|
||||
- "Neuer Service → ROUTE-DPM-INTERN"
|
||||
- "Unklar → ROUTE-SO"
|
||||
|
||||
schritt_3:
|
||||
name: "Minimaldokumentation"
|
||||
dauer: "3-5 Minuten"
|
||||
bedingung: "Nur bei ROUTE-DPM-INTERN"
|
||||
|
||||
aufwand: "10-15 Minuten"
|
||||
steckbrief: "Reduziert (Validierungsprofil ROUTE-DPM-INTERN)"
|
||||
|
||||
routing_optionen:
|
||||
- "Direkt an Service Owner (kein Steckbrief)"
|
||||
- "ROUTE-DPM-INTERN (reduzierter Steckbrief)"
|
||||
- "ROUTE-SO (bei Unklarheit)"
|
||||
|
||||
beispiele:
|
||||
|
||||
- titel: "Personalabteilung DIGIT möchte neue Personalsoftware"
|
||||
situation: |
|
||||
Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue
|
||||
Software zur Zeiterfassung, da das aktuelle System nicht mehr
|
||||
den Anforderungen entspricht.
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich, im Scope"
|
||||
schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN"
|
||||
schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M"
|
||||
ergebnis: "An DPM mit reduziertem Steckbrief"
|
||||
aufwand: "~12 Minuten"
|
||||
|
||||
- titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)"
|
||||
situation: |
|
||||
Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang
|
||||
für kollaborative Workshops.
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich"
|
||||
schritt_2: "Bestehender Service: Conceptboard → Direkt an SO"
|
||||
schritt_3: "Nicht erforderlich"
|
||||
ergebnis: |
|
||||
Direkt an Service Owner Conceptboard. SO klärt:
|
||||
- Reicht Conceptboard aus?
|
||||
- Fehlt eine Funktion? → Ggf. Change
|
||||
- Begründeter Mehrbedarf? → SO entscheidet
|
||||
aufwand: "~8 Minuten"
|
||||
|
||||
- titel: "DIGIT-Sekretariat benötigt Terminplanungstool"
|
||||
situation: |
|
||||
Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung
|
||||
mit externen Besuchern (Buchungslink-Funktion).
|
||||
prozess:
|
||||
schritt_1: "Valide – Bedarf verständlich, im Scope"
|
||||
schritt_2: "Prüfung: Kalendertool mit Buchungsfunktion vorhanden?"
|
||||
schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku"
|
||||
ergebnis: "Abhängig von Service-Katalog-Prüfung"
|
||||
aufwand: "~10 Minuten"
|
||||
|
||||
# =============================================================================
|
||||
# TYP 3: SERVICE-LIFECYCLE-BEDARFE (BYPASS)
|
||||
# =============================================================================
|
||||
|
||||
typ_3_service_lifecycle_bedarfe:
|
||||
|
||||
name: "Service-Lifecycle-Bedarfe"
|
||||
kurzbezeichnung: "Bypass"
|
||||
|
||||
definition: |
|
||||
Bedarfe, die aus dem Service-Lifecycle oder aus technisch-strategischen
|
||||
Rollen heraus entstehen. Der Bedarfsträger ist eine DIGIT-interne Rolle
|
||||
mit fachlicher Expertise (Service Owner, ISB, SOR, DIGIT-Leitung).
|
||||
|
||||
Diese Bedarfe durchlaufen die SHM-Triage NICHT, weil die fachliche
|
||||
Qualifizierung bereits durch den Bedarfsträger erfolgt ist.
|
||||
|
||||
bedarfstraeger:
|
||||
- "Service Owner (für eigenen Service)"
|
||||
- "ISB / Compliance"
|
||||
- "SOR (strategische Entscheidungen)"
|
||||
- "DIGIT-Leitung / Mission Board"
|
||||
- "Technische Architektur-Rollen"
|
||||
|
||||
eintrittskanal: "Direkt SOR / DPM (je nach Umfang)"
|
||||
|
||||
shm_rolle: |
|
||||
SHM ist bei Service-Lifecycle-Bedarfen **nicht Routing-Instanz**, aber:
|
||||
- SHM wird **informiert**, wenn externe Stakeholder betroffen sind
|
||||
- SHM übernimmt dann die **Stakeholder-Kommunikation**
|
||||
- SHM kann **Stakeholder-Perspektive** in DSR/MB einbringen
|
||||
|
||||
szenarien:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_1_change_bedarf_so:
|
||||
name: "Service Owner identifiziert Change-Bedarf"
|
||||
|
||||
beschreibung: |
|
||||
Der Service Owner erkennt im Rahmen seiner laufenden Arbeit oder aus
|
||||
dem Service Review, dass sein Service angepasst werden muss.
|
||||
|
||||
ausloeser:
|
||||
- "Service Review (sr_02) zeigt Optimierungspotenzial"
|
||||
- "Technische Schulden müssen abgebaut werden"
|
||||
- "Performance-Verbesserung erforderlich"
|
||||
- "Nutzer-Feedback zeigt Verbesserungsbedarf"
|
||||
|
||||
routing: "SO führt Change selbst durch (Normal Change Authority)"
|
||||
shm_information: "Nur bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Performance-Optimierung Ticketsystem"
|
||||
situation: "SO stellt fest, dass die Suche zu langsam ist."
|
||||
routing: "SO führt Datenbank-Tuning als Change durch"
|
||||
shm_information: "Nicht erforderlich (keine Nutzer-Auswirkung)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_2_redesign_bedarf_so:
|
||||
name: "Service Owner identifiziert Redesign-Bedarf"
|
||||
|
||||
beschreibung: |
|
||||
Der Service Owner erkennt, dass sein Service grundlegend überarbeitet
|
||||
werden muss – die Änderung hat Projektcharakter.
|
||||
|
||||
ausloeser:
|
||||
- "Service Review zeigt grundlegenden Modernisierungsbedarf"
|
||||
- "Technologie ist veraltet (End-of-Life)"
|
||||
- "Architektur-Änderung erforderlich"
|
||||
|
||||
routing: "SO → SOR (REDESIGN) → DPM (Demand)"
|
||||
shm_information: "Ja, da Stakeholder betroffen"
|
||||
|
||||
beispiel:
|
||||
titel: "Modernisierung Dokumentenmanagement"
|
||||
situation: "SO erkennt im Review: DMS technisch veraltet"
|
||||
routing: "SO → SOR bestätigt → DPM erhält Demand"
|
||||
shm_information: "SHM bereitet Stakeholder-Kommunikation vor"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_3_service_abloesung:
|
||||
name: "Service-Ablösung / Retirement"
|
||||
|
||||
beschreibung: |
|
||||
Ein Service soll nicht mehr weitergeführt werden – entweder
|
||||
ersatzlos oder durch einen anderen Service ersetzt.
|
||||
|
||||
ausloeser:
|
||||
- "End-of-Life des Produkts/der Technologie"
|
||||
- "Strategische Konsolidierung"
|
||||
- "Service wird nicht mehr benötigt"
|
||||
|
||||
routing: "SO → SOR (RETIRE) → DPM (Retirement-Projekt)"
|
||||
shm_information: "Ja, zwingend"
|
||||
|
||||
beispiel:
|
||||
titel: "Ablösung Legacy-Mailsystem"
|
||||
situation: "DIGIT entscheidet strategisch: Mailsystem ersetzen"
|
||||
routing: "SO (alt) → SOR → DPM (Retirement + ggf. neues System)"
|
||||
shm_information: |
|
||||
SHM übernimmt komplette Stakeholder-Kommunikation:
|
||||
- Key-Stakeholder: Persönliche Gespräche
|
||||
- Aktiv-Stakeholder: Strukturierte Information
|
||||
- Standard/Basis: Schriftliche Ankündigung
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_4_sicherheit_compliance:
|
||||
name: "Sicherheits- oder Compliance-Anforderung"
|
||||
|
||||
beschreibung: |
|
||||
Eine Änderung wird durch Sicherheitsvorgaben, Regulatorik oder
|
||||
Compliance-Anforderungen notwendig.
|
||||
|
||||
ausloeser:
|
||||
- "Sicherheitsvorfall oder -erkenntnis"
|
||||
- "Neue gesetzliche Anforderung"
|
||||
- "Audit-Feststellung"
|
||||
- "BSI-Empfehlung"
|
||||
|
||||
routing: "ISB → SOR/SO (je nach Umfang)"
|
||||
shm_information: "Bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Zwei-Faktor-Authentifizierung verpflichtend"
|
||||
situation: "Neue Sicherheitsrichtlinie erfordert 2FA"
|
||||
routing: "ISB → SOR → Umsetzung durch betroffene SOs"
|
||||
shm_information: |
|
||||
SHM übernimmt Stakeholder-Kommunikation:
|
||||
- Erklärung der Notwendigkeit
|
||||
- Zeitplan und Umstellungsprozess
|
||||
- Schulungs-/Support-Angebote
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
szenario_5_strategische_initiative:
|
||||
name: "Strategische DIGIT-Initiative"
|
||||
|
||||
beschreibung: |
|
||||
DIGIT startet eine übergreifende Initiative, die mehrere Services
|
||||
betrifft oder neue Infrastruktur schafft.
|
||||
|
||||
ausloeser:
|
||||
- "IT-Strategie-Umsetzung"
|
||||
- "Konsolidierungsprojekt"
|
||||
- "Infrastruktur-Modernisierung"
|
||||
- "Einführung neuer Basisdienste"
|
||||
|
||||
routing: "DIGIT-Leitung → MB → DPM"
|
||||
shm_information: "Ja, bei Stakeholder-Auswirkungen"
|
||||
|
||||
beispiel:
|
||||
titel: "Einführung zentrales Identity Management"
|
||||
situation: "DIGIT führt IAM-System ein (Single Sign-On)"
|
||||
routing: "DIGIT-Leitung → MB (Freigabe) → DPM (Programm)"
|
||||
shm_information: |
|
||||
SHM wird frühzeitig eingebunden:
|
||||
- Vorteile kommunizieren
|
||||
- Migrationsplanung je Amt
|
||||
- Schulungskonzept
|
||||
|
||||
# =============================================================================
|
||||
# ENTSCHEIDUNGSHILFE
|
||||
# =============================================================================
|
||||
|
||||
entscheidungshilfe:
|
||||
|
||||
kernfragen:
|
||||
- frage: "Wer ist Bedarfsträger?"
|
||||
typ_1: "Externes Amt / Dienststelle"
|
||||
typ_2: "DIGIT-Mitarbeiter als Nutzer"
|
||||
typ_3: "SO, ISB, SOR, DIGIT-Leitung"
|
||||
|
||||
- frage: "Woher kommt der Bedarf?"
|
||||
typ_1: "Stakeholder-Anfrage von außerhalb DIGIT"
|
||||
typ_2: "Interne Nutzer-Anforderung"
|
||||
typ_3: "Service-Lifecycle, Sicherheit, Strategie"
|
||||
|
||||
- frage: "Hat der Bedarfsträger fachliche IT-Expertise?"
|
||||
typ_1: "Nein (fachliche Übersetzung durch SHM nötig)"
|
||||
typ_2: "Begrenzt (vereinfachte Prüfung ausreichend)"
|
||||
typ_3: "Ja (Bedarfsträger qualifiziert selbst)"
|
||||
|
||||
grenzfaelle:
|
||||
|
||||
- fall: "Stakeholder beschwert sich, SO erkennt daraus Redesign-Bedarf"
|
||||
einschaetzung: |
|
||||
Der initiale Bedarf war extern (Beschwerde) → Typ 1.
|
||||
Die Schlussfolgerung "Redesign nötig" ist SO-Erkenntnis → Typ 3.
|
||||
|
||||
Routing: Beschwerde über SHM (Typ 1). Wenn SHM an SO routet und
|
||||
SO dann Redesign empfiehlt, geht der Demand direkt zu DPM (Typ 3).
|
||||
|
||||
- fall: "SO möchte Feature, das Stakeholder auch wünschen"
|
||||
einschaetzung: |
|
||||
Entscheidend ist, wer den Bedarf zuerst artikuliert hat:
|
||||
- Stakeholder zuerst → Typ 1 (SHM-Regelweg)
|
||||
- SO zuerst → Typ 3 (Service-Lifecycle)
|
||||
|
||||
In der Praxis: SO kann auf Stakeholder-Unterstützung verweisen.
|
||||
|
||||
- fall: "DIGIT-Personalabteilung vs. Personalamt der Stadt"
|
||||
einschaetzung: |
|
||||
- DIGIT-Personalabteilung → Typ 2 (Fast Track)
|
||||
- Personalamt der Stadt (anderes Amt) → Typ 1 (Regelweg)
|
||||
|
||||
Entscheidend ist die organisatorische Zugehörigkeit, nicht die
|
||||
funktionale Ähnlichkeit.
|
||||
|
||||
- fall: "ISB fordert Änderung, die Stakeholder nicht wollen"
|
||||
einschaetzung: |
|
||||
Sicherheits-/Compliance-Anforderungen sind Typ 3, auch wenn sie
|
||||
Stakeholder-Widerstand erzeugen.
|
||||
|
||||
SHM übernimmt die (ggf. schwierige) Stakeholder-Kommunikation,
|
||||
aber das Routing bleibt Typ 3 (ISB → SOR/SO).
|
||||
|
||||
# =============================================================================
|
||||
# ROUTING-MATRIX (KOMPAKT)
|
||||
# =============================================================================
|
||||
|
||||
routing_matrix_kompakt:
|
||||
|
||||
zeilen:
|
||||
- bedarfstyp: "Extern (Typ 1)"
|
||||
beispiel: "Bauamt braucht neue Funktion"
|
||||
eintritt: "SHM"
|
||||
prozess: "Regelweg"
|
||||
aufwand: "2-4h"
|
||||
steckbrief: "Vollständig"
|
||||
|
||||
- bedarfstyp: "Intern-Nutzer (Typ 2)"
|
||||
beispiel: "DIGIT-Personal braucht Zeiterfassung"
|
||||
eintritt: "SHM (Fast Track)"
|
||||
prozess: "3 Schritte"
|
||||
aufwand: "10-15min"
|
||||
steckbrief: "Reduziert"
|
||||
|
||||
- bedarfstyp: "Service-Lifecycle (Typ 3)"
|
||||
beispiel: "SO plant DMS-Modernisierung"
|
||||
eintritt: "Direkt SOR/DPM"
|
||||
prozess: "Kein SHM"
|
||||
aufwand: "0 (SHM)"
|
||||
steckbrief: "Vom SO"
|
||||
|
||||
# =============================================================================
|
||||
# SHM-AUFGABEN JE BEDARFSTYP
|
||||
# =============================================================================
|
||||
|
||||
shm_aufgaben_je_typ:
|
||||
|
||||
typ_1_extern:
|
||||
- "Vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3)"
|
||||
- "User-Story-Erhebung mit Stakeholder"
|
||||
- "Bedarfssteckbrief erstellen und validieren"
|
||||
- "Routing-Entscheidung treffen"
|
||||
- "Stakeholder-Kommunikation im gesamten Prozess"
|
||||
|
||||
typ_2_intern_nutzer:
|
||||
- "Fast Track Basistriage (3-5 min)"
|
||||
- "Schnelle Routing-Entscheidung (5-7 min)"
|
||||
- "Minimaldokumentation bei ROUTE-DPM-INTERN (3-5 min)"
|
||||
- "Weiterleitung an SO oder DPM"
|
||||
|
||||
typ_3_service_lifecycle:
|
||||
- "Keine Routing-Aufgabe"
|
||||
- "Information bei Stakeholder-Auswirkungen entgegennehmen"
|
||||
- "Stakeholder-Kommunikation übernehmen (wenn informiert)"
|
||||
- "Stakeholder-Perspektive in DSR/MB einbringen"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-01-29"
|
||||
aenderung: "Initiale Erstellung (Fokus auf Service-Lifecycle-Bedarfe)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Chat-Session Konzeptprüfung"
|
||||
|
||||
- version: "2.0"
|
||||
datum: "2025-01-29"
|
||||
aenderung: |
|
||||
Komplette Überarbeitung: Drei Bedarfstypen klar unterschieden
|
||||
- Typ 1: Externe Stakeholder-Bedarfe (Regelweg)
|
||||
- Typ 2: Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track)
|
||||
- Typ 3: Service-Lifecycle-Bedarfe (Bypass)
|
||||
- Visualisierung und Routing-Matrix ergänzt
|
||||
- Entscheidungshilfe mit Grenzfällen
|
||||
- SHM-Aufgaben je Bedarfstyp
|
||||
- Synchronisierung mit shm_bedarfsbewertung.yaml v1.3
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Chat-Session Konzeptprüfung"
|
||||
|
|
@ -0,0 +1,470 @@
|
|||
# =============================================================================
|
||||
# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Arbeitsmaterial (Leitfaden)
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-09
|
||||
# Status: Final
|
||||
# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
dokument_id: "SHM-A-01"
|
||||
name: "Leitfaden User Stories"
|
||||
typ: "Arbeitsmaterial"
|
||||
|
||||
zweck: |
|
||||
Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen
|
||||
aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte
|
||||
Bedarfe in konkrete, nachvollziehbare Funktionswünsche.
|
||||
|
||||
zielgruppe: "Stakeholder-Manager:innen"
|
||||
|
||||
kontext: |
|
||||
Im DIGIT-Kontext helfen User Stories, die Perspektive der
|
||||
Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen.
|
||||
Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung).
|
||||
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status_dokument:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch:
|
||||
- person: "DPM-Teammitglied"
|
||||
datum: "2025-09-17"
|
||||
- person: "DPM-Leitung"
|
||||
datum: null
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
referenzen:
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "schritt_0"
|
||||
beschreibung: "Integration in Bedarfsbewertungs-Prozess"
|
||||
- dokument: "shm_schema_bedarfssteckbrief.yaml"
|
||||
abschnitt: "user_stories"
|
||||
beschreibung: "Dokumentation der erhobenen User Stories"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDLAGEN
|
||||
# =============================================================================
|
||||
|
||||
grundlagen:
|
||||
|
||||
definition: |
|
||||
User Stories beschreiben Anforderungen aus Sicht der Nutzenden.
|
||||
Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare
|
||||
Funktionswünsche.
|
||||
|
||||
grundformat:
|
||||
schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]"
|
||||
|
||||
elemente:
|
||||
- element: "Rolle"
|
||||
beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')"
|
||||
beispiele:
|
||||
- "Sachbearbeiter*in Bauamt"
|
||||
- "Abteilungsleitung"
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
|
||||
- element: "Funktionalität"
|
||||
beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)"
|
||||
beispiele:
|
||||
- "Bauanträge nach Flurstücknummer durchsuchen"
|
||||
- "Urlaubsanträge digital genehmigen"
|
||||
- "Bearbeitungsstatus online einsehen"
|
||||
|
||||
- element: "Nutzen"
|
||||
beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)"
|
||||
beispiele:
|
||||
- "zusammenhängende Anträge schnell identifizieren"
|
||||
- "Prozess auch im Homeoffice funktioniert"
|
||||
- "nicht telefonisch nachfragen müssen"
|
||||
|
||||
mehrwert:
|
||||
- aspekt: "Perspektivwechsel"
|
||||
beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf"
|
||||
|
||||
- aspekt: "Verständlichkeit"
|
||||
beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache"
|
||||
|
||||
- aspekt: "Priorisierung"
|
||||
beschreibung: "Nutzen wird explizit und bewertbar"
|
||||
|
||||
- aspekt: "Validierung"
|
||||
beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'"
|
||||
|
||||
# =============================================================================
|
||||
# SCHRITT-FÜR-SCHRITT-ANLEITUNG
|
||||
# =============================================================================
|
||||
|
||||
anleitung:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 1: VORBEREITUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_1:
|
||||
name: "Vorbereitung des Gesprächs"
|
||||
|
||||
vor_dem_termin_klaeren:
|
||||
- "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)"
|
||||
- "Welcher Prozess ist betroffen?"
|
||||
- "Gibt es Vorarbeiten oder Dokumentationen?"
|
||||
|
||||
materialien_bereithalten:
|
||||
- "Bedarfs-Steckbrief"
|
||||
- "Ggf. Prozessvisualisierung"
|
||||
- "Beispiel-User-Stories zur Illustration"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 2: EINSTIEG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_2:
|
||||
name: "Einstieg ins Gespräch"
|
||||
|
||||
grundprinzip:
|
||||
falsch: "Welche User Stories haben Sie?"
|
||||
richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten."
|
||||
|
||||
leitfragen_einstieg:
|
||||
- "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt."
|
||||
- "Was würde Ihnen die Arbeit erleichtern?"
|
||||
- "Wobei verlieren Sie die meiste Zeit?"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 3: ROLLEN IDENTIFIZIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_3:
|
||||
name: "Die richtigen Rollen identifizieren"
|
||||
|
||||
typische_rollen:
|
||||
verwaltungsintern:
|
||||
- "Sachbearbeiter*in [Amt]"
|
||||
- "Abteilungsleitung"
|
||||
- "Verwaltungsmitarbeitende"
|
||||
- "Amtsleitung"
|
||||
- "Datenschutzbeauftragte*r"
|
||||
|
||||
verwaltungsextern:
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
- "Unternehmen"
|
||||
- "Andere Institute"
|
||||
- "Dienstleister"
|
||||
|
||||
wichtiger_hinweis: |
|
||||
Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_4:
|
||||
name: "Funktionalitäten herausarbeiten"
|
||||
|
||||
prinzip: "Von der Lösung zum Bedarf"
|
||||
|
||||
uebersetzungen:
|
||||
- stakeholder_sagt: "Wir brauchen eine Datenbank"
|
||||
shm_fragt: "Was möchten Sie damit tun?"
|
||||
story_wird: "...möchte ich Anträge zentral verwalten..."
|
||||
|
||||
- stakeholder_sagt: "Das System ist zu langsam"
|
||||
shm_fragt: "Wobei genau verlieren Sie Zeit?"
|
||||
story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..."
|
||||
|
||||
- stakeholder_sagt: "Wir wollen alles digitalisieren"
|
||||
shm_fragt: "Was genau soll digital werden?"
|
||||
story_wird: "...möchte ich Anträge online einreichen..."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 5: NUTZEN EXPLIZIT MACHEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_5:
|
||||
name: "Den Nutzen explizit machen"
|
||||
|
||||
nachfragen:
|
||||
- "Warum ist das wichtig?"
|
||||
- "Was können Sie dann besser machen?"
|
||||
|
||||
nutzen_kategorien:
|
||||
- kategorie: "Effizienz"
|
||||
beispiel: "...damit ich mehr Anträge bearbeiten kann"
|
||||
|
||||
- kategorie: "Qualität"
|
||||
beispiel: "...damit weniger Fehler passieren"
|
||||
|
||||
- kategorie: "Service"
|
||||
beispiel: "...damit Bürger*innen schneller Antworten erhalten"
|
||||
|
||||
- kategorie: "Compliance"
|
||||
beispiel: "...damit wir gesetzeskonform arbeiten"
|
||||
|
||||
- kategorie: "Transparenz"
|
||||
beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 6: FORMULIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_6:
|
||||
name: "User Stories formulieren"
|
||||
|
||||
beispiel_gut:
|
||||
rolle: "Sachbearbeiterin im Bauamt"
|
||||
funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können"
|
||||
nutzen: "zusammenhängende Anträge schnell identifiziere"
|
||||
vollstaendig: |
|
||||
Als Sachbearbeiterin im Bauamt
|
||||
möchte ich Bauanträge nach Flurstücknummer durchsuchen können
|
||||
damit ich zusammenhängende Anträge schnell identifiziere
|
||||
|
||||
beispiel_schlecht:
|
||||
rolle: "Nutzer"
|
||||
funktionalitaet: "eine bessere Suche"
|
||||
nutzen: "es schneller geht"
|
||||
vollstaendig: |
|
||||
Als Nutzer
|
||||
möchte ich eine bessere Suche
|
||||
damit es schneller geht
|
||||
probleme:
|
||||
- "Rolle zu unspezifisch"
|
||||
- "Funktionalität zu vage"
|
||||
- "Nutzen nicht konkret"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 7: PRIORISIEREN UND VALIDIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_7:
|
||||
name: "Stories priorisieren und validieren"
|
||||
|
||||
validierungsfragen:
|
||||
- "Habe ich Sie richtig verstanden?"
|
||||
- "Ist diese Reihenfolge nach Wichtigkeit korrekt?"
|
||||
- "Fehlt noch etwas Wesentliches?"
|
||||
|
||||
priorisierungsstufen:
|
||||
- stufe: "Kritisch"
|
||||
beschreibung: "Ohne geht es nicht"
|
||||
|
||||
- stufe: "Wichtig"
|
||||
beschreibung: "Deutliche Verbesserung"
|
||||
|
||||
- stufe: "Nützlich"
|
||||
beschreibung: "Wäre schön"
|
||||
|
||||
# =============================================================================
|
||||
# TYPISCHE HERAUSFORDERUNGEN
|
||||
# =============================================================================
|
||||
|
||||
herausforderungen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 1: LÖSUNGSDENKEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
loesungsdenken:
|
||||
name: "Der Stakeholder denkt nur in Lösungen"
|
||||
|
||||
technik: "Die 5-Warum-Methode"
|
||||
|
||||
beispiel_dialog:
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Wir brauchen ein Dashboard"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum brauchen Sie ein Dashboard?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um die Zahlen zu sehen"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum müssen Sie die Zahlen sehen?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um zu erkennen, wo sich Anträge stauen"
|
||||
|
||||
resultierende_story: |
|
||||
Als Abteilungsleitung
|
||||
möchte ich Engpässe im Antragsprozess erkennen
|
||||
damit ich Ressourcen umverteilen kann
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 2: ALLES DRINGEND
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
alles_dringend:
|
||||
name: "Alles ist wichtig und dringend"
|
||||
|
||||
technik: "Relatives Priorisieren"
|
||||
|
||||
hilfreiche_fragen:
|
||||
- "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?"
|
||||
- "Was würde am meisten wehtun, wenn es fehlt?"
|
||||
- "Was nutzen Sie täglich vs. was nur monatlich?"
|
||||
|
||||
# =============================================================================
|
||||
# QUALITÄTSKRITERIEN
|
||||
# =============================================================================
|
||||
|
||||
qualitaetskriterien:
|
||||
|
||||
invest:
|
||||
name: "INVEST-Kriterien"
|
||||
beschreibung: "Qualitätsstandard für gute User Stories"
|
||||
|
||||
kriterien:
|
||||
- buchstabe: "I"
|
||||
name: "Independent"
|
||||
beschreibung: "Unabhängig von anderen Stories"
|
||||
|
||||
- buchstabe: "N"
|
||||
name: "Negotiable"
|
||||
beschreibung: "Nicht in Stein gemeißelt"
|
||||
|
||||
- buchstabe: "V"
|
||||
name: "Valuable"
|
||||
beschreibung: "Klarer Nutzen erkennbar"
|
||||
|
||||
- buchstabe: "E"
|
||||
name: "Estimable"
|
||||
beschreibung: "Größe grob einschätzbar"
|
||||
|
||||
- buchstabe: "S"
|
||||
name: "Small"
|
||||
beschreibung: "In überschaubarer Zeit umsetzbar"
|
||||
|
||||
- buchstabe: "T"
|
||||
name: "Testable"
|
||||
beschreibung: "Überprüfbare Erfolgskriterien"
|
||||
|
||||
# =============================================================================
|
||||
# BEISPIEL-STORIES
|
||||
# =============================================================================
|
||||
|
||||
beispiel_stories:
|
||||
|
||||
- bereich: "Bürgerservice"
|
||||
story:
|
||||
rolle: "Bürger*in"
|
||||
funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen"
|
||||
nutzen: "ich nicht telefonisch nachfragen muss"
|
||||
volltext: |
|
||||
Als Bürger*in
|
||||
möchte ich den Bearbeitungsstatus meines Antrags online einsehen
|
||||
damit ich nicht telefonisch nachfragen muss
|
||||
|
||||
- bereich: "Interne Verwaltung"
|
||||
story:
|
||||
rolle: "Personalverantwortliche"
|
||||
funktionalitaet: "Urlaubsanträge digital genehmigen können"
|
||||
nutzen: "der Prozess auch im Homeoffice funktioniert"
|
||||
volltext: |
|
||||
Als Personalverantwortliche
|
||||
möchte ich Urlaubsanträge digital genehmigen können
|
||||
damit der Prozess auch im Homeoffice funktioniert
|
||||
|
||||
- bereich: "Schnittstellen"
|
||||
story:
|
||||
rolle: "Mitarbeitende im Einwohnermeldeamt"
|
||||
funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen"
|
||||
nutzen: "Bürger*innen sich nicht doppelt melden müssen"
|
||||
volltext: |
|
||||
Als Mitarbeitende im Einwohnermeldeamt
|
||||
möchte ich Meldedaten automatisch ans Finanzamt übertragen
|
||||
damit Bürger*innen sich nicht doppelt melden müssen
|
||||
|
||||
# =============================================================================
|
||||
# CHECKLISTE FÜR SHM
|
||||
# =============================================================================
|
||||
|
||||
checkliste:
|
||||
|
||||
name: "Checkliste für Stakeholder-Manager"
|
||||
|
||||
pruefpunkte:
|
||||
- id: "CK-01"
|
||||
pruefpunkt: "Rollen spezifisch identifiziert"
|
||||
beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'"
|
||||
|
||||
- id: "CK-02"
|
||||
pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)"
|
||||
beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'"
|
||||
|
||||
- id: "CK-03"
|
||||
pruefpunkt: "Nutzen explizit gemacht"
|
||||
beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'"
|
||||
|
||||
- id: "CK-04"
|
||||
pruefpunkt: "Stories mit Stakeholder validiert"
|
||||
beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'"
|
||||
|
||||
- id: "CK-05"
|
||||
pruefpunkt: "Prioritäten geklärt"
|
||||
beispiel: "Kritisch / Wichtig / Nützlich zugeordnet"
|
||||
|
||||
- id: "CK-06"
|
||||
pruefpunkt: "Zusammenhang zum Problem hergestellt"
|
||||
beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse"
|
||||
|
||||
- id: "CK-07"
|
||||
pruefpunkt: "In Bedarfs-Steckbrief übertragen"
|
||||
beispiel: "Stories im Schema-konformen Format dokumentiert"
|
||||
|
||||
# =============================================================================
|
||||
# DOKUMENTATION
|
||||
# =============================================================================
|
||||
|
||||
dokumentation:
|
||||
|
||||
nach_dem_gespraech:
|
||||
- schritt: 1
|
||||
aktion: "Stories im Steckbrief sauber dokumentieren"
|
||||
- schritt: 2
|
||||
aktion: "Priorisierung vermerken"
|
||||
- schritt: 3
|
||||
aktion: "Offene Punkte notieren"
|
||||
- schritt: 4
|
||||
aktion: "Validierungstermin vereinbaren"
|
||||
|
||||
ablage:
|
||||
ziel_dokument: "Bedarfs-Steckbrief"
|
||||
ziel_abschnitt: "user_stories"
|
||||
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# HINWEISE
|
||||
# =============================================================================
|
||||
|
||||
hinweise:
|
||||
|
||||
- typ: "Tipp"
|
||||
text: |
|
||||
Die erste User Story ist die schwerste. Mit etwas Übung entwickeln
|
||||
Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe
|
||||
strukturiert zu erfassen.
|
||||
|
||||
- typ: "Warnung"
|
||||
text: |
|
||||
Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist
|
||||
es, den Bedarf zu verstehen – nicht, ihn zu lösen.
|
||||
|
||||
- typ: "Best Practice"
|
||||
text: |
|
||||
Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie
|
||||
konkrete User Stories formulieren. Der Kontext hilft, die
|
||||
richtigen Fragen zu stellen.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-09"
|
||||
aenderung: "Initiale Erstellung aus PDF-Vorlage"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Konzept_DPM_Abnahme20230925, Seiten 125-131"
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# Stakeholder-Informations-Management-System (SIMS)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 11
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 11]
|
||||
File diff suppressed because it is too large
Load diff
1135
#04_mission-board/mb_geschaeftsordnung.yaml
Normal file
1135
#04_mission-board/mb_geschaeftsordnung.yaml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,837 @@
|
|||
# =============================================================================
|
||||
# FUNKTIONSBESCHREIBUNG: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "funktionsbeschreibung"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
aliases: ["PM", "PZM", "Prozess-Funktion"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Governance"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied", "PM-Leitung"]
|
||||
status: "draft"
|
||||
|
||||
kontext_tags:
|
||||
- "prozess-management"
|
||||
- "funktion"
|
||||
- "prozess-governance"
|
||||
- "prozess-optimierung"
|
||||
- "befaehigung"
|
||||
- "key-user"
|
||||
|
||||
quellen:
|
||||
- "#02 - Prozess-Management: Funktionsbeschreibung.docx"
|
||||
|
||||
taxonomie_referenz: "#00_meta/digitom_taxonomie.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# ABKÜRZUNGSVERZEICHNIS
|
||||
# =============================================================================
|
||||
|
||||
abkuerzungen:
|
||||
pm: "Prozess-Management"
|
||||
pzm: "Prozess-Management (alternative Abkürzung)"
|
||||
dpm: "Demand-Portfolio-Management"
|
||||
spm: "Service-Portfolio-Management"
|
||||
shm: "Stakeholder-Management"
|
||||
ppm: "Projekt-Portfolio-Management"
|
||||
mb: "Mission Board"
|
||||
vb: "Vision Board"
|
||||
digitom: "Digital Target Operating Model"
|
||||
|
||||
# =============================================================================
|
||||
# 1. ZWECK
|
||||
# =============================================================================
|
||||
|
||||
zweck:
|
||||
wozu_existiert_diese_funktion:
|
||||
kurz: |
|
||||
Das Prozess-Management gestaltet aktiv die Art und Weise, wie das DIGIT arbeitet.
|
||||
Als unterstützende und befähigende Einheit etabliert und verantwortet es den
|
||||
verbindlichen methodischen Rahmen für alle übergreifenden (Organisations-)Prozesse (DIGITOM).
|
||||
|
||||
ausfuehrlich: |
|
||||
Das Prozess-Management agiert im Auftrag des Vision Board (strategisches Führungsgremium)
|
||||
und dient internen Kunden - den Fachbereichen/Abteilungen und ihren Key Usern sowie
|
||||
den Projektteams - indem es methodische Standards, Werkzeuge und Beratung bereitstellt,
|
||||
damit diese ihre Prozesse eigenständig managen und verbessern können.
|
||||
|
||||
Ziel ist es, durch klare Strukturen, einheitliche Standards und gezielte Befähigung
|
||||
eine solide Grundlage für Effektivität, Transparenz und kontinuierliche Verbesserung
|
||||
im gesamten Amt zu schaffen.
|
||||
|
||||
Dadurch unterstützt das Prozess-Management die erfolgreiche Umsetzung der Digitalstrategie
|
||||
und schafft Arbeitsabläufe, die gut funktionieren und sich flexibel an neue Anforderungen
|
||||
anpassen lassen.
|
||||
|
||||
wertbeitrag:
|
||||
- "Einheitliche, vergleichbare und nachvollziehbare Prozessdokumentation im Amt"
|
||||
- "Methodische Qualität und Effektivität in der Prozessgestaltung und -optimierung"
|
||||
- "Gemeinsame 'Prozess-Sprache' und Verständnis über Abteilungsgrenzen hinweg"
|
||||
- "Befähigung der Organisation zur eigenverantwortlichen Prozesssteuerung"
|
||||
- "Flexibel anpassbare Arbeitsabläufe für neue Anforderungen"
|
||||
|
||||
kritisches_merkmal: |
|
||||
Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation.
|
||||
Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung
|
||||
zu ersetzen. Die Verantwortung bleibt, wo sie hingehört - bei den Fachbereichen.
|
||||
|
||||
hauptziel:
|
||||
beschreibung: |
|
||||
Nachhaltig wirksame und anpassungsfähige Prozesse in der Organisation zu verankern.
|
||||
|
||||
erreicht_durch:
|
||||
- id: "Z1"
|
||||
aktivitaet: "Prozesslandschaft schaffen und pflegen"
|
||||
beschreibung: |
|
||||
Eine konsistente, transparente und an der Strategie ausgerichtete Prozesslandschaft
|
||||
schaffen und pflegen, die Silos überwindet.
|
||||
umfasst:
|
||||
- "Erhebung und Visualisierung der Prozesslandkarte"
|
||||
- "Laufende Pflege und Aktualisierung"
|
||||
- "Strategische Ausrichtung sicherstellen"
|
||||
|
||||
- id: "Z2"
|
||||
aktivitaet: "Organisation befähigen"
|
||||
beschreibung: |
|
||||
Die Organisation durch gezielte Beratung, Coaching und Schulung befähigen,
|
||||
ihre Prozesse innerhalb des Rahmens eigenverantwortlich zu steuern und zu optimieren.
|
||||
umfasst:
|
||||
- "Beratung und Coaching von Prozessverantwortlichen"
|
||||
- "Schulungen und Workshops durchführen"
|
||||
- "Key-User-Netzwerk aufbauen und betreuen"
|
||||
|
||||
- id: "Z3"
|
||||
aktivitaet: "Prozess-Governance überwachen"
|
||||
beschreibung: |
|
||||
Die Einhaltung der Prozess-Governance (Standards, Methoden, Dokumentation) als Grundlage
|
||||
für Qualität, Nachvollziehbarkeit und Verlässlichkeit überwachen und unterstützen.
|
||||
umfasst:
|
||||
- "Qualitäts-Checks und Reviews durchführen"
|
||||
- "Framework-Konformität prüfen"
|
||||
- "Governance-Lücken identifizieren und adressieren"
|
||||
|
||||
- id: "Z4"
|
||||
aktivitaet: "DIGITOM weiterentwickeln"
|
||||
beschreibung: |
|
||||
Die kontinuierliche Weiterentwicklung und Anpassung des DIGITOMs als lebendiges
|
||||
Organisationsmodell vorantreiben, um auf veränderte Anforderungen und gewonnene
|
||||
Erkenntnisse reagieren zu können.
|
||||
umfasst:
|
||||
- "Analyse interner Bedarfe und externer Best Practices"
|
||||
- "Konzepte zur Weiterentwicklung erarbeiten"
|
||||
- "Änderungen umsetzen und kommunizieren"
|
||||
|
||||
# =============================================================================
|
||||
# 2. FUNKTIONSVERSTÄNDNIS & ABGRENZUNG
|
||||
# =============================================================================
|
||||
|
||||
funktionsverstaendnis:
|
||||
charakterisierung:
|
||||
typ: "Unterstützende und befähigende Funktion"
|
||||
|
||||
beschreibung: |
|
||||
Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger für die Organisation.
|
||||
Es unterstützt und berät die Fachbereiche bei ihren Prozessen, ohne deren Verantwortung
|
||||
zu ersetzen. Dies beinhaltet eine klare Rollenverteilung zwischen Linienorganisation
|
||||
und Prozessmanagement.
|
||||
|
||||
grundprinzipien:
|
||||
|
||||
prinzip_1:
|
||||
name: "Die Verantwortung bleibt, wo sie hingehört"
|
||||
beschreibung: |
|
||||
Die Fachbereiche/Abteilungen sind fachlich und operativ für die Ausführung und Ergebnisse
|
||||
ihrer Prozesse verantwortlich. Sie liefern die Prozessinhalte und gewährleisten funktionierende
|
||||
Abläufe im Tagesgeschäft. Hierfür werden in der Regel Prozessverantwortliche - wie Key User
|
||||
oder Process Owner - als erste Ansprechpartner benannt.
|
||||
|
||||
Das zentrale Prozess-Management verantwortet Rahmen und Methodik der Prozessarbeit, gibt
|
||||
Standards vor, überblickt die Prozesslandschaft und berät Prozessverantwortliche. Es greift
|
||||
nicht in die Liniensteuerung ein, sondern beeinflusst durch Expertise, Governance und
|
||||
Koordination. Entscheidungen werden bei Bedarf über Gremien initiiert.
|
||||
auswirkung: |
|
||||
Klare Trennung zwischen operativer Prozessverantwortung (Fachbereich) und
|
||||
methodischer Prozessverantwortung (PM). Eigenverantwortung der Fachbereiche bleibt erhalten.
|
||||
referenz: "#02 - Funktionsbeschreibung.docx"
|
||||
|
||||
prinzip_2:
|
||||
name: "Partnerschaft statt Kontrolle"
|
||||
beschreibung: |
|
||||
Prozess-Management agiert als proaktiver Partner der Fachbereiche/Abteilungen und schafft
|
||||
einen verbindlichen Ordnungsrahmen. Bei signifikanten Abweichungen von Standards oder
|
||||
Governance-Lücken greift es unterstützend ein.
|
||||
auswirkung: |
|
||||
Fördert Vertrauen: Fachbereiche erhalten Unterstützung zur Selbsthilfe, während das
|
||||
Management die Einhaltung der Standards und der Gesamtzusammenhänge gewährleistet sieht.
|
||||
referenz: "#02 - Funktionsbeschreibung.docx"
|
||||
|
||||
prinzip_3:
|
||||
name: "Strukturierte Leistungserbringung"
|
||||
beschreibung: |
|
||||
Das Prozess-Management differenziert seine Unterstützung nach vier Leistungskategorien,
|
||||
die unterschiedlichen Beauftragungswegen und Priorisierungslogiken folgen.
|
||||
auswirkung: |
|
||||
Bedarfsgerechte Ressourcensteuerung und klare Erwartungen auf allen Seiten.
|
||||
referenz: "#02 - Funktionsbeschreibung.docx"
|
||||
|
||||
leistungskategorien:
|
||||
- kategorie: "Standard-Leistungen"
|
||||
beschreibung: "Wiederkehrende Unterstützung für operative Prozessbedarfe (Beratung, Workshops, Schulungen)"
|
||||
beauftragung: "Niedrigschwellig, etablierte Muster"
|
||||
|
||||
- kategorie: "Projekt-Leistungen"
|
||||
beschreibung: "Ressourcenintensive Vorhaben mit mehrwöchiger Laufzeit (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)"
|
||||
beauftragung: "Formale Beauftragung durch Mission Board"
|
||||
|
||||
- kategorie: "Strategische Leistungen"
|
||||
beschreibung: "Weiterentwicklung des DIGITOMs, grundlegende Transformation der Prozesslandschaft"
|
||||
beauftragung: "Beauftragung durch Vision Board"
|
||||
|
||||
- kategorie: "Krisen-Leistungen"
|
||||
beschreibung: "Akute Prozessstörungen oder Compliance-Verstöße mit sofortigem Handlungsbedarf"
|
||||
beauftragung: "Sofortige Priorisierung, andere Aktivitäten werden zurückgestellt"
|
||||
|
||||
abgrenzung_zu_angrenzenden_funktionen:
|
||||
|
||||
- funktion: "dpm"
|
||||
name: "Demand-Portfolio-Management"
|
||||
dpm_tut: |
|
||||
Steuert und priorisiert Demands über den gesamten Lifecycle.
|
||||
Managt das Demand-Portfolio und koordiniert die Umsetzung.
|
||||
pm_tut: |
|
||||
Definiert den methodischen Rahmen für Prozesse, die Demands auslösen können.
|
||||
Unterstützt bei Prozessänderungen, die aus Demands resultieren.
|
||||
schnittstelle: |
|
||||
Demands können Prozess-Änderungen sein. PM unterstützt DPM bei der Bewertung
|
||||
prozessualer Auswirkungen von Demands.
|
||||
|
||||
- funktion: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
spm_tut: |
|
||||
Steuert das Service-Portfolio, verantwortet Service-Lifecycle und Service-Level.
|
||||
Managt servicebezogene Prozesse nach ITIL-Framework.
|
||||
pm_tut: |
|
||||
Stellt methodischen Rahmen für die Dokumentation von Service-Prozessen bereit.
|
||||
Unterstützt bei der Gestaltung und Standardisierung von Service-Prozessen.
|
||||
schnittstelle: |
|
||||
Services basieren auf Prozessen. PM liefert Methodik und Framework,
|
||||
SPM wendet diese auf Service-Prozesse an. Gegenseitiges Feedback zur
|
||||
Anwendbarkeit des Frameworks.
|
||||
|
||||
- funktion: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
shm_tut: |
|
||||
Identifiziert und managt Stakeholder-Beziehungen.
|
||||
Erfasst Stakeholder-Anforderungen und -Feedback.
|
||||
pm_tut: |
|
||||
Definiert Prozesse für den Umgang mit externen Stakeholdern.
|
||||
Berücksichtigt Stakeholder-Anforderungen in der Prozessgestaltung.
|
||||
schnittstelle: |
|
||||
Stakeholder haben Prozess-Anforderungen. PM erhält von SHM Anforderungen
|
||||
(z.B. Kundenfeedback, regulative Vorgaben), die Prozesse beeinflussen.
|
||||
|
||||
- funktion: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
ppm_tut: |
|
||||
Plant und priorisiert Projekte.
|
||||
Steuert das Projekt-Portfolio.
|
||||
pm_tut: |
|
||||
Definiert Vorgaben, wie Projekte im Rahmen des DIGITOM ablaufen sollen.
|
||||
Bewertet Machbarkeit von Projekten aus prozessualer Sicht.
|
||||
schnittstelle: |
|
||||
Projekte können Prozess-Änderungen erfordern. PM erhält Informationen zu
|
||||
geplanten Projekten und deren Prozessauswirkungen.
|
||||
|
||||
# =============================================================================
|
||||
# 3. VERANTWORTUNGSBEREICHE
|
||||
# =============================================================================
|
||||
|
||||
verantwortungsbereiche:
|
||||
|
||||
beschreibung: |
|
||||
Das Prozess-Management gliedert sich in fünf Kernverantwortungsbereiche,
|
||||
die das Spektrum von der Framework-Definition über das Prozesslandschafts-Management
|
||||
bis zur Befähigung und Leistungssteuerung abdecken.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 VERANTWORTUNGSBEREICH 1
|
||||
# ---------------------------------------------------------------------------
|
||||
bereich_1_framework:
|
||||
id: "VB1"
|
||||
name: "Prozess-Management-Framework definieren und weiterentwickeln"
|
||||
|
||||
beschreibung: |
|
||||
Definition, Kommunikation und Weiterentwicklung der verbindlichen methodischen
|
||||
und technischen Grundlagen für das gesamte Prozess-Management im DIGIT als
|
||||
Fundament für einheitliche und qualitativ hochwertige Prozessarbeit.
|
||||
|
||||
was:
|
||||
- "Etablierung eines einheitlichen Prozess-Management-Frameworks: Gemeinsame verbindliche Standards und Methoden für die Darstellung, Dokumentation und Steuerung von Prozessen"
|
||||
- "Festlegung von Governance-Regeln und Richtlinien für alle Aspekte der Prozessarbeit (von der Dokumentation über die Analyse bis zur Steuerung)"
|
||||
- "Auswahl, Bereitstellung und laufende Betreuung zentraler Prozess-Management-Werkzeuge"
|
||||
|
||||
warum:
|
||||
- "Sicherstellung einer einheitlichen, vergleichbaren und nachvollziehbaren Prozessdokumentation im Amt"
|
||||
- "Gewährleistung von methodischer Qualität, Effektivität und fundierter Erhebung in der Prozessgestaltung und -optimierung"
|
||||
- "Schaffung einer gemeinsamen 'Prozess-Sprache' und eines gemeinsamen Verständnisses für Prozessarbeit über Abteilungsgrenzen hinweg"
|
||||
|
||||
wie:
|
||||
governance:
|
||||
- "Laufende Analyse von internen Bedarfen und externen Best Practices/Standards im Prozess-Management"
|
||||
- "Abstimmung der Anforderungen mit Fachbereichen, IT-Architektur und übergreifenden Governance-Vorgaben"
|
||||
- "Klare Dokumentation des Prozess-Management-Frameworks (z.B. Methodenhandbuch oder Playbook)"
|
||||
|
||||
frequenz:
|
||||
- "Framework-Reviews: quartalsweise"
|
||||
- "Tool-Updates: bei Bedarf"
|
||||
- "Schulungen: laufend"
|
||||
|
||||
outputs:
|
||||
- "Prozess-Management-Framework (Methodenhandbuch/Playbook)"
|
||||
- "Governance-Regeln und Richtlinien"
|
||||
- "Tool-Dokumentation und Anleitungen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 VERANTWORTUNGSBEREICH 2
|
||||
# ---------------------------------------------------------------------------
|
||||
bereich_2_prozesslandschaft:
|
||||
id: "VB2"
|
||||
name: "Übergreifende Prozesslandschaft managen und Governance sicherstellen"
|
||||
|
||||
beschreibung: |
|
||||
Aufbau, Pflege und Überwachung der Gesamtarchitektur der bereichsübergreifenden
|
||||
Prozesse (Kern-, Management- und Supportprozesse) des DIGIT zur Schaffung von
|
||||
Transparenz, zur Steuerung und zur Sicherstellung der Einhaltung des definierten Rahmens.
|
||||
|
||||
was:
|
||||
- "Erhebung, Visualisierung und laufende Pflege der übergreifenden Prozesslandkarte des DIGIT"
|
||||
- "Überwachung der Einhaltung des Prozess-Management-Frameworks (Methoden, Standards, Dokumentationsqualität)"
|
||||
- "Systematische Identifikation und Adressierung von Governance-Lücken: Dokumentation fehlender Regelungen, strukturierte Eskalation über definierte Wege, Nachverfolgung bis zur Schließung der Lücke"
|
||||
|
||||
warum:
|
||||
- "Schaffung von Transparenz über die Kernabläufe, Abhängigkeiten und Schnittstellen im Amt"
|
||||
- "Ermöglichung einer strategischen Steuerung und Priorisierung von bereichsübergreifenden Prozessinitiativen (durch das Vision Board)"
|
||||
- "Sicherstellung der Konsistenz und Qualität der Prozessarbeit sowie Einhaltung von Compliance-Vorgaben"
|
||||
- "Vermeidung von Silos und unkoordinierten Insellösungen"
|
||||
|
||||
wie:
|
||||
governance:
|
||||
- "Nutzung des Prozess-Management-Werkzeugs zur Darstellung und Verwaltung der Prozessarchitektur"
|
||||
- "Regelmäßige Qualitäts-Checks und Reviews zur Prüfung der Framework-Konformität"
|
||||
- "Kontinuierlicher Austausch mit den Fachbereichen (u.a. über Key-User)"
|
||||
- "Regelmäßiges Reporting an das Vision Board und relevante Gremien"
|
||||
|
||||
frequenz:
|
||||
- "Prozesslandkarten-Review: quartalsweise"
|
||||
- "Qualitäts-Checks: monatlich"
|
||||
- "Vision Board Reporting: quartalsweise"
|
||||
|
||||
outputs:
|
||||
- "Übergreifende Prozesslandkarte"
|
||||
- "Governance-Reports"
|
||||
- "Qualitäts-Berichte"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.3 VERANTWORTUNGSBEREICH 3
|
||||
# ---------------------------------------------------------------------------
|
||||
bereich_3_beratung:
|
||||
id: "VB3"
|
||||
name: "Beratung und operative Prozessgestaltung (in definierten Fällen)"
|
||||
|
||||
beschreibung: |
|
||||
Methodische Unterstützung der Fachbereiche bei Prozessfragen sowie aktive Gestaltung
|
||||
und Optimierung von Prozessen in spezifischen, strategisch relevanten oder komplexen
|
||||
Situationen, wobei die Rolle klar als Berater und Befähiger verstanden wird.
|
||||
|
||||
was:
|
||||
- "Fachliche Beratung von Fachbereichen und Teams bei der Analyse, Neugestaltung und Optimierung ihrer Prozesse (methodische Fachexpertise bereitstellen)"
|
||||
- "Bei Bedarf Moderation von Prozessworkshops bei bereichsübergreifenden oder komplexen Abläufen"
|
||||
- "In ausgewählten Ausnahmefällen operative Unterstützung bei der Prozessaufnahme, -modellierung und -optimierung (bei strategisch bedeutsamen oder abteilungsübergreifenden Prozessen, bei Projekten mit großem Prozesseinfluss oder initial als 'Starthilfe')"
|
||||
|
||||
warum:
|
||||
- "Sicherstellung hoher methodischer Qualität bei der Lösung komplexer Prozessherausforderungen"
|
||||
- "Unterstützung der Fachbereiche bei der Erreichung ihrer Ziele durch effektive Prozesse ('Enabling')"
|
||||
- "Gezielter Einsatz zentraler Ressourcen auf die Prozesse mit dem größten Hebel oder der höchsten Komplexität"
|
||||
|
||||
wie:
|
||||
governance:
|
||||
- "Durchführung von individuellen Beratungsgesprächen und Coachings für Prozessverantwortliche/-teams"
|
||||
- "Planung und professionelle Moderation von Analyse- und Design-Workshops"
|
||||
- "Anwendung geeigneter Prozessanalyse- und Optimierungstechniken"
|
||||
- "Detaillierte Modellierung (Ist/Soll) gemäß Prozess-Framework bei Übernahme operativer Verantwortung"
|
||||
|
||||
frequenz:
|
||||
- "Beratungsgespräche: bei Bedarf"
|
||||
- "Workshops: nach Vereinbarung"
|
||||
- "Operative Unterstützung: in definierten Fällen"
|
||||
|
||||
outputs:
|
||||
- "Beratungsprotokolle"
|
||||
- "Workshop-Ergebnisse"
|
||||
- "Prozessmodelle (Ist/Soll)"
|
||||
- "Optimierungsempfehlungen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.4 VERANTWORTUNGSBEREICH 4
|
||||
# ---------------------------------------------------------------------------
|
||||
bereich_4_befaehigung:
|
||||
id: "VB4"
|
||||
name: "Dezentrale Prozesskompetenz durch Befähigung und Aufbau Key-User-Konzept"
|
||||
|
||||
beschreibung: |
|
||||
Systematischer Aufbau und Pflege von Prozess-Management-Kompetenzen in den Fachbereichen,
|
||||
insbesondere durch die Etablierung und Betreuung eines Key-User-Netzwerks, um die
|
||||
Prozessarbeit nachhaltig in der Organisation zu verankern.
|
||||
|
||||
was:
|
||||
- "Entwicklung und Umsetzung eines übergreifenden Befähigungskonzepts für Prozess-Management"
|
||||
- "Identifikation, Gewinnung und Qualifizierung von geeigneten Key-Usern für Prozesse in den Fachbereichen als dezentrale Prozess-Ansprechpartner"
|
||||
- "Aufbau und Management eines Key-User-Netzwerks, das den regelmäßigen Erfahrungsaustausch fördert und die kontinuierliche Weiterbildung im Prozessmanagement sicherstellt"
|
||||
|
||||
warum:
|
||||
- "Stärkung der Eigenverantwortung der Fachbereiche für ihre Prozesse ('Hilfe zur Selbsthilfe')"
|
||||
- "Sicherstellung der nachhaltigen Anwendung und Verbesserung von Prozessen im Tagesgeschäft"
|
||||
- "Schaffung von Multiplikatoren für Prozessdenken und das Prozessmanagement-Framework in der gesamten Organisation"
|
||||
|
||||
wie:
|
||||
governance:
|
||||
- "Konzeption und Durchführung von zielgruppenspezifischen Trainings und Workshops (Methoden, Tools)"
|
||||
- "Definition der Rolle und Aufgaben von Key-Usern in Abstimmung mit den Fachbereichen"
|
||||
- "Organisation von regelmäßigen Austauschformaten für Key-User (z.B. Community of Practice, Best-Practice-Sharing)"
|
||||
- "Bereitstellung von Lernmaterialien, Leitfäden und Coaching für die Key-User"
|
||||
- "Strategische Netzwerk-Entwicklung: Systematische Identifikation von Kompetenzlücken, gezielte Rekrutierung neuer Key-User"
|
||||
|
||||
frequenz:
|
||||
- "Key-User-Netzwerktreffen: monatlich"
|
||||
- "Trainings: quartalsweise"
|
||||
- "Coaching: bei Bedarf"
|
||||
|
||||
outputs:
|
||||
- "Befähigungskonzept"
|
||||
- "Schulungsmaterialien und Leitfäden"
|
||||
- "Key-User-Dokumentation"
|
||||
- "Community-of-Practice-Protokolle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.5 VERANTWORTUNGSBEREICH 5
|
||||
# ---------------------------------------------------------------------------
|
||||
bereich_5_leistungssteuerung:
|
||||
id: "VB5"
|
||||
name: "Leistungserbringung strukturieren und steuern"
|
||||
|
||||
beschreibung: |
|
||||
Die Prozess-Management-Funktion erbringt ihre Leistungen in vier unterschiedlichen Modi,
|
||||
die sich nach Komplexität, strategischer Bedeutung und Ressourcenbedarf unterscheiden.
|
||||
Diese differenzierte Herangehensweise ermöglicht es, flexibel auf verschiedene
|
||||
organisationale Bedarfe zu reagieren und gleichzeitig die verfügbaren Ressourcen
|
||||
optimal einzusetzen.
|
||||
|
||||
was:
|
||||
- "Standard-Leistungen: Wiederkehrende Unterstützung für operative Prozessbedarfe wie Einzelberatungen, Prozess-Management-Framework-Schulungen oder methodische Kurzberatungen"
|
||||
- "Projekt-Leistungen: Umfangreichere Prozess-Management-Unterstützung, die signifikante Ressourcen bindet (komplette Prozess-Neugestaltungen, bereichsübergreifende Transformationen)"
|
||||
- "Strategische Leistungen: Initiativen zur Weiterentwicklung des gesamten DIGITOMs oder zur grundlegenden Transformation der Prozesslandschaft"
|
||||
- "Krisen-Leistungen: Sofortige Unterstützung bei akuten Prozess-Störungen oder Compliance-Verstößen"
|
||||
|
||||
warum:
|
||||
- "Sicherstellung einer bedarfsgerechten und ressourceneffizienten Leistungserbringung durch klare Priorisierung"
|
||||
- "Schaffung von Transparenz über verfügbare Prozess-Management-Services und deren Zugangswege"
|
||||
- "Ermöglichung einer strategischen Kapazitätsplanung und vorausschauenden Ressourcenallokation"
|
||||
- "Balance zwischen planbaren Aktivitäten und der notwendigen Flexibilität für ungeplante Bedarfe"
|
||||
|
||||
wie:
|
||||
governance:
|
||||
- "Definition klarer Kriterien für die Zuordnung von Anfragen zu Leistungskategorien (Aufwand, Laufzeit, Komplexität, strategische Relevanz)"
|
||||
- "Etablierung unterschiedlicher Beauftragungswege je nach Leistungstyp (von Ticketsystemen bis Gremienentscheidungen)"
|
||||
- "Regelmäßige Überprüfung der Leistungsverteilung und Anpassung der Kapazitätsallokation"
|
||||
- "Transparente Kommunikation der Leistungstypen und ihrer Zugangswege"
|
||||
|
||||
frequenz:
|
||||
- "Kapazitätsplanung: quartalsweise"
|
||||
- "Leistungs-Review: monatlich"
|
||||
|
||||
outputs:
|
||||
- "Leistungskatalog"
|
||||
- "Beauftragungsrichtlinien"
|
||||
- "Kapazitätsberichte"
|
||||
|
||||
# =============================================================================
|
||||
# 4. SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
beschreibung: "Input/Output und typische Abstimmungswege der Prozess-Management-Funktion"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.1 INPUTS
|
||||
# ---------------------------------------------------------------------------
|
||||
inputs:
|
||||
beschreibung: "Was das Prozess-Management empfängt"
|
||||
|
||||
quellen:
|
||||
- von: "vision_board"
|
||||
name: "Vision Board"
|
||||
inhalt: |
|
||||
- Strategische Leitlinien und Entscheidungen zur Ausgestaltung des DIGITOMs
|
||||
- Aufträge zur Umsetzung beschlossener Änderungen
|
||||
- Entscheidungen über Framework-Transformationen, strategische PM-Ausrichtung, Ressourcenrahmen
|
||||
|
||||
- von: "mission_board"
|
||||
name: "Mission Board"
|
||||
inhalt: |
|
||||
- Impulse und Prioritäten aus der strategischen bzw. taktischen Steuerung
|
||||
- Entscheidungen bei Eskalationen von bereichsübergreifenden Prozesskonflikten
|
||||
- Entscheidungen über Projekt-Leistungen, Prioritätskonflikte bei Ressourcenengpässen, Governance-Eskalationen
|
||||
|
||||
- von: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
inhalt: |
|
||||
- Informationen zu geplanten Projekten und priorisierten Initiativen, die prozessuale Änderungen erfordern oder bestehende Prozesse betreffen
|
||||
|
||||
- von: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
inhalt: |
|
||||
- Anforderungen aus der Service-Entwicklung und dem Service-Betrieb, die neue Prozesse oder Anpassungen bestehender Prozesse nötig machen
|
||||
- Feedback zur Anwendbarkeit/Vollständigkeit des Prozess-Management-Frameworks für Service-Prozesse
|
||||
- Feedback zur Effektivität bestehender Prozessmodelle aus Service-Sicht
|
||||
- Informationen zur Ausgestaltung des ITIL-Frameworks mit Bezug zum Prozess-Management-Framework
|
||||
|
||||
- von: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
inhalt: |
|
||||
- Anforderungen von Stakeholdern (z.B. Kundenfeedback, gesetzliche/regulative Vorgaben), welche die internen Prozesse beeinflussen
|
||||
|
||||
- von: "key_user"
|
||||
name: "Key-User"
|
||||
inhalt: |
|
||||
- Bindeglied zwischen zentralem Prozess-Management-Team und Fachbereich
|
||||
- Feedback zur Anwendbarkeit des Frameworks, spezifische Unterstützungsbedarfe, operative Prozessdetails
|
||||
- Anforderungen, Detailfragen und Rückmeldungen aus ihrem Bereich
|
||||
|
||||
- von: "fachbereiche"
|
||||
name: "Fachbereiche / Teams"
|
||||
inhalt: |
|
||||
- Input in Form von Bedarfen (z.B. Wunsch nach Neugestaltung eines Prozesses, Hinweise auf ineffiziente Abläufe, spezifische Beratungsanfragen)
|
||||
- Feedback zur bestehenden Prozessausführung
|
||||
|
||||
- von: "it_architektur"
|
||||
name: "IT-Architektur"
|
||||
inhalt: |
|
||||
- Technische Rahmenbedingungen
|
||||
- Informationen über IT-Systemlandschaft
|
||||
- Technische Standards
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.2 OUTPUTS
|
||||
# ---------------------------------------------------------------------------
|
||||
outputs:
|
||||
beschreibung: "Was das Prozess-Management weitergibt"
|
||||
|
||||
ziele:
|
||||
- an: "vision_board"
|
||||
name: "Vision Board"
|
||||
inhalt: |
|
||||
- Konzepte und Vorschläge zur Weiterentwicklung des DIGITOMs (inkl. Begründungen und Auswirkungen)
|
||||
- Regelmäßige Statusberichte zur Implementierung des DIGITOMs
|
||||
- Meldung von grundsätzlichen Problemen oder Risiken in der Prozesslandschaft (Eskalation)
|
||||
|
||||
- an: "mission_board"
|
||||
name: "Mission Board"
|
||||
inhalt: |
|
||||
- Berichte über operative Herausforderungen und bereichsübergreifende Prozess-Themen, die strategische Entscheidungen erfordern
|
||||
- Empfehlungen für taktische Maßnahmen zur Prozessanpassung
|
||||
|
||||
- an: "ppm"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
inhalt: |
|
||||
- Vorgaben und Richtlinien, wie Projekte im Rahmen des DIGITOM ablaufen sollen (z.B. definierte Prozessschritte, Decision Gates)
|
||||
- Bewertung der Machbarkeit geplanter Projekte aus (organisations-)prozessualer Sicht
|
||||
|
||||
- an: "spm"
|
||||
name: "Service-Portfolio-Management"
|
||||
inhalt: |
|
||||
- Bei Bedarf Unterstützung bei der Gestaltung von servicebezogenen Prozessen (z.B. Einführung neuer Services)
|
||||
- Unterstützung bei der Standardisierung/Dokumentation von Service-Prozessen
|
||||
|
||||
- an: "shm"
|
||||
name: "Stakeholder-Management"
|
||||
inhalt: |
|
||||
- Definierte Prozesse und Verantwortlichkeiten für den Umgang mit externen Stakeholdern
|
||||
- Rückmeldung, wie externe Anforderungen im DIGITOM berücksichtigt wurden
|
||||
|
||||
- an: "fachbereiche"
|
||||
name: "Fachbereiche / Abteilungen"
|
||||
inhalt: |
|
||||
- Schulungsmaterial, Handbücher und Leitfäden zum DIGITOM
|
||||
- Individuelle Beratung und Lösungen für gemeldete Prozessprobleme
|
||||
- Methodische Unterstützung und Empfehlungen zur Prozessgestaltung und Dokumentation
|
||||
- Informationen über anstehende Prozessänderungen
|
||||
|
||||
- an: "key_user"
|
||||
name: "Key-User"
|
||||
inhalt: |
|
||||
- Weitergabe der vom Prozess-Management entwickelten Lösungen, Standards und Guidelines in ihre Teams
|
||||
- Unterstützung der jeweiligen Abteilungen oder Teams bei der Prozessanwendung
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.3 TYPISCHE ABSTIMMUNGSWEGE
|
||||
# ---------------------------------------------------------------------------
|
||||
typische_abstimmungswege:
|
||||
beschreibung: "Standardisierte Interaktionsformate"
|
||||
|
||||
formate:
|
||||
- format: "vision_board_reporting"
|
||||
name: "Vision Board (Regel-Reporting)"
|
||||
frequenz: "quartalsweise"
|
||||
inhalt:
|
||||
- "Status Prozesslandschaft & Framework-Compliance"
|
||||
- "Strategische Abstimmung"
|
||||
- "Eskalationen"
|
||||
- "Grundsatzentscheidungen"
|
||||
|
||||
- format: "mission_board"
|
||||
name: "Mission Board (bei Bedarf)"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Abstimmung bereichsübergreifender Prozessfragen"
|
||||
- "Entscheidungen über Priorisierungen oder Ressourcenkonflikte"
|
||||
|
||||
- format: "beratungsgespraech"
|
||||
name: "Beratungsgespräch / Coaching (Fachbereich/Key-User)"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Methodische Unterstützung bei Prozessfragen"
|
||||
- "Anleitung zur Prozess-Framework-Anwendung"
|
||||
- "Problemlösung"
|
||||
|
||||
- format: "schulung_workshop"
|
||||
name: "Schulung / Workshop (Key-User/Teams)"
|
||||
frequenz: "quartalsweise / bei Bedarf"
|
||||
inhalt:
|
||||
- "Kompetenzaufbau (Methoden, Tools)"
|
||||
- "Praktische Anwendung"
|
||||
- "Befähigung zur dezentralen Prozessarbeit"
|
||||
|
||||
- format: "key_user_netzwerk"
|
||||
name: "Key-User-Netzwerktreffen / Community of Practice"
|
||||
frequenz: "monatlich"
|
||||
inhalt:
|
||||
- "Erfahrungsaustausch"
|
||||
- "Best-Practice-Sharing"
|
||||
- "Feedback zum Framework"
|
||||
- "Multiplikation von Wissen"
|
||||
|
||||
- format: "projekt_meeting"
|
||||
name: "Projekt-Meeting / Abstimmungsrunde"
|
||||
frequenz: "projektabhängig"
|
||||
inhalt:
|
||||
- "Klärung Prozessauswirkungen von Projekten"
|
||||
- "Sicherstellung Prozess-Management-Standards in Projekten"
|
||||
- "Prozess-Integrationsplanung"
|
||||
|
||||
- format: "architektur_board"
|
||||
name: "Architektur-Board"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Abgleich Prozessanforderungen mit technischer Machbarkeit"
|
||||
- "Systemauswahl/-anpassung"
|
||||
|
||||
- format: "ad_hoc_workshop"
|
||||
name: "Ad-hoc-Workshops"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Bei größeren Prozessänderungen oder neuen Initiativen"
|
||||
- "Gemeinsame Erarbeitung von Lösungen"
|
||||
- "Vorbereitung der Umsetzung"
|
||||
|
||||
- format: "ad_hoc_abstimmung"
|
||||
name: "Ad-hoc Abstimmung / Klärung"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Lösung spezifischer, oft bereichsübergreifender Prozesskonflikte"
|
||||
- "Prozess-Management-Framework-Interpretationsfragen"
|
||||
|
||||
- format: "info_veranstaltung"
|
||||
name: "Info-Veranstaltung / Intranet News"
|
||||
frequenz: "bei Bedarf"
|
||||
inhalt:
|
||||
- "Breite Kommunikation von Prozess-Management-Framework-Updates"
|
||||
- "Prozessänderungen"
|
||||
- "Relevante Prozess-Management-Informationen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.4 ESKALATIONSPROZESS
|
||||
# ---------------------------------------------------------------------------
|
||||
eskalationsprozess:
|
||||
beschreibung: "3-stufiger Eskalationsprozess für Prozesskonflikte und Governance-Themen"
|
||||
|
||||
stufen:
|
||||
- stufe: 1
|
||||
name: "Intern"
|
||||
zeitrahmen: "24-48 Stunden"
|
||||
beschreibung: "Klärung innerhalb des Prozess-Management-Teams und mit den direkt Beteiligten"
|
||||
|
||||
- stufe: 2
|
||||
name: "Mission Board"
|
||||
zeitrahmen: "1-2 Wochen"
|
||||
beschreibung: "Eskalation an das Mission Board für taktische Entscheidungen bei bereichsübergreifenden Konflikten"
|
||||
|
||||
- stufe: 3
|
||||
name: "Vision Board"
|
||||
zeitrahmen: "2-4 Wochen"
|
||||
beschreibung: "Eskalation an das Vision Board für strategische Grundsatzentscheidungen"
|
||||
|
||||
# =============================================================================
|
||||
# 5. ORGANISATORISCHE EINORDNUNG
|
||||
# =============================================================================
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
abteilung: "DIGIT (Amt für Digitalisierung und IT)"
|
||||
berichtslinie: "Vision Board (strategisch) / Mission Board (taktisch)"
|
||||
|
||||
designentscheidungen:
|
||||
- id: "D-PM-01"
|
||||
entscheidung: |
|
||||
Prozess-Management als zentrale, befähigende Funktion statt als Kontrollinstanz
|
||||
begruendung: |
|
||||
Fördert Eigenverantwortung der Fachbereiche und schafft Vertrauen.
|
||||
Prozess-Management unterstützt, kontrolliert aber nicht.
|
||||
|
||||
- id: "D-PM-02"
|
||||
entscheidung: |
|
||||
Differenzierte Leistungserbringung nach vier Kategorien
|
||||
begruendung: |
|
||||
Ermöglicht bedarfsgerechte Ressourcensteuerung und klare Erwartungen.
|
||||
Balance zwischen planbaren und ungeplanten Aktivitäten.
|
||||
|
||||
- id: "D-PM-03"
|
||||
entscheidung: |
|
||||
Key-User-Netzwerk als dezentrale Prozess-Kompetenz
|
||||
begruendung: |
|
||||
Nachhaltige Verankerung von Prozesswissen in der Organisation.
|
||||
Multiplikatoren-Effekt für Prozessdenken.
|
||||
|
||||
rollen_in_funktion:
|
||||
- rolle: "Prozess-Manager"
|
||||
typ: "Einzelrolle"
|
||||
beschreibung: |
|
||||
Verantwortlich für das Prozess-Management-Framework und die Prozesslandschaft.
|
||||
Koordiniert Beratung, Befähigung und Leistungserbringung.
|
||||
referenz: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml"
|
||||
|
||||
- rolle: "Key-User (Prozesse)"
|
||||
typ: "Mehrfachrolle"
|
||||
beschreibung: |
|
||||
Dezentrale Prozess-Ansprechpartner in den Fachbereichen.
|
||||
Bindeglied zwischen zentralem PM und Fachbereich.
|
||||
referenz: "#05_prozessmanagement/#05.4_rollen/rolle_key-user-prozesse.yaml"
|
||||
|
||||
vertretung:
|
||||
regel: |
|
||||
Die Vertretung des Prozess-Managers wird im Governance-Modell geregelt.
|
||||
Key-User vertreten sich innerhalb ihres Fachbereichs gegenseitig.
|
||||
|
||||
# =============================================================================
|
||||
# 6. OFFENE PUNKTE
|
||||
# =============================================================================
|
||||
|
||||
offene_punkte:
|
||||
|
||||
fuer_mvp_nicht_adressiert:
|
||||
|
||||
- id: "OPEN-PM-001"
|
||||
thema: "Detail-Definition Key-User-Rolle"
|
||||
beschreibung: |
|
||||
Genaue Aufgaben, Kompetenzen und Zeitbudget der Key-User-Rolle
|
||||
müssen noch mit den Fachbereichen abgestimmt werden.
|
||||
status: "Bei Bedarf zu klären"
|
||||
prioritaet: "mittel"
|
||||
|
||||
- id: "OPEN-PM-002"
|
||||
thema: "Tool-Auswahl Prozess-Management"
|
||||
beschreibung: |
|
||||
Auswahl und Einführung eines zentralen Prozess-Management-Werkzeugs
|
||||
steht noch aus.
|
||||
status: "Post-MVP-Erweiterung"
|
||||
prioritaet: "hoch"
|
||||
|
||||
- id: "OPEN-PM-003"
|
||||
thema: "Integration PPM-Schnittstelle"
|
||||
beschreibung: |
|
||||
Die Schnittstelle zu Projekt-Portfolio-Management muss noch
|
||||
detailliert ausgearbeitet werden.
|
||||
status: "Post-MVP-Erweiterung"
|
||||
prioritaet: "mittel"
|
||||
|
||||
# =============================================================================
|
||||
# 7. REFERENZEN
|
||||
# =============================================================================
|
||||
|
||||
referenzen:
|
||||
|
||||
verwandte_dokumente:
|
||||
- titel: "Rollenbeschreibung Prozess-Manager"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/rolle_prozess-manager.yaml"
|
||||
unterschied: "Rollenbeschreibung = personenzentriert; Funktionsbeschreibung = systemisch"
|
||||
|
||||
- titel: "Governance-Framework PM"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
relevanz: "Übergeordneter Governance-Rahmen für PM-Funktion"
|
||||
|
||||
- titel: "RACI-Matrix PM"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
relevanz: "Detaillierte Verantwortlichkeiten"
|
||||
|
||||
- titel: "Leistungs-Canvas PM"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
relevanz: "Practices und Leistungsportfolio"
|
||||
|
||||
- titel: "DIGITOM Taxonomie"
|
||||
pfad: "#00_meta/digitom_taxonomie.yaml"
|
||||
relevanz: "Konzeptuelle Grundlagen (Funktion, Practice, Rolle, Gremium)"
|
||||
|
||||
- titel: "DPM-Funktionsbeschreibung"
|
||||
pfad: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_funktionsbeschreibung.yaml"
|
||||
relevanz: "Parallele Portfolio-Funktion, Strukturvorlage"
|
||||
|
||||
- titel: "SPM-Funktionsbeschreibung"
|
||||
pfad: "#02_service-portfolio-management/02.1_spm_konzepte/spm_funktionsbeschreibung.yaml"
|
||||
relevanz: "Parallele Portfolio-Funktion"
|
||||
|
||||
- titel: "SHM-Funktionsbeschreibung"
|
||||
pfad: "#03_stakeholder-management/#03.1_funktion/shm_funktionsbeschreibung.yaml"
|
||||
relevanz: "Parallele Management-Funktion"
|
||||
|
||||
# =============================================================================
|
||||
# 8. ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
|
||||
Quelle: #02 - Prozess-Management: Funktionsbeschreibung.docx
|
||||
|
||||
Inhalte:
|
||||
- Zweck und Hauptziel
|
||||
- Funktionsverständnis und Abgrenzung
|
||||
- 5 Verantwortungsbereiche (VB1-VB5)
|
||||
- Schnittstellen (Inputs/Outputs)
|
||||
- Typische Abstimmungswege
|
||||
- Eskalationsprozess (3-stufig)
|
||||
- Organisatorische Einordnung
|
||||
|
||||
Strukturvorlage: spm_funktionsbeschreibung.yaml
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,528 @@
|
|||
# =============================================================================
|
||||
# GOVERNANCE-FRAMEWORK: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "governance-framework"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Governance"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#05 - Prozess-Management: Governance-Modell.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. GOVERNANCE-PHILOSOPHIE UND GRUNDPRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
governance_philosophie:
|
||||
kernaussage: |
|
||||
Das Prozess-Management-Governance-Framework folgt dem Prinzip der
|
||||
"Befähigungs-Governance" - es soll befähigen und unterstützen, nicht
|
||||
kontrollieren und bremsen. Gleichzeitig muss es sich nahtlos in die
|
||||
bestehende DIGITOM-Governance-Architektur integrieren.
|
||||
|
||||
leitprinzipien:
|
||||
- prinzip: "Subsidiarität"
|
||||
beschreibung: |
|
||||
Entscheidungen werden auf der niedrigstmöglichen Ebene getroffen,
|
||||
die kompetent und legitimiert ist. Operative Prozess-Beratung braucht
|
||||
keine Gremien-Freigabe, strategische Framework-Änderungen schon.
|
||||
|
||||
- prinzip: "Proportionalität"
|
||||
beschreibung: |
|
||||
Der Governance-Aufwand muss dem Risiko und der Tragweite einer
|
||||
Entscheidung angemessen sein. Eine Template-Anpassung braucht weniger
|
||||
Governance als eine komplette Framework-Transformation.
|
||||
|
||||
- prinzip: "Integration"
|
||||
beschreibung: |
|
||||
PM-Governance ergänzt die bestehende DIGITOM-Governance, ersetzt sie nicht.
|
||||
Vision Board, Mission Board und DSR bleiben die primären Steuerungsgremien.
|
||||
|
||||
- prinzip: "Transparenz"
|
||||
beschreibung: |
|
||||
Alle Governance-Entscheidungen und ihre Begründungen müssen nachvollziehbar
|
||||
dokumentiert und kommuniziert werden.
|
||||
|
||||
# =============================================================================
|
||||
# 2. INTERNE PM-GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
interne_governance:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.1 Framework-Änderungs-Governance
|
||||
# ---------------------------------------------------------------------------
|
||||
framework_aenderungen:
|
||||
beschreibung: |
|
||||
Die Governance für Framework-Änderungen folgt einem dreistufigen Modell,
|
||||
das die Komplexität und Tragweite der Änderungen berücksichtigt.
|
||||
|
||||
kategorie_a:
|
||||
name: "Operative Anpassungen"
|
||||
definition: |
|
||||
Kleinere Verbesserungen, Klarstellungen oder Ergänzungen,
|
||||
die die Framework-Grundlogik nicht verändern.
|
||||
beispiele:
|
||||
- "Template-Updates"
|
||||
- "Methodenbeschreibungs-Präzisierungen"
|
||||
- "Tool-Konfigurationsanpassungen"
|
||||
- "FAQ-Ergänzungen"
|
||||
entscheidungsweg:
|
||||
- schritt: 1
|
||||
aktion: "Prozess-Framework-Manager*in trifft Entscheidung eigenständig nach fachlicher Prüfung und Dokumentation"
|
||||
- schritt: 2
|
||||
aktion: "Prozess-Management-Team gibt formale Freigabe"
|
||||
- schritt: 3
|
||||
aktion: "Leiter*in Prozess-Management wird zeitnah informiert"
|
||||
- schritt: 4
|
||||
aktion: "Betroffene Process Owner und Key-User werden über reguläre Kommunikationskanäle benachrichtigt"
|
||||
implementierung:
|
||||
- "Kann sofort umgesetzt werden"
|
||||
- "Änderungen werden im Framework-Changelog dokumentiert"
|
||||
|
||||
kategorie_b:
|
||||
name: "Taktische Erweiterungen"
|
||||
definition: |
|
||||
Bedeutendere Änderungen, die neue Elemente einführen oder bestehende erweitern,
|
||||
aber die Framework-Architektur beibehalten.
|
||||
beispiele:
|
||||
- "Neue Prozess-Kategorien"
|
||||
- "Zusätzliche PM-Governance-Elemente"
|
||||
- "Erweiterte KPI-Systematiken"
|
||||
- "Neue Qualifizierungsmodule"
|
||||
entscheidungsweg:
|
||||
- schritt: 1
|
||||
aktion: "Prozess-Framework-Manager*in entwickelt den Vorschlag"
|
||||
- schritt: 2
|
||||
aktion: "Prozess-Management-Team gibt formale Freigabe"
|
||||
- schritt: 3
|
||||
aktion: "Betroffene Process Owner werden konsultiert und können Einwände oder Verbesserungsvorschläge einbringen"
|
||||
- schritt: 4
|
||||
aktion: "Mission Board wird über die Änderung informiert und kann Feedback geben"
|
||||
implementierung:
|
||||
- "Erfordert Vorlaufzeit für Stakeholder-Abstimmung und Kommunikation"
|
||||
- "Implementierung erfolgt zu definierten Stichtagen für Planbarkeit"
|
||||
|
||||
kategorie_c:
|
||||
name: "Strategische Transformationen"
|
||||
definition: |
|
||||
Fundamentale Änderungen der Framework-Philosophie oder -Architektur,
|
||||
die das Operating Model betreffen.
|
||||
beispiele:
|
||||
- "Wechsel der Grundmethodik"
|
||||
- "Komplette Neudefinition der PM-Governance-Struktur"
|
||||
- "Integration neuer strategischer Anforderungen"
|
||||
entscheidungsweg:
|
||||
- schritt: 1
|
||||
aktion: "Prozess-Framework-Manager*in erarbeitet Konzept mit Stakeholder-Analyse und Impact-Assessment"
|
||||
- schritt: 2
|
||||
aktion: "Leiter*in Prozess-Management koordiniert umfassende Abstimmungsrunde mit allen betroffenen Bereichen"
|
||||
- schritt: 3
|
||||
aktion: "Mission Board führt Vorbewertung durch und gibt Empfehlung ab"
|
||||
- schritt: 4
|
||||
aktion: "Vision Board trifft finale Entscheidung nach Präsentation des Konzepts"
|
||||
implementierung:
|
||||
- "Erfordert längere Vorlaufzeit mit detailliertem Change Management-Plan"
|
||||
- "Implementierung erfolgt als formales Transformationsprojekt mit entsprechendem Projektmanagement"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.2 Ressourcen- und Prioritäts-Governance
|
||||
# ---------------------------------------------------------------------------
|
||||
ressourcen_governance:
|
||||
kapazitaetsallokation:
|
||||
beschreibung: |
|
||||
Die Leiter*in Prozess-Management verteilt die verfügbaren PM-Kapazitäten
|
||||
nach folgender Prioritätslogik:
|
||||
prioritaeten:
|
||||
- prio: 1
|
||||
typ: "Strategische Leistungen mit Vision Board-Freigabe"
|
||||
- prio: 2
|
||||
typ: "Projekt Leistungen mit Mission Board-Freigabe"
|
||||
- prio: 3
|
||||
typ: "Compliance-kritische Standard Leistungen"
|
||||
- prio: 4
|
||||
typ: "Geplante Standard Leistungen aus Jahresplanung"
|
||||
- prio: 5
|
||||
typ: "Ad-hoc Standard Leistungen nach Verfügbarkeit"
|
||||
|
||||
interne_koordination:
|
||||
- format: "Wöchentliche PM-Team-Abstimmung"
|
||||
inhalt: "Operative Koordination, Ressourcenplanung, Problem-Eskalation"
|
||||
- format: "Monatliche Stakeholder-Runde"
|
||||
inhalt: "Review mit Process Ownern, Feedback-Sammlung, Planungsabstimmung"
|
||||
- format: "Regelmäßige Governance-Review"
|
||||
inhalt: "Framework-Performance, Governance-Optimierung, strategische Ausrichtung"
|
||||
|
||||
# =============================================================================
|
||||
# 3. LEISTUNGS-GOVERNANCE UND BEAUFTRAGUNG
|
||||
# =============================================================================
|
||||
|
||||
leistungs_governance:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 Leistungskategorien
|
||||
# ---------------------------------------------------------------------------
|
||||
leistungskategorien:
|
||||
|
||||
standard_leistungen:
|
||||
definition: |
|
||||
Wiederkehrende, standardisierte PM-Unterstützung für operative Bedarfe.
|
||||
beispiele:
|
||||
- "Prozess-Workshops in definierten Bereichen"
|
||||
- "Einzelberatungen"
|
||||
- "PM-Framework-Schulungen"
|
||||
- "Prozess-Assessments"
|
||||
- "Key-User-Support"
|
||||
beauftragungsberechtigung: "Alle DIGITOM-Mitarbeitenden über Ticketsystem oder direkte Anfrage"
|
||||
entscheidungsweg:
|
||||
- "Anfragen werden von zuständiger PM-Rolle (meist Prozess-Berater*in) bewertet"
|
||||
- "Bearbeitung nach Verfügbarkeit und Priorität"
|
||||
- "Bei Ressourcenkonflikten entscheidet Leiter*in Prozess-Management"
|
||||
|
||||
projekt_leistungen:
|
||||
definition: |
|
||||
Umfangreichere, projektähnliche PM-Unterstützung, die signifikante Ressourcen bindet.
|
||||
beispiele:
|
||||
- "Komplette Prozess-Neugestaltung"
|
||||
- "PM-Tool-Einführung"
|
||||
- "Bereichsspezifische PM-Framework-Entwicklung"
|
||||
- "Umfassende Prozess-Transformationen"
|
||||
abgrenzung:
|
||||
quantitativ:
|
||||
- "Leistung über 10 Beratungstage"
|
||||
- "Laufzeit über 4 Wochen"
|
||||
qualitativ:
|
||||
- "Leistung mit mehreren Fachbereichen/Abteilungen"
|
||||
- "Framework-Implikationen"
|
||||
- "Strategische Relevanz"
|
||||
beauftragungsberechtigung: "Fachbereichs-/Abteilungsleitungen, Projektleitungen, Gremien"
|
||||
entscheidungsweg:
|
||||
- "Antrag wird von Leiter*in PM formuliert und in Mission Board eingebracht"
|
||||
- "Mission Board prüft strategische Passung, Ressourcen-Impact und Priorisierung"
|
||||
- "Bei Freigabe wird Leistung als Projekt konfiguriert mit entsprechendem Projektmanagement"
|
||||
|
||||
strategische_leistungen:
|
||||
definition: |
|
||||
Strategische PM-Initiativen, die das Operating Model weiterentwickeln oder transformieren.
|
||||
beispiele:
|
||||
- "Entwicklung neuer Governance-Strukturen"
|
||||
- "Strategische Prozess-Digitalisierung"
|
||||
- "Organisationsweite Methodeneinführung"
|
||||
- "Integration in Transformationsprojekte"
|
||||
beauftragungsberechtigung:
|
||||
- "Vision Board (proaktiv)"
|
||||
- "Mission Board/Leiter*in PM (als Vorschlag)"
|
||||
entscheidungsweg:
|
||||
- "Konzeptentwicklung durch PM-Team mit strategischer Stakeholder-Analyse"
|
||||
- "Vision Board-Präsentation mit Ressourcen-Impact, Zeitplan und erwarteten Outcomes"
|
||||
- "Bei Freigabe erfolgt Mandatierung als strategisches Projekt"
|
||||
|
||||
krisen_leistungen:
|
||||
definition: |
|
||||
Dringende Prozess-Unterstützung bei akuten Problemen oder Krisen.
|
||||
beispiele:
|
||||
- "Compliance-Verstöße mit Prozess-Bezug"
|
||||
- "Schwerwiegende Prozess-Störungen"
|
||||
- "Akute Konfliktmediation"
|
||||
beauftragungsberechtigung:
|
||||
- "Jede Abteilungsleitung bei akuten Problemen"
|
||||
- "Amtsleitung bei kritischen Situationen"
|
||||
entscheidungsweg:
|
||||
- "Sofortige Bewertung und Klassifizierung durch Leiter*in PM"
|
||||
- "Ressourcen-Umschichtung nach Krisenlogik (andere Leistungen werden pausiert)"
|
||||
- "Bildung eines Response-Teams aus relevanten PM-Rollen"
|
||||
- "Nachträgliche Information an Mission Board"
|
||||
- "Post-Crisis-Review zur Governance-Optimierung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 Projektzentrierte Prozessgestaltung
|
||||
# ---------------------------------------------------------------------------
|
||||
projektzentrierte_prozessgestaltung:
|
||||
beschreibung: "Spezial-PM-Governance für Projekte mit Prozess-Impact"
|
||||
|
||||
obligatorische_compliance:
|
||||
hinweis: "Jedes Projekt, das Prozesse neu gestaltet oder verändert, muss folgende PM-Elemente berücksichtigen:"
|
||||
elemente:
|
||||
- name: "Key-User-Integration"
|
||||
beschreibung: "Key-User müssen konsultiert und in die Prozessgestaltung eingebunden werden"
|
||||
- name: "PM-Framework-konforme Dokumentation"
|
||||
beschreibung: "Neue Prozesse müssen nach PM-Standards dokumentiert werden"
|
||||
- name: "Process Owner-Koordination"
|
||||
beschreibung: "Bei Änderungen an bestehenden Prozessen muss der zuständige Process Owner konsultiert werden"
|
||||
- name: "Standardnotation"
|
||||
beschreibung: "Prozessmodellierung muss PM-Framework-konforme Notation verwenden"
|
||||
|
||||
process_owner_abnahme:
|
||||
name: "Process Owner-Abnahme als Quality Gate"
|
||||
beschreibung: |
|
||||
Bei allen Projekten, die Prozesse verändern, die einem Process Owner
|
||||
zugeordnet sind, muss dieser formale Abnahme-Verantwortung übernehmen.
|
||||
pruefbereiche:
|
||||
- "Fachliche Korrektheit: End-to-End-Konsistenz des veränderten Prozesses"
|
||||
- "Schnittstellen-Impact: Auswirkungen auf vor- und nachgelagerte Prozesse"
|
||||
- "Implementierbarkeit: Praktische Umsetzbarkeit im operativen Betrieb"
|
||||
veto_recht:
|
||||
- "Process Owner hat finales Veto-Recht bei inhaltlichen Aspekten"
|
||||
- "Bei Veto: Verpflichtende Mediation durch PM-Leitung"
|
||||
- "Eskalation ans Mission Board nur bei unlösbaren Konflikten"
|
||||
- "Dokumentationspflicht für Veto-Gründe"
|
||||
|
||||
pm_qualitaetspruefung:
|
||||
name: "PM-Qualitätsprüfung als methodisches Quality Gate"
|
||||
beschreibung: |
|
||||
Für alle Projekte mit Prozess-Impact führt die PM-Funktion eine formale
|
||||
Qualitätsprüfung durch (vor Projektabschluss, Voraussetzung für finale Abnahme).
|
||||
pruefbereiche:
|
||||
- "PM-Framework-Compliance-Check: Einhaltung aller PM-Standards"
|
||||
- "Cross-Process-Impact-Analysis: Bewertung möglicher Seiteneffekte auf andere Prozesse"
|
||||
- "Tool-Kompatibilität: Integration in bestehende PM-Tools"
|
||||
- "Dokumentations-Vollständigkeit: Vollständige und korrekte Dokumentation"
|
||||
|
||||
# =============================================================================
|
||||
# 4. EXTERNE GOVERNANCE-INTEGRATION
|
||||
# =============================================================================
|
||||
|
||||
externe_governance:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.1 Vision Board-Integration
|
||||
# ---------------------------------------------------------------------------
|
||||
vision_board:
|
||||
pm_relevante_entscheidungen:
|
||||
- "PM-Strategische Ausrichtung: Grundsätzliche Rolle und Positionierung der PM-Funktion in DIGITOM"
|
||||
- "Framework-Transformationen: Freigabe strategischer Framework-Änderungen (Kategorie C)"
|
||||
- "Strategische Leistungen: Beauftragung und Priorisierung strategischer PM-Initiativen"
|
||||
- "PM-Ressourcen-Rahmen: Grundsätzliche Kapazitäts- und Budget-Entscheidungen für PM-Funktion"
|
||||
|
||||
pm_input:
|
||||
beschreibung: "Die Leiter*in PM liefert strategischen Input für Vision Board-Entscheidungen:"
|
||||
inhalte:
|
||||
- "Prozesslandschafts-Assessment: Jährliche Bewertung der Prozess-Reife und strategischen Prozess-Herausforderungen"
|
||||
- "Framework-Entwicklungsvorschläge: Vorschläge für strategische Framework-Weiterentwicklungen"
|
||||
- "Organisationsreife-Einschätzung: Assessment der PM-Kompetenz und Change-Bereitschaft in DIGITOM"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.2 Mission Board-Integration
|
||||
# ---------------------------------------------------------------------------
|
||||
mission_board:
|
||||
pm_relevante_entscheidungen:
|
||||
beschreibung: "Das Mission Board fungiert als taktische Steuerungsebene für PM-Leistungen:"
|
||||
entscheidungen:
|
||||
- "Freigabe von Projekt-Leistungen: Entscheidung über ressourcenintensive PM-Unterstützung"
|
||||
- "Prioritäts-Konflikte: Auflösung von Ressourcenkonflikten zwischen verschiedenen PM-Anfragen"
|
||||
- "Prozess-Governance-Eskalationen: Entscheidung bei schwerwiegenden Governance-Konflikten"
|
||||
- "Jährliche PM-Leistungsplanung: Freigabe des Jahresplans für geplante PM-Leistungen"
|
||||
|
||||
pm_reporting:
|
||||
- "Regelmäßige Governance-Reports: Performance der PM-Funktion, Framework-Adoption, kritische Issues"
|
||||
- "Ad-hoc Eskalations-Briefings: Bei strategischen Problemen oder Ressourcenengpässen"
|
||||
- "Jährliche Leistungsplanung: Vorstellung des geplanten Leistungs-Portfolios für das Folgejahr"
|
||||
|
||||
# =============================================================================
|
||||
# 5. VERANTWORTUNGS- UND ESKALATIONSARCHITEKTUR
|
||||
# =============================================================================
|
||||
|
||||
verantwortungsarchitektur:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.1 Primäre Verantwortlichkeiten
|
||||
# ---------------------------------------------------------------------------
|
||||
primaere_verantwortlichkeiten:
|
||||
|
||||
leiter_pm:
|
||||
rolle: "Leiter*in Prozess-Management"
|
||||
verantwortlichkeiten:
|
||||
- "Strategische Verantwortung: Ausrichtung der PM-Funktion an DIGITOM-Zielen"
|
||||
- "Ressourcen-Verantwortung: Allokation von PM-Kapazitäten nach strategischen Prioritäten"
|
||||
- "Stakeholder-Verantwortung: Management der Beziehungen zu Gremien und Fachbereichen"
|
||||
- "Eskalations-Verantwortung: Entscheidung bei PM-internen Konflikten und strategischen Issues"
|
||||
delegation_nach_oben:
|
||||
- "Konflikte mit gesetzlichen vs. strategischen Prioritäten"
|
||||
- "Grundsätzliche Richtungsentscheidungen"
|
||||
- "Politisch sensible Themen"
|
||||
|
||||
prozess_framework_manager:
|
||||
rolle: "Prozess-Framework-Manager*in"
|
||||
verantwortlichkeiten:
|
||||
- "Framework-Verantwortung: Qualität, Aktualität und Anwendbarkeit des PM-Frameworks"
|
||||
- "Standards-Verantwortung: Definition und Pflege einheitlicher PM-Standards"
|
||||
- "Innovation-Verantwortung: Integration neuer Tools, Methoden und Best Practices"
|
||||
|
||||
prozesslandschafts_koordinator:
|
||||
rolle: "Prozesslandschafts-Koordinator*in"
|
||||
verantwortlichkeiten:
|
||||
- "Governance-Verantwortung: Überwachung der PM-Framework-Compliance und Governance-Qualität"
|
||||
- "Koordinations-Verantwortung: Abstimmung zwischen verschiedenen Process Ownern"
|
||||
- "Reporting-Verantwortung: Bereitstellung von PM-Governance-Transparenz für Gremien"
|
||||
|
||||
prozess_berater:
|
||||
rolle: "Prozess-Berater*in"
|
||||
verantwortlichkeiten:
|
||||
- "Leistungsverantwortung: Qualität der direkten PM-Beratung und -Unterstützung"
|
||||
- "Kundenverantwortung: Zufriedenheit und Erfolg der betreuten Fachbereiche"
|
||||
|
||||
key_user_netzwerk_manager:
|
||||
rolle: "Key-User-Netzwerk-Manager*in"
|
||||
verantwortlichkeiten:
|
||||
- "Community-Verantwortung: Aufbau und Betreuung des dezentralen PM-Netzwerks"
|
||||
- "Befähigungs-Verantwortung: Kompetenzentwicklung und Selbsthilfe-Befähigung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.2 Eskalationswege
|
||||
# ---------------------------------------------------------------------------
|
||||
eskalationswege:
|
||||
|
||||
stufe_1:
|
||||
name: "Operative Eskalation (binnen PM-Funktion)"
|
||||
trigger:
|
||||
- "Ressourcenkonflikte"
|
||||
- "Komplexe Beratungsfälle"
|
||||
- "Methodenunklarheiten"
|
||||
eskalationsweg: "Beratende PM-Rolle → Leiter*in PM"
|
||||
zeitrahmen: "24-48 Stunden für Entscheidung"
|
||||
outcomes:
|
||||
- "Ressourcen-Umpriorisierung"
|
||||
- "Methodische Klärung"
|
||||
- "Interne Lösungsfindung"
|
||||
|
||||
stufe_2:
|
||||
name: "Taktische Eskalation (Mission Board)"
|
||||
trigger:
|
||||
- "Strategische Ressourcenkonflikte"
|
||||
- "Framework-Widerstand"
|
||||
- "Prozessübergreifende Konflikte"
|
||||
eskalationsweg: "Leiter*in PM → Mission Board (über reguläre Sitzungen oder ad-hoc)"
|
||||
zeitrahmen: "1-2 Wochen für Mission Board-Behandlung"
|
||||
outcomes:
|
||||
- "Prioritäts-Neuordnung"
|
||||
- "Konfliktlösung"
|
||||
- "Zusätzliche Ressourcen-Freigabe"
|
||||
verpflichtende_eskalation:
|
||||
- "Ressourcenkonflikte zwischen Projekten mit harten Deadlines"
|
||||
- "Governance-Lücken, die nicht binnen 4 Wochen gelöst werden können"
|
||||
- "Verweigerung der Zusammenarbeit durch Abteilungen"
|
||||
- "Grundsätzliche Framework-Widerstände aus mehreren Bereichen"
|
||||
|
||||
stufe_3:
|
||||
name: "Strategische Eskalation (Vision Board)"
|
||||
trigger:
|
||||
- "Grundsätzliche Framework-Konflikte"
|
||||
- "Strategische PM-Richtungsfragen"
|
||||
- "Organisationsweite PM-Krisen"
|
||||
eskalationsweg: "Mission Board → Vision Board oder direkt durch Leiter*in PM bei Krisensituationen"
|
||||
zeitrahmen: "2-4 Wochen für strategische Entscheidung"
|
||||
outcomes:
|
||||
- "Strategische Neuausrichtung"
|
||||
- "Framework-Grundsatzentscheidungen"
|
||||
- "Organisationsänderungen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.3 Governance-Lücken-Management
|
||||
# ---------------------------------------------------------------------------
|
||||
governance_luecken_management:
|
||||
beschreibung: "Wenn die PLK eine Governance-Lücke im DIGIT/DIGITOM identifiziert:"
|
||||
|
||||
kurzfristig_loesbar:
|
||||
- "PLK informiert Prozessberater*in"
|
||||
- "Prozessberater*in spricht mit verantwortlicher Person im Fachbereich"
|
||||
- "Bei erfolgreicher Lösung: Dokumentation durch PLK, Monitoring der Umsetzung"
|
||||
|
||||
langfristig_strukturell:
|
||||
- "PLK dokumentiert die Governance-Lücke"
|
||||
- "Strukturierte Eskalation über LPM ans Mission Board"
|
||||
- "Mission Board priorisiert und entscheidet über Maßnahmen"
|
||||
- "PLK verfolgt initiierte Maßnahmen bis zur Schließung der Lücke nach"
|
||||
|
||||
keine_kooperation:
|
||||
- "Direkte Eskalation ans Mission Board mit Hinweis auf Verweigerung"
|
||||
- "Mission Board entscheidet über verbindliche Maßnahmen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.4 Konfliktlösungs-Mechanismen
|
||||
# ---------------------------------------------------------------------------
|
||||
konfliktloesung:
|
||||
|
||||
framework_widerstand:
|
||||
- stufe: 1
|
||||
aktion: "Prozess-Berater*in führt Stakeholder-Dialog zur Bedarfsklärung"
|
||||
- stufe: 2
|
||||
aktion: "Prozesslandschafts-Koordinator*in moderiert Interessenausgleich"
|
||||
- stufe: 3
|
||||
aktion: "Leiter*in PM eskaliert an zuständiges Gremium für autoritative Entscheidung"
|
||||
|
||||
ressourcen_konkurrenz:
|
||||
- "Dokumentation aller konkurrierenden Anfragen mit Business Case und Dringlichkeit"
|
||||
- "Stakeholder-Konsultation zur Interessenabwägung"
|
||||
- "Entscheidung durch Leiter*in PM nach definierten Prioritätskriterien"
|
||||
- "Transparente Kommunikation der Entscheidung und alternative Lösungsoptionen"
|
||||
|
||||
compliance_konflikte:
|
||||
- "Sofortige Einbindung relevanter Compliance-Funktionen (ISB, Datenschutz, QM)"
|
||||
- "Gemeinsame Lösungsentwicklung zwischen PM und Compliance-Bereichen"
|
||||
- "Eskalation an Mission Board bei unauflösbaren Zielkonflikten"
|
||||
|
||||
# =============================================================================
|
||||
# 6. JAHRESPLANUNG UND STRATEGISCHE LEISTUNGS-GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
jahresplanung:
|
||||
|
||||
planungsprozess:
|
||||
- zeitpunkt: "Q4 des Vorjahres"
|
||||
aktivitaet: "Bedarfserhebung bei allen Stakeholdern und strategische Priorisierung"
|
||||
- zeitpunkt: "Dezember"
|
||||
aktivitaet: "Entwurf des PM-Leistungsplans mit Ressourcenallokation und Zeitplanung"
|
||||
- zeitpunkt: "Januar"
|
||||
aktivitaet: "Mission Board-Freigabe des Plans nach eventuellen Anpassungen"
|
||||
- zeitpunkt: "Februar"
|
||||
aktivitaet: "Kommunikation und Abstimmung der geplanten Leistungen mit Stakeholdern"
|
||||
|
||||
leistungs_portfolio_struktur:
|
||||
hinweis: "Beispielhafte Verteilung"
|
||||
verteilung:
|
||||
- kategorie: "Strategische Leistungen"
|
||||
anteil: "40%"
|
||||
beschreibung: "Vom Vision Board beauftragte strategische Initiativen"
|
||||
- kategorie: "Projekt Leistungen"
|
||||
anteil: "30%"
|
||||
beschreibung: "Geplante projektbezogene PM-Unterstützung nach Mission Board-Priorisierung"
|
||||
- kategorie: "Geplante Standard-Leistungen"
|
||||
anteil: "20%"
|
||||
beschreibung: "Regelmäßige Leistungen wie Schulungen, Community-Events, Framework-Updates"
|
||||
- kategorie: "Krisen-Reserve"
|
||||
anteil: "10%"
|
||||
beschreibung: "Reserve für ungeplante Krisen-Leistungen"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #05 - Prozess-Management: Governance-Modell.docx
|
||||
|
||||
Inhalte:
|
||||
- Governance-Philosophie und Leitprinzipien
|
||||
- Interne PM-Governance (Framework-Änderungen Kat. A/B/C)
|
||||
- Leistungs-Governance (4 Leistungskategorien)
|
||||
- Projektzentrierte Prozessgestaltung (Quality Gates)
|
||||
- Externe Governance-Integration (VB, MB)
|
||||
- Eskalationsarchitektur (3 Stufen)
|
||||
- Konfliktlösungs-Mechanismen
|
||||
- Jahresplanung
|
||||
autor: "DIGITOM-Projekt"
|
||||
721
#05_prozessmanagement/#05.2_governance/pm_raci.yaml
Normal file
721
#05_prozessmanagement/#05.2_governance/pm_raci.yaml
Normal file
|
|
@ -0,0 +1,721 @@
|
|||
# =============================================================================
|
||||
# RACI-MATRIX: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Excel-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "raci-matrix"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#06 - Prozess-Management: RACI Matrix.xlsx"
|
||||
|
||||
# =============================================================================
|
||||
# RACI-LEGENDE
|
||||
# =============================================================================
|
||||
|
||||
legende:
|
||||
R:
|
||||
name: "Responsible"
|
||||
beschreibung: "Führt die Aktivität aus, ist operativ verantwortlich"
|
||||
A:
|
||||
name: "Accountable"
|
||||
beschreibung: "Hat die finale Verantwortung und Entscheidungsbefugnis"
|
||||
C:
|
||||
name: "Consulted"
|
||||
beschreibung: "Wird vor der Entscheidung konsultiert, gibt fachlichen Input"
|
||||
I:
|
||||
name: "Informed"
|
||||
beschreibung: "Wird über das Ergebnis informiert"
|
||||
|
||||
kombinationen:
|
||||
"A/R": "Accountable und Responsible in einer Rolle"
|
||||
"R (lokal)": "Responsible auf lokaler Ebene (Key-User-Netzwerk/Bereich)"
|
||||
"C (fachlich)": "Consulted für Fachprozesse"
|
||||
|
||||
hinweis_entscheidung: "Bei Unentschieden im PM-Team hat LPM Entscheidungshoheit"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
rollen:
|
||||
# Interne PM-Rollen
|
||||
LPM:
|
||||
name: "Leitung Prozess-Management"
|
||||
fokus: "Strategische Führung, Ressourcenverantwortung"
|
||||
kategorie: "intern"
|
||||
|
||||
PFM:
|
||||
name: "Prozess-Framework-Manager:in"
|
||||
fokus: "Methodische Standards, Framework-Entwicklung"
|
||||
kategorie: "intern"
|
||||
|
||||
PLK:
|
||||
name: "Prozesslandschafts-Koordinator:in"
|
||||
fokus: "Übergreifende Prozessharmonisierung"
|
||||
kategorie: "intern"
|
||||
|
||||
PB:
|
||||
name: "Prozess-Berater:in-Team"
|
||||
fokus: "Operative Beratung und Durchführung"
|
||||
kategorie: "intern"
|
||||
|
||||
KNM:
|
||||
name: "Key-User-Netzwerk-Manager:in"
|
||||
fokus: "Dezentrale PM-Befähigung, Community-Management"
|
||||
kategorie: "intern"
|
||||
|
||||
# Schnittstellenrollen
|
||||
PO:
|
||||
name: "Process Owner"
|
||||
fokus: "Fachliche Prozessverantwortung"
|
||||
kategorie: "schnittstelle"
|
||||
|
||||
KU:
|
||||
name: "Key User"
|
||||
fokus: "Lokale Prozessexpertise, erste Anlaufstelle"
|
||||
kategorie: "schnittstelle"
|
||||
|
||||
# Governance-Rollen
|
||||
GL:
|
||||
name: "Geschäftsleitung (VB/MB/AL konsolidiert)"
|
||||
fokus: "Strategische Entscheidungen"
|
||||
kategorie: "governance"
|
||||
hinweis: "VB = Vision Board, MB = Mission Board, AL = Amtsleitung"
|
||||
|
||||
# Externe Rollen
|
||||
PL:
|
||||
name: "Projektleitung"
|
||||
fokus: "Projektspezifische Umsetzung"
|
||||
kategorie: "extern"
|
||||
|
||||
QS:
|
||||
name: "Qualitätssicherung (ISB/DSB/ITA konsolidiert)"
|
||||
fokus: "Compliance und technische Standards"
|
||||
kategorie: "extern"
|
||||
hinweis: "ISB = Informationssicherheitsbeauftragter, DSB = Datenschutzbeauftragter, ITA = IT-Architektur"
|
||||
|
||||
FBL:
|
||||
name: "Fachbereichsleitung"
|
||||
fokus: "Fachliche Auftraggeber"
|
||||
kategorie: "extern"
|
||||
|
||||
# =============================================================================
|
||||
# 1. FRAMEWORK-GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
bereich_1_framework_governance:
|
||||
name: "Framework-Governance"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 1.1 Framework-Entwicklung
|
||||
# ---------------------------------------------------------------------------
|
||||
framework_entwicklung:
|
||||
name: "Framework-Entwicklung"
|
||||
|
||||
kategorie_a_operative_anpassungen:
|
||||
name: "Kategorie A: Operative Anpassungen"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Methoden-Feintuning"
|
||||
LPM: "I"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "I"
|
||||
GL: "-"
|
||||
KNM: "I"
|
||||
KU: "I"
|
||||
PM_Team: "A/R"
|
||||
|
||||
- aktivitaet: "Template-Updates"
|
||||
LPM: "I"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "I"
|
||||
GL: "-"
|
||||
KNM: "I"
|
||||
KU: "I"
|
||||
PM_Team: "A/R"
|
||||
|
||||
- aktivitaet: "Dokumentation aktualisieren"
|
||||
LPM: "I"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "I"
|
||||
GL: "-"
|
||||
KNM: "I"
|
||||
KU: "I"
|
||||
PM_Team: "A/R"
|
||||
|
||||
kategorie_b_taktische_erweiterungen:
|
||||
name: "Kategorie B: Taktische Erweiterungen"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Neue Methoden entwickeln"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "I"
|
||||
KNM: "C"
|
||||
KU: "I"
|
||||
|
||||
- aktivitaet: "Standards erweitern"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "I"
|
||||
KNM: "C"
|
||||
KU: "I"
|
||||
|
||||
- aktivitaet: "Tool-Integration"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "I"
|
||||
GL: "I"
|
||||
QS: "C"
|
||||
|
||||
kategorie_c_strategische_transformationen:
|
||||
name: "Kategorie C: Strategische Transformationen"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Framework-Neuausrichtung"
|
||||
LPM: "R"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "A"
|
||||
KNM: "C"
|
||||
KU: "I"
|
||||
|
||||
- aktivitaet: "Paradigmenwechsel"
|
||||
LPM: "R"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "A"
|
||||
KNM: "C"
|
||||
KU: "I"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 1.2 Framework-Kommunikation
|
||||
# ---------------------------------------------------------------------------
|
||||
framework_kommunikation:
|
||||
name: "Framework-Kommunikation"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Schulungskonzepte"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
KNM: "R"
|
||||
KU: "I"
|
||||
|
||||
- aktivitaet: "Updates kommunizieren"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
KNM: "R"
|
||||
KU: "R (lokal)"
|
||||
hinweis: "R (lokal) = für KU-Netzwerk/Bereich"
|
||||
|
||||
- aktivitaet: "Framework-Portal pflegen"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
KNM: "C"
|
||||
|
||||
# =============================================================================
|
||||
# 2. LEISTUNGSERBRINGUNG
|
||||
# =============================================================================
|
||||
|
||||
bereich_2_leistungserbringung:
|
||||
name: "Leistungserbringung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.1 Standard Leistungen
|
||||
# ---------------------------------------------------------------------------
|
||||
standard_leistungen:
|
||||
name: "Standard Leistungen (Regelgeschäft)"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Leistungsanfrage annehmen"
|
||||
LPM: "I"
|
||||
PFM: "I"
|
||||
PLK: "I"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
FBL: "C"
|
||||
|
||||
- aktivitaet: "Aufwand schätzen"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "I"
|
||||
|
||||
- aktivitaet: "Leistung durchführen"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
KU: "C"
|
||||
|
||||
- aktivitaet: "Qualität sicherstellen"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.2 Projekt Leistungen
|
||||
# ---------------------------------------------------------------------------
|
||||
projekt_leistungen:
|
||||
name: "Projekt Leistungen (Geplante Projekte)"
|
||||
hinweis: "Bei kritischen Konflikten: Empfehlung an MB, finale Entscheidung durch MB"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Projektantrag bewerten"
|
||||
LPM: "R"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "A"
|
||||
PL: "R"
|
||||
|
||||
- aktivitaet: "Ressourcen zuweisen"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "I"
|
||||
GL: "I"
|
||||
PL: "C"
|
||||
|
||||
- aktivitaet: "PM-Integration planen"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "R"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
PL: "C"
|
||||
|
||||
- aktivitaet: "Projekt begleiten"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
PL: "A"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.3 Strategische Leistungen
|
||||
# ---------------------------------------------------------------------------
|
||||
strategische_leistungen:
|
||||
name: "Strategische Leistungen (Transformationsinitiativen)"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Initiative konzipieren"
|
||||
LPM: "R"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
GL: "I"
|
||||
|
||||
- aktivitaet: "Business Case erstellen"
|
||||
LPM: "R"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
GL: "I"
|
||||
|
||||
- aktivitaet: "Board-Freigabe einholen"
|
||||
LPM: "R"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
GL: "A"
|
||||
|
||||
- aktivitaet: "Umsetzung steuern"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
GL: "I"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.4 Krisen-Leistungen
|
||||
# ---------------------------------------------------------------------------
|
||||
krisen_leistungen:
|
||||
name: "Krisen-Leistungen (Krisensituationen)"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Notfall klassifizieren"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
GL: "I"
|
||||
|
||||
- aktivitaet: "Ressourcen mobilisieren"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
GL: "I"
|
||||
|
||||
- aktivitaet: "Krisenunterstützung"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
FBL: "C"
|
||||
|
||||
- aktivitaet: "Lessons Learned"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
GL: "I"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 2.5 Key-User-Management
|
||||
# ---------------------------------------------------------------------------
|
||||
key_user_management:
|
||||
name: "Key-User-Management"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "KU identifizieren"
|
||||
LPM: "A"
|
||||
KNM: "R"
|
||||
PB: "C"
|
||||
FBL: "C"
|
||||
|
||||
- aktivitaet: "KU qualifizieren"
|
||||
LPM: "A"
|
||||
KNM: "R"
|
||||
PFM: "C"
|
||||
PB: "C"
|
||||
|
||||
- aktivitaet: "KU-Netzwerk betreuen"
|
||||
LPM: "A"
|
||||
KNM: "R"
|
||||
PB: "C"
|
||||
KU: "C"
|
||||
|
||||
- aktivitaet: "Best Practices teilen"
|
||||
LPM: "I"
|
||||
KNM: "R"
|
||||
PB: "C"
|
||||
KU: "R"
|
||||
|
||||
- aktivitaet: "Lokale PM-Unterstützung"
|
||||
LPM: "I"
|
||||
KNM: "C"
|
||||
PB: "C"
|
||||
KU: "R"
|
||||
|
||||
# =============================================================================
|
||||
# 3. QUALITÄTSSICHERUNG
|
||||
# =============================================================================
|
||||
|
||||
bereich_3_qualitaetssicherung:
|
||||
name: "Qualitätssicherung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 Process Owner Quality Gate
|
||||
# ---------------------------------------------------------------------------
|
||||
process_owner_quality_gate:
|
||||
name: "Process Owner Quality Gate"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Fachliche Konsistenz prüfen"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "R"
|
||||
PL: "C"
|
||||
|
||||
- aktivitaet: "Schnittstellen validieren"
|
||||
LPM: "I"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
PO: "A"
|
||||
PL: "C"
|
||||
|
||||
- aktivitaet: "Implementierbarkeit bewerten"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "R"
|
||||
PL: "C"
|
||||
|
||||
- aktivitaet: "Gate-Entscheidung"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PO: "A"
|
||||
PL: "I"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 PM Quality Gate
|
||||
# ---------------------------------------------------------------------------
|
||||
pm_quality_gate:
|
||||
name: "PM Quality Gate"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Methodische Konformität"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "I"
|
||||
|
||||
- aktivitaet: "Prozesslandschafts-Fit"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
|
||||
- aktivitaet: "Dokumentationsqualität"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "C (fachlich)"
|
||||
KU: "C (fachlich)"
|
||||
hinweis: "C (fachlich) = für Fachprozesse"
|
||||
|
||||
# =============================================================================
|
||||
# 4. GOVERNANCE-INTEGRATION
|
||||
# =============================================================================
|
||||
|
||||
bereich_4_governance_integration:
|
||||
name: "Governance-Integration"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.1 Strategische Ausrichtung
|
||||
# ---------------------------------------------------------------------------
|
||||
strategische_ausrichtung:
|
||||
name: "Strategische Ausrichtung"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Jahresplanung PM"
|
||||
LPM: "R"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
GL: "A"
|
||||
KNM: "C"
|
||||
|
||||
- aktivitaet: "Strategische Reviews"
|
||||
LPM: "R"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
GL: "A"
|
||||
|
||||
- aktivitaet: "Ressourcenrahmen"
|
||||
LPM: "R"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
GL: "A"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.2 Operative Koordination
|
||||
# ---------------------------------------------------------------------------
|
||||
operative_koordination:
|
||||
name: "Operative Koordination"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Wöchentliche Teamrunde"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "R"
|
||||
PB: "R"
|
||||
KNM: "R"
|
||||
|
||||
- aktivitaet: "Monatliche Stakeholder"
|
||||
LPM: "A"
|
||||
PFM: "C"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
KNM: "C"
|
||||
|
||||
- aktivitaet: "Quartals-Review"
|
||||
LPM: "A"
|
||||
PFM: "R"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
GL: "I"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.3 Governance-Lücken-Management
|
||||
# ---------------------------------------------------------------------------
|
||||
governance_luecken_management:
|
||||
name: "Governance-Lücken-Management"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Lücke identifizieren"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
PO: "C"
|
||||
KU: "R (lokal)"
|
||||
hinweis: "R (lokal) = auf lokaler Ebene"
|
||||
|
||||
- aktivitaet: "Kurzfristige Lösung initiieren"
|
||||
LPM: "I"
|
||||
PLK: "A"
|
||||
PB: "R"
|
||||
PO: "C"
|
||||
|
||||
- aktivitaet: "Strukturierte Eskalation"
|
||||
LPM: "R"
|
||||
PLK: "R"
|
||||
GL: "A"
|
||||
|
||||
- aktivitaet: "Maßnahmen-Nachverfolgung"
|
||||
LPM: "A"
|
||||
PLK: "R"
|
||||
PB: "C"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.4 Management von End-to-End-Geschäftsprozessen
|
||||
# ---------------------------------------------------------------------------
|
||||
e2e_prozess_management:
|
||||
name: "Management von End-to-End-Geschäftsprozessen"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Prozess-Performance messen & berichten"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "A"
|
||||
|
||||
- aktivitaet: "Prozess-Schwachstellen analysieren"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "R"
|
||||
|
||||
- aktivitaet: "Prozess-Änderungsbedarf definieren & priorisieren"
|
||||
LPM: "C"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "A"
|
||||
|
||||
- aktivitaet: "Prozess-Änderungsprojekt beauftragen"
|
||||
LPM: "C"
|
||||
PO: "R"
|
||||
GL: "A"
|
||||
|
||||
- aktivitaet: "Prozess-Dokumentation aktuell halten"
|
||||
LPM: "I"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
PO: "A"
|
||||
KU: "R"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 4.5 Dezentrale Prozessarbeit
|
||||
# ---------------------------------------------------------------------------
|
||||
dezentrale_prozessarbeit:
|
||||
name: "Dezentrale Prozessarbeit"
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Fachprozesse modellieren"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
PLK: "C"
|
||||
PB: "C"
|
||||
KNM: "C"
|
||||
KU: "R"
|
||||
|
||||
- aktivitaet: "PM-Framework lokal umsetzen"
|
||||
LPM: "I"
|
||||
PFM: "C"
|
||||
KNM: "C"
|
||||
KU: "R"
|
||||
|
||||
- aktivitaet: "Lokale Optimierung initiieren"
|
||||
LPM: "I"
|
||||
PLK: "I"
|
||||
PB: "C"
|
||||
KU: "R"
|
||||
|
||||
- aktivitaet: "PM-Bedarfe identifizieren"
|
||||
LPM: "I"
|
||||
PB: "I"
|
||||
KNM: "I"
|
||||
KU: "R"
|
||||
|
||||
# =============================================================================
|
||||
# 5. KONFLIKTMANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
bereich_5_konfliktmanagement:
|
||||
name: "Konfliktmanagement (Explizite Eskalationspfade)"
|
||||
|
||||
eskalationsstufen:
|
||||
- stufe: 1
|
||||
name: "Stufe 1"
|
||||
konflikttyp: "Methodische Differenzen"
|
||||
primaer_entscheider: "LPM"
|
||||
zeitrahmen: "48h"
|
||||
|
||||
- stufe: 2
|
||||
name: "Stufe 2"
|
||||
konflikttyp: "Ressourcenkonflikte"
|
||||
primaer_entscheider: "GL (MB)"
|
||||
zeitrahmen: "1 Woche"
|
||||
|
||||
- stufe: 3
|
||||
name: "Stufe 3"
|
||||
konflikttyp: "Strategische Divergenzen"
|
||||
primaer_entscheider: "GL (VB)"
|
||||
zeitrahmen: "2-4 Wochen"
|
||||
|
||||
sonderfaelle:
|
||||
- typ: "Fachkonflikt"
|
||||
thema: "Prozess-Inhalt"
|
||||
primaer_entscheider: "PO"
|
||||
zeitrahmen: "72h"
|
||||
|
||||
- typ: "Governance-Lücke"
|
||||
thema: "Nicht lösbar binnen 4 Wochen"
|
||||
primaer_entscheider: "GL (MB)"
|
||||
zeitrahmen: "nach Eskalation"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Excel-Dokument.
|
||||
Quelle: #06 - Prozess-Management: RACI Matrix.xlsx
|
||||
|
||||
Inhalte:
|
||||
- 11 Rollen definiert (LPM, PFM, PLK, PB, KNM, PO, KU, GL, PL, QS, FBL)
|
||||
- 5 Hauptbereiche mit RACI-Zuordnungen
|
||||
- Eskalationsstufen und Sonderfälle
|
||||
autor: "DIGITOM-Projekt"
|
||||
263
#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml
Normal file
263
#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml
Normal file
|
|
@ -0,0 +1,263 @@
|
|||
# =============================================================================
|
||||
# KONZEPTRAHMEN: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "konzeptrahmen"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. DIE HERAUSFORDERUNG
|
||||
# =============================================================================
|
||||
|
||||
herausforderung:
|
||||
titel: "Zwischen Standardisierung und Befähigung"
|
||||
|
||||
beschreibung: |
|
||||
Moderne Verwaltungsorganisationen stehen vor einem fundamentalen Dilemma:
|
||||
Sie müssen gleichzeitig Stabilität gewährleisten und Agilität ermöglichen.
|
||||
Im Kontext des DIGITOM manifestiert sich diese Spannung besonders deutlich
|
||||
in der Frage, wie Prozesse gestaltet und gesteuert werden sollen.
|
||||
|
||||
problemstellung: |
|
||||
Die traditionelle Antwort - zentrale Vorgaben und strikte Kontrolle -
|
||||
greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig
|
||||
führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz.
|
||||
|
||||
ansatz: |
|
||||
Die Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem
|
||||
Spannungsfeld.
|
||||
|
||||
# =============================================================================
|
||||
# 2. DIE LÖSUNG
|
||||
# =============================================================================
|
||||
|
||||
loesung:
|
||||
titel: "Eine mehrdimensionale Organisationsarchitektur"
|
||||
|
||||
beschreibung: |
|
||||
Statt einer monolithischen Struktur wurde für das Prozess-Management
|
||||
eine vielschichtige Architektur entwickelt. Diese erlaubt es, verschiedene
|
||||
organisationale Bedürfnisse gleichzeitig zu adressieren.
|
||||
|
||||
spannungsfelder:
|
||||
- dimension_1: "Strategische Steuerung"
|
||||
dimension_2: "Operative Flexibilität"
|
||||
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Autonomie"
|
||||
|
||||
- dimension_1: "Zentrale Kompetenz"
|
||||
dimension_2: "Dezentrale Befähigung"
|
||||
|
||||
prinzip: |
|
||||
Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv
|
||||
genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige
|
||||
Verbesserung.
|
||||
|
||||
# =============================================================================
|
||||
# 3. DOKUMENTATIONSARCHITEKTUR
|
||||
# =============================================================================
|
||||
|
||||
dokumentationsarchitektur:
|
||||
titel: "Fünf Perspektiven, ein System"
|
||||
|
||||
beschreibung: |
|
||||
Die Komplexität dieser Organisationsform spiegelt sich in der bewusst
|
||||
gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das
|
||||
Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen eigenen Zweck.
|
||||
|
||||
dokumente:
|
||||
- id: "DOK-1"
|
||||
name: "Funktionsbeschreibung"
|
||||
untertitel: "Legitimation und Mandat"
|
||||
kernfrage: "Was darf und soll die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Schafft die formale Grundlage. Definiert den Verantwortungsbereich,
|
||||
grenzt Zuständigkeiten ab und legitimiert das Handeln der PM-Funktion
|
||||
innerhalb der Gesamtorganisation.
|
||||
metapher: "Die 'Verfassung' der Funktion - ihre grundlegenden Rechte und Pflichten"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
|
||||
- id: "DOK-2"
|
||||
name: "Leistungs-Canvas"
|
||||
untertitel: "Der Nutzennachweis"
|
||||
kernfrage: "Welchen konkreten Mehrwert schafft die PM-Funktion?"
|
||||
beschreibung: |
|
||||
Zeigt, was tatsächlich geleistet wird. Nimmt konsequent die Perspektive
|
||||
der Nutzer:innen ein und macht sichtbar, wie aus Aktivitäten konkreter
|
||||
Nutzen entsteht.
|
||||
format: "Canvas-Format ermöglicht ganzheitliche Betrachtung aller relevanten Elemente"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
|
||||
- id: "DOK-3"
|
||||
name: "Rollenmodell"
|
||||
untertitel: "Die Arbeitsorganisation"
|
||||
kernfrage: "Wer trägt welche Verantwortung?"
|
||||
beschreibung: |
|
||||
Elf differenzierte Rollen ermöglichen es, verschiedene Aspekte der
|
||||
PM-Arbeit klar zu verteilen. Von der strategischen Führung über
|
||||
methodische Expertise bis zur operativen Beratung.
|
||||
mehrwert: "Verhindert Interessenskonflikte und schafft Klarheit in der Zusammenarbeit"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
|
||||
- id: "DOK-4"
|
||||
name: "Governance-Modell"
|
||||
untertitel: "Die Spielregeln"
|
||||
kernfrage: "Wie werden Entscheidungen getroffen?"
|
||||
beschreibung: |
|
||||
Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Definiert
|
||||
differenzierte Entscheidungswege für verschiedene Leistungstypen.
|
||||
design: "Eskalationspfade sind klar definiert, aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
|
||||
- id: "DOK-5"
|
||||
name: "RACI-Matrix"
|
||||
untertitel: "Das Navigationsinstrument"
|
||||
kernfrage: "Wer ist wofür konkret zuständig?"
|
||||
beschreibung: |
|
||||
Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf
|
||||
einen Blick sichtbar. Dient als praktisches Nachschlagewerk im
|
||||
Arbeitsalltag.
|
||||
mehrwert: "Verhindert Zuständigkeitskonflikte durch klare Rollenzuweisungen"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# 4. SYSTEMISCHE ZUSAMMENHÄNGE
|
||||
# =============================================================================
|
||||
|
||||
systemische_zusammenhaenge:
|
||||
beschreibung: |
|
||||
Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden
|
||||
ein integriertes System. Jedes Element verstärkt und ergänzt die anderen.
|
||||
Gemeinsam schaffen sie ein robustes, aber flexibles Organisationsdesign.
|
||||
|
||||
verknuepfungen:
|
||||
- von: "Funktionsbeschreibung"
|
||||
zu: "Leistungs-Canvas"
|
||||
beziehung: "legitimiert die beschriebenen Leistungen"
|
||||
|
||||
- von: "Rollenmodell"
|
||||
zu: "Leistungserbringung"
|
||||
beziehung: "operationalisiert durch klare Verantwortlichkeiten"
|
||||
|
||||
- von: "Governance-Modell"
|
||||
zu: "Rollen"
|
||||
beziehung: "regelt, wie diese zusammenarbeiten und Entscheidungen treffen"
|
||||
|
||||
- von: "RACI-Matrix"
|
||||
zu: "Zusammenarbeit"
|
||||
beziehung: "macht transparent und nachvollziehbar"
|
||||
|
||||
# =============================================================================
|
||||
# 5. NAVIGATIONSHINWEISE
|
||||
# =============================================================================
|
||||
|
||||
navigationshinweise:
|
||||
beschreibung: |
|
||||
Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche
|
||||
Einstiegspunkte in die Dokumentation.
|
||||
|
||||
zielgruppen:
|
||||
- zielgruppe: "Führungskräfte und Entscheidungsträger:innen"
|
||||
einstieg: "Governance-Modell"
|
||||
zweck: "Entscheidungswege und Steuerungsmechanismen verstehen"
|
||||
dann: "Leistungs-Canvas für den strategischen Nutzen"
|
||||
|
||||
- zielgruppe: "Operative Teams und Fachbereiche"
|
||||
einstieg: "Leistungs-Canvas"
|
||||
zweck: "Verfügbare Services und Zugangswege erkunden"
|
||||
dann: "RACI-Matrix zeigt konkrete Ansprechpersonen"
|
||||
|
||||
- zielgruppe: "Neue Mitarbeitende der PM-Funktion"
|
||||
einstieg: "Funktionsbeschreibung"
|
||||
zweck: "Grundlegendes Verständnis aufbauen"
|
||||
dann: "Rollenmodell für die eigene Verortung im Team"
|
||||
|
||||
- zielgruppe: "Projektleitungen"
|
||||
einstieg: "Governance-Modell (Abschnitt projektzentrierte Prozessgestaltung)"
|
||||
zweck: "PM-Integration in Projekten verstehen"
|
||||
dann: "RACI-Matrix für konkrete Abstimmungswege"
|
||||
|
||||
# =============================================================================
|
||||
# 6. DIE ZENTRALE BALANCE
|
||||
# =============================================================================
|
||||
|
||||
zentrale_balance:
|
||||
titel: "Standardisierung ermöglichen, Autonomie bewahren"
|
||||
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung.
|
||||
Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen
|
||||
fachliche Vielfalt möglich bleibt.
|
||||
|
||||
dimensionen:
|
||||
- dimension_1: "Methodische Standards"
|
||||
dimension_2: "Fachliche Freiheit"
|
||||
|
||||
- dimension_1: "Zentrale Governance"
|
||||
dimension_2: "Dezentrale Ausführung"
|
||||
|
||||
- dimension_1: "Verbindliche Frameworks"
|
||||
dimension_2: "Situative Anpassung"
|
||||
|
||||
leitsatz: |
|
||||
Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen,
|
||||
ohne die notwendige Flexibilität zu ersticken.
|
||||
|
||||
# =============================================================================
|
||||
# 7. AUSBLICK
|
||||
# =============================================================================
|
||||
|
||||
ausblick:
|
||||
titel: "Ein lernendes System"
|
||||
|
||||
beschreibung: |
|
||||
Die hier dokumentierte Organisationsform ist kein statisches Konstrukt.
|
||||
Sie ist darauf angelegt, sich weiterzuentwickeln - durch Feedback aus
|
||||
der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse.
|
||||
|
||||
anpassungsfaehigkeit: |
|
||||
Die mehrdimensionale Dokumentation ermöglicht gezielte Anpassungen:
|
||||
Einzelne Elemente können weiterentwickelt werden, ohne das Gesamtsystem
|
||||
zu destabilisieren.
|
||||
|
||||
vision: |
|
||||
So entsteht eine Organisation, die gleichzeitig stabil und adaptiv ist -
|
||||
genau das, was moderne Verwaltung braucht.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #01 - Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur.docx
|
||||
|
||||
Inhalte:
|
||||
- Herausforderung: Standardisierung vs. Befähigung
|
||||
- Lösung: Mehrdimensionale Organisationsarchitektur
|
||||
- Dokumentationsarchitektur (5 Dokumente)
|
||||
- Systemische Zusammenhänge
|
||||
- Navigationshinweise nach Zielgruppen
|
||||
- Zentrale Balance
|
||||
- Ausblick: Lernendes System
|
||||
autor: "DIGITOM-Projekt"
|
||||
481
#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml
Normal file
481
#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml
Normal file
|
|
@ -0,0 +1,481 @@
|
|||
# =============================================================================
|
||||
# LEISTUNGS-CANVAS: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "leistungs-canvas"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#03.1 - Prozess-Management: Leistungs-Canvas.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. EINFÜHRUNG
|
||||
# =============================================================================
|
||||
|
||||
einfuehrung:
|
||||
warum_ein_leistungs_canvas: |
|
||||
Das Leistungs-Canvas betrachtet die Prozess-Management-Funktion konsequent
|
||||
aus der Perspektive ihrer Nutzer:innen. Diese Perspektivverschiebung macht
|
||||
sichtbar, was in traditionellen Funktionsbeschreibungen oft untergeht:
|
||||
Wie entsteht konkret Nutzen? Welche Beziehungen ermöglichen wirksame
|
||||
Zusammenarbeit? Über welche Wege werden Leistungen tatsächlich zugänglich?
|
||||
|
||||
leitfragen:
|
||||
- "Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?"
|
||||
- "Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?"
|
||||
- "Welche Voraussetzungen müssen dafür geschaffen werden?"
|
||||
|
||||
funktionen_des_canvas:
|
||||
- "Schafft Klarheit über das Leistungsportfolio"
|
||||
- "Macht Zusammenhänge zwischen verschiedenen Elementen sichtbar"
|
||||
- "Dient als Kommunikationsinstrument zwischen PM-Funktion und Nutzer:innen"
|
||||
- "Steuerungsinstrument für Ressourcen-Investitionen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. CANVAS-LOGIK
|
||||
# =============================================================================
|
||||
|
||||
canvas_logik:
|
||||
beschreibung: |
|
||||
Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander
|
||||
verbundene Bausteine. Die rechte Seite fokussiert auf die Außenperspektive,
|
||||
die linke Seite richtet den Blick nach innen. Im Zentrum steht das
|
||||
Wertversprechen als verbindendes Element.
|
||||
|
||||
bausteine:
|
||||
rechte_seite_aussen:
|
||||
- "Nutzendensegmente"
|
||||
- "Nutzendenbeziehung"
|
||||
- "Kanäle"
|
||||
zentrum:
|
||||
- "Wertversprechen"
|
||||
linke_seite_innen:
|
||||
- "Schlüsselaktivitäten"
|
||||
- "Schlüsselressourcen"
|
||||
- "Schlüsselpartner"
|
||||
|
||||
# =============================================================================
|
||||
# 3. CLUSTER A: FÜR WEN DIE PM-FUNKTION DA IST
|
||||
# =============================================================================
|
||||
|
||||
cluster_a_fuer_wen:
|
||||
name: "Für wen die PM-Funktion da ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.1 Nutzendensegmente
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendensegmente:
|
||||
beschreibung: |
|
||||
Die verschiedenen internen Zielgruppen, für die die PM-Funktion Leistungen
|
||||
erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen und Arbeitsweisen.
|
||||
|
||||
segmente:
|
||||
- segment: "Management-Gremien"
|
||||
beispiele: "Vision Board, Mission Board"
|
||||
bedarfe:
|
||||
- "Transparenz über die Prozesslandschaft"
|
||||
- "Governance-Berichte"
|
||||
- "Einheitliche Standards zur besseren Steuerung"
|
||||
- "Strategische Ausrichtung der Organisation"
|
||||
|
||||
- segment: "Abteilungsleitungen"
|
||||
bedarfe:
|
||||
- "Prozessperspektive für bessere Ressourcenplanung"
|
||||
- "Steuerung ihrer Bereiche"
|
||||
- "Fundierte Entscheidungen bei bereichsübergreifenden Themen"
|
||||
|
||||
- segment: "Process Owner der Teilprozesse"
|
||||
beispiele: "SHM, DPM, PPM, SPM"
|
||||
bedarfe:
|
||||
- "End-to-End-Verantwortung für ihre jeweiligen Teilprozesse"
|
||||
- "Methodische Unterstützung zur Prozessoptimierung"
|
||||
- "Unterstützung bei Prozesssteuerung"
|
||||
|
||||
- segment: "Fachbereiche und Teams mit Key-Usern"
|
||||
bedarfe:
|
||||
- "Methodische Unterstützung"
|
||||
- "Befähigung und Standards"
|
||||
- "Eigenständige Dokumentation und Verbesserung fachspezifischer Prozesse"
|
||||
|
||||
- segment: "Projekt- und Programmorganisationen"
|
||||
bedarfe:
|
||||
- "Einheitliche Prozessvorgaben"
|
||||
- "Methodische Beratung"
|
||||
- "Sicherstellung der Framework-Compliance in Projekten"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.2 Nutzendenbeziehung
|
||||
# ---------------------------------------------------------------------------
|
||||
nutzendenbeziehung:
|
||||
beschreibung: |
|
||||
Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren
|
||||
Nutzer:innen. Sie definiert das "Wie" der Interaktion.
|
||||
|
||||
beziehungstypen:
|
||||
- typ: "Partnerschaftliche Zusammenarbeit & Co-Kreation"
|
||||
beschreibung: |
|
||||
Aufbau von Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen.
|
||||
Key-User als zentrale Partner:innen eng in Entwicklung und Umsetzung
|
||||
von Prozesslösungen eingebunden.
|
||||
|
||||
- typ: "Persönliche Beratung & Dedizierte Unterstützung"
|
||||
beschreibung: |
|
||||
Direkte Beratung und Coaching, insbesondere bei komplexen
|
||||
Prozessherausforderungen oder strategischen Initiativen.
|
||||
Besonderer Fokus auf Befähigung der Key-User als Multiplikator:innen.
|
||||
|
||||
- typ: "Befähigungsorientierte Begleitung"
|
||||
beschreibung: |
|
||||
Konsequente Fokussierung auf Befähigung statt Ausführung.
|
||||
Ermächtigung der Nutzenden, ihre Prozesse eigenständig zu managen.
|
||||
Key-User als erste Ansprechpartner:innen in ihren Bereichen.
|
||||
|
||||
- typ: "Community Building & Facilitation"
|
||||
beschreibung: |
|
||||
Aktive Förderung und Pflege des Key-User-Netzwerks als zentrales
|
||||
Element für gemeinsames Lernen, Erfahrungsaustausch und kontinuierliche
|
||||
Verbesserung über Abteilungsgrenzen hinweg.
|
||||
|
||||
- typ: "Proaktive Impulsgebung"
|
||||
beschreibung: |
|
||||
Agieren als Impulsgeber durch Vorstellung neuer Methoden, Best Practices
|
||||
und Anregung des Prozessdenkens. Key-User als Multiplikator:innen
|
||||
tragen diese Impulse in ihre Fachbereiche.
|
||||
|
||||
- typ: "Governance-basierte Interaktion"
|
||||
beschreibung: |
|
||||
Formelles Reporting, strategische Abstimmung und Eskalationsmanagement
|
||||
mit Vision/Mission Boards. Regelmäßige Berichte über Entwicklung der
|
||||
dezentralen Prozesskompetenzen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 3.3 Kanäle
|
||||
# ---------------------------------------------------------------------------
|
||||
kanaele:
|
||||
beschreibung: |
|
||||
Die Wege und Formate, über die PM-Leistungen zugänglich werden.
|
||||
Die Vielfalt der Kanäle sichert niedrigschwelligen Zugang und ermöglicht
|
||||
situationsgerechte Unterstützung.
|
||||
|
||||
kategorien:
|
||||
direkte_interaktion:
|
||||
name: "Direkte Interaktions- & Befähigungskanäle"
|
||||
kanaele:
|
||||
- name: "Workshops und Schulungen"
|
||||
beschreibung: "Vermittlung von Wissen, Methoden und Werkzeugkompetenzen"
|
||||
- name: "Beratungsgespräche und Coaching"
|
||||
beschreibung: "Maßgeschneiderte Unterstützung (individuell oder Team)"
|
||||
- name: "Moderation von Prozess-Workshops"
|
||||
beschreibung: "Kollaborative Prozessarbeit bei komplexen/bereichsübergreifenden Prozessen"
|
||||
- name: "Ticketsystem"
|
||||
beschreibung: "Formaler Kanal für Anfragen mit automatischem Routing ans PM-Team"
|
||||
|
||||
self_service:
|
||||
name: "Self-Service & digitale Lernkanäle"
|
||||
kanaele:
|
||||
- name: "Zentrale Wissensplattform (Confluence)"
|
||||
beschreibung: "PM-Framework, Methodenhandbuch, Templates, Prozessregister, FAQs"
|
||||
- name: "KI-gestützter PM-Assistent"
|
||||
beschreibung: "Interaktiver Dialog für Prozessfragen und kontextspezifische Antworten"
|
||||
- name: "Prozessvisualisierungs-Tool (Picture Prozess Plattform)"
|
||||
beschreibung: "Eigenständige Arbeit mit der Prozesslandschaft"
|
||||
- name: "E-Learning-Module"
|
||||
beschreibung: "Strukturierte Lernpfade für selbstgesteuertes Lernen"
|
||||
|
||||
community:
|
||||
name: "Community- & Kommunikationskanäle"
|
||||
kanaele:
|
||||
- name: "Key-User-Netzwerktreffen und Communities of Practice"
|
||||
beschreibung: "Regelmäßiger Erfahrungsaustausch und kollektives Lernen"
|
||||
- name: "Informationsveranstaltungen und Newsletter"
|
||||
beschreibung: "Framework-Updates und relevante PM-Informationen"
|
||||
- name: "DigiLog Podcast-Format"
|
||||
beschreibung: "Einsichten und Erfolgsgeschichten zur Förderung des Prozessdenkens"
|
||||
|
||||
# =============================================================================
|
||||
# 4. CLUSTER B: WAS DIE PM-FUNKTION BIETET
|
||||
# =============================================================================
|
||||
|
||||
cluster_b_was:
|
||||
name: "Was die PM-Funktion bietet"
|
||||
|
||||
wertversprechen:
|
||||
beschreibung: |
|
||||
Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen
|
||||
Zielgruppen schafft. Es ist das zentrale Element, das alle anderen
|
||||
Bausteine ausrichtet.
|
||||
|
||||
fuer_strategische_gremien:
|
||||
- nutzen: "Strategische Prozess-Governance und Transparenz"
|
||||
beschreibung: "Konsistente, strategisch ausgerichtete Prozesslandschaft"
|
||||
- nutzen: "Messbare Verbesserung und KPI-basierte Steuerung"
|
||||
beschreibung: "Faktenbasierte Bewertung von Prozessleistung und Nachweis von Optimierungserfolgen"
|
||||
- nutzen: "Entscheidungsunterstützung und Risikominimierung"
|
||||
beschreibung: "Konzepte zur Weiterentwicklung des Operating Models und proaktive Meldung von Risiken"
|
||||
- nutzen: "Skalierbare Prozessstrukturen"
|
||||
beschreibung: "Ermöglichung von Organisationswachstum und systematische Erschließung von Automatisierungspotenzialen"
|
||||
|
||||
fuer_fachbereiche_und_teams:
|
||||
- nutzen: "Einheitliches Prozessmanagement-Framework"
|
||||
beschreibung: "Verbindliche Standards, Methoden, Werkzeuge und Templates"
|
||||
- nutzen: "Methodische Beratung und Unterstützung"
|
||||
beschreibung: "Von der Erstaufnahme bis zur Automatisierung"
|
||||
- nutzen: "Systematische Befähigung zur Selbsthilfe"
|
||||
beschreibung: "Schulungen, Coaching, Self-Service-Ressourcen und Key-User-Netzwerk"
|
||||
- nutzen: "Klarheit und Orientierung"
|
||||
beschreibung: "Gemeinsame Prozess-Sprache über alle Hierarchieebenen"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
- nutzen: "Grundlage für Effektivität und kontinuierliche Verbesserung"
|
||||
beschreibung: "Methodische Rahmenbedingungen für anpassungsfähige Arbeitsabläufe"
|
||||
- nutzen: "Automatisierung und Digitalisierung"
|
||||
beschreibung: "Systematische Identifikation von Automatisierungspotenzialen"
|
||||
- nutzen: "Siloüberwindung und Integration"
|
||||
beschreibung: "Transparente End-to-End-Prozesse und einheitliche Standards"
|
||||
|
||||
# =============================================================================
|
||||
# 5. CLUSTER C: WIE DIE PM-FUNKTION ES ERMÖGLICHT
|
||||
# =============================================================================
|
||||
|
||||
cluster_c_wie:
|
||||
name: "Wie die PM-Funktion es ermöglicht"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.1 Schlüsselaktivitäten
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselaktivitaeten:
|
||||
beschreibung: |
|
||||
Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen
|
||||
einlöst. Sie transformieren Ressourcen in konkreten Nutzen.
|
||||
|
||||
aktivitaeten:
|
||||
- aktivitaet: "Framework-Entwicklung & -Pflege"
|
||||
beschreibung: |
|
||||
Kontinuierliche Definition und Weiterentwicklung des verbindlichen
|
||||
PM-Frameworks inklusive Methoden, Standards, Templates und Governance-Regeln.
|
||||
umfasst:
|
||||
- "Laufende Analyse interner Bedarfe und externer Best Practices"
|
||||
- "Entwicklung standardisierter Templates"
|
||||
|
||||
- aktivitaet: "Management der Prozesslandschaft & Governance"
|
||||
beschreibung: |
|
||||
Aufbau, Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse.
|
||||
umfasst:
|
||||
- "Sicherstellung der Framework-Compliance"
|
||||
- "Aufdecken von Governance-Lücken"
|
||||
- "Bereitstellung des Prozessregisters"
|
||||
|
||||
- aktivitaet: "Tool-Bereitstellung & -Management"
|
||||
beschreibung: |
|
||||
Auswahl, Implementierung und kontinuierliche Wartung zentraler PM-Tools.
|
||||
umfasst:
|
||||
- "Technische Verfügbarkeit, Updates und Support"
|
||||
- "Integration neuer Möglichkeiten wie KI-gestützte Prozessanalyse"
|
||||
|
||||
- aktivitaet: "Beratung & Methodische Unterstützung"
|
||||
beschreibung: |
|
||||
Durchführung von Beratungen, Coachings und Moderation von Workshops
|
||||
zur Prozessanalyse und -optimierung.
|
||||
umfasst:
|
||||
- "Schwerpunkt auf Befähigung der Fachbereiche zur eigenständigen Prozessarbeit"
|
||||
|
||||
- aktivitaet: "Befähigung & Kompetenzaufbau"
|
||||
beschreibung: |
|
||||
Entwicklung und Umsetzung des Befähigungskonzepts.
|
||||
umfasst:
|
||||
- "Qualifizierung und Betreuung des Key-User-Netzwerks"
|
||||
- "Durchführung von Schulungen"
|
||||
|
||||
- aktivitaet: "Kommunikation & Stakeholder-Engagement"
|
||||
beschreibung: |
|
||||
Aktive Kommunikation von Framework-Updates und Prozessänderungen.
|
||||
umfasst:
|
||||
- "Reporting an Gremien"
|
||||
- "Proaktive Information bei identifizierten Governance-Lücken"
|
||||
|
||||
- aktivitaet: "Prozessinnovation & -weiterentwicklung"
|
||||
beschreibung: |
|
||||
Identifikation von Optimierungspotenzialen und Automatisierungsmöglichkeiten.
|
||||
umfasst:
|
||||
- "Zusammenarbeit mit dem KI-Hub für innovative Lösungsansätze"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.2 Schlüsselressourcen
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselressourcen:
|
||||
beschreibung: |
|
||||
Das notwendige Fundament für wirksame PM-Arbeit. Diese Ressourcen ermöglichen
|
||||
erst die Durchführung der Schlüsselaktivitäten.
|
||||
|
||||
kategorien:
|
||||
menschliche_ressourcen:
|
||||
name: "Menschliche Ressourcen"
|
||||
elemente:
|
||||
- "Fachliche und methodische Expertise in PM-Methoden, -Standards und -Governance"
|
||||
- "Beratungs- und Moderationskompetenz"
|
||||
- "Ausreichende personelle Kapazität"
|
||||
|
||||
intellektuelle_ressourcen:
|
||||
name: "Intellektuelle Ressourcen"
|
||||
elemente:
|
||||
- "Dokumentiertes PM-Framework mit Standards und Methoden"
|
||||
- "Prozesslandkarte mit Prozessregister"
|
||||
- "Strukturierte Schulungskonzepte"
|
||||
- "Umfassende Template-Bibliothek"
|
||||
|
||||
technische_ressourcen:
|
||||
name: "Physische/Technische Ressourcen"
|
||||
elemente:
|
||||
- "Zentrale PM-Werkzeuge für Prozessmodellierung und -dokumentation"
|
||||
- "KI-gestützte Assistenzsysteme zur Prozessanalyse"
|
||||
- "Digitale Kollaborationsplattformen"
|
||||
|
||||
beziehungsnetzwerk:
|
||||
name: "Beziehungsnetzwerk & Zugänge"
|
||||
elemente:
|
||||
- "Etablierte Governance-Zugänge zu relevanten Entscheidungsgremien"
|
||||
- "Key-User-Netzwerk als Community dezentraler Prozessansprechpartner"
|
||||
- "Organisationsweites Beziehungsnetzwerk von Mitarbeitenden bis zur Führung"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# 5.3 Schlüsselpartner
|
||||
# ---------------------------------------------------------------------------
|
||||
schluesselpartner:
|
||||
beschreibung: |
|
||||
Die internen Kooperationspartner, mit denen die PM-Funktion zusammenarbeitet,
|
||||
um ihr volles Potenzial zu entfalten. Erfolgreiche PM-Arbeit ist immer
|
||||
Teamarbeit über Funktionsgrenzen hinweg.
|
||||
|
||||
partner:
|
||||
- partner: "IT-Architektur"
|
||||
beitrag: "Definiert technische Rahmenbedingungen und Standards, die Framework und Werkzeugauswahl beeinflussen"
|
||||
|
||||
- partner: "Informationssicherheitsbeauftragter"
|
||||
beitrag: "Stellt IT-Sicherheit und technische Compliance von Prozessen sicher"
|
||||
|
||||
- partner: "Datenschutzbeauftragte"
|
||||
beitrag: "Gewährleistet datenschutzkonforme Prozessgestaltung"
|
||||
|
||||
- partner: "Business Continuity Management"
|
||||
beitrag: "Kategorisiert kritische Prozesse und integriert Notfallpläne"
|
||||
|
||||
- partner: "Data Excellence Governance"
|
||||
beitrag: "Stimmt datengetriebene Prozesse ab"
|
||||
|
||||
- partner: "KI-Hub"
|
||||
beitrag: "Strategischer Partner für KI-basierte Prozessinnovationen"
|
||||
|
||||
- partner: "Vision Board"
|
||||
beitrag: "Strategischer Auftraggeber für die PM-Ausrichtung"
|
||||
|
||||
- partner: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beitrag: "Verantworten ihre jeweiligen Teilprozesse"
|
||||
|
||||
- partner: "Qualitätsmanagement"
|
||||
beitrag: "Partner zur Abstimmung von QM-Anforderungen und PM-Standards"
|
||||
status: "noch zu klären"
|
||||
|
||||
- partner: "Zentrale GPM (Geschäftsprozess Management)"
|
||||
beitrag: |
|
||||
Ämterübergreifender Prozess-Framework-Verantwortlicher für einheitliche
|
||||
GPM-Standards und -Methoden. Verfügt über vollständige Prozesslandkarte
|
||||
aller Ämter.
|
||||
|
||||
# =============================================================================
|
||||
# 6. ZUSAMMENHÄNGE UND LESEHILFEN
|
||||
# =============================================================================
|
||||
|
||||
zusammenhaenge:
|
||||
gesamtbild: |
|
||||
Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der
|
||||
PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen
|
||||
Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese
|
||||
Bedarfe in konkrete Leistungszusagen.
|
||||
|
||||
wechselwirkungen:
|
||||
- element: "Key-User-Netzwerk"
|
||||
mehrfachrolle:
|
||||
- "Kanal (für dezentrale Unterstützung)"
|
||||
- "Beziehungselement (Community Building)"
|
||||
- "Ressource (Multiplikator:innen)"
|
||||
|
||||
- element: "Framework-Entwicklung"
|
||||
wechselwirkung: "Schlüsselaktivität, deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten ermöglicht"
|
||||
|
||||
lesehilfen_nach_zielgruppe:
|
||||
gremien:
|
||||
fokus:
|
||||
- "Strategisches Wertversprechen"
|
||||
- "Governance-basierte Beziehungen"
|
||||
- "Formelle Berichtskanäle"
|
||||
relevante_aktivitaeten:
|
||||
- "Framework-Entwicklung"
|
||||
- "Prozesslandschafts-Management"
|
||||
|
||||
fachbereiche_und_teams:
|
||||
fokus:
|
||||
- "Operatives Wertversprechen"
|
||||
- "Befähigungsorientierte Beziehungen"
|
||||
- "Vielfältige Zugangskanäle (Beratung bis Self-Service)"
|
||||
relevante_aktivitaeten:
|
||||
- "Beratung"
|
||||
- "Befähigung"
|
||||
- "Tool-Bereitstellung"
|
||||
|
||||
key_user:
|
||||
mehrfachverortung:
|
||||
- "Teil der Nutzendensegmente"
|
||||
- "Element der Community-Beziehungen"
|
||||
- "Wichtiger Kanal"
|
||||
- "Schlüsselressource"
|
||||
bedeutung: "Zentrale Rolle im Gesamtkonzept"
|
||||
|
||||
# =============================================================================
|
||||
# 7. VERBINDUNG ZU ANDEREN KONZEPTBAUSTEINEN
|
||||
# =============================================================================
|
||||
|
||||
verbindung_zu_anderen_dokumenten:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
verbindung: "Definiert die formalen Verantwortlichkeiten, die den Leistungen zugrunde liegen"
|
||||
|
||||
- dokument: "Governance-Modell"
|
||||
verbindung: "Konkretisiert die Entscheidungswege und Beauftragungslogiken"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
verbindung: "Spezifiziert, wer innerhalb der PM-Funktion für welche Canvas-Elemente verantwortlich ist"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
verbindung: "Operationalisiert die Zusammenarbeit mit den Schlüsselpartnern"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #03.1 - Prozess-Management: Leistungs-Canvas.docx
|
||||
|
||||
Inhalte:
|
||||
- Canvas-Logik (7 Bausteine)
|
||||
- Cluster A: Nutzendensegmente, Nutzendenbeziehung, Kanäle
|
||||
- Cluster B: Wertversprechen (nach Zielgruppen)
|
||||
- Cluster C: Schlüsselaktivitäten, -ressourcen, -partner
|
||||
- Zusammenhänge und Lesehilfen
|
||||
- Verbindungen zu anderen Dokumenten
|
||||
autor: "DIGITOM-Projekt"
|
||||
337
#05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml
Normal file
337
#05_prozessmanagement/#05.3_konzepte/pm_pilot-konzept.yaml
Normal file
|
|
@ -0,0 +1,337 @@
|
|||
# =============================================================================
|
||||
# PILOTKONZEPT: WORKING STREAM "PROZESSMANAGEMENT"
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "pilotkonzept"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#07 - Pilot-Konzept.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. KONTEXT & KONZEPTBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
kontext:
|
||||
pilotgegenstand: |
|
||||
Einführung und Erprobung der neuen Prozess-Management-Funktionsbereich
|
||||
nach DIGITOM-Modell
|
||||
|
||||
voraussetzungen:
|
||||
titel: "Was benötigen wir zur Zielerreichung?"
|
||||
anforderungen:
|
||||
- id: "VA-1"
|
||||
beschreibung: "Prozess-Management-Tool & Methodik (Auswahl und Setup)"
|
||||
|
||||
- id: "VA-2"
|
||||
beschreibung: "Key-User aus verschiedenen Fachbereichen, je nach Prozessauswahl"
|
||||
|
||||
- id: "VA-3"
|
||||
beschreibung: "Zugang zu bestehender Prozessdokumentation"
|
||||
|
||||
- id: "VA-4"
|
||||
beschreibung: "Workshops-Räume und Moderationsausstattung"
|
||||
|
||||
- id: "VA-5"
|
||||
beschreibung: |
|
||||
Zugriff auf Prozess-Funktions-Mitglieder (Kapazität muss vorhanden sein,
|
||||
Coaching für Framework-Schulungen durchführen zu können)
|
||||
|
||||
- id: "VA-6"
|
||||
beschreibung: |
|
||||
Schulung und Coaching für PM-Team (Coaching für ein Train-the-Trainer-Konzept)
|
||||
und Key-User (Qualifizierungsmaßnahmen intern/extern).
|
||||
Bei Bedarf Einbindung externer Trainer.
|
||||
|
||||
- id: "VA-7"
|
||||
beschreibung: |
|
||||
Auswahl mindestens eines passenden Prozesses zum Prüfen der Wirksamkeit
|
||||
und Arbeitsweise des PM-Teams im Rahmen der Funktion
|
||||
|
||||
hypothesen:
|
||||
titel: "Was wollen wir mit dem Pilot beweisen/widerlegen?"
|
||||
items:
|
||||
- id: "HYP-1"
|
||||
hypothese: |
|
||||
Der definierte PM-Funktionsbereich ist in der Praxis funktionsfähig
|
||||
und wird von den Fachbereichen akzeptiert
|
||||
|
||||
- id: "HYP-2"
|
||||
hypothese: |
|
||||
Key-User können nach entsprechender Befähigung eigenständig Prozesse
|
||||
dokumentieren und optimieren
|
||||
|
||||
- id: "HYP-3"
|
||||
hypothese: |
|
||||
Die Prozessberater sind fähig, die Key-User bei ihrer Aufgabe zu
|
||||
befähigen und zu unterstützen
|
||||
|
||||
- id: "HYP-4"
|
||||
hypothese: |
|
||||
Die Aufnahme eines Prozesses bis in das Prozesstool Picture schafft
|
||||
einen Mehrwert bei der täglichen Arbeit
|
||||
|
||||
- id: "HYP-5"
|
||||
hypothese: "Das Governance-Modell funktioniert effektiv"
|
||||
|
||||
risiken:
|
||||
titel: "Welche potenziellen Risiken sehen wir im Zuge des Piloten?"
|
||||
items:
|
||||
- id: "RISK-1"
|
||||
risiko: |
|
||||
Keine verfügbaren Ressourcen in der Pilotphase, die konkret
|
||||
(verfügbare Zeit) mit der Abteilungsleitung abgestimmt wurden
|
||||
|
||||
- id: "RISK-2"
|
||||
risiko: |
|
||||
Fachbereich kooperiert nicht mit dem Key-User oder Prozessberater
|
||||
(Zeit-Konflikt oder Akzeptanz)
|
||||
|
||||
- id: "RISK-3"
|
||||
risiko: |
|
||||
Keine externe Unterstützung in der anvisierten Zeit
|
||||
(Dienstleister, HPA...)
|
||||
|
||||
- id: "RISK-4"
|
||||
risiko: "Zu starke Anpassungen am Pilotkonzept im Pilotzeitraum"
|
||||
|
||||
# =============================================================================
|
||||
# 2. ROLLENVERGABE
|
||||
# =============================================================================
|
||||
|
||||
rollenvergabe:
|
||||
pilot_sponsor:
|
||||
rolle: "Pilot-Sponsor"
|
||||
person: "Lisa Schroth"
|
||||
|
||||
coaches:
|
||||
rolle: "Coaches"
|
||||
personen:
|
||||
- "Patrick Breitenbach"
|
||||
- "Human Nagafi"
|
||||
|
||||
pilot_lead_operativ:
|
||||
rolle: "Pilot-Lead operativ"
|
||||
person: "Martin Mayer"
|
||||
|
||||
pilot_lead_konsultativ:
|
||||
rolle: "Pilot-Lead konsultativ"
|
||||
person: "Patrick Breitenbach"
|
||||
|
||||
pilot_team:
|
||||
titel: "Pilot-Team"
|
||||
mitglieder:
|
||||
- rolle: "PFM (Prozess-Framework-Manager)"
|
||||
person: "Martin Mayer"
|
||||
|
||||
- rolle: "PB (Prozess-Berater)"
|
||||
personen:
|
||||
- "Gordian Gossen"
|
||||
- "Jannik Eisenmann"
|
||||
- "David Trenkle"
|
||||
|
||||
- rolle: "PLK (Prozesslandschafts-Koordinator)"
|
||||
personen:
|
||||
- "David Trenkle"
|
||||
- "Gordian Gossen"
|
||||
|
||||
hinweis: "Key-User und Process Owner werden im Pilotplan bestimmt"
|
||||
|
||||
# =============================================================================
|
||||
# 3. ARBEITSPAKETE
|
||||
# =============================================================================
|
||||
|
||||
arbeitspakete:
|
||||
- id: "AP-1"
|
||||
name: "Kick-off"
|
||||
aktivitaeten:
|
||||
- "Kick-off mit dem Funktions-Team"
|
||||
output: "Pilotvorstellungs-Präsentation"
|
||||
|
||||
- id: "AP-2"
|
||||
name: "Planungsphase"
|
||||
aktivitaeten:
|
||||
- "Projektmanagement: Projektplan, Risikobewertung, Stakeholder, Ressourceplanung etc."
|
||||
- "Kommunikationsmaßnahmen"
|
||||
- "Schulungsbedarf und Durchführung der Schulungen (Prozess-Berater und Key-User)"
|
||||
- "Tool-Setup"
|
||||
- "Prozessmanagement-Leistungsangebot"
|
||||
- "Methodenübersicht (z.B. Prozess- und Methodenhandbuch)"
|
||||
- "GPM-Kreislauf für die Prozess-Management-Funktion"
|
||||
- "Onboarding Key-User"
|
||||
- "Aufbau Prozessartefakte: Prozessteckbriefe, Prozesslandkarte, Prozessregister"
|
||||
output: "Pilotplan"
|
||||
|
||||
- id: "AP-3"
|
||||
name: "Onboarding und Informationsphase"
|
||||
aktivitaeten:
|
||||
- "Pilotprozesse auswählen"
|
||||
- "Prozess-Berater onboarden"
|
||||
- "Key-User auswählen und onboarden"
|
||||
output: "Bei Bedarf aktualisierter Pilotplan"
|
||||
|
||||
- id: "AP-4"
|
||||
name: "Umsetzungsphase"
|
||||
aktivitaeten:
|
||||
- "Pilotprozess aufnehmen in definierten Bereichen"
|
||||
- "Pilotdurchführung monitoren (Quantitativ und Qualitativ)"
|
||||
- "Pilotdurchführung reviewen (Was läuft gut? / Was lernen wir unterwegs? / Wo haben wir Probleme?)"
|
||||
output: "Prozess-Artefakte, Bei Bedarf aktualisierter Pilotplan"
|
||||
|
||||
- id: "AP-5"
|
||||
name: "Retrospektive"
|
||||
aktivitaeten:
|
||||
- "Retrospektive vorbereiten und durchführen"
|
||||
- "Empfehlung weitere Vorgehen durch 1789 ausarbeiten"
|
||||
output: "Ergebnisbericht Pilotdurchführung, Empfehlungsbericht"
|
||||
|
||||
# =============================================================================
|
||||
# 4. KOMMUNIKATIONSWEGE
|
||||
# =============================================================================
|
||||
|
||||
kommunikation:
|
||||
intern:
|
||||
titel: "Interne Kommunikation"
|
||||
kanaele:
|
||||
- kanal: "Mission Board"
|
||||
zweck: "Vorstellung Pilotkonzept und Retroergebnisse"
|
||||
|
||||
- kanal: "SyncUp PzM"
|
||||
rhythmus: "1x Woche"
|
||||
format: "Teil für Pilot-Team, Teil für restliches Funktions-Team"
|
||||
|
||||
- kanal: "Key-User Runde"
|
||||
|
||||
- kanal: "Abteilungsleitungen"
|
||||
|
||||
- kanal: "DIGIT Allgemein"
|
||||
|
||||
- kanal: "Process Owner"
|
||||
|
||||
- kanal: "Weekly Check-In Pilotstatus und Review"
|
||||
rhythmus: "Wöchentlich"
|
||||
dauer: "Maximal 30 Minuten"
|
||||
verantwortlich: "1789 inkl. PzM-Team"
|
||||
|
||||
- kanal: "Ad-Hoc Coaching"
|
||||
format: "Auf Anfrage durch 1789"
|
||||
|
||||
- kanal: "Moderierte Retrospektive"
|
||||
anzahl: "1x"
|
||||
verantwortlich: "1789"
|
||||
|
||||
hinweis: "Weitere Maßnahmen gemäß Ergebnisse Kommunikationsplanung (Maßnahme)"
|
||||
|
||||
extern:
|
||||
titel: "Externe Schnittstellen"
|
||||
partner:
|
||||
- "Zentrales GPM der Stadt Freiburg"
|
||||
|
||||
# =============================================================================
|
||||
# 5. TIMELINE / RHYTHMUS
|
||||
# =============================================================================
|
||||
|
||||
timeline:
|
||||
hinweis: |
|
||||
Folgende Phasenzeitplanung wird angenommen. Anpassungen können während
|
||||
der Pilotphase erfolgen.
|
||||
|
||||
verlaengerung: |
|
||||
Bei Bedarf Verlängerung bis Anfang 2026. Die Retrospektive sowie die
|
||||
Empfehlungsdokumente von 1789 sind dann davon nicht betroffen.
|
||||
|
||||
phasen:
|
||||
- phase: "Kick-off"
|
||||
termin: "ca. 27.08.2025"
|
||||
typ: "Meilenstein"
|
||||
|
||||
- phase: "Pilotphase allgemein"
|
||||
start: "15.08.2025"
|
||||
ende: "31.12.2025"
|
||||
typ: "Rahmen"
|
||||
|
||||
- phase: "Planungsphase"
|
||||
start: "15.08.2025"
|
||||
ende: "30.09.2025"
|
||||
arbeitspaket: "AP-2"
|
||||
|
||||
- phase: "Onboarding und Informationsphase"
|
||||
start: "01.10.2025"
|
||||
ende: "15.11.2025"
|
||||
arbeitspaket: "AP-3"
|
||||
|
||||
- phase: "Umsetzungsphase"
|
||||
start: "15.10.2025"
|
||||
ende: "15.12.2025"
|
||||
arbeitspaket: "AP-4"
|
||||
|
||||
- phase: "Retrospektive"
|
||||
termin: "ca. 16.12.2025"
|
||||
typ: "Meilenstein"
|
||||
arbeitspaket: "AP-5"
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNGEN
|
||||
# =============================================================================
|
||||
|
||||
verknuepfungen:
|
||||
referenzierte_dokumente:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
relevanz: "Definiert die zu pilotierende Funktion"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
relevanz: "Beschreibt die Rollen PFM, PB, PLK, KNM, KU, PO"
|
||||
|
||||
- dokument: "Governance-Framework"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
relevanz: "Hypothese HYP-5 testet dessen Wirksamkeit"
|
||||
|
||||
- dokument: "Leistungs-Canvas"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
relevanz: "Definiert das Leistungsangebot"
|
||||
|
||||
externe_partner:
|
||||
- partner: "1789"
|
||||
rolle: "Coaching und Moderation"
|
||||
leistungen:
|
||||
- "Weekly Check-In"
|
||||
- "Ad-Hoc Coaching"
|
||||
- "Moderierte Retrospektive"
|
||||
- "Empfehlungsbericht"
|
||||
|
||||
- partner: "Zentrales GPM Stadt Freiburg (HPA)"
|
||||
rolle: "Externe Schnittstelle"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #07 - Pilot-Konzept.docx
|
||||
|
||||
Inhalte:
|
||||
- Kontext & Konzeptbeschreibung (7 Voraussetzungen, 5 Hypothesen, 4 Risiken)
|
||||
- Rollenvergabe (Sponsor, Coaches, Leads, Team)
|
||||
- 5 Arbeitspakete (Kick-off bis Retrospektive)
|
||||
- Kommunikationswege (intern und extern)
|
||||
- Timeline (15.08.2025 - 31.12.2025)
|
||||
autor: "DIGITOM-Projekt"
|
||||
162
#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml
Normal file
162
#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml
Normal file
|
|
@ -0,0 +1,162 @@
|
|||
# =============================================================================
|
||||
# ROLLENMODELL: PROZESS-MANAGEMENT (PM)
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "rollenmodell"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#04 - Prozess-Management: Rollenmodell.docx"
|
||||
|
||||
# =============================================================================
|
||||
# STRATEGISCHE ARCHITEKTUR-PRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
architektur_prinzipien:
|
||||
beschreibung: |
|
||||
Das Prozess-Management im DIGITOM operiert als Enabling-Funktion mit klarer
|
||||
Trennung zwischen methodischer Beratung und operativer PM-Governance.
|
||||
Die Rollen-Architektur folgt dem Prinzip der dezentralen Befähigung bei
|
||||
zentraler Methodenkompetenz.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Enabling-Funktion"
|
||||
beschreibung: "PM unterstützt und befähigt, kontrolliert nicht"
|
||||
|
||||
- prinzip: "Dezentrale Befähigung"
|
||||
beschreibung: "Prozess-Kompetenz wird in die Fachbereiche getragen"
|
||||
|
||||
- prinzip: "Zentrale Methodenkompetenz"
|
||||
beschreibung: "Framework und Standards werden zentral gepflegt"
|
||||
|
||||
- prinzip: "Beratung-vs.-Governance-Trennung"
|
||||
beschreibung: |
|
||||
Methodische Unterstützung und PM-Compliance-Überwachung werden auf
|
||||
unterschiedliche Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten.
|
||||
|
||||
hinweis: |
|
||||
Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare Verantwortungsschnitte
|
||||
und vermeidet Interessenskonflikte (z.B. zwischen PM-Governance-Überwachung und
|
||||
PM-Framework-Gestaltung).
|
||||
|
||||
# =============================================================================
|
||||
# BEGRIFFSDEFINITION: END-TO-END VERANTWORTUNG
|
||||
# =============================================================================
|
||||
|
||||
begriffsdefinitionen:
|
||||
end_to_end_verantwortung:
|
||||
definition: |
|
||||
Im DIGITOM-Kontext bedeutet "End-to-End Verantwortung" die vollständige
|
||||
Verantwortung für einen definierten Prozessabschnitt über alle beteiligten
|
||||
Funktionen und Abteilungen hinweg.
|
||||
|
||||
abgrenzungen:
|
||||
- "End-to-End bezieht sich auf Teilprozesse, nicht auf den Gesamtprozess"
|
||||
- "Der Process Owner trägt die Verantwortung innerhalb seiner Prozessebene"
|
||||
- "Aktive Gestaltung der Schnittstellen zu vor- und nachgelagerten Prozessen"
|
||||
|
||||
verantwortung_umfasst:
|
||||
- "Performance und Qualität des eigenen Teilprozesses"
|
||||
- "Schnittstellen-Vereinbarungen mit angrenzenden Process Ownern"
|
||||
- "Eskalation bei Problemen in verbundenen Prozessen"
|
||||
- "Kontinuierliche Optimierung inkl. schnittstellenübergreifender Verbesserungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLEN-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
rollen_uebersicht:
|
||||
|
||||
kernrollen_intern:
|
||||
beschreibung: "Interne PM-Organisation"
|
||||
rollen:
|
||||
- id: "R1"
|
||||
name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
datei: "rolle_leiter-pm.yaml"
|
||||
|
||||
- id: "R2"
|
||||
name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
datei: "rolle_prozess-framework-manager.yaml"
|
||||
|
||||
- id: "R3"
|
||||
name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
datei: "rolle_prozesslandschafts-koordinator.yaml"
|
||||
|
||||
- id: "R4"
|
||||
name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
datei: "rolle_prozess-berater.yaml"
|
||||
|
||||
- id: "R5"
|
||||
name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
datei: "rolle_key-user-netzwerk-manager.yaml"
|
||||
|
||||
schnittstellenrollen:
|
||||
beschreibung: "Rollen an der Schnittstelle zwischen PM und Organisation"
|
||||
rollen:
|
||||
- id: "R6"
|
||||
name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
datei: "rolle_process-owner.yaml"
|
||||
hinweis: "Übernommen von SHM, DPM, PPM, SPM"
|
||||
|
||||
- id: "R7"
|
||||
name: "Key-User"
|
||||
kurzform: "KU"
|
||||
datei: "rolle_key-user.yaml"
|
||||
hinweis: "Formale Rolle in den Fachbereichen"
|
||||
|
||||
- id: "R8"
|
||||
name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
datei: "rolle_auftraggeber-pm.yaml"
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
governance_support_rollen:
|
||||
beschreibung: "Governance- und Support-Rollen"
|
||||
rollen:
|
||||
- id: "R9"
|
||||
name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
datei: "rolle_it-architektur.yaml"
|
||||
hinweis: "Technische Schnittstelle"
|
||||
|
||||
- id: "R10"
|
||||
name: "ISB / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
datei: "rolle_isb-dsb.yaml"
|
||||
|
||||
- id: "R11"
|
||||
name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
datei: "rolle_gremien.yaml"
|
||||
hinweis: "Vision Board, Mission Board, DSR"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #04 - Prozess-Management: Rollenmodell.docx
|
||||
autor: "DIGITOM-Projekt"
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
# =============================================================================
|
||||
# ROLLE: AUFTRAGGEBER PROZESS-MANAGEMENT (AG-PM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R8-AG-PM"
|
||||
rolle_name: "Auftraggeber Prozess-Management"
|
||||
kurzform: "AG-PM"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Verschiedene organisatorische Ausprägungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Bedarfs-Artikulation und Beauftragung der PM-Funktion zur zielgerichteten
|
||||
Nutzung der PM-Services für spezifische organisatorische Herausforderungen.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation und Artikulation von Prozess-Management-Bedarfen"
|
||||
- "Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder Projekten"
|
||||
- "Bereitstellung notwendiger Ressourcen und Informationen für PM-Services"
|
||||
- "Definition von Erfolgserwartungen und Zielen für PM-Unterstützung"
|
||||
- "Feedback und Bewertung der erbrachten PM-Leistungen"
|
||||
- "Sicherstellung der Implementierung von PM-Empfehlungen"
|
||||
|
||||
# =============================================================================
|
||||
# AUFTRAGGEBER-KATEGORIEN
|
||||
# =============================================================================
|
||||
|
||||
auftraggeber_kategorien:
|
||||
- kategorie: "Abteilungsleitung"
|
||||
fokus: "Bereichsspezifische Prozessoptimierungen"
|
||||
|
||||
- kategorie: "Projektleitungen"
|
||||
fokus: "Projektbezogene Prozess-Unterstützung"
|
||||
|
||||
- kategorie: "Vision Board / Mission Board"
|
||||
fokus: "Strategische PM-Initiativen"
|
||||
|
||||
- kategorie: "Service-(Portfolio)-Manager"
|
||||
fokus: "Servicebezogene Prozessentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Beauftragung und Zusammenarbeit"
|
||||
- name: "Betroffene Teams und Bereiche"
|
||||
beziehung: "Implementierung"
|
||||
- name: "Übergeordnete Gremien"
|
||||
beziehung: "Bei strategischen Aufträgen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Beauftragung und Priorisierung von PM-Services im eigenen Verantwortungsbereich"
|
||||
- "Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten"
|
||||
- "Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen"
|
||||
- "Stakeholder-Management für Implementierungsmaßnahmen"
|
||||
- "Change-Management-Grundverständnis"
|
||||
- "Budget- und Ressourcen-Verantwortung"
|
||||
71
#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml
Normal file
71
#05_prozessmanagement/#05.4_rollen/rolle_gremien.yaml
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
# =============================================================================
|
||||
# ROLLE: GREMIEN (Vision Board, Mission Board, DSR)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R11-GREMIEN"
|
||||
rolle_name: "Gremien"
|
||||
kurzform: "VB/MB/DSR"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Vision Board, Mission Board, Digital Services Review"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische und taktische Steuerung der PM-Funktion sowie
|
||||
Entscheidungen zu prozessrelevanten Governance-Fragen.
|
||||
|
||||
# =============================================================================
|
||||
# GREMIEN-SPEZIFISCHE AUFGABEN
|
||||
# =============================================================================
|
||||
|
||||
gremien:
|
||||
vision_board:
|
||||
name: "Vision Board"
|
||||
ebene: "strategisch"
|
||||
aufgaben:
|
||||
- "Strategische PM-Ausrichtung und Framework-Grundsätze"
|
||||
- "Budget- und Ressourcen-Entscheidungen für PM-Funktion"
|
||||
- "Grundsatzentscheidungen bei Eskalationen"
|
||||
|
||||
mission_board:
|
||||
name: "Mission Board"
|
||||
ebene: "taktisch"
|
||||
aufgaben:
|
||||
- "Taktische PM-Priorisierung und Konfliktlösung"
|
||||
- "Prozessübergreifende Optimierungsentscheidungen"
|
||||
- "Entscheidungen bei Ressourcenkonflikten"
|
||||
- "Governance-Eskalationen"
|
||||
|
||||
dsr:
|
||||
name: "Digital Services Review (DSR)"
|
||||
ebene: "operativ"
|
||||
aufgaben:
|
||||
- "Operative Prozess-Entscheidungen im Kontext des Service-Portfolios"
|
||||
|
||||
# =============================================================================
|
||||
# BEZIEHUNG ZUR PM-FUNKTION
|
||||
# =============================================================================
|
||||
|
||||
beziehung_pm:
|
||||
vision_board:
|
||||
- "Empfängt strategische Berichte und Konzepte von PM"
|
||||
- "Erteilt strategische Aufträge an PM"
|
||||
- "Entscheidet über Framework-Transformationen"
|
||||
|
||||
mission_board:
|
||||
- "Empfängt operative Berichte von PM"
|
||||
- "Entscheidet über Projekt-Leistungen"
|
||||
- "Löst Prioritätskonflikte"
|
||||
|
||||
dsr:
|
||||
- "Abstimmung servicebezogener Prozessfragen"
|
||||
40
#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml
Normal file
40
#05_prozessmanagement/#05.4_rollen/rolle_isb-dsb.yaml
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# =============================================================================
|
||||
# ROLLE: ISB / DATENSCHUTZBEAUFTRAGTE*R
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R10-ISB-DSB"
|
||||
rolle_name: "Informationssicherheitsbeauftragte*r / Datenschutzbeauftragte*r"
|
||||
kurzform: "ISB/DSB"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der Compliance von Prozessen und PM-Tools mit
|
||||
Sicherheits- und Datenschutzvorgaben.
|
||||
|
||||
kernaufgaben:
|
||||
- "Compliance-Prüfung von Prozess-Designs und PM-Tools"
|
||||
- "Definition sicherheitsrelevanter Prozess-Anforderungen"
|
||||
- "Risiko-Assessment für prozessbezogene Datenverarbeitung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Compliance-Beratung und -Freigaben"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene Sicherheitsanforderungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Datenschutz-Compliance"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Compliance-Freigaben für Prozesse und Tools"
|
||||
- "Definition von Sicherheitsanforderungen"
|
||||
43
#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml
Normal file
43
#05_prozessmanagement/#05.4_rollen/rolle_it-architektur.yaml
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# =============================================================================
|
||||
# ROLLE: IT-ARCHITEKTUR (Technische Schnittstelle)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R9-ITA"
|
||||
rolle_name: "IT-Architektur"
|
||||
kurzform: "ITA"
|
||||
kategorie: "governance_support"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Technische Schnittstelle zur PM-Funktion"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Sicherstellung der technischen Machbarkeit und Integration von
|
||||
Prozess-Lösungen in die DIGITOM-IT-Landschaft.
|
||||
|
||||
kernaufgaben:
|
||||
- "Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen"
|
||||
- "Definition technischer Rahmenbedingungen für Prozess-Tools und -systeme"
|
||||
- "Sicherstellung der Systemkompatibilität bei prozessbezogenen IT-Lösungen"
|
||||
- "Beratung zu technischen Möglichkeiten und Grenzen bei Prozessoptimierungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Technische Beratung und Abstimmung"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Prozessbezogene IT-Anforderungen"
|
||||
- name: "IT-Betrieb"
|
||||
beziehung: "Systemintegration und -betrieb"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Technische Architektur-Vorgaben für Prozess-Tools"
|
||||
- "System-Kompatibilitäts-Bewertungen"
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
# =============================================================================
|
||||
# ROLLE: KEY-USER-NETZWERK-MANAGER*IN (KNM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R5-KNM"
|
||||
rolle_name: "Key-User-Netzwerk-Manager*in"
|
||||
kurzform: "KNM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Systematischer Aufbau und Betreuung eines dezentralen Netzwerks von
|
||||
Prozess-Champions zur Skalierung der PM-Kompetenz in die gesamte
|
||||
DIGITOM-Organisation.
|
||||
|
||||
kernaufgaben:
|
||||
- "Identifikation, Rekrutierung und Onboarding geeigneter Key-User in allen Abteilungen"
|
||||
- "Entwicklung und Durchführung strukturierter Qualifizierungsprogramme für Key-User"
|
||||
- "Community-Management durch regelmäßige Netzwerk-Events und Erfahrungsaustausch"
|
||||
- "Aufbau und Pflege der zentralen Wissensplattform mit Self-Service-Ressourcen"
|
||||
- "Best-Practice-Transfer zwischen Abteilungen durch das Key-User-Netzwerk"
|
||||
- "Performance-Management des Key-User-Netzwerks und kontinuierliche Weiterentwicklung"
|
||||
|
||||
stakeholder:
|
||||
- name: "Key-User in allen Fachbereichen/Abteilungen"
|
||||
beziehung: "Direkte Betreuung und Entwicklung"
|
||||
- name: "Fachbereichsleitungen"
|
||||
beziehung: "Key-User-Nominierung und Freistellung"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Operative Zusammenarbeit bei Fachbereichs-Support"
|
||||
- name: "IT-Abteilung"
|
||||
beziehung: "Wissensplattform-Entwicklung und -betrieb"
|
||||
- name: "Personalentwicklung"
|
||||
beziehung: "Qualifizierungskoordination"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design"
|
||||
- "Community-Event-Planung und Ressourcen-Allokation"
|
||||
- "Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung"
|
||||
- "Key-User-Performance-Bewertung und Entwicklungsempfehlungen"
|
||||
|
||||
kompetenzen:
|
||||
- "Community-Building und Netzwerk-Management für diverse organisatorische Kontexte"
|
||||
- "Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung"
|
||||
- "Content-Management für digitale Wissensplattformen"
|
||||
- "Motivations- und Engagement-Management für freiwillige Communities"
|
||||
- "Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung"
|
||||
59
#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml
Normal file
59
#05_prozessmanagement/#05.4_rollen/rolle_key-user.yaml
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
# =============================================================================
|
||||
# ROLLE: KEY-USER (KU)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R7-KU"
|
||||
rolle_name: "Key-User"
|
||||
kurzform: "KU"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: "Formale Rolle in den Fachbereichen/Abteilungen"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Dezentrale PM-Kompetenz und Change-Agenten in den Fachbereichen/Abteilungen
|
||||
zur lokalen Prozessexpertise und Schnittstelle zur zentralen PM-Funktion.
|
||||
|
||||
kernaufgaben:
|
||||
- "Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im eigenen Fachbereich/Abteilung"
|
||||
- "Lokale Prozessexpertise und Unterstützung der Kollegen bei Prozessarbeit"
|
||||
- "Schnittstelle zwischen Fachbereichen/Abteilungen und zentraler PM-Funktion"
|
||||
- "Modellierung spezifischer (Fach-)Prozesse"
|
||||
- "Implementierung von Framework-Updates und Prozessänderungen im Fachbereich"
|
||||
- "Identifikation lokaler Optimierungspotenziale und Weiterleitung an PM-Funktion"
|
||||
- "Multiplikator für Prozess-Know-how und Best Practices"
|
||||
|
||||
stakeholder:
|
||||
- name: "Kolleg:innen im eigenen Fachbereich/Abteilung"
|
||||
beziehung: "Direkte Unterstützung"
|
||||
- name: "Key-User-Netzwerk-Manager:in"
|
||||
beziehung: "Qualifizierung und Community"
|
||||
- name: "Prozess-Berater:innen"
|
||||
beziehung: "Bei komplexeren Herausforderungen"
|
||||
- name: "Fachbereichs-/Abteilungsleitung"
|
||||
beziehung: "Lokale PM-Vertretung"
|
||||
- name: "Andere Key-User"
|
||||
beziehung: "Erfahrungsaustausch und Peer-Learning"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Erste Bewertung und Priorisierung lokaler Prozess-Anfragen"
|
||||
- "Methodische Empfehlungen für Standardsituationen im Rahmen des Frameworks"
|
||||
- "Weiterleitung komplexerer Fälle an zentrale PM-Funktion"
|
||||
- "Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner"
|
||||
|
||||
kompetenzen:
|
||||
- "Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden"
|
||||
- "Beratungs- und Unterstützungskompetenz für Kolleg:innen"
|
||||
- "Fachbereichs-spezifisches Prozess-Know-how"
|
||||
- "Netzwerk- und Community-Fähigkeiten"
|
||||
- "Change-Agent-Qualitäten für lokale Prozessverbesserungen"
|
||||
61
#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml
Normal file
61
#05_prozessmanagement/#05.4_rollen/rolle_leiter-pm.yaml
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
# =============================================================================
|
||||
# ROLLE: LEITER*IN PROZESS-MANAGEMENT (LPM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R1-LPM"
|
||||
rolle_name: "Leiter*in Prozess-Management"
|
||||
kurzform: "LPM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Strategische Führung und operative Steuerung der gesamten PM-Funktion
|
||||
zur Sicherstellung der Wertschöpfung für DIGITOM.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und organisationalen Bedarfen"
|
||||
- "Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Perspektive (z.B. neue Funktionen, Rollenanpassungen, Governance-Strukturen)"
|
||||
- "Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB, KNM)"
|
||||
- "Stakeholder-Management zu Gremien und Fachbereichen/Abteilungen"
|
||||
- "Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der PM-Funktion"
|
||||
- "Eskalationsmanagement bei strategischen Konflikten oder Ressourcenengpässen"
|
||||
- "Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei kritischen Fällen Eskalation ans Mission Board"
|
||||
- "Berichterstattung an Vision Board über PM-Performance und strategische Entwicklungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Vision Board"
|
||||
beziehung: "Auftraggeber und strategische Abstimmung"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Abstimmung"
|
||||
- name: "Interne PM-Rollen"
|
||||
beziehung: "Führung und Koordination"
|
||||
- name: "Abteilungsleitungen"
|
||||
beziehung: "Strategische PM-Partnerschaften"
|
||||
- name: "Amtsleitung DIGIT"
|
||||
beziehung: "Organisatorische Einbindung"
|
||||
- name: "Externe Berater und Dienstleister"
|
||||
beziehung: "Strategische Partnerschaften"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei kritischen Entscheidungen in Konsultation mit Mission Board)"
|
||||
- "Personalentscheidungen für PM-Team (Einstellung, Entwicklung, Zielsetzung)"
|
||||
- "Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung"
|
||||
- "Eskalation an Mission Board bei konkurrierenden Prioritäten"
|
||||
- "PM-Framework-Freigaben nach PFM-Vorschlägen"
|
||||
|
||||
kompetenzen:
|
||||
- "Führungskompetenz für interdisziplinäre Teams mit verschiedenen Expertisen"
|
||||
- "Strategisches Stakeholder-Management und politische Sensibilität in der Verwaltung"
|
||||
- "Verständnis für das DIGITOM und das PM-Framework sowie organisationale Transformationen"
|
||||
- "Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen Fachbereichen/Abteilungen"
|
||||
- "Change Management für komplexe organisatorische Veränderungen"
|
||||
80
#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml
Normal file
80
#05_prozessmanagement/#05.4_rollen/rolle_process-owner.yaml
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROCESS OWNER (PO)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R6-PO"
|
||||
rolle_name: "Process Owner"
|
||||
kurzform: "PO"
|
||||
kategorie: "schnittstellenrolle"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
hinweis: |
|
||||
Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager (DPM),
|
||||
Projekt Portfolio Manager (PPM), Service Portfolio Manager (SPM)
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
End-to-End-Verantwortung für spezifische Teilprozess-Prozesse zur
|
||||
Sicherstellung von Prozess-Performance, Qualität und kontinuierlicher Optimierung.
|
||||
|
||||
kernaufgaben:
|
||||
- "Strategische Verantwortung für Performance und Qualität der zugeordneten End-to-End-Prozesse"
|
||||
- "Definition prozessspezifischer KPIs auf Basis zentral vorgegebener KPI-Kategorien und Standards"
|
||||
- "Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen"
|
||||
- "Koordination prozessbezogener Optimierungsinitiativen zwischen beteiligten Bereichen"
|
||||
- "Eskalationsmanagement bei prozessrelevanten Problemen oder Ressourcenkonflikten"
|
||||
- "Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen Änderungen"
|
||||
- "Sicherstellung der Framework-Compliance in den verantworteten Prozessen"
|
||||
|
||||
# =============================================================================
|
||||
# PROCESS OWNER-ZUORDNUNG
|
||||
# =============================================================================
|
||||
|
||||
spezifische_zuordnung:
|
||||
- funktion: "SHM"
|
||||
name: "Stakeholder-Management"
|
||||
prozess: "Bedarfserfassung und -qualifizierung"
|
||||
|
||||
- funktion: "DPM"
|
||||
name: "Demand-Portfolio-Management"
|
||||
prozess: "Demand-Bewertung und Demand-Portfolio-Steuerung"
|
||||
|
||||
- funktion: "PPM"
|
||||
name: "Projekt-Portfolio-Management"
|
||||
prozess: "Projektsteuerung und -überwachung"
|
||||
|
||||
- funktion: "SPM"
|
||||
name: "Service-Portfolio-Management"
|
||||
prozess: "Service-Integration und Betriebsüberführung"
|
||||
|
||||
stakeholder:
|
||||
- name: "PM-Funktion"
|
||||
beziehung: "Methodische Unterstützung und Framework-Compliance"
|
||||
- name: "Beteiligte Fachbereiche/Abteilungen"
|
||||
beziehung: "Im jeweiligen End-to-End-Prozess"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Performance-Reporting und strategische Abstimmung"
|
||||
- name: "Key-User"
|
||||
beziehung: "In den prozessrelevanten Bereichen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks"
|
||||
- "Ressourcen-Anfrage/Priorisierung für prozessbezogene Optimierungsmaßnahmen"
|
||||
- "Eskalations-Entscheidungen bei prozessübergreifenden Konflikten"
|
||||
- "KPI-Definition und Performance-Ziele für die verantworteten Prozesse"
|
||||
- "Abnahme-Entscheidungen für Prozessänderungen"
|
||||
|
||||
kompetenzen:
|
||||
- "End-to-End-Prozess-Verständnis mit systemischer Sichtweise"
|
||||
- "Performance-Management mit KPI-Entwicklung und -monitoring"
|
||||
- "Cross-funktionale Koordination zwischen verschiedenen Bereichen"
|
||||
- "Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis"
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESS-BERATER*IN (PB)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R4-PB"
|
||||
rolle_name: "Prozess-Berater*in"
|
||||
kurzform: "PB"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Direkte, vertrauensvolle methodische Unterstützung der Fachbereiche/Abteilungen
|
||||
bei Prozessanalyse, -gestaltung und -optimierung zur Befähigung für
|
||||
eigenständige Prozessarbeit.
|
||||
|
||||
kernaufgaben:
|
||||
- "Individuelle Beratung und Coaching von Fachbereichen/Abteilungen bei konkreten Prozess-Herausforderungen"
|
||||
- "Moderation von Prozess-Workshops für kollaborative Analyse und Optimierung in definierten Fällen"
|
||||
- "Methodische Unterstützung bei Prozessmodellierung und -dokumentation"
|
||||
- "Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl. Erstbewertung von Anfragen über das Ticketsystem)"
|
||||
- "Identifikation von Optimierungspotenzialen durch Prozess-Assessments"
|
||||
- "Begleitende Umsetzungsunterstützung bei Prozessänderungen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Fachbereiche/Abteilungen und deren Teams"
|
||||
beziehung: "Direkte Beratung und Coaching"
|
||||
- name: "Key-User"
|
||||
beziehung: "Operative Zusammenarbeit und Befähigung"
|
||||
- name: "Projektteams"
|
||||
beziehung: "Prozessbezogene Projektunterstützung"
|
||||
- name: "Auftraggeber PM"
|
||||
beziehung: "Bedarfsklärung und Erwartungsmanagement"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Methodische Unterstützung bei End-to-End-Optimierungen"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Methodische Empfehlungen im Rahmen des gültigen Frameworks"
|
||||
- "Workshop-Design und Moderations-Ansätze für spezifische Situationen"
|
||||
- "Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen"
|
||||
- "Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven Problemen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessberatungs-Expertise mit breitem Methoden-Portfolio"
|
||||
- "Workshop-Moderation und Facilitierung für diverse Stakeholder-Konstellationen"
|
||||
- "Change Management-Fähigkeiten für begleitende Prozessveränderungen"
|
||||
- "Empathie und Beziehungsaufbau für vertrauensvolle Beratungspartnerschaften"
|
||||
- "Problemlösungs-Kompetenz für komplexe organisatorische Herausforderungen"
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESS-FRAMEWORK-MANAGER*IN (PFM)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R2-PFM"
|
||||
rolle_name: "Prozess-Framework-Manager*in"
|
||||
kurzform: "PFM"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Entwicklung und Pflege eines einheitlichen, zukunftsfähigen PM-Frameworks,
|
||||
das DIGITOM-weit als methodische Grundlage für qualitativ hochwertige
|
||||
Prozessarbeit dient.
|
||||
|
||||
kernaufgaben:
|
||||
- "Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des verbindlichen PM-Frameworks (Standards, Methoden, Tools, Governance-Regeln)"
|
||||
- "Entwicklung und Pflege eines zentralen KPI-Frameworks mit standardisierten Messkategorien, Berechnungsmethoden und Reporting-Standards"
|
||||
- "Analyse externer Best Practices, Standards und gesetzlicher Anforderungen für Integration ins PM-Framework"
|
||||
- "PM-Framework-Kommunikation und Change Management bei größeren Methodenänderungen"
|
||||
- "Qualitätssicherung des PM-Frameworks durch systematisches Feedback-Management"
|
||||
- "Entwicklung von PM-Framework-Schulungskonzepten und Zertifizierungsstandards"
|
||||
- "Vorschläge zur Weiterentwicklung des DIGITOMs aus Prozess-Management-Sicht"
|
||||
- "Harmonisierung des PM-Frameworks mit dem Service Management Framework"
|
||||
- "Identifikation geeigneter Methoden und technischer Ansätze zur Digitalisierung und (Teil-)Automatisierung von Prozessen"
|
||||
|
||||
stakeholder:
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Strategische Abstimmung und Freigaben"
|
||||
- name: "Alle internen PM-Rollen"
|
||||
beziehung: "Framework-Anwendung und Feedback"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Technische Machbarkeit und Systemintegration"
|
||||
- name: "ISB/Datenschutz"
|
||||
beziehung: "Compliance-Anforderungen"
|
||||
- name: "Process Owner"
|
||||
beziehung: "Framework-Implementierung in spezifischen Prozessen"
|
||||
- name: "Externe Standards-Organisationen und Beratungsunternehmen"
|
||||
beziehung: "Best Practices und Standards"
|
||||
- name: "Zentrales GPM (HPA)"
|
||||
beziehung: "Übergeordnete Abstimmung"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben"
|
||||
- "Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen"
|
||||
- "Methodische Standards für einheitliche Prozessarbeit in DIGITOM"
|
||||
- "PM-Framework-Update-Prioritäten basierend auf organisationalen Bedarfen"
|
||||
|
||||
kompetenzen:
|
||||
- "Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design Thinking)"
|
||||
- "Technisches Verständnis für digitale Prozess-Tools und Plattform-Architekturen"
|
||||
- "Systemisches Denken für komplexe organisatorische Zusammenhänge"
|
||||
- "Didaktische Fähigkeiten für Framework-Kommunikation und Wissensvermittlung"
|
||||
- "Analytische Fähigkeiten für Technologie-Assessment und Standards-Evaluierung"
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
# =============================================================================
|
||||
# ROLLE: PROZESSLANDSCHAFTS-KOORDINATOR*IN (PLK)
|
||||
# =============================================================================
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "R3-PLK"
|
||||
rolle_name: "Prozesslandschafts-Koordinator*in"
|
||||
kurzform: "PLK"
|
||||
kategorie: "kernrolle_intern"
|
||||
funktion_id: "pm"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
|
||||
status:
|
||||
status: "draft"
|
||||
|
||||
# =============================================================================
|
||||
# ROLLENBESCHREIBUNG
|
||||
# =============================================================================
|
||||
|
||||
hauptzweck: |
|
||||
Operative Governance und Transparenz der DIGITOM-Prozesslandschaft zur
|
||||
Sicherstellung von Framework-Compliance und End-to-End-Prozessqualität.
|
||||
|
||||
kernaufgaben:
|
||||
- "Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen Prozessregisters"
|
||||
- "Monitoring von Framework-Compliance und Identifikation von PM-Governance-Lücken"
|
||||
- "Koordination prozessübergreifender Initiativen zwischen verschiedenen Process Ownern"
|
||||
- "PM-Governance-Reporting für Gremien mit Prozess-KPIs und Compliance-Status"
|
||||
- "Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen"
|
||||
- "Risiko-Assessment für Prozesslandschaft und frühzeitige Problemerkennung"
|
||||
- "Schnittstellen-Governance: Moderation von Schnittstellen-Vereinbarungen zwischen Process Ownern und Konfliktlösung bei schnittstellenübergreifenden Problemen"
|
||||
|
||||
pm_governance_luecken_management:
|
||||
beschreibung: "Systematisches Management von PM-Governance-Lücken"
|
||||
aufgaben:
|
||||
- "Systematische Identifikation von PM-Governance-Lücken im DIGIT/DIGITOM"
|
||||
- "Abstimmung mit Prozessberater:innen für Lösungsansätze"
|
||||
- "Bei kurzfristiger Lösung: Dokumentation und Monitoring"
|
||||
- "Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans Mission Board"
|
||||
|
||||
stakeholder:
|
||||
- name: "Process Owner (SHM, DPM, PPM, SPM)"
|
||||
beziehung: "End-to-End-Prozess-Koordination"
|
||||
- name: "Leiter*in Prozess-Management"
|
||||
beziehung: "Governance-Reporting und Eskalationen"
|
||||
- name: "Mission Board"
|
||||
beziehung: "Taktische Governance-Entscheidungen"
|
||||
- name: "Fachbereiche/Abteilungen"
|
||||
beziehung: "Compliance-Unterstützung und Konfliktlösung"
|
||||
- name: "IT-Architektur"
|
||||
beziehung: "Systemische Prozess-Dependencies"
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
- "Governance-Compliance-Bewertungen und Abweichungsmanagement"
|
||||
- "Prozessregister-Updates und Dokumentationsstandards"
|
||||
- "Eskalations-Empfehlungen bei systematischen Governance-Problemen"
|
||||
- "Priorisierung von prozessübergreifenden Optimierungsmaßnahmen"
|
||||
|
||||
kompetenzen:
|
||||
- "Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften"
|
||||
- "Governance-Kompetenz mit Verständnis für Compliance und Risikomanagement"
|
||||
- "Diplomatische Fähigkeiten für Konfliktmediation zwischen Fachbereichen/Abteilungen"
|
||||
- "Analytische Fähigkeiten für KPI-Entwicklung und Performance-Measurement"
|
||||
- "Kommunikationsstärke für verständliches Governance-Reporting"
|
||||
353
#05_prozessmanagement/pm_uebersicht.yaml
Normal file
353
#05_prozessmanagement/pm_uebersicht.yaml
Normal file
|
|
@ -0,0 +1,353 @@
|
|||
# =============================================================================
|
||||
# PROZESS-MANAGEMENT: EXECUTIVE SUMMARY / ÜBERSICHT
|
||||
# =============================================================================
|
||||
# Version: 1.0
|
||||
# Datum: 2026-02-05
|
||||
# Status: Draft - Konvertiert aus Word-Dokumentation
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
typ: "executive_summary"
|
||||
funktion_id: "pm"
|
||||
funktion_name: "Prozess-Management"
|
||||
version: "1.0"
|
||||
gueltig_ab: "2026-02-05"
|
||||
geltungsbereich: "DIGITOM / Prozess-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
|
||||
status: "draft"
|
||||
|
||||
quellen:
|
||||
- "#00 - Prozess-Management.docx"
|
||||
|
||||
# =============================================================================
|
||||
# 1. STRATEGISCHER KONTEXT UND KERNKONZEPT
|
||||
# =============================================================================
|
||||
|
||||
strategischer_kontext:
|
||||
titel: "Strategischer Kontext und Kernkonzept"
|
||||
|
||||
organisationale_herausforderung:
|
||||
titel: "Die organisationale Herausforderung"
|
||||
beschreibung: |
|
||||
Das DIGITOM steht vor einem typischen Widerspruch in modernen
|
||||
Verwaltungen: Es braucht einheitliche Standards für Effektivität und
|
||||
Vergleichbarkeit - gleichzeitig müssen Fachbereiche flexibel auf ihre
|
||||
spezifischen Anforderungen reagieren können.
|
||||
|
||||
ausgangslage:
|
||||
- "Fragmentierte Abläufe"
|
||||
- "Methodische Vielfalt ohne gemeinsame Basis"
|
||||
- "Silos statt Integration"
|
||||
|
||||
konsequenzen:
|
||||
- "Operative Reibungsverluste"
|
||||
- "Verhinderte strategische Weiterentwicklung"
|
||||
- "Ungenutzte Digitalisierungs- und Automatisierungspotenziale"
|
||||
- "Fehlender strukturierter Überblick und notwendige Befähigungen"
|
||||
- "Lokale Optimierungen ohne systemische Wirkung"
|
||||
|
||||
loesungskonzept:
|
||||
titel: "Ein neuer Weg zwischen Kontrolle und Autonomie"
|
||||
beschreibung: |
|
||||
Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung
|
||||
und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn
|
||||
produktiv.
|
||||
|
||||
kernprinzipien:
|
||||
- prinzip: "Zentrale Methodenkompetenz trifft dezentrale Umsetzung"
|
||||
beschreibung: |
|
||||
Die PM-Funktion definiert den Rahmen durch einheitliche Standards,
|
||||
Methoden und Werkzeuge. Innerhalb dieses Rahmens gestalten die
|
||||
Fachbereiche ihre Prozesse aktiv und tragen somit die Verantwortung dafür.
|
||||
|
||||
- prinzip: "Befähigung statt Kontrolle"
|
||||
beschreibung: |
|
||||
Die Funktion versteht sich als Ermöglicher, nicht als Wächter.
|
||||
Sie schafft Kompetenzen vor Ort durch ein Netzwerk von "Key-User",
|
||||
die als Multiplikator:innen in ihren Bereichen wirken.
|
||||
|
||||
- prinzip: "Nutzenorientierung statt Strukturfixierung"
|
||||
beschreibung: |
|
||||
Ausgangspunkt sind nicht interne Logiken, sondern die Bedarfe der
|
||||
internen Kund:innen - von strategischen Gremien bis zu operativen Teams.
|
||||
|
||||
erwarteter_mehrwert:
|
||||
titel: "Der erwartete Mehrwert"
|
||||
|
||||
fuer_strategische_entscheider:
|
||||
zielgruppe: "Strategische Entscheider:innen"
|
||||
mehrwert:
|
||||
- "Erstmals Transparenz über die gesamte Prozesslandschaft"
|
||||
- "Ermöglichte strategische Gestaltung"
|
||||
- "Frühzeitige Sichtbarkeit von Risiken"
|
||||
- "Systematische Erschließung von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
|
||||
fuer_operative_teams:
|
||||
zielgruppe: "Operative Teams"
|
||||
mehrwert:
|
||||
- "Methodische Unterstützung genau dann, wenn sie benötigt wird"
|
||||
- "Von schneller Beratung bis zur Begleitung komplexer Transformationen"
|
||||
- "Einheitliche Standards für bereichsübergreifende Zusammenarbeit"
|
||||
|
||||
fuer_gesamtorganisation:
|
||||
zielgruppe: "Gesamtorganisation"
|
||||
mehrwert:
|
||||
- "Anpassungsfähigkeit ohne Kontrollverlust"
|
||||
- "Kontinuierliche Prozessverbesserung statt nur Dokumentation"
|
||||
- "Systematische Identifikation von Digitalisierungs- und Automatisierungspotenzialen"
|
||||
- "Adressierung von Fachkräftemangel und steigenden Anforderungen"
|
||||
|
||||
# =============================================================================
|
||||
# 2. ORGANISATIONSDESIGN UND GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
organisationsdesign:
|
||||
titel: "Organisationsdesign und Governance"
|
||||
|
||||
architektur:
|
||||
titel: "Eine Architektur der produktiven Spannung"
|
||||
prinzip: |
|
||||
Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung.
|
||||
Methodische Beratung und operative Governance liegen in unterschiedlichen
|
||||
Händen - so entsteht Vertrauen statt Kontrollangst.
|
||||
|
||||
zentrale_rollen:
|
||||
beschreibung: |
|
||||
Fünf zentrale Rollen im PM-Team decken das Spektrum von strategischer
|
||||
Führung über Methodenentwicklung bis zur operativen Beratung ab.
|
||||
Jede Rolle hat klare Verantwortlichkeiten, Überschneidungen werden vermieden.
|
||||
rollen:
|
||||
- "Leiter*in Prozess-Management"
|
||||
- "Prozess-Framework-Manager*in (PFM)"
|
||||
- "Prozesslandschafts-Koordinator*in (PLK)"
|
||||
- "Prozess-Berater*in (PB)"
|
||||
- "Key-User-Netzwerk-Manager*in (KNM)"
|
||||
|
||||
process_owner:
|
||||
beschreibung: |
|
||||
Process Owner in den Hauptprozessen tragen horizontale und vertikale
|
||||
End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren
|
||||
bereichsübergreifend und sichern Prozessqualität.
|
||||
hauptprozesse:
|
||||
- "Stakeholder-Management"
|
||||
- "Demand-Management"
|
||||
- "Projekt-Management"
|
||||
- "Service-Management"
|
||||
|
||||
key_user:
|
||||
beschreibung: |
|
||||
Key-User werden in allen Fachbereichen identifiziert und zu lokalen
|
||||
Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle vor Ort
|
||||
und Bindeglied zur zentralen PM-Funktion.
|
||||
|
||||
governance:
|
||||
titel: "Governance: So viel wie nötig, so wenig wie möglich"
|
||||
prinzip: "Subsidiaritätsprinzip"
|
||||
|
||||
entscheidungskategorien:
|
||||
- kategorie: "Operative Anpassungen"
|
||||
entscheidungsträger: "PM-Team eigenständig"
|
||||
beispiele:
|
||||
- "Tool-Konfigurationen"
|
||||
- "Template-Updates"
|
||||
- "Schulungsinhalte"
|
||||
|
||||
- kategorie: "Prozessspezifische Anpassungen"
|
||||
entscheidungsträger: "Abstimmung mit jeweiligem Process Owner"
|
||||
beispiele:
|
||||
- "Änderungen an Prozessschnittstellen"
|
||||
- "Neue Metriken für spezifische Prozesse"
|
||||
- "Integration neuer Systeme in bestehende Prozesse"
|
||||
|
||||
- kategorie: "PM-Framework-Weiterentwicklungen"
|
||||
entscheidungsträger: "PM-Team eigenständig (Information an Process Owner)"
|
||||
beispiele:
|
||||
- "Neue Modellierungsstandards"
|
||||
- "Erweiterte Methodenbausteine"
|
||||
- "Übergreifende Bewertungskriterien"
|
||||
|
||||
- kategorie: "Fundamentale Änderungen"
|
||||
entscheidungsträger: "Steuerungsgremien"
|
||||
beispiele:
|
||||
- "Wechsel der Prozessmodellierungssprache"
|
||||
- "Grundlegende Änderung der PM-Strategie"
|
||||
- "Neuausrichtung der Prozessarchitektur"
|
||||
|
||||
leistungsbeauftragung:
|
||||
- typ: "Standard-Leistungen"
|
||||
zugang: "Niedrigschwellig für alle zugänglich"
|
||||
beispiele:
|
||||
- "Beratung"
|
||||
- "Workshops"
|
||||
|
||||
- typ: "Projekt-Leistungen"
|
||||
zugang: "Mission Board-Freigabe erforderlich"
|
||||
beispiele:
|
||||
- "Größere Transformationen"
|
||||
|
||||
- typ: "Strategische Initiativen"
|
||||
zugang: "Direkte Beauftragung durch Vision Board"
|
||||
|
||||
- typ: "Krisen-Interventionen"
|
||||
zugang: "Jederzeit durch Führungskräfte auslösbar"
|
||||
|
||||
eskalationsmodell:
|
||||
beschreibung: "Dreistufiges Eskalationsmodell sichert schnelle Konfliktlösung"
|
||||
stufen:
|
||||
- stufe: 1
|
||||
typ: "Operative Themen"
|
||||
zeitrahmen: "Binnen 48 Stunden"
|
||||
|
||||
- stufe: 2
|
||||
typ: "Taktische Konflikte"
|
||||
gremium: "Mission Board"
|
||||
zeitrahmen: "Binnen einer Woche"
|
||||
|
||||
- stufe: 3
|
||||
typ: "Strategische Grundsatzfragen"
|
||||
gremium: "Vision Board"
|
||||
zeitrahmen: "Binnen eines Monats"
|
||||
|
||||
integration:
|
||||
titel: "Integration statt Parallelstruktur"
|
||||
beschreibung: |
|
||||
Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance
|
||||
ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien.
|
||||
Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor.
|
||||
|
||||
schluesselpartner:
|
||||
- "Zentrales Geschäftsprozessmanagement (HPA)"
|
||||
- "IT-Architektur"
|
||||
- "Datenschutz"
|
||||
- "Informationssicherheit"
|
||||
|
||||
prinzip: |
|
||||
Systematische Einbindung schafft vernetzte Kompetenz statt neuer Silos.
|
||||
|
||||
# =============================================================================
|
||||
# 3. IMPLEMENTIERUNG UND KRITISCHE ERFOLGSFAKTOREN
|
||||
# =============================================================================
|
||||
|
||||
implementierung:
|
||||
titel: "Implementierung und kritische Erfolgsfaktoren"
|
||||
|
||||
leistungsportfolio:
|
||||
titel: "Konkrete Leistungen, klare Zugänge"
|
||||
orientierung: "Reale Bedarfe"
|
||||
|
||||
leistungsbereiche:
|
||||
- bereich: "Prozess-Framework/DIGITOM-Entwicklung"
|
||||
zweck: "Schafft die methodische Basis"
|
||||
|
||||
- bereich: "Beratung und Coaching"
|
||||
zweck: "Unterstützt bei konkreten Herausforderungen"
|
||||
|
||||
- bereich: "Befähigung und Schulung"
|
||||
zweck: "Baut Kompetenzen dezentral auf"
|
||||
|
||||
- bereich: "Transparenz und Reporting"
|
||||
zweck: "Ermöglicht faktenbasierte Steuerung"
|
||||
|
||||
zugangswege:
|
||||
- "Ticketsystem für direkte Hilfe"
|
||||
- "Strukturierte Beauftragungen für größere Vorhaben"
|
||||
- "Informelle Kanäle über das Key-User-Netzwerk"
|
||||
|
||||
ressourcen:
|
||||
titel: "Ressourcen und Voraussetzungen"
|
||||
|
||||
quantitativ:
|
||||
- "Dediziertes PM-Team mit komplementären Kompetenzen"
|
||||
- "Moderne Prozess-Tools"
|
||||
- "Qualifizierungsbudgets"
|
||||
|
||||
qualitativ:
|
||||
wichtigkeit: "Wichtiger als Ressourcen sind die qualitativen Voraussetzungen"
|
||||
faktoren:
|
||||
- faktor: "Klares Mandat der Führung"
|
||||
wirkung: "Legitimiert die Funktion"
|
||||
|
||||
- faktor: "Bereitschaft der Fachbereiche"
|
||||
wirkung: "Zur aktiven Mitgestaltung"
|
||||
|
||||
- faktor: "Einbindung der Schlüsselpartner"
|
||||
wirkung: "Von Anfang an"
|
||||
|
||||
- faktor: "Verständnis von Prozessmanagement"
|
||||
wirkung: "Als kontinuierliche Entwicklung, nicht als Projekt"
|
||||
|
||||
risikomanagement:
|
||||
titel: "Risiken aktiv managen"
|
||||
|
||||
risiken:
|
||||
- risiko: "Akzeptanzrisiken"
|
||||
mitigationsstrategie: |
|
||||
Konsequente Trennung von Beratung und Kontrolle.
|
||||
Erfolgsgeschichten und Key-User als Botschafter:innen schaffen Vertrauen.
|
||||
|
||||
- risiko: "Ressourcenkonflikte"
|
||||
mitigationsstrategie: |
|
||||
Transparentes Priorisierungsmodell. Strategische Initiativen gehen
|
||||
stets vor, konkurrierende Anfragen werden offen abgewogen.
|
||||
|
||||
- risiko: "Qualitätsrisiken"
|
||||
mitigationsstrategie: |
|
||||
Systematische Einbindung von Compliance-Funktionen und
|
||||
Process Owner als Qualitätsgatekeeper.
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNGEN ZU ANDEREN PM-DOKUMENTEN
|
||||
# =============================================================================
|
||||
|
||||
dokumentverknuepfungen:
|
||||
beschreibung: |
|
||||
Diese Executive Summary gibt einen kompakten Überblick. Die Details
|
||||
finden sich in den spezialisierten Dokumenten der PM-Funktion.
|
||||
|
||||
detaildokumente:
|
||||
- dokument: "Funktionsbeschreibung"
|
||||
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
|
||||
inhalt: "Formale Grundlagen, Verantwortungsbereiche, Mandat"
|
||||
|
||||
- dokument: "Leistungs-Canvas"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
|
||||
inhalt: "Detaillierte Leistungen, Nutzersegmente, Wertversprechen"
|
||||
|
||||
- dokument: "Rollenmodell"
|
||||
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
|
||||
inhalt: "Alle 11 Rollen mit Aufgaben, Befugnissen, Schnittstellen"
|
||||
|
||||
- dokument: "Governance-Framework"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
|
||||
inhalt: "Entscheidungswege, Eskalation, Leitprinzipien"
|
||||
|
||||
- dokument: "RACI-Matrix"
|
||||
pfad: "#05_prozessmanagement/#05.2_governance/pm_raci.yaml"
|
||||
inhalt: "Verantwortlichkeitsmatrix für alle Leistungen"
|
||||
|
||||
- dokument: "Konzeptrahmen"
|
||||
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_konzeptrahmen.yaml"
|
||||
inhalt: "Dokumentationsarchitektur und Navigationshilfe"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2026-02-05"
|
||||
aenderung: |
|
||||
Initiale Erstellung durch Konvertierung aus Word-Dokument.
|
||||
Quelle: #00 - Prozess-Management.docx
|
||||
|
||||
Inhalte:
|
||||
- Strategischer Kontext und Kernkonzept
|
||||
- Organisationale Herausforderung
|
||||
- Lösungskonzept (3 Kernprinzipien)
|
||||
- Erwarteter Mehrwert (3 Zielgruppen)
|
||||
- Organisationsdesign (Rollen, Process Owner, Key-User)
|
||||
- Governance (4 Entscheidungskategorien, 4 Leistungstypen, 3 Eskalationsstufen)
|
||||
- Implementierung (Leistungsportfolio, Ressourcen, Risikomanagement)
|
||||
autor: "DIGITOM-Projekt"
|
||||
7
README.md
Normal file
7
README.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
# DIGITOM – Konzeptdokumentation
|
||||
|
||||
Dieses Repository enthält die YAML-Quelldateien des DIGITOM-Frameworks der Stadt Freiburg im Breisgau.
|
||||
|
||||
DIGITOM ist ein digitales Transformationsmodell zur Weiterentwicklung der IT-Organisation auf Basis von ITIL 4.
|
||||
|
||||
> Hinweis: Dieses Repository enthält ausschließlich die konzeptionellen Kerndateien. Pilot-Instanzen, lokale Konfigurationen und interne Arbeitsdokumente sind nicht enthalten.
|
||||
Loading…
Add table
Add a link
Reference in a new issue