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
|
|
@ -1,329 +0,0 @@
|
|||
meta:
|
||||
typ: "bewertungsmatrix"
|
||||
dimension: "komplexitaet"
|
||||
titel: "Klassifizierungsmatrix Komplexität"
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"]
|
||||
status: "abgenommen_in_gesamtkonzept"
|
||||
|
||||
referenzen:
|
||||
teil_von: "#01.4_methodik/demand-klassifizierung.yaml"
|
||||
verwendet_in: "#01.4_methodik/demand-bewertung.yaml"
|
||||
|
||||
kontext_tags:
|
||||
- "komplexitaet"
|
||||
- "loesungsunsicherheit"
|
||||
- "bewertungsmatrix"
|
||||
|
||||
# ========================================
|
||||
# ZWECK
|
||||
# ========================================
|
||||
|
||||
zweck:
|
||||
beschreibung: |
|
||||
Diese Bewertungsmatrix unterstützt die Einschätzung der Komplexität von Demands.
|
||||
Sie operationalisiert die Dimension "Komplexität" aus dem Klassifizierungsmodell
|
||||
und hilft DPM, die Lösungsunsicherheit und den Koordinationsaufwand strukturiert
|
||||
zu bewerten.
|
||||
|
||||
grundverstaendnis: |
|
||||
Komplexität im DPM-Kontext bedeutet nicht primär technische Schwierigkeit,
|
||||
sondern die Unsicherheit über Lösung, Aufwand und Abhängigkeiten. Ein technisch
|
||||
einfacher Demand kann hochkomplex sein, wenn viele Stakeholder mit unterschiedlichen
|
||||
Interessen involviert sind.
|
||||
|
||||
# ========================================
|
||||
# BEWERTUNGSDIMENSIONEN
|
||||
# ========================================
|
||||
|
||||
bewertungsdimensionen:
|
||||
anzahl: 4
|
||||
beschreibung: "Vier orthogonale Bewertungsdimensionen zur Komplexitätseinschätzung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 1: STAKEHOLDER & KOORDINATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_1_stakeholder_koordination:
|
||||
id: "stakeholder_koordination"
|
||||
name: "Stakeholder & Koordination"
|
||||
leitfrage: "Wie viele Akteure müssen koordiniert werden?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "beteiligte_teams"
|
||||
name: "Beteiligte Teams"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Teams"
|
||||
komplex: "3-4 Teams"
|
||||
hochkomplex: "5+ Teams"
|
||||
|
||||
- kriterium_id: "stakeholder_gruppen"
|
||||
name: "Stakeholder-Gruppen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Gruppen"
|
||||
komplex: "3-5 Gruppen"
|
||||
hochkomplex: "6+ Gruppen"
|
||||
|
||||
- kriterium_id: "entscheidungsebene"
|
||||
name: "Entscheidungsebene"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Arbeitsebene"
|
||||
komplex: "Abteilungsleitung"
|
||||
hochkomplex: "Amtsleitung/Politik"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 2: LÖSUNGSRAUM & UNSICHERHEIT
|
||||
# ----------------------------------
|
||||
|
||||
dimension_2_loesungsraum_unsicherheit:
|
||||
id: "loesungsraum_unsicherheit"
|
||||
name: "Lösungsraum & Unsicherheit"
|
||||
leitfrage: "Wie klar ist der Weg zur Lösung?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "loesungsklarheit"
|
||||
name: "Lösungsklarheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Eindeutige Lösung"
|
||||
komplex: "2-3 Optionen"
|
||||
hochkomplex: "Unklar/Exploration nötig"
|
||||
|
||||
- kriterium_id: "technologie_reife"
|
||||
name: "Technologie-Reife"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Bewährt im DIGIT"
|
||||
komplex: "Neu für DIGIT"
|
||||
hochkomplex: "Innovativ/Experimentell"
|
||||
|
||||
- kriterium_id: "anforderungsstabilitaet"
|
||||
name: "Anforderungsstabilität"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Stabil & klar"
|
||||
komplex: "Teilweise unklar"
|
||||
hochkomplex: "Volatil/Undefiniert"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 3: ABHÄNGIGKEITEN & INTEGRATION
|
||||
# ----------------------------------
|
||||
|
||||
dimension_3_abhaengigkeiten_integration:
|
||||
id: "abhaengigkeiten_integration"
|
||||
name: "Abhängigkeiten & Integration"
|
||||
leitfrage: "Wie vernetzt ist der Demand?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "externe_partner"
|
||||
name: "Externe Partner"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "1-2 Partner"
|
||||
hochkomplex: "3+ Partner"
|
||||
|
||||
- kriterium_id: "system_schnittstellen"
|
||||
name: "System-Schnittstellen"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "1-2 Systeme"
|
||||
komplex: "3-4 Systeme"
|
||||
hochkomplex: "5+ Systeme"
|
||||
|
||||
- kriterium_id: "zeitliche_abhaengigkeiten"
|
||||
name: "Zeitliche Abhängigkeiten"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Flexibel planbar"
|
||||
komplex: "Teilweise gebunden"
|
||||
hochkomplex: "Kritische Verkettung"
|
||||
|
||||
# ----------------------------------
|
||||
# DIMENSION 4: RISIKEN & UNWÄGBARKEITEN
|
||||
# ----------------------------------
|
||||
|
||||
dimension_4_risiken_unwaegbarkeiten:
|
||||
id: "risiken_unwaegbarkeiten"
|
||||
name: "Risiken & Unwägbarkeiten"
|
||||
leitfrage: "Wie beherrschbar sind die Risiken?"
|
||||
|
||||
kriterien:
|
||||
- kriterium_id: "budget_unsicherheit"
|
||||
name: "Budget-Unsicherheit"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Verlässlich planbar"
|
||||
komplex: "Bandbreiten-Schätzung"
|
||||
hochkomplex: "Unkalkulierbar"
|
||||
|
||||
- kriterium_id: "termin_risiko"
|
||||
name: "Termin-Risiko"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Gering"
|
||||
komplex: "Mittel"
|
||||
hochkomplex: "Hoch/Unklar"
|
||||
|
||||
- kriterium_id: "compliance_risiken"
|
||||
name: "Compliance-Risiken"
|
||||
|
||||
auspraegungen:
|
||||
moderat: "Keine"
|
||||
komplex: "Handhabbar"
|
||||
hochkomplex: "Kritisch/Unklar"
|
||||
|
||||
# ========================================
|
||||
# SIGNALE FÜR HOCHKOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
signale_hochkomplexitaet:
|
||||
beschreibung: "Qualitative Indikatoren, die auf Hochkomplexität hindeuten"
|
||||
|
||||
signale:
|
||||
- id: "paradoxe_anforderungen"
|
||||
signal: "Paradoxe Anforderungen"
|
||||
beispiel: "\"Soll alles können, darf nichts kosten\""
|
||||
interpretation: "Fundamentale Zielkonflikte zwischen Stakeholdern"
|
||||
|
||||
- id: "moving_targets"
|
||||
signal: "Moving Targets"
|
||||
beschreibung: "Anforderungen ändern sich während der Analyse"
|
||||
interpretation: "Instabile Ausgangslage, hohe Unsicherheit"
|
||||
|
||||
- id: "interessenskomplexitaet"
|
||||
signal: "Interessenskomplexität"
|
||||
beschreibung: "Vielschichtige, teils unausgesprochene Stakeholder-Motivationen"
|
||||
interpretation: "Verdeckte Agenden, schwierige Konsensfindung"
|
||||
|
||||
- id: "regulatorische_grauzonen"
|
||||
signal: "Regulatorische Grauzonen"
|
||||
beschreibung: "Rechtslage unklar oder im Wandel"
|
||||
interpretation: "Compliance-Risiko, Neuorientierung erforderlich"
|
||||
|
||||
- id: "praezedenzfall"
|
||||
signal: "Präzedenzfall"
|
||||
beschreibung: "Erstmalige Herausforderung ohne Referenz"
|
||||
interpretation: "Kein Erfahrungswissen, explorativer Ansatz nötig"
|
||||
|
||||
# ========================================
|
||||
# ANWENDUNG DER MATRIX
|
||||
# ========================================
|
||||
|
||||
anwendung:
|
||||
bewertungsverfahren:
|
||||
beschreibung: "Strukturierter Prozess zur Komplexitätseinschätzung"
|
||||
|
||||
schritte:
|
||||
- schritt: 1
|
||||
name: "Dimension-Scoring"
|
||||
beschreibung: "Jede der vier Dimensionen separat bewerten"
|
||||
output: "4 Einzelbewertungen (moderat/komplex/hochkomplex)"
|
||||
|
||||
- schritt: 2
|
||||
name: "Komplexitäts-Aggregation"
|
||||
beschreibung: "Die höchste Einzelbewertung plus Anzahl der \"Komplex\"- oder \"Hochkomplex\"-Bewertungen"
|
||||
logik: "siehe aggregationslogik unten"
|
||||
|
||||
- schritt: 3
|
||||
name: "Kontextuelle Anpassung"
|
||||
beschreibung: "Berücksichtigung verwaltungsspezifischer Faktoren"
|
||||
|
||||
aggregationslogik:
|
||||
titel: "Logik des Gesamt-Werts für Dimension \"Komplexität\""
|
||||
|
||||
regeln:
|
||||
- bedingung: "1 Dimension = \"Hochkomplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Ein hochkomplexer Aspekt dominiert"
|
||||
|
||||
- bedingung: "3 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Hochkomplex"
|
||||
rationale: "Kumulative Komplexität führt zu Hochkomplexität"
|
||||
|
||||
- bedingung: "2 Dimensionen = \"Komplex\""
|
||||
ergebnis: "Komplex"
|
||||
rationale: "Moderate kumulative Komplexität"
|
||||
|
||||
- bedingung: "ansonsten"
|
||||
ergebnis: "Moderat"
|
||||
rationale: "Überschaubare Komplexität"
|
||||
|
||||
# ========================================
|
||||
# KONSEQUENZEN DER BEWERTUNG
|
||||
# ========================================
|
||||
|
||||
konsequenzen:
|
||||
- komplexitaet: "moderat"
|
||||
konsequenz: "Direkte Umsetzung"
|
||||
typische_massnahmen:
|
||||
- "Standardprozess"
|
||||
- "Keine Sonderanalysen"
|
||||
|
||||
- komplexitaet: "komplex"
|
||||
konsequenz: "Strukturierte Analyse"
|
||||
typische_massnahmen:
|
||||
- "Vorprojekt empfohlen"
|
||||
- "Experteneinbindung"
|
||||
- "Risikomanagement"
|
||||
|
||||
- komplexitaet: "hochkomplex"
|
||||
konsequenz: "Sondierung zwingend"
|
||||
typische_massnahmen:
|
||||
- "Machbarkeitsstudie"
|
||||
- "Pilot/PoC"
|
||||
- "Steering Committee"
|
||||
|
||||
# ========================================
|
||||
# UMGANG MIT KOMPLEXITÄT
|
||||
# ========================================
|
||||
|
||||
umgang_mit_komplexitaet:
|
||||
bei_hochkomplexitaet:
|
||||
massnahmen:
|
||||
- id: "M1"
|
||||
name: "Komplexitätsreduktion prüfen"
|
||||
frage: "Kann der Demand geteilt werden?"
|
||||
ziel: "Reduzierung auf handhabbare Teilprobleme"
|
||||
|
||||
- id: "M2"
|
||||
name: "Sondierung priorisieren"
|
||||
prinzip: "Keine vorschnellen Lösungsversprechen"
|
||||
ziel: "Exploration vor Commitment"
|
||||
|
||||
- id: "M3"
|
||||
name: "Stakeholder-Zielausrichtung"
|
||||
aktivitaet: "Frühzeitige Erwartungsklärung"
|
||||
ziel: "Konvergenz der Interessen"
|
||||
|
||||
- id: "M4"
|
||||
name: "Iteratives Vorgehen"
|
||||
prinzip: "Schritt-für-Schritt statt \"Big Bang\""
|
||||
ziel: "Schrittweise Komplexitätsreduktion"
|
||||
|
||||
komplexitaetsfallen_vermeiden:
|
||||
beschreibung: "Typische Denkfehler im Umgang mit Komplexität"
|
||||
|
||||
fallen:
|
||||
- falle: "Schein-Einfachheit"
|
||||
beispiel: "\"Wir brauchen nur Tool X\""
|
||||
gegenmassnahme: "Immer nach dem \"Warum\" fragen"
|
||||
|
||||
- falle: "Komplexitäts-Paralysis"
|
||||
beschreibung: "Nicht alles Komplexe ist unlösbar"
|
||||
gegenmassnahme: "Handlungsfähigkeit bewahren"
|
||||
|
||||
- falle: "Oversimplification"
|
||||
beschreibung: "Komplexität nicht wegdefinieren"
|
||||
gegenmassnahme: "Realistische Einschätzung"
|
||||
|
||||
- falle: "Analysis-Paralysis"
|
||||
beschreibung: "Irgendwann muss entschieden werden"
|
||||
gegenmassnahme: "Entscheidungszeitpunkt definieren"
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
# DIGITOM Demand-Lifecycle Blueprint
|
||||
|
||||
## Über dieses Repository
|
||||
Dieses Repository enthält die **strukturelle Definition des Demand-Lifecycles** für die DIGIT-Organisation der Stadt Freiburg.
|
||||
|
||||
Es beschreibt den standardisierten Prozess von der ersten Bedarfsmeldung bis zur Übergabe in ein initialisiertes Projekt. Der Blueprint dient als "Single Source of Truth" für die Prozesssteuerung und mögliche technische Implementierungen (z.B. in Jira/ServiceNow).
|
||||
|
||||
> **Scope:** Demand-to-Project (D2P)
|
||||
> **Fokus:** Taktische Steuerung, Quality Gates, Gremienwege
|
||||
> **Basis:** DIGITOM-Transformationskonzept
|
||||
|
||||
## Referenzdokumente
|
||||
Dieser Blueprint basiert auf folgenden abgestimmten Governance-Dokumenten:
|
||||
|
||||
* [cite_start]**Konzept DPM (v1.0):** Definiert die Phasen, Klassifizierungslogik und Gremien[cite: 34, 39].
|
||||
* [cite_start]**DPM Governance & RACI:** Regelt Verantwortlichkeiten und Eskalationswege[cite: 241, 344].
|
||||
* [cite_start]**SPM Glossar (v2.1):** Definiert die zentralen Begrifflichkeiten (z.B. "Demand", "Service")[cite: 1821].
|
||||
|
||||
## Der Lifecycle im Überblick
|
||||
Der Demand-Lifecycle gliedert sich in vier taktische Phasen, getrennt durch definierte Quality Gates.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
%% Rollen-Definitionen für Styling
|
||||
classDef shm fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
|
||||
classDef dpm fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#e65100
|
||||
classDef gremium fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px,color:#1b5e20
|
||||
classDef ppm fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
|
||||
|
||||
subgraph P1 [Phase 1: Initiierung SHM]
|
||||
START((Bedarf)) --> 1.3[Triage & Qualifizierung]:::shm
|
||||
1.3 --> QG1{QG1: Ready for Portfolio?}
|
||||
end
|
||||
|
||||
subgraph P2 [Phase 2: Qualifizierung DPM]
|
||||
QG1 -- Ja --> 2.2[Klassifizierung & Analyse]:::dpm
|
||||
2.2 --> 2.4[Bewertung & Priorisierung]:::dpm
|
||||
2.4 --> 2.6[Entscheidungsvorlage]:::dpm
|
||||
2.6 --> QG2{QG2: Entscheidungsreif?}
|
||||
end
|
||||
|
||||
subgraph P3 [Phase 3: Entscheidung]
|
||||
QG2 -- Routing DSR --> DSR[DSR Sitzung]:::gremium
|
||||
QG2 -- Routing MB --> MB[Mission Board]:::gremium
|
||||
DSR -- Delegation --> MB
|
||||
DSR --> QG3{QG3: Freigabe?}
|
||||
MB --> QG3
|
||||
end
|
||||
|
||||
subgraph P4 [Phase 4: Projektinitiierung PPM]
|
||||
QG3 -- Ja --> 4.1[Projektauftrag & Ressourcen]:::ppm
|
||||
4.1 --> END((Service Lifecycle))
|
||||
end
|
||||
|
||||
QG1 -- Nein --> REJECT[Abweisung / Katalog]
|
||||
QG3 -- Nein/Vertagung --> LOOP[Zurück zu Phase 2]
|
||||
LOOP -.-> 2.2
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# Glossar: Demand-Lifecycle
|
||||
|
||||
Dieses Glossar definiert die zentralen Begrifflichkeiten für den Demand-Lifecycle im DIGITOM-Kontext.
|
||||
|
||||
## Kernobjekte
|
||||
|
||||
### Demand (Bedarf)
|
||||
[cite_start]Ein qualifizierter Kundenbedarf nach IT-Leistungen (Services, Produkte, Projekte), der noch nicht durch das bestehende Service-Portfolio abgedeckt ist oder eine signifikante Änderung erfordert[cite: 4]. [cite_start]Im Gegensatz zum "Service Request" (Abruf standardisierter Leistungen) durchläuft ein Demand einen dedizierten Bewertungs- und Entscheidungsprozess[cite: 4].
|
||||
|
||||
### Service
|
||||
[cite_start]Eine Möglichkeit, gemeinsamen Wert zu schaffen, indem das Erreichen der von Kunden gewünschten Ergebnisse erleichtert wird, ohne dass diese spezifische Kosten und Risiken managen müssen[cite: 4].
|
||||
|
||||
### Produkt
|
||||
[cite_start]Eine Konfiguration von Ressourcen, die erstellt wird, um einen Service bieten zu können[cite: 4].
|
||||
|
||||
## Prozess & Steuerung
|
||||
|
||||
### Demand-Portfolio-Management (DPM)
|
||||
[cite_start]Die zentrale Instanz und der Prozess für die Aufnahme, Qualifizierung, Bewertung, Priorisierung und Steuerung aller Demands[cite: 4]. [cite_start]DPM fungiert als neutrale Koordinationsstelle zwischen Stakeholdern und Entscheidungsgremien[cite: 4].
|
||||
|
||||
### Stakeholder-Management (SHM)
|
||||
[cite_start]Die systematische Identifikation, Analyse, Kommunikation und Beziehungspflege mit allen relevanten Interessengruppen (Stakeholdern)[cite: 4]. [cite_start]Im Demand-Prozess ist das SHM für die initiale Bedarfserfassung und die Kommunikation mit den Anfordernden zuständig[cite: 4].
|
||||
|
||||
### Quality Gate (QG)
|
||||
[cite_start]Ein definierter Entscheidungspunkt zwischen Prozessphasen, an dem geprüft wird, ob bestimmte Kriterien erfüllt sind, bevor der nächste Schritt eingeleitet wird[cite: 4].
|
||||
|
||||
## Gremien & Rollen
|
||||
|
||||
### Mission Board (MB)
|
||||
[cite_start]Das zentrale taktische Entscheidungsgremium im DIGITOM[cite: 4]. [cite_start]Es entscheidet über Demands mit hoher strategischer Relevanz, Tragweite oder Komplexität (MB-Demands) und steuert die übergeordnete Ressourcenallokation[cite: 4].
|
||||
|
||||
### Demand & Stakeholder Runde (DSR)
|
||||
[cite_start]Das operative Entscheidungsgremium für Demands[cite: 4]. [cite_start]Es setzt sich aus DPM, SHM, SPM und PPM zusammen und entscheidet über Demands, die nicht zwingend ins Mission Board müssen[cite: 4].
|
||||
|
||||
### Service Owner
|
||||
[cite_start]Die Rolle, die für die Steuerung eines oder mehrerer Services über deren gesamten Lebenszyklus hinweg verantwortlich ist[cite: 4]. [cite_start]Sie ist oft fachlicher Sponsor für Demands, die ihren Service betreffen[cite: 4].
|
||||
|
||||
## Bewertungsdimensionen (DPM-Spezifisch)
|
||||
|
||||
### Treiber
|
||||
[cite_start]Die Impulsquelle eines Demands (z.B. extern-regulatorisch vs. intern-strategisch), die maßgeblich die Dringlichkeit und den Handlungsspielraum bestimmt[cite: 4].
|
||||
|
||||
### Tragweite
|
||||
[cite_start]Das Ausmaß der Veränderung, die ein Demand verursacht (z.B. evolutionäre Optimierung vs. transformative Neugestaltung)[cite: 4].
|
||||
|
||||
### Komplexität
|
||||
[cite_start]Ein Maß für die Lösungsunsicherheit und den Koordinationsaufwand eines Demands, nicht nur für die technische Schwierigkeit[cite: 4].
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# Governance Rules: Demand-Lifecycle
|
||||
|
||||
Diese Datei dokumentiert die festen Entscheidungsregeln, die den Fluss eines Demands durch den Lifecycle steuern. Sie bildet das regelbasierte Herzstück der Phasen 2 und 3.
|
||||
|
||||
## 1. Klassifizierungs-Logik (Phase 2.2)
|
||||
Jeder Demand wird in vier Dimensionen klassifiziert. Diese Klassifizierung bestimmt maßgeblich das weitere Routing.
|
||||
|
||||
| Dimension | Leitfrage | Ausprägungen (geordnet nach Impact) |
|
||||
| :--- | :--- | :--- |
|
||||
| **Treiber** | Woher kommt der Impuls? | Extern-Regulatorisch > Extern-Fachlich > Intern-Strategisch > Intern-Operativ |
|
||||
| **Tragweite** | Wie tiefgreifend ist die Änderung? | Neugestaltung (Transformativ) > Ausbau (Evolutionär) > Optimierung (Inkrementell) |
|
||||
| **Systemebene** | Wo wirkt der Demand technisch? | Infrastruktur, Plattform, Fachverfahren, Querschnittskomponente, Daten & Integration |
|
||||
| **Komplexität** | Wie unsicher ist die Lösung? | Hochkomplex > Komplex > Moderat |
|
||||
|
||||
> **Grundsatz:** Im Zweifel wird immer die höhere/kritischere Ausprägung gewählt (Vorsichtsprinzip).
|
||||
|
||||
## 2. Routing-Logik (Phase 2.6 -> Phase 3)
|
||||
Basierend auf der Klassifizierung wird entschieden, welches Gremium zuständig ist.
|
||||
|
||||
### 🔴 Mission Board (MB) Routing
|
||||
Ein Demand MUSS ins Mission Board, wenn mindestens EINE der folgenden Bedingungen erfüllt ist:
|
||||
* **Komplexität** = `Hochkomplex`
|
||||
* **Tragweite** = `Neugestaltung (Transformativ)`
|
||||
* **Treiber** = `Extern-Regulatorisch` UND **Komplexität** ≥ `Komplex`
|
||||
|
||||
### 🟡 DSR mit Delegationsoption
|
||||
Ein Demand KANN von der DSR ans MB delegiert werden, wenn er in kritischen Graubereichen liegt:
|
||||
* **Tragweite** = `Ausbau (Evolutionär)` UND **Komplexität** = `Komplex`
|
||||
* **Systemebene** = `Infrastruktur` ODER `Querschnittskomponente` (wegen hoher Breitenwirkung)
|
||||
* **Treiber** = `Extern-Fachlich` (oft politisch sensibel)
|
||||
|
||||
### 🟢 DSR Standard-Routing
|
||||
Alle anderen Demands werden standardmäßig in der **Demand & Stakeholder Runde (DSR)** entschieden.
|
||||
|
||||
## 3. Priorisierungs-Logik (Phase 2.5)
|
||||
Die Priorisierung erfolgt über eine Matrix aus Wichtigkeit (Nutzen) und Dringlichkeit (Zeitdruck).
|
||||
|
||||
| Quadrant | Strategie | Typische Aktion DPM |
|
||||
| :--- | :--- | :--- |
|
||||
| **Q1: Sofort angehen** (Wichtig & Dringend) | "Feuerwehr" | Sofortige Einplanung in nächste DSR, ggf. Sonder-DSR |
|
||||
| **Q2: Strategisch planen** (Wichtig, nicht dringend) | "Fundament" | Einplanung in reguläre Roadmaps, Ressourcensicherung |
|
||||
| **Q3: Effizient abarbeiten** (Nicht wichtig, dringend) | "Tagesgeschäft" | Schnelle operative Freigabe, wenig Analyseaufwand |
|
||||
| **Q4: Kritisch prüfen** (Weder wichtig noch dringend) | "Papierkorb" | Zurückstellung oder Ablehnung empfehlen |
|
||||
|
||||
> **Farb-Indikator (Machbarkeit):** Zusätzlich erhält jeder Demand eine Ampel (Grün/Gelb/Rot) basierend auf der technischen/organisatorischen Machbarkeit. Ein `Q1`-Demand mit `Roter` Machbarkeit ist ein automatischer Eskalationsfall für das Mission Board.
|
||||
|
|
@ -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 |
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
# SHM Bedarfsrouting: Kompaktübersicht
|
||||
|
||||
> **Leitfrage:** Wer ist der Bedarfsträger und woher kommt der Bedarf?
|
||||
|
||||
---
|
||||
|
||||
## Die drei Bedarfstypen auf einen Blick
|
||||
|
||||
| Merkmal | Typ 1: Extern | Typ 2: Intern (Fast Track) | Typ 3: Service-Lifecycle |
|
||||
|---------|---------------|---------------------------|--------------------------|
|
||||
| **Bedarfsträger** | Ämter, Dienststellen außerhalb DIGIT | DIGIT-Mitarbeiter als Nutzer | SO, ISB, SOR, DIGIT-Leitung |
|
||||
| **Beispiele** | Bauamt, Sozialamt, Ordnungsamt | Personalabteilung DIGIT, Sekretariat | Service Owner für eigenen Service |
|
||||
| **Eintrittskanal** | SHM | SHM (Self-Service) | Direkt SOR/DPM |
|
||||
| **Prozess** | Regelweg (Schritt 0 + Prüfungen 1-3) | Fast Track (3 Schritte) | Kein SHM-Routing |
|
||||
| **SHM-Aufwand** | 2-4 Stunden | 10-15 Minuten | 0 (nur Information) |
|
||||
| **Steckbrief** | Vollständig | Reduziert | Vom Bedarfsträger |
|
||||
|
||||
---
|
||||
|
||||
## Entscheidungsbaum: Welcher Typ?
|
||||
|
||||
```
|
||||
BEDARF GEHT EIN
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Wer ist Bedarfsträger? │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
│
|
||||
├── Externes Amt/Dienststelle ──────────────► TYP 1 (Regelweg)
|
||||
│ (Bauamt, Sozialamt, etc.)
|
||||
│
|
||||
├── DIGIT-Mitarbeiter als Nutzer ───────────► TYP 2 (Fast Track)
|
||||
│ (Personalabteilung, Sekretariat)
|
||||
│
|
||||
└── SO/ISB/SOR/Leitung ─────────────────────► TYP 3 (Bypass)
|
||||
(für eigenen Service/Fachbereich) → Kein SHM-Routing!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Typ 2: Fast Track im Detail (10-15 Min.)
|
||||
|
||||
| Schritt | Dauer | Frage | Ergebnis |
|
||||
|---------|-------|-------|----------|
|
||||
| **1. Basistriage** | 3-5 min | Ist es ein valider Bedarf im DIGIT-Scope? | Valide → weiter / Unklar → Rückfrage |
|
||||
| **2. Routing** | 5-7 min | Gibt es einen bestehenden Service? | Ja → direkt an SO / Nein → DPM-INTERN |
|
||||
| **3. Minimaldoku** | 3-5 min | Nur bei ROUTE-DPM-INTERN | SHM-Einschätzung (2-3 Sätze) |
|
||||
|
||||
---
|
||||
|
||||
## Typ 3: Wann ist SHM NICHT zuständig?
|
||||
|
||||
SHM routet **nicht**, wenn der Bedarf aus dem Service-Lifecycle kommt:
|
||||
|
||||
| Auslöser | Bedarfsträger | Weg | SHM-Rolle |
|
||||
|----------|---------------|-----|-----------|
|
||||
| SO erkennt Change-Bedarf (aus Review) | Service Owner | SO führt Change durch | Keine |
|
||||
| SO erkennt Redesign-Bedarf | Service Owner | SO → SOR → DPM | Info bei Stakeholder-Auswirkung |
|
||||
| Service-Ablösung geplant | SO/SOR | SO → SOR → DPM | Stakeholder-Kommunikation |
|
||||
| Sicherheitsanforderung | ISB | ISB → SOR/SO | Ggf. Stakeholder-Kommunikation |
|
||||
| Strategische Initiative | DIGIT-Leitung/MB | MB → DPM | Frühzeitige Einbindung |
|
||||
|
||||
**Merksatz:** Wenn ein SO etwas an *seinem eigenen Service* ändern will, ist das Typ 3 – nicht Typ 2!
|
||||
|
||||
---
|
||||
|
||||
## Häufige Grenzfälle
|
||||
|
||||
| Situation | Einschätzung | Typ |
|
||||
|-----------|--------------|-----|
|
||||
| DIGIT-Personalabteilung braucht neue Software | DIGIT-MA als Nutzer | **Typ 2** |
|
||||
| Personalamt der Stadt braucht neue Software | Externes Amt | **Typ 1** |
|
||||
| Stabsstelle Digital möchte Miro | Interner Nutzer (obwohl nicht direkt DIGIT) | **Typ 2** |
|
||||
| SO möchte sein DMS modernisieren | SO für eigenen Service | **Typ 3** |
|
||||
| Stakeholder beschwert sich → SO erkennt Redesign | Initial extern, dann SO-Erkenntnis | **Typ 1 → Typ 3** |
|
||||
|
||||
---
|
||||
|
||||
## SHM-Aufgaben je Typ
|
||||
|
||||
| Typ | SHM macht... | SHM macht NICHT... |
|
||||
|-----|--------------|---------------------|
|
||||
| **Typ 1** | Vollständige Bewertung, User Stories, Steckbrief | – |
|
||||
| **Typ 2** | Fast Track (3 Schritte), Minimaldoku | Vollständige Bedarfserhebung |
|
||||
| **Typ 3** | Stakeholder-Kommunikation (wenn informiert) | Routing, Bedarfsbewertung |
|
||||
|
||||
---
|
||||
|
||||
## Kurzreferenz: Status-Werte
|
||||
|
||||
| Status | Bedeutung | Typ |
|
||||
|--------|-----------|-----|
|
||||
| `an_dpm_uebergeben` | Externer Bedarf an DPM (vollständig) | Typ 1 |
|
||||
| `an_dpm_uebergeben_intern` | Interner Bedarf an DPM (reduziert) | Typ 2 |
|
||||
| `in_klaerung_intern` | Fast Track: Rückfrage an Einreichenden | Typ 2 |
|
||||
| `an_spm_uebergeben` | Change an Service Owner | Typ 1 oder 2 |
|
||||
|
||||
---
|
||||
|
||||
*Version 1.0 | Stand: 29.01.2025 | Quelle: shm_bedarfsbewertung.yaml v1.3, shm_interne-bedarfe-routing.yaml v2.0*
|
||||
47
#04_mission-board/README.md
Normal file
47
#04_mission-board/README.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# Mission Board
|
||||
|
||||
Dieser Ordner enthält die Dokumentation zum **Mission Board** des DIGIT (Amt für Digitales und IT) der Stadt Freiburg.
|
||||
|
||||
## Übersicht
|
||||
|
||||
Das Mission Board ist das zentrale taktische Entscheidungs- und Koordinierungsgremium für IT- und Digitalisierungsinitiativen. Es operiert unterhalb des Vision Boards und oberhalb der koordinativen Gremien (DSR, SOR).
|
||||
|
||||
## Governance-Hierarchie
|
||||
|
||||
```
|
||||
Vision Board (strategisch)
|
||||
↓
|
||||
Mission Board (taktisch) ← Dieser Ordner
|
||||
↓
|
||||
DSR / SOR (koordinativ)
|
||||
```
|
||||
|
||||
## Enthaltene Dokumente
|
||||
|
||||
| Dokument | Beschreibung | Status |
|
||||
|----------|--------------|--------|
|
||||
| `mb_geschaeftsordnung.yaml` | Geschäftsordnung des Mission Boards | Draft v0.3 |
|
||||
|
||||
## Kernfunktionen des Mission Boards
|
||||
|
||||
1. **Demand- & Projektportfolio-Steuerung** - Entscheidung über Initiierung, Priorisierung und Beendigung von IT-Projekten und Demands
|
||||
2. **Ressourcenallokation & Kapazitätssteuerung** - Taktische Allokation von Personal-, Budget- und Sachmitteln
|
||||
3. **Monitoring & Eskalation** - Bewertung laufender Projekte und kritischer Services
|
||||
4. **Umsetzung strategischer Entscheidungen** - Transformation strategischer Vorgaben in umsetzbare Maßnahmen
|
||||
5. **Security, Compliance & Politik** - Integration von Sicherheits-, Datenschutz- und politischen Anforderungen
|
||||
|
||||
## Schnittstellen
|
||||
|
||||
- **Vision Board** - Eskalationsinstanz für strategische Fragen
|
||||
- **Demand- & Stakeholder-Runde (DSR)** - Vorgelagertes koordinatives Gremium für Demand-Bewertung
|
||||
- **Service Operations Runde (SOR)** - Koordinatives Gremium für Service-Portfolio-Governance
|
||||
- **IT-Architektur-Board** - Technische Standards und Architekturvorgaben
|
||||
|
||||
## Referenzen
|
||||
|
||||
- DSR-Geschäftsordnung: `../01_demand-portfolio-management/.../dpm_dsr-go.yaml`
|
||||
- SOR-Geschäftsordnung: `../02_service-portfolio-management/.../spm_sor_go.yaml`
|
||||
- DIGITOM-Taxonomie: `../00_meta/digitom_taxonomie.yaml`
|
||||
|
||||
---
|
||||
*Stand: Januar 2026 | DIGITOM-Projekt*
|
||||
74
#05_prozessmanagement/README.md
Normal file
74
#05_prozessmanagement/README.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
# Prozess-Management (PM)
|
||||
|
||||
**Status:** ✅ Vollständig - Alle 8 Dokumente konvertiert
|
||||
**Datum:** 2026-02-05
|
||||
|
||||
---
|
||||
|
||||
## Übersicht
|
||||
|
||||
Dieser Ordner enthält die Dokumentation der Prozess-Management-Funktion im DIGIT Operating Model.
|
||||
|
||||
**Funktion:** Prozess-Management (PM)
|
||||
**ID:** PM
|
||||
**Status:** In Entwicklung
|
||||
|
||||
---
|
||||
|
||||
## Ordnerstruktur
|
||||
|
||||
```
|
||||
#05_prozessmanagement/
|
||||
├── README.md # Diese Datei
|
||||
├── #05.1_funktion/ # Funktionsbeschreibung
|
||||
├── #05.2_governance/ # Governance & RACI
|
||||
├── #05.3_konzepte/ # Leistungs-Canvas, Practices
|
||||
├── #05.4_rollen/ # Rollenmodell
|
||||
├── #05.5_arbeitsmaterialien/ # Templates, Hilfsmittel
|
||||
└── docs/ # Markdown-Zwischendateien
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Konvertierungsstatus
|
||||
|
||||
| Dokument | Quelle | Ziel | Status |
|
||||
|----------|--------|------|--------|
|
||||
| Funktionsbeschreibung | #02 - Funktionsbeschreibung.docx | #05.1_funktion/pm_funktionsbeschreibung.yaml | ✅ Fertig |
|
||||
| Rollenmodell | #04 - Rollenmodell.docx | #05.4_rollen/ | ✅ Fertig (12 Dateien) |
|
||||
| Governance-Modell | #05 - Governance-Modell.docx | #05.2_governance/pm_governance-framework.yaml | ✅ Fertig |
|
||||
| RACI Matrix | #06 - RACI Matrix.xlsx | #05.2_governance/pm_raci.yaml | ✅ Fertig |
|
||||
| Leistungs-Canvas | #03.1 - Leistungs-Canvas.docx | #05.3_konzepte/pm_leistungs-canvas.yaml | ✅ Fertig |
|
||||
| Konzeptrahmen | #01 - Konzeptrahmen.docx | #05.3_konzepte/pm_konzeptrahmen.yaml | ✅ Fertig |
|
||||
| Übersicht | #00 - Prozess-Management.docx | pm_uebersicht.yaml | ✅ Fertig |
|
||||
| Pilot-Konzept | #07 - Pilot-Konzept.docx | #05.3_konzepte/pm_pilot-konzept.yaml | ✅ Fertig |
|
||||
|
||||
---
|
||||
|
||||
## Status
|
||||
|
||||
**Alle Konvertierungen abgeschlossen!**
|
||||
|
||||
Die gesamte Word/Excel-Dokumentation wurde erfolgreich in strukturierte YAML-Dateien überführt.
|
||||
|
||||
---
|
||||
|
||||
## Schnittstellen zu anderen Funktionen
|
||||
|
||||
- **DPM**: Demand-Portfolio-Management
|
||||
- **SPM**: Service-Portfolio-Management
|
||||
- **SHM**: Stakeholder-Management
|
||||
- **PPM**: Projekt-Portfolio-Management
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- **Taxonomie:** `#00_meta/digitom_taxonomie.yaml`
|
||||
- **Template:** `#100_tmp-files/pm_funktionsbeschreibung_template.yaml`
|
||||
- **Status:** `#100_tmp-files/prozessmanagement_konvertierung_status.md`
|
||||
|
||||
---
|
||||
|
||||
**Erstellt:** 2026-02-05
|
||||
**Zuletzt aktualisiert:** 2026-02-05
|
||||
572
#05_prozessmanagement/docs/pm_funktionsbeschreibung.md
Normal file
572
#05_prozessmanagement/docs/pm_funktionsbeschreibung.md
Normal file
|
|
@ -0,0 +1,572 @@
|
|||
# **Prozess-Management: Funktionsbeschreibung**
|
||||
|
||||
#
|
||||
|
||||
## **1. Zweck**
|
||||
|
||||
**Wozu existiert diese Funktion?**\
|
||||
Das Prozess-Management gestaltet aktiv die Art und Weise, *wie* das
|
||||
DIGIT arbeitet. Als **unterstützende und befähigende Einheit** etabliert
|
||||
und verantwortet es den verbindlichen methodischen Rahmen für *alle*
|
||||
übergreifenden (Organisations-) Prozesse (DIGITOM).
|
||||
|
||||
Das Prozess-Management agiert im Auftrag des **Vision Board**
|
||||
(strategisches Führungsgremium) und dient internen Kunden -- den
|
||||
**Fachbereichen/ Abteilungen** und ihren **Key Usern** sowie den
|
||||
Projektteams -- indem es methodische Standards, Werkzeuge und Beratung
|
||||
bereitstellt, damit diese ihre Prozesse eigenständig managen und
|
||||
verbessern können.
|
||||
|
||||
Ziel ist es, durch klare Strukturen, einheitliche Standards und gezielte
|
||||
Befähigung eine solide Grundlage für Effektivität, Transparenz und
|
||||
kontinuierliche Verbesserung im gesamten Amt zu schaffen.
|
||||
|
||||
Dadurch unterstützt das Prozess-Management die erfolgreiche Umsetzung
|
||||
der Digitalstrategie und schafft **Arbeitsabläufe, die gut funktionieren
|
||||
und sich flexibel an neue Anforderungen anpassen** lassen.
|
||||
|
||||
**Was ist das Hauptziel?**\
|
||||
Nachhaltig wirksame und anpassungsfähige Prozesse in der Organisation zu
|
||||
verankern.\
|
||||
*Dies wird erreicht, indem\...*
|
||||
|
||||
- ... eine konsistente, transparente und an der Strategie ausgerichtete
|
||||
Prozesslandschaft geschaffen und gepflegt wird, die Silos überwindet.
|
||||
|
||||
- ·... die Organisation durch gezielte Beratung, Coaching und Schulung
|
||||
befähigt wird, ihre Prozesse innerhalb des Rahmens eigenverantwortlich
|
||||
zu steuern und zu optimieren.
|
||||
|
||||
- ... die Einhaltung der Prozess-Governance (Standards, Methoden,
|
||||
Dokumentation und der darin definierten Prozess-Management-Prozesse)
|
||||
als Grundlage für Qualität, Nachvollziehbarkeit und Verlässlichkeit
|
||||
überwacht und unterstützt wird.
|
||||
|
||||
- ... die kontinuierliche Weiterentwicklung und Anpassung des DIGITOMs
|
||||
als lebendiges Organisationsmodell vorangetrieben wird, um auf
|
||||
veränderte Anforderungen und gewonnene Erkenntnisse reagieren zu
|
||||
können
|
||||
|
||||
##
|
||||
|
||||
##
|
||||
|
||||
##
|
||||
|
||||
## **2. Funktionsverständnis & Abgrenzung**
|
||||
|
||||
Prozess-Management ist eine Dienstleistung und ein zentraler Befähiger
|
||||
für die Organisation. Es unterstützt und berät die Fachbereiche bei
|
||||
ihren Prozessen, ohne deren Verantwortung zu ersetzen. Dies beinhaltet
|
||||
eine klare Rollenverteilung zwischen Linienorganisation und
|
||||
Prozessmanagement.
|
||||
|
||||
**Die Verantwortung bleibt, wo sie hingehört**
|
||||
|
||||
## Die Fachbereiche/ Abteilungen sind fachlich und operativ für die Ausführung und Ergebnisse ihrer Prozesse verantwortlich. Sie liefern die Prozessinhalte und gewährleisten funktionierende Abläufe im Tagesgeschäft. Hierfür werden in der Regel Prozessverantwortliche -- wie Key User oder Process Owner -- als erste Ansprechpartner benannt.
|
||||
|
||||
## Das zentrale Prozess-Management verantwortet Rahmen und Methodik der Prozessarbeit, gibt Standards vor, überblickt die Prozesslandschaft und berät Prozessverantwortliche. Es greift nicht in die Liniensteuerung ein, sondern beeinflusst durch Expertise, Governance und Koordination. Entscheidungen werden bei Bedarf über Gremien initiiert.
|
||||
|
||||
**\
|
||||
Partnerschaft statt Kontrolle**
|
||||
|
||||
## Prozess-Management agiert als proaktiver Partner der Fachbereiche/ Abteilungen und schafft einen verbindlichen Ordnungsrahmen. Bei signifikanten Abweichungen von Standards oder Governance-Lücken greift es unterstützend ein. Dies fördert Vertrauen: Fachbereiche erhalten Unterstützung zur Selbsthilfe, während das Management die Einhaltung der Standards und der Gesamtzusammenhängen gewährleistet sieht.
|
||||
|
||||
**\
|
||||
Strukturierte Leistungserbringung\**
|
||||
|
||||
Das Prozess-Management differenziert seine Unterstützung nach vier
|
||||
Leistungskategorien, die unterschiedlichen Beauftragungswegen und
|
||||
Priorisierungslogiken folgen:
|
||||
|
||||
- Standard-Leistungen für den operativen Alltag (Beratung, Workshops,
|
||||
Schulungen)
|
||||
|
||||
- Projekt-Leistungen für ressourcenintensive Vorhaben mit mehrwöchiger
|
||||
Laufzeit
|
||||
|
||||
- Strategische Leistungen zur Weiterentwicklung des DIGITOMs
|
||||
|
||||
- Krisen-Leistungen für akute Prozessstörungen mit sofortigem
|
||||
Handlungsbedarf
|
||||
|
||||
Diese Differenzierung ermöglicht eine bedarfsgerechte
|
||||
Ressourcensteuerung und schafft klare Erwartungen auf allen Seiten. Die
|
||||
detaillierten Beauftragungswege und Entscheidungsmechanismen sind im
|
||||
Governance-Modell definiert.
|
||||
|
||||
## **2. Verantwortungsbereich**
|
||||
|
||||
### **2.1 Prozess-Management-Framework definieren und weiterentwickeln**
|
||||
|
||||
Definition, Kommunikation und Weiterentwicklung der verbindlichen
|
||||
methodischen und technischen Grundlagen für das gesamte
|
||||
Prozess-Management im DIGIT als Fundament für einheitliche und
|
||||
qualitativ hochwertige Prozessarbeit.
|
||||
|
||||
**Was:**
|
||||
|
||||
- Etablierung eines einheitlichen Prozess-Management-Frameworks:
|
||||
Gemeinsamer verbindlicher Standards, und Methoden für die Darstellung,
|
||||
Dokumentation und Steuerung von Prozessen.
|
||||
|
||||
- Festlegung von Governance-Regeln und Richtlinien für alle Aspekte der
|
||||
Prozessarbeit (von der Dokumentation über die Analyse bis zur
|
||||
Steuerung).
|
||||
|
||||
- Auswahl, Bereitstellung und laufende Betreuung zentraler
|
||||
Prozess-Management-Werkzeuge.
|
||||
|
||||
⠀**Warum:**
|
||||
|
||||
- Sicherstellung einer einheitlichen, vergleichbaren und
|
||||
nachvollziehbaren Prozessdokumentation im Amt.
|
||||
|
||||
- Gewährleistung von methodischer Qualität, Effektivität und fundierter
|
||||
Erhebung in der Prozessgestaltung und -optimierung.
|
||||
|
||||
- Schaffung einer gemeinsamen \"Prozess-Sprache\" und eines gemeinsamen
|
||||
Verständnisses für Prozessarbeit über Abteilungsgrenzen hinweg.
|
||||
|
||||
⠀**Wie:**
|
||||
|
||||
- Laufende Analyse von internen Bedarfen und externen Best
|
||||
Practices/Standards im Prozess-Management.
|
||||
|
||||
- Abstimmung der Anforderungen mit Fachbereichen, IT-Architektur und
|
||||
übergreifenden Governance-Vorgaben.
|
||||
|
||||
- Klare Dokumentation des Prozess-Management-Frameworks (z.B. in Form
|
||||
eines Methodenhandbuch oder Playbook) und leicht zugängliche
|
||||
Bereitstellung für alle Mitarbeitenden.
|
||||
|
||||
- Aktive Kommunikation und Verankerung des Frameworks in der
|
||||
Organisation (z. B. durch Schulungen, Informationsveranstaltungen und
|
||||
kontinuierliche Beratung der relevanten Akteure).
|
||||
|
||||
###
|
||||
|
||||
### **2.2 Übergreifende Prozesslandschaft managen und Governance sicherstellen**
|
||||
|
||||
Aufbau, Pflege und Überwachung der Gesamtarchitektur der
|
||||
bereichsübergreifenden Prozesse (Kern-, Management- und Supportprozesse)
|
||||
des DIGIT zur Schaffung von Transparenz, zur Steuerung und zur
|
||||
Sicherstellung der Einhaltung des definierten Rahmens.
|
||||
|
||||
**Was:**
|
||||
|
||||
- Erhebung, Visualisierung und laufende Pflege der übergreifenden
|
||||
Prozesslandkarte des DIGIT.
|
||||
|
||||
- Überwachung der Einhaltung des Prozess-Management-Frameworks
|
||||
(Methoden, Standards, Dokumentationsqualität).
|
||||
|
||||
- Systematische Identifikation und Adressierung von Governance-Lücken:
|
||||
Dokumentation fehlender Regelungen, strukturierte Eskalation über
|
||||
definierte Wege, Nachverfolgung bis zur Schließung der Lücke.
|
||||
|
||||
⠀**Warum:**
|
||||
|
||||
- Schaffung von Transparenz über die Kernabläufe, Abhängigkeiten und
|
||||
Schnittstellen im Amt.
|
||||
|
||||
- Ermöglichung einer strategischen Steuerung und Priorisierung von
|
||||
bereichsübergreifenden Prozessinitiativen (durch das Vision Board).
|
||||
|
||||
- Sicherstellung der Konsistenz und Qualität der Prozessarbeit sowie
|
||||
Einhaltung von Compliance-Vorgaben.
|
||||
|
||||
- Vermeidung von Silos und unkoordinierten Insellösungen, indem
|
||||
bereichsübergreifende Prozesslücken frühzeitig erkannt und geschlossen
|
||||
werden.
|
||||
|
||||
⠀**Wie:**
|
||||
|
||||
- Nutzung des Prozess-Management-Werkzeugs zur Darstellung und
|
||||
Verwaltung der Prozessarchitektur.
|
||||
|
||||
- Regelmäßige Qualitäts-Checks und Reviews zur Prüfung der
|
||||
Framework-Konformität.
|
||||
|
||||
- Kontinuierlicher Austausch mit den Fachbereichen (u. a. über
|
||||
Key-User), um frühzeitig Optimierungsfelder oder fehlende Regelungen
|
||||
(Governance-Lücken) zu identifizieren und adressieren zu können
|
||||
|
||||
- Regelmäßiges Reporting an das Vision Board und relevante Gremien.
|
||||
|
||||
###
|
||||
|
||||
### **2.3 Beratung und operative Prozessgestaltung (in definierten Fällen)**
|
||||
|
||||
Methodische Unterstützung der Fachbereiche bei Prozessfragen sowie
|
||||
aktive Gestaltung und Optimierung von Prozessen in spezifischen,
|
||||
strategisch relevanten oder komplexen Situationen, wobei die Rolle klar
|
||||
als Berater und Befähiger verstanden wird.
|
||||
|
||||
**Was:**
|
||||
|
||||
- Fachliche Beratung von Fachbereichen und Teams bei der Analyse,
|
||||
Neugestaltung und Optimierung ihrer Prozesse (methodische
|
||||
Fachexpertise bereitstellen)
|
||||
|
||||
- Bei Bedarf Moderation von Prozessworkshops bei bereichsübergreifenden
|
||||
oder komplexen Abläufen.
|
||||
|
||||
- In ausgewählten Ausnahmefällen operative Unterstützung bei der
|
||||
Prozessaufnahme, -modellierung und -optimierung leisten (etwa bei
|
||||
strategisch bedeutsamen oder abteilungsübergreifenden Prozessen, bei
|
||||
Projekten mit großem Prozesseinfluss oder initial als „Starthilfe").
|
||||
|
||||
⠀**Warum:**
|
||||
|
||||
- Sicherstellung hoher methodischer Qualität bei der Lösung komplexer
|
||||
Prozessherausforderungen.
|
||||
|
||||
- Unterstützung der Fachbereiche bei der Erreichung ihrer Ziele durch
|
||||
effektive Prozesse (\"Enabling\").
|
||||
|
||||
- Gezielter Einsatz zentraler Ressourcen auf die Prozesse mit dem
|
||||
größten Hebel oder der höchsten Komplexität.
|
||||
|
||||
⠀**Wie:**
|
||||
|
||||
- Durchführung von individuellen Beratungsgesprächen und Coachings für
|
||||
Prozessverantwortliche/-teams.
|
||||
|
||||
- Planung und professionelle Moderation von Analyse- und
|
||||
Design-Workshops.
|
||||
|
||||
- Anwendung geeigneter Prozessanalyse- und Optimierungstechniken.
|
||||
|
||||
- Detaillierte Modellierung (Ist/Soll) gemäß Prozess-Framework bei
|
||||
Übernahme operativer Verantwortung (in den definierten Fällen).
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
### **2.4 Dezentrale Prozesskompetenz durch Befähigung und Aufbau Key-User-Konzept**
|
||||
|
||||
Systematischer Aufbau und Pflege von Prozess-Management-Kompetenzen in
|
||||
den Fachbereichen, insbesondere durch die Etablierung und Betreuung
|
||||
eines Key-User-Netzwerks, um die Prozessarbeit nachhaltig in der
|
||||
Organisation zu verankern.
|
||||
|
||||
**Was:**
|
||||
|
||||
- Entwicklung und Umsetzung eines übergreifenden Befähigungskonzepts für
|
||||
Prozess-Management.
|
||||
|
||||
- Identifikation, Gewinnung und Qualifizierung von geeigneten Key-Usern
|
||||
für Prozesse in den Fachbereichen als dezentrale
|
||||
Prozess-Ansprechpartner.
|
||||
|
||||
- Aufbau und Management eines Key-User-Netzwerks, das den regelmäßigen
|
||||
Erfahrungsaustausch fördert und die kontinuierliche Weiterbildung im
|
||||
Prozessmanagement sicherstellt,
|
||||
|
||||
⠀**Warum:**
|
||||
|
||||
- Stärkung der Eigenverantwortung der Fachbereiche für ihre Prozesse
|
||||
(\"Hilfe zur Selbsthilfe\").
|
||||
|
||||
- Sicherstellung der nachhaltigen Anwendung und Verbesserung von
|
||||
Prozessen im Tagesgeschäft.
|
||||
|
||||
- Schaffung von Multiplikatoren für Prozessdenken und das
|
||||
Prozessmanagement-Framework in der gesamten Organisation.
|
||||
|
||||
⠀**Wie:**
|
||||
|
||||
- Konzeption und Durchführung von zielgruppenspezifischen Trainings und
|
||||
Workshops (Methoden, Tools).
|
||||
|
||||
- Definition der Rolle und Aufgaben von Key-Usern in Abstimmung mit den
|
||||
Fachbereichen.
|
||||
|
||||
- Organisation von regelmäßigen Austauschformaten für Key-User (z.B.
|
||||
Community of Practice, Best-Practice-Sharing).
|
||||
|
||||
- Bereitstellung von Lernmaterialien, Leitfäden und Coaching für die
|
||||
Key-User.
|
||||
|
||||
- Strategische Netzwerk-Entwicklung: Systematische Identifikation von
|
||||
Kompetenzlücken im Netzwerk, gezielte Rekrutierung neuer Key-User in
|
||||
unterrepräsentierten Bereichen und kontinuierliche Weiterentwicklung
|
||||
der Community-Formate basierend auf Feedback und organisationalen
|
||||
Bedarfen.
|
||||
|
||||
**2.5 Leistungserbringung strukturieren und steuern**
|
||||
|
||||
Die Prozess-Management-Funktion erbringt ihre Leistungen in vier
|
||||
unterschiedlichen Modi, die sich nach Komplexität, strategischer
|
||||
Bedeutung und Ressourcenbedarf unterscheiden. Diese differenzierte
|
||||
Herangehensweise ermöglicht es, flexibel auf verschiedene
|
||||
organisationale Bedarfe zu reagieren und gleichzeitig die verfügbaren
|
||||
Ressourcen optimal einzusetzen.
|
||||
|
||||
**Was:**
|
||||
|
||||
- **Standard-Leistungen**: Wiederkehrende Unterstützung für operative
|
||||
Prozessbedarfe wie Einzelberatungen,
|
||||
Prozess-Management-Framework-Schulungen oder methodische
|
||||
Kurzberatungen. Diese Leistungen sind niedrigschwellig zugänglich und
|
||||
folgen etablierten Mustern.
|
||||
|
||||
- **Projekt-Leistungen**: Umfangreichere
|
||||
Prozess-Management-Unterstützung, die signifikante Ressourcen bindet -
|
||||
etwa bei kompletten Prozess-Neugestaltungen oder
|
||||
bereichsübergreifenden Transformationen. Diese Leistungen erfordern
|
||||
eine formale Beauftragung durch das Mission Board.
|
||||
|
||||
- **Strategische Leistungen**: Initiativen zur Weiterentwicklung des
|
||||
gesamten DIGITOMs oder zur grundlegenden Transformation der
|
||||
Prozesslandschaft. Sie werden vom Vision Board beauftragt und haben
|
||||
organisationsweite Auswirkungen.
|
||||
|
||||
- **Krisen-Leistungen**: Sofortige Unterstützung bei akuten
|
||||
Prozess-Störungen oder Compliance-Verstößen. Hier werden andere
|
||||
Aktivitäten zurückgestellt, um schnelle Lösungen zu ermöglichen.
|
||||
|
||||
**Warum:**
|
||||
|
||||
- Sicherstellung einer bedarfsgerechten und ressourceneffizienten
|
||||
Leistungserbringung durch klare Priorisierung.
|
||||
|
||||
- Schaffung von Transparenz über verfügbare Prozess-Management-Services
|
||||
und deren Zugangswege für alle Organisationseinheiten.
|
||||
|
||||
- Ermöglichung einer strategischen Kapazitätsplanung und
|
||||
vorausschauenden Ressourcenallokation.
|
||||
|
||||
- Balance zwischen planbaren Aktivitäten und der notwendigen
|
||||
Flexibilität für ungeplante Bedarfe.
|
||||
|
||||
**Wie:**
|
||||
|
||||
- Definition klarer Kriterien für die Zuordnung von Anfragen zu den
|
||||
verschiedenen Leistungskategorien (z.B. Aufwand, Laufzeit,
|
||||
Komplexität, strategische Relevanz).
|
||||
|
||||
- Etablierung unterschiedlicher Beauftragungswege je nach Leistungstyp -
|
||||
von niedrigschwelligen Ticketsystemen bis zu formalen
|
||||
Gremienentscheidungen.
|
||||
|
||||
- Regelmäßige Überprüfung der Leistungsverteilung und Anpassung der
|
||||
Kapazitätsallokation basierend auf organisationalen Prioritäten.
|
||||
|
||||
- Transparente Kommunikation der verschiedenen Leistungstypen und ihrer
|
||||
Zugangswege an alle potenziellen Nutzer:innen.
|
||||
|
||||
## **3. Schnittstellen (Input/Output/Typische Abstimmungswege)**
|
||||
|
||||
### **3.1 Inputs**
|
||||
|
||||
(was das Prozess-Management empfängt)
|
||||
|
||||
+:---------------------:+:----------------------------------------------------:+
|
||||
| **Von** | **Inhalt** |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Vision Board** | - Strategische Leitlinien und Entscheidungen zur |
|
||||
| | Ausgestaltung des DIGITOMs |
|
||||
| | |
|
||||
| | - Aufträge zur Umsetzung beschlossener Änderungen. |
|
||||
| | |
|
||||
| | - Entscheidungen über: |
|
||||
| | |
|
||||
| | - Framework-Transformationen, |
|
||||
| | |
|
||||
| | - strategische Prozess-Management-Ausrichtung, |
|
||||
| | |
|
||||
| | - Ressourcenrahmen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Mission Board** | - Impulse und Prioritäten aus der strategischen bzw. |
|
||||
| | taktischen Steuerung |
|
||||
| | |
|
||||
| | - Entscheidungen bei Eskalationen von |
|
||||
| | bereichsübergreifenden Prozesskonflikten |
|
||||
| | |
|
||||
| | - Entscheidungen über: |
|
||||
| | |
|
||||
| | - Projekt-Leistungen, |
|
||||
| | |
|
||||
| | - Prioritätskonflikte bei Ressourcenengpässen, |
|
||||
| | |
|
||||
| | - Governance-Eskalationen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Projekt-Portfolio-\ | - Informationen zu geplanten Projekten und |
|
||||
| Management** | priorisierten Initiativen, die prozessuale |
|
||||
| | Änderungen erfordern oder bestehende Prozesse |
|
||||
| | betreffen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Service-Portfolio-\ | - Anforderungen aus der Service-Entwicklung und dem |
|
||||
| Management** | Service-Betrieb, die neue Prozesse oder |
|
||||
| | Anpassungen bestehender Prozesse nötig machen |
|
||||
| | |
|
||||
| | - Feedback zur Anwendbarkeit/Vollständigkeit des |
|
||||
| | Prozess-Management-Frameworks für Service-Prozesse |
|
||||
| | |
|
||||
| | - Feedback zur Effektivität bestehender |
|
||||
| | Prozessmodelle aus
Service-Sicht |
|
||||
| | |
|
||||
| | - Informationen zur Ausgestaltung des ITIL-Framewoks |
|
||||
| | mit Bezug zum Prozess-Management-Framework |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Stakeholder-\ | - Anforderungen von Stakeholdern (z.B. |
|
||||
| Management** | Kundenfeedback, gesetzliche/regulative Vorgaben), |
|
||||
| | welche die internen Prozesse beeinflussen. |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Key-User** | - Bindeglied zwischen zentralem Prozess-Management |
|
||||
| | Team und Fachbereich |
|
||||
| | |
|
||||
| | - Feedback zur Anwendbarkeit des Frameworks, |
|
||||
| | spezifische Unterstützungsbedarfe, operative |
|
||||
| | Prozessdetails |
|
||||
| | |
|
||||
| | - Bringen Anforderungen, Detailfragen und |
|
||||
| | Rückmeldungen aus ihrem Bereich ins |
|
||||
| | Prozessmanagement ein |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Fachbereiche / | - Input in Form von Bedarfen (z. B. Wunsch nach |
|
||||
| Teams** | Neugestaltung eines Prozesses, Hinweise auf |
|
||||
| | ineffiziente Abläufe, spezifische |
|
||||
| | Beratungsanfragen) und Feedback zur bestehenden |
|
||||
| | Prozessausführung |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **IT-Architektur** | - Technische Rahmenbedingungen, Informationen über |
|
||||
| | IT-Systemlandschaft, technische Standards |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
|
||||
###
|
||||
|
||||
### **3.2 Outputs**
|
||||
|
||||
(Was das Prozess-Management weitergibt)
|
||||
|
||||
+:---------------------:+:---------------------------------------------------:+
|
||||
| **An** | **Inhalt** |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Vision Board** | - Konzepte und Vorschläge zur Weiterentwicklung des |
|
||||
| | DIGITOMs (inkl. Begründungen und Auswirkungen) |
|
||||
| | |
|
||||
| | - Regelmäßige Statusberichte zur Implementierung |
|
||||
| | des DIGITOMs |
|
||||
| | |
|
||||
| | - Meldung von grundsätzlichen Problemen oder |
|
||||
| | Risiken in der Prozesslandschaft (Eskalation) |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Mission Board** | - Berichte über operative Herausforderungen und |
|
||||
| | bereichsübergreifende Prozess-Themen, die |
|
||||
| | strategische Entscheidungen erfordern |
|
||||
| | |
|
||||
| | - Empfehlungen für taktische Maßnahmen zur |
|
||||
| | Prozessanpassung |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Projekt-Portfolio-\ | - Vorgaben und Richtlinien, wie Projekte im Rahmen |
|
||||
| Management:** | des DIGITOM ablaufen sollen (z.B. definierte |
|
||||
| | Prozessschritte, Decision Gates) |
|
||||
| | |
|
||||
| | - Bewertung der Machbarkeit geplanter Projekte aus |
|
||||
| | (organisations-)prozessualer Sicht |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Service-Portfolio-\ | - Bei Bedarf Unterstützung bei der Gestaltung von |
|
||||
| Management** | servicebezogenen Prozessen (z.B. Einführung neuer |
|
||||
| | Services) und bei der |
|
||||
| | Standardisierung/Dokumentation von |
|
||||
| | Service-Prozessen |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Stakeholder-\ | - Definierte Prozesse und Verantwortlichkeiten für |
|
||||
| Management** | den Umgang mit externen Stakeholdern |
|
||||
| | |
|
||||
| | - Rückmeldung, wie externe Anforderungen im DIGITOM |
|
||||
| | berücksichtigt wurden |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Fachbereiche/\ | - Schulungsmaterial, Handbücher und Leitfäden zum |
|
||||
| Abteilungen** | DIGITOM |
|
||||
| | |
|
||||
| | - Individuelle Beratung und Lösungen für gemeldete |
|
||||
| | Prozessprobleme - Methodische Unterstützung und |
|
||||
| | Empfehlungen zur Prozessgestaltung und |
|
||||
| | Dokumentation |
|
||||
| | |
|
||||
| | - Informationen über anstehende Prozessänderungen |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
| **Key-User** | - Weitergabe die vom Prozess-Management |
|
||||
| | entwickelten Lösungen, Standards und Guidelines |
|
||||
| | in ihre Teams |
|
||||
| | |
|
||||
| | - Unterstützung der jeweiligen Abteilungen oder |
|
||||
| | Teams bei der Prozessanwendung |
|
||||
+-----------------------+-----------------------------------------------------+
|
||||
|
||||
###
|
||||
|
||||
### **3.3 Typische Abstimmungswege**
|
||||
|
||||
+:---------------------:+:----------------------------------------------------:+
|
||||
| **Format / Kontext** | **Inhalt** |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Vision Board\ | - Status Prozesslandschaft & Framework-Compliance |
|
||||
| (Regel Reporting)** | |
|
||||
| | - Strategische Abstimmung |
|
||||
| | |
|
||||
| | - Eskalationen |
|
||||
| | |
|
||||
| | - Grundsatzentscheidungen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Mission Board\ | - Abstimmung bereichsübergreifende Prozessfragen |
|
||||
| (bei Bedarf)** | |
|
||||
| | - Entscheidungen über Priorisierungen oder |
|
||||
| | Ressourcenkonflikte |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Beratungsgespräch / | - Methodische Unterstützung bei Prozessfragen |
|
||||
| Coaching | |
|
||||
| (Fachbereich/\ | - Anleitung zur Prozess-Framework-Anwendung |
|
||||
| Key-User)** | |
|
||||
| | - Problemlösung |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Schulung / Workshop | - Kompetenzaufbau (Methoden, Tools) |
|
||||
| (Key-User/Teams)** | |
|
||||
| | - Praktische Anwendung |
|
||||
| | |
|
||||
| | - Befähigung zur dezentralen Prozessarbeit |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Key-User-**\ | - Erfahrungsaustausch |
|
||||
| **Netzwerktreffen | |
|
||||
| /**\ | - Best-Practice-Sharing |
|
||||
| **Community of | |
|
||||
| Practice** | - Feedback zum Framework |
|
||||
| | |
|
||||
| | - Multiplikation von Wissen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Projekt-Meeting / | - Klärung Prozessauswirkungen von Projekten |
|
||||
| Abstimmungsrunde** | |
|
||||
| | - Sicherstellung Prozess-Management-Standards in |
|
||||
| | Projekten |
|
||||
| | |
|
||||
| | - Prozess-Integrationsplanung |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Architektur-Board** | - Abgleich Prozessanforderungen mit technischer |
|
||||
| | Machbarkeit, Systemauswahl/-anpassung |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Ad-hoc-Workshops** | - Bei größeren Prozessänderungen oder neuen |
|
||||
| | Initiativen, um gemeinsam Lösungen zu erarbeiten |
|
||||
| | und die Umsetzung vorzubereiten |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Ad-hoc Abstimmung / | - Lösung spezifischer, oft bereichsübergreifender |
|
||||
| Klärung** | Prozesskonflikte oder |
|
||||
| | Prozess-Management-Framework-Interpretationsfragen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Info-Veranstaltung | - Breite Kommunikation von |
|
||||
| / Intranet News** | Prozess-Management-Framework-Updates, |
|
||||
| | Prozessänderungen oder relevanten |
|
||||
| | Prozess-Management-Informationen |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
| **Eskalationsprozess | - Stufe 1: Intern (24-48h) |
|
||||
| (3-stufig)** | |
|
||||
| | - Stufe 2: Mission Board (1-2 Wochen) |
|
||||
| | |
|
||||
| | - Stufe 3: Vision Board (2-4 Wochen)\" |
|
||||
+-----------------------+------------------------------------------------------+
|
||||
635
#05_prozessmanagement/docs/pm_governance-modell.md
Normal file
635
#05_prozessmanagement/docs/pm_governance-modell.md
Normal file
|
|
@ -0,0 +1,635 @@
|
|||
# **Prozess-Management: Governance-Modell**
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## **1. Governance-Philosophie und Grundprinzipien**
|
||||
|
||||
Das Prozess-Management-Governance-Framework folgt dem Prinzip der
|
||||
**\"Befähigungs- Governance\"** - es soll befähigen und unterstützen,
|
||||
nicht kontrollieren und bremsen. Gleichzeitig muss es sich nahtlos in
|
||||
die bestehende DIGITOM-Governance-Architektur integrieren und klare
|
||||
Verantwortlichkeiten sowie Entscheidungswege schaffen.
|
||||
|
||||
### **Leitprinzipien der PM-Governance**
|
||||
|
||||
**Subsidiarität**: Entscheidungen werden auf der niedrigstmöglichen
|
||||
Ebene getroffen, die kompetent und legitimiert ist. Operative
|
||||
Prozess-Beratung braucht keine Gremien-Freigabe, strategische
|
||||
Prozess-Managment-Framework-Änderungen schon.
|
||||
|
||||
**Proportionalität**: Der Governance-Aufwand muss dem Risiko und der
|
||||
Tragweite einer Entscheidung angemessen sein. Eine Template-Anpassung
|
||||
braucht weniger Governance als eine komplette Framework-Transformation.
|
||||
|
||||
**Integration**: PM-Governance ergänzt die bestehende
|
||||
DIGITOM-Governance, ersetzt sie nicht. Vision Board, Mission Board und
|
||||
Demand & Stakeholder Runde (DSR) bleiben die primären Steuerungsgremien.
|
||||
|
||||
**Transparenz**: Alle Governance-Entscheidungen und ihre Begründungen
|
||||
müssen nachvollziehbar dokumentiert und kommuniziert werden.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **2. Interne PM-Governance**
|
||||
|
||||
### **2.1 Framework-Änderungs-Governance**
|
||||
|
||||
Die Governance für Framework-Änderungen folgt einem dreistufigen Modell,
|
||||
das die Komplexität und Tragweite der Änderungen berücksichtigt.
|
||||
|
||||
#### **2.1.1 Kategorie A: Operative Anpassungen**
|
||||
|
||||
**Definition**: Kleinere Verbesserungen, Klarstellungen oder
|
||||
Ergänzungen, die die Framework-Grundlogik nicht verändern.
|
||||
|
||||
**Beispiele**: Template-Updates, Methodenbeschreibungs-Präzisierungen,
|
||||
Tool-Konfigurationsanpassungen, FAQ-Ergänzungen.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Die Prozess-Framework-Manager\*in trifft die Entscheidung
|
||||
eigenständig nach fachlicher Prüfung und Dokumentation.
|
||||
|
||||
2. Das Prozess-Management-Team gibt die formale Freigabe.
|
||||
|
||||
3. Die Leite\*rin Prozess-Management wird zeitnah informiert.
|
||||
|
||||
4. Betroffene Process Owner und Key-User werden über reguläre
|
||||
Kommunikationskanäle benachrichtigt.
|
||||
|
||||
**Implementierung**:
|
||||
|
||||
- Kann sofort umgesetzt werden.
|
||||
|
||||
- Änderungen werden im Framework-Changelog dokumentiert.
|
||||
|
||||
#### **2.1.2 Kategorie B: Taktische Erweiterungen**
|
||||
|
||||
**Definition**: Bedeutendere Änderungen, die neue Elemente einführen
|
||||
oder bestehende erweitern, aber die
|
||||
Prozess-Management-Framework-Architektur beibehalten.
|
||||
|
||||
**Beispiele**: Neue Prozess-Kategorien, zusätzliche
|
||||
PM-Governance-Elemente, erweiterte KPI-Systematiken, neue
|
||||
Qualifizierungsmodule.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Die Prozess-Framework-Manager\*in entwickelt den Vorschlag.
|
||||
|
||||
2. Das Prozess-Management-Team gibt die formale Freigabe.
|
||||
|
||||
3. Betroffene Process Owner werden konsultiert und können Einwände oder
|
||||
Verbesserungsvorschläge einbringen.
|
||||
|
||||
4. Das Mission Board wird über die Änderung informiert und kann
|
||||
Feedback geben.
|
||||
|
||||
**Implementierung**:
|
||||
|
||||
- Erfordert Vorlaufzeit für Stakeholder-Abstimmung und Kommunikation.
|
||||
|
||||
- Implementierung erfolgt zu definierten Stichtagen für Planbarkeit.
|
||||
|
||||
#### **2.1.3 Kategorie C: Strategische Transformationen**
|
||||
|
||||
**Definition**: Fundamentale Änderungen der Framework-Philosophie oder
|
||||
-Architektur, die das Operating Model betreffen.
|
||||
|
||||
**Beispiele**: Wechsel der Grundmethodik, komplette Neudefinition der
|
||||
PM-Governance-Struktur, Integration neuer strategischer Anforderungen.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Die Prozess-Framework-Manager\*in erarbeitet Konzept mit
|
||||
Stakeholder-Analyse und Impact-Assessment.
|
||||
|
||||
2. Die Leiter\*in Prozess-Management koordiniert umfassende
|
||||
Abstimmungsrunde mit allen betroffenen Bereichen.
|
||||
|
||||
3. Das Mission Board führt Vorbewertung durch und gibt Empfehlung ab.
|
||||
|
||||
4. Das Vision Board trifft die finale Entscheidung nach Präsentation
|
||||
des Konzepts.
|
||||
|
||||
**Implementierung**:
|
||||
|
||||
- Erfordert längere Vorlaufzeit mit detailliertem Change
|
||||
Management-Plan.
|
||||
|
||||
- Implementierung erfolgt als formales Transformationsprojekt mit
|
||||
entsprechendem Projektmanagement.
|
||||
|
||||
### **2.2 Interne Ressourcen- und Prioritäts-Governance**
|
||||
|
||||
#### **2.2.1 Kapazitätsallokation**
|
||||
|
||||
Die Leiter\*in Prozess-Management verteilt die verfügbaren
|
||||
PM-Kapazitäten nach folgender Prioritätslogik:
|
||||
|
||||
- Prio 1: Strategische Leistungen mit Vision Board-Freigabe
|
||||
|
||||
- Prio 2: Projekt Leistungen mit Mission Board-Freigabe
|
||||
|
||||
- Prio 3: Compliance-kritische Standard Leistungen
|
||||
|
||||
- Prio 4: Geplante Standard Leistungen aus Jahresplanung
|
||||
|
||||
- Prio 5: Ad-hoc Standard Leistungen nach Verfügbarkeit
|
||||
|
||||
#### **2.2.2 Interne Koordination**
|
||||
|
||||
**Wöchentliche PM-Team-Abstimmung**: Operative Koordination,
|
||||
Ressourcenplanung, Problem-Eskalation.
|
||||
|
||||
**Monatliche Stakeholder-Runde**: Review mit Process Ownern,
|
||||
Feedback-Sammlung, Planungsabstimmung.
|
||||
|
||||
**Regelmäßige Governance-Review**: Framework-Performance,
|
||||
Governance-Optimierung, strategische Ausrichtung.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **3. Leistungs-Governance und Beauftragung**
|
||||
|
||||
### **3.1 Leistungs-Kategorien und Beauftragungslogik**
|
||||
|
||||
#### **3.1.1 Standard Leistungen**
|
||||
|
||||
**Definition**: Wiederkehrende, standardisierte PM-Unterstützung für
|
||||
operative Bedarfe.
|
||||
|
||||
**Beispiele**: Prozess-Workshops in definierten Bereichen,
|
||||
Einzelberatungen, PM-Framework-Schulungen, Prozess-Assessments,
|
||||
Key-User-Support.
|
||||
|
||||
**Beauftragungsberechtigung**: Alle DIGITOM-Mitarbeitenden über
|
||||
Ticketsystem oder direkte Anfrage.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Anfragen werden von zuständiger PM-Rolle (meist Prozess-Berater\*in)
|
||||
bewertet und nach Verfügbarkeit und Priorität bearbeitet.
|
||||
|
||||
2. Bei Ressourcenkonflikten entscheidet die Leiter\*in
|
||||
Prozess-Management.
|
||||
|
||||
#### **3.1.2 Projekt Leistungen**
|
||||
|
||||
**Definition**: Umfangreichere, projektähnliche PM-Unterstützung, die
|
||||
signifikante Ressourcen bindet.
|
||||
|
||||
**Beispiele**: Komplette Prozess-Neugestaltung, PM-Tool-Einführung,
|
||||
bereichsspezifische PM-Framework-Entwicklung, umfassende
|
||||
Prozess-Transformationen.
|
||||
|
||||
**Quantitative Abgrenzung (beispielhaft)**:
|
||||
|
||||
- Leistung über 10 Beratungstage oder
|
||||
|
||||
- Laufzeit über 4 Wochen.
|
||||
|
||||
**Qualitative Abgrenzung (beispielhaft)**:
|
||||
|
||||
- Leistung mit mehreren Fachbereichen/ Abteilungen,
|
||||
|
||||
- Framework-Implikationen oder
|
||||
|
||||
- strategischer Relevanz.
|
||||
|
||||
**Beauftragungsberechtigung**: **Fachbereichs-/ Abteilungsleitungen**,
|
||||
**Projektleitungen**, **Gremien**.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Antrag wird von Leiter\*in PM formuliert und in Mission Board
|
||||
eingebracht.
|
||||
|
||||
2. Mission Board prüft strategische Passung, Ressourcen-Impact und
|
||||
Priorisierung.
|
||||
|
||||
3. Bei Freigabe wird die Leistung als Projekt konfiguriert mit
|
||||
entsprechendem Projektmanagement.
|
||||
|
||||
####
|
||||
|
||||
#### **3.1.3 Strategische Leistungen**
|
||||
|
||||
**Definition**: Strategische PM-Initiativen, die das Operating Model
|
||||
weiterentwickeln oder transformieren.
|
||||
|
||||
**Beispiele**: Entwicklung neuer Governance-Strukturen, strategische
|
||||
Prozess-Digitalisierung, organisationsweite Methodeneinführung,
|
||||
Integration in Transformationsprojekte.
|
||||
|
||||
**Beauftragungsberechtigung**:
|
||||
|
||||
- Vision Board (proaktiv) oder
|
||||
|
||||
- Mission Board/Leiterin PM (als Vorschlag).
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Konzeptentwicklung durch PM-Team mit strategischer
|
||||
Stakeholder-Analyse.
|
||||
|
||||
2. Vision Board-Präsentation mit Ressourcen-Impact, Zeitplan und
|
||||
erwarteten Outcomes.
|
||||
|
||||
3. Bei Freigabe erfolgt Mandatierung als strategisches Projekt mit
|
||||
entsprechender Governance.
|
||||
|
||||
#### **3.1.4 Krisen-Leistungen**
|
||||
|
||||
**Definition**: Dringende Prozess-Unterstützung bei akuten Problemen
|
||||
oder Krisen.
|
||||
|
||||
**Beispiele**:
|
||||
|
||||
- Compliance-Verstöße mit Prozess-Bezug,
|
||||
|
||||
- schwerwiegende Prozess-Störungen,
|
||||
|
||||
- akute Konfliktmediation.
|
||||
|
||||
**Beauftragungsberechtigung**:
|
||||
|
||||
- Jede Abteilungsleitung bei akuten Problemen.
|
||||
|
||||
- Amtsleitung bei kritischen Situationen.
|
||||
|
||||
**Entscheidungsweg**:
|
||||
|
||||
1. Sofortige Bewertung und Klassifizierung durch Leiter:in PM
|
||||
|
||||
2. Ressourcen-Umschichtung nach Krisenlogik (andere Leistungen werden
|
||||
pausiert)
|
||||
|
||||
3. Bildung eines Response-Teams aus relevanten PM-Rollen
|
||||
|
||||
4. Nachträgliche Information an Mission Board
|
||||
|
||||
5. Post-Crisis-Review zur Governance-Optimierung
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
### **3.2 Projektzentrierte Prozessgestaltung: Spezial-PM-Governance**
|
||||
|
||||
**3.2.1 Obligatorische PM-Framework-ComplianceJedes Projekt**, das
|
||||
Prozesse neu gestaltet oder verändert, muss zwingend folgende
|
||||
PM-Elemente berücksichtigen:
|
||||
|
||||
- **Key-User-Integration**: Key-User müssen konsultiert und in die
|
||||
Prozessgestaltung eingebunden werden.
|
||||
|
||||
- **PM-Framework-konforme Dokumentation**: Neue Prozesse müssen nach
|
||||
PM-Standards dokumentiert werden.
|
||||
|
||||
- **Process Owner-Koordination**: Bei Änderungen an bestehenden
|
||||
Prozessen muss der zuständige Process Owner konsultiert werden.
|
||||
|
||||
- **Standardnotation**: Prozessmodellierung muss PM-Framework-konforme
|
||||
Notation verwenden.
|
||||
|
||||
#### **3.2.2 Process Owner-Abnahme als Quality Gate**
|
||||
|
||||
Bei allen Projekten, die Prozesse verändern, die einem Process Owner
|
||||
zugeordnet sind, muss dieser formale Abnahme-Verantwortung übernehmen.
|
||||
Dies umfasst:
|
||||
|
||||
- **Fachliche Korrektheit**: Der Process Owner prüft die
|
||||
End-to-End-Konsistenz des veränderten Prozesses.
|
||||
|
||||
- **Schnittstellen-Impact**: Bewertung der Auswirkungen auf vor- und
|
||||
nachgelagerte Prozesse.
|
||||
|
||||
- **Implementierbarkeit**: Einschätzung der praktischen Umsetzbarkeit im
|
||||
operativen Betrieb.
|
||||
|
||||
- **Process Owner** hat finales Veto-Recht bei inhaltlichen Aspekten
|
||||
|
||||
- Bei Veto: Verpflichtende Mediation durch PM-Leitung
|
||||
|
||||
- Eskalation ans Mission Board nur bei unlösbaren Konflikten -
|
||||
Dokumentationspflicht für Veto-Gründe
|
||||
|
||||
#### **3.2.3 PM-Qualitätsprüfung als methodisches Quality Gate**
|
||||
|
||||
Für alle Projekte mit Prozess-Impact führt die PM-Funktion eine formale
|
||||
Qualitätsprüfung durch:
|
||||
|
||||
- **PM-Framework-Compliance-Check**: Prüfung der Einhaltung aller
|
||||
PM-Standards.
|
||||
|
||||
- **Cross-Process-Impact-Analysis**: Bewertung möglicher Seiteneffekte
|
||||
auf andere Prozesse.
|
||||
|
||||
- **Tool-Kompatibilität**: Sicherstellung der Integration in bestehende
|
||||
PM-Tools.
|
||||
|
||||
- **Dokumentations-Vollständigkeit**: Kontrolle der vollständigen und
|
||||
korrekten Dokumentation.
|
||||
|
||||
Diese Prüfung erfolgt **vor Projektabschluss** und ist **Voraussetzung
|
||||
für die finale Abnahme**.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## **4. Externe Governance-Integration**
|
||||
|
||||
### **4.1 Integration in Vision Board-Governance**
|
||||
|
||||
#### **4.1.1 PM-relevante Vision Board-Entscheidungen**
|
||||
|
||||
Das Vision Board trifft strategische Entscheidungen mit PM-Relevanz:
|
||||
|
||||
- **PM-Strategische Ausrichtung**: Grundsätzliche Rolle und
|
||||
Positionierung der PM-Funktion in DIGITOM.
|
||||
|
||||
- **Framework-Transformationen**: Freigabe strategischer
|
||||
Framework-Änderungen (Kategorie C).
|
||||
|
||||
- **Strategische Leistungen**: Beauftragung und Priorisierung
|
||||
strategischer PM-Initiativen.
|
||||
|
||||
- **PM-Ressourcen-Rahmen**: Grundsätzliche Kapazitäts- und
|
||||
Budget-Entscheidungen für PM-Funktion.
|
||||
|
||||
#### **4.1.2 PM-Input für Vision Board**
|
||||
|
||||
Die Leiter\*in PM liefert **strategischen Input** für Vision
|
||||
Board-Entscheidungen:
|
||||
|
||||
- **Prozesslandschafts-Assessment**: Jährliche Bewertung der
|
||||
Prozess-Reife und strategischen Prozess-Herausforderungen.
|
||||
|
||||
- **Framework-Entwicklungsvorschläge**: Vorschläge für strategische
|
||||
Framework-Weiterentwicklungen.
|
||||
|
||||
- **Organisationsreife-Einschätzung**: Assessment der PM-Kompetenz und
|
||||
Change-Bereitschaft in DIGITOM.
|
||||
|
||||
### **4.2 Integration in Mission Board-Governance**
|
||||
|
||||
#### **4.2.1 PM-relevante Mission Board-Entscheidungen**
|
||||
|
||||
Das Mission Board fungiert als **taktische Steuerungsebene** für
|
||||
PM-Leistungen:
|
||||
|
||||
- **Freigabe von Projekt-Leistungen**: Entscheidung über
|
||||
ressourcenintensive PM-Unterstützung für Projekte.
|
||||
|
||||
- **Prioritäts-Konflikte**: Auflösung von Ressourcenkonflikten zwischen
|
||||
verschiedenen PM-Anfragen.
|
||||
|
||||
- **Prozess-Governance-Eskalationen**: Entscheidung bei schwerwiegenden
|
||||
Governance-Konflikten.
|
||||
|
||||
- **Jährliche PM-Leistungsplanung**: Freigabe des Jahresplans für
|
||||
geplante PM-Leistungen.
|
||||
|
||||
####
|
||||
|
||||
#### **4.2.2 Mission Board-Reporting durch PM**
|
||||
|
||||
- **Regelmäßige Governance-Reports**: Performance der PM-Funktion,
|
||||
Framework-Adoption, kritische Issues.
|
||||
|
||||
- **Ad-hoc Eskalations-Briefings**: Bei strategischen Problemen oder
|
||||
Ressourcenengpässen.
|
||||
|
||||
- **Jährliche Leistungsplanung**: Vorstellung des geplanten
|
||||
Leistungs-Portfolios für das Folgejahr.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **5. Verantwortungs- und Eskalationsarchitektur**
|
||||
|
||||
### **5.1 Primäre Verantwortlichkeiten**
|
||||
|
||||
#### **5.1.1 Leiter\*in Prozess-Management**
|
||||
|
||||
- **Strategische Verantwortung**: Ausrichtung der PM-Funktion an
|
||||
DIGITOM-Zielen.
|
||||
|
||||
- **Ressourcen-Verantwortung**: Allokation von PM-Kapazitäten nach
|
||||
strategischen Prioritäten.
|
||||
|
||||
- **Stakeholder-Verantwortung**: Management der Beziehungen zu Gremien
|
||||
und Fachbereichen/ Abteilungen.
|
||||
|
||||
- **Eskalations-Verantwortung**: Entscheidung bei PM-internen Konflikten
|
||||
und strategischen Issues.
|
||||
|
||||
- **Bei kritischen Ressourcenkonflikten**: Empfehlung ans Mission Board
|
||||
mit Entscheidungsvorlage
|
||||
|
||||
- **Delegation von Entscheidungen nach oben bei**:
|
||||
|
||||
- Konflikten mit gesetzlichen vs. strategischen Prioritäten
|
||||
|
||||
- Grundsätzlichen Richtungsentscheidungen - Politisch sensiblen Themen
|
||||
|
||||
#### **5.1.2 Prozess-Framework-Manager\*in**
|
||||
|
||||
- **Framework-Verantwortung**: Qualität, Aktualität und Anwendbarkeit
|
||||
des PM-Frameworks.
|
||||
|
||||
- **Standards-Verantwortung**: Definition und Pflege einheitlicher
|
||||
PM-Standards.
|
||||
|
||||
- **Innovation-Verantwortung**: Integration neuer Tools, Methoden und
|
||||
Best Practices.
|
||||
|
||||
#### **5.1.3 Prozesslandschafts-Koordinator\*in**
|
||||
|
||||
- **Governance-Verantwortung**: Überwachung der PM-Framework-Compliance
|
||||
und Governance-Qualität.
|
||||
|
||||
- **Koordinations-Verantwortung**: Abstimmung zwischen verschiedenen
|
||||
Process Ownern.
|
||||
|
||||
- **Reporting-Verantwortung**: Bereitstellung von
|
||||
PM-Governance-Transparenz für Gremien
|
||||
|
||||
#### **5.1.4 Prozess-Berater:innen**
|
||||
|
||||
- **Leistungsverantwortung**: Qualität der direkten PM-Beratung und
|
||||
-Unterstützung.
|
||||
|
||||
<!-- -->
|
||||
|
||||
- **Kundenverantwortung**: Zufriedenheit und Erfolg der betreuten
|
||||
Fachbereiche/ Abteilungen.
|
||||
|
||||
#### **5.1.5 Key-User-Netzwerk-Manager\*in**
|
||||
|
||||
- **Community-Verantwortung**: Aufbau und Betreuung des dezentralen
|
||||
PM-Netzwerks.
|
||||
|
||||
- **Befähigungs-Verantwortung**: Kompetenzentwicklung und
|
||||
Selbsthilfe-Befähigung.
|
||||
|
||||
###
|
||||
|
||||
### **5.2 Eskalationswege und -trigger**
|
||||
|
||||
#### **5.2.1 Stufe 1: Operative Eskalation (binnen PM-Funktion)**
|
||||
|
||||
- **Trigger**: Ressourcenkonflikte, komplexe Beratungsfälle,
|
||||
Methodenunklarheiten.
|
||||
|
||||
- **Eskalationsweg**: Beratende PM-Rolle → Leiterin PM.
|
||||
|
||||
- **Zeitrahmen**: **24-48 Stunden** für Entscheidung.
|
||||
|
||||
- **Outcomes**: Ressourcen-Umpriorisierung, methodische Klärung, interne
|
||||
Lösungsfindung.
|
||||
|
||||
#### **5.2.2 Stufe 2: Taktische Eskalation (Mission Board)**
|
||||
|
||||
- **Trigger**: Strategische Ressourcenkonflikte, Framework-Widerstand,
|
||||
prozessübergreifende Konflikte.
|
||||
|
||||
- **Eskalationsweg**: Leiterin PM → Mission Board (über reguläre
|
||||
Sitzungen oder ad-hoc).
|
||||
|
||||
- **Zeitrahmen**: **1-2 Wochen** für Mission Board-Behandlung.
|
||||
|
||||
- **Outcomes**: Prioritäts-Neuordnung, Konfliktlösung, zusätzliche
|
||||
Ressourcen-Freigabe.
|
||||
|
||||
Folgende Situationen erfordern eine verpflichtende Eskalation ans
|
||||
Mission Board:
|
||||
|
||||
- Ressourcenkonflikte zwischen Projekten mit harten Deadlines
|
||||
|
||||
- Governance-Lücken, die nicht binnen 4 Wochen gelöst werden können
|
||||
|
||||
- Verweigerung der Zusammenarbeit durch Abteilungen
|
||||
|
||||
- Grundsätzliche Framework-Widerstände aus mehreren Bereichen
|
||||
|
||||
#### **5.2.3 Stufe 3: Strategische Eskalation (Vision Board)**
|
||||
|
||||
- **Trigger**: Grundsätzliche Framework-Konflikte, strategische
|
||||
PM-Richtungsfragen, organisationsweite PM-Krisen.
|
||||
|
||||
- **Eskalationsweg**: Mission Board → Vision Board oder direkt durch
|
||||
Leiterin PM bei Krisensituationen.
|
||||
|
||||
- **Zeitrahmen**: **2-4 Wochen** für strategische Entscheidung.
|
||||
|
||||
- **Outcomes**: Strategische Neuausrichtung,
|
||||
Framework-Grundsatzentscheidungen, Organisationsänderungen.
|
||||
|
||||
#### **5.2.3 Governance-Lücken-Management**
|
||||
|
||||
Wenn die PLK eine Governance-Lücke im DIGIT/ DIGITOM identifiziert:
|
||||
|
||||
**Kurzfristig lösbar:**
|
||||
|
||||
- PLK informiert Prozessberater:in
|
||||
|
||||
- Prozessberater:in spricht mit verantwortlicher Person im Fachbereich/
|
||||
Abteilungen
|
||||
|
||||
- Bei erfolgreicher Lösung: Dokumentation durch PLK, Monitoring der
|
||||
Umsetzung
|
||||
|
||||
**Langfristig/strukturell:**
|
||||
|
||||
- PLK dokumentiert die Governance-Lücke
|
||||
|
||||
- Strukturierte Eskalation über LPM ans Mission Board
|
||||
|
||||
- Mission Board priorisiert und entscheidet über Maßnahmen
|
||||
|
||||
- PLK verfolgt initiierte Maßnahmen bis zur Schließung der Lücke nach
|
||||
|
||||
**Keine Kooperation des Fachbereichs/ Abteilung:**
|
||||
|
||||
- Direkte Eskalation ans Mission Board mit Hinweis auf Verweigerung
|
||||
|
||||
- Mission Board entscheidet über verbindliche Maßnahmen
|
||||
|
||||
### **5.3 Konfliktlösungs-Mechanismen**
|
||||
|
||||
#### **5.3.1 Framework-Widerstand**
|
||||
|
||||
- **Erste Stufe**: Prozess-Berater\*in führt Stakeholder-Dialog zur
|
||||
Bedarfsklärung.
|
||||
|
||||
- **Zweite Stufe**: Prozesslandschafts-Koordinator\*in moderiert
|
||||
Interessenausgleich.
|
||||
|
||||
- **Dritte Stufe**: Leiter\*in PM eskaliert an zuständiges Gremium für
|
||||
autoritative Entscheidung.
|
||||
|
||||
#### **5.3.2 Ressourcen-Konkurrenz**
|
||||
|
||||
- **Dokumentation** aller konkurrierenden Anfragen mit Business Case und
|
||||
Dringlichkeit.
|
||||
|
||||
- **Stakeholder-Konsultation** zur Interessenabwägung.
|
||||
|
||||
- **Entscheidung** durch Leiterin PM nach definierten
|
||||
Prioritätskriterien.
|
||||
|
||||
- **Transparente Kommunikation** der Entscheidung und alternative
|
||||
Lösungsoptionen.
|
||||
|
||||
#### **5.3.3 Compliance-Konflikte**
|
||||
|
||||
- **Sofortige Einbindung** relevanter Compliance-Funktionen (ISB,
|
||||
Datenschutz, Qualitätsmanagement).
|
||||
|
||||
- **Gemeinsame Lösungsentwicklung** zwischen PM und
|
||||
Compliance-Bereichen.
|
||||
|
||||
- **Eskalation** an Mission Board bei unauflösbaren Zielkonflikten.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **6. Jahresplanung und strategische Leistungs-Governance**
|
||||
|
||||
### **6.1 Strategische Leistungsplanung**
|
||||
|
||||
#### **6.1.1 Jahresplanungsprozess**
|
||||
|
||||
- **Q4 des Vorjahres**: Bedarfserhebung bei allen Stakeholdern und
|
||||
strategische Priorisierung.
|
||||
|
||||
- **Dezember**: Entwurf des PM-Leistungsplans mit Ressourcenallokation
|
||||
und Zeitplanung.
|
||||
|
||||
- **Januar**: Mission Board-Freigabe des Plans nach eventuellen
|
||||
Anpassungen.
|
||||
|
||||
- **Februar**: Kommunikation und Abstimmung der geplanten Leistungen mit
|
||||
Stakeholdern.
|
||||
|
||||
#### **6.1.2 Leistungs-Portfolio-Struktur (beispielhaft)**
|
||||
|
||||
- **40% Strategische Leistungen**: Vom Vision Board beauftragte
|
||||
strategische Initiativen.
|
||||
|
||||
- **30% Projekt Leistungen**: Geplante projektbezogene PM-Unterstützung
|
||||
nach Mission Board-Priorisierung.
|
||||
|
||||
- **20% Geplante Standard-Leistungen:** Regelmäßige Leistungen wie
|
||||
Schulungen, Community-Events, Framework-Updates.
|
||||
|
||||
- **10% Krisen-Leistungen**
|
||||
169
#05_prozessmanagement/docs/pm_konzeptrahmen.md
Normal file
169
#05_prozessmanagement/docs/pm_konzeptrahmen.md
Normal file
|
|
@ -0,0 +1,169 @@
|
|||
# **Prozess-Management: Konzeptrahmen und Dokumentationsarchitektur**
|
||||
|
||||
## **1. Die Herausforderung: Zwischen Standardisierung und Befähigung**
|
||||
|
||||
Moderne Verwaltungsorganisationen stehen vor einem fundamentalen
|
||||
Dilemma: Sie müssen gleichzeitig Stabilität gewährleisten und Agilität
|
||||
ermöglichen. Im Kontext des DIGITOM manifestiert sich diese Spannung
|
||||
besonders deutlich in der Frage, wie Prozesse gestaltet und gesteuert
|
||||
werden sollen.
|
||||
|
||||
Die traditionelle Antwort -- zentrale Vorgaben und strikte Kontrolle --
|
||||
greift in einer komplexen, vernetzten Organisation zu kurz. Gleichzeitig
|
||||
führt völlige Dezentralisierung zu Wildwuchs und Ineffizienz. Die
|
||||
Prozess-Management-Funktion des DIGITOM navigiert bewusst in diesem
|
||||
Spannungsfeld.
|
||||
|
||||
## **2. Die Lösung: Eine mehrdimensionale Organisationsarchitektur**
|
||||
|
||||
Statt einer monolithischen Struktur wurde für das Prozess-Management
|
||||
eine vielschichtige Architektur entwickelt. Diese erlaubt es,
|
||||
verschiedene organisationale Bedürfnisse gleichzeitig zu adressieren:
|
||||
|
||||
- **Strategische Steuerung** bei gleichzeitiger operativer Flexibilität
|
||||
|
||||
- **Methodische Standards** bei gleichzeitiger fachlicher Autonomie
|
||||
|
||||
- **Zentrale Kompetenz** bei gleichzeitiger dezentraler Befähigung
|
||||
|
||||
Diese scheinbaren Widersprüche werden nicht aufgelöst, sondern produktiv
|
||||
genutzt. Aus diesem Spannungsfeld entsteht Antrieb für eine ständige
|
||||
Verbesserung.
|
||||
|
||||
##
|
||||
|
||||
## **3. Die Dokumentationsarchitektur: Fünf Perspektiven, ein System**
|
||||
|
||||
Die Komplexität dieser Organisationsform spiegelt sich in der bewusst
|
||||
gewählten Dokumentationsstruktur wider. Jedes Dokument beleuchtet das
|
||||
Gesamtsystem aus einer spezifischen Perspektive und erfüllt einen
|
||||
eigenen Zweck:
|
||||
|
||||
### **3.1 Die Funktionsbeschreibung: Legitimation und Mandat**
|
||||
|
||||
**Kernfrage: Was darf und soll die PM-Funktion?**
|
||||
|
||||
Dieses Dokument schafft die formale Grundlage. Es definiert den
|
||||
Verantwortungsbereich, grenzt Zuständigkeiten ab und legitimiert das
|
||||
Handeln der PM-Funktion innerhalb der Gesamtorganisation. Hier findet
|
||||
sich die \"Verfassung\" der Funktion -- ihre grundlegenden Rechte und
|
||||
Pflichten.
|
||||
|
||||
### **3.2 Das Leistungs-Canvas: Der Nutzennachweis**
|
||||
|
||||
**Kernfrage: Welchen konkreten Mehrwert schafft die PM-Funktion?**
|
||||
|
||||
Während die Funktionsbeschreibung sagt, was getan werden darf, zeigt das
|
||||
Leistungs-Canvas, was tatsächlich geleistet wird. Es nimmt konsequent
|
||||
die Perspektive der Nutzer:innen ein und macht sichtbar, wie aus
|
||||
Aktivitäten konkreter Nutzen entsteht. Das Canvas-Format ermöglicht
|
||||
dabei eine ganzheitliche Betrachtung aller relevanten Elemente.
|
||||
|
||||
### **3.3 Das Rollenmodell: Die Arbeitsorganisation**
|
||||
|
||||
**Kernfrage: Wer trägt welche Verantwortung?**
|
||||
|
||||
Acht differenzierte Rollen ermöglichen es, verschiedene Aspekte der
|
||||
PM-Arbeit klar zu verteilen. Von der strategischen Führung über
|
||||
methodische Expertise bis zur operativen Beratung -- jede Rolle hat
|
||||
ihren spezifischen Fokus. Diese Differenzierung verhindert
|
||||
Interessenskonflikte und schafft Klarheit in der Zusammenarbeit.
|
||||
|
||||
### **3.4 Das Governance-Modell: Die Spielregeln**
|
||||
|
||||
**Kernfrage: Wie werden Entscheidungen getroffen?**
|
||||
|
||||
Governance bedeutet hier nicht Kontrolle, sondern Befähigung. Das Modell
|
||||
definiert differenzierte Entscheidungswege für verschiedene
|
||||
Leistungstypen -- von niedrigschwelligen Standardleistungen bis zu
|
||||
strategischen Transformationen. Eskalationspfade sind klar definiert,
|
||||
aber so gestaltet, dass sie nur bei echtem Bedarf genutzt werden.
|
||||
|
||||
###
|
||||
|
||||
### **3.5 Die RACI-Matrix: Das Navigationsinstrument**
|
||||
|
||||
**Kernfrage: Wer ist wofür konkret zuständig?**
|
||||
|
||||
Als verdichtete Übersicht macht die Matrix Verantwortlichkeiten auf
|
||||
einen Blick sichtbar. Sie dient als praktisches Nachschlagewerk im
|
||||
Arbeitsalltag und verhindert Zuständigkeitskonflikte durch klare
|
||||
Rollenzuweisungen.
|
||||
|
||||
## **4. Systemische Zusammenhänge: Wie die Elemente ineinandergreifen**
|
||||
|
||||
Die fünf Dokumente stehen nicht isoliert nebeneinander, sondern bilden
|
||||
ein integriertes System:
|
||||
|
||||
- Die **Funktionsbeschreibung** legitimiert die im **Leistungs-Canvas**
|
||||
beschriebene Leistungen
|
||||
|
||||
- Das **Rollenmodell** operationalisiert die Leistungserbringung durch
|
||||
klare Verantwortlichkeiten
|
||||
|
||||
- Das **Governance-Modell** regelt, wie diese Rollen zusammenarbeiten
|
||||
und Entscheidungen treffen
|
||||
|
||||
- Die **RACI-Matrix** macht diese Zusammenarbeit transparent und
|
||||
nachvollziehbar
|
||||
|
||||
Jedes Element verstärkt und ergänzt die anderen. Gemeinsam schaffen sie
|
||||
ein robustes, aber flexibles Organisationsdesign.
|
||||
|
||||
## **5. Navigationshinweise: Verschiedene Wege durch die Dokumentation**
|
||||
|
||||
Je nach Rolle und Erkenntnisinteresse bieten sich unterschiedliche
|
||||
Einstiegspunkte:
|
||||
|
||||
- **Für Führungskräfte und Entscheidungsträger:innen:**\
|
||||
Start beim **Governance-Modell**, um Entscheidungswege und
|
||||
Steuerungsmechanismen zu verstehen. Anschließend das
|
||||
**Leistungs-Canvas** für den strategischen Nutzen.
|
||||
|
||||
- **Für operative Teams und Fachbereiche:\**
|
||||
Einstieg über das **Leistungs-Canvas**, um verfügbare Services und
|
||||
Zugangswege zu erkunden. Die **RACI-Matrix** zeigt dann konkrete
|
||||
Ansprechpersonen.
|
||||
|
||||
- **Für neue Mitarbeitende der PM-Funktion:\**
|
||||
Beginn mit der **Funktionsbeschreibung** für das grundlegende
|
||||
Verständnis, dann das **Rollenmodell** für die eigene Verortung im
|
||||
Team.
|
||||
|
||||
- **Für Projektleitungen:**\
|
||||
Fokus auf **Governance-Modell** (Abschnitt zur projektzentrierten
|
||||
Prozessgestaltung) und **RACI-Matrix** für konkrete Abstimmungswege.
|
||||
|
||||
## **6. Die zentrale Balance: Standardisierung ermöglichen, Autonomie bewahren**
|
||||
|
||||
Das Prozess-Management im DIGITOM verfolgt keine totale Harmonisierung.
|
||||
Stattdessen schafft es einen verbindlichen Rahmen, innerhalb dessen
|
||||
fachliche Vielfalt möglich bleibt. Diese Balance zeigt sich in mehreren
|
||||
Dimensionen:
|
||||
|
||||
- **Methodische Standards** bei **fachlicher Freiheit\**
|
||||
|
||||
- **Zentrale Governance** bei **dezentraler Ausführung**
|
||||
|
||||
- **Verbindliche Frameworks** bei **situativer Anpassung**
|
||||
|
||||
Die Kunst liegt darin, genug Struktur für Effizienz zu schaffen, ohne
|
||||
die notwendige Flexibilität zu ersticken.
|
||||
|
||||
## **Ausblick: Ein lernendes System**
|
||||
|
||||
Die hier dokumentierte Organisationsform ist kein statisches Konstrukt.
|
||||
Sie ist darauf angelegt, sich weiterzuentwickeln -- durch Feedback aus
|
||||
der Praxis, veränderte Rahmenbedingungen und neue Erkenntnisse.
|
||||
|
||||
Die mehrdimensionale Dokumentation ermöglicht dabei gezielte
|
||||
Anpassungen: Einzelne Elemente können weiterentwickelt werden, ohne das
|
||||
Gesamtsystem zu destabilisieren. So entsteht eine Organisation, die
|
||||
gleichzeitig stabil und adaptiv ist -- genau das, was moderne Verwaltung
|
||||
braucht.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
*Die vorliegende Dokumentation ist das Ergebnis eines intensiven
|
||||
Konzeptionsprozesses. Sie spiegelt den aktuellen Entwicklungsstand wider
|
||||
und wird kontinuierlich fortgeschrieben.*
|
||||
419
#05_prozessmanagement/docs/pm_leistungs-canvas.md
Normal file
419
#05_prozessmanagement/docs/pm_leistungs-canvas.md
Normal file
|
|
@ -0,0 +1,419 @@
|
|||
# **Prozess-Management: Leistungs-Canvas**
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## **1. Warum ein Leistungs-Canvas?**
|
||||
|
||||
Organisationen verstehen sich oft durch ihre formalen Strukturen --
|
||||
Organigramme, Stellenbeschreibungen, Verantwortungsmatrizen. Diese
|
||||
Instrumente sind wichtig, greifen aber zu kurz, wenn es darum geht, den
|
||||
tatsächlichen Wertbeitrag einer Funktion sichtbar zu machen. Das
|
||||
Leistungs-Canvas wählt deshalb einen anderen Zugang: **Es betrachtet die
|
||||
Prozess-Management-Funktion konsequent aus der Perspektive ihrer
|
||||
Nutzer:innen**.
|
||||
|
||||
Diese Perspektivverschiebung macht sichtbar, was in traditionellen
|
||||
Funktionsbeschreibungen oft untergeht: Wie entsteht konkret Nutzen?
|
||||
Welche Beziehungen ermöglichen wirksame Zusammenarbeit? Über welche Wege
|
||||
werden Leistungen tatsächlich zugänglich?
|
||||
|
||||
Das Canvas-Format hat sich bei vielen Organisationen als Instrument zur
|
||||
Geschäftsmodellentwicklung etabliert. Seine Stärke liegt in der
|
||||
visuellen Verdichtung komplexer Zusammenhänge. Für den
|
||||
Verwaltungskontext wurde es hier adaptiert: Statt um Erlösströme und
|
||||
Kostenstrukturen geht es um Leistungsbeziehungen und
|
||||
Ressourcenallokation. Statt Kunden werden Nutzer:innen in den
|
||||
Mittelpunkt gestellt.
|
||||
|
||||
Die Entwicklung dieses Canvas erfolgte in einem kollaborativen
|
||||
Workshop-Format. Vertreter:innen der Prozess-Management Funktion
|
||||
erarbeiteten gemeinsam, welche Leistungen die PM-Funktion erbringen soll
|
||||
und wie diese optimal zugänglich gemacht werden können.
|
||||
|
||||
Drei Leitfragen strukturierten diesen Prozess:
|
||||
|
||||
- Was erwarten die verschiedenen Nutzergruppen von einer PM-Funktion?
|
||||
|
||||
- Wie kann die Funktion diese Erwartungen bestmöglich erfüllen?
|
||||
|
||||
- Welche Voraussetzungen müssen dafür geschaffen werden?
|
||||
|
||||
Die Antworten auf diese Fragen verdichten sich im Canvas zu einem
|
||||
kohärenten Gesamtbild.
|
||||
|
||||
Das Canvas erfüllt damit mehrere Funktionen gleichzeitig: Es schafft
|
||||
Klarheit über das Leistungsportfolio, macht Zusammenhänge zwischen
|
||||
verschiedenen Elementen sichtbar und dient als Kommunikationsinstrument
|
||||
zwischen PM-Funktion und ihren Nutzer:innen. Nicht zuletzt ist es ein
|
||||
Steuerungsinstrument, das zeigt, wo Ressourcen investiert werden müssen,
|
||||
um maximalen Nutzen zu generieren.
|
||||
|
||||
##
|
||||
|
||||
## **2. Die Logik des Canvas verstehen**
|
||||
|
||||
Das Leistungs-Canvas strukturiert die PM-Funktion in sieben miteinander
|
||||
verbundene Bausteine. Diese Bausteine folgen einer inneren Logik: Sie
|
||||
beginnen bei den Nutzer:innen und ihren Bedarfen, definieren das
|
||||
Leistungsversprechen und zeigen auf, wie dieses Versprechen eingelöst
|
||||
wird.
|
||||
|
||||
Die rechte Seite des Canvas fokussiert auf die Außenperspektive -- wer
|
||||
sind die Nutzer:innen, welche Beziehungen werden zu ihnen aufgebaut,
|
||||
über welche Kanäle erfolgt die Interaktion. Die linke Seite richtet den
|
||||
Blick nach innen -- welche Aktivitäten sind erforderlich, welche
|
||||
Ressourcen werden benötigt, mit wem muss kooperiert werden. Im Zentrum
|
||||
steht das Wertversprechen als verbindendes Element.
|
||||
|
||||
{width="6.267716535433071in"
|
||||
height="3.5416666666666665in"}
|
||||
|
||||
Diese Struktur ist kein Selbstzweck. Sie zwingt dazu, konsequent vom
|
||||
Nutzen her zu denken und erst dann die erforderlichen Mittel zu
|
||||
definieren. Klassische Organisationsentwicklung geht oft den umgekehrten
|
||||
Weg -- definiert erst Strukturen und Prozesse, dann deren Zweck. Das
|
||||
Canvas kehrt diese Logik um.
|
||||
|
||||
##
|
||||
|
||||
## **3. Die sieben Bausteine im Detail**
|
||||
|
||||
### **3.1 Cluster A: Für wen die PM-Funktion da ist**
|
||||
|
||||
#### **3.1.1 Nutzendensegmente**
|
||||
|
||||
Die verschiedenen internen Zielgruppen, für die die PM-Funktion
|
||||
Leistungen erbringt. Jedes Segment hat spezifische Bedarfe, Erwartungen
|
||||
und Arbeitsweisen. Die Differenzierung ermöglicht passgenaue Angebote --
|
||||
von strategischer Transparenz für Gremien bis zur methodischen
|
||||
Unterstützung für operative Teams. Entscheidend ist das Verständnis,
|
||||
dass unterschiedliche Nutzergruppen unterschiedliche Formen der
|
||||
Unterstützung benötigen:
|
||||
|
||||
- **Management-Gremien (Vision Board, Mission Board)** benötigen
|
||||
Transparenz über die Prozesslandschaft und Governance-Berichte. Sie
|
||||
profitieren von einheitlichen Standards zur besseren Steuerung und
|
||||
strategischen Ausrichtung der Organisation.
|
||||
|
||||
- **Abteilungsleitungen** nutzen die Prozessperspektive für bessere
|
||||
Ressourcenplanung, Steuerung ihrer Bereiche und fundierte
|
||||
Entscheidungen bei bereichsübergreifenden Themen.
|
||||
|
||||
- **Process Owner der Teilprozesse** -- Stakeholder Management, Demand
|
||||
Portfolio Management, Projekt Portfolio Management und Service
|
||||
Portfolio Management -- tragen die End-to-End-Verantwortung für ihre
|
||||
jeweiligen Teilprozesse und benötigen methodische Unterstützung zur
|
||||
Prozessoptimierung und -steuerung.
|
||||
|
||||
- **Fachbereiche und ihre Teams mit Key-Usern** sind die Hauptadressaten
|
||||
für methodische Unterstützung, Befähigung und Standards, um ihre
|
||||
fachspezifischen Prozesse eigenständig zu dokumentieren und zu
|
||||
verbessern.
|
||||
|
||||
- **Projekt- und Programmorganisationen** greifen auf das
|
||||
Prozessmanagement zurück für einheitliche Prozessvorgaben, methodische
|
||||
Beratung und Sicherstellung der Framework-Compliance in ihren
|
||||
Projekten.
|
||||
|
||||
#### **3.1.2 Nutzendenbeziehung**
|
||||
|
||||
Die Art und Qualität der Zusammenarbeit zwischen PM-Funktion und ihren
|
||||
Nutzer:innen. Sie definiert das \"Wie\" der Interaktion --
|
||||
partnerschaftlich, befähigend, beratend oder formal steuernd. Die
|
||||
bewusste Gestaltung dieser Beziehungen prägt maßgeblich, ob und wie gut
|
||||
die PM-Leistungen angenommen und wirksam werden:
|
||||
|
||||
- **Partnerschaftliche Zusammenarbeit & Co-Kreation**: Aufbau von
|
||||
Vertrauen und kollaborative Zusammenarbeit mit Fachbereichen, wobei
|
||||
Key-User als zentrale Partner:innen eng in die Entwicklung und
|
||||
Umsetzung von Prozesslösungen eingebunden werden.
|
||||
|
||||
- **Persönliche Beratung & Dedizierte Unterstützung**: Bereitstellung
|
||||
direkter Beratung und Coaching, insbesondere bei komplexen
|
||||
Prozessherausforderungen oder strategischen Initiativen, mit
|
||||
besonderem Fokus auf die Befähigung der Key-User als
|
||||
Multiplikator:innen.
|
||||
|
||||
- **Befähigungsorientierte Begleitung**: Konsequente Fokussierung auf
|
||||
Befähigung statt Ausführung -- Ermächtigung der Nutzenden, ihre
|
||||
Prozesse eigenständig zu managen, wobei Key-User als erste
|
||||
Ansprechpartner:innen in ihren Bereichen etabliert werden.
|
||||
|
||||
- **Community Building & Facilitation**: Aktive Förderung und Pflege des
|
||||
Key-User-Netzwerks als zentrales Element für gemeinsames Lernen,
|
||||
Erfahrungsaustausch und kontinuierliche Verbesserung über
|
||||
Abteilungsgrenzen hinweg.
|
||||
|
||||
- **Proaktive Impulsgebung**: Agieren als Impulsgeber durch die
|
||||
Vorstellung neuer Methoden, Best Practices und die Anregung des
|
||||
Prozessdenkens in der Organisation, wobei Key-User als
|
||||
Multiplikator:innen diese Impulse in ihre Fachbereiche tragen.
|
||||
|
||||
- **Governance-basierte Interaktion**: Formelles Reporting, strategische
|
||||
Abstimmung und Eskalationsmanagement mit Vision/Mission Boards,
|
||||
einschließlich regelmäßiger Berichte über die Entwicklung der
|
||||
dezentralen Prozesskompetenzen.
|
||||
|
||||
#### **3.1.3 Kanäle**
|
||||
|
||||
Die Wege und Formate, über die PM-Leistungen zugänglich werden. Von
|
||||
persönlicher Beratung über digitale Plattformen bis zu
|
||||
Community-Formaten -- jeder Kanal erfüllt spezifische Funktionen und
|
||||
erreicht unterschiedliche Zielgruppen. Die Vielfalt der Kanäle sichert
|
||||
niedrigschwelligen Zugang und ermöglicht situationsgerechte
|
||||
Unterstützung.
|
||||
|
||||
- **Direkte Interaktions- & Befähigungskanäle** umfassen Workshops und
|
||||
Schulungen zur Vermittlung von Wissen, Methoden und
|
||||
Werkzeugkompetenzen in verschiedenen Formaten. Beratungsgespräche und
|
||||
individuelles oder Team-Coaching bieten maßgeschneiderte
|
||||
Unterstützung. Die Moderation von Prozess-Workshops auf Anfrage
|
||||
unterstützt kollaborative Prozessarbeit, insbesondere bei komplexen
|
||||
oder bereichsübergreifenden Prozessen. Ein Ticketsystem dient als
|
||||
formaler Kanal für Anfragen mit automatischem Routing an das PM-Team.
|
||||
|
||||
- **Self-Service & digitale Lernkanäle** bieten niedrigschwelligen
|
||||
Zugang: Eine zentrale Wissensplattform (Confluence) ermöglicht
|
||||
selbstständigen Zugang zum PM-Framework, Methodenhandbuch, Templates,
|
||||
Prozessregister und FAQs. Ein KI-gestützter PM-Assistent bietet
|
||||
interaktiven Dialog für Prozessfragen und kontextspezifische
|
||||
Antworten. Das Prozessvisualisierungs-Tool (Picture Prozess Plattform)
|
||||
ermöglicht die eigenständige Arbeit mit der Prozesslandschaft.
|
||||
E-Learning-Module bieten strukturierte Lernpfade für selbstgesteuertes
|
||||
Lernen.
|
||||
|
||||
- **Community- & Kommunikationskanäle** fördern den Austausch:
|
||||
Key-User-Netzwerktreffen und Communities of Practice ermöglichen
|
||||
regelmäßigen Erfahrungsaustausch und kollektives Lernen.
|
||||
Informationsveranstaltungen und Newsletter kommunizieren
|
||||
Framework-Updates und relevante PM-Informationen. Das DigiLog
|
||||
Podcast-Format teilt Einsichten und Erfolgsgeschichten zur Förderung
|
||||
des Prozessdenkens.
|
||||
|
||||
### **3.2 Cluster B: Was die PM-Funktion bietet**
|
||||
|
||||
#### **3.2.1 Wertversprechen**
|
||||
|
||||
Der konkrete Nutzen, den die PM-Funktion für ihre verschiedenen
|
||||
Zielgruppen schafft. Es übersetzt organisationale Bedarfe in greifbare
|
||||
Leistungszusagen. Das Wertversprechen verbindet, was Nutzer:innen
|
||||
brauchen, mit dem, was die PM-Funktion leisten kann -- und macht damit
|
||||
den Mehrwert der Funktion explizit. Es ist das zentrale Element, das
|
||||
alle anderen Bausteine ausrichtet:
|
||||
|
||||
- **Für Strategische Gremien** bietet die PM-Funktion strategische
|
||||
Prozess-Governance und Transparenz durch eine konsistente, strategisch
|
||||
ausgerichtete Prozesslandschaft. Messbare Verbesserung und
|
||||
KPI-basierte Steuerung ermöglichen faktenbasierte Bewertung von
|
||||
Prozessleistung und Nachweis von Optimierungserfolgen.
|
||||
Entscheidungsunterstützung und Risikominimierung erfolgen durch
|
||||
Konzepte zur Weiterentwicklung des Operating Models und proaktive
|
||||
Meldung von Risiken. Die Schaffung skalierbarer Prozessstrukturen
|
||||
ermöglicht Organisationswachstum und erschließt systematisch
|
||||
Automatisierungspotenziale.
|
||||
|
||||
- **Für Fachbereiche, Abteilungsleitungen, Key User und Projektteams**
|
||||
stellt die PM-Funktion ein einheitliches Prozessmanagement-Framework
|
||||
mit verbindlichen Standards, Methoden, Werkzeugen und Templates
|
||||
bereit. Methodische Beratung und Unterstützung erfolgt von der
|
||||
Erstaufnahme bis zur Automatisierung. Die systematische Befähigung zur
|
||||
Selbsthilfe erfolgt durch Schulungen, Coaching,
|
||||
Self-Service-Ressourcen und das Key-User-Netzwerk. Klarheit und
|
||||
Orientierung entstehen durch eine gemeinsame Prozess-Sprache über alle
|
||||
Hierarchieebenen.
|
||||
|
||||
- **Für die Gesamtorganisation** schafft die PM-Funktion die Grundlage
|
||||
für Effektivität und kontinuierliche Verbesserung durch methodische
|
||||
Rahmenbedingungen für anpassungsfähige Arbeitsabläufe. Automatisierung
|
||||
und Digitalisierung werden durch systematische Identifikation von
|
||||
Automatisierungspotenzialen vorangetrieben. Siloüberwindung und
|
||||
Integration erfolgen durch transparente End-to-End-Prozesse und
|
||||
einheitliche Standards.
|
||||
|
||||
###
|
||||
|
||||
### **3.3 Cluster C: Wie die PM-Funktion es ermöglicht**
|
||||
|
||||
#### **3.3.1 Schlüsselaktivitäten**
|
||||
|
||||
Die zentralen Tätigkeiten, durch die die PM-Funktion ihr Wertversprechen
|
||||
einlöst. Von Framework-Entwicklung über Beratung bis zur Befähigung --
|
||||
diese Aktivitäten transformieren Ressourcen in konkreten Nutzen. Sie
|
||||
zeigen, womit die PM-Funktion ihre Zeit verbringt und wo Kompetenzen
|
||||
aufgebaut werden müssen:
|
||||
|
||||
- **Framework-Entwicklung & -Pflege** umfasst die kontinuierliche
|
||||
Definition und Weiterentwicklung des verbindlichen PM-Frameworks
|
||||
inklusive Methoden, Standards, Templates und Governance-Regeln. Dies
|
||||
beinhaltet die laufende Analyse interner Bedarfe und externer Best
|
||||
Practices sowie die Entwicklung standardisierter Templates.
|
||||
|
||||
- **Management der Prozesslandschaft & Governance** bedeutet Aufbau,
|
||||
Pflege und Überwachung der Gesamtarchitektur übergreifender Prozesse.
|
||||
Die Sicherstellung der Framework-Compliance und das Aufdecken von
|
||||
Governance-Lücken gehören ebenso dazu wie die Bereitstellung des
|
||||
Prozessregisters.
|
||||
|
||||
- **Tool-Bereitstellung & -Management** beinhaltet Auswahl,
|
||||
Implementierung und kontinuierliche Wartung zentraler PM-Tools. Die
|
||||
technische Verfügbarkeit, Updates und Support werden sichergestellt,
|
||||
neue technologische Möglichkeiten wie KI-gestützte Prozessanalyse
|
||||
integriert.
|
||||
|
||||
- **Beratung & Methodische Unterstützung** erfolgt durch Durchführung
|
||||
von Beratungen, Coachings und Moderation von Workshops zur
|
||||
Prozessanalyse und -optimierung. Der Schwerpunkt liegt auf der
|
||||
Befähigung der Fachbereiche zur eigenständigen Prozessarbeit.
|
||||
|
||||
- **Befähigung & Kompetenzaufbau** umfasst Entwicklung und Umsetzung des
|
||||
Befähigungskonzepts, Qualifizierung und Betreuung des
|
||||
Key-User-Netzwerks sowie Durchführung von Schulungen.
|
||||
|
||||
- **Kommunikation & Stakeholder-Engagement** bedeutet aktive
|
||||
Kommunikation von Framework-Updates und Prozessänderungen, Reporting
|
||||
an Gremien sowie proaktive Information bei identifizierten
|
||||
Governance-Lücken.
|
||||
|
||||
- **Prozessinnovation & -weiterentwicklung** beinhaltet die
|
||||
Identifikation von Optimierungspotenzialen, systematische
|
||||
Identifikation von Automatisierungsmöglichkeiten und Zusammenarbeit
|
||||
mit dem KI-Hub für innovative Lösungsansätze.
|
||||
|
||||
####
|
||||
|
||||
#### **3.3.2 Schlüsselressourcen**
|
||||
|
||||
Das notwendige Fundament für wirksame PM-Arbeit. Dazu gehören
|
||||
menschliche Kompetenzen, intellektuelles Kapital wie Frameworks und
|
||||
Methoden, technische Infrastruktur sowie gewachsene Netzwerke. Diese
|
||||
Ressourcen ermöglichen erst die Durchführung der Schlüsselaktivitäten
|
||||
und müssen kontinuierlich gepflegt und weiterentwickelt werden.
|
||||
|
||||
- **Menschliche Ressourcen** umfassen fachliche und methodische
|
||||
Expertise in Prozessmanagement-Methoden, -Standards und -Governance.
|
||||
Beratungs- und Moderationskompetenz sowie ausreichende personelle
|
||||
Kapazität sind essentiell.
|
||||
|
||||
- **Intellektuelle Ressourcen** bestehen aus dem dokumentierten
|
||||
PM-Framework mit Standards und Methoden, der Prozesslandkarte mit
|
||||
Prozessregister, strukturierten Schulungskonzepten und einer
|
||||
umfassenden Template-Bibliothek.
|
||||
|
||||
- **Physische/Technische Ressourcen** beinhalten zentrale PM-Werkzeuge
|
||||
für Prozessmodellierung und -dokumentation, KI-gestützte
|
||||
Assistenzsysteme zur Prozessanalyse sowie digitale
|
||||
Kollaborationsplattformen.
|
||||
|
||||
- **Beziehungsnetzwerk & Zugänge** umfassen etablierte
|
||||
Governance-Zugänge zu relevanten Entscheidungsgremien, das
|
||||
Key-User-Netzwerk als Community dezentraler Prozessansprechpartner
|
||||
sowie ein organisationsweites Beziehungsnetzwerk von Mitarbeitenden
|
||||
bis zur Führung.
|
||||
|
||||
#### **3.3.3 Schlüsselpartner**
|
||||
|
||||
Die internen Kooperationspartner, mit denen die PM-Funktion
|
||||
zusammenarbeitet, um ihr volles Potenzial zu entfalten. Von
|
||||
IT-Architektur über Datenschutz bis zu Process Ownern -- diese
|
||||
Partnerschaften erweitern die eigenen Möglichkeiten und sichern die
|
||||
Integration in die Gesamtorganisation. Erfolgreiche PM-Arbeit ist immer
|
||||
Teamarbeit über Funktionsgrenzen hinweg.
|
||||
|
||||
- **IT-Architektur** definiert technische Rahmenbedingungen und
|
||||
Standards, die Framework und Werkzeugauswahl beeinflussen.
|
||||
|
||||
- Der **Informationssicherheitsbeauftragte** stellt IT-Sicherheit und
|
||||
technische Compliance von Prozessen sicher.
|
||||
|
||||
- Die **Datenschutzbeauftragte** gewährleistet datenschutzkonforme
|
||||
Prozessgestaltung.
|
||||
|
||||
- **Business Continuity Management** kategorisiert kritische Prozesse
|
||||
und integriert Notfallpläne.
|
||||
|
||||
- **Data Excellence Governance** stimmt datengetriebene Prozesse ab.
|
||||
|
||||
- Der **KI-Hub** fungiert als strategischer Partner für KI-basierte
|
||||
Prozessinnovationen.
|
||||
|
||||
- Das **Vision Board** agiert als strategischer Auftraggeber für die
|
||||
PM-Ausrichtung.
|
||||
|
||||
- **Process Owner** der Teilprozesse -- Stakeholder-Manager, Demand
|
||||
Portfolio Manager, Projekt Portfolio Manager und Service Portfolio
|
||||
Manager -- verantworten ihre jeweiligen Teilprozesse.
|
||||
|
||||
- Das **Qualitätsmanagement** (Status noch zu klären) könnte als Partner
|
||||
zur Abstimmung von QM-Anforderungen und PM-Standards fungieren.
|
||||
|
||||
- **Zentrale GPM (Geschäftsprozess Management):** Ämterübergreifender
|
||||
Prozess-Framework-Verantwortlicher für einheitliche GPM-Standards und
|
||||
-Methoden. Verfügt über die vollständige Prozesslandkarte aller Ämter
|
||||
und koordiniert die strategische Weiterentwicklung des
|
||||
Geschäftsprozessmanagements.
|
||||
|
||||
## **4. Das Gesamtbild: Zusammenhänge erkennen**
|
||||
|
||||
Das Leistungs-Canvas macht sichtbar, wie die verschiedenen Elemente der
|
||||
PM-Funktion ineinandergreifen. Die Nutzer:innen mit ihren spezifischen
|
||||
Bedarfen stehen am Ausgangspunkt. Das Wertversprechen übersetzt diese
|
||||
Bedarfe in konkrete Leistungszusagen. Die Kanäle definieren, wie diese
|
||||
Leistungen zugänglich werden. Die Beziehungsgestaltung prägt die Art der
|
||||
Zusammenarbeit.
|
||||
|
||||
Auf der Umsetzungsseite zeigen die Schlüsselaktivitäten, wie das
|
||||
Wertversprechen eingelöst wird. Die Schlüsselressourcen bilden das
|
||||
notwendige Fundament. Die Schlüsselpartner erweitern die eigenen
|
||||
Möglichkeiten durch Kooperation.
|
||||
|
||||
Diese systemische Betrachtung offenbart Wechselwirkungen: Das
|
||||
Key-User-Netzwerk beispielsweise ist gleichzeitig Kanal (für dezentrale
|
||||
Unterstützung), Beziehungselement (Community Building) und Ressource
|
||||
(Multiplikator:innen). Die Framework-Entwicklung ist Schlüsselaktivität,
|
||||
deren Ergebnis als intellektuelle Ressource wiederum neue Aktivitäten
|
||||
ermöglicht.
|
||||
|
||||
## **5. Praktische Lesehilfen**
|
||||
|
||||
Die verschiedenen Nutzergruppen finden sich im Canvas an
|
||||
unterschiedlichen Stellen wieder:
|
||||
|
||||
- **Gremien** sollten besonders auf das strategische Wertversprechen,
|
||||
die Governance-basierten Beziehungen und die formellen Berichtskanäle
|
||||
achten. Für sie sind die übergreifenden Schlüsselaktivitäten wie
|
||||
Framework-Entwicklung und Prozesslandschafts-Management besonders
|
||||
relevant.
|
||||
|
||||
- **Fachbereiche und Teams** finden ihren Nutzen primär im operativen
|
||||
Wertversprechen, den befähigungsorientierten Beziehungen und den
|
||||
vielfältigen Zugangskanälen von persönlicher Beratung bis
|
||||
Self-Service. Die Aktivitäten Beratung, Befähigung und
|
||||
Tool-Bereitstellung adressieren ihre Bedarfe direkt.
|
||||
|
||||
- **Key-User** sind im Canvas mehrfach verortet: als Teil der
|
||||
Nutzendensegmente, als Element der Community-Beziehungen, als
|
||||
wichtiger Kanal und als Schlüsselressource. Diese Mehrfachrolle
|
||||
unterstreicht ihre zentrale Bedeutung im Gesamtkonzept.
|
||||
|
||||
## **6. Verbindung zu anderen Konzeptbausteinen**
|
||||
|
||||
Das Leistungs-Canvas steht nicht isoliert, sondern ist Teil eines
|
||||
integrierten Konzepts zur PM-Funktion:
|
||||
|
||||
- Die **Funktionsbeschreibung** definiert die formalen
|
||||
Verantwortlichkeiten, die den hier dargestellten Leistungen zugrunde
|
||||
liegen.
|
||||
|
||||
- Das **Governance-Modell** konkretisiert die Entscheidungswege und
|
||||
Beauftragungslogiken, die in den Kanälen und Beziehungen angedeutet
|
||||
werden.
|
||||
|
||||
- Das **Rollenmodell** spezifiziert, wer innerhalb der PM-Funktion für
|
||||
welche Elemente des Canvas verantwortlich ist.
|
||||
|
||||
- Die **RACI-Matrix** operationalisiert die Zusammenarbeit mit den
|
||||
Schlüsselpartnern.
|
||||
|
||||
Gemeinsam bilden diese Dokumente ein kohärentes Gesamtbild der
|
||||
Prozess-Management-Funktion im DIGIT -- aus verschiedenen, sich
|
||||
ergänzenden Perspektiven.
|
||||
724
#05_prozessmanagement/docs/pm_rollenmodell.md
Normal file
724
#05_prozessmanagement/docs/pm_rollenmodell.md
Normal file
|
|
@ -0,0 +1,724 @@
|
|||
# **Prozess-Management: Rollenmodell**
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
## **1. Strategische Architektur-Prinzipien**
|
||||
|
||||
Das Prozess-Management im DIGITOM operiert als **Enabling-Funktion** mit
|
||||
klarer Trennung zwischen **methodischer Beratung** und **operativer
|
||||
PM-Governance**. Die Rollen-Architektur folgt dem Prinzip der
|
||||
**dezentralen Befähigung** bei **zentraler Methodenkompetenz**.
|
||||
|
||||
**Auflösung des Beratung-vs.-Governance-Konflikts:** Methodische
|
||||
Unterstützung und PM-Compliance-Überwachung werden auf unterschiedliche
|
||||
Rollen verteilt, um Vertrauen und Effektivität zu gewährleisten.
|
||||
|
||||
Hinweis: Die bewusste Differenzierung in 8 Kernrollen ermöglicht klare
|
||||
Verantwortungsschnitte und vermeidet Interessenskonflikte (z.B. zwischen
|
||||
PM-Governance-Überwachung und PM-Framework-Gestaltung).
|
||||
|
||||
## **2. Begriffsdefinition: End-to-End Verantwortung**
|
||||
|
||||
Im DIGITOM-Kontext bedeutet **\"End-to-End Verantwortung\"** die
|
||||
vollständige Verantwortung für einen definierten Prozessabschnitt über
|
||||
alle beteiligten Funktionen und Abteilungen hinweg.
|
||||
|
||||
Wichtige Abgrenzungen:
|
||||
|
||||
- End-to-End bezieht sich auf **Teilprozesse**, nicht auf den
|
||||
Gesamtprozess (bspw. der Teilprozess \"Demand to Project")
|
||||
|
||||
- Der Process Owner trägt die Verantwortung **innerhalb seiner
|
||||
Prozessebene**, sowie für die **aktive Gestaltung der Schnittstellen**
|
||||
zu vor- und nachgelagerten Prozessen
|
||||
|
||||
- Die Verantwortung umfasst: Performance und Qualität des eigenen
|
||||
Teilprozesses
|
||||
|
||||
- **Schnittstellen-Vereinbarungen** mit angrenzenden Process Ownern
|
||||
|
||||
- **Eskalation** bei Problemen in verbundenen Prozessen, die das eigene
|
||||
Prozessergebnis gefährden
|
||||
|
||||
- Kontinuierliche Optimierung inkl. schnittstellenübergreifender
|
||||
Verbesserungen. Diese Definition ist essentiell für das Verständnis
|
||||
der nachfolgenden Rollenbeschreibungen, insbesondere der Process
|
||||
Owner-Rollen.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **3. Kernrollen (Interne PM-Organisation)**
|
||||
|
||||
### **Rolle 1: Leiter\*in Prozess-Management**
|
||||
|
||||
**Hauptzweck:** Strategische Führung und operative Steuerung der
|
||||
gesamten PM-Funktion zur Sicherstellung der Wertschöpfung für DIGITOM
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Strategische Ausrichtung der PM-Funktion an DIGIT-Zielen und
|
||||
organisationalen Bedarfen
|
||||
|
||||
- Strategische Vorschläge zur Weiterentwicklung des DIGITOMs aus
|
||||
Prozess-Management-Perspektive (z.B. neue Funktionen,
|
||||
Rollenanpassungen, Governance-Strukturen)
|
||||
|
||||
- Koordination und Priorisierung der internen PM-Rollen (PFM, PLK, PB,
|
||||
KNM)
|
||||
|
||||
- Stakeholder-Management zu Gremien und Fachbereichen/ Abteilungen
|
||||
|
||||
- Ressourcenplanung, Budgetverantwortung und Kapazitätssteuerung der
|
||||
PM-Funktion
|
||||
|
||||
- Eskalationsmanagement bei strategischen Konflikten oder
|
||||
Ressourcenengpässen
|
||||
|
||||
- Im Fall von Ressourcen-Konflikten: Erstbewertung und Empfehlung, bei
|
||||
kritischen Fällen Eskalation ans Mission Board
|
||||
|
||||
- Berichterstattung an Vision Board über PM-Performance und strategische
|
||||
Entwicklungen
|
||||
|
||||
- **Stakeholder:**
|
||||
|
||||
<!-- -->
|
||||
|
||||
- Vision Board (Auftraggeber und strategische Abstimmung=
|
||||
|
||||
- Mission Board (taktische Abstimmung)
|
||||
|
||||
- Interne PM-Rollen (Führung und Koordination)
|
||||
|
||||
- Abteilungsleitungen (strategische PM-Partnerschaften)
|
||||
|
||||
- Amtsleitung DIGIT (organisatorische Einbindung)
|
||||
|
||||
- Externe Berater und Dienstleister (strategische Partnerschaften)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Priorisierung von PM-Aufträgen bei Ressourcenkonflikten (bei
|
||||
kritischen Entscheidungen in Konsultation mit Mission Board)
|
||||
|
||||
- Personalentscheidungen für PM-Team (Einstellung, Entwicklung,
|
||||
Zielsetzung)
|
||||
|
||||
- Budget-Allokation für PM-Tools, Schulungen und externe Unterstützung
|
||||
|
||||
- Eskalation an Mission Board bei konkurrierenden Prioritäten
|
||||
|
||||
- PM-Framework-Freigaben nach PFM-Vorschlägen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Führungskompetenz für interdisziplinäre Teams mit verschiedenen
|
||||
Expertisen
|
||||
|
||||
- Strategisches Stakeholder-Management und politische Sensibilität in
|
||||
der Verwaltung
|
||||
|
||||
- Verständnis für das DIGITOM und das PM-Framework sowie organisationale
|
||||
Transformationen
|
||||
|
||||
- Konfliktmanagement bei konkurrierenden Prioritäten in verschiedenen
|
||||
Fachbereiche/ Abteilungen
|
||||
|
||||
- Change Management für komplexe organisatorische Veränderungen
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### **Rolle 2: Prozess-Framework-Manager\*in (PFM)**
|
||||
|
||||
**Hauptzweck:** Entwicklung und Pflege eines einheitlichen,
|
||||
zukunftsfähigen PM-Frameworks, das DIGITOM-weit als methodische
|
||||
Grundlage für qualitativ hochwertige Prozessarbeit dient
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Konzeption, Dokumentation und kontinuierliche Weiterentwicklung des
|
||||
verbindlichen PM-Frameworks (Standards, Methoden, Tools,
|
||||
Governance-Regeln)
|
||||
|
||||
- Entwicklung und Pflege eines zentralen KPI-Frameworks mit
|
||||
standardisierten Messkategorien, Berechnungsmethoden und
|
||||
Reporting-Standards
|
||||
|
||||
- Analyse externer Best Practices, Standards und gesetzlicher
|
||||
Anforderungen für Integration ins PM-Framework
|
||||
|
||||
- PM-Framework-Kommunikation und Change Management bei größeren
|
||||
Methodenänderungen
|
||||
|
||||
- Qualitätssicherung des PM-Frameworks durch systematisches
|
||||
Feedback-Management
|
||||
|
||||
- Entwicklung von PM-Framework-Schulungskonzepten und
|
||||
Zertifizierungsstandards
|
||||
|
||||
- Vorschläge zur Weiterentwicklung des DIGITOMs aus
|
||||
Prozess-Management-Sicht
|
||||
|
||||
- Harmonisierung des PM-Frameworks mit dem Service Management Framework
|
||||
|
||||
- Identifikation geeigneter Methoden und technischer Ansätze zur
|
||||
Digitalisierung und (Teil-)Automatisierung von Prozessen im Einklang
|
||||
mit dem PM-Framework und der Gesamtstrategie
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- Leiterin Prozess-Management (strategische Abstimmung und Freigaben)
|
||||
|
||||
- Alle internen PM-Rollen (Framework-Anwendung und Feedback)
|
||||
|
||||
- IT-Architektur (technische Machbarkeit und Systemintegration)
|
||||
|
||||
- ISB/Datenschutz (Compliance-Anforderungen)
|
||||
|
||||
- Process Owner (Framework-Implementierung in spezifischen Prozessen)
|
||||
|
||||
- Externe Standards-Organisationen und Beratungsunternehmen
|
||||
|
||||
- Zentrales GPM (HPA)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- PM-Framework-Design-Entscheidungen im Rahmen strategischer Vorgaben
|
||||
|
||||
- Tool-Evaluierung und Empfehlungen für Investitionsentscheidungen
|
||||
|
||||
- Methodische Standards für einheitliche Prozessarbeit in DIGITOM
|
||||
|
||||
- PM-Framework-Update-Prioritäten basierend auf organisationalen
|
||||
Bedarfen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Expertise in Prozessmanagement-Methoden (BPM, Lean, Six Sigma, Design
|
||||
Thinking)
|
||||
|
||||
- Technisches Verständnis für digitale Prozess-Tools und
|
||||
Plattform-Architekturen
|
||||
|
||||
- Systemisches Denken für komplexe organisatorische Zusammenhänge
|
||||
|
||||
- Didaktische Fähigkeiten für Framework-Kommunikation und
|
||||
Wissensvermittlung
|
||||
|
||||
- Analytische Fähigkeiten für Technologie-Assessment und
|
||||
Standards-Evaluierung
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 3: Prozesslandschafts-Koordinator\*in (PLK)**
|
||||
|
||||
**Hauptzweck:** Operative Governance und Transparenz der
|
||||
DIGITOM-Prozesslandschaft zur Sicherstellung von Framework-Compliance
|
||||
und End-to-End-Prozessqualität
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Aufbau, Pflege und kontinuierliche Aktualisierung des zentralen
|
||||
Prozessregisters
|
||||
|
||||
- Monitoring von Framework-Compliance und Identifikation von
|
||||
PM-Governance-Lücken
|
||||
|
||||
- Koordination prozessübergreifender-Initiativen zwischen verschiedenen
|
||||
Process Owner
|
||||
|
||||
- PM-Governance-Reporting für Gremien mit Prozess-KPIs und
|
||||
Compliance-Status
|
||||
|
||||
- Eskalationsmanagement bei Prozess-Konflikten zwischen Abteilungen
|
||||
|
||||
- Risiko-Assessment für Prozesslandschaft und frühzeitige
|
||||
Problemerkennung
|
||||
|
||||
- Schnittstellen-Governance: Moderation von
|
||||
Schnittstellen-Vereinbarungen zwischen Process Ownern und
|
||||
Konfliktlösung bei schnittstellenübergreifenden Problemen
|
||||
|
||||
- PM-Governance-Lücken-Management**:**
|
||||
|
||||
- Systematische Identifikation von PM-Governance-Lücken im DIGIT/
|
||||
DIGITOM
|
||||
|
||||
- Abstimmung mit Prozessberater:innen für Lösungsansätze
|
||||
|
||||
- Bei kurzfristiger Lösung: Dokumentation und Monitoring
|
||||
|
||||
- Bei langfristigem Bedarf: Strukturierte Eskalation über LPM ans
|
||||
Mission Board
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- Process Owner (SHM, DPM, PPM, SPM) für End-to-End-Prozess-Koordination
|
||||
|
||||
- Leiterin Prozess-Management (Governance-Reporting und Eskalationen)
|
||||
|
||||
- Mission Board (taktische Governance-Entscheidungen)
|
||||
|
||||
- Fachbereiche/ Abteilungen (Compliance-Unterstützung und
|
||||
Konfliktlösung)
|
||||
|
||||
- IT-Architektur (systemische Prozess-Dependencies)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Governance-Compliance-Bewertungen und Abweichungsmanagement
|
||||
|
||||
- Prozessregister-Updates und Dokumentationsstandards
|
||||
|
||||
- Eskalations-Empfehlungen bei systematischen Governance-Problemen
|
||||
|
||||
- Priorisierung von prozessübergreifenden Optimierungsmaßnahmen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Prozessanalyse-Expertise für komplexe, vernetzte Prozesslandschaften
|
||||
|
||||
- Governance-Kompetenz mit Verständnis für Compliance und
|
||||
Risikomanagement
|
||||
|
||||
- Diplomatische Fähigkeiten für Konfliktmediation zwischen
|
||||
Fachbereichen/ Abteilungen
|
||||
|
||||
- Analytische Fähigkeiten für KPI-Entwicklung und
|
||||
Performance-Measurement
|
||||
|
||||
- Kommunikationsstärke für verständliches Governance-Reporting
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 4: Prozess-Berater\*in (PB)**
|
||||
|
||||
**Hauptzweck:** Direkte, vertrauensvolle methodische Unterstützung der
|
||||
Fachbereiche/ Abteilungen bei Prozessanalyse, -gestaltung und
|
||||
-optimierung zur Befähigung für eigenständige Prozessarbeit
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Individuelle Beratung und Coaching von Fachbereichen/ Abteilungen bei
|
||||
konkreten Prozess-Herausforderungen
|
||||
|
||||
- Moderation von Prozess-Workshops für kollaborative Analyse und
|
||||
Optimierung in definierten Fällen
|
||||
|
||||
- Methodische Unterstützung bei Prozessmodellierung und -dokumentation
|
||||
|
||||
- Troubleshooting bei operativen Prozess-Problemen und Konflikten (inkl.
|
||||
Erstbewertung von Anfragen über das Ticketsystem)
|
||||
|
||||
- Identifikation von Optimierungspotenzialen durch Prozess-Assessments
|
||||
|
||||
- Begleitende Umsetzungsunterstützung bei Prozessänderungen
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- Fachbereiche/ Abteilungen und deren Teams (direkte Beratung und
|
||||
Coaching)
|
||||
|
||||
- Key-User (operative Zusammenarbeit und Befähigung)
|
||||
|
||||
- Projektteams (prozessbezogene Projektunterstützung)
|
||||
|
||||
- Auftraggeber PM (Bedarfsklärung und Erwartungsmanagement)
|
||||
|
||||
- Process Owner (methodische Unterstützung bei End-to-End-Optimierungen)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Methodische Empfehlungen im Rahmen des gültigen Frameworks
|
||||
|
||||
- Workshop-Design und Moderations-Ansätze für spezifische Situationen
|
||||
|
||||
- Beratungs-Priorisierung bei mehreren gleichzeitigen Anfragen
|
||||
|
||||
- Eskalations-Empfehlungen bei komplexen oder ressourcenintensiven
|
||||
Problemen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Prozessberatungs-Expertise mit breitem Methoden-Portfolio
|
||||
|
||||
- Workshop-Moderation und Facilitierung für diverse
|
||||
Stakeholder-Konstellationen
|
||||
|
||||
- Change Management-Fähigkeiten für begleitende Prozessveränderungen
|
||||
|
||||
- Empathie und Beziehungsaufbau für vertrauensvolle
|
||||
Beratungspartnerschaften
|
||||
|
||||
- Problemlösungs-Kompetenz für komplexe organisatorische
|
||||
Herausforderungen
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 5: Key-User-Netzwerk-Manager\*in (KNM)**
|
||||
|
||||
**Hauptzweck:** Systematischer Aufbau und Betreuung eines dezentralen
|
||||
Netzwerks von Prozess-Champions zur Skalierung der PM-Kompetenz in die
|
||||
gesamte DIGITOM-Organisation
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Identifikation, Rekrutierung und Onboarding geeigneter Key-User in
|
||||
allen Abteilungen
|
||||
|
||||
- Entwicklung und Durchführung strukturierter Qualifizierungsprogramme
|
||||
für Key-User
|
||||
|
||||
- Community-Management durch regelmäßige Netzwerk-Events und
|
||||
Erfahrungsaustausch
|
||||
|
||||
- Aufbau und Pflege der zentralen Wissensplattform mit
|
||||
Self-Service-Ressourcen
|
||||
|
||||
- Best-Practice-Transfer zwischen Abteilungen durch das
|
||||
Key-User-Netzwerk
|
||||
|
||||
- Performance-Management des Key-User-Netzwerks und kontinuierliche
|
||||
Weiterentwicklung
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- Key-User in allen Fachbereichen/ Abteilungen (direkte Betreuung und
|
||||
Entwicklung)
|
||||
|
||||
- Fachbereichsleitungen (Key-User-Nominierung und Freistellung)
|
||||
|
||||
- Prozess-Berater:innen (operative Zusammenarbeit bei
|
||||
Fachbereichs-Support)
|
||||
|
||||
- IT-Abteilung (Wissensplattform-Entwicklung und -betrieb)
|
||||
|
||||
- Personalentwicklung (Qualifizierungskoordination)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Key-User-Qualifizierungskonzepte und Schulungsprogramm-Design
|
||||
|
||||
- Community-Event-Planung und Ressourcen-Allokation
|
||||
|
||||
- Wissensplattform-Inhalte und Self-Service-Ressourcen-Priorisierung
|
||||
|
||||
- Key-User-Performance-Bewertung und Entwicklungsempfehlungen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Community-Building und Netzwerk-Management für diverse
|
||||
organisatorische Kontexte
|
||||
|
||||
- Didaktische Expertise für Erwachsenenbildung und Kompetenzentwicklung
|
||||
|
||||
- Content-Management für digitale Wissensplattformen
|
||||
|
||||
- Motivations- und Engagement-Management für freiwillige Communities
|
||||
|
||||
- Train-the-Trainer-Fähigkeiten für Multiplikator-Entwicklung
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **4. Schnittstellenrollen**
|
||||
|
||||
### **Rolle 6: Process Owner**
|
||||
|
||||
*Übernommen von: Stakeholder-Manager (SHM), Demand Portfolio Manager
|
||||
(DPM), Projekt Portfolio Manager (PPM), Service Portfolio Manager
|
||||
(SPM)r*
|
||||
|
||||
**Hauptzweck:** End-to-End-Verantwortung für spezifische
|
||||
Teilprozess-Prozesse zur Sicherstellung von Prozess-Performance,
|
||||
Qualität und kontinuierlicher Optimierung
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Strategische Verantwortung für Performance und Qualität der
|
||||
zugeordneten End-to-End-Prozesse
|
||||
|
||||
- Definition prozessspezifischer KPIs auf Basis zentral vorgegebener
|
||||
KPI-Kategorien Standards, Monitoring der Prozess-Performance in
|
||||
Abstimmung mit organisationalen Zielen
|
||||
|
||||
- Monitoring der Prozess-KPIs in Abstimmung mit organisationalen Zielen
|
||||
|
||||
- Koordination prozessbezogener Optimierungsinitiativen zwischen
|
||||
beteiligten Bereichen
|
||||
|
||||
- Eskalationsmanagement bei prozessrelevanten Problemen oder
|
||||
Ressourcenkonflikten
|
||||
|
||||
- Abstimmung mit PM-Funktion bei PM-Framework-Updates oder methodischen
|
||||
Änderungen
|
||||
|
||||
- Sicherstellung der Framework-Compliance in den verantworteten
|
||||
Prozessen
|
||||
|
||||
**Spezifische Process Owner-Zuordnung:**
|
||||
|
||||
- **SHM:** \"Bedarfserfassung und -qualifizierung\"
|
||||
|
||||
- **DPM:** \"Demand-Bewertung und Demand-Portfolio-Steuerungt\"
|
||||
|
||||
- **PPM:** \"Projektsteuerung und -überwachung\"
|
||||
|
||||
- **SPM:** \"Service-Integration und Betriebsüberführung\"
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- PM-Funktion (methodische Unterstützung und Framework-Compliance)
|
||||
|
||||
- Beteiligte Fachbereiche/ Abteilungen im jeweiligen End-to-End-Prozess
|
||||
|
||||
- Mission Board (Performance-Reporting und strategische Abstimmung)
|
||||
|
||||
- Key-User in den prozessrelevanten Bereichen
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Prozess-Design-Entscheidungen im Rahmen des gültigen PM-Frameworks
|
||||
|
||||
- Ressourcen-Anfrage/Priorisierung für prozessbezogene
|
||||
Optimierungsmaßnahmen
|
||||
|
||||
- Eskalations-Entscheidungen bei prozessübergreifenden Konflikten
|
||||
|
||||
- KPI-Definition und Performance-Ziele für die verantworteten Prozesse
|
||||
|
||||
- Abnahme-Entscheidungen für Prozessänderungen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- End-to-End-Prozess-Verständnis mit systemischer Sichtweise
|
||||
|
||||
- Performance-Management mit KPI-Entwicklung und -monitoring
|
||||
|
||||
- Cross-funktionale Koordination zwischen verschiedenen Bereichen
|
||||
|
||||
- Prozessoptimierungs-Kompetenz mit methodischem Grundverständnis
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 7: Key-User**
|
||||
|
||||
*Formale Rolle in den Fachbereichen/ Abteilungen*
|
||||
|
||||
**Hauptzweck:** Dezentrale PM-Kompetenz und Change-Agenten in den
|
||||
Fachbereichen/ Abteilungen zur lokalen Prozessexpertise und
|
||||
Schnittstelle zur zentralen PM-Funktion
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Erste Anlaufstelle für prozessbezogene Fragen und Herausforderungen im
|
||||
eigenen Fachbereich/ Abteilung
|
||||
|
||||
- Lokale Prozessexpertise und Unterstützung der Kollegen bei
|
||||
Prozessarbeit
|
||||
|
||||
- Schnittstelle zwischen Fachbereiche/ Abteilungen und zentraler
|
||||
PM-Funktion
|
||||
|
||||
- Modellierung spezifischer (Fach-) Prozesse
|
||||
|
||||
- Implementierung von Framework-Updates und Prozessänderungen im
|
||||
Fachbereich
|
||||
|
||||
- Identifikation lokaler Optimierungspotenziale und Weiterleitung an
|
||||
PM-Funktion
|
||||
|
||||
- Multiplikator für Prozess-Know-how und Best Practices
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- Kolleg:innen im eigenen Fachbereich/Abteilung (direkte Unterstützung)
|
||||
|
||||
- Key-User-Netzwerk-Manager:in (Qualifizierung und Community)
|
||||
|
||||
- Prozess-Berater:innen (bei komplexeren Herausforderungen)
|
||||
|
||||
- Fachbereichs-/ Abteilungsleitung (lokale PM-Vertretung)
|
||||
|
||||
- Andere Key-User (Erfahrungsaustausch und Peer-Learning)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Erste Bewertung und Priorisierung lokaler Prozess-Anfragen
|
||||
|
||||
- Methodische Empfehlungen für Standardsituationen im Rahmen des
|
||||
Frameworks
|
||||
|
||||
- Weiterleitung komplexerer Fälle an zentrale PM-Funktion
|
||||
|
||||
- Lokale Prozess-Dokumentations-Updates in Abstimmung mit Process Owner
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Fundierte Kenntnisse des PM-Frameworks und Standard-Methoden
|
||||
|
||||
- Beratungs- und Unterstützungskompetenz für Kolleg:innen
|
||||
|
||||
- Fachbereichs-spezifisches Prozess-Know-how
|
||||
|
||||
- Netzwerk- und Community-Fähigkeiten
|
||||
|
||||
- Change-Agent-Qualitäten für lokale Prozessverbesserungen
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 8: Auftraggeber Prozess-Management**
|
||||
|
||||
*Verschiedene organisatorische Ausprägungen*
|
||||
|
||||
**Hauptzweck:** Bedarfs-Artikulation und Beauftragung der PM-Funktion
|
||||
zur zielgerichteten Nutzung der PM-Services für spezifische
|
||||
organisatorische Herausforderungen
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Identifikation und Artikulation von Prozess-Management-Bedarfen
|
||||
|
||||
- Formale Beauftragung der PM-Funktion mit spezifischen Aufgaben oder
|
||||
Projekten
|
||||
|
||||
- Bereitstellung notwendiger Ressourcen und Informationen für
|
||||
PM-Services
|
||||
|
||||
- Definition von Erfolgserwartungen und Zielen für PM-Unterstützung
|
||||
|
||||
- Feedback und Bewertung der erbrachten PM-Leistungen
|
||||
|
||||
- Sicherstellung der Implementierung von PM-Empfehlungen
|
||||
|
||||
**Auftraggeber-Kategorien:**
|
||||
|
||||
- **Abteilungsleitung:** Bereichsspezifische Prozessoptimierungen
|
||||
|
||||
- **Projektleitungen:** Projektbezogene Prozess-Unterstützung
|
||||
|
||||
- **Vision Board/ Mission Board:** Strategische PM-Initiativen
|
||||
|
||||
- **Service-(Portfolio)-Manager:** Servicebezogene Prozessentwicklung
|
||||
|
||||
**Stakeholder:**
|
||||
|
||||
- PM-Funktion (Beauftragung und Zusammenarbeit)
|
||||
|
||||
- Betroffene Teams und Bereiche (Implementierung)
|
||||
|
||||
- Übergeordnete Gremien (bei strategischen Aufträgen)
|
||||
|
||||
**Entscheidungsbefugnisse:**
|
||||
|
||||
- Beauftragung und Priorisierung von PM-Services im eigenen
|
||||
Verantwortungsbereich
|
||||
|
||||
- Ressourcen-Bereitstellung für beauftragte PM-Aktivitäten
|
||||
|
||||
- Freigabe und Implementierungs-Entscheidungen für PM-Empfehlungen
|
||||
|
||||
**Kompetenzen:**
|
||||
|
||||
- Bedarfs-Analyse und Ziel-Definition für Prozessoptimierungen
|
||||
|
||||
- Stakeholder-Management für Implementierungsmaßnahmen
|
||||
|
||||
- Change-Management-Grundverständnis
|
||||
|
||||
- Budget- und Ressourcen-Verantwortung
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
##
|
||||
|
||||
## **5. Governance- und Support-Rollen**
|
||||
|
||||
### **Rolle 9: IT-Architektur (Technische Schnittstelle)**
|
||||
|
||||
**Hauptzweck:** Sicherstellung der technischen Machbarkeit und
|
||||
Integration von Prozess-Lösungen in die DIGITOM-IT-Landschaft
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Bewertung technischer Anforderungen aus Prozess-Design-Entscheidungen
|
||||
|
||||
- Definition technischer Rahmenbedingungen für Prozess-Tools und
|
||||
-systeme
|
||||
|
||||
- Sicherstellung der Systemkompatibilität bei prozessbezogenen
|
||||
IT-Lösungen
|
||||
|
||||
- Beratung zu technischen Möglichkeiten und Grenzen bei
|
||||
Prozessoptimierungen
|
||||
|
||||
**Stakeholder:** PM-Funktion, Process Owner, IT-Betrieb
|
||||
|
||||
**Entscheidungsbefugnisse:** Technische Architektur-Vorgaben,
|
||||
System-Kompatibilitäts-Bewertungen
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
### **Rolle 10: Informationssicherheitsbeauftragte:r / Datenschutzbeauftragte:r**
|
||||
|
||||
**Hauptzweck:** Sicherstellung der Compliance von Prozessen und PM-Tools
|
||||
mit Sicherheits- und Datenschutzvorgaben
|
||||
|
||||
**Kernaufgaben:**
|
||||
|
||||
- Compliance-Prüfung von Prozess-Designs und PM-Tools
|
||||
|
||||
- Definition sicherheitsrelevanter Prozess-Anforderungen
|
||||
|
||||
- Risiko-Assessment für prozessbezogene Datenverarbeitung
|
||||
|
||||
**Stakeholder:** PM-Funktion, Process Owner, Fachbereiche/ Abteilungen
|
||||
|
||||
**Entscheidungsbefugnisse:** Compliance-Freigaben,
|
||||
Sicherheitsanforderungen
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
###
|
||||
|
||||
### **Rolle 11: Gremien (Vision Board, Mission Board, DSR)**
|
||||
|
||||
**Hauptzweck:** Strategische und taktische Steuerung der PM-Funktion
|
||||
sowie Entscheidungen zu prozessrelevanten Governance-Fragen
|
||||
|
||||
**Vision Board:**
|
||||
|
||||
- Strategische PM-Ausrichtung und Framework-Grundsätze
|
||||
|
||||
- Budget- und Ressourcen-Entscheidungen für PM-Funktion
|
||||
|
||||
**Mission Board:**
|
||||
|
||||
- Taktische PM-Priorisierung und Konfliktlösung
|
||||
|
||||
- Prozessübergreifende Optimierungsentscheidungen
|
||||
|
||||
**DSR (Digital Services Review):**
|
||||
|
||||
- Operative Prozess-Entscheidungen im Kontext des Service-Portfolios
|
||||
|
||||
------------------------------------------------------------------------
|
||||
199
#05_prozessmanagement/docs/pm_uebersicht.md
Normal file
199
#05_prozessmanagement/docs/pm_uebersicht.md
Normal file
|
|
@ -0,0 +1,199 @@
|
|||
# **Prozess-Management: Executive Summary**
|
||||
|
||||
# **1. Strategischer Kontext und Kernkonzept**
|
||||
|
||||
### **1.1 Die organisationale Herausforderung**
|
||||
|
||||
Das DIGITOM steht vor einem typischen Widerspruch in modernen
|
||||
Verwaltungen: Es braucht einheitliche Standards für Effektivität und
|
||||
Vergleichbarkeit -- gleichzeitig müssen Fachbereiche flexibel auf ihre
|
||||
spezifischen Anforderungen reagieren können. Die bisherige
|
||||
Prozesslandschaft spiegelt dieses Dilemma wider: fragmentierte Abläufe,
|
||||
methodische Vielfalt ohne gemeinsame Basis, Silos statt Integration.
|
||||
|
||||
Diese Ausgangslage erzeugt operative Reibungsverluste und verhindert
|
||||
strategische Weiterentwicklung. Digitalisierungs- und
|
||||
Automatisierungspotenziale bleiben ungenutzt, weil es an einem
|
||||
strukturierten Überblick und den notwendigen Befähigungen fehlt.
|
||||
Optimierungen verpuffen lokal, statt systemisch zu wirken.
|
||||
|
||||
### **1.2 Das Lösungskonzept: Ein neuer Weg zwischen Kontrolle und Autonomie**
|
||||
|
||||
Die neue Prozess-Management-Funktion navigiert zwischen Standardisierung
|
||||
und Flexibilität. Statt diesen Widerspruch aufzulösen, nutzt sie ihn
|
||||
produktiv:
|
||||
|
||||
- **Zentrale Methodenkompetenz und Rahmenverantwortung** trifft auf
|
||||
**dezentrale Umsetzungsverantwortung**. Die PM-Funktion definiert den
|
||||
Rahmen durch einheitliche Standards, Methoden und Werkzeuge. Innerhalb
|
||||
dieses Rahmens gestalten die Fachbereiche ihre Prozesse aktiv und
|
||||
tragen somit die Verantwortung dafür.
|
||||
|
||||
- **Befähigung statt Kontrolle** prägt die Arbeitsweise. Die Funktion
|
||||
versteht sich als Ermöglicher, nicht als Wächter. Sie schafft
|
||||
Kompetenzen vor Ort durch ein Netzwerk von "Key-User", die als
|
||||
Multiplikator:innen in ihren Bereichen wirken.
|
||||
|
||||
- **Nutzenorientierung statt Strukturfixierung** leitet das Design
|
||||
dieser Funktion. Ausgangspunkt sind nicht interne Logiken, sondern die
|
||||
Bedarfe der internen Kund:innen -- von strategischen Gremien bis zu
|
||||
operativen Teams.
|
||||
|
||||
###
|
||||
|
||||
###
|
||||
|
||||
### **1.3 Der erwartete Mehrwert**
|
||||
|
||||
- Für **strategische Entscheider:innen** entsteht erstmals Transparenz
|
||||
über die gesamte Prozesslandschaft. Strategische Gestaltung wird
|
||||
ermöglicht, Risiken werden frühzeitig sichtbar sowie Digitalisierungs-
|
||||
und Automatisierungspotenziale systematisch erschlossen.
|
||||
|
||||
- **Operative Teams** erhalten methodische Unterstützung genau dann,
|
||||
wenn sie sie brauchen -- von der schnellen Beratung bis zur Begleitung
|
||||
komplexer Transformationen. Einheitliche Standards erleichtern die
|
||||
bereichsübergreifende Zusammenarbeit.
|
||||
|
||||
- Die **Gesamtorganisation** gewinnt an Anpassungsfähigkeit ohne
|
||||
Kontrollverlust. Prozesse werden nicht nur dokumentiert, sondern
|
||||
kontinuierlich verbessert. Die systematische Identifikation von
|
||||
Digitalisierungs- Automatisierungspotenzialen adressiert direkt die
|
||||
Herausforderungen von Fachkräftemangel und steigenden Anforderungen.
|
||||
|
||||
##
|
||||
|
||||
## **2. Organisationsdesign und Governance**
|
||||
|
||||
### **2.1 Eine Architektur der produktiven Spannung**
|
||||
|
||||
Das Organisationsdesign folgt dem Prinzip der bewussten Rollentrennung.
|
||||
Methodische Beratung und operative Governance liegen in
|
||||
unterschiedlichen Händen -- so entsteht Vertrauen statt Kontrollangst.
|
||||
|
||||
- **Fünf zentrale Rollen** im PM-Team decken das Spektrum von
|
||||
strategischer Führung über Methodenentwicklung bis zur operativen
|
||||
Beratung ab. Jede Rolle hat klare Verantwortlichkeiten,
|
||||
Überschneidungen werden vermieden:
|
||||
|
||||
- Leiter\*in Prozess-Management
|
||||
|
||||
- Prozess-Framework-Manager\*in (PFM)
|
||||
|
||||
- Prozesslandschafts-Koordinator\*in (PLK)
|
||||
|
||||
- Prozess-Berater\*in (PB)
|
||||
|
||||
- Key-User-Netzwerk-Manager\*in (KNM)
|
||||
|
||||
- **Process Owner** in den Hauptprozessen (Stakeholder-, Demand-,
|
||||
Projekt- und Service-Management) tragen horizontale und vertikale
|
||||
End-to-End-Verantwortung für ihre Teilprozesse. Sie koordinieren
|
||||
bereichsübergreifend und sichern Prozessqualität.
|
||||
|
||||
- **Key-User** werden in allen Fachbereichen identifiziert und zu
|
||||
lokalen Prozess-Expert:innen entwickelt. Sie sind erste Anlaufstelle
|
||||
vor Ort und Bindeglied zur zentralen PM-Funktion.
|
||||
|
||||
###
|
||||
|
||||
### **2.2 Governance: So viel wie nötig, so wenig wie möglich**
|
||||
|
||||
Die Entscheidungsarchitektur folgt dem Subsidiaritätsprinzip:
|
||||
|
||||
- **Operative Anpassungen** entscheidet das PM-Team eigenständig (z.B.
|
||||
Tool-Konfigurationen, Template-Updates, Schulungsinhalte)
|
||||
|
||||
- **Prozessspezifische Anpassungen** werden mit dem jeweiligen Process
|
||||
Owner abgestimmt (z.B. Änderungen an Prozessschnittstellen, neue
|
||||
Metriken für spezifische Prozesse, Integration neuer Systeme in
|
||||
bestehende Prozesse)
|
||||
|
||||
- **PM-Framework-Weiterentwicklungen** entscheidet das PM-Team
|
||||
eigenständig und informiert die Process Owner (z.B. neue
|
||||
Modellierungsstandards, erweiterte Methodenbausteine, übergreifende
|
||||
Bewertungskriterien)
|
||||
|
||||
- **Fundamentale Änderungen** durchlaufen die Steuerungsgremien (z.B.
|
||||
Wechsel der Prozessmodellierungssprache, grundlegende Änderung der
|
||||
PM-Strategie, Neuausrichtung der Prozessarchitektur)
|
||||
|
||||
Für die **Leistungsbeauftragung** des Prozess-Managements gilt eine
|
||||
klare Logik:
|
||||
|
||||
- **Standard-Leistungen** (Beratung, Workshops) sind niedrigschwellig
|
||||
für alle zugänglich
|
||||
|
||||
- **Projekt-Leistungen** (größere Transformationen) benötigen eine
|
||||
Mission Board-Freigabe
|
||||
|
||||
- **Strategische Initiativen** beauftragt das Vision Board direkt
|
||||
|
||||
- **Krisen-Interventionen** können jederzeit von Führungskräften
|
||||
ausgelöst werden
|
||||
|
||||
Ein dreistufiges **Eskalationsmodell** sichert schnelle Konfliktlösung:
|
||||
Operative Themen werden binnen 48 Stunden geklärt, taktische Konflikte
|
||||
erreichen das Mission Board binnen einer Woche, strategische
|
||||
Grundsatzfragen das Vision Board binnen eines Monats.
|
||||
|
||||
### **2.3 Integration statt Parallelstruktur**
|
||||
|
||||
Die PM-Funktion fügt sich nahtlos in die bestehende DIGITOM-Governance
|
||||
ein. Vision und Mission Board bleiben die zentralen Steuerungsgremien.
|
||||
Die PM-Funktion agiert in ihrem Auftrag und bereitet Entscheidungen vor.
|
||||
|
||||
Schlüsselpartner wie zentrales Geschäftsprozessmanagement (HPA),
|
||||
IT-Architektur, Datenschutz und Informationssicherheit werden
|
||||
systematisch eingebunden. So entstehen keine neuen Silos, sondern
|
||||
vernetzte Kompetenz.
|
||||
|
||||
##
|
||||
|
||||
## **3. Implementierung und kritische Erfolgsfaktoren**
|
||||
|
||||
### **3.1 Konkrete Leistungen, klare Zugänge**
|
||||
|
||||
Das Leistungsportfolio orientiert sich an realen Bedarfen:
|
||||
|
||||
- **Prozess-Framework/DIGITOM-Entwicklung** schafft die methodische
|
||||
Basis
|
||||
|
||||
- **Beratung und Coaching** unterstützen bei konkreten Herausforderungen
|
||||
|
||||
- **Befähigung und Schulung** bauen Kompetenzen dezentral auf
|
||||
|
||||
- **Transparenz und Reporting** ermöglichen faktenbasierte Steuerung
|
||||
|
||||
Die Zugangswege sind bewusst vielfältig: vom Ticketsystem für direkte
|
||||
Hilfe über strukturierte Beauftragungen für größere Vorhaben bis zu
|
||||
informellen Kanälen über das Key-User-Netzwerk.
|
||||
|
||||
### **3.2 Ressourcen und Voraussetzungen**
|
||||
|
||||
Ein dediziertes PM-Team mit komplementären Kompetenzen ist ebenso nötig,
|
||||
wie moderne Prozess-Tools und Qualifizierungsbudgets.
|
||||
|
||||
Wichtiger als Ressourcen sind jedoch die qualitativen Voraussetzungen:
|
||||
|
||||
- **Klares Mandat** der Führung legitimiert die Funktion
|
||||
|
||||
- **Bereitschaft der Fachbereiche** zur aktiven Mitgestaltung
|
||||
|
||||
- **Einbindung der Schlüsselpartner** von Anfang an
|
||||
|
||||
- **Verständnis von Prozessmanagement** als kontinuierliche Entwicklung,
|
||||
nicht als Projekt
|
||||
|
||||
### **3.3 Risiken aktiv managen**
|
||||
|
||||
- **Akzeptanzrisiken** werden durch die konsequente Trennung von
|
||||
Beratung und Kontrolle gemindert. Erfolgsgeschichten und Key-User als
|
||||
Botschafter:innen schaffen Vertrauen.
|
||||
|
||||
- **Ressourcenkonflikte** werden durch ein transparentes
|
||||
Priorisierungsmodell gelöst. Strategische Initiativen gehen dabei
|
||||
stets vor, konkurrierende Anfragen werden offen abgewogen.
|
||||
|
||||
- **Qualitätsrisiken** verhindert die systematische Einbindung von
|
||||
Compliance-Funktionen und "Process Owner" als Qualitätsgatekeeper.
|
||||
|
|
@ -1,7 +1,2 @@
|
|||
# DIGITOM – Konzeptdokumentation
|
||||
|
||||
Dieses Repository enthält die YAML-Quelldateien des DIGITOM-Frameworks.
|
||||
|
||||
DIGITOM ist ein digitales Transformationsmodell zur Weiterentwicklung der IT-Organisation - u.a. auf Basis von ITIL 4.
|
||||
|
||||
> Hinweis: Dieses Repository enthält ausschließlich die konzeptionellen Kerndateien. Pilot-Instanzen, lokale Konfigurationen und interne Arbeitsdokumente sind nicht enthalten.
|
||||
# freiburg_digitom
|
||||
Entwicklung eines Operating Models für das Amt für Digitales und IT der Stadt Freibrug
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue