# 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 |