Update Systemprompt und Architekturhinweis
This commit is contained in:
parent
07050fa5a6
commit
1f12fb5625
3 changed files with 525 additions and 0 deletions
132
#00_meta/README_architektur.md
Normal file
132
#00_meta/README_architektur.md
Normal file
|
|
@ -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.
|
||||||
350
#00_meta/digitom_taxonomie.yaml
Normal file
350
#00_meta/digitom_taxonomie.yaml
Normal file
|
|
@ -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"
|
||||||
43
CLAUDE.md
Normal file
43
CLAUDE.md
Normal file
|
|
@ -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.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue