säuberung repo
This commit is contained in:
parent
93b9576bc6
commit
9788e273ed
80 changed files with 47758 additions and 48172 deletions
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
|
|
@ -1,184 +1,193 @@
|
|||
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
|
||||
|
||||
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. Diese Aktivität bildet den Startpunkt für
|
||||
die Erstellung der Service-Definition als zentrales Artefakt.
|
||||
|
||||
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"
|
||||
|
||||
hinweis_rollen: >
|
||||
In der Design-Phase agiert die Rolle service_owner als designierter
|
||||
Service Owner, da der Service noch nicht im Betrieb existiert und die
|
||||
formale Übernahme der SO-Rolle erst bei Gate 1 (tr_01) erfolgt
|
||||
(vgl. GOV-TR-004, GOV-TR-006). Die Empfehlung ist eine frühzeitige
|
||||
Benennung bei/kurz nach Projektfreigabe; der harte Constraint liegt
|
||||
bei Gate 1. Dieser Hinweis gilt für alle Aktivitäten ds_01 bis ds_04.
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -1,268 +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"
|
||||
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"
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -1,407 +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"
|
||||
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"
|
||||
|
|
@ -1,104 +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"
|
||||
# =============================================================================
|
||||
# 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
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
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
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
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
File diff suppressed because it is too large
Load diff
|
|
@ -1,165 +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"
|
||||
# =============================================================================
|
||||
# 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"
|
||||
|
|
|
|||
|
|
@ -1,186 +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"
|
||||
# =============================================================================
|
||||
# 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
Loading…
Add table
Add a link
Reference in a new issue