From 1f12fb562510ffc3468d5db432c5a6bbd335f4bc Mon Sep 17 00:00:00 2001 From: breitenbach76 Date: Sun, 21 Jun 2026 15:56:01 +0200 Subject: [PATCH] Update Systemprompt und Architekturhinweis --- #00_meta/README_architektur.md | 132 ++++++++++++ #00_meta/digitom_taxonomie.yaml | 350 ++++++++++++++++++++++++++++++++ CLAUDE.md | 43 ++++ 3 files changed, 525 insertions(+) create mode 100644 #00_meta/README_architektur.md create mode 100644 #00_meta/digitom_taxonomie.yaml create mode 100644 CLAUDE.md diff --git a/#00_meta/README_architektur.md b/#00_meta/README_architektur.md new file mode 100644 index 0000000..11d1ebd --- /dev/null +++ b/#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. diff --git a/#00_meta/digitom_taxonomie.yaml b/#00_meta/digitom_taxonomie.yaml new file mode 100644 index 0000000..13ab8f1 --- /dev/null +++ b/#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" diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..c2c3401 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,43 @@ +# CLAUDE.md – Arbeitsanweisung für dieses Repo + +Dieses Repository ist die **öffentliche, unter Creative Commons veröffentlichte Konzeptsammlung** des **DIGIT Operating Models (DIGITOM)** der Stadt Freiburg (Amt für Digitales und IT). Es enthält ausschließlich die strukturierten Konzept-Dateien (YAML) der fünf Kernfunktionen sowie übergreifende Meta-Dokumente. + +Orientierung zur Struktur: siehe [#00_meta/README_architektur.md](#00_meta/README_architektur.md) und [#00_meta/digitom_taxonomie.yaml](#00_meta/digitom_taxonomie.yaml). + +## Wichtig: Dies ist ein Spiegel-Repository + +- Dieses Repo ist ein **Einweg-Spiegel** eines internen Arbeitsrepositories. Änderungen entstehen **upstream** und werden hierher übertragen. +- **Hier nicht direkt inhaltlich bearbeiten** – Änderungen an den Konzept-YAMLs fließen nicht zurück und gingen beim nächsten Sync verloren. Ausnahme: ausdrücklich auf dieses Repo bezogene Meta-/Doku-Dateien (z. B. dieses `CLAUDE.md`, das Architektur-README). + +## Oberste Regel: Quelltreue + +- Beantworte inhaltliche Fragen zum DIGITOM **ausschließlich** auf Basis der Dateien in diesem Repo. **Nichts erfinden** – keine Konzepte, Rollen, Pfade, Beispiele oder Zahlen, die nicht belegt sind. +- Steht etwas nicht im Repo, sag das offen und nenne, was stattdessen abgedeckt ist – statt zu raten. +- Bleib nachvollziehbar: **Dateipfad nennen** (als klickbaren Link, ggf. mit `:Zeile`). + +## Begriffe & Glossar + +- Verwende die offiziellen DIGITOM-Begriffe. Setze ähnliche Begriffe **nicht gleich** – „Bedarf" ≠ „Demand". +- Primäre Begriffsreferenz: [service-portfolio-management_glossar.yaml](#02_service-portfolio-management/service-portfolio-management_glossar.yaml); funktionsspezifische Glossare ergänzen. +- Rollen statt Namen: „das Demand-Portfolio-Management", „der Service Owner" – keine Personennamen. + +## Vollständigkeit + +- Hat ein Konzept mehrere Varianten/Pfade (z. B. die drei Routing-Ziele Mission Board / DSR-mit-Delegation / DSR), **nenne alle**. +- Bei Schnittstellenthemen beide Seiten und den Übergabepunkt erklären. +- Verantwortlichkeiten über die RACI-Logik benennen (R/A/C/I), inkl. der Accountable-Rolle – auch wenn sie außerhalb der gerade betrachteten Funktion liegt. + +## Status beachten + +Jedes Konzept-YAML hat einen `status`/`meta.status`-Block: `draft` (in Entwicklung), `review` (zur Abstimmung), `abgenommen_in_gesamtkonzept`/`final` (gültig). **Weise auf nicht-finalen Status hin**, wenn du daraus zitierst. + +## Repo-Konventionen + +- **Konzepttypen:** Funktion · Practice · Rolle · Gremium · Wertschöpfungsprozess – definiert in [#00_meta/digitom_taxonomie.yaml](#00_meta/digitom_taxonomie.yaml). +- **Funktionsordner:** `#01_*` DPM · `#02_*` SPM · `#03_*` SHM · `#04_*` Mission Board · `#05_*` Prozessmanagement. +- **Dateitypen:** `README_*` = Navigation · `*_glossar.yaml` = Begriffe · `*_funktionsbeschreibung.yaml` = Mandat/Schnittstellen · `*_governance*.yaml` / `*_raci.yaml` = Verantwortlichkeiten · `*_schema_*.yaml` = Artefaktstruktur · `*-lifecycle-blueprint*` = Prozessabläufe. +- **Sprache:** Deutsch ist Standard. + +## Lizenz + +Inhalte stehen unter Creative Commons (siehe Repository-Lizenzangabe) und dürfen unter den dort genannten Bedingungen nachgenutzt werden.