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
|
|
@ -1,215 +1,215 @@
|
|||
metadata:
|
||||
version: "3.7"
|
||||
datum: "2026-03-09"
|
||||
quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
|
||||
basis: "ITIL4 / DIGITOM Begriffsüberleitung"
|
||||
hinweis: >
|
||||
Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
|
||||
ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
|
||||
eins in das DIGIT Service-Management Framework passen (Übernehmen),
|
||||
ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
|
||||
modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
|
||||
keinen erkennbaren Mehrwert bieten (Weglassen).
|
||||
|
||||
glossar:
|
||||
- begriff: "Anforderung"
|
||||
definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
|
||||
synonyme: ["Requirement", "Vorgabe"]
|
||||
|
||||
- begriff: "Anwender*in"
|
||||
definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
|
||||
synonyme: ["Nutzer*in", "User"]
|
||||
|
||||
- begriff: "Auftraggeber*in"
|
||||
definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
|
||||
|
||||
- begriff: "Bedarf"
|
||||
definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
|
||||
|
||||
- begriff: "Change"
|
||||
definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
|
||||
synonyme: ["Änderung"]
|
||||
|
||||
- begriff: "Configuration Item (CI)"
|
||||
definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
|
||||
|
||||
- begriff: "Demand"
|
||||
definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
|
||||
|
||||
- begriff: "Demand-Steckbrief"
|
||||
definition: |
|
||||
Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
|
||||
den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
|
||||
Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
|
||||
abgrenzung:
|
||||
- "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
|
||||
- "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
|
||||
|
||||
- begriff: "Emergency-Change"
|
||||
definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
|
||||
|
||||
- begriff: "Ergebnis"
|
||||
definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
|
||||
synonyme: ["Outcome"]
|
||||
|
||||
- begriff: "Gewährleistung"
|
||||
definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
|
||||
synonyme: ["Qualitätszusage", "Warranty"]
|
||||
|
||||
- begriff: "Geschäftskritikalität"
|
||||
definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
|
||||
synonyme: ["Business Criticality", "Service-Kritikalität"]
|
||||
|
||||
- begriff: "Governance"
|
||||
definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
|
||||
|
||||
- begriff: "Incident"
|
||||
definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
|
||||
synonyme: ["Vorfall", "Störung"]
|
||||
|
||||
- begriff: "Interner Service"
|
||||
definition: |
|
||||
Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
|
||||
DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
|
||||
sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
|
||||
Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
|
||||
eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
|
||||
Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
|
||||
Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
|
||||
abgrenzung:
|
||||
- "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
|
||||
- "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
|
||||
kategorie: "I"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
|
||||
|
||||
- begriff: "Initiative"
|
||||
definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
|
||||
synonyme: ["Chance", "Möglichkeit", "Opportunity"]
|
||||
|
||||
- begriff: "Key Performance Indicator (KPI)"
|
||||
definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
|
||||
|
||||
- begriff: "Kontinuierliche Verbesserung"
|
||||
definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
|
||||
|
||||
- begriff: "Kundenservice"
|
||||
definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
|
||||
|
||||
- begriff: "Kund*in"
|
||||
definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
|
||||
synonyme: ["Service-Konsument"]
|
||||
|
||||
- begriff: "Major-Change"
|
||||
definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
|
||||
synonyme: ["Wesentliche Änderung"]
|
||||
|
||||
- begriff: "Normal-Change"
|
||||
definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
|
||||
|
||||
- begriff: "Nutzen"
|
||||
definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
|
||||
synonyme: ["Utility"]
|
||||
|
||||
- begriff: "Problem (engl.)"
|
||||
definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
|
||||
synonyme: ["Ursache"]
|
||||
|
||||
- begriff: "Produkt"
|
||||
definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
|
||||
synonyme: ["Leistungsbaustein"]
|
||||
|
||||
- begriff: "Recovery Time Objective (RTO)"
|
||||
definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
|
||||
synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
|
||||
|
||||
- begriff: "Request-Katalog"
|
||||
definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
|
||||
|
||||
- begriff: "Request for Change (RFC)"
|
||||
definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
|
||||
synonyme: ["Change Request"]
|
||||
|
||||
- begriff: "Ressource"
|
||||
definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
|
||||
|
||||
- begriff: "Service"
|
||||
definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
|
||||
synonyme: ["Dienstleistung"]
|
||||
|
||||
- begriff: "Service Level"
|
||||
definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
|
||||
synonyme: ["Service-Qualitätsniveau"]
|
||||
|
||||
- begriff: "Operational Level Agreement (OLA)"
|
||||
definition: |
|
||||
Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
|
||||
(Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
|
||||
Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
|
||||
abgrenzung:
|
||||
- "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
|
||||
- "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
- begriff: "Service-Sichtbarkeit"
|
||||
definition: |
|
||||
Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
|
||||
Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
|
||||
Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
|
||||
Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
|
||||
Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
|
||||
governance_referenz: "GOV-SPM-I-003"
|
||||
|
||||
- begriff: "Service Level Agreement (SLA)"
|
||||
definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
|
||||
synonyme: ["Servicevereinbarung"]
|
||||
|
||||
- begriff: "Service Request"
|
||||
definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
|
||||
synonyme: ["Serviceanfrage"]
|
||||
|
||||
- begriff: "Service-Anbieter"
|
||||
definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
|
||||
synonyme: ["Dienstleister", "Service Provider"]
|
||||
|
||||
- begriff: "Service-Angebot"
|
||||
definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
|
||||
synonyme: ["Leistungsangebot"]
|
||||
|
||||
- begriff: "Service-Bereitstellung"
|
||||
definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
|
||||
synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
|
||||
|
||||
- begriff: "Service-Beziehung"
|
||||
definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
|
||||
|
||||
- begriff: "Service-Katalog"
|
||||
definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
|
||||
|
||||
- begriff: "Service-Portfolio"
|
||||
definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
|
||||
synonyme: ["IT-Service-Portfolio"]
|
||||
|
||||
- begriff: "Sponsor*in"
|
||||
definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
|
||||
|
||||
- begriff: "Stakeholder"
|
||||
definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
|
||||
synonyme: ["Anspruchsgruppen"]
|
||||
|
||||
- begriff: "Standard Operating Procedures (SOPs)"
|
||||
definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
|
||||
synonyme: ["Standardvorgehensweise"]
|
||||
|
||||
- begriff: "Standard-Change"
|
||||
definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
|
||||
|
||||
- begriff: "Vital Business Function (VBF)"
|
||||
definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
|
||||
synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
|
||||
|
||||
- begriff: "Wert"
|
||||
definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
|
||||
|
||||
- begriff: "Wissensmanagement"
|
||||
definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."
|
||||
metadata:
|
||||
version: "3.7"
|
||||
datum: "2026-03-09"
|
||||
quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
|
||||
basis: "ITIL4 / DIGITOM Begriffsüberleitung"
|
||||
hinweis: >
|
||||
Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
|
||||
ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
|
||||
eins in das DIGIT Service-Management Framework passen (Übernehmen),
|
||||
ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
|
||||
modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
|
||||
keinen erkennbaren Mehrwert bieten (Weglassen).
|
||||
|
||||
glossar:
|
||||
- begriff: "Anforderung"
|
||||
definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
|
||||
synonyme: ["Requirement", "Vorgabe"]
|
||||
|
||||
- begriff: "Anwender*in"
|
||||
definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
|
||||
synonyme: ["Nutzer*in", "User"]
|
||||
|
||||
- begriff: "Auftraggeber*in"
|
||||
definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
|
||||
|
||||
- begriff: "Bedarf"
|
||||
definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
|
||||
|
||||
- begriff: "Change"
|
||||
definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
|
||||
synonyme: ["Änderung"]
|
||||
|
||||
- begriff: "Configuration Item (CI)"
|
||||
definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
|
||||
|
||||
- begriff: "Demand"
|
||||
definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
|
||||
|
||||
- begriff: "Demand-Steckbrief"
|
||||
definition: |
|
||||
Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
|
||||
den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
|
||||
Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
|
||||
abgrenzung:
|
||||
- "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
|
||||
- "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
|
||||
|
||||
- begriff: "Emergency-Change"
|
||||
definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
|
||||
|
||||
- begriff: "Ergebnis"
|
||||
definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
|
||||
synonyme: ["Outcome"]
|
||||
|
||||
- begriff: "Gewährleistung"
|
||||
definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
|
||||
synonyme: ["Qualitätszusage", "Warranty"]
|
||||
|
||||
- begriff: "Geschäftskritikalität"
|
||||
definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
|
||||
synonyme: ["Business Criticality", "Service-Kritikalität"]
|
||||
|
||||
- begriff: "Governance"
|
||||
definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
|
||||
|
||||
- begriff: "Incident"
|
||||
definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
|
||||
synonyme: ["Vorfall", "Störung"]
|
||||
|
||||
- begriff: "Interner Service"
|
||||
definition: |
|
||||
Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
|
||||
DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
|
||||
sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
|
||||
Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
|
||||
eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
|
||||
Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
|
||||
Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
|
||||
abgrenzung:
|
||||
- "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
|
||||
- "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
|
||||
kategorie: "I"
|
||||
governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
|
||||
|
||||
- begriff: "Initiative"
|
||||
definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
|
||||
synonyme: ["Chance", "Möglichkeit", "Opportunity"]
|
||||
|
||||
- begriff: "Key Performance Indicator (KPI)"
|
||||
definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
|
||||
|
||||
- begriff: "Kontinuierliche Verbesserung"
|
||||
definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
|
||||
|
||||
- begriff: "Kundenservice"
|
||||
definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
|
||||
|
||||
- begriff: "Kund*in"
|
||||
definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
|
||||
synonyme: ["Service-Konsument"]
|
||||
|
||||
- begriff: "Major-Change"
|
||||
definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
|
||||
synonyme: ["Wesentliche Änderung"]
|
||||
|
||||
- begriff: "Normal-Change"
|
||||
definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
|
||||
|
||||
- begriff: "Nutzen"
|
||||
definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
|
||||
synonyme: ["Utility"]
|
||||
|
||||
- begriff: "Problem (engl.)"
|
||||
definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
|
||||
synonyme: ["Ursache"]
|
||||
|
||||
- begriff: "Produkt"
|
||||
definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
|
||||
synonyme: ["Leistungsbaustein"]
|
||||
|
||||
- begriff: "Recovery Time Objective (RTO)"
|
||||
definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
|
||||
synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
|
||||
|
||||
- begriff: "Request-Katalog"
|
||||
definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
|
||||
|
||||
- begriff: "Request for Change (RFC)"
|
||||
definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
|
||||
synonyme: ["Change Request"]
|
||||
|
||||
- begriff: "Ressource"
|
||||
definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
|
||||
|
||||
- begriff: "Service"
|
||||
definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
|
||||
synonyme: ["Dienstleistung"]
|
||||
|
||||
- begriff: "Service Level"
|
||||
definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
|
||||
synonyme: ["Service-Qualitätsniveau"]
|
||||
|
||||
- begriff: "Operational Level Agreement (OLA)"
|
||||
definition: |
|
||||
Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
|
||||
(Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
|
||||
Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
|
||||
Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
|
||||
abgrenzung:
|
||||
- "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
|
||||
- "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
|
||||
governance_referenz: "GOV-SPM-I-002"
|
||||
|
||||
- begriff: "Service-Sichtbarkeit"
|
||||
definition: |
|
||||
Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
|
||||
Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
|
||||
Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
|
||||
Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
|
||||
Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
|
||||
governance_referenz: "GOV-SPM-I-003"
|
||||
|
||||
- begriff: "Service Level Agreement (SLA)"
|
||||
definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
|
||||
synonyme: ["Servicevereinbarung"]
|
||||
|
||||
- begriff: "Service Request"
|
||||
definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
|
||||
synonyme: ["Serviceanfrage"]
|
||||
|
||||
- begriff: "Service-Anbieter"
|
||||
definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
|
||||
synonyme: ["Dienstleister", "Service Provider"]
|
||||
|
||||
- begriff: "Service-Angebot"
|
||||
definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
|
||||
synonyme: ["Leistungsangebot"]
|
||||
|
||||
- begriff: "Service-Bereitstellung"
|
||||
definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
|
||||
synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
|
||||
|
||||
- begriff: "Service-Beziehung"
|
||||
definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
|
||||
|
||||
- begriff: "Service-Katalog"
|
||||
definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
|
||||
|
||||
- begriff: "Service-Portfolio"
|
||||
definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
|
||||
synonyme: ["IT-Service-Portfolio"]
|
||||
|
||||
- begriff: "Sponsor*in"
|
||||
definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
|
||||
|
||||
- begriff: "Stakeholder"
|
||||
definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
|
||||
synonyme: ["Anspruchsgruppen"]
|
||||
|
||||
- begriff: "Standard Operating Procedures (SOPs)"
|
||||
definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
|
||||
synonyme: ["Standardvorgehensweise"]
|
||||
|
||||
- begriff: "Standard-Change"
|
||||
definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
|
||||
|
||||
- begriff: "Vital Business Function (VBF)"
|
||||
definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
|
||||
synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
|
||||
|
||||
- begriff: "Wert"
|
||||
definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
|
||||
|
||||
- begriff: "Wissensmanagement"
|
||||
definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue