sync: initial full sync to match digitom HEAD

#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/README_demand-lifecycle-blueprint.md

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

#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/glossary_demand-lifecycle-blueprint.md

@@ -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].

#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/governance_rules_demand-lifecycle-blueprint.md

@@ -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.