Update Systemprompt und Architekturhinweis

This commit is contained in:
breitenbach76 2026-06-21 15:56:01 +02:00
parent 07050fa5a6
commit 1f12fb5625
3 changed files with 525 additions and 0 deletions

View 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"