patrick/digitom_cc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
digitom_cc/#00_meta/digitom_taxonomie.yaml

350 lines
11 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# =============================================================================
# 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"
Reference in a new issue View git blame Copy permalink