säuberung repo

This commit is contained in:
breitenbach76 2026-03-23 22:28:45 +01:00
parent 93b9576bc6
commit 9788e273ed
80 changed files with 47758 additions and 48172 deletions

View file

@ -194,7 +194,7 @@ aufgaben:
- typ: "go_live_freigabe"
name: "Go-Live-Freigabe (Gate 3)"
beschreibung: "Formale Freigabe zur Aktivierung eines neuen oder wesentlich geänderten Services"
lifecycle_aktivitaet: "tr_11"
lifecycle_aktivitaet: "tr_12"
entscheidungsoptionen:
- option: "go_live"
@ -311,7 +311,7 @@ aufgaben:
go_live_freigabe:
zweck: "Freigabe nach Abschluss der Transition-Aktivitäten"
entspricht: "Gate 3 (tr_11)"
entspricht: "Gate 3 (tr_12)"
entscheidungsoptionen:
- "Go-Live"
- "Go-Live mit Auflagen"

View file

@ -72,7 +72,8 @@ aktivitaeten:
beschreibung: >
Grundlegende Definition des neuen oder geänderten Services aus
fachlicher Perspektive.
fachlicher Perspektive. Diese Aktivität bildet den Startpunkt für
die Erstellung der Service-Definition als zentrales Artefakt.
umfasst:
- "Definition von Zweck, Nutzen, Zielgruppen"
@ -81,6 +82,14 @@ aktivitaeten:
- "Ermittlung unterstützender Services und Abhängigkeiten"
- "Identifikation fachlicher und technischer Anforderungen"
hinweis_rollen: >
In der Design-Phase agiert die Rolle service_owner als designierter
Service Owner, da der Service noch nicht im Betrieb existiert und die
formale Übernahme der SO-Rolle erst bei Gate 1 (tr_01) erfolgt
(vgl. GOV-TR-004, GOV-TR-006). Die Empfehlung ist eine frühzeitige
Benennung bei/kurz nach Projektfreigabe; der harte Constraint liegt
bei Gate 1. Dieser Hinweis gilt für alle Aktivitäten ds_01 bis ds_04.
mitarbeit:
- rolle: service_owner
raci: A

View file

@ -1,66 +0,0 @@
# =============================================================================
# SHM VOICE-OF-CUSTOMER (VoC) KONZEPT
# =============================================================================
#
# Voice-of-Customer Methodik im Stakeholder-Management.
# Status: Placeholder mit SPM-Schnittstelle
# =============================================================================
metadata:
name: "Voice-of-Customer (VoC) Konzept"
version: "0.1"
status: "placeholder"
erstellt: "2025-12-17"
projekt: "DIGITOM"
organisation: "Stadt Freiburg / DIGIT"
beschreibung: >
Voice-of-Customer Methodik zur systematischen Erfassung und
Aufbereitung von Kundenrueckmeldungen. Dieses Dokument ist ein
Placeholder und enthaelt vorerst nur die SPM-Schnittstelle.
referenzen:
service_review_konzept: "02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
governance_entscheidungen: "GOV-SR-001"
# =============================================================================
# SCHNITTSTELLE ZU SPM SERVICE-REVIEW
# =============================================================================
spm_schnittstelle:
beschreibung: |
Der VoC-Cluster D2 (Service-Qualitaet) liefert Input fuer die
Service-Review-Dimension "Nutzerzufriedenheit" (SR-D3).
referenz: "spm_konzept_service-review.yaml -> bewertungsschema.dimensionen.SR-D3"
governance_referenz: "GOV-SR-001"
nutzung_im_service_review:
input_fuer_dimension: "SR-D3 Nutzerzufriedenheit"
datenquelle: "VoC-Erkenntnisse aus SHM E2-Reports (Cluster D2)"
verantwortlich: "SO bezieht SHM-Erkenntnisse in Review ein"
indikatoren_aus_shm:
- "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)"
- "Beschwerden und Eskalationen"
- "VoC-Signale aus Stakeholder-Gespraechen"
- "Informelle Rueckmeldungen via SM"
synchronisation:
beschreibung: |
SHM E2-Review liefert VoC-Erkenntnisse als Input fuer den
quartalsweisen Service-Review.
sequenz: "SHM E2-Review -> VoC-Erkenntnisse -> Service-Review nutzt D2-Cluster"
# =============================================================================
# AENDERUNGSHISTORIE
# =============================================================================
aenderungshistorie:
- version: "0.1"
datum: "2025-12-17"
aenderung: |
- Placeholder erstellt mit SPM-Schnittstelle fuer Service-Review (GOV-SR-001)
autor: "DIGITOM-Projekt"
referenz: "spm_konzept_service-review.yaml"

View file

@ -1,20 +0,0 @@
# ========================================
# Stakeholder-Informations-Management-System (SIMS)
# ========================================
# Version: 0.1 (Platzhalter)
# Datum: 2024-12-03
# Status: Ausstehend
# Entwicklungsphase: 11
# ========================================
# ITIL4-Referenz (falls zutreffend):
# itil4_referenz:
# practice: ""
# relevante_elemente: []
# adaption_fuer_digitom: ""
# ========================================
# INHALT
# ========================================
# [Inhalt folgt in Phase 11]

View file

@ -1,337 +0,0 @@
# =============================================================================
# PILOTKONZEPT: WORKING STREAM "PROZESSMANAGEMENT"
# =============================================================================
# Version: 1.0
# Datum: 2026-02-05
# Status: Draft - Konvertiert aus Word-Dokumentation
# =============================================================================
meta:
typ: "pilotkonzept"
funktion_id: "pm"
funktion_name: "Prozess-Management"
version: "1.0"
gueltig_ab: "2026-02-05"
geltungsbereich: "DIGITOM / Prozess-Management"
status:
inhaltlich_abgenommen_durch: ["PM-Teammitglied"]
status: "draft"
quellen:
- "#07 - Pilot-Konzept.docx"
# =============================================================================
# 1. KONTEXT & KONZEPTBESCHREIBUNG
# =============================================================================
kontext:
pilotgegenstand: |
Einführung und Erprobung der neuen Prozess-Management-Funktionsbereich
nach DIGITOM-Modell
voraussetzungen:
titel: "Was benötigen wir zur Zielerreichung?"
anforderungen:
- id: "VA-1"
beschreibung: "Prozess-Management-Tool & Methodik (Auswahl und Setup)"
- id: "VA-2"
beschreibung: "Key-User aus verschiedenen Fachbereichen, je nach Prozessauswahl"
- id: "VA-3"
beschreibung: "Zugang zu bestehender Prozessdokumentation"
- id: "VA-4"
beschreibung: "Workshops-Räume und Moderationsausstattung"
- id: "VA-5"
beschreibung: |
Zugriff auf Prozess-Funktions-Mitglieder (Kapazität muss vorhanden sein,
Coaching für Framework-Schulungen durchführen zu können)
- id: "VA-6"
beschreibung: |
Schulung und Coaching für PM-Team (Coaching für ein Train-the-Trainer-Konzept)
und Key-User (Qualifizierungsmaßnahmen intern/extern).
Bei Bedarf Einbindung externer Trainer.
- id: "VA-7"
beschreibung: |
Auswahl mindestens eines passenden Prozesses zum Prüfen der Wirksamkeit
und Arbeitsweise des PM-Teams im Rahmen der Funktion
hypothesen:
titel: "Was wollen wir mit dem Pilot beweisen/widerlegen?"
items:
- id: "HYP-1"
hypothese: |
Der definierte PM-Funktionsbereich ist in der Praxis funktionsfähig
und wird von den Fachbereichen akzeptiert
- id: "HYP-2"
hypothese: |
Key-User können nach entsprechender Befähigung eigenständig Prozesse
dokumentieren und optimieren
- id: "HYP-3"
hypothese: |
Die Prozessberater sind fähig, die Key-User bei ihrer Aufgabe zu
befähigen und zu unterstützen
- id: "HYP-4"
hypothese: |
Die Aufnahme eines Prozesses bis in das Prozesstool Picture schafft
einen Mehrwert bei der täglichen Arbeit
- id: "HYP-5"
hypothese: "Das Governance-Modell funktioniert effektiv"
risiken:
titel: "Welche potenziellen Risiken sehen wir im Zuge des Piloten?"
items:
- id: "RISK-1"
risiko: |
Keine verfügbaren Ressourcen in der Pilotphase, die konkret
(verfügbare Zeit) mit der Abteilungsleitung abgestimmt wurden
- id: "RISK-2"
risiko: |
Fachbereich kooperiert nicht mit dem Key-User oder Prozessberater
(Zeit-Konflikt oder Akzeptanz)
- id: "RISK-3"
risiko: |
Keine externe Unterstützung in der anvisierten Zeit
(Dienstleister, HPA...)
- id: "RISK-4"
risiko: "Zu starke Anpassungen am Pilotkonzept im Pilotzeitraum"
# =============================================================================
# 2. ROLLENVERGABE
# =============================================================================
rollenvergabe:
pilot_sponsor:
rolle: "Pilot-Sponsor"
person: "Lisa Schroth"
coaches:
rolle: "Coaches"
personen:
- "Patrick Breitenbach"
- "Human Nagafi"
pilot_lead_operativ:
rolle: "Pilot-Lead operativ"
person: "Martin Mayer"
pilot_lead_konsultativ:
rolle: "Pilot-Lead konsultativ"
person: "Patrick Breitenbach"
pilot_team:
titel: "Pilot-Team"
mitglieder:
- rolle: "PFM (Prozess-Framework-Manager)"
person: "Martin Mayer"
- rolle: "PB (Prozess-Berater)"
personen:
- "Gordian Gossen"
- "Jannik Eisenmann"
- "David Trenkle"
- rolle: "PLK (Prozesslandschafts-Koordinator)"
personen:
- "David Trenkle"
- "Gordian Gossen"
hinweis: "Key-User und Process Owner werden im Pilotplan bestimmt"
# =============================================================================
# 3. ARBEITSPAKETE
# =============================================================================
arbeitspakete:
- id: "AP-1"
name: "Kick-off"
aktivitaeten:
- "Kick-off mit dem Funktions-Team"
output: "Pilotvorstellungs-Präsentation"
- id: "AP-2"
name: "Planungsphase"
aktivitaeten:
- "Projektmanagement: Projektplan, Risikobewertung, Stakeholder, Ressourceplanung etc."
- "Kommunikationsmaßnahmen"
- "Schulungsbedarf und Durchführung der Schulungen (Prozess-Berater und Key-User)"
- "Tool-Setup"
- "Prozessmanagement-Leistungsangebot"
- "Methodenübersicht (z.B. Prozess- und Methodenhandbuch)"
- "GPM-Kreislauf für die Prozess-Management-Funktion"
- "Onboarding Key-User"
- "Aufbau Prozessartefakte: Prozessteckbriefe, Prozesslandkarte, Prozessregister"
output: "Pilotplan"
- id: "AP-3"
name: "Onboarding und Informationsphase"
aktivitaeten:
- "Pilotprozesse auswählen"
- "Prozess-Berater onboarden"
- "Key-User auswählen und onboarden"
output: "Bei Bedarf aktualisierter Pilotplan"
- id: "AP-4"
name: "Umsetzungsphase"
aktivitaeten:
- "Pilotprozess aufnehmen in definierten Bereichen"
- "Pilotdurchführung monitoren (Quantitativ und Qualitativ)"
- "Pilotdurchführung reviewen (Was läuft gut? / Was lernen wir unterwegs? / Wo haben wir Probleme?)"
output: "Prozess-Artefakte, Bei Bedarf aktualisierter Pilotplan"
- id: "AP-5"
name: "Retrospektive"
aktivitaeten:
- "Retrospektive vorbereiten und durchführen"
- "Empfehlung weitere Vorgehen durch 1789 ausarbeiten"
output: "Ergebnisbericht Pilotdurchführung, Empfehlungsbericht"
# =============================================================================
# 4. KOMMUNIKATIONSWEGE
# =============================================================================
kommunikation:
intern:
titel: "Interne Kommunikation"
kanaele:
- kanal: "Mission Board"
zweck: "Vorstellung Pilotkonzept und Retroergebnisse"
- kanal: "SyncUp PzM"
rhythmus: "1x Woche"
format: "Teil für Pilot-Team, Teil für restliches Funktions-Team"
- kanal: "Key-User Runde"
- kanal: "Abteilungsleitungen"
- kanal: "DIGIT Allgemein"
- kanal: "Process Owner"
- kanal: "Weekly Check-In Pilotstatus und Review"
rhythmus: "Wöchentlich"
dauer: "Maximal 30 Minuten"
verantwortlich: "1789 inkl. PzM-Team"
- kanal: "Ad-Hoc Coaching"
format: "Auf Anfrage durch 1789"
- kanal: "Moderierte Retrospektive"
anzahl: "1x"
verantwortlich: "1789"
hinweis: "Weitere Maßnahmen gemäß Ergebnisse Kommunikationsplanung (Maßnahme)"
extern:
titel: "Externe Schnittstellen"
partner:
- "Zentrales GPM der Stadt Freiburg"
# =============================================================================
# 5. TIMELINE / RHYTHMUS
# =============================================================================
timeline:
hinweis: |
Folgende Phasenzeitplanung wird angenommen. Anpassungen können während
der Pilotphase erfolgen.
verlaengerung: |
Bei Bedarf Verlängerung bis Anfang 2026. Die Retrospektive sowie die
Empfehlungsdokumente von 1789 sind dann davon nicht betroffen.
phasen:
- phase: "Kick-off"
termin: "ca. 27.08.2025"
typ: "Meilenstein"
- phase: "Pilotphase allgemein"
start: "15.08.2025"
ende: "31.12.2025"
typ: "Rahmen"
- phase: "Planungsphase"
start: "15.08.2025"
ende: "30.09.2025"
arbeitspaket: "AP-2"
- phase: "Onboarding und Informationsphase"
start: "01.10.2025"
ende: "15.11.2025"
arbeitspaket: "AP-3"
- phase: "Umsetzungsphase"
start: "15.10.2025"
ende: "15.12.2025"
arbeitspaket: "AP-4"
- phase: "Retrospektive"
termin: "ca. 16.12.2025"
typ: "Meilenstein"
arbeitspaket: "AP-5"
# =============================================================================
# VERKNÜPFUNGEN
# =============================================================================
verknuepfungen:
referenzierte_dokumente:
- dokument: "Funktionsbeschreibung"
pfad: "#05_prozessmanagement/#05.1_funktion/pm_funktionsbeschreibung.yaml"
relevanz: "Definiert die zu pilotierende Funktion"
- dokument: "Rollenmodell"
pfad: "#05_prozessmanagement/#05.4_rollen/pm_rollenmodell.yaml"
relevanz: "Beschreibt die Rollen PFM, PB, PLK, KNM, KU, PO"
- dokument: "Governance-Framework"
pfad: "#05_prozessmanagement/#05.2_governance/pm_governance-framework.yaml"
relevanz: "Hypothese HYP-5 testet dessen Wirksamkeit"
- dokument: "Leistungs-Canvas"
pfad: "#05_prozessmanagement/#05.3_konzepte/pm_leistungs-canvas.yaml"
relevanz: "Definiert das Leistungsangebot"
externe_partner:
- partner: "1789"
rolle: "Coaching und Moderation"
leistungen:
- "Weekly Check-In"
- "Ad-Hoc Coaching"
- "Moderierte Retrospektive"
- "Empfehlungsbericht"
- partner: "Zentrales GPM Stadt Freiburg (HPA)"
rolle: "Externe Schnittstelle"
# =============================================================================
# ÄNDERUNGSHISTORIE
# =============================================================================
aenderungshistorie:
- version: "1.0"
datum: "2026-02-05"
aenderung: |
Initiale Erstellung durch Konvertierung aus Word-Dokument.
Quelle: #07 - Pilot-Konzept.docx
Inhalte:
- Kontext & Konzeptbeschreibung (7 Voraussetzungen, 5 Hypothesen, 4 Risiken)
- Rollenvergabe (Sponsor, Coaches, Leads, Team)
- 5 Arbeitspakete (Kick-off bis Retrospektive)
- Kommunikationswege (intern und extern)
- Timeline (15.08.2025 - 31.12.2025)
autor: "DIGITOM-Projekt"