sync: initial full sync to match digitom HEAD
This commit is contained in:
digitom-sync-hook
parent
9788e273ed
commit
6a3299ed48
28 changed files with 5666 additions and 340 deletions
|
|
@ -90,7 +90,7 @@ mandat:
|
|||
|
||||
entscheidungen:
|
||||
- gegenstand: "Service-Aktivierungen (Go-Live-Freigabe)"
|
||||
referenz: "Gate 3 der Service Transition (tr_11)"
|
||||
referenz: "Gate 3 der Service Transition (tr_12)"
|
||||
governance_referenz: "GOV-TR-002"
|
||||
|
||||
- gegenstand: "Service-Review-Entscheidungen"
|
||||
|
|
@ -1139,9 +1139,15 @@ aenderungshistorie:
|
|||
dass die SOR bei REDESIGN/RETIRE die Reife prüft und an DPM übergibt,
|
||||
aber nicht selbst strategisch entscheidet.
|
||||
|
||||
- version: "1.2"
|
||||
datum: "2026-04-11"
|
||||
aenderung: "Gate-3-Referenz korrigiert: tr_11 → tr_12 (Anpassung an Service-Lifecycle v3.2)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.2"
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2026-01-30"
|
||||
aenderung: "Anpassung an Service-Lifecycle 3.0: Gate-Referenzen aktualisiert (Go-Live-Freigabe ist Gate 3 / tr_11, nicht Gate 2)"
|
||||
aenderung: "Anpassung an Service-Lifecycle 3.0: Gate-Referenzen aktualisiert (Go-Live-Freigabe ist Gate 3 / tr_12, nicht Gate 2)"
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,292 @@
|
|||
# Service-Lifecycle Blueprint - Changelog
|
||||
|
||||
## Version 3.2 - Gate-1-Verschiebung in Transition-Phase (18. Februar 2026)
|
||||
|
||||
### 🎯 Übersicht
|
||||
|
||||
Gate 1 wurde aus der Design-Phase in die Transition-Phase verschoben. Es ist nun das Entry-Gate der Transition und trägt die ID `tr_01`. Alle bisherigen Transition-Aktivitäts-IDs haben sich dadurch um +1 erhöht.
|
||||
|
||||
---
|
||||
|
||||
### 🔄 ID-Verschiebungen
|
||||
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| ds_05 | tr_01 | **Gate 1: Entwicklung oder Konfiguration?** |
|
||||
| tr_01 | tr_02 | Koordinieren der Entwicklungs- und Beschaffungsaktivitäten |
|
||||
| tr_02 | tr_03 | Entwickeln von Anwendungen und Systemen |
|
||||
| tr_03 | tr_04 | Entgegennehmen der Service-Komponenten |
|
||||
| tr_04 | tr_05 | Konfiguration der Service-Komponenten |
|
||||
| tr_05 | tr_06 | Erstellen oder Aktualisieren der Betriebs-Dokumentation |
|
||||
| tr_06 | tr_07 | Testen der Service-Komponenten |
|
||||
| tr_07 | tr_08 | Formale Übergabe (Build abgeschlossen) |
|
||||
| tr_08 | tr_09 | **Gate 2: Entry-Prüfung nach Build** |
|
||||
| tr_09 | tr_10 | Ausrollen der Service-Komponenten |
|
||||
| tr_10 | tr_11 | Vorbereiten der Service-Aktivierung |
|
||||
| tr_11 | tr_12 | **Gate 3: Go-Live-Freigabe** |
|
||||
|
||||
**Design-Phase:** ds_05 entfällt, Design endet jetzt bei ds_04.
|
||||
|
||||
---
|
||||
|
||||
### 📁 Datei-Änderungen
|
||||
|
||||
| Datei | Version | Änderung |
|
||||
|-------|---------|----------|
|
||||
| `service-lifecycle_transition.yaml` | 1.0 → 2.0 | Gate 1 als tr_01 aufgenommen, alle IDs um +1 verschoben |
|
||||
| `spm_konzept_service-transition.yaml` | 2.0 → 3.0 | Gate-Referenzen und Aktivitäts-IDs aktualisiert |
|
||||
| `spm_schema_transition-steckbrief.yaml` | 0.2 → 0.3 | Gate-IDs aktualisiert (Gate 2 = tr_09, Gate 3 = tr_12) |
|
||||
| `readme_service-lifecycle-blueprint.md` | 3.1 → 3.2 | Gate-Tabellen, Aktivitätslisten, Präfix-Tabelle aktualisiert |
|
||||
| `spm_sor_go.yaml` | — | Residualfehler tr_11 → tr_12 korrigiert (2 Stellen) |
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Begründung
|
||||
|
||||
Gate 1 ist konzeptionell das Entry-Gate der Transition, nicht der Abschluss des Designs. Die Verschiebung spiegelt wider, dass die SOR-Entscheidung (Build vs. Configure) den Eintritt in die Transition-Phase steuert und daher inhaltlich zur Transition gehört.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Version 3.1 - Ressourcen-Commitment-Prüfung an Gate 1 (30. Januar 2026)
|
||||
|
||||
### 🎯 Übersicht
|
||||
|
||||
Konzeptionelle Korrektur: Die Prüfung des Ressourcen-Commitments von Betrieb und Support muss **vor Beginn der Transition** erfolgen, nicht erst an Gate 3. Andernfalls werden Ressourcen für einen Service aufgewendet, der möglicherweise nicht betrieben werden kann.
|
||||
|
||||
---
|
||||
|
||||
### ✨ Neue Zwei-Stufen-Prüfung
|
||||
|
||||
| Gate | Prüfgegenstand | Was wird geprüft? |
|
||||
|------|----------------|-------------------|
|
||||
| **Gate 1** (ds_05) | Grundsätzliches Ressourcen-Commitment | "Haben Betrieb und Support grundsätzlich die Kapazität/Bereitschaft, diesen Service zu übernehmen?" |
|
||||
| **Gate 3** (tr_11) | Operatives Ressourcen-Commitment | "Haben Betrieb und Support die konkrete Übernahme für JETZT bestätigt?" |
|
||||
|
||||
**Logik:**
|
||||
1. Gate 1 prüft das **grundsätzliche** Commitment (Showstopper bei "nicht_gegeben")
|
||||
2. Gate 3 bestätigt die **operative** Bereitschaft (konkreter Termin, Personal eingeplant)
|
||||
|
||||
---
|
||||
|
||||
### 📁 Änderungen
|
||||
|
||||
#### service-lifecycle_design.yaml (v2.0 → v2.1)
|
||||
- **Neu:** Prüfdimensionen für Gate 1 explizit dokumentiert (g1_dim_01 bis g1_dim_05)
|
||||
- **Neu:** Prüfdimension "Betriebs- und Support-Bereitschaft" (g1_dim_04) als Showstopper
|
||||
- **Aktualisiert:** governance_hinweis enthält nun 5 statt 4 Punkte
|
||||
|
||||
#### spm_schema_transition-steckbrief.yaml (v0.2 → v0.3)
|
||||
- **Aktualisiert:** Beschreibung von `pruefung_ressourcen_commitment` präzisiert
|
||||
- **Neu:** Abgrenzung zu Gate 1 dokumentiert
|
||||
- **Klarstellung:** Gate 3 prüft operative Bestätigung, nicht grundsätzliches Commitment
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Auswirkungen
|
||||
|
||||
- Gate-1-Prüfung wird strenger: Ohne Bestätigung von Betrieb/Support kann Transition nicht starten
|
||||
- Bei Änderungen zwischen Gate 1 und Gate 3 (z.B. Personalabgang) muss eskaliert werden
|
||||
- Governance-Dokumentation muss entsprechend angepasst werden
|
||||
|
||||
---
|
||||
|
||||
### 📝 Begründung
|
||||
|
||||
Der bisherige Zustand war konzeptionell inkonsistent: Wenn erst an Gate 3 festgestellt wird, dass keine Betriebsressourcen verfügbar sind, sind alle Build-, Test- und Deploy-Aktivitäten (tr_01 bis tr_10) umsonst durchgeführt worden. Das widerspricht dem Grundprinzip der Ressourceneffizienz.
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Version 3.0 - 5-Phasen-Konsolidierung (30. Januar 2026)
|
||||
|
||||
### 🎯 Übersicht
|
||||
|
||||
Konsolidierung des Service-Lifecycle-Blueprint von 6 auf 5 Phasen mit englischen Phasennamen und vollständiger Harmonisierung der Aktivitäts-IDs. Diese Änderung wurde am 28.01.2026 beschlossen und folgt dem YASM-Prinzip, dass LP2 (Design) und LP3 (Build/Transition) als aufeinanderfolgende, aber zusammengehörige Phasen betrachtet werden.
|
||||
|
||||
---
|
||||
|
||||
### ✨ Neue Phasenstruktur
|
||||
|
||||
| Alt (6 Phasen) | Neu (5 Phasen) | Begründung |
|
||||
|----------------|----------------|------------|
|
||||
| Service Design | **Design** | Englische Benennung |
|
||||
| Service Entwicklung | → **Transition** | Zusammengeführt |
|
||||
| Service Transition | → **Transition** | Zusammengeführt |
|
||||
| Service Betrieb | **Operation** | Englische Benennung |
|
||||
| Service Support | **Support** | Englische Benennung |
|
||||
| Service Review | **Review** | Englische Benennung |
|
||||
|
||||
**Begründung:** Die Trennung zwischen "Entwicklung" (Build) und "Transition" (Deploy) führte zu unnötiger Komplexität. YASM LP3 behandelt beides als eine zusammenhängende Phase.
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Aktivitäts-ID-Mapping
|
||||
|
||||
#### Design (sd_ → ds_)
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| sd_01 | ds_01 | Definieren der erforderlichen Service-Eigenschaften |
|
||||
| sd_02 | ds_02 | Designen der erforderlichen Service- und Service-Management-Komponenten |
|
||||
| sd_03 | ds_03 | Beschreiben des Vorgehens zur Implementierung |
|
||||
| sd_04 | ds_04 | Vorbereiten der Service-Implementierung |
|
||||
| sd_05 | ds_05 | **Gate 1: Entwicklung oder Konfiguration?** |
|
||||
|
||||
#### Transition (se_ + st_ → tr_)
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| se_01 | tr_01 | Koordinieren der Entwicklungs- und Beschaffungsaktivitäten |
|
||||
| se_02 | tr_02 | Entwickeln von Anwendungen und Systemen |
|
||||
| se_03 | tr_03 | Entgegennehmen der Service-Komponenten |
|
||||
| se_04 | tr_04 | Konfiguration der Service-Komponenten |
|
||||
| se_05 | tr_05 | Erstellen oder Aktualisieren der Betriebs-Dokumentation |
|
||||
| se_06 | tr_06 | Testen der Service-Komponenten |
|
||||
| se_07 | tr_07 | Formale Übergabe (Build abgeschlossen) |
|
||||
| (neu) | tr_08 | **Gate 2: Entry-Prüfung nach Build** |
|
||||
| st_02 | tr_09 | Ausrollen der Service-Komponenten |
|
||||
| st_03 | tr_10 | Vorbereiten der Service-Aktivierung |
|
||||
| st_01 | tr_11 | **Gate 3: Go-Live-Freigabe** |
|
||||
|
||||
#### Operation (st_04 + sb_ → op_)
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| st_04 | op_01 | Early Life Support (ELS) |
|
||||
| sb_01 | op_02 | Bereitstellen von Leitlinien für den Service-Betrieb |
|
||||
| sb_02 | op_03 | Durchführen laufender Betriebsaufgaben |
|
||||
| sb_03 | op_04 | Ressourcen, Dienstleister und Budget managen |
|
||||
| sb_04 | op_05 | Überwachen der Services |
|
||||
| sb_05 | op_06 | Erstellen des Service-Qualitätsbericht |
|
||||
| sb_06 | op_07 | Proaktive Problem Identifikation |
|
||||
|
||||
#### Support (ss_ → sp_)
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| ss_01 | sp_01 | Bereitstellen von Leitlinien für den Service-Support |
|
||||
| ss_02 | sp_02 | Wissensdatenbank |
|
||||
| ss_03 | sp_03 | Überwachen / Verteilung von Incidents und Service Requests |
|
||||
| ss_04 | sp_04 | Bearbeiten von Requests |
|
||||
| ss_05 | sp_05 | Lösen von Incidents im 1st Level Support |
|
||||
| ss_06 | sp_06 | Lösen von Incidents im 2nd Level Support |
|
||||
| ss_07 | sp_07 | Incident Record (Gelöst) / Request Record (Gelöst) |
|
||||
| ss_08 | sp_08 | Schließen von Incidents & Service Requests |
|
||||
| ss_09 | sp_09 | Anlegen Problem Record für nicht lösbare Incidents |
|
||||
| ss_10 | sp_10 | Wiederkehrende Incidents analysieren & Problem Record anlegen |
|
||||
| ss_11 | sp_11 | Operative Root-Cause-Analyse durchführen & Workaround bereitstellen |
|
||||
|
||||
#### Review (sr_ → rv_)
|
||||
| Alt | Neu | Name |
|
||||
|-----|-----|------|
|
||||
| sr_01 | rv_01 | Taktische Root-Cause-Analyse + Auswertung Support-KPIs |
|
||||
| sr_02 | rv_02 | Service Performance & Improvement Review |
|
||||
| sr_03 | rv_03 | SOR: Periodischer Service Review |
|
||||
| sr_04 | rv_04 | Service Improvement |
|
||||
| sr_05 | rv_05 | Service Redesign / Erweiterung |
|
||||
| sr_06 | rv_06 | Service außer Betrieb nehmen |
|
||||
|
||||
---
|
||||
|
||||
### 🚪 Gate-Struktur
|
||||
|
||||
Drei durchnummerierte Gates:
|
||||
|
||||
| Gate | ID | Position | Gate-Keeper | Zweck |
|
||||
|------|----|----------|-------------|-------|
|
||||
| **Gate 1** | ds_05 | Ende Design | SOR | Build or Configure Decision |
|
||||
| **Gate 2** | tr_08 | Mitte Transition | SO | Entry-Prüfung nach Build |
|
||||
| **Gate 3** | tr_11 | Ende Transition | SOR | Go-Live-Freigabe |
|
||||
|
||||
**Neu:** Gate 2 (tr_08) wurde als explizite Aktivität formalisiert. Es war zuvor nur im Konzept-Dokument definiert, aber nicht als YAML-Aktivität.
|
||||
|
||||
---
|
||||
|
||||
### 📁 Datei-Änderungen
|
||||
|
||||
#### Neue Dateien
|
||||
| Datei | Beschreibung |
|
||||
|-------|--------------|
|
||||
| `service-lifecycle_design.yaml` | Design-Phase (ds_01 – ds_05) |
|
||||
| `service-lifecycle_transition.yaml` | Transition-Phase (tr_01 – tr_11) |
|
||||
| `service-lifecycle_operation.yaml` | Operation-Phase (op_01 – op_07) |
|
||||
| `service-lifecycle_support.yaml` | Support-Phase (sp_01 – sp_11) |
|
||||
| `service-lifecycle_review.yaml` | Review-Phase (rv_01 – rv_06) |
|
||||
|
||||
#### Gelöschte Dateien
|
||||
| Datei | Ersetzt durch |
|
||||
|-------|---------------|
|
||||
| `service-lifecycle_service-design.yaml` | `service-lifecycle_design.yaml` |
|
||||
| `service-lifecycle_service-entwicklung.yaml` | `service-lifecycle_transition.yaml` |
|
||||
| `service-lifecycle_service-transition.yaml` | `service-lifecycle_transition.yaml` |
|
||||
| `service-lifecycle_service-betrieb.yaml` | `service-lifecycle_operation.yaml` |
|
||||
| `service-lifecycle_service-support.yaml` | `service-lifecycle_support.yaml` |
|
||||
| `service-lifecycle_service-review.yaml` | `service-lifecycle_review.yaml` |
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Wichtige Änderungen
|
||||
|
||||
#### 1. Early Life Support (ELS) verschoben
|
||||
- **Alt:** st_04 in Phase "Service Transition"
|
||||
- **Neu:** op_01 in Phase "Operation"
|
||||
- **Begründung:** Nach Go-Live ist der Service faktisch im Betrieb. ELS ist Betrieb mit erhöhter Aufmerksamkeit, nicht mehr Projektverantwortung.
|
||||
|
||||
#### 2. Gate 2 formalisiert
|
||||
- **Alt:** Nur im Konzeptdokument beschrieben
|
||||
- **Neu:** Explizite Aktivität tr_08 mit vollständiger RACI-Definition
|
||||
- **Gate-Keeper:** Service Owner (SO) – Einzelentscheidung
|
||||
|
||||
#### 3. Aktivitäts-ID-Präfixe harmonisiert
|
||||
- Design: ds_ (nicht mehr sd_, da "Design" der englische Begriff ist)
|
||||
- Transition: tr_ (konsolidiert aus se_ und st_)
|
||||
- Operation: op_ (nicht mehr sb_)
|
||||
- Support: sp_ (nicht mehr ss_)
|
||||
- Review: rv_ (nicht mehr sr_)
|
||||
|
||||
---
|
||||
|
||||
### 📝 Folgeänderungen erforderlich
|
||||
|
||||
Die folgenden Dateien müssen noch aktualisiert werden, um die neuen Aktivitäts-IDs zu verwenden:
|
||||
|
||||
| Datei | Änderungsbedarf |
|
||||
|-------|-----------------|
|
||||
| `spm_konzept_service-transition.yaml` | Alle Verweise auf sd_, se_, st_ → ds_, tr_, op_ |
|
||||
| `spm_schema_transition-steckbrief.yaml` | Aktivitäts-ID-Referenzen |
|
||||
| `demand-lifecycle-blueprint_phase-4.yaml` | Trigger-Referenz prüfen |
|
||||
| `spm_practice_service-catalog-management.yaml` | Lifecycle-Phasen-Referenzen |
|
||||
| `spm_practice_service-level-management.yaml` | Lifecycle-Phasen-Referenzen |
|
||||
| `spm_sor_go.yaml` | Gate-Referenzen |
|
||||
|
||||
---
|
||||
|
||||
### 👥 Beteiligte
|
||||
|
||||
- **Beschluss:** 28. Januar 2026
|
||||
- **Umsetzung:** 30. Januar 2026
|
||||
- **Autor:** DIGITOM-Projekt
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Version 2.0 - YASM Alignment Update (22. Januar 2026)
|
||||
|
||||
### 🎯 Übersicht
|
||||
|
||||
Vollständige Umstrukturierung des Service-Lifecycle-Blueprint nach dem **YASM (Yet Another Service Management Model)** Framework. Die bisherige Phase "Service Entwicklung" wurde in zwei separate Phasen aufgeteilt, um die Trennung von Design und Implementierung klarzustellen.
|
||||
|
||||
**Status:** Überholt durch Version 3.0 (5-Phasen-Konsolidierung)
|
||||
|
||||
---
|
||||
|
||||
## Version 1.0 - Initial Release (26. November 2025)
|
||||
|
||||
### Initiale Veröffentlichung
|
||||
- Service Entwicklung (SE_01-SE_12)
|
||||
- Service Transition (ST_01-ST_04)
|
||||
- Service Betrieb (SB_01-SB_06)
|
||||
- Service Support (SS_01-SS_11)
|
||||
- Service Review (SR_01-SR_06)
|
||||
|
||||
**Status:** Überholt durch Version 2.0 (YASM Alignment)
|
||||
|
|
@ -0,0 +1,182 @@
|
|||
# Service-Lifecycle-Blueprint
|
||||
|
||||
## Überblick
|
||||
|
||||
Der Service-Lifecycle-Blueprint beschreibt den vollständigen Lebenszyklus eines Services von der initialen Gestaltung bis zur Stilllegung. Er definiert Phasen, Aktivitäten, Gates und Verantwortlichkeiten für die strukturierte Steuerung von Services im DIGITOM-Framework.
|
||||
|
||||
**Version:** 3.2
|
||||
**Stand:** 2026-02-18
|
||||
**Status:** Draft
|
||||
|
||||
---
|
||||
|
||||
## 5-Phasen-Modell
|
||||
|
||||
Der Service-Lifecycle besteht aus fünf Phasen mit englischen Bezeichnungen:
|
||||
|
||||
```
|
||||
┌─────────┐ ┌────────────┐ ┌───────────┐ ┌─────────┐ ┌────────┐
|
||||
│ Design │───▶│ Transition │───▶│ Operation │◀──▶│ Support │───▶│ Review │
|
||||
└─────────┘ └────────────┘ └───────────┘ └─────────┘ └────────┘
|
||||
│ │ │ │ │
|
||||
Gate 1 Gate 2 Gate 3 ELS Decisions
|
||||
```
|
||||
|
||||
| Phase | Beschreibung | YASM-Referenz |
|
||||
|-------|--------------|---------------|
|
||||
| **Design** | Strategische und architektonische Gestaltung | LP2: Design new or changed services |
|
||||
| **Transition** | Build/Konfiguration, Test, Deployment, Go-Live | LP3: Build new or changed services |
|
||||
| **Operation** | Laufender Betrieb inkl. Early Life Support | LP4.1-LP4.5: Operate the services |
|
||||
| **Support** | Incident/Request-Bearbeitung, Problem Management | LP4.6-LP4.7: Operate the services |
|
||||
| **Review** | Periodische Bewertung, Improvement, Retirement | LP5: Improve the services |
|
||||
|
||||
---
|
||||
|
||||
## Gate-Struktur
|
||||
|
||||
Drei durchnummerierte Gates steuern die Übergänge zwischen den Phasen:
|
||||
|
||||
| Gate | ID | Position | Gate-Keeper | Zweck |
|
||||
|------|----|----------|-------------|-------|
|
||||
| **Gate 1** | tr_01 | Anfang Transition (Entry-Gate) | SOR | Build or Configure Decision |
|
||||
| **Gate 2** | tr_09 | Mitte Transition (nach Build) | SO | Entry-Prüfung nach Build |
|
||||
| **Gate 3** | tr_12 | Ende Transition | SOR | Go-Live-Freigabe → Operation |
|
||||
|
||||
### Gate 1: Build or Configure Decision (tr_01)
|
||||
- **Position:** Entry-Gate der Transition-Phase (nach Design ds_04)
|
||||
- **Gate-Keeper:** Service Owner Runde (SOR)
|
||||
- **Entscheidungspfade:**
|
||||
- *Entwicklung:* → tr_02 (voller Build-Zyklus)
|
||||
- *Konfiguration:* → tr_05 (überspringt Build, direkt Konfiguration)
|
||||
|
||||
### Gate 2: Entry-Prüfung nach Build (tr_09)
|
||||
- **Position:** Nach Build-Abschluss (tr_08), vor Deploy
|
||||
- **Gate-Keeper:** Service Owner (SO) – Einzelentscheidung
|
||||
- **Entscheidungspfade:**
|
||||
- *Freigabe:* → tr_10 (Deploy)
|
||||
- *Freigabe mit Auflagen:* → tr_10 (Deploy mit Nacharbeiten)
|
||||
- *Zurück an Build:* → tr_02 oder passende Build-Aktivität
|
||||
- *Ablehnung:* → SOR-Eskalation
|
||||
|
||||
### Gate 3: Go-Live-Freigabe (tr_12)
|
||||
- **Position:** Exit Transition → Entry Operation
|
||||
- **Gate-Keeper:** Service Owner Runde (SOR)
|
||||
- **Entscheidungspfade:**
|
||||
- *Go-Live:* → op_01 (Early Life Support)
|
||||
- *Go-Live mit Auflagen:* → op_01 (mit definierten Nacharbeiten)
|
||||
- *Zurück:* → tr_10 oder passende Deploy-Aktivität
|
||||
- *Ablehnung:* → Service-Vorhaben wird beendet
|
||||
|
||||
---
|
||||
|
||||
## Aktivitäts-IDs
|
||||
|
||||
Jede Phase verwendet ein eindeutiges Präfix für ihre Aktivitäten:
|
||||
|
||||
| Phase | Präfix | Beispiel |
|
||||
|-------|--------|----------|
|
||||
| Design | ds_ | ds_01, ds_02, ... ds_04 |
|
||||
| Transition | tr_ | tr_01, tr_02, ... tr_12 |
|
||||
| Operation | op_ | op_01, op_02, ... op_07 |
|
||||
| Support | sp_ | sp_01, sp_02, ... sp_11 |
|
||||
| Review | rv_ | rv_01, rv_02, ... rv_06 |
|
||||
|
||||
---
|
||||
|
||||
## Aktivitäten pro Phase
|
||||
|
||||
### Design (ds_01 – ds_04)
|
||||
| ID | Name | Typ |
|
||||
|----|------|-----|
|
||||
| ds_01 | Definieren der erforderlichen Service-Eigenschaften | Aktivität |
|
||||
| ds_02 | Designen der erforderlichen Service- und Service-Management-Komponenten | Aktivität |
|
||||
| ds_03 | Beschreiben des Vorgehens zur Implementierung | Aktivität |
|
||||
| ds_04 | Vorbereiten der Service-Implementierung | Aktivität |
|
||||
|
||||
### Transition (tr_01 – tr_12)
|
||||
| ID | Name | Typ |
|
||||
|----|------|-----|
|
||||
| tr_01 | **Gate 1: Entwicklung oder Konfiguration?** | Gate |
|
||||
| tr_02 | Koordinieren der Entwicklungs- und Beschaffungsaktivitäten | Aktivität |
|
||||
| tr_03 | Entwickeln von Anwendungen und Systemen | Aktivität |
|
||||
| tr_04 | Entgegennehmen der Service-Komponenten | Aktivität |
|
||||
| tr_05 | Konfiguration der Service-Komponenten | Aktivität |
|
||||
| tr_06 | Erstellen oder Aktualisieren der Betriebs-Dokumentation | Aktivität |
|
||||
| tr_07 | Testen der Service-Komponenten | Aktivität |
|
||||
| tr_08 | Formale Übergabe (Build abgeschlossen) | Aktivität |
|
||||
| tr_09 | **Gate 2: Entry-Prüfung nach Build** | Gate |
|
||||
| tr_10 | Ausrollen der Service-Komponenten | Aktivität |
|
||||
| tr_11 | Vorbereiten der Service-Aktivierung | Aktivität |
|
||||
| tr_12 | **Gate 3: Go-Live-Freigabe** | Gate |
|
||||
|
||||
### Operation (op_01 – op_07)
|
||||
| ID | Name | Typ |
|
||||
|----|------|-----|
|
||||
| op_01 | Early Life Support (ELS) | Aktivität |
|
||||
| op_02 | Bereitstellen von Leitlinien für den Service-Betrieb | Aktivität |
|
||||
| op_03 | Durchführen laufender Betriebsaufgaben | Aktivität |
|
||||
| op_04 | Ressourcen, Dienstleister und Budget managen | Aktivität |
|
||||
| op_05 | Überwachen der Services | Aktivität |
|
||||
| op_06 | Erstellen des Service-Qualitätsbericht | Aktivität |
|
||||
| op_07 | Proaktive Problem Identifikation | Aktivität |
|
||||
|
||||
### Support (sp_01 – sp_11)
|
||||
| ID | Name | Typ |
|
||||
|----|------|-----|
|
||||
| sp_01 | Bereitstellen von Leitlinien für den Service-Support | Aktivität |
|
||||
| sp_02 | Wissensdatenbank | Aktivität |
|
||||
| sp_03 | Überwachen / Verteilung von Incidents und Service Requests | Aktivität |
|
||||
| sp_04 | Bearbeiten von Requests | Aktivität |
|
||||
| sp_05 | Lösen von Incidents im 1st Level Support | Aktivität |
|
||||
| sp_06 | Lösen von Incidents im 2nd Level Support | Aktivität |
|
||||
| sp_07 | Incident Record (Gelöst) / Request Record (Gelöst) | Aktivität |
|
||||
| sp_08 | Schließen von Incidents & Service Requests | Aktivität |
|
||||
| sp_09 | Anlegen Problem Record für nicht lösbare Incidents | Aktivität |
|
||||
| sp_10 | Wiederkehrende Incidents analysieren & Problem Record anlegen | Aktivität |
|
||||
| sp_11 | Operative Root-Cause-Analyse durchführen & Workaround bereitstellen | Aktivität |
|
||||
|
||||
### Review (rv_01 – rv_06)
|
||||
| ID | Name | Typ |
|
||||
|----|------|-----|
|
||||
| rv_01 | Taktische Root-Cause-Analyse + Auswertung Support-KPIs | Aktivität |
|
||||
| rv_02 | Service Performance & Improvement Review | Aktivität |
|
||||
| rv_03 | SOR: Periodischer Service Review | Aktivität |
|
||||
| rv_04 | Service Improvement | Aktivität |
|
||||
| rv_05 | Service Redesign / Erweiterung | Aktivität |
|
||||
| rv_06 | Service außer Betrieb nehmen | Aktivität |
|
||||
|
||||
---
|
||||
|
||||
## Schnittstellen
|
||||
|
||||
### Eingang (aus Demand-Lifecycle)
|
||||
- **Trigger:** Freigabe in DPM Phase 4 (nach DSR/MB Genehmigung)
|
||||
- **Artefakt:** Projektauftrag mit benannter Projektleitung
|
||||
- **Einstieg:** Design-Phase (ds_01)
|
||||
|
||||
### Ausgang (zurück zu Demand-Lifecycle)
|
||||
- **Service Redesign:** Strukturelle Änderung als neuer Demand (rv_05)
|
||||
- **Service Retirement:** Stilllegung als Demand/Projekt (rv_06)
|
||||
|
||||
---
|
||||
|
||||
## Dateien in diesem Verzeichnis
|
||||
|
||||
| Datei | Beschreibung |
|
||||
|-------|--------------|
|
||||
| `service-lifecycle_design.yaml` | Design-Phase (ds_01 – ds_04) |
|
||||
| `service-lifecycle_transition.yaml` | Transition-Phase (tr_01 – tr_12, inkl. alle 3 Gates) |
|
||||
| `service-lifecycle_operation.yaml` | Operation-Phase (op_01 – op_07) |
|
||||
| `service-lifecycle_support.yaml` | Support-Phase (sp_01 – sp_11) |
|
||||
| `service-lifecycle_review.yaml` | Review-Phase (rv_01 – rv_06) |
|
||||
| `readme_service-lifecycle-blueprint.md` | Diese Datei |
|
||||
| `CHANGELOG_service-lifecycle-blueprint.md` | Änderungshistorie |
|
||||
|
||||
---
|
||||
|
||||
## Weiterführende Dokumente
|
||||
|
||||
- **Konzept Service-Transition:** `02a_lifecycle-konzepte/spm_konzept_service-transition.yaml`
|
||||
- **Konzept Service-Review:** `02a_lifecycle-konzepte/spm_konzept_service-review.yaml`
|
||||
- **Governance-Entscheidungen:** `02b_governance/spm_sor_go.yaml`
|
||||
- **Demand-Lifecycle-Blueprint:** `#01_demand-portfolio-management/`
|
||||
|
|
@ -29,7 +29,7 @@ metadata:
|
|||
eingang:
|
||||
- quelle: "Transition"
|
||||
artefakt: "Aktivierter Service"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_11)"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_12)"
|
||||
ausgang:
|
||||
- ziel: "Support"
|
||||
artefakt: "Alarme, Events, Betriebsinformationen"
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ metadata:
|
|||
eingang:
|
||||
- quelle: "Transition"
|
||||
artefakt: "Aktivierter Service"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_11)"
|
||||
trigger: "SOR-Freigabe an Gate 3 (tr_12)"
|
||||
- quelle: "Nutzer/Anwender"
|
||||
artefakt: "Incidents, Service Requests"
|
||||
- quelle: "Operation"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,553 @@
|
|||
# =============================================================================
|
||||
# SYNTHESE: ANALYSE-GRUNDLAGEN SERVICE-SUPPORT-MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
id: "SSM-SYNTHESE"
|
||||
name: "Synthese Analyse-Grundlagen"
|
||||
version: "1.0"
|
||||
status: "validiert"
|
||||
erstellt: "2025-12-07"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: >
|
||||
Konsolidierte Synthese aus drei Analyse-Perspektiven als Grundlage
|
||||
für die Entwicklung des Service-Support-Management Konzepts.
|
||||
|
||||
quellen:
|
||||
- name: "Ticket-Analyse"
|
||||
typ: "quantitativ"
|
||||
umfang: "2.000 geschlossene Tickets"
|
||||
fokus: "Kennzahlen-Baseline, Klassifikationsprobleme"
|
||||
|
||||
- name: "Schnittstellen-Analyse"
|
||||
typ: "qualitativ-extern"
|
||||
umfang: "7 Interviews mit Schnittstellenpartnern"
|
||||
fokus: "Wahrnehmung, Prozesslücken, Erfolgsmodelle"
|
||||
|
||||
- name: "Team-Analyse"
|
||||
typ: "qualitativ-intern"
|
||||
umfang: "5 Interviews mit Teammitgliedern"
|
||||
fokus: "Paradoxien, Kultur, Teamdynamik"
|
||||
|
||||
# =============================================================================
|
||||
# KONVERGENTE KERNBEFUNDE
|
||||
# =============================================================================
|
||||
|
||||
konvergente_kernbefunde:
|
||||
|
||||
beschreibung: >
|
||||
Acht zentrale Problembereiche, die von allen drei Perspektiven
|
||||
unabhängig bestätigt werden. Hohe Validität durch Triangulation.
|
||||
|
||||
befunde:
|
||||
|
||||
- id: KB-01
|
||||
name: "Kritischer Erstlösungsdefizit"
|
||||
schweregrad: "kritisch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "FCR unter 10% (Proxy-Berechnung)"
|
||||
schnittstellen: "Ursprüngliches Ziel First-Level-Lösungs-Service Desk aufgegeben"
|
||||
team: "Empowerment-Gap - fehlende Berechtigungen und Tools"
|
||||
|
||||
konsequenzen:
|
||||
- "Ticket-Ping-Pong zwischen Abteilungen"
|
||||
- "Mehrfachkontakte für einfache Anfragen"
|
||||
- "Kapazitätsbindung auf beiden Levels"
|
||||
|
||||
design_implikation: >
|
||||
Empowerment First Level durch Berechtigungserweiterung UND
|
||||
Prozessklarheit ist Voraussetzung für FCR-Verbesserung.
|
||||
|
||||
- id: KB-02
|
||||
name: "SLA-Vakuum als Steuerungsblockade"
|
||||
schweregrad: "kritisch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "SLA-Spalte vorhanden aber ungepflegt"
|
||||
schnittstellen: "Existierende Dokumente als 'veraltet' ohne 'rechtliche Bindung'"
|
||||
team: "Fehlende Grundlage für Priorisierung und Eskalation"
|
||||
|
||||
konsequenzen:
|
||||
- "Kein objektiver Maßstab für Performance"
|
||||
- "Keine legitime Eskalationsbasis"
|
||||
- "Keine Differenzierung kritisch vs. trivial"
|
||||
|
||||
design_implikation: >
|
||||
SLA-Rahmenstruktur ist Grundvoraussetzung für jede Form
|
||||
von Service-Steuerung. Mindestens interne Zielwerte erforderlich.
|
||||
|
||||
- id: KB-03
|
||||
name: "Prozessdefinitions-Vakuum"
|
||||
schweregrad: "kritisch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Impact-Urgency-Matrix fehlt vollständig"
|
||||
schnittstellen: "Unterscheidung Incident/Request 'prozessual null geklärt'"
|
||||
team: "Standards bestenfalls 'mündlich' definiert"
|
||||
|
||||
konsequenzen:
|
||||
- "Prozess-Pragmatismus-Lücke"
|
||||
- "Ad-hoc-Entscheidungen statt Regeln"
|
||||
- "Abhängigkeit von 'Heldentum' einzelner"
|
||||
|
||||
design_implikation: >
|
||||
Verbindliche Prozessdefinitionen mit Entscheidungsbäumen.
|
||||
Das Konzept muss die "mündlichen Standards" formalisieren.
|
||||
|
||||
- id: KB-04
|
||||
name: "Ticket-Qualitätsdefizit"
|
||||
schweregrad: "hoch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Unvollständige Informationen, fehlende CI-Verknüpfungen"
|
||||
schnittstellen: "70% Rückfragequote"
|
||||
team: "E-Mail-Bypass umgeht Formulare systematisch"
|
||||
|
||||
konsequenzen:
|
||||
- "Massiver Nachqualifizierungsaufwand"
|
||||
- "Verzögerte Bearbeitung"
|
||||
- "Frustration auf allen Seiten"
|
||||
|
||||
erfolgsmodell:
|
||||
bereich: "Webservices / Endgeräte"
|
||||
massnahme: "Pflichtfelder in Formularen"
|
||||
ergebnis: "Rückfragequote unter 1%"
|
||||
|
||||
design_implikation: >
|
||||
Definition of Ready (DoR) mit Pflichtfeldern.
|
||||
Erfolgsmodell Webservices muss skaliert werden.
|
||||
|
||||
- id: KB-05
|
||||
name: "Problem Management als strukturelle Lücke"
|
||||
schweregrad: "hoch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Konkrete Problem-Kandidaten identifiziert"
|
||||
schnittstellen: "Rein reaktive Symptombehandlung"
|
||||
team: "Keine Ursachenanalyse"
|
||||
|
||||
problem_kandidaten:
|
||||
- "Outlook-Konfigurationsänderungen (wiederkehrend)"
|
||||
- "Jabber-Anmeldefehler"
|
||||
- "Enaio-Workflow-Probleme"
|
||||
- "SAP-Performance-Beschwerden"
|
||||
|
||||
konsequenzen:
|
||||
- "Wiederholte Bearbeitung gleicher Symptome"
|
||||
- "Keine Eskalation struktureller Probleme an Service Owner"
|
||||
- "Verschwendete Kapazität"
|
||||
|
||||
design_implikation: >
|
||||
Problem-Management-Grundprozess mit klaren Kriterien
|
||||
für Problem-Record-Erstellung bei wiederkehrenden Incidents.
|
||||
|
||||
- id: KB-06
|
||||
name: "Wissensmanagement-Dysfunktion"
|
||||
schweregrad: "hoch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Fehlende Wissensdatenbank-Nutzung"
|
||||
schnittstellen: "Wissensvernichtung - 'wird eh nicht gelesen'"
|
||||
team: "'FAQ Urwald' ohne Governance"
|
||||
|
||||
teufelskreis:
|
||||
- "Second Level erstellt keine Anleitungen mehr"
|
||||
- "Weil sie 'eh nicht genutzt werden'"
|
||||
- "First Level findet nichts Brauchbares"
|
||||
- "Und fragt direkt nach"
|
||||
- "Was Second Level frustriert"
|
||||
|
||||
governance_problem: "Jeder kann ändern ohne Freigabe oder Nachverfolgung"
|
||||
|
||||
design_implikation: >
|
||||
3-Schichten-Wissensmodell mit klarer redaktioneller
|
||||
Verantwortung und Freigabeprozess.
|
||||
|
||||
- id: KB-07
|
||||
name: "L1/L2-Grenzziehungs-Vakuum"
|
||||
schweregrad: "hoch"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Identische Workflows für Incidents und Requests"
|
||||
schnittstellen: "Ständige Zuständigkeitskonflikte"
|
||||
team: "Offene Fragen bei Benutzeranlagen, AD, Berechtigungen"
|
||||
|
||||
ungeklaerte_zuordnungen:
|
||||
- "Benutzeranlagen"
|
||||
- "Active Directory Änderungen"
|
||||
- "SharedMailbox-Berechtigungen"
|
||||
- "Standard-Software-Installation"
|
||||
|
||||
design_implikation: >
|
||||
Verbindliche Scope-Definition mit expliziter Aufgaben-,
|
||||
Rechte- und Berechtigungszuordnung pro Level.
|
||||
|
||||
- id: KB-08
|
||||
name: "Change-Kommunikationsdefizit"
|
||||
schweregrad: "mittel"
|
||||
|
||||
evidenz:
|
||||
ticket_analyse: "Massiver Ticket-Spike Q1/2025"
|
||||
schnittstellen: "Fehlendes Change Advisory Board"
|
||||
team: "Service Desk als 'überraschtes Opfer des Wandels'"
|
||||
|
||||
beispiel:
|
||||
ereignis: "Passwortwechsel vor Weihnachten"
|
||||
problem: "Keine Impact-Bewertung, keine Vorbereitung Support"
|
||||
|
||||
konsequenzen:
|
||||
- "Service Desk erfährt von Rollouts durch frustrierte Kunden"
|
||||
- "Keine Schulung, keine FAQs vorbereitet"
|
||||
- "Kompetenz und Glaubwürdigkeit untergraben"
|
||||
|
||||
design_implikation: >
|
||||
Formale Change-Kommunikations-Schnittstelle.
|
||||
Service Desk muss in Change-Planung eingebunden sein.
|
||||
|
||||
# =============================================================================
|
||||
# SPANNUNGSFELDER
|
||||
# =============================================================================
|
||||
|
||||
spannungsfelder:
|
||||
|
||||
beschreibung: >
|
||||
Divergente Perspektiven, die nicht auf Widersprüche hinweisen,
|
||||
sondern auf unterschiedliche Kausalattributionen verweisen.
|
||||
|
||||
felder:
|
||||
|
||||
- id: SF-01
|
||||
name: "Technische Lösung vs. Befähigungsproblem"
|
||||
|
||||
perspektiven:
|
||||
ticket_schnittstellen: "Automatisierungspotenzial als Lösungsweg"
|
||||
team: "Fundamentaler Empowerment-Gap - fehlende Berechtigungen"
|
||||
|
||||
synthese: >
|
||||
Automatisierung adressiert Symptome, nicht strukturelle Ursache.
|
||||
Beide Perspektiven sind valide und komplementär.
|
||||
|
||||
design_implikation: >
|
||||
Automatisierung ist notwendig, aber nicht hinreichend.
|
||||
Parallel muss Berechtigungsmodell für L1 erweitert werden.
|
||||
|
||||
- id: SF-02
|
||||
name: "Prozessdefizit vs. Kulturdefizit vs. Strukturdefizit"
|
||||
|
||||
perspektiven:
|
||||
ticket_analyse: "Primär Prozess- und Tool-Defizite"
|
||||
schnittstellen: "Zusätzlich Kompetenzdefizite"
|
||||
team: "Strukturelle und motivationale Ursachen (Status, Karriere, Bezahlung)"
|
||||
|
||||
paradoxon:
|
||||
name: "Verantwortungs-Status-Paradoxon"
|
||||
beschreibung: "Kritische Funktion bei niedrigem organisationalem Status"
|
||||
zitat: "Warum soll ich für meinen Lohn ihre Arbeit mitmachen?"
|
||||
|
||||
synthese: >
|
||||
Drei konkurrierende Erklärungsebenen - Prozess, Kultur, Struktur.
|
||||
Ein robustes Konzept muss alle drei adressieren.
|
||||
|
||||
design_implikation: >
|
||||
Konzept adressiert Prozesse direkt. Governance-Empfehlungen
|
||||
müssen explizit auf strukturelle Voraussetzungen hinweisen.
|
||||
|
||||
ausserhalb_scope:
|
||||
- "Vergütungsstruktur"
|
||||
- "Karrierepfade"
|
||||
- "Organisatorischer Status"
|
||||
|
||||
- id: SF-03
|
||||
name: "Außen- vs. Innenperspektive auf Qualität"
|
||||
|
||||
perspektiven:
|
||||
schnittstellen: "Vernichtendes Bild ('Chaos', Reputationsverfall)"
|
||||
team: "Differenziert: Leistungsträger vs. Leistungsverweigerer, externe Faktoren"
|
||||
|
||||
synthese: >
|
||||
Externe Wahrnehmung ist real und handlungsrelevant.
|
||||
Interne Differenzierung erklärt Ursachen, entschuldigt nicht.
|
||||
|
||||
design_implikation: >
|
||||
Quick Wins für Vertrauenswiederherstellung erforderlich.
|
||||
Konzept muss Leistungsgefälle adressierbar machen ohne Cherry-Picking.
|
||||
|
||||
- id: SF-04
|
||||
name: "Messbarkeit vs. Messbarkeits-Risiken"
|
||||
|
||||
perspektiven:
|
||||
alle_quellen: "Fordern Kennzahlen und SLAs"
|
||||
team: "Warnt vor individueller Leistungsmessung (verstärkt Cherry-Picking)"
|
||||
ticket_analyse: "Massive Datenqualitätsprobleme (Langläufer verzerren MTTR)"
|
||||
|
||||
synthese: >
|
||||
Messung ist notwendig, aber Design der Metriken entscheidend.
|
||||
Falsche Metriken verstärken Dysfunktionen.
|
||||
|
||||
design_implikation: >
|
||||
Team-Ziele priorisieren, nicht individuelle Ticketzahlen.
|
||||
Datenbereinigung ist Voraussetzung für valide Steuerung.
|
||||
|
||||
# =============================================================================
|
||||
# DESIGN-ANFORDERUNGEN (PRIORISIERT)
|
||||
# =============================================================================
|
||||
|
||||
design_anforderungen:
|
||||
|
||||
must_have:
|
||||
beschreibung: "Im Konzept zwingend zu adressieren"
|
||||
|
||||
anforderungen:
|
||||
- id: DA-MH-01
|
||||
name: "Priorisierungs-Framework"
|
||||
beschreibung: "Impact-Urgency-Matrix mit definierten Kriterien"
|
||||
begruendung: "Ohne Priorisierung keine SLA-Steuerung, keine Eskalationslogik"
|
||||
adressiert_befunde: ["KB-02", "KB-03"]
|
||||
|
||||
- id: DA-MH-02
|
||||
name: "Ticket-Klassifikations-Logik"
|
||||
beschreibung: "Verbindliche Unterscheidung Incident/Request/Projekt mit Entscheidungsbaum"
|
||||
begruendung: "Aktuelle Vermischung macht alle Metriken unbrauchbar"
|
||||
adressiert_befunde: ["KB-03", "KB-04"]
|
||||
|
||||
- id: DA-MH-03
|
||||
name: "Definition of Ready (DoR)"
|
||||
beschreibung: "Pflichtinformationen je Ticket-Kategorie"
|
||||
begruendung: "Erfolgsmodell Webservices muss skaliert werden"
|
||||
adressiert_befunde: ["KB-04"]
|
||||
referenz_erfolgsmodell: "Webservices/Endgeräte: Rückfragequote <1%"
|
||||
|
||||
- id: DA-MH-04
|
||||
name: "L1/L2-Scope-Definition"
|
||||
beschreibung: "Verbindliche Zuordnung von Aufgaben, Rechten, Berechtigungen"
|
||||
begruendung: "Ohne Definition bleibt Ping-Pong systemimmanent"
|
||||
adressiert_befunde: ["KB-01", "KB-07"]
|
||||
|
||||
- id: DA-MH-05
|
||||
name: "SLA-Rahmenstruktur"
|
||||
beschreibung: "Mindestens Zielwerte für Reaktions- und Lösungszeit je Priorität"
|
||||
begruendung: "Messbare Commitments als Steuerungsgrundlage"
|
||||
adressiert_befunde: ["KB-02"]
|
||||
|
||||
- id: DA-MH-06
|
||||
name: "Eskalationsmatrix"
|
||||
beschreibung: "Kriterien und Pfade für funktionale und hierarchische Eskalation"
|
||||
begruendung: "Aktuelle Eskalation rein informell ('Goodwill')"
|
||||
adressiert_befunde: ["KB-02", "KB-07"]
|
||||
|
||||
should_have:
|
||||
beschreibung: "Empfohlen für vollständiges Konzept"
|
||||
|
||||
anforderungen:
|
||||
- id: DA-SH-01
|
||||
name: "Problem-Management-Grundprozess"
|
||||
beschreibung: "Kriterien für Problem-Record-Erstellung bei wiederkehrenden Incidents"
|
||||
begruendung: "Identifizierte Problem-Kandidaten erfordern systematische Bearbeitung"
|
||||
adressiert_befunde: ["KB-05"]
|
||||
vorschlag_schwelle: "3 gleichartige Incidents in 30 Tagen"
|
||||
|
||||
- id: DA-SH-02
|
||||
name: "Wissensdatenbank-Governance"
|
||||
beschreibung: "Redaktionelle Verantwortung, Freigabeprozess, Pflegezyklus"
|
||||
begruendung: "Ohne Governance bleibt FAQ-Urwald bestehen"
|
||||
adressiert_befunde: ["KB-06"]
|
||||
|
||||
- id: DA-SH-03
|
||||
name: "Change-Kommunikations-Schnittstelle"
|
||||
beschreibung: "Formale Einbindung Service Desk in Change-Planung"
|
||||
begruendung: "Ticket-Spike Q1/2025 war vermeidbar"
|
||||
adressiert_befunde: ["KB-08"]
|
||||
|
||||
- id: DA-SH-04
|
||||
name: "Ticket-Qualitäts-Messung"
|
||||
beschreibung: "Definition und Tracking eines Ticket Quality Score"
|
||||
begruendung: "Basis für kontinuierliche Verbesserung"
|
||||
adressiert_befunde: ["KB-04"]
|
||||
|
||||
- id: DA-SH-05
|
||||
name: "Self-Service-Strategie"
|
||||
beschreibung: "Roadmap für Top-5-Automatisierungskandidaten"
|
||||
begruendung: "Entlastung First Level, Verbesserung Nutzererfahrung"
|
||||
kandidaten:
|
||||
- "Passwort-Reset"
|
||||
- "Software-Verteilung"
|
||||
- "Berechtigungsworkflows"
|
||||
- "Account-Entsperrung"
|
||||
- "Standard-Hardware-Anforderung"
|
||||
|
||||
nice_to_have:
|
||||
beschreibung: "Optional oder für Folgephase"
|
||||
|
||||
anforderungen:
|
||||
- id: DA-NH-01
|
||||
name: "Automatisierte Ticket-Zuweisung"
|
||||
beschreibung: "Ausweitung Webservices-Modell (Formulare + Filter)"
|
||||
|
||||
- id: DA-NH-02
|
||||
name: "Proaktives Monitoring"
|
||||
beschreibung: "Frühwarnsystem für Service-Probleme vor Ticket-Eingang"
|
||||
|
||||
- id: DA-NH-03
|
||||
name: "Kundenzufriedenheits-Messung"
|
||||
beschreibung: "Systematische Erhebung als Steuerungsindikator"
|
||||
|
||||
- id: DA-NH-04
|
||||
name: "Onboarding-Programm Service Desk"
|
||||
beschreibung: "Strukturierte Einarbeitung statt Learning by Chaos"
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-ENTSCHEIDUNGEN (VORGESCHLAGEN)
|
||||
# =============================================================================
|
||||
|
||||
governance_entscheidungen_vorschlag:
|
||||
|
||||
beschreibung: >
|
||||
Vorgeschlagene Governance-Entscheidungen basierend auf der Analyse.
|
||||
Nach Validierung in zentrales Log übertragen.
|
||||
|
||||
ziel_log: "../spm_governance-entscheidungen-log.yaml"
|
||||
|
||||
entscheidungen:
|
||||
|
||||
- id: "SSM-G-01"
|
||||
name: "Mission Service Desk"
|
||||
entscheidung: >
|
||||
Primär Störungsbearbeitung (Incident) mit sekundärer
|
||||
Auftragsentgegennahme (Request). Keine Projektbearbeitung im Ticketsystem.
|
||||
begruendung: >
|
||||
Aktuelle Vermischung macht Metriken unbrauchbar.
|
||||
Strategische Klärung ist Voraussetzung für Prozessdesign.
|
||||
quellen: ["Ticket", "Schnittstellen", "Team"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-02"
|
||||
name: "Priorisierungs-Autorität"
|
||||
entscheidung: >
|
||||
Service Desk priorisiert nach Matrix, Eskalation an Teamleitung bei Widerspruch.
|
||||
Kunden können Dringlichkeit melden, nicht Priorität festlegen.
|
||||
begruendung: >
|
||||
Aktuelle "4 low"-Monokultur verhindert Triage.
|
||||
Priorisierung muss regelbasiert sein, nicht verhandelbar.
|
||||
quellen: ["Ticket", "Team"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-03"
|
||||
name: "Ticket-Pflicht-Prinzip"
|
||||
entscheidung: >
|
||||
"Ohne Ticket kein Auftrag" wird technisch durchgesetzt.
|
||||
E-Mail-Tickets erhalten Auto-Responder mit Pflichtfeld-Abfrage.
|
||||
begruendung: >
|
||||
Regel existiert, wird nicht durchgesetzt.
|
||||
Technische Durchsetzung statt Appelle.
|
||||
quellen: ["Schnittstellen", "Team"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-04"
|
||||
name: "DoR-Verbindlichkeit"
|
||||
entscheidung: >
|
||||
Tickets ohne Mindestinformationen werden an Melder zurückgewiesen.
|
||||
L2 darf unvollständige Tickets ablehnen.
|
||||
begruendung: >
|
||||
70% Rückfragequote ist systemischer Kapazitätsfresser.
|
||||
DoR muss konsequent angewandt werden.
|
||||
quellen: ["Schnittstellen", "Ticket"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-05"
|
||||
name: "L1-Berechtigungserweiterung"
|
||||
entscheidung: >
|
||||
First Level erhält technische Berechtigungen für Top-5-Standardanfragen
|
||||
(Passwort-Reset, Basis-Berechtigungen).
|
||||
begruendung: >
|
||||
FCR <10% ist auch Befähigungsproblem.
|
||||
Empowerment erfordert Berechtigungen.
|
||||
quellen: ["Team", "Ticket"]
|
||||
status: "vorgeschlagen"
|
||||
hinweis: "Erfordert Abstimmung mit IT-Sicherheit"
|
||||
|
||||
- id: "SSM-G-06"
|
||||
name: "Kennzahlen-Fokus Team"
|
||||
entscheidung: >
|
||||
Performance-Metriken werden primär auf Team-Ebene erhoben, nicht individuell.
|
||||
Ausnahme: Qualitätsindikatoren bei systematischen Abweichungen.
|
||||
begruendung: >
|
||||
Cherry-Picking und Leistungsgefälle erfordern Team-Orientierung.
|
||||
Individuelle Ticketzahlen verstärken Dysfunktionen.
|
||||
quellen: ["Team"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
- id: "SSM-G-07"
|
||||
name: "Datenbereinigung Langläufer"
|
||||
entscheidung: >
|
||||
Tickets >20 Arbeitstage werden retrospektiv als "Projekt" umklassifiziert
|
||||
und aus operativen KPIs exkludiert.
|
||||
begruendung: >
|
||||
MTTR-Verzerrung um Faktor 10 macht Baseline unbrauchbar.
|
||||
Bereinigung ist Voraussetzung für valide Steuerung.
|
||||
quellen: ["Ticket"]
|
||||
status: "vorgeschlagen"
|
||||
|
||||
# =============================================================================
|
||||
# OFFENE FRAGEN
|
||||
# =============================================================================
|
||||
|
||||
offene_fragen:
|
||||
|
||||
strategische_klaerung:
|
||||
- frage: "SLA-Ambitionsniveau"
|
||||
details: "Reaktivierung bestehender Dokumente oder Neuentwicklung? Welche Verbindlichkeit?"
|
||||
optionen: ["intern", "vertraglich"]
|
||||
|
||||
- frage: "Externer Dienstleister"
|
||||
details: "Vertragslaufzeit Randstad/Gulp? Qualitätsvorgaben nachliefern oder Exit?"
|
||||
|
||||
- frage: "Tooling-Roadmap"
|
||||
details: "Zeitplan neues Ticketsystem? Team-Einbindung als Stakeholder gesichert?"
|
||||
|
||||
operative_detailklaerung:
|
||||
- frage: "L1/L2-Grenzziehung konkret"
|
||||
details: "Welche spezifischen Aufgaben gehören wohin?"
|
||||
beispiele: ["Benutzeranlagen", "AD-Änderungen", "SharedMailbox-Berechtigungen"]
|
||||
|
||||
- frage: "Eskalationsschwellen Problem Management"
|
||||
details: "Ab wie vielen wiederkehrenden Incidents wird Problem Record erstellt?"
|
||||
vorschlag: "3 gleichartige Incidents in 30 Tagen"
|
||||
|
||||
- frage: "Wissensdatenbank-Plattform"
|
||||
details: "Teamwork als Single Source of Truth bestätigt? Confluence-Migration?"
|
||||
|
||||
validierung_erforderlich:
|
||||
- frage: "Ursache Ticket-Spike Q1/2025"
|
||||
details: "Welches konkrete Ereignis? Wie wurde (nicht) geplant?"
|
||||
|
||||
- frage: "First-Level-Befugnisse aktuell"
|
||||
details: "Welche technischen Berechtigungen hat L1 faktisch? Gap zu benötigten?"
|
||||
|
||||
- frage: "IT-Sicherheit-Queue"
|
||||
details: "Warum Langläufer dort? Alternativer Prozess für Security-Projekte?"
|
||||
|
||||
# =============================================================================
|
||||
# METHODISCHE ANMERKUNG
|
||||
# =============================================================================
|
||||
|
||||
methodische_anmerkung:
|
||||
triangulation: >
|
||||
Die drei Quellen bilden ein komplementäres Triangulationsset:
|
||||
quantitative Performance-Daten, qualitative Außenperspektive und
|
||||
qualitative Innenperspektive.
|
||||
|
||||
validitaet: >
|
||||
Die hohe Konvergenz der Kernbefunde erhöht deren Validität erheblich.
|
||||
|
||||
divergenzen: >
|
||||
Die Divergenzen verweisen nicht auf Widersprüche, sondern auf
|
||||
unterschiedliche Kausalattributionen – Prozess, Kultur, Struktur
|
||||
als konkurrierende Erklärungsebenen.
|
||||
|
||||
implikation: >
|
||||
Ein robustes Konzept muss alle drei Ebenen adressieren, auch wenn
|
||||
der unmittelbare Gestaltungsspielraum des SPM-Frameworks primär
|
||||
auf der Prozessebene liegt.
|
||||
|
|
@ -0,0 +1,300 @@
|
|||
# Service-Portfolio – Detailversion (Template)
|
||||
|
||||
> **Version:** 0.1 (Entwurf)
|
||||
> **Datum:** 2026-03-03
|
||||
> **Projekt:** DIGITOM
|
||||
> **Zweck:** Workshopgrundlage zur Diskussion der Portfolio-Einträge
|
||||
> **Quellen:** DIGIT SPM-Konzepte (Service-Definition Schema v1.3, Service-Steckbrief Schema v0.3), Scholderer (2022): IT-Servicekatalog (CECAR-Modell)
|
||||
|
||||
---
|
||||
|
||||
## 1. Einordnung und Abgrenzung
|
||||
|
||||
Das **Service-Portfolio** ist die vollständige Sammlung aller Services, die DIGIT während ihres gesamten Lebenszyklus verwaltet. Es ist ein **strategisches Steuerungsinstrument** – nicht zu verwechseln mit dem Service-Katalog, der nur die kundenorientierte Sicht auf aktive Services darstellt.
|
||||
|
||||
### Portfolio vs. Katalog vs. Definition
|
||||
|
||||
| Artefakt | Perspektive | Scope | Zielgruppe |
|
||||
|---|---|---|---|
|
||||
| **Service-Portfolio** | Strategisch | Gesamter Lifecycle (Pipeline → Live → Retired) | SPM, SOR, Mission Board |
|
||||
| **Service-Katalog** | Kundenorientiert | Nur aktive (Live-)Services | Mitarbeitende, Amtsleitungen |
|
||||
| **Service-Definition** | Operativ-intern | Ein einzelner Service (Master-Dokument) | Service Owner, SPM |
|
||||
| **Service-Steckbrief** | Kundenorientiert | Ein einzelner Service (Auszug) | Mitarbeitende, Amtsleitungen |
|
||||
|
||||
### Lifecycle-Phasen im Portfolio
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌──────────────┐ ┌────────┐ ┌───────────────┐ ┌────────────┐
|
||||
│ In Entwick- │───▶│ In Transition │───▶│ Aktiv │───▶│ In Still- │───▶│ Stillgelegt │
|
||||
│ lung │ │ │ │ (Live) │ │ legung │ │ (Retired) │
|
||||
└──────┬──────┘ └──────┬───────┘ └────────┘ └───────────────┘ └────────────┘
|
||||
│ Pipeline │ Katalog Archiv
|
||||
│ │
|
||||
▼ ▼
|
||||
┌─────────────────────────┐
|
||||
│ Abgebrochen (Cancelled) │ ◄── Projektabbruch vor Go-Live
|
||||
└─────────────────────────┘
|
||||
```
|
||||
|
||||
**Referenz:** DIGIT Lifecycle-Status gem. GOV-TR-019, Service-Definition Schema v1.3
|
||||
|
||||
---
|
||||
|
||||
## 2. Strukturbeschreibung – Felder und deren Begründung
|
||||
|
||||
Die folgenden Abschnitte beschreiben jeden Eintrag im Service-Portfolio. Pro Feld wird angegeben: Zweck, Quelle (DIGIT-Konzept oder Fachbuch), ob Pflicht oder optional, und ein Beispiel.
|
||||
|
||||
### 2.1 Metadaten & Identität
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | `service_id` | String | Ja | Eindeutiger Identifier für Referenzierung | DIGIT Schema: metadaten.service_id |
|
||||
| 2 | `service_name` | String | Ja | Offizieller Name | DIGIT Schema: identitaet.service_name |
|
||||
| 3 | `service_name_kurz` | String | Nein | Akronym für Listen/Dashboards | DIGIT Schema: identitaet.service_name_kurz |
|
||||
| 4 | `kurzbeschreibung` | String (max. 200 Zeichen) | Ja | Einzeiler zum schnellen Verständnis | DIGIT Schema + Scholderer Kap. 11.2.3 (Beschreibungstiefe) |
|
||||
| 5 | `service_kategorie` | Enum: A / B / C | Ja | Strategische Stratifikation | DIGIT P-02 SLM Kernkonzepte |
|
||||
| 6 | `service_typ` | Enum: Kundenservice / Interner Service | Ja | Sichtbarkeitssteuerung: Kundenfacing vs. intern | DIGIT Glossar + Scholderer Kap. 8.1 (Target Group) |
|
||||
|
||||
**Diskussionspunkt (Workshop):**
|
||||
- Reicht die A/B/C-Kategorie, oder braucht es eine zusätzliche funktionale Gruppierung (z.B. nach Scholderer: Client-Services, Application-Services, Infrastruktur-Services)?
|
||||
- Soll `service_typ` bereits im Portfolio geführt werden oder erst in der Service-Definition?
|
||||
|
||||
### 2.2 Lifecycle & Status
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 7 | `lifecycle_status` | Enum (s. oben) | Ja | Aktuelle Phase im Lifecycle | DIGIT Schema: lifecycle.lifecycle_status |
|
||||
| 8 | `lifecycle_status_seit` | Datum | Ja | Seit wann in dieser Phase | DIGIT Schema |
|
||||
| 9 | `lifecycle_status_durch` | String | Nein | Entscheidungsinstanz (SO, SOR, MB) | DIGIT Schema |
|
||||
| 10 | `geplantes_go_live` | Datum | Nein | Nur für Pipeline-Services | Scholderer Kap. 4 (Managementstrategie) |
|
||||
| 11 | `geplante_stilllegung` | Datum | Nein | Nur für Services in Stilllegung | DIGIT Lifecycle |
|
||||
|
||||
### 2.3 Strategische Einordnung
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 12 | `zweck` | Text | Ja | Warum existiert der Service? Welchen Nutzen stiftet er? | DIGIT Schema: identitaet.zweck |
|
||||
| 13 | `zielgruppe` | Liste | Ja | Für wen ist der Service bestimmt? | DIGIT Schema: identitaet.zielgruppe |
|
||||
| 14 | `geschaeftskritikalitaet` | Enum: geschäftskritisch / wichtig / unterstützend | Ja | Bedeutung für den Geschäftsbetrieb | DIGIT Schema: geschaeftskritikalitaet |
|
||||
| 15 | `betroffene_kernprozesse` | Liste | Nein | Welche Verwaltungsprozesse werden unterstützt? | DIGIT Schema + Scholderer Kap. 11.2.5 (Abhängigkeiten) |
|
||||
| 16 | `strategische_relevanz` | Text | Nein | Bezug zu städtischen Digitalisierungszielen | Ergänzung für Portfolio-Steuerung |
|
||||
|
||||
**Diskussionspunkt (Workshop):**
|
||||
- Soll `strategische_relevanz` ein Freitext sein oder eine strukturierte Bewertung (z.B. Ampel)?
|
||||
- Welche Digitalisierungsstrategien des DIGIT sind hier referenzierbar?
|
||||
|
||||
### 2.4 Leistung & Qualität (Überblick)
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 17 | `leistungen_inkludiert` | Liste | Ja | Was umfasst der Service? | DIGIT Schema: leistungsumfang |
|
||||
| 18 | `leistungen_exkludiert` | Liste | Ja | Was ist explizit nicht enthalten? | DIGIT Schema + Scholderer Kap. 11.2.6 (Leistungsabgrenzung) |
|
||||
| 19 | `service_level_referenz` | Objekt (Typ + Dokument-ID) | Ja | Verweis auf SLS/SLA | DIGIT Schema: qualitaet.service_level_referenz |
|
||||
| 20 | `verfuegbarkeit_servicezeit` | String | Ja | Wann ist der Service nutzbar? | DIGIT Schema: qualitaet.verfuegbarkeit |
|
||||
| 21 | `verfuegbarkeit_supportzeit` | String | Ja | Wann ist Support erreichbar? | DIGIT Schema |
|
||||
|
||||
### 2.5 Verantwortlichkeiten
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 22 | `service_owner` | Objekt (Name, Kontakt) | Ja | Fachlich Gesamtverantwortliche:r | DIGIT Schema: verantwortlichkeiten.service_owner |
|
||||
| 23 | `service_owner_stellvertretung` | String | Nein | Stellvertretung | DIGIT Schema |
|
||||
| 24 | `betriebsteam` | String | Ja | Zuständiges Team innerhalb DIGIT | DIGIT Schema: betriebsmodell.betriebsteam |
|
||||
| 25 | `betriebsverantwortung` | Enum: intern / hybrid / extern_gesteuert | Ja | Wer betreibt operativ? | DIGIT Schema: betriebsmodell |
|
||||
|
||||
### 2.6 Abhängigkeiten & Kosten
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 26 | `abhaengig_von` | Liste (Service-IDs/Namen) | Nein | Von welchen Services/Systemen abhängig? | DIGIT Schema + Scholderer Kap. 11.2.5 (Dekomposition) |
|
||||
| 27 | `genutzt_von` | Liste (Service-IDs/Namen) | Nein | Welche Services nutzen diesen? | DIGIT Schema |
|
||||
| 28 | `externe_lieferanten` | Liste (Name, Leistung) | Nein | Externe Anbieter | DIGIT Schema |
|
||||
| 29 | `kostenmodell` | Enum: Umlage / nutzungsbasiert / pauschal / Projekt | Ja | Verrechnungsmodell | DIGIT Schema: kosten |
|
||||
| 30 | `kostentreiber` | Liste | Nein | Hauptfaktoren | DIGIT Schema |
|
||||
|
||||
### 2.7 Compliance & Sicherheit
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 31 | `datenschutz_klassifikation` | Enum: keine_pbD / pbD_normal / pbD_hoch / besondere_kategorien | Ja | Datenschutzrelevanz | DIGIT Schema: compliance |
|
||||
| 32 | `schutzbedarf` | Objekt (V/I/V je normal/hoch/sehr_hoch) | Nein | IT-Sicherheit nach BSI | DIGIT Schema |
|
||||
| 33 | `rechtsgrundlagen` | Liste | Nein | Relevante Gesetze | DIGIT Schema |
|
||||
|
||||
### 2.8 Review & Verbesserung (interne Steuerung)
|
||||
|
||||
| # | Feld | Typ | Pflicht | Zweck | Quelle |
|
||||
|---|---|---|---|---|---|
|
||||
| 34 | `letzter_review_datum` | Datum | Nein | Wann wurde der Service zuletzt reviewt? | DIGIT Schema: service_review |
|
||||
| 35 | `review_ergebnis` | Objekt (4 Dimensionen + Empfehlung) | Nein | Ampelstatus D1-D4 | DIGIT Schema: service_review |
|
||||
| 36 | `naechster_review_faellig` | Datum | Nein | Fälligkeit nächster Review | DIGIT Schema |
|
||||
| 37 | `laufende_massnahmen` | Liste (ID, Beschreibung, Status) | Nein | Aktive Improvement-Maßnahmen | DIGIT Schema: laufende_verbesserungen |
|
||||
|
||||
---
|
||||
|
||||
## 3. Befüllbares Template – Service-Portfolio-Eintrag (Detailversion)
|
||||
|
||||
Dieses Template wird pro Service einmal ausgefüllt. Es bildet die **Single Source of Truth** auf Portfolio-Ebene.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# Service-Portfolio-Eintrag: [Service-Name]
|
||||
|
||||
## Metadaten & Identität
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Service-ID** | SVC-___ |
|
||||
| **Service-Name** | _[Offizieller Name]_ |
|
||||
| **Kurzbezeichnung** | _[Akronym, falls vorhanden]_ |
|
||||
| **Kurzbeschreibung** | _[Max. 200 Zeichen: Was macht der Service in einem Satz?]_ |
|
||||
| **Service-Kategorie** | ☐ A (Basis) ☐ B (Erweitert) ☐ C (Spezial) |
|
||||
| **Service-Typ** | ☐ Kundenservice ☐ Interner Service |
|
||||
|
||||
## Lifecycle
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Lifecycle-Status** | ☐ In Entwicklung ☐ In Transition ☐ Aktiv ☐ In Stilllegung ☐ Stillgelegt ☐ Abgebrochen |
|
||||
| **Status seit** | _TT.MM.JJJJ_ |
|
||||
| **Entscheidungsinstanz** | _[SO / SOR / MB]_ |
|
||||
| **Geplantes Go-Live** | _TT.MM.JJJJ (nur Pipeline)_ |
|
||||
| **Geplante Stilllegung** | _TT.MM.JJJJ (nur bei Stilllegung)_ |
|
||||
|
||||
## Strategische Einordnung
|
||||
|
||||
**Zweck / Nutzen:**
|
||||
> _[Warum existiert dieser Service? Welches Problem löst er? Welchen Nutzen stiftet er für die Verwaltung?]_
|
||||
|
||||
**Zielgruppe(n):**
|
||||
- _[z.B. Alle Mitarbeitenden der Stadtverwaltung]_
|
||||
- _[z.B. Amtsleitungen]_
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Geschäftskritikalität** | ☐ Geschäftskritisch (RTO < 4h) ☐ Wichtig (RTO 4-24h) ☐ Unterstützend (RTO > 24h) |
|
||||
| **RTO (Stunden)** | _[optional: konkrete Stundenangabe]_ |
|
||||
|
||||
**Betroffene Kernprozesse:**
|
||||
- _[z.B. Bürgerservice / Antragsbearbeitung]_
|
||||
|
||||
**Strategische Relevanz:**
|
||||
> _[Bezug zu städtischen Digitalisierungszielen, falls relevant]_
|
||||
|
||||
## Leistungsumfang
|
||||
|
||||
**Inkludierte Leistungen:**
|
||||
- _[Konkrete Leistung 1]_
|
||||
- _[Konkrete Leistung 2]_
|
||||
|
||||
**Exkludierte Leistungen (Abgrenzung):**
|
||||
- _[Explizit nicht enthalten 1]_
|
||||
- _[Explizit nicht enthalten 2]_
|
||||
|
||||
## Servicequalität
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Service-Level-Referenz** | Typ: ☐ SLS ☐ SLA_integriert – Dokument: _[ID/Titel]_ |
|
||||
| **Servicezeit** | _[z.B. Mo-Fr 06:00-22:00]_ |
|
||||
| **Supportzeit** | _[z.B. Mo-Fr 08:00-17:00]_ |
|
||||
| **Wartungsfenster** | _[z.B. So 02:00-06:00]_ |
|
||||
|
||||
## Verantwortlichkeiten
|
||||
|
||||
| Rolle | Person | Kontakt |
|
||||
|---|---|---|
|
||||
| **Service Owner** | _[Name]_ | _[E-Mail/Tel]_ |
|
||||
| **Stellvertretung** | _[Name]_ | _[E-Mail/Tel]_ |
|
||||
| **Betriebsteam** | _[Team/Gruppe]_ | |
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Betriebsverantwortung** | ☐ Intern (DIGIT) ☐ Hybrid ☐ Extern gesteuert |
|
||||
|
||||
## Abhängigkeiten
|
||||
|
||||
**Abhängig von:**
|
||||
| Service/System | Typ | Kritikalität |
|
||||
|---|---|---|
|
||||
| _[Name]_ | ☐ intern ☐ extern ☐ infrastruktur | ☐ kritisch ☐ wichtig ☐ optional |
|
||||
|
||||
**Genutzt von:**
|
||||
- _[Service-ID / Name]_
|
||||
|
||||
**Externe Lieferanten:**
|
||||
| Lieferant | Leistung | Vertrag |
|
||||
|---|---|---|
|
||||
| _[Name]_ | _[Was wird geliefert?]_ | _[Vertragsreferenz]_ |
|
||||
|
||||
## Kosten
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Kostenmodell** | ☐ Umlage ☐ Nutzungsbasiert ☐ Pauschal ☐ Projekt |
|
||||
| **Kostentreiber** | _[z.B. Anzahl Arbeitsplätze, Lizenzkosten]_ |
|
||||
| **Budget-Referenz** | _[Kostenstelle/Budgetposition]_ |
|
||||
|
||||
## Compliance & Sicherheit
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Datenschutz** | ☐ keine pbD ☐ pbD normal ☐ pbD hoch ☐ besondere Kategorien (Art. 9) |
|
||||
| **Schutzbedarf Vertraulichkeit** | ☐ normal ☐ hoch ☐ sehr hoch |
|
||||
| **Schutzbedarf Integrität** | ☐ normal ☐ hoch ☐ sehr hoch |
|
||||
| **Schutzbedarf Verfügbarkeit** | ☐ normal ☐ hoch ☐ sehr hoch |
|
||||
|
||||
**Rechtsgrundlagen:**
|
||||
- _[z.B. DSGVO, LDSG BW]_
|
||||
|
||||
## Service-Review (interne Steuerung)
|
||||
|
||||
| Feld | Wert |
|
||||
|---|---|
|
||||
| **Letzter Review** | _TT.MM.JJJJ_ |
|
||||
| **D1 Leistungserbringung** | ☐ Grün ☐ Gelb ☐ Rot |
|
||||
| **D2 Betriebsstabilität** | ☐ Grün ☐ Gelb ☐ Rot |
|
||||
| **D3 Nutzerzufriedenheit** | ☐ Grün ☐ Gelb ☐ Rot |
|
||||
| **D4 Zukunftsfähigkeit** | ☐ Grün ☐ Gelb ☐ Rot |
|
||||
| **Handlungsempfehlung** | ☐ Continue ☐ Improvement ☐ Redesign ☐ Retire |
|
||||
| **Nächster Review fällig** | _TT.MM.JJJJ_ |
|
||||
|
||||
**Laufende Maßnahmen:**
|
||||
| ID | Beschreibung | Dimension | Status | Zieltermin |
|
||||
|---|---|---|---|---|
|
||||
| IMP-SVC-___-001 | _[Kurzbeschreibung]_ | ☐ D1 ☐ D2 ☐ D3 ☐ D4 | ☐ offen ☐ in Arbeit ☐ abgeschlossen | _TT.MM.JJJJ_ |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Anmerkungen zur Nutzung
|
||||
|
||||
### Wann wird dieses Template genutzt?
|
||||
- Bei **Neuaufnahme** eines Services ins Portfolio (frühestens bei Übergang in "In Entwicklung")
|
||||
- Bei **wesentlichen Änderungen** an einem bestehenden Service
|
||||
- Im Rahmen des **jährlichen Portfolio-Reviews**
|
||||
|
||||
### Wer befüllt das Template?
|
||||
- **Service Owner** (Ersteller, Responsible)
|
||||
- **Service-Portfolio-Manager** (Validierung, Accountable)
|
||||
- **SOR / Mission Board** (Freigabe bei Neuaufnahme und strategischen Entscheidungen)
|
||||
|
||||
### Verhältnis zu bestehenden Schemas
|
||||
Dieses Template bildet die **leicht lesbare Darstellung** der in den YAML-Schemas definierten Attribute. Die YAML-Schemas (`spm_schema_service-definition.yaml`, `spm_schema_service-steckbrief.yaml`) bleiben die technische Referenz. Das Template dient dem praktischen Einsatz.
|
||||
|
||||
---
|
||||
|
||||
## 5. Quellenabgleich
|
||||
|
||||
| Feld-Bereich | DIGIT-Schema | Scholderer (2022) |
|
||||
|---|---|---|
|
||||
| Metadaten & Identität | Service-Definition Schema v1.3, Abschnitt metadaten + identitaet | Kap. 11.2.3 (Servicenamen, Beschreibungstiefe) |
|
||||
| Lifecycle | Service-Definition Schema v1.3, Abschnitt lifecycle (GOV-TR-019) | Kap. 7 (SCM Lifecycle), Kap. 4 (Managementstrategie) |
|
||||
| Strategische Einordnung | Identitaet + Geschäftskritikalität | Kap. 4.2 (Zielanalyse), Kap. 12 (KPI/Service Levels) |
|
||||
| Leistungsumfang | Leistungsumfang (Utility) | Kap. 11.2.3 (Beschreibung), Kap. 11.2.6 (Leistungsabgrenzung) |
|
||||
| Servicequalität | Qualitaet (Warranty) | Kap. 12 (KPI/Service Levels), SOUSIS-Modell |
|
||||
| Verantwortlichkeiten | Verantwortlichkeiten + Betriebsmodell | Kap. 11.2.1 (Zuständigkeitsmatrix) |
|
||||
| Abhängigkeiten | Abhaengigkeiten | Kap. 11.2.5 (Dekomposition, Servicebundles) |
|
||||
| Kosten | Kosten | Kap. 13 (Costs/Charge) |
|
||||
| Compliance | Compliance | — (DIGIT-spezifisch, kommunaler Kontext) |
|
||||
| Review | Service-Review + Laufende Verbesserungen | Kap. 6 (Reifegradmodell), Kap. 7 (SCM) |
|
||||
|
|
@ -0,0 +1,172 @@
|
|||
# Service-Portfolio – Kurzversion / Quick Inventory (Template)
|
||||
|
||||
> **Version:** 0.1 (Entwurf)
|
||||
> **Datum:** 2026-03-03
|
||||
> **Projekt:** DIGITOM
|
||||
> **Zweck:** Schnellerfassung aller Services für den initialen Portfolioüberblick
|
||||
> **Quellen:** DIGIT SPM-Konzepte (Service-Definition Schema v1.3), Scholderer (2022): IT-Servicekatalog – Kap. 5 (CECAR Design-Modell, Serviceliste)
|
||||
|
||||
---
|
||||
|
||||
## 1. Wann und wozu diese Kurzversion?
|
||||
|
||||
Bevor ein detailliertes Service-Portfolio aufgebaut werden kann, braucht DIGIT eine **vollständige Übersicht aller Services** – egal in welchem Zustand diese sich befinden. Scholderer beschreibt diesen Schritt als „Serviceliste" im CECAR-Design-Modell (Phase 1: Konzeptionierung):
|
||||
|
||||
> *„Listen Sie alle Ihre IT-Services auf. [...] Die freie Erfassung der Services erfolgt durch interne Rechercheobjekte wie SLAs, Verträge, Rechnungen, OLAs, UCs"* (Scholderer, Kap. 5)
|
||||
|
||||
Die Kurzversion reduziert die 37 Felder der Detailversion auf **12 Kernfelder**, die in einem Workshop oder durch Service Owner pro Service in **5–10 Minuten** erfassbar sind. Die spätere Detaillierung erfolgt dann gezielt mit dem Detailtemplate.
|
||||
|
||||
### Arbeitsweise
|
||||
|
||||
1. **Erfassung** – Jede:r Service Owner (oder SPM) füllt pro Service eine Zeile/ein Formular aus
|
||||
2. **Konsolidierung** – SPM-Team sammelt, dedupliziert, ordnet
|
||||
3. **Workshop** – Gemeinsame Validierung und Priorisierung
|
||||
4. **Vertiefung** – Ausgewählte Services werden in die Detailversion überführt
|
||||
|
||||
---
|
||||
|
||||
## 2. Felder der Kurzversion – Erläuterung
|
||||
|
||||
| # | Feld | Pflicht | Zweck | Herkunft |
|
||||
|---|---|---|---|---|
|
||||
| 1 | **Service-Name** | Ja | Eindeutiger Name, wie er intern bekannt ist | DIGIT: identitaet.service_name |
|
||||
| 2 | **Kurzbeschreibung** | Ja | 1 Satz: Was macht der Service? | DIGIT: identitaet.kurzbeschreibung (max. 200 Zeichen) |
|
||||
| 3 | **Lifecycle-Status** | Ja | Wo steht der Service aktuell? | DIGIT: lifecycle.lifecycle_status |
|
||||
| 4 | **Service-Kategorie** | Ja | Strategische Einordnung A / B / C | DIGIT: P-02 SLM Kernkonzepte |
|
||||
| 5 | **Service-Typ** | Ja | Kundenservice oder interner Service? | DIGIT: Glossar + Scholderer Kap. 8 |
|
||||
| 6 | **Zielgruppe** | Ja | Für wen? (Stichworte genügen) | DIGIT: identitaet.zielgruppe |
|
||||
| 7 | **Service Owner** | Ja | Wer ist verantwortlich? | DIGIT: verantwortlichkeiten.service_owner |
|
||||
| 8 | **Betriebsteam** | Ja | Welches Team betreibt den Service? | DIGIT: betriebsmodell.betriebsteam |
|
||||
| 9 | **Geschäftskritikalität** | Ja | Wie wichtig ist der Service? | DIGIT: geschaeftskritikalitaet |
|
||||
| 10 | **Kostenmodell** | Nein | Wie wird verrechnet? (grob) | DIGIT: kosten.kostenmodell |
|
||||
| 11 | **Datenschutz** | Nein | Werden personenbezogene Daten verarbeitet? | DIGIT: compliance.datenschutz_klassifikation |
|
||||
| 12 | **Bemerkungen** | Nein | Freitext für alles Weitere (z.B. bekannte Probleme, Abhängigkeiten, offene Fragen) | — |
|
||||
|
||||
**Warum genau diese 12 Felder?** Sie decken die vier essenziellen Fragen ab, die für ein strategisches Portfolio mindestens beantwortet sein müssen:
|
||||
|
||||
- **Was?** → Felder 1, 2, 4, 5
|
||||
- **Wo im Lifecycle?** → Feld 3
|
||||
- **Wer?** → Felder 6, 7, 8
|
||||
- **Wie wichtig?** → Felder 9, 10, 11
|
||||
|
||||
Das Bemerkungsfeld (12) fängt alles auf, was nicht in die Struktur passt, aber nicht verloren gehen soll.
|
||||
|
||||
---
|
||||
|
||||
## 3. Befüllbares Template – Einzelservice
|
||||
|
||||
```markdown
|
||||
# Quick-Inventory: [Service-Name]
|
||||
|
||||
| Feld | Eintrag |
|
||||
|---|---|
|
||||
| **Service-Name** | _[Name wie intern gebräuchlich]_ |
|
||||
| **Kurzbeschreibung** | _[1 Satz, max. 200 Zeichen]_ |
|
||||
| **Lifecycle-Status** | ☐ In Entwicklung ☐ In Transition ☐ Aktiv ☐ In Stilllegung ☐ Stillgelegt ☐ Abgebrochen |
|
||||
| **Service-Kategorie** | ☐ A (Basis) ☐ B (Erweitert) ☐ C (Spezial) |
|
||||
| **Service-Typ** | ☐ Kundenservice ☐ Interner Service |
|
||||
| **Zielgruppe** | _[z.B. Alle MA / Amtsleitungen / IT-intern]_ |
|
||||
| **Service Owner** | _[Name]_ |
|
||||
| **Betriebsteam** | _[Team/Gruppe innerhalb DIGIT]_ |
|
||||
| **Geschäftskritikalität** | ☐ Geschäftskritisch ☐ Wichtig ☐ Unterstützend |
|
||||
| **Kostenmodell** | ☐ Umlage ☐ Nutzungsbasiert ☐ Pauschal ☐ Projekt ☐ _noch unklar_ |
|
||||
| **Datenschutz** | ☐ keine pbD ☐ pbD normal ☐ pbD hoch ☐ besondere Kategorien |
|
||||
| **Bemerkungen** | _[Freitext: Abhängigkeiten, offene Punkte, bekannte Risiken]_ |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Listenansicht – Mehrere Services auf einen Blick
|
||||
|
||||
Für die Gesamtübersicht aller Services empfiehlt sich eine **tabellarische Ansicht**. Diese kann z.B. in einem Workshop an der Wand gedruckt oder als Excel-Export genutzt werden.
|
||||
|
||||
```markdown
|
||||
| # | Service-Name | Kurzbeschreibung | Status | Kat. | Typ | Zielgruppe | Owner | Team | Krit. | Kosten | DS | Bemerkungen |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| 1 | _[Name]_ | _[1-Satz]_ | _[Status]_ | _[A/B/C]_ | _[K/I]_ | _[Stichworte]_ | _[Name]_ | _[Team]_ | _[G/W/U]_ | _[Modell]_ | _[Klasse]_ | _[Freitext]_ |
|
||||
| 2 | | | | | | | | | | | | |
|
||||
| 3 | | | | | | | | | | | | |
|
||||
```
|
||||
|
||||
**Legende für Listenansicht:**
|
||||
- **Status:** IE = In Entwicklung, IT = In Transition, AK = Aktiv, IS = In Stilllegung, SG = Stillgelegt, AB = Abgebrochen
|
||||
- **Kat.:** A = Basis, B = Erweitert, C = Spezial
|
||||
- **Typ:** K = Kundenservice, I = Interner Service
|
||||
- **Krit.:** G = Geschäftskritisch, W = Wichtig, U = Unterstützend
|
||||
- **DS:** 0 = keine pbD, 1 = normal, 2 = hoch, 3 = besondere Kategorien
|
||||
|
||||
---
|
||||
|
||||
## 5. Beispiel-Einträge (zur Veranschaulichung)
|
||||
|
||||
Um das Template greifbar zu machen, hier zwei fiktive Beispiel-Services angelehnt an typische kommunale IT-Services (vgl. Scholderer, Anhang A):
|
||||
|
||||
### Beispiel 1: Arbeitsplatz-Service
|
||||
|
||||
| Feld | Eintrag |
|
||||
|---|---|
|
||||
| **Service-Name** | Digitaler Arbeitsplatz |
|
||||
| **Kurzbeschreibung** | Bereitstellung und Betrieb des Standard-PC/Notebook-Arbeitsplatzes inkl. Betriebssystem und Basisanwendungen |
|
||||
| **Lifecycle-Status** | ☐ In Entwicklung ☐ In Transition ☒ Aktiv ☐ In Stilllegung ☐ Stillgelegt |
|
||||
| **Service-Kategorie** | ☒ A (Basis) ☐ B (Erweitert) ☐ C (Spezial) |
|
||||
| **Service-Typ** | ☒ Kundenservice ☐ Interner Service |
|
||||
| **Zielgruppe** | Alle Mitarbeitenden der Stadtverwaltung |
|
||||
| **Service Owner** | Müller, K. |
|
||||
| **Betriebsteam** | Client Management |
|
||||
| **Geschäftskritikalität** | ☒ Geschäftskritisch ☐ Wichtig ☐ Unterstützend |
|
||||
| **Kostenmodell** | ☒ Umlage ☐ Nutzungsbasiert ☐ Pauschal ☐ Projekt |
|
||||
| **Datenschutz** | ☐ keine pbD ☒ pbD normal ☐ pbD hoch ☐ besondere Kategorien |
|
||||
| **Bemerkungen** | Abhängig von Netzwerk-Service und Active Directory. Win11-Migration bis Q3/2026 geplant. |
|
||||
|
||||
### Beispiel 2: Monitoring-Service (intern)
|
||||
|
||||
| Feld | Eintrag |
|
||||
|---|---|
|
||||
| **Service-Name** | IT-Monitoring & Alerting |
|
||||
| **Kurzbeschreibung** | Zentrale Überwachung aller IT-Systeme und automatisierte Alarmierung bei Störungen |
|
||||
| **Lifecycle-Status** | ☐ In Entwicklung ☐ In Transition ☒ Aktiv ☐ In Stilllegung ☐ Stillgelegt |
|
||||
| **Service-Kategorie** | ☒ A (Basis) ☐ B (Erweitert) ☐ C (Spezial) |
|
||||
| **Service-Typ** | ☐ Kundenservice ☒ Interner Service |
|
||||
| **Zielgruppe** | IT-Betrieb, Service Owner |
|
||||
| **Service Owner** | Schmidt, T. |
|
||||
| **Betriebsteam** | Systemmanagement |
|
||||
| **Geschäftskritikalität** | ☒ Geschäftskritisch ☐ Wichtig ☐ Unterstützend |
|
||||
| **Kostenmodell** | ☒ Umlage ☐ Nutzungsbasiert ☐ Pauschal ☐ Projekt |
|
||||
| **Datenschutz** | ☒ keine pbD ☐ pbD normal ☐ pbD hoch ☐ besondere Kategorien |
|
||||
| **Bemerkungen** | Zabbix-basiert. Erweiterung um Application-Monitoring in Prüfung (Pipeline-Kandidat). |
|
||||
|
||||
---
|
||||
|
||||
## 6. Übergang zur Detailversion
|
||||
|
||||
Nach der initialen Quick-Inventory-Phase wird entschieden, welche Services als Erstes in die Detailversion überführt werden. Empfohlene Priorisierung:
|
||||
|
||||
1. **Geschäftskritische Services** (Kritikalität = Geschäftskritisch) → sofort detaillieren
|
||||
2. **Kategorie-A-Services** → mittelfristig detaillieren
|
||||
3. **Pipeline-Services** → bei Übergang in Transition detaillieren
|
||||
4. **Alle übrigen aktiven Services** → gemäß Review-Zyklus schrittweise
|
||||
|
||||
Die Kurzversion bleibt als **Einstiegspunkt** erhalten und wird regelmäßig als Portfolio-Gesamtübersicht aktualisiert (vgl. DIGIT Practice SCM, Activity scm_05: Pflege des Katalogbestands).
|
||||
|
||||
---
|
||||
|
||||
## 7. Diskussionspunkte für den Workshop
|
||||
|
||||
- **Erfassungsmethode:** Sollen Service Owner das Template selbst ausfüllen (dezentral) oder soll SPM die Ersterfassung zentral durchführen (z.B. basierend auf bestehenden Verträgen/SLAs)?
|
||||
- **Anzahl Services:** Wie viele Services erwarten wir grob? (Erfahrungswert kommunale IT: 30–80 Kundenservices, 20–50 interne Services)
|
||||
- **Abgrenzung Service vs. System:** Wann ist etwas ein eigenständiger Service und wann eine Komponente? (Kriterium: eigenständig bestellbar/wahrnehmbar durch Zielgruppe?)
|
||||
- **Namenskonventionen:** Sollen Servicenamen einem einheitlichen Schema folgen? (z.B. Scholderer: Substantiviertes Format wie „Bereitstellung und Betrieb [Gegenstand]")
|
||||
- **Kategorie-Zuordnung:** Ist die A/B/C-Zuordnung bei der Ersterfassung bereits möglich oder soll sie erst nach Konsolidierung erfolgen?
|
||||
|
||||
---
|
||||
|
||||
## 8. Quellenabgleich
|
||||
|
||||
| Element | DIGIT-Referenz | Scholderer (2022) |
|
||||
|---|---|---|
|
||||
| Grundidee Quick Inventory | — | Kap. 5: CECAR Phase 1 (Serviceliste) |
|
||||
| Feldauswahl | Service-Definition Schema v1.3 (reduzierter Auszug) | Kap. 11.2 (Methodentabelle) |
|
||||
| Lifecycle-Status | GOV-TR-019 | Kap. 7 (SCM Lifecycle) |
|
||||
| Kategorie A/B/C | P-02 SLM Kernkonzepte | — (DIGIT-spezifisch) |
|
||||
| Beispielservices | — | Anhang A (Repository zu IT-Services) |
|
||||
| Priorisierung Detaillierung | Practice P-01 SCM (scm_05) | Kap. 5 (Design-Modell, Step 2) |
|
||||
|
|
@ -0,0 +1,407 @@
|
|||
# Service-Katalog – Strukturvarianten für DIGIT
|
||||
|
||||
> **Version:** 0.1 (Entwurf)
|
||||
> **Datum:** 2026-03-03
|
||||
> **Projekt:** DIGITOM
|
||||
> **Zweck:** Workshop-Diskussionsgrundlage – drei alternative Katalogstrukturen zur Auswahl
|
||||
> **Quellen:** DIGIT SPM-Konzepte (Service-Steckbrief Schema v0.3, Practice P-01 SCM), Scholderer (2022): Kap. 8 (Katalogansätze), Kap. 9 (Katalogorganisation), Kap. 11 (Service-Modellierung), Anhang A
|
||||
|
||||
---
|
||||
|
||||
## 1. Einordnung: Was ist der Service-Katalog im DIGIT-Kontext?
|
||||
|
||||
Der **Service-Katalog** ist die kundenorientierte Sicht auf alle **aktiven Services** des DIGIT. Er leitet sich aus dem Service-Portfolio ab und enthält nur Services im Lifecycle-Status „Aktiv". Im Gegensatz zum Portfolio ist der Katalog kein internes Steuerungsinstrument, sondern eine **Kommunikations- und Bestellgrundlage** für Mitarbeitende und Amtsleitungen der Stadtverwaltung.
|
||||
|
||||
### Abgrenzung zum Portfolio
|
||||
|
||||
```
|
||||
Service-Portfolio (intern, alle Lifecycle-Phasen)
|
||||
└──▶ Service-Katalog (extern, nur aktive Services)
|
||||
└──▶ Service-Steckbrief (Detailsicht pro Service)
|
||||
```
|
||||
|
||||
### Views laut DIGIT SCM-Practice (P-01)
|
||||
|
||||
Die DIGIT-Konzepte definieren drei Katalog-Views:
|
||||
|
||||
| View | Zielgruppe | Fokus |
|
||||
|---|---|---|
|
||||
| **Nutzer-View** | Alle Mitarbeitenden | Was kann ich nutzen? Wie bestelle ich? |
|
||||
| **Entscheider-View** | Amtsleitungen, Fachbereichsleitungen | Was kostet es? Welche Kategorie? Welcher SLA-Typ? |
|
||||
| **Request-View** | Service-Desk, Bestell-Portal | Bestellbar, konfigurierbar, mit Parametern |
|
||||
|
||||
Die drei folgenden Strukturvarianten können jeweils in allen drei Views dargestellt werden – die View bestimmt die **Tiefe und Auswahl der angezeigten Attribute**, die Struktur bestimmt die **Gliederung und Navigation**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Gemeinsame Elemente aller Varianten
|
||||
|
||||
Unabhängig von der gewählten Struktur enthält jeder DIGIT-Service-Katalog:
|
||||
|
||||
### 2.1 Rahmenelemente (vgl. Scholderer, Kap. 9.1)
|
||||
|
||||
- **Einführung:** Zweck des Katalogs, Geltungsbereich, Ansprechpartner
|
||||
- **Übergeordnete Service Levels:** Allgemeine Betriebs-/Servicezeiten, Standard-Support-Kanäle, Wartungsfenster (gelten für alle Services, sofern nicht im Steckbrief abweichend definiert)
|
||||
- **Glossar/Begriffsdefinitionen:** Verweis auf DIGIT SPM-Glossar (bereits vorhanden)
|
||||
- **Bestellprozess:** Beschreibung des Anforderungs-/Bestellwegs (Service-Request → Service-Desk)
|
||||
|
||||
### 2.2 Service-Steckbrief als Detailsicht
|
||||
|
||||
Jeder Service im Katalog verweist auf seinen **Service-Steckbrief** (gem. `spm_schema_service-steckbrief.yaml`), der die vollständige kundenorientierte Beschreibung enthält. Der Katalog selbst zeigt pro Service nur eine **Übersichtszeile** mit den wichtigsten Attributen.
|
||||
|
||||
### 2.3 Übersichtsattribute pro Service (Katalog-Zeile)
|
||||
|
||||
Aus dem Service-Steckbrief Schema (View: `katalog_uebersicht`) werden für jede Katalogzeile folgende Attribute angezeigt:
|
||||
|
||||
| Attribut | Quelle (Steckbrief-Schema) |
|
||||
|---|---|
|
||||
| Service-Name | identifikation.service_name |
|
||||
| Kurzbeschreibung | ueberblick.kurzbeschreibung |
|
||||
| Kategorie (A/B/C) | identifikation.service_kategorie |
|
||||
| Servicezeit | servicequalitaet.verfuegbarkeit.servicezeit |
|
||||
| Supportzeit | servicequalitaet.verfuegbarkeit.supportzeit |
|
||||
| Bestellweg | beantragung.bestellweg |
|
||||
| Service Owner | identifikation.service_owner |
|
||||
|
||||
---
|
||||
|
||||
## 3. Variante A: Schichtenbasierte Struktur (Technisch-funktional)
|
||||
|
||||
### Idee
|
||||
|
||||
Die Services werden entlang einer **funktionalen Schichtung** gegliedert, von der Nutzerschnittstelle (Arbeitsplatz) über Anwendungen bis hinunter zu Infrastruktur und Querschnitts-Services. Diese Struktur orientiert sich an Scholderer Kap. 9.2.1 (Schichtenbasierte Katalogstruktur) mit Erweiterung um Cross-Services und Security (Abb. 9-4).
|
||||
|
||||
### Struktur
|
||||
|
||||
```
|
||||
DIGIT Service-Katalog (Variante A – Schichtenbasiert)
|
||||
│
|
||||
├── 0. Einführung & Rahmenbedingungen
|
||||
│ ├── Zweck und Geltungsbereich
|
||||
│ ├── Übergeordnete Service Levels
|
||||
│ ├── Bestellprozess
|
||||
│ └── Glossar (→ Verweis SPM-Glossar)
|
||||
│
|
||||
├── 1. Arbeitsplatz-Services
|
||||
│ ├── Digitaler Arbeitsplatz (PC/Notebook)
|
||||
│ ├── Mobiler Arbeitsplatz (Smartphone/Tablet)
|
||||
│ ├── Telefonie
|
||||
│ ├── Peripheriegeräte (Drucker, Scanner, etc.)
|
||||
│ └── [weitere]
|
||||
│
|
||||
├── 2. Anwendungs-Services
|
||||
│ ├── Fachverfahren (z.B. SAP, Prosoz, etc.)
|
||||
│ ├── Bürokommunikation (E-Mail, Kalender, Kollaboration)
|
||||
│ ├── Dokumentenmanagement (DMS/ECM)
|
||||
│ ├── Intranet / Wissensplattform
|
||||
│ └── [weitere]
|
||||
│
|
||||
├── 3. Plattform- & Infrastruktur-Services
|
||||
│ ├── Serverhosting / Virtualisierung
|
||||
│ ├── Datenbank-Services
|
||||
│ ├── Storage & Backup
|
||||
│ ├── Netzwerk (LAN/WLAN/WAN/VPN)
|
||||
│ └── [weitere]
|
||||
│
|
||||
├── 4. Querschnitts-Services (Cross-Services)
|
||||
│ ├── Service Desk / IT-Hotline
|
||||
│ ├── IT-Beratung & Projektunterstützung
|
||||
│ ├── Monitoring & Alerting
|
||||
│ └── [weitere]
|
||||
│
|
||||
└── 5. IT-Sicherheits-Services
|
||||
├── Firewall / Gateway
|
||||
├── Identity & Access Management
|
||||
├── Virenschutz / Endpoint Protection
|
||||
└── [weitere]
|
||||
```
|
||||
|
||||
### DIGIT-Kategorie-Mapping (A/B/C)
|
||||
|
||||
| Schicht | Typische Kategorie |
|
||||
|---|---|
|
||||
| Arbeitsplatz-Services | A (Basis) – von allen genutzt |
|
||||
| Anwendungs-Services | A oder B – je nach Verbreitung |
|
||||
| Plattform & Infrastruktur | A (intern, aber Basis-Voraussetzung) |
|
||||
| Querschnitts-Services | A (Basis) |
|
||||
| IT-Sicherheit | A (Basis, nicht optional) |
|
||||
|
||||
### Bewertung
|
||||
|
||||
| Kriterium | Einschätzung |
|
||||
|---|---|
|
||||
| **Verständlichkeit für Endnutzer** | ⚠️ Mittel – Nutzer denken nicht in Schichten, sondern in „was brauche ich" |
|
||||
| **Verständlichkeit für IT-Fachleute** | ✅ Hoch – logische Gliederung entlang IT-Architektur |
|
||||
| **Skalierbarkeit** | ✅ Hoch – neue Services lassen sich klar einordnen |
|
||||
| **Passend für Entscheider-View** | ✅ Gut – Kostenzuordnung pro Schicht möglich |
|
||||
| **DIGIT A/B/C-Kompatibilität** | ⚠️ Mittel – Kategorie geht quer zu Schichten |
|
||||
|
||||
**Empfehlung:** Gut als **internes Strukturierungsinstrument** und für den **Entscheider-View**. Für den reinen Nutzer-View ggf. zu technisch.
|
||||
|
||||
---
|
||||
|
||||
## 4. Variante B: Endbenutzersicht-basierte Struktur (Bedarfsorientiert)
|
||||
|
||||
### Idee
|
||||
|
||||
Die Struktur orientiert sich konsequent an der **Nutzerperspektive**: Welche Kategorien von Unterstützung braucht ein:e Mitarbeiter:in der Stadtverwaltung? Basierend auf Scholderer Kap. 9.2.2 (Endbenutzersicht-basierte Katalogstruktur) und angepasst an den kommunalen Kontext von DIGIT.
|
||||
|
||||
### Struktur
|
||||
|
||||
```
|
||||
DIGIT Service-Katalog (Variante B – Bedarfsorientiert)
|
||||
│
|
||||
├── 0. Einführung & Rahmenbedingungen
|
||||
│ ├── Zweck und Geltungsbereich
|
||||
│ ├── Übergeordnete Service Levels
|
||||
│ ├── Bestellprozess
|
||||
│ └── Glossar (→ Verweis SPM-Glossar)
|
||||
│
|
||||
├── 1. Mein Arbeitsplatz
|
||||
│ ├── Computer & Zubehör (PC, Notebook, Bildschirm)
|
||||
│ ├── Mobilgeräte (Smartphone, Tablet)
|
||||
│ ├── Drucken & Scannen
|
||||
│ ├── Telefon & Kommunikation
|
||||
│ └── Software auf meinem Arbeitsplatz
|
||||
│
|
||||
├── 2. Anwendungen & Fachverfahren
|
||||
│ ├── Büro & Zusammenarbeit (E-Mail, Kalender, Teams/Chat)
|
||||
│ ├── Dokumentenmanagement
|
||||
│ ├── Fachverfahren (nach Fachbereichen gruppiert)
|
||||
│ │ ├── Bürgerservice (z.B. Meldewesen, KFZ)
|
||||
│ │ ├── Finanzen (z.B. SAP, HKR)
|
||||
│ │ ├── Soziales & Jugend
|
||||
│ │ ├── Bau & Stadtplanung
|
||||
│ │ └── [weitere Bereiche]
|
||||
│ └── Intranet & Wissensplattform
|
||||
│
|
||||
├── 3. Hilfe & Unterstützung
|
||||
│ ├── IT-Hotline / Service Desk
|
||||
│ ├── Vor-Ort-Support
|
||||
│ ├── Schulungen & Anleitungen
|
||||
│ └── IT-Beratung für Projekte
|
||||
│
|
||||
├── 4. Zugang & Sicherheit
|
||||
│ ├── Benutzerkonto & Berechtigungen
|
||||
│ ├── VPN / Homeoffice-Zugang
|
||||
│ ├── WLAN
|
||||
│ └── Passwort & Zwei-Faktor-Authentifizierung
|
||||
│
|
||||
└── 5. Spezialdienste (auf Anfrage)
|
||||
├── Serverbereitstellung (für Fachabteilungen)
|
||||
├── Individuelle Softwareentwicklung
|
||||
├── Konferenz- & Veranstaltungstechnik
|
||||
└── [weitere]
|
||||
```
|
||||
|
||||
### DIGIT-Kategorie-Mapping (A/B/C)
|
||||
|
||||
| Bedarfskategorie | Typische Kategorie |
|
||||
|---|---|
|
||||
| Mein Arbeitsplatz | A (Basis) – Standard für alle |
|
||||
| Anwendungen (Basis) | A (Basis) – E-Mail, Office etc. |
|
||||
| Fachverfahren | B (Erweitert) – fachbereichsspezifisch |
|
||||
| Hilfe & Unterstützung | A (Basis) |
|
||||
| Zugang & Sicherheit | A (Basis) |
|
||||
| Spezialdienste | C (Spezial) – auf Anfrage |
|
||||
|
||||
### Bewertung
|
||||
|
||||
| Kriterium | Einschätzung |
|
||||
|---|---|
|
||||
| **Verständlichkeit für Endnutzer** | ✅ Hoch – Alltagssprache, „Ich"-Perspektive |
|
||||
| **Verständlichkeit für IT-Fachleute** | ⚠️ Mittel – vermischt technische Schichten |
|
||||
| **Skalierbarkeit** | ⚠️ Mittel – bei sehr vielen Fachverfahren wird Kategorie 2 groß |
|
||||
| **Passend für Entscheider-View** | ⚠️ Mittel – Kostenstruktur nicht direkt ablesbar |
|
||||
| **DIGIT A/B/C-Kompatibilität** | ✅ Gut – Kategorien lassen sich natürlich zuordnen |
|
||||
|
||||
**Empfehlung:** Ideal für den **Nutzer-View** (Self-Service-Portal, Intranet). Sollte für Entscheider ggf. durch eine ergänzende Kostenübersicht erweitert werden.
|
||||
|
||||
---
|
||||
|
||||
## 5. Variante C: Hybridstruktur (DIGIT-optimiert)
|
||||
|
||||
### Idee
|
||||
|
||||
Diese Variante kombiniert die Stärken beider vorangegangenen Ansätze und integriert die DIGIT-spezifische A/B/C-Kategorisierung als **primäres Gliederungsmerkmal**. Die Services werden zuerst nach Kategorie (Basis / Erweitert / Spezial) und dann nach funktionaler Gruppierung sortiert. Zusätzlich wird die Scholderer'sche Gewichtungslogik (Kap. 9.2.3: Commodity → SLA → Innovation) adaptiert.
|
||||
|
||||
### Struktur
|
||||
|
||||
```
|
||||
DIGIT Service-Katalog (Variante C – Hybridstruktur)
|
||||
│
|
||||
├── 0. Einführung & Rahmenbedingungen
|
||||
│ ├── Zweck und Geltungsbereich
|
||||
│ ├── So nutzen Sie diesen Katalog
|
||||
│ ├── Übergeordnete Service Levels
|
||||
│ ├── Bestellprozess & Ansprechpartner
|
||||
│ └── Glossar (→ Verweis SPM-Glossar)
|
||||
│
|
||||
├── A. BASIS-SERVICES (Kategorie A)
|
||||
│ │ Alle Services, die standardmäßig für alle Mitarbeitenden
|
||||
│ │ bereitgestellt werden. Keine gesonderte Bestellung nötig.
|
||||
│ │
|
||||
│ ├── A1. Arbeitsplatz & Endgeräte
|
||||
│ │ ├── Digitaler Arbeitsplatz
|
||||
│ │ ├── Telefonie
|
||||
│ │ └── Drucken & Scannen
|
||||
│ │
|
||||
│ ├── A2. Kommunikation & Zusammenarbeit
|
||||
│ │ ├── E-Mail
|
||||
│ │ ├── Kalender
|
||||
│ │ └── Kollaboration / Chat
|
||||
│ │
|
||||
│ ├── A3. Zugang & Sicherheit
|
||||
│ │ ├── Benutzerkonto & Berechtigungen
|
||||
│ │ ├── Netzwerkzugang (LAN/WLAN)
|
||||
│ │ └── Virenschutz / Endpoint Protection
|
||||
│ │
|
||||
│ └── A4. Hilfe & Support
|
||||
│ ├── IT-Hotline / Service Desk
|
||||
│ └── Vor-Ort-Support
|
||||
│
|
||||
├── B. ERWEITERTE SERVICES (Kategorie B)
|
||||
│ │ Services, die für bestimmte Fachbereiche oder Aufgaben
|
||||
│ │ bereitgestellt werden. Bestellung/Freigabe erforderlich.
|
||||
│ │
|
||||
│ ├── B1. Fachverfahren
|
||||
│ │ ├── [nach Fachbereich gruppiert]
|
||||
│ │ ├── Bürgerservice-Verfahren
|
||||
│ │ ├── Finanz-Verfahren
|
||||
│ │ └── [weitere]
|
||||
│ │
|
||||
│ ├── B2. Erweiterte Arbeitsplatz-Optionen
|
||||
│ │ ├── Mobiler Arbeitsplatz (Smartphone/Tablet)
|
||||
│ │ ├── Homeoffice / VPN-Zugang
|
||||
│ │ └── Spezial-Hardware (z.B. Grafik-Arbeitsplatz)
|
||||
│ │
|
||||
│ ├── B3. Dokumentenmanagement & Archivierung
|
||||
│ │ ├── DMS/ECM
|
||||
│ │ └── Elektronische Akte
|
||||
│ │
|
||||
│ └── B4. Beratung & Schulung
|
||||
│ ├── IT-Beratung für Fachprojekte
|
||||
│ └── IT-Schulungen
|
||||
│
|
||||
├── C. SPEZIAL-SERVICES (Kategorie C)
|
||||
│ │ Individuelle oder projektbezogene Services.
|
||||
│ │ Separate Beauftragung und ggf. Kostenübernahme nötig.
|
||||
│ │
|
||||
│ ├── C1. Hosting & Plattform
|
||||
│ │ ├── Serverbereitstellung für Fachabteilung
|
||||
│ │ ├── Datenbankbereitstellung
|
||||
│ │ └── Cloud-Services
|
||||
│ │
|
||||
│ ├── C2. Entwicklung & Integration
|
||||
│ │ ├── Individuelle Softwareentwicklung
|
||||
│ │ ├── Schnittstellenentwicklung
|
||||
│ │ └── Migrationsunterstützung
|
||||
│ │
|
||||
│ └── C3. Veranstaltung & Sonderbedarf
|
||||
│ ├── Konferenz- & Veranstaltungstechnik
|
||||
│ └── Sonder-IT-Anforderungen
|
||||
│
|
||||
└── Anhang
|
||||
├── Übersicht: Alle Services nach Fachbereich
|
||||
├── Übersicht: Alle Services alphabetisch
|
||||
└── Kostenübersicht (Entscheider-View)
|
||||
```
|
||||
|
||||
### Besonderheiten dieser Variante
|
||||
|
||||
**1. A/B/C als Hauptgliederung** – Die DIGIT-eigene Kategorisierung wird zum primären Navigationselement. Nutzer:innen sehen sofort: „A = ist für mich automatisch da, B = kann ich beantragen, C = muss ich beauftragen."
|
||||
|
||||
**2. Funktionale Untergruppen** – Innerhalb jeder Kategorie werden Services nach Nutzungszweck gruppiert (nicht nach technischer Schicht), was die Auffindbarkeit verbessert.
|
||||
|
||||
**3. Anhang mit Querverweisen** – Für Nutzer:innen, die einen Service nicht in der A/B/C-Logik finden, gibt es alternative Zugangswege (alphabetisch, nach Fachbereich). Dies entspricht Scholderers Empfehlung, mehrere Einstiegswege anzubieten (Kap. 11.2.3).
|
||||
|
||||
**4. Skalierbarkeit** – Neue Services werden in die passende Kategorie eingeordnet. Bei Bedarf können Untergruppen erweitert werden, ohne die Gesamtstruktur zu ändern.
|
||||
|
||||
### DIGIT-Kategorie-Mapping
|
||||
|
||||
Die Kategorie A/B/C **ist** das Gliederungsmerkmal – kein separates Mapping nötig.
|
||||
|
||||
### Bewertung
|
||||
|
||||
| Kriterium | Einschätzung |
|
||||
|---|---|
|
||||
| **Verständlichkeit für Endnutzer** | ✅ Hoch – klare Aussage: „was bekomme ich automatisch / auf Antrag / auf Beauftragung" |
|
||||
| **Verständlichkeit für IT-Fachleute** | ✅ Hoch – funktionale Gruppierung innerhalb der Kategorien |
|
||||
| **Skalierbarkeit** | ✅ Hoch – Kategorien + Untergruppen sind flexibel erweiterbar |
|
||||
| **Passend für Entscheider-View** | ✅ Hoch – Kostenübersicht im Anhang, klare Unterscheidung Basis/Erweitert/Spezial |
|
||||
| **DIGIT A/B/C-Kompatibilität** | ✅ Nativ – Kategorie ist das Strukturprinzip |
|
||||
|
||||
**Empfehlung:** Diese Variante nutzt die DIGIT-eigene Logik am konsequentesten und ist sowohl für den **Nutzer-View** als auch den **Entscheider-View** geeignet. Sie könnte als **Hauptempfehlung** in den Workshop eingebracht werden.
|
||||
|
||||
---
|
||||
|
||||
## 6. Vergleichsmatrix der Varianten
|
||||
|
||||
| Kriterium | Variante A (Schichten) | Variante B (Bedarf) | Variante C (Hybrid) |
|
||||
|---|---|---|---|
|
||||
| Primäres Gliederungsmerkmal | Technische Funktion | Nutzerbedarf | DIGIT-Kategorie A/B/C |
|
||||
| Verständlichkeit Nutzer | ⚠️ Mittel | ✅ Hoch | ✅ Hoch |
|
||||
| Verständlichkeit IT | ✅ Hoch | ⚠️ Mittel | ✅ Hoch |
|
||||
| Entscheider-tauglich | ✅ Gut | ⚠️ Eingeschränkt | ✅ Gut |
|
||||
| A/B/C-Kompatibilität | ⚠️ Quer | ✅ Natürlich | ✅ Nativ |
|
||||
| Skalierbarkeit | ✅ Hoch | ⚠️ Mittel | ✅ Hoch |
|
||||
| Scholderer-Referenz | Kap. 9.2.1, Abb. 9-4 | Kap. 9.2.2, Abb. 9-5 | Kap. 9.2.3 + DIGIT-eigen |
|
||||
| Empfehlung für | Intern / Entscheider | Nutzer-Portal | **Hauptkatalog** |
|
||||
|
||||
---
|
||||
|
||||
## 7. Beispiel-Steckbrief für den Katalog (View: Nutzer-Übersicht)
|
||||
|
||||
Unabhängig von der gewählten Struktur sieht ein Eintrag im Katalog (Übersichtsebene) wie folgt aus:
|
||||
|
||||
```markdown
|
||||
### Digitaler Arbeitsplatz
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Kurzbeschreibung** | Standard-PC oder -Notebook mit Betriebssystem und Basisanwendungen |
|
||||
| **Kategorie** | A (Basis) – wird automatisch bereitgestellt |
|
||||
| **Servicezeit** | Mo–Fr 06:00–22:00 |
|
||||
| **Supportzeit** | Mo–Fr 08:00–17:00, IT-Hotline: [Telefon] |
|
||||
| **Bestellweg** | Automatisch bei Onboarding / Änderungen über Service-Desk |
|
||||
| **Service Owner** | Müller, K. (Client Management) |
|
||||
| **Details** | → [Service-Steckbrief öffnen](link) |
|
||||
```
|
||||
|
||||
Für den **Entscheider-View** werden zusätzlich angezeigt: Kostenmodell, SLA-Typ, Geschäftskritikalität.
|
||||
Für den **Request-View** werden zusätzlich angezeigt: Konfigurationsoptionen, Genehmigungspflicht, Lieferzeit.
|
||||
|
||||
---
|
||||
|
||||
## 8. Empfehlung für den Workshop
|
||||
|
||||
### Vorgeschlagenes Vorgehen
|
||||
|
||||
1. **Varianten vorstellen** – alle drei Strukturen kurz präsentieren (je 5 Min.)
|
||||
2. **Nutzer-Perspektive einnehmen** – „Finden Sie den Service X?" als Test mit fiktiven Szenarien
|
||||
3. **Entscheider-Perspektive** – „Können Sie Kosten und Verantwortlichkeiten ablesen?"
|
||||
4. **Entscheidung oder Hybrid** – ggf. Elemente verschiedener Varianten kombinieren
|
||||
5. **Nächste Schritte** – gewählte Struktur mit realen Services befüllen (Quick Inventory als Basis)
|
||||
|
||||
### Offene Fragen für den Workshop
|
||||
|
||||
- Soll der Katalog primär als **Dokument** (Markdown/PDF) oder als **Tool-gestütztes Portal** realisiert werden?
|
||||
- Wie tief soll die Fachverfahrens-Gruppierung gehen? (Pro Amt? Pro Themenfeld?)
|
||||
- Sollen **interne Services** (Typ = Interner Service) in einem separaten Abschnitt oder gar nicht im Kundenkatalog erscheinen?
|
||||
- Wie wird der Katalog **gepflegt**? (Trigger-basiert gem. Steckbrief-Schema oder periodisch?)
|
||||
- Sollen **Pipeline-Services** (Vorschau auf kommende Services) einen eigenen Abschnitt erhalten?
|
||||
|
||||
---
|
||||
|
||||
## 9. Quellenabgleich
|
||||
|
||||
| Element | DIGIT-Referenz | Scholderer (2022) |
|
||||
|---|---|---|
|
||||
| Katalog-Views | P-01 SCM: Nutzer-View, Entscheider-View, Request-View | Kap. 8.1 (Target Group – Zielgruppenbestimmung) |
|
||||
| Rahmenelemente | — | Kap. 9.1 (Aufbau: Prozessbeschreibung, übergeordnete SLs, Glossar, Kosten) |
|
||||
| Variante A (Schichten) | — | Kap. 9.2.1 + Tab. 9-1 (8 Servicekategorien) |
|
||||
| Variante B (Bedarf) | — | Kap. 9.2.2 (Endbenutzersicht, Abb. 9-5) |
|
||||
| Variante C (Gewichtung/Hybrid) | P-02 SLM: Kategorie A/B/C | Kap. 9.2.3 (Commodity/SLA/Innovation) |
|
||||
| Katalog-Übersichtsattribute | Steckbrief Schema v0.3: View `katalog_uebersicht` | Kap. 11.2.3 (Beschreibungstiefe) |
|
||||
| Beispiel-Steckbrief | Steckbrief Schema v0.3 | Anhang A (Repository zu IT-Services) |
|
||||
| Bestellprozess | P-01 SCM: Activities scm_03, scm_04 | Kap. 10 (Order Procedure) |
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
# Workshop-Leitfaden: SPM-Arbeitssession – Portfolio & Katalogstrukturen
|
||||
|
||||
> **Version:** 0.1 (Entwurf)
|
||||
> **Datum:** 2026-03-03
|
||||
> **Projekt:** DIGITOM
|
||||
> **Format:** Halbtages-Workshop (3,5 Stunden)
|
||||
> **Teilnehmende:** DIGIT-intern (Service Owner, SPM-Team, IT-Fachleute)
|
||||
> **Materialien:** Begleitpräsentation (PPTX), Arbeitsmaterialien 01–03 (Markdown)
|
||||
|
||||
---
|
||||
|
||||
## 1. Ziel der Session
|
||||
|
||||
Am Ende des Workshops sollen folgende Ergebnisse vorliegen:
|
||||
|
||||
1. **Gemeinsames Verständnis** der SPM-Artefakte (Portfolio, Katalog, Steckbrief) und deren Zusammenspiel
|
||||
2. **Entscheidung über die Portfolio-Templates** – Detailversion und Kurzversion validiert oder angepasst
|
||||
3. **Entscheidung über die Katalogstruktur** – eine der drei Varianten (oder ein Hybrid) als Arbeitsgrundlage gewählt
|
||||
4. **Greifbare Erfahrung** durch fiktive Beispiel-Services, die das Template-Handling illustrieren
|
||||
|
||||
---
|
||||
|
||||
## 2. Agenda
|
||||
|
||||
| Zeit | Block | Dauer | Methode |
|
||||
|---|---|---|---|
|
||||
| 09:00 | **Ankommen & Einführung** | 15 Min. | Präsentation |
|
||||
| 09:15 | **Block 1: Theoretischer Rahmen** – Was ist SPM? Portfolio vs. Katalog vs. Definition | 30 Min. | Präsentation + Diskussion |
|
||||
| 09:45 | **Block 2: Portfolio-Templates im Detail** – Detailversion und Kurzversion Feld für Feld | 45 Min. | Präsentation + Gruppenarbeit |
|
||||
| 10:30 | ☕ **Pause** | 15 Min. | |
|
||||
| 10:45 | **Block 3: Quick-Inventory-Übung** – Fiktive Services gemeinsam erfassen | 30 Min. | Gruppenarbeit |
|
||||
| 11:15 | **Block 4: Katalogstruktur-Varianten** – Drei Ansätze vorstellen und vergleichen | 40 Min. | Präsentation + Diskussion |
|
||||
| 11:55 | **Block 5: Entscheidungen & nächste Schritte** | 20 Min. | Moderation |
|
||||
| 12:15 | **Abschluss** | 15 Min. | |
|
||||
| **12:30** | **Ende** | | |
|
||||
|
||||
---
|
||||
|
||||
## 3. Detaillierte Blockbeschreibungen
|
||||
|
||||
### Block 0: Ankommen & Einführung (15 Min.)
|
||||
|
||||
**Ziel:** Kontext herstellen, Erwartungen klären.
|
||||
|
||||
**Ablauf:**
|
||||
- Begrüßung, kurze Vorstellungsrunde (falls nötig)
|
||||
- Einordnung: Wo stehen wir im DIGITOM-Projekt?
|
||||
- Ziel des Workshops benennen (Folie)
|
||||
- Kurzer Überblick über die Agenda
|
||||
|
||||
**Moderationshinweis:** Keine Detaildiskussionen in der Einführung – offene Fragen auf Parkplatz-Liste.
|
||||
|
||||
---
|
||||
|
||||
### Block 1: Theoretischer Rahmen (30 Min.)
|
||||
|
||||
**Ziel:** Alle Teilnehmenden haben dasselbe Verständnis der SPM-Grundbegriffe.
|
||||
|
||||
**Ablauf (Präsentation + Diskussion):**
|
||||
|
||||
| Min. | Inhalt | Folie |
|
||||
|---|---|---|
|
||||
| 0–10 | **Warum SPM?** – Problemstellung: „Welche Services hat DIGIT eigentlich?" Herausforderungen ohne strukturiertes Portfolio. | 3–4 |
|
||||
| 10–18 | **Die SPM-Artefakte** – Portfolio → Katalog → Service-Definition → Steckbrief. Wer nutzt was? CECAR-Modell (Scholderer) als theoretischer Unterbau. | 5–7 |
|
||||
| 18–25 | **Lifecycle-Phasen** – Von „In Entwicklung" bis „Stillgelegt" (inkl. „Abgebrochen"). Wann wird was im Portfolio geführt? Wann erscheint ein Service im Katalog? | 8 |
|
||||
| 25–30 | **Diskussion:** Ist die Abgrenzung klar? Gibt es Fragen zu den Begriffen? | — |
|
||||
|
||||
**Diskussionsfragen:**
|
||||
- „Könntet ihr spontan sagen, wie viele Services DIGIT aktuell betreibt?"
|
||||
- „Wer ist heute für das Thema ‚Service-Übersicht' verantwortlich?"
|
||||
|
||||
---
|
||||
|
||||
### Block 2: Portfolio-Templates im Detail (45 Min.)
|
||||
|
||||
**Ziel:** Detailversion und Kurzversion sind verstanden, Feedback ist eingeholt.
|
||||
|
||||
**Ablauf:**
|
||||
|
||||
| Min. | Inhalt | Methode |
|
||||
|---|---|---|
|
||||
| 0–15 | **Detailversion vorstellen** – Feld für Feld durchgehen: 8 Abschnitte, je Abschnitt die wichtigsten Felder erläutern. Fokus auf die „Warum"-Frage pro Feld. | Präsentation (Folien 9–13) |
|
||||
| 15–20 | **Rückfragen & Markierungen** – Teilnehmende markieren: ✅ sinnvoll / ⚠️ unklar / ❌ überflüssig | Einzelarbeit (Handout) |
|
||||
| 20–30 | **Kurzversion vorstellen** – Die 12 Kernfelder im Vergleich zur Detailversion. Warum genau diese Auswahl? Die vier Leitfragen (Was? Wo? Wer? Wie wichtig?). | Präsentation (Folien 14–16) |
|
||||
| 30–40 | **Gruppenarbeit: Template-Review** – In 2er-Teams: „Fehlt etwas in der Kurzversion? Ist etwas zu viel in der Detailversion?" Ergebnisse auf Moderationskarten. | Gruppenarbeit |
|
||||
| 40–45 | **Zusammenführung** – Moderationskarten clustern, offene Punkte notieren. | Plenum |
|
||||
|
||||
**Benötigte Materialien:**
|
||||
- Ausdruck der Detailversion (Arbeitsmaterial 01, S. 3–5 = Template-Teil)
|
||||
- Ausdruck der Kurzversion (Arbeitsmaterial 02, S. 2–3 = Template + Listenansicht)
|
||||
- Moderationskarten (grün = „passt", gelb = „ändern", rot = „streichen")
|
||||
|
||||
**Moderationshinweis:** Bei Detaildiskussionen über einzelne Enum-Werte (z.B. Kostenmodell-Typen) – auf Parkplatz verschieben. Heute geht es um die Struktur, nicht um jeden Wert.
|
||||
|
||||
---
|
||||
|
||||
### ☕ Pause (15 Min.)
|
||||
|
||||
---
|
||||
|
||||
### Block 3: Quick-Inventory-Übung (30 Min.)
|
||||
|
||||
**Ziel:** Templates werden „erlebbar" durch praktisches Ausfüllen mit fiktiven Services.
|
||||
|
||||
**Ablauf:**
|
||||
|
||||
| Min. | Inhalt | Methode |
|
||||
|---|---|---|
|
||||
| 0–5 | **Aufgabe erklären** – Jedes 2er-Team wählt einen fiktiven Service und füllt die Kurzversion aus. | Moderation |
|
||||
| 5–20 | **Ausfüllen** – Teams arbeiten mit dem Quick-Inventory-Template. Pro Team 1 Service. | Gruppenarbeit |
|
||||
| 20–30 | **Vorstellung & Reflexion** – Jedes Team stellt seinen Service in 2 Min. vor. Gruppe diskutiert: Was war einfach? Was war schwierig? Wo gab es Unklarheiten? | Plenum |
|
||||
|
||||
**Fiktive Services zur Auswahl** (auf Kärtchen vorbereiten):
|
||||
|
||||
| # | Service-Name | Hinweis |
|
||||
|---|---|---|
|
||||
| 1 | Digitaler Arbeitsplatz | Basis-Service, Kategorie A, alle MA |
|
||||
| 2 | SAP-Finanzbuchhaltung | Fachverfahren, Kategorie B, nur Finanzen |
|
||||
| 3 | VPN-Zugang / Homeoffice | Erweiterung, Kategorie B, auf Antrag |
|
||||
| 4 | Konferenztechnik-Verleih | Spezial, Kategorie C, auf Beauftragung |
|
||||
| 5 | IT-Monitoring & Alerting | Interner Service, Kategorie A, nur IT |
|
||||
| 6 | Elektronische Akte (eAkte) | Fachverfahren, Kategorie B, in Einführung (Pipeline) |
|
||||
|
||||
**Reflexionsfragen:**
|
||||
- „Wie lange hat das Ausfüllen gedauert? War das Ziel ‚5–10 Minuten' realistisch?"
|
||||
- „Gab es Felder, bei denen ihr unsicher wart?"
|
||||
- „Würde ein Service Owner das allein ausfüllen können?"
|
||||
|
||||
---
|
||||
|
||||
### Block 4: Katalogstruktur-Varianten (40 Min.)
|
||||
|
||||
**Ziel:** Die drei Varianten sind verstanden, eine Tendenz/Entscheidung ist erreicht.
|
||||
|
||||
**Ablauf:**
|
||||
|
||||
| Min. | Inhalt | Methode |
|
||||
|---|---|---|
|
||||
| 0–15 | **Drei Varianten vorstellen** – Je 5 Min. pro Variante: Idee, Struktur-Baum, Vor-/Nachteile | Präsentation (Folien 17–22) |
|
||||
| 15–20 | **Vergleichsmatrix** – Alle drei Varianten nebeneinander. Kriterien gemeinsam durchgehen. | Präsentation (Folie 23) |
|
||||
| 20–30 | **Praxistest: „Finde den Service"** – Szenario-Karten: Teilnehmende müssen fiktive Services in jeder Variante einordnen. Welche Struktur macht es am leichtesten? | Gruppenübung |
|
||||
| 30–40 | **Diskussion & Abstimmung** – Welche Variante bevorzugt die Gruppe? Gibt es Hybrid-Wünsche? | Plenum |
|
||||
|
||||
**Szenario-Karten für den Praxistest:**
|
||||
|
||||
| Szenario | Frage |
|
||||
|---|---|
|
||||
| „Ich bin neu in der Stadtverwaltung und brauche einen Laptop." | In welcher Kategorie suche ich? |
|
||||
| „Unser Amt möchte ein neues Fachverfahren für Baugenehmigungen." | Wo finde ich, ob DIGIT das anbietet? |
|
||||
| „Ich arbeite ab nächster Woche im Homeoffice." | Welchen Service muss ich beantragen? |
|
||||
| „Meine Abteilungsleitung fragt, was DIGIT pro Arbeitsplatz kostet." | Wo finde ich eine Kostenübersicht? |
|
||||
| „Ich bin IT-Admin und brauche einen neuen Server für ein Projekt." | Wie bestelle ich das? |
|
||||
|
||||
**Moderationshinweis:** Wenn die Gruppe sich nicht einigen kann, Variante C (Hybrid mit A/B/C) als Empfehlung einbringen – sie bietet die höchste Flexibilität und nutzt die bestehende DIGIT-Logik.
|
||||
|
||||
---
|
||||
|
||||
### Block 5: Entscheidungen & nächste Schritte (20 Min.)
|
||||
|
||||
**Ziel:** Verbindliche Festlegungen und klare nächste Schritte.
|
||||
|
||||
**Ablauf:**
|
||||
|
||||
| Min. | Inhalt | Methode |
|
||||
|---|---|---|
|
||||
| 0–10 | **Entscheidungen festhalten** – Zu jedem Artefakt: Was ist beschlossen? Was ist offen? | Moderation |
|
||||
| 10–20 | **Nächste Schritte & Verantwortlichkeiten** | Moderation |
|
||||
|
||||
**Entscheidungsmatrix (am Flipchart):**
|
||||
|
||||
| Thema | Entscheidung | Status | Verantwortlich |
|
||||
|---|---|---|---|
|
||||
| Portfolio Detailversion | Template passt / wird angepasst (was?) | ☐ Beschlossen ☐ Offen | |
|
||||
| Portfolio Kurzversion | Template passt / wird angepasst (was?) | ☐ Beschlossen ☐ Offen | |
|
||||
| Katalogstruktur | Variante A / B / C / Hybrid | ☐ Beschlossen ☐ Offen | |
|
||||
| Erfassungsmethode | Dezentral (Service Owner) / Zentral (SPM) | ☐ Beschlossen ☐ Offen | |
|
||||
| Nächster Schritt | Quick Inventory mit echten Services starten | ☐ Beschlossen ☐ Offen | |
|
||||
|
||||
**Typische nächste Schritte:**
|
||||
1. Templates gemäß Feedback anpassen (SPM-Team, 1 Woche)
|
||||
2. Quick-Inventory-Phase starten – Service Owner füllen Kurzversion aus (2–4 Wochen)
|
||||
3. Konsolidierung und Deduplizierung (SPM-Team, 1 Woche)
|
||||
4. Follow-up-Session: Erste echte Services reviewen und Katalogstruktur befüllen
|
||||
|
||||
---
|
||||
|
||||
### Abschluss (15 Min.)
|
||||
|
||||
- Kurzes Blitzlicht: „Was nehme ich mit? Was ist noch offen?"
|
||||
- Dank an Teilnehmende
|
||||
- Protokoll-Versand ankündigen (innerhalb 3 Werktage)
|
||||
|
||||
---
|
||||
|
||||
## 4. Checkliste Vorbereitung
|
||||
|
||||
### Materialien
|
||||
|
||||
- [ ] Präsentation (PPTX) auf Laptop geladen und Beamer-Test gemacht
|
||||
- [ ] Arbeitsmaterial 01 (Detailversion) – ausgedruckt, 1x pro Teilnehmer
|
||||
- [ ] Arbeitsmaterial 02 (Kurzversion) – ausgedruckt, 1x pro Teilnehmer
|
||||
- [ ] Arbeitsmaterial 03 (Katalogvarianten) – ausgedruckt, 1x pro Teilnehmer
|
||||
- [ ] Moderationskarten (grün/gelb/rot) – ca. 30 Stück
|
||||
- [ ] Szenario-Karten für Praxistest – 5 Stück (ggf. laminiert)
|
||||
- [ ] Fiktive-Service-Kärtchen – 6 Stück für Quick-Inventory-Übung
|
||||
- [ ] Flipchart oder Whiteboard für Entscheidungsmatrix
|
||||
- [ ] Stifte (Edding + Kugelschreiber für jeden TN)
|
||||
|
||||
### Raum
|
||||
|
||||
- [ ] Beamer + Bildschirm
|
||||
- [ ] Tische für Gruppenarbeit (2er-Teams)
|
||||
- [ ] Flipchart
|
||||
- [ ] Getränke & Snacks für Pause
|
||||
|
||||
### Nachbereitung
|
||||
|
||||
- [ ] Fotos von Flipchart/Moderationskarten sichern
|
||||
- [ ] Protokoll erstellen (Entscheidungen + offene Punkte)
|
||||
- [ ] Templates bei Bedarf anpassen
|
||||
- [ ] Protokoll + angepasste Templates versenden (innerhalb 3 WT)
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
# Arbeitsmaterialien SPM
|
||||
|
||||
Dieser Ordner enthält operative Vorlagen, Templates und Checklisten
|
||||
zur Umsetzung der SPM-Konzepte.
|
||||
|
||||
## Status
|
||||
| Datei | Version | Status |
|
||||
|-------|---------|--------|
|
||||
| template_sls.md | - | ausstehend |
|
||||
| template_sla-kategorie-a.md | - | ausstehend |
|
||||
| 06_template_ola-kategorie-i.yaml | 1.0 | Entwurf (Pilotphase) |
|
||||
| 07_leitfaden_sieben-fragen-orientierung.yaml | 1.0 | Final |
|
||||
| ... | | |
|
||||
|
||||
## Hinweise
|
||||
- Templates sind "lebende Dokumente" und werden iterativ weiterentwickelt
|
||||
- Änderungen an Templates erfordern keine Konzept-Anpassung
|
||||
- Finale Templates werden im DIGIT-Dokumentenmanagement versioniert
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# SPM Governance-Entscheidungs-Log
|
||||
|
||||
**Zweck:** Sammlung aller Governance-Entscheidungen, die während der Entwicklung der SPM-Konzepte getroffen werden. Dient als Quelle für die Konsolidierung in G-01 (Portfolio Governance), G-02 (SOR Geschäftsordnung) und G-03 (Portfolio Review Prozess).
|
||||
|
||||
**Letzte Aktualisierung:** 2025-11-26
|
||||
|
||||
---
|
||||
|
||||
## Entscheidungen
|
||||
|
||||
```yaml
|
||||
entscheidungen:
|
||||
|
||||
# ==========================================================================
|
||||
# P-02 SERVICE LEVEL MANAGEMENT
|
||||
# ==========================================================================
|
||||
|
||||
# [Beispiel-Struktur - wird während Chat P-02 befüllt]
|
||||
#
|
||||
# - id: GOV-001
|
||||
# datum: 2025-11-26
|
||||
# quelle_modul: "P-02 Service Level Management"
|
||||
# quelle_chat: "[Link zum Chat]"
|
||||
#
|
||||
# frage: "Wer genehmigt SLA-Definitionen für neue Services?"
|
||||
#
|
||||
# entscheidung: |
|
||||
# - Standard-SLAs (aus Katalog): Service Owner allein
|
||||
# - Individuelle SLAs: SOR-Freigabe erforderlich
|
||||
#
|
||||
# begründung: |
|
||||
# Analog zur Klassifizierungslogik im DPM. Standard-SLAs sind bereits
|
||||
# durch Portfolio-Governance abgedeckt, individuelle Abweichungen
|
||||
# erfordern Gremienentscheidung wegen Ressourcen-/Risiko-Implikationen.
|
||||
#
|
||||
# auswirkung_auf:
|
||||
# - dokument: "G-01 Portfolio Governance"
|
||||
# abschnitt: "Entscheidungsmatrix"
|
||||
# - dokument: "G-02 SOR Geschäftsordnung"
|
||||
# abschnitt: "Entscheidungsgegenstände"
|
||||
# - dokument: "R-01 Service Owner"
|
||||
# abschnitt: "Entscheidungsbefugnisse"
|
||||
#
|
||||
# status: "final" # draft | review | final
|
||||
#
|
||||
# abhängig_von: [] # Liste von GOV-IDs falls Abhängigkeit
|
||||
#
|
||||
# offene_fragen: [] # Falls noch Klärungsbedarf
|
||||
|
||||
# ==========================================================================
|
||||
# P-01 SERVICE CATALOG MANAGEMENT
|
||||
# ==========================================================================
|
||||
|
||||
# [Wird während Chat P-01 befüllt]
|
||||
|
||||
# ==========================================================================
|
||||
# S-01 SCHNITTSTELLE DPM → SPM
|
||||
# ==========================================================================
|
||||
|
||||
# [Wird während Chat S-01 befüllt]
|
||||
|
||||
# ==========================================================================
|
||||
# WEITERE MODULE
|
||||
# ==========================================================================
|
||||
|
||||
# [Fortlaufend ergänzen]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Konsolidierungs-Tracking
|
||||
|
||||
| Ziel-Dokument | Relevante GOV-IDs | Status |
|
||||
|---------------|-------------------|--------|
|
||||
| G-01 Portfolio Governance | | Ausstehend |
|
||||
| G-02 SOR Geschäftsordnung | | Ausstehend |
|
||||
| G-03 Portfolio Review Prozess | | Ausstehend |
|
||||
|
||||
---
|
||||
|
||||
## Offene Fragen (zur späteren Klärung)
|
||||
|
||||
```yaml
|
||||
offene_fragen:
|
||||
|
||||
# [Beispiel-Struktur]
|
||||
#
|
||||
# - id: OPEN-001
|
||||
# datum: 2025-11-26
|
||||
# quelle_modul: "P-02 Service Level Management"
|
||||
#
|
||||
# frage: "Wie verhält sich SLA-Eskalation zur DSR-Eskalation im DPM?"
|
||||
#
|
||||
# kontext: |
|
||||
# Bei SLA-Verletzungen könnte Eskalation sowohl über SOR (operativ)
|
||||
# als auch über DSR (strategisch) laufen. Abgrenzung unklar.
|
||||
#
|
||||
# zu_klären_in: "G-01 oder separater Abstimmung DPM/SPM"
|
||||
#
|
||||
# status: "offen" # offen | in_klärung | geklärt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Änderungshistorie
|
||||
|
||||
| Datum | Änderung | Autor |
|
||||
|-------|----------|-------|
|
||||
| 2025-11-26 | Template erstellt | Claude/Meta-Chat |
|
||||
|
|
@ -0,0 +1,311 @@
|
|||
# SPM Konzept-Sprint: Konsolidierte MVP-Liste
|
||||
|
||||
**Version:** 1.1
|
||||
**Datum:** 2025-11-26
|
||||
**Kontext:** DIGITOM Service-Portfolio-Management
|
||||
**Änderung v1.1:** Bottom-Up-Ansatz, revidierte Sprint-Reihenfolge
|
||||
|
||||
---
|
||||
|
||||
## Methodischer Ansatz: Bottom-Up
|
||||
|
||||
### Grundprinzip
|
||||
|
||||
Governance-Strukturen werden **nicht vorab definiert**, sondern **emergieren aus der Entwicklung der operativen Konzepte**.
|
||||
|
||||
**Begründung (systemtheoretisch):**
|
||||
- Strukturen emergieren aus Operationen, nicht umgekehrt
|
||||
- Governance ist Beobachtung zweiter Ordnung – sie beobachtet, wie das System sich selbst steuert
|
||||
- Governance-Fragen werden erst durch konkrete Anwendungsfälle sichtbar
|
||||
|
||||
### Umsetzung
|
||||
|
||||
Bei der Entwicklung jeder Practice werden Governance-Fragen **direkt geklärt** (nicht nur markiert). Diese Entscheidungen werden im **Governance-Entscheidungs-Log** dokumentiert und später in die Governance-Dokumente (G-01, G-02, G-03) konsolidiert.
|
||||
|
||||
```yaml
|
||||
# Beispiel: In practice_service-level-management.yaml
|
||||
aktivitaeten:
|
||||
- id: slm_03
|
||||
name: "SLA-Änderung genehmigen"
|
||||
governance_entscheidung:
|
||||
frage: "Wer genehmigt SLA-Änderungen?"
|
||||
entscheidung: "SOR bei Änderungen >10% Abweichung, SO bei Minor-Anpassungen"
|
||||
begründung: "Analog zur Change-Klassifizierung im DPM"
|
||||
source_für: "G-01 Portfolio Governance, Abschnitt Entscheidungsmatrix"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Arbeitsstruktur
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ GIT REPOSITORY │
|
||||
│ (Single Source of Truth) │
|
||||
│ - spm_vorgehen-entwicklung-spm-mvp-konzept.md │
|
||||
│ - spm_governance-entscheidungen-log.yaml │
|
||||
│ - Practice-YAMLs, Blueprint-Erweiterungen │
|
||||
│ - Finale Governance-Dokumente (konsolidiert) │
|
||||
└───────────────────────┬─────────────────────────────────┘
|
||||
│
|
||||
┌─────────────┼─────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
│ Meta-Chat│ │ Chat: │ │ Chat: │
|
||||
│ │ │ P-02 SLM │ │ P-01 SCM │
|
||||
│ Übersicht│ │ │ │ │
|
||||
│ Prio │ │ Detail- │ │ Detail- │
|
||||
│ Kurs- │ │ arbeit │ │ arbeit │
|
||||
│ korrektur│ │ │ │ │
|
||||
└──────────┘ └──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
### Rückfluss-Protokoll
|
||||
|
||||
Nach Abschluss jedes Konzept-Chats:
|
||||
1. Ergebnis im Git-Repo dokumentieren (YAML/MD)
|
||||
2. Governance-Entscheidungen ins Log eintragen
|
||||
3. Im Meta-Chat kurz zusammenfassen: "Modul X fertig, Y Governance-Entscheidungen, Z offene Fragen"
|
||||
|
||||
---
|
||||
|
||||
## Zielstruktur Repository
|
||||
```
|
||||
02.1_spm_konzepte/
|
||||
│
|
||||
├── 01_governance/
|
||||
│ ├── spm_governance_anker.yaml [existiert – Placeholder]
|
||||
│ ├── spm_portfolio-governance.yaml [emergiert am Ende]
|
||||
│ ├── spm_portfolio-review-konzept.yaml [NEU – Prio HOCH]
|
||||
│ └── spm_sor-geschaeftsordnung.yaml [NEU – Prio HOCH]
|
||||
│
|
||||
├── 02_service-lifecycle-blueprint/
|
||||
│ ├── readme.md
|
||||
│ ├── spm_rollen.yaml [existiert – Kurzreferenz]
|
||||
│ ├── service-lifecycle_service-entwicklung.yaml [existiert]
|
||||
│ ├── service-lifecycle_service-transition.yaml [existiert]
|
||||
│ ├── service-lifecycle_service-betrieb.yaml [existiert]
|
||||
│ ├── service-lifecycle_service-support.yaml [existiert]
|
||||
│ └── service-lifecycle_service-review.yaml [existiert]
|
||||
│
|
||||
├── 02a_lifecycle-konzepte/ [NEU – Ordner]
|
||||
│ ├── konzept_service-transition.yaml [NEU – Prio MITTEL]
|
||||
│ └── konzept_service-betrieb-light.yaml [NEU – Prio MITTEL-HOCH]
|
||||
│
|
||||
├── 03_practices/
|
||||
│ ├── spm_practice_service-level-management.yaml
|
||||
│ ├── spm_practice_service-catalog-management.yaml
|
||||
│ ├── spm_practice_change-enablement.yaml [ausstehend]
|
||||
│ └── spm_practice_service-support-management/
|
||||
│ ├── ssm_governance.yaml
|
||||
│ ├── ssm_rollen.yaml
|
||||
│ ├── sub-practice_incident-management.yaml
|
||||
│ ├── sub-practice_request-management.yaml
|
||||
│ ├── sub-practice_service-desk.yaml
|
||||
│ └── sub-practice_problem-management.yaml
|
||||
│
|
||||
├── 04_rollen/
|
||||
│ ├── rolle_service-owner.yaml [NEU – Prio HOCH]
|
||||
│ └── rolle_service-portfolio-manager.yaml [NEU – Prio HOCH]
|
||||
│
|
||||
├── 05_schnittstellen/
|
||||
│ ├── schnittstelle_dpm-spm.yaml [ausstehend]
|
||||
│ └── schnittstelle_spm-ppm.yaml [ausstehend]
|
||||
│
|
||||
├── 06_Informationsmodell/
|
||||
│ ├── spm_schema_service-definition.yaml [existiert]
|
||||
│ └── spm_schema_service-steckbrief.yaml [existiert]
|
||||
│
|
||||
└── 07_arbeitsmaterialien/
|
||||
├── README_arbeitsmaterialien.md [existiert]
|
||||
└── [Templates – ausstehend]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Erweiterte Modulliste (Update Dezember 2025)
|
||||
|
||||
### Neue Module (nicht im ursprünglichen Plan)
|
||||
|
||||
| ID | Modul | Typ | Priorität | Status |
|
||||
|----|-------|-----|-----------|--------|
|
||||
| G-SOR | SOR Geschäftsordnung | Gremien-GO | HOCH | placeholder |
|
||||
| G-PR | Portfolio Review Konzept | Methodik | HOCH | placeholder |
|
||||
| R-SO | Rolle Service Owner (vollständig) | Rollenbeschreibung | HOCH | placeholder |
|
||||
| R-SPM | Rolle SPM (vollständig) | Rollenbeschreibung | HOCH | placeholder |
|
||||
| K-TR | Rahmenkonzept Service Transition | Konzept | MITTEL | placeholder |
|
||||
| K-BL | Service Betrieb (Light-Weight) | Konzept | MITTEL-HOCH | placeholder |
|
||||
|
||||
### Begründung der Erweiterung
|
||||
|
||||
**Workshop-Befund (Dez 2025):** Ohne minimale Strukturelemente für den Service-Betrieb fehlt die Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft muss sich im Modell wiederfinden.
|
||||
|
||||
**Strukturelle Lücke:** Blueprints definieren Aktivitäten und RACI, aber keine Governance-Logik oder Entscheidungsprinzipien. Die neuen Konzept-Dokumente schließen diese Lücke.
|
||||
|
||||
### Dokumenttyp-Unterscheidung
|
||||
|
||||
| Typ | Charakter | Beispiel |
|
||||
|-----|-----------|----------|
|
||||
| **Blueprint** | Phasen, Aktivitäten, RACI-Zuordnung | service-lifecycle_*.yaml |
|
||||
| **Konzept** | Governance, Prinzipien, Entscheidungslogik | konzept_*.yaml |
|
||||
| **Rollenbeschreibung** | Vollständige Rolle (analog SHM-Rollen) | rolle_*.yaml |
|
||||
| **Geschäftsordnung** | Gremienregeln, Zusammensetzung, Rhythmus | *_geschaeftsordnung.yaml |
|
||||
|
||||
---
|
||||
|
||||
## MVP-Module im Detail
|
||||
|
||||
### Cluster 1: Practices (ITIL4-aligned)
|
||||
|
||||
| ID | Modul | ITIL4 Practice | Aktiviert in Phase(n) | Status |
|
||||
|----|-------|----------------|----------------------|--------|
|
||||
| P-01 | **Service Catalog Management** | Service Catalogue Management | Transition, Review | Ausstehend |
|
||||
| P-02 | **Service Level Management** | Service Level Management | Transition, Betrieb, Review | **START** |
|
||||
| P-03 | **Change Enablement** | Change Enablement | Entwicklung, Transition | Ausstehend |
|
||||
| P-04 | **Incident Management** | Incident Management | Support | Ausstehend |
|
||||
| P-05 | **Request Management** | Service Request Management | Support | Ausstehend |
|
||||
| P-06 | **Problem Management** | Problem Management | Support, Review | Ausstehend |
|
||||
| P-07 | **Monitoring & Event Mgmt** | Monitoring and Event Management | Betrieb, Support | Ausstehend |
|
||||
|
||||
### Cluster 2: Blueprint-Erweiterungen
|
||||
|
||||
| ID | Modul | Status |
|
||||
|----|-------|--------|
|
||||
| B-01 | **service_transition.yaml** | Existiert (draft), erweitern |
|
||||
| B-02 | **service_betrieb.yaml** | NEU erstellen |
|
||||
| B-03 | **service_review.yaml** | NEU erstellen |
|
||||
|
||||
### Cluster 3: Rollen-Module
|
||||
|
||||
| ID | Modul | Status |
|
||||
|----|-------|--------|
|
||||
| R-01 | **Service Owner** | In spm_rollen.yaml, ggf. erweitern |
|
||||
| R-02 | **Service-Portfolio-Manager** | In spm_rollen.yaml, ggf. erweitern |
|
||||
| R-03 | **Service Owner Playbook** | NEU erstellen |
|
||||
| R-04 | **Weitere Rollen** | Nach Bedarf |
|
||||
|
||||
### Cluster 4: Schnittstellen
|
||||
|
||||
| ID | Modul | Status |
|
||||
|----|-------|--------|
|
||||
| S-01 | **Schnittstelle DPM → SPM** | NEU erstellen (kritisch) |
|
||||
| S-02 | **Schnittstelle SPM → PPM** | NEU erstellen |
|
||||
|
||||
### Cluster 5: Governance (emergiert)
|
||||
|
||||
| ID | Modul | Status |
|
||||
|----|-------|--------|
|
||||
| G-01 | **Portfolio Governance** | Konsolidierung am Ende |
|
||||
| G-02 | **SOR Geschäftsordnung** | Konsolidierung am Ende |
|
||||
| G-03 | **Portfolio Review Prozess** | Konsolidierung am Ende |
|
||||
|
||||
---
|
||||
|
||||
## Revidierte Sprint-Reihenfolge (Bottom-Up)
|
||||
|
||||
### Phase 1: Kern-Practices mit Governance-Entscheidungen
|
||||
|
||||
| # | Modul | Ziel | Governance-Output |
|
||||
|---|-------|------|-------------------|
|
||||
| 1 | **P-02 Service Level Management** | SLA-Lifecycle definieren | Wer genehmigt SLAs? Wer monitort? Eskalation bei Verletzung? |
|
||||
| 2 | **P-01 Service Catalog Management** | Katalogstruktur, Einträge | Wer pflegt Katalog? Wer genehmigt Aufnahme? |
|
||||
| 3 | **S-01 Schnittstelle DPM→SPM** | Übergabelogik | Quality Gate zwischen Lifecycles |
|
||||
|
||||
### Phase 2: Rollen und Transition
|
||||
|
||||
| # | Modul | Ziel | Governance-Output |
|
||||
|---|-------|------|-------------------|
|
||||
| 4 | **R-01/R-02 Rollen erweitern** | Verantwortlichkeiten schärfen | RACI-Grundlage |
|
||||
| 5 | **B-01 Service Transition erweitern** | Kritische Phase detaillieren | SOR-Entscheidungspunkte |
|
||||
| 6 | **P-03 Change Enablement** | Abgrenzung Standard vs. Demand | Routing-Logik zu DPM |
|
||||
|
||||
### Phase 3: Support-Prozesse
|
||||
|
||||
| # | Modul | Ziel | Governance-Output |
|
||||
|---|-------|------|-------------------|
|
||||
| 7 | **P-04 Incident Management** | Incident-Lifecycle | Eskalationswege, SLA-Bezug |
|
||||
| 8 | **P-05 Request Management** | Request-Katalog | Genehmigungslogik |
|
||||
| 9 | **B-02 Service Betrieb** | Blueprint vervollständigen | Betriebsverantwortung |
|
||||
|
||||
### Phase 4: Review und Verbesserung
|
||||
|
||||
| # | Modul | Ziel | Governance-Output |
|
||||
|---|-------|------|-------------------|
|
||||
| 10 | **B-03 Service Review** | Improvement-Loop | Review-Entscheidungen (Improve/Redesign/Retire) |
|
||||
| 11 | **R-03 Service Owner Playbook** | Rolle operationalisieren | Handlungsanweisungen |
|
||||
| 12 | **P-06 Problem Management** | Strukturelle Fehleranalyse | Schnittstelle zu Change |
|
||||
|
||||
### Phase 5: Governance-Konsolidierung
|
||||
|
||||
| # | Modul | Ziel |
|
||||
|---|-------|------|
|
||||
| 13 | **G-01 Portfolio Governance** | Alle Entscheidungen aus Log konsolidieren |
|
||||
| 14 | **G-02 SOR Geschäftsordnung** | Gremienregeln formalisieren |
|
||||
| 15 | **G-03 Portfolio Review Prozess** | Strategischen Zyklus definieren |
|
||||
|
||||
### Phase 6: Vertiefung (optional)
|
||||
|
||||
| # | Modul |
|
||||
|---|-------|
|
||||
| 16 | P-07 Monitoring & Event Management |
|
||||
| 17 | R-04 Weitere Rollen |
|
||||
| 18 | S-02 Schnittstelle SPM→PPM |
|
||||
|
||||
---
|
||||
|
||||
## Offene Entscheidungen
|
||||
|
||||
| Frage | Optionen | Empfehlung | Status |
|
||||
|-------|----------|------------|--------|
|
||||
| Separate Rollen-Dokumente oder Integration in `spm_rollen.yaml`? | A) Separate / B) Integration | B) für MVP | Offen |
|
||||
| Incident + Request als ein oder zwei Module? | A) Kombiniert / B) Getrennt | B) ITIL4-konform | Offen |
|
||||
| Service Desk Governance: eigenes Dokument oder Teil von G-01? | A) Separat / B) Integriert | B) Teil von G-01 | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Aktueller Stand
|
||||
|
||||
| Modul | Status | Chat | Datum |
|
||||
|-------|--------|------|-------|
|
||||
| P-02 Service Level Management | In Arbeit | [Link] | 2025-11-26 |
|
||||
| ... | ... | ... | ... |
|
||||
|
||||
---
|
||||
|
||||
## Modul-Status (Stand: 2025-12-15)
|
||||
|
||||
### Governance & Gremien
|
||||
| ID | Modul | Pfad | Status |
|
||||
|----|-------|------|--------|
|
||||
| G-SOR | SOR Geschäftsordnung | `01_governance/spm_sor-geschaeftsordnung.yaml` | placeholder |
|
||||
| G-PR | Portfolio Review Konzept | `01_governance/spm_portfolio-review-konzept.yaml` | placeholder |
|
||||
|
||||
### Rollen (vollständig)
|
||||
| ID | Modul | Pfad | Status |
|
||||
|----|-------|------|--------|
|
||||
| R-SO | Service Owner | `04_rollen/rolle_service-owner.yaml` | placeholder |
|
||||
| R-SPM | Service-Portfolio-Manager | `04_rollen/rolle_service-portfolio-manager.yaml` | placeholder |
|
||||
|
||||
### Lifecycle-Konzepte
|
||||
| ID | Modul | Pfad | Status |
|
||||
|----|-------|------|--------|
|
||||
| K-TR | Rahmenkonzept Transition | `02a_lifecycle-konzepte/konzept_service-transition.yaml` | placeholder |
|
||||
| K-BL | Service Betrieb (Light) | `02a_lifecycle-konzepte/konzept_service-betrieb-light.yaml` | placeholder |
|
||||
|
||||
### Abhängigkeiten
|
||||
```
|
||||
G-SOR ──► G-PR (Review braucht SOR-Entscheidungslogik)
|
||||
──► K-TR (Transition-Gates sind SOR-Entscheidungen)
|
||||
R-SO ──► K-BL (Betriebsrollen brauchen SO-Abgrenzung)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Änderungshistorie
|
||||
|
||||
| Version | Datum | Änderung |
|
||||
|---------|-------|----------|
|
||||
| 1.0 | 2025-11-26 | Initiale Erstellung |
|
||||
| 1.1 | 2025-11-26 | Bottom-Up-Ansatz, revidierte Sprint-Reihenfolge, Arbeitsstruktur |
|
||||
| 1.2 | 2025-12-15 | Erweiterte Modulliste (G-SOR, G-PR, R-SO, R-SPM, K-TR, K-BL), Ordner 02a_lifecycle-konzepte, Dokumenttyp-Unterscheidung |
|
||||
Loading…
Add table
Add a link
Reference in a new issue