digitom-sync-hook 6a3299ed48 sync: initial full sync to match digitom HEAD

2026-04-11 21:57:43 +00:00

13 KiB

Raw Permalink Blame History

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.

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

Ergebnis im Git-Repo dokumentieren (YAML/MD)
Governance-Entscheidungen ins Log eintragen
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

13 KiB Raw Permalink Blame History Unescape Escape