Update Systemprompt und Architekturhinweis

#00_meta/README_architektur.md

@@ -0,0 +1,132 @@
+# DIGITOM Repository – Architektur-Überblick
+
+## Zweck dieses Dokuments
+Dieses README erklärt die Struktur dieses Repositories und dient als Orientierung für die Navigation und Interpretation des Modells.
+
+## Was dieses Repository ist
+
+Dieses Repository ist die **öffentliche, unter Creative Commons veröffentlichte Konzeptsammlung** des **DIGIT Operating Models (DIGITOM)** – des Organisationsmodells des Amts für Digitales und IT der Stadt Freiburg. Das Modell strukturiert die Abläufe auf Basis von **ITIL 4**.
+
+Es enthält ausschließlich die **strukturierten Konzept-Dateien** (YAML) der fünf Kernfunktionen. Es ist ein **kuratierter Auszug** aus einem internen Arbeitsrepository und wird daraus gepflegt – dieses Repository wird **nicht direkt bearbeitet**.
+
+### Repository-Philosophie
+
+Das Modell folgt einem **Bottom-Up-Entwicklungsansatz**: Governance-Strukturen emergieren aus operativen Konzepten, nicht umgekehrt. Die Konzepte sind als maschinen- und menschenlesbare YAML-Dateien abgelegt, damit Struktur, Rollen, Schnittstellen und Entscheidungsregeln eindeutig und versionierbar bleiben.
+
+### Konzepttypen (Taxonomie)
+
+Das Modell unterscheidet mehrere Konzepttypen (vollständig definiert in [digitom_taxonomie.yaml](digitom_taxonomie.yaml)):
+
+| Typ | Charakter | Beispiel |
+|-----|-----------|----------|
+| **Funktion** | Organisationseinheit mit Mandat und Schnittstellen | DPM, SPM, SHM |
+| **Practice** | Inhaltliche Verantwortung innerhalb einer Funktion | Service Level Management, Incident Management |
+| **Rolle** | Aufgaben-/Verantwortungsbereich einer Person | Service Owner, Demand-Portfolio-Manager*in |
+| **Gremium** | Entscheidungsinstanz mit Geschäftsordnung | Vision Board, Mission Board, DSR |
+| **Wertschöpfungsprozess** | End-to-End-Ablauf über mehrere Funktionen | Demand-Lifecycle, Service-Lifecycle |
+
+### Dokumenttypen
+
+| Suffix/Präfix | Bedeutung |
+|---------------|-----------|
+| `README_*.md` | Kontext und Navigation für ein Modul |
+| `*_glossar.yaml` | Begriffsdefinitionen |
+| `*_funktionsbeschreibung.yaml` | Mandat, Zweck und Schnittstellen einer Funktion |
+| `*_governance*.yaml` / `*_raci.yaml` | Verantwortlichkeiten, RACI, Entscheidungsregeln |
+| `*_schema_*.yaml` | Strukturdefinitionen für Artefakte |
+| `*_practice_*.yaml` | Practice-Beschreibungen |
+| `*-lifecycle-blueprint*` | Prozessabläufe über Phasen und Quality Gates |
+
+---
+
+## Ordnerstruktur
+```
+digitom_cc/
+├── #00_meta/                               # Übergreifende Dokumente
+│   ├── digitom_taxonomie.yaml              # Konzepttypen-Definition
+│   └── README_architektur.md               # (dieses Dokument)
+│
+├── #01_demand-portfolio-management/        # Funktion: DPM
+│   ├── #01.1_demand-portfolio-management_documentation/   # Konzept-Dokumentation
+│   └── #01.2_demand-lifecycle-blueprint/   # Lifecycle-Prozess
+│
+├── #02_service-portfolio-management/       # Funktion: SPM
+│   ├── service-portfolio-management_glossar.yaml          # SPM-Begriffe (primäre Begriffsreferenz)
+│   └── 02.1_spm_konzepte/
+│       ├── 01_spm_governance/              # Governance-Dokumente
+│       ├── 02_spm_service-lifecycle-blueprint/    # Lifecycle-Prozess
+│       ├── 02a_lifecycle-konzepte/         # Ergänzende Lifecycle-Konzepte
+│       ├── 03_spm_practices/               # Practice-Definitionen
+│       ├── 04_rollen/                      # Rollenbeschreibungen
+│       ├── 06_Informationsmodell/          # Schemas für Artefakte
+│       └── 07_spm_arbeitsmaterialien/      # Templates, Leitfäden
+│
+├── #03_stakeholder-management/             # Funktion: SHM
+│   ├── #03.1_funktion/
+│   ├── #03.2_governance/
+│   ├── #03.3_konzepte/
+│   ├── #03.4_methodik/
+│   ├── #03.5_schnittstellen/
+│   ├── #03.6_informationsmodell/
+│   └── #03.7_arbeitsmaterialien/
+│
+├── #04_mission-board/                      # Gremium: Mission Board (Geschäftsordnung)
+│
+├── #05_prozessmanagement/                  # Funktion: Prozessmanagement
+│   ├── #05.1_funktion/
+│   ├── #05.2_governance/
+│   ├── #05.3_konzepte/
+│   ├── #05.4_rollen/
+│   └── docs/
+│
+└── README.md
+```
+
+---
+
+## Navigationslogik
+
+### Einstieg nach Funktion
+- **DPM-Themen** (Demand-Portfolio-Management): `#01_demand-portfolio-management/`
+- **SPM-Themen** (Service-Portfolio-Management): `#02_service-portfolio-management/`
+- **SHM-Themen** (Stakeholder-Management): `#03_stakeholder-management/`
+- **Mission Board** (Gremium): `#04_mission-board/`
+- **Prozessmanagement**: `#05_prozessmanagement/`
+
+### Einstieg nach Informationstyp
+- **Begriffsdefinitionen**: `*_glossar.yaml` (primär: `service-portfolio-management_glossar.yaml`)
+- **Rollen und Verantwortlichkeiten**: `*/governance/`, `*/rollen/` oder `*_raci.yaml`
+- **Prozessabläufe**: `*-lifecycle-blueprint/`
+- **Artefakt-Strukturen**: `*/Informationsmodell/` oder `*_schema_*.yaml`
+
+### Status-Konvention
+Jedes YAML enthält im `meta`/`metadata`-Block einen `status`:
+- `draft` – in Entwicklung
+- `review` – zur Abstimmung
+- `abgenommen_in_gesamtkonzept` / `final` – abgestimmt und gültig
+
+Konzepte mit nicht-finalem Status sind als solche zu kennzeichnen, wenn daraus zitiert wird.
+
+---
+
+## Querverweise und Kohärenz
+
+### Glossar als Begriffsbasis
+Das SPM-Glossar (`service-portfolio-management_glossar.yaml`) ist die primäre Begriffsreferenz für alle Funktionen. Abweichende oder ergänzende Begriffe werden in funktionsspezifischen Glossaren dokumentiert. Begriffe werden **nicht gleichgesetzt** – z. B. ist „Bedarf" nicht dasselbe wie „Demand".
+
+### Schnittstellen zwischen Funktionen
+Die wichtigsten Übergabepunkte:
+- **SHM → DPM**: Qualifizierte Bedarfe aus der Stakeholder-Interaktion
+- **DPM → SPM/PPM**: Übergabe freigegebener Demands an Service- bzw. Projektentwicklung
+- **SPM → SHM**: Service-Informationen für die Stakeholder-Kommunikation
+
+---
+
+## Hinweis zur Pflege
+
+Dieses Repository ist ein **Einweg-Spiegel** des internen Arbeitsmodells: Änderungen entstehen im internen Repository und werden hierher übertragen. Direkte Änderungen in diesem Repository fließen **nicht** zurück und sollten daher unterbleiben.
+
+---
+
+## Lizenz
+Die Inhalte dieses Repositories stehen unter einer **Creative-Commons-Lizenz** (siehe Repository-Lizenzangabe). Sie dürfen unter den dort genannten Bedingungen nachgenutzt werden.

#00_meta/digitom_taxonomie.yaml

@@ -0,0 +1,350 @@
+# =============================================================================
+# DIGITOM TAXONOMIE
+# =============================================================================
+# Definiert die konzeptionellen Bausteine des DIGIT Operating Models
+# und deren Beziehungen zueinander.
+# =============================================================================
+
+metadata:
+  version: "1.0"
+  datum: "2025-11-28"
+  status: "Gültig für SPM, SHM; Nachziehen für DPM ausstehend"
+  zweck: >
+    Einheitliche Sprache für die Dokumentation und Weiterentwicklung
+    des Operating Models. Schafft Klarheit über Konzepttypen und
+    deren Zusammenspiel.
+
+# =============================================================================
+# KONZEPTTYPEN
+# =============================================================================
+
+konzepttypen:
+
+  # ---------------------------------------------------------------------------
+  funktion:
+    definition: >
+      Organisationseinheit mit Mandat, Verantwortungsbereich und
+      definierten Schnittstellen.
+
+    charakteristika:
+      - "Hat einen abgegrenzten Verantwortungsbereich"
+      - "Definiert Schnittstellen zu anderen Funktionen (Input/Output)"
+      - "Bündelt eine oder mehrere Practices"
+      - "Wird durch Rollen operationalisiert"
+
+    dokumenttyp: "Funktionsbeschreibung"
+
+    beispiele:
+      - id: "DPM"
+        name: "Demand-Portfolio-Management"
+      - id: "SPM"
+        name: "Service-Portfolio-Management"
+      - id: "SHM"
+        name: "Stakeholder-Management"
+      - id: "PPM"
+        name: "Projekt-Portfolio-Management"
+
+    struktur_beispiel:
+      funktion: "Service-Portfolio-Management (SPM)"
+      mandat: "Steuerung des Service-Portfolios über den gesamten Lifecycle"
+      practices:
+        - "Service Level Management"
+        - "Service Catalog Management"
+      rollen:
+        - "Service-Portfolio-Manager*in"
+        - "Service Owner"
+      schnittstellen:
+        - "DPM"
+        - "PPM"
+        - "SHM"
+
+  # ---------------------------------------------------------------------------
+  practice:
+    definition: >
+      Inhaltliche Verantwortung innerhalb einer Funktion.
+      Wird von einer Rolle als Practice Owner verantwortet.
+
+    charakteristika:
+      - "Wird von einem Practice Owner (Rolle) verantwortet"
+      - "Umfasst definierte Aktivitäten und Prozessschritte"
+      - "Hat eigene Governance-Regeln (wer entscheidet was)"
+      - "Ist an ITIL4-Practices orientiert, aber DIGIT-spezifisch adaptiert"
+
+    dokumenttyp: "Practice-Konzept"
+
+    beispiele:
+      - id: "P-01"
+        name: "Service Catalog Management"
+        funktion: "SPM"
+      - id: "P-02"
+        name: "Service Level Management"
+        funktion: "SPM"
+      - id: "P-03"
+        name: "Change Enablement"
+        funktion: "SPM"
+      - id: "DM"
+        name: "Demand Management"
+        funktion: "DPM"
+        status: "implizit vorhanden, explizite Dokumentation ausstehend"
+
+    struktur_beispiel:
+      practice: "Service Level Management (P-02)"
+      practice_owner: "Service-Portfolio-Manager*in"
+      kernkonzepte:
+        - "SLA"
+        - "SLS"
+        - "Service-Kategorien"
+        - "Kundenvertretung"
+      aktivitaeten:
+        - "SLA-Anforderungen erheben"
+        - "SLS erstellen"
+        - "SLA vereinbaren"
+        - "Service Levels monitoren"
+        - "SLA-Performance reporten"
+        - "SLA reviewen"
+      governance: "Entscheidungswege je Service-Kategorie"
+      schnittstellen:
+        - "SCM"
+        - "Monitoring"
+        - "Service Review"
+
+    verhaeltnis_zu_funktion: >
+      Eine Funktion kann mehrere Practices bündeln.
+      Die Funktion definiert das "Wer und Warum",
+      die Practice das "Was und Wie".
+
+  # ---------------------------------------------------------------------------
+  rolle:
+    definition: >
+      Klar umrissener Aufgaben- und Verantwortungsbereich,
+      der einer Person zugewiesen ist. Gekoppelt an Funktion
+      und/oder Practice.
+
+    charakteristika:
+      - "Ist an eine Funktion und/oder ein Gremium gekoppelt"
+      - "Kann Practice Owner für eine oder mehrere Practices sein"
+      - "Hat definierte Entscheidungsbefugnisse"
+      - "Wird in RACI-Matrizen referenziert"
+
+    dokumenttyp: "Rollenbeschreibung (Teil der Funktionsbeschreibung oder separates Dokument)"
+
+    beispiele:
+      - id: "SPM"
+        name: "Service-Portfolio-Manager*in"
+        funktion: "SPM"
+        practice_owner_fuer:
+          - "Service Level Management"
+          - "Service Catalog Management"
+          - "Change Enablement"
+      - id: "SO"
+        name: "Service Owner"
+        funktion: "SPM"
+        practice_owner_fuer: []
+      - id: "DPM"
+        name: "Demand-Portfolio-Manager*in"
+        funktion: "DPM"
+        practice_owner_fuer:
+          - "Demand Management"
+      - id: "SHM"
+        name: "Stakeholder-Manager*in"
+        funktion: "SHM"
+
+    struktur_beispiel:
+      rolle: "Service-Portfolio-Manager*in"
+      funktion: "SPM"
+      practice_owner_fuer:
+        - "Service Level Management"
+        - "Service Catalog Management"
+        - "Change Enablement"
+      gremien:
+        - rolle: "Mitglied"
+          gremium: "SOR"
+        - rolle: "Mitglied"
+          gremium: "DSR"
+      entscheidungsbefugnisse:
+        - "Katalogfreigabe (minor)"
+        - "SLA-Validierung"
+        - "Service-Definition-Freigabe"
+
+  # ---------------------------------------------------------------------------
+  gremium:
+    definition: >
+      Entscheidungsinstanz mit definierter Governance-Kompetenz.
+
+    charakteristika:
+      - "Hat eine Geschäftsordnung (Zusammensetzung, Rhythmus, Entscheidungsverfahren)"
+      - "Trifft Entscheidungen innerhalb seines Mandats"
+      - "Ist Teil der Governance-Architektur (strategisch / taktisch / koordinativ)"
+
+    dokumenttyp: "Geschäftsordnung"
+
+    governance_ebenen:
+      - ebene: "Strategisch"
+        gremien:
+          - "Vision Board"
+        fokus: "Langfristige Ausrichtung, Operating Model"
+
+      - ebene: "Taktisch"
+        gremien:
+          - "Mission Board"
+        fokus: "Priorisierung, Ressourcenallokation"
+
+      - ebene: "Koordinativ"
+        gremien:
+          - "Demand & Stakeholder-Runde (DSR)"
+          - "Service Operations Runde (SOR)"
+          - "IT-Architektur-Board"
+        fokus: "Operative Abstimmung, fachliche Entscheidungen"
+
+    beispiele:
+      - id: "VB"
+        name: "Vision Board"
+        ebene: "strategisch"
+      - id: "MB"
+        name: "Mission Board"
+        ebene: "taktisch"
+      - id: "DSR"
+        name: "Demand & Stakeholder-Runde"
+        ebene: "koordinativ"
+      - id: "SOR"
+        name: "Service Operations Runde"
+        ebene: "koordinativ"
+
+  # ---------------------------------------------------------------------------
+  wertschoepfungsprozess:
+    definition: >
+      End-to-End-Ablauf über mehrere Funktionen und Phasen hinweg,
+      der Wert für Stakeholder erzeugt.
+
+    charakteristika:
+      - "Hat einen definierten Auslöser (Trigger) und ein Ergebnis (Outcome)"
+      - "Durchläuft mehrere Phasen mit Quality Gates"
+      - "Involviert verschiedene Funktionen mit ihren Practices"
+      - "Wird durch Gremien an definierten Entscheidungspunkten gesteuert"
+
+    dokumenttyp: "Lifecycle-Blueprint"
+
+    beispiele:
+      - id: "demand-lifecycle"
+        name: "Demand-Lifecycle"
+        phasen:
+          - "Bedarfserfassung (SHM)"
+          - "Qualifizierung (DPM)"
+          - "Priorisierung (DPM)"
+          - "Entscheidung (DSR/MB)"
+          - "Übergabe an PPM oder SPM"
+
+      - id: "service-lifecycle"
+        name: "Service-Lifecycle"
+        phasen:
+          - name: "Service Entwicklung"
+            gate: "Übergabe an Transition (SOR)"
+          - name: "Service Transition"
+            gate: "Go-Live-Freigabe (SOR)"
+          - name: "Service Betrieb + Support"
+            gate: "Kontinuierlich"
+          - name: "Service Review"
+            gate: "Improve / Redesign / Retire (SOR → ggf. MB)"
+
+# =============================================================================
+# BEZIEHUNGEN ZWISCHEN KONZEPTEN
+# =============================================================================
+
+beziehungen:
+
+  - von: "Wertschöpfungsprozess"
+    zu: "Funktion"
+    art: "durchläuft"
+    beschreibung: "Ein Wertschöpfungsprozess durchläuft mehrere Funktionen"
+
+  - von: "Funktion"
+    zu: "Practice"
+    art: "bündelt"
+    beschreibung: "Eine Funktion bündelt eine oder mehrere Practices"
+
+  - von: "Funktion"
+    zu: "Rolle"
+    art: "wird operationalisiert durch"
+    beschreibung: "Eine Funktion wird durch Rollen operationalisiert"
+
+  - von: "Rolle"
+    zu: "Practice"
+    art: "ist Practice Owner für"
+    beschreibung: "Eine Rolle kann Practice Owner für Practices sein"
+
+  - von: "Rolle"
+    zu: "Gremium"
+    art: "ist Mitglied von"
+    beschreibung: "Rollen können Mitglieder in Gremien sein"
+
+  - von: "Gremium"
+    zu: "Practice"
+    art: "entscheidet über"
+    beschreibung: "Gremien treffen Governance-Entscheidungen für Practices"
+
+  - von: "Gremium"
+    zu: "Wertschöpfungsprozess"
+    art: "steuert"
+    beschreibung: "Gremien steuern Wertschöpfungsprozesse an Quality Gates"
+
+# =============================================================================
+# ZUORDNUNG: FUNKTION → PRACTICES
+# =============================================================================
+
+funktionen_practices_mapping:
+
+  - funktion: "SPM"
+    practices:
+      - id: "P-01"
+        name: "Service Catalog Management"
+        status: "in Entwicklung"
+      - id: "P-02"
+        name: "Service Level Management"
+        status: "in Entwicklung"
+      - id: "P-03"
+        name: "Change Enablement"
+        status: "ausstehend"
+      - id: "P-04"
+        name: "Incident Management"
+        status: "ausstehend"
+      - id: "P-05"
+        name: "Request Management"
+        status: "ausstehend"
+      - id: "P-06"
+        name: "Problem Management"
+        status: "ausstehend"
+      - id: "P-07"
+        name: "Monitoring & Event Management"
+        status: "ausstehend"
+
+  - funktion: "DPM"
+    practices:
+      - id: "DM"
+        name: "Demand Management"
+        status: "implizit vorhanden"
+        hinweis: "Klassifizierung, Bewertung, Priorisierung – explizite Dokumentation nachziehen"
+
+  - funktion: "SHM"
+    practices:
+      - id: "SE"
+        name: "Stakeholder Engagement"
+        status: "ausstehend"
+      - id: "BQ"
+        name: "Bedarfsqualifizierung"
+        status: "ausstehend"
+    hinweis: "Practices werden bei SHM-Modellierung definiert"
+
+  - funktion: "PPM"
+    practices:
+      - hinweis: "Noch zu definieren"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+
+  - version: "1.0"
+    datum: "2025-11-28"
+    aenderung: "Initiale Erstellung auf Basis SPM-Konzeptarbeit"
+    autor: "DIGITOM-Projekt"