digitom_cc/#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml

1807 lines
71 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.

# =============================================================================
# SHM ENGAGEMENT-FRAMEWORK: ARBEITSSTAND
# =============================================================================
# Version: 0.5 (Entwurf)
# Datum: 2025-12-10
# Status: In Entwicklung
# Kontext: Entwicklung Phase 2
# =============================================================================
meta:
dokument_typ: "arbeitsstand"
modul: "shm_engagement-framework"
phase: 2
zweck: |
Das Engagement-Framework operationalisiert die Betreuungsmodi aus dem
Stakeholder-Portfolio. Es definiert Interaktionsformate,
Frequenzen und Reaktionslogiken für die Auftraggeber-Betreuung.
design_prinzipien:
- prinzip: "Zweckorientierung"
beschreibung: "Jedes Format verfolgt einen definierten Zweck"
- prinzip: "Differenzierung nach Betreuungsmodus"
beschreibung: "Key-Stakeholder erhalten qualitativ andere Betreuung, nicht nur häufigere"
- prinzip: "Bidirektionaler Wertfluss"
beschreibung: "Strategische Formate liefern Input für DIGIT-Strategie"
- prinzip: "Prozessgesteuerte Eskalation"
beschreibung: "Eskalationswege sind strukturiert, nicht personengebunden"
annahmen:
- id: "ANNAHME-EF-001"
thema: "Frequenz-Richtwerte"
beschreibung: |
Die angegebenen Frequenzen sind Empfehlungen, keine verbindlichen Vorgaben.
Die finalen Frequenzen werden im Rahmen der Pilotierung festgelegt und
müssen verprobt werden.
status: "Im Pilotierung zu validieren"
- id: "ANNAHME-EF-002"
thema: "Cluster-basierte Kollektivformate"
beschreibung: |
Kollektive Formate werden primär nach Segmentierungs-Clustern organisiert.
Thematische Formate ergänzen dies für clusterübergreifende Bedarfe.
status: "Designentscheidung"
- id: "ANNAHME-EF-003"
thema: "Integriertes Auftraggeber-Forum"
beschreibung: |
Die Auftraggeber-Vertretungen (SLM) und Advisory Boards (SHM) werden
zu einem integrierten Auftraggeber-Forum konsolidiert. Diese Entscheidung
reduziert Gremien-Redundanz und stärkt die gemeinsame Außenwirkung.
status: "Designentscheidung"
governance_referenz: "GOV-SHM-015"
schnittstellen:
- schnittstelle: "DIGIT-Strategieprozess"
richtung: "SHM → Strategie"
beschreibung: |
Strategische Formate liefern Erkenntnisse zu Bedarfstrends und
Entwicklungspotenzialen, die in die DIGIT-Strategie einfließen.
status: "Strategieprozess noch nicht modelliert Verweis auf Schnittstelle"
- schnittstelle: "Voice-of-Customer (VoC)"
richtung: "Engagement-Framework → VoC → Koordinations- und Steuerungsstruktur"
beschreibung: |
Das Engagement-Framework liefert Inputs für das VoC-Konzept
(Beziehungsqualität, Eskalationen, Interaktionsqualität).
VoC aggregiert diese zu übergreifenden Erkenntnissen, die in die
REV-1/REV-2 Review-Zyklen einfließen.
status: "Aktiv (Phase 5 abgeschlossen)"
referenz: "shm_voice-of-customer.yaml"
# =============================================================================
# FUNKTIONALE HERLEITUNG
# =============================================================================
funktionale_herleitung:
leitfrage: |
Welche Entscheidungen und Handlungen soll das Engagement-Framework
unterstützen?
kernentscheidungen:
- id: EKE-1
name: "Interaktionsplanung"
leitfrage: "Wann interagiere ich mit wem in welchem Format?"
kontext: |
Ein Stakeholder-Manager betreut mehrere Ämter mit unterschiedlichen
Betreuungsmodi. Das Framework muss helfen, Zeitressourcen systematisch
zu allokieren planbar, nicht ad-hoc.
unterstuetzt_durch:
- "Interaktionsformat-Katalog"
- "Frequenz-Matrix"
- id: EKE-2
name: "Reaktionssteuerung"
leitfrage: "Wie reagiere ich auf eingehende Anfragen, Beschwerden, Eskalationen?"
kontext: |
Nicht alle Interaktionen sind geplant. Das Framework muss Regeln liefern,
wann SHM reagiert, wann weitergeleitet wird, und wie eskaliert wird.
unterstuetzt_durch:
- "Reaktionslogik"
- "Eskalationspfade"
- id: EKE-3
name: "Beziehungsqualitätssicherung"
leitfrage: "Woran erkenne ich Beziehungsprobleme, wann interveniere ich?"
kontext: |
Beziehungen können erodieren ohne explizite Beschwerden. Das Framework
sollte Indikatoren und Review-Mechanismen liefern.
unterstuetzt_durch:
- "Review-Mechanismus"
- "Interventions-Trigger"
- id: EKE-4
name: "Strategische Wertschöpfung"
leitfrage: "Wie schaffe ich bei Key-Stakeholdern aktiven Mehrwert?"
kontext: |
Bei priorisierten Stakeholdern ist SHM nicht nur reaktiver Aufnehmer,
sondern proaktiver Berater. Das Framework muss Formate definieren,
die strategische Beratung und bidirektionalen Wertfluss ermöglichen.
unterstuetzt_durch:
- "Strategische Formate"
- "Output-Kanal Richtung DIGIT-Strategie"
# =============================================================================
# FORMAT-TAXONOMIE: ÜBERSICHT
# =============================================================================
format_taxonomie:
beschreibung: |
Das Engagement-Framework unterscheidet fünf Format-Kategorien, die
unterschiedliche Zwecke erfüllen und sich in Planbarkeit, Teilnehmerkreis
und Interaktionstiefe unterscheiden.
kategorien:
- kategorie: "Turnus-Formate"
kuerzel: "TF"
charakter: "Geplant, wiederkehrend, 1:1"
primaerer_zweck: "Regelmäßiger Austausch, Beziehungspflege, Früherkennung"
betreuungsmodi: ["Key", "Aktiv"]
- kategorie: "Strategische Formate"
kuerzel: "SF"
charakter: "Geplant, anlassbezogen, 1:1 oder Kleingruppe"
primaerer_zweck: "Aktive Digitalberatung, strategische Bedarfsentwicklung"
betreuungsmodi: ["Key"]
- kategorie: "Kollektive Formate"
kuerzel: "KF"
charakter: "Geplant, wiederkehrend, Gruppe"
primaerer_zweck: "Effiziente Abdeckung mehrerer Stakeholder, Informationsaustausch"
betreuungsmodi: ["Standard", "Basis"]
- kategorie: "Thematische Formate"
kuerzel: "ThF"
charakter: "Anlassbezogen, Gruppe"
primaerer_zweck: "Bedarfskonsolidierung über Cluster-Grenzen"
betreuungsmodi: ["Alle (bedarfsgetrieben)"]
- kategorie: "Reaktive Formate"
kuerzel: "RF"
charakter: "Ungeplant, anlassbezogen"
primaerer_zweck: "Umgang mit Eskalationen, Beschwerden, Ad-hoc-Anfragen"
betreuungsmodi: ["Alle"]
# =============================================================================
# TURNUS-FORMATE (TF)
# =============================================================================
turnus_formate:
beschreibung: |
Turnus-Formate bilden das Rückgrat der regelmäßigen Stakeholder-Betreuung.
Sie sind geplant, wiederkehrend und finden im 1:1-Setting zwischen
Stakeholder-Manager und Kundenvertreter statt.
formate:
# -------------------------------------------------------------------------
# TF-01: Strategisches Turnus-Gespräch (Key)
# -------------------------------------------------------------------------
- id: "TF-01"
name: "Strategisches Turnus-Gespräch"
zweck: |
Tiefgehender Austausch mit Key-Stakeholdern zu strategischen Themen,
laufenden Vorhaben und Beziehungsqualität. Geht über Statusabfrage
hinaus aktive Beratungskomponente.
zielgruppe:
betreuungsmodus: "Key (Proaktiv/Dediziert)"
teilnehmer_auftraggeber: "Amtsleitung oder delegierte SLA-Befugnis"
teilnehmer_shm: "Zugeordneter Stakeholder-Manager"
frequenz:
empfehlung: "Quartalsweise"
flexibilitaet: |
Kann bei Bedarf häufiger stattfinden. Minimum: halbjährlich.
referenz_annahme: "ANNAHME-EF-001"
typische_inhalte:
- block: "Beziehungs-Check"
beschreibung: "Wie läuft die Zusammenarbeit? Gibt es Irritationen?"
dauer_anteil: "10%"
- block: "Laufende Vorhaben"
beschreibung: "Status relevanter Projekte, Demands, Service-Themen"
dauer_anteil: "30%"
- block: "Strategischer Ausblick"
beschreibung: "Welche Themen stehen beim Amt an? Digitalisierungsbedarfe?"
dauer_anteil: "40%"
- block: "Offene Punkte / Vereinbarungen"
beschreibung: "Konkrete nächste Schritte, Verantwortlichkeiten"
dauer_anteil: "20%"
voraussetzungen:
informationen:
- "Aktueller Projektstatus zu Vorhaben des Amtes"
- "Service-Performance-Daten (SLA-Einhaltung, offene Tickets)"
- "Offene Bedarfe und Demands im System"
vorbereitung:
- "Agenda vorab abstimmen"
- "Relevante Statusberichte sichten"
output:
dokumentation: "Gesprächsprotokoll im SIMS (Stakeholder-Informations-Management-System)"
follow_up: "Vereinbarte Maßnahmen mit Verantwortlichkeit und Termin"
strategie_input: |
Erkenntnisse zu strategischen Bedarfstrends werden aggregiert und
fließen in DIGIT-Strategieprozess ein.
[Verweis: Strategieprozess noch nicht modelliert]
template_bedarf:
- "Agenda-Vorlage Strategisches Turnus-Gespräch"
- "Protokoll-Vorlage"
abgrenzung: |
Unterscheidet sich vom operativen Turnus-Gespräch (TF-02) durch
strategische Tiefe und Beratungskomponente.
# -------------------------------------------------------------------------
# TF-02: Operatives Turnus-Gespräch (Aktiv)
# -------------------------------------------------------------------------
- id: "TF-02"
name: "Operatives Turnus-Gespräch"
zweck: |
Regelmäßiger Austausch mit Aktiv-Stakeholdern zu laufenden Themen
und Service-Zufriedenheit. Fokus auf Beziehungspflege und
Früherkennung von Problemen.
zielgruppe:
betreuungsmodus: "Aktiv (Regelmäßig)"
teilnehmer_auftraggeber: "Amtsleitung oder operative Ansprechperson"
teilnehmer_shm: "Zugeordneter Stakeholder-Manager"
frequenz:
empfehlung: "Halbjährlich"
flexibilitaet: |
Kann bei konkretem Anlass (laufendes Projekt, bekannte Probleme)
auf quartalsweise erhöht werden.
referenz_annahme: "ANNAHME-EF-001"
typische_inhalte:
- block: "Zufriedenheits-Check"
beschreibung: "Wie zufrieden ist das Amt mit den IT-Services?"
dauer_anteil: "20%"
- block: "Laufende Themen"
beschreibung: "Offene Tickets, Bedarfe, bekannte Probleme"
dauer_anteil: "40%"
- block: "Ausblick"
beschreibung: "Anstehende Veränderungen beim Amt, absehbare Bedarfe"
dauer_anteil: "30%"
- block: "Vereinbarungen"
beschreibung: "Nächste Schritte, offene Punkte"
dauer_anteil: "10%"
voraussetzungen:
informationen:
- "Offene Tickets des Amtes"
- "Bekannte Service-Probleme"
vorbereitung:
- "Kurze Agenda vorab"
output:
dokumentation: "Kurzprotokoll im SIMS"
follow_up: "Offene Punkte mit Verantwortlichkeit"
template_bedarf:
- "Agenda-Vorlage Operatives Turnus-Gespräch"
abgrenzung: |
Weniger strategische Tiefe als TF-01. Fokus auf operative
Beziehungspflege, nicht auf aktive Beratung.
# =============================================================================
# STRATEGISCHE FORMATE (SF)
# =============================================================================
strategische_formate:
beschreibung: |
Strategische Formate gehen über regelmäßige Turnus-Gespräche hinaus.
Sie dienen der aktiven Digitalberatung und strategischen
Bedarfsentwicklung bei Key-Stakeholdern. Der Wertfluss ist
bidirektional: SHM berät den Kunden, gewinnt aber auch strategische
Erkenntnisse für die DIGIT-Weiterentwicklung.
formate:
# -------------------------------------------------------------------------
# SF-01: Digitalisierungs-Strategie-Workshop
# -------------------------------------------------------------------------
- id: "SF-01"
name: "Digitalisierungs-Strategie-Workshop"
zweck: |
Strukturierte Erarbeitung der Digitalisierungsperspektive eines
Key-Stakeholders. Identifikation strategischer Bedarfe, Priorisierung,
Ableitung einer gemeinsamen Roadmap.
zielgruppe:
betreuungsmodus: "Key (Proaktiv/Dediziert)"
teilnehmer_auftraggeber: |
Amtsleitung + relevante Führungskräfte/Fachexperten des Amtes
(typisch 3-6 Personen)
teilnehmer_shm: "Stakeholder-Manager, ggf. weitere DIGIT-Expertise"
anlass:
- "Initiale Strategieerarbeitung bei neuem Key-Stakeholder"
- "Periodische Aktualisierung (z.B. alle 2 Jahre)"
- "Wesentliche Veränderung beim Amt (Reorganisation, neue Aufgaben)"
frequenz:
empfehlung: "Anlassbezogen, typisch alle 1-2 Jahre"
hinweis: "Kein fester Turnus, aber proaktiv durch SHM angestoßen"
typische_inhalte:
- block: "Ist-Analyse"
beschreibung: |
Aktuelle IT-Landschaft des Amtes, genutzte Services,
bekannte Schmerzpunkte
- block: "Strategische Ziele des Amtes"
beschreibung: |
Wohin entwickelt sich das Amt? Welche Aufgaben werden wichtiger/unwichtiger?
- block: "Digitalisierungspotenziale"
beschreibung: |
Wo kann Digitalisierung unterstützen? Welche Bedarfe zeichnen sich ab?
- block: "Priorisierung und Roadmap"
beschreibung: |
Gemeinsame Bewertung der Potenziale, Ableitung priorisierter
Handlungsfelder und grober Zeitrahmen
voraussetzungen:
informationen:
- "Service-Nutzung des Amtes (aus Service-Katalog)"
- "Laufende und geplante Projekte"
- "Bekannte Bedarfe und Demands"
- "Strategische Dokumente des Amtes (falls verfügbar)"
vorbereitung:
- "Vorgespräch mit Amtsleitung zur Erwartungsklärung"
- "Analyse der Ist-Situation"
- "Workshop-Design und Methodik vorbereiten"
output:
dokumentation: |
Ergebnisdokumentation mit:
- Identifizierte Digitalisierungsbedarfe
- Priorisierte Handlungsfelder
- Roadmap-Entwurf
follow_up: |
- Konkrete Bedarfe werden in Bedarfssteckbriefe überführt
- Roadmap wird Grundlage für Turnus-Gespräche
strategie_input: |
Aggregierte Erkenntnisse zu Bedarfstrends und Entwicklungsrichtungen
fließen in DIGIT-Strategieprozess ein.
[Verweis: Strategieprozess noch nicht modelliert]
template_bedarf:
- "Workshop-Leitfaden Digitalisierungs-Strategie"
- "Canvas: Digitalisierungspotenziale"
- "Ergebnisdokumentation-Vorlage"
ressourcen_hinweis: |
Ressourcenintensives Format (Vorbereitung + Durchführung: 1-2 Personentage).
Daher nur für Key-Stakeholder und anlassbezogen.
# -------------------------------------------------------------------------
# SF-02: Bedarfs-Vertiefungs-Workshop
# -------------------------------------------------------------------------
- id: "SF-02"
name: "Bedarfs-Vertiefungs-Workshop"
zweck: |
Vertiefende Bedarfsanalyse für komplexe oder strategisch bedeutsame
Bedarfe eines Key-Stakeholders. Geht über den Bedarfssteckbrief hinaus
und erarbeitet ein fundiertes Problemverständnis.
zielgruppe:
betreuungsmodus: "Key (Proaktiv/Dediziert)"
teilnehmer_auftraggeber: |
Amtsleitung oder delegierte Entscheider + Fachexperten für
den spezifischen Bedarf
teilnehmer_shm: "Stakeholder-Manager"
anlass:
- "Komplexer Bedarf, der nicht im Turnus-Gespräch vollständig erfasst werden kann"
- "Strategisch bedeutsamer Bedarf mit hohem Investitionsvolumen"
- "Bedarf mit unklarem Problemkern (Symptom vs. Ursache)"
frequenz:
empfehlung: "Anlassbezogen"
typische_inhalte:
- block: "Problemverständnis"
beschreibung: "Was ist das eigentliche Problem? Symptome vs. Ursachen"
- block: "Kontext und Auswirkungen"
beschreibung: "Wer ist betroffen? Was sind die Konsequenzen?"
- block: "Zielbild"
beschreibung: "Wie sieht der gewünschte Zielzustand aus?"
- block: "Lösungsoptionen (grob)"
beschreibung: |
Welche Lösungsrichtungen sieht der Kunde?
(Hinweis: SHM bewertet nicht technisch, nimmt aber auf)
- block: "Nächste Schritte"
beschreibung: "Routing-Empfehlung, weitere Klärungsbedarfe"
output:
dokumentation: "Erweiterter Bedarfssteckbrief"
follow_up: "Routing an DSR (Change vs. Demand)"
template_bedarf:
- "Workshop-Leitfaden Bedarfs-Vertiefung"
- "Erweiterter Bedarfssteckbrief (Vorlage)"
abgrenzung: |
Unterscheidet sich von SF-01 durch Fokus auf einen konkreten Bedarf
statt auf die Gesamtstrategie des Amtes.
# =============================================================================
# KOLLEKTIVE FORMATE (KF)
# =============================================================================
kollektive_formate:
beschreibung: |
Kollektive Formate adressieren mehrere Stakeholder gleichzeitig.
Sie sind ressourceneffizient und ermöglichen Informationsaustausch
zwischen Ämtern.
DESIGNENTSCHEIDUNG: Die kollektiven Formate des SHM sind mit den
Auftraggeber-Vertretungen des SLM (P-02) zu einem integrierten
"Auftraggeber-Forum"-Konzept konsolidiert. Dies vermeidet Gremien-Redundanz
und stärkt die "One DIGIT"-Wahrnehmung.
governance_referenz: "GOV-SHM-015"
integriertes_auftraggeber_forum:
beschreibung: |
Das Auftraggeber-Forum ist das zentrale kollektive Interaktionsformat
zwischen DIGIT und seinen Auftraggebern. Es vereint die Funktionen der
ehemaligen SHM-Advisory-Boards und der SLM-Auftraggeber-Vertretungen.
formate:
# -----------------------------------------------------------------------
# KF-01: Auftraggeber-Forum Basisservices
# -----------------------------------------------------------------------
- id: "KF-01"
name: "Auftraggeber-Forum Basisservices"
zweck: |
Integriertes Forum für Ämter zur Abstimmung von Basis-Services
(Kategorie A), Informationsaustausch, Feedback-Sammlung und
Bedarfsidentifikation. Kombiniert SLA-Review-Funktion (SLM)
mit Beziehungspflege-Funktion (SHM).
zielgruppe:
betreuungsmodus: "Standard, Basis (primär), Aktiv (optional)"
teilnehmer_auftraggeber: |
- Pflichtvertreter: Amtsleitungen strategischer Querschnittsämter
- Weitere Vertreter: Rotation/Wahl aus Fachämtern
- Alle Teilnehmer müssen Entscheidungsbefugnis haben oder
diese dokumentiert delegiert bekommen haben
teilnehmer_digit:
- rolle: "Service Owner (Basis-Services)"
verantwortung: "SLA-bezogene Themen, Service-Performance"
- rolle: "Stakeholder-Manager"
verantwortung: "Beziehungsthemen, Feedback-Moderation, Bedarfssammlung"
- rolle: "SPM (optional)"
verantwortung: "Governance-Konformität, Portfolio-Perspektive"
frequenz:
empfehlung: "Jährlich"
hinweis: |
Die Frequenz ist im Rahmen der Pilotierung zu validieren
und zu verproben. Bei Bedarf kann auf halbjährlich erhöht werden.
referenz_annahme: "ANNAHME-EF-001"
typische_inhalte:
- block: "SLA-Review Basis-Services"
verantwortung: "Service Owner"
beschreibung: |
Performance-Bericht, Zielerreichung, geplante Änderungen
dauer_anteil: "30%"
- block: "DIGIT-Update"
verantwortung: "Stakeholder-Manager / SPM"
beschreibung: |
Strategische Entwicklungen, neue Services, Roadmap
dauer_anteil: "20%"
- block: "Feedback-Runde"
verantwortung: "Stakeholder-Manager"
beschreibung: |
Strukturierte Sammlung: Was läuft gut? Wo gibt es Probleme?
dauer_anteil: "25%"
- block: "Bedarfs-Sammlung"
verantwortung: "Stakeholder-Manager"
beschreibung: |
Gemeinsame Bedarfe? Themen für mehrere Ämter?
dauer_anteil: "15%"
- block: "Ausblick / Vereinbarungen"
verantwortung: "Gemeinsam"
beschreibung: "Nächste Schritte, offene Punkte"
dauer_anteil: "10%"
voraussetzungen:
informationen:
- "SLA-Performance-Daten der Basis-Services"
- "Service-Portfolio-Update"
- "Bekannte Probleme/Feedback"
vorbereitung:
- "Einladung mit Agenda mind. 4 Wochen vorher"
- "Möglichkeit zur Themenanmeldung durch Teilnehmer"
- "Abstimmung SO/SHM zur Agenda-Aufteilung"
output:
dokumentation: "Protokoll mit SLA-Review-Ergebnis, Feedback, Bedarfen"
follow_up:
- "SLA-Änderungen werden in SLM-Prozess überführt"
- "Feedback wird an relevante Stellen weitergeleitet (SO, SPM)"
- "Gemeinsame Bedarfe werden ggf. in Thematisches Format überführt"
governance_hinweis: |
Das Auftraggeber-Forum hat für SLA-Themen Entscheidungskompetenz
(Konsensprinzip, bei Dissens qualifizierte Mehrheit).
Für Bedarfe gilt: Beratende Funktion, Entscheidung über
etablierte Governance (SOR, DSR, MB).
template_bedarf:
- "Einladungs-Vorlage Auftraggeber-Forum"
- "Agenda-Vorlage (integriert SLA + SHM)"
- "Protokoll-Vorlage"
schnittstelle_slm: |
Das Auftraggeber-Forum erfüllt die Funktion der "Auftraggeber-Vertretung
Basisservices" gemäß P-02 Service Level Management.
Die SLA-Review-Aktivität (slm_09) wird im Rahmen des
Auftraggeber-Forums durchgeführt.
# -----------------------------------------------------------------------
# KF-02: Auftraggeber-Forum [Service] (für Kategorie B)
# -----------------------------------------------------------------------
- id: "KF-02"
name: "Auftraggeber-Forum [Servicename]"
zweck: |
Service-spezifisches Forum für Nutzer eines Kategorie-B-Services.
Primär SLA-Review und Service-Roadmap, ergänzt um Bedarfssammlung.
zielgruppe:
betreuungsmodus: "Alle nutzenden Ämter des Services"
teilnehmer_auftraggeber: |
Amtsleitungen der nutzenden Ämter oder delegierte Vertreter
mit dokumentierter Entscheidungsbefugnis
teilnehmer_digit:
- rolle: "Service Owner"
verantwortung: "Leitung, SLA-Themen, Roadmap"
- rolle: "Stakeholder-Manager (optional)"
verantwortung: "Bei Beziehungsthemen oder komplexen Bedarfen"
frequenz:
empfehlung: "Jährlich (SLA-Review) + bei Bedarf"
referenz_annahme: "ANNAHME-EF-001"
typische_inhalte:
- block: "SLA-Review"
beschreibung: "Performance, Zielerreichung, Anpassungsbedarf"
- block: "Service-Roadmap"
beschreibung: "Geplante Änderungen, Erweiterungen"
- block: "Bedarfssammlung"
beschreibung: "Wünsche, Anforderungen der Nutzer"
output:
dokumentation: "Protokoll mit SLA-Review, Roadmap-Feedback, Bedarfen"
schnittstelle_slm: |
Erfüllt die Funktion der "Auftraggeber-Vertretung [Servicename]"
gemäß P-02 Service Level Management.
shm_beteiligung: |
SHM-Beteiligung ist optional und erfolgt bei:
- Beziehungsproblemen mit nutzenden Ämtern
- Komplexen übergreifenden Bedarfen
- Key-Stakeholdern unter den Nutzern
# ---------------------------------------------------------------------------
# KF-03: Basis-Puls-Check (NEU)
# ---------------------------------------------------------------------------
basis_puls_check:
id: "KF-03"
name: "Basis-Puls-Check"
zweck: |
Minimal-invasives proaktives Format für Basis-Stakeholder, die
keine individuelle Betreuung erhalten und ggf. nicht am Auftraggeber-Forum
teilnehmen. Verhindert "Silent Churn" das unbemerkte Abdriften
von Stakeholdern ohne explizite Beschwerden.
zielgruppe:
betreuungsmodus: "Basis (Reaktiv)"
adressaten: "Alle Basis-Stakeholder, die nicht am Auftraggeber-Forum teilnehmen"
frequenz:
empfehlung: "Jährlich"
zeitpunkt: "Versetzt zum Auftraggeber-Forum (z.B. 6 Monate danach)"
referenz_annahme: "ANNAHME-EF-001"
format:
typ: "Automatisierte Kurzumfrage / strukturiertes Mailing"
aufwand_shm: "Minimal (Versand + Auswertung)"
aufwand_kunde: "5-10 Minuten"
inhalte:
- frage: "Allgemeine Zufriedenheit"
typ: "Skala 1-5"
beschreibung: "Wie zufrieden sind Sie insgesamt mit den IT-Services?"
- frage: "Größte Herausforderung"
typ: "Freitext (optional)"
beschreibung: "Was ist aktuell Ihre größte IT-bezogene Herausforderung?"
- frage: "Bedarfsmeldung"
typ: "Ja/Nein + Freitext"
beschreibung: "Gibt es Bedarfe, die Sie uns mitteilen möchten?"
- frage: "Gesprächswunsch"
typ: "Ja/Nein"
beschreibung: "Wünschen Sie ein persönliches Gespräch mit uns?"
auswertung:
verantwortung: "Stakeholder-Manager"
vorgehen:
- "Aggregierte Auswertung der Zufriedenheitswerte"
- "Identifikation von Ämtern mit niedriger Zufriedenheit"
- "Priorisierung von Gesprächswünschen"
- "Sammlung und Kategorisierung von Bedarfen"
trigger_fuer_intervention:
- bedingung: "Zufriedenheit ≤ 2"
aktion: "Proaktive Kontaktaufnahme durch SHM"
- bedingung: "Gesprächswunsch = Ja"
aktion: "Terminvereinbarung innerhalb 2 Wochen"
- bedingung: "Konkreter Bedarf genannt"
aktion: "Bedarfssteckbrief erstellen, Routing prüfen"
output:
dokumentation: "Aggregierter Puls-Check-Bericht"
berichterstattung: "Zusammenfassung im SHM-Performance-Review"
template_bedarf:
- "Puls-Check Fragebogen (digital)"
- "Auswertungs-Template"
- "Anschreiben-Vorlage"
abgrenzung: |
Der Puls-Check ersetzt keine individuelle Betreuung. Er ist ein
"Frühwarnsystem" für Basis-Stakeholder und ermöglicht es,
Probleme zu erkennen, bevor sie eskalieren.
# =============================================================================
# THEMATISCHE FORMATE (ThF)
# =============================================================================
thematische_formate:
beschreibung: |
Thematische Formate sind anlassbezogen und adressieren übergreifende
Bedarfe, die mehrere Ämter unabhängig von ihrer Cluster-Zugehörigkeit
betreffen. Sie dienen der Bedarfskonsolidierung vor DPM-Übergabe.
formate:
# -------------------------------------------------------------------------
# ThF-01: Bedarfs-Konsolidierungs-Workshop
# -------------------------------------------------------------------------
- id: "ThF-01"
name: "Bedarfs-Konsolidierungs-Workshop"
zweck: |
Zusammenführung von Ämtern mit ähnlichem Bedarf zur gemeinsamen
Bedarfsdefinition. Stellt Demand auf breitere Basis, erhöht
Priorisierungschancen und vermeidet Parallelentwicklungen.
zielgruppe:
betreuungsmodus: "Alle (bedarfsgetrieben)"
teilnehmer_auftraggeber: |
Vertreter der Ämter mit gleichem/ähnlichem Bedarf.
Typisch 3-8 Teilnehmer.
teilnehmer_shm: "Stakeholder-Manager (Moderation)"
anlass:
- "SHM erkennt gleichartigen Bedarf bei mehreren Ämtern"
- "Amt meldet Bedarf, der vermutlich auch andere betrifft"
- "Proaktive Identifikation durch Cluster-Advisory-Board"
frequenz:
empfehlung: "Anlassbezogen"
hinweis: "Wird durch SHM initiiert, wenn Konsolidierungspotenzial erkannt wird"
typische_inhalte:
- block: "Bedarfs-Vorstellung"
beschreibung: "Jedes Amt stellt seinen Bedarf/sein Problem vor"
- block: "Gemeinsamkeiten und Unterschiede"
beschreibung: "Was ist der gemeinsame Kern? Wo gibt es Spezifika?"
- block: "Konsolidierter Bedarf"
beschreibung: "Erarbeitung einer gemeinsamen Bedarfsbeschreibung"
- block: "Governance und nächste Schritte"
beschreibung: |
Wer vertritt den konsolidierten Bedarf?
Wie geht es weiter (SOR, DPM)?
output:
dokumentation: "Konsolidierter Bedarfssteckbrief"
follow_up: |
- Routing an SOR mit Hinweis auf Bedarfs-Gemeinschaft
- Benennung eines Sprechers für die Bedarfs-Gemeinschaft
template_bedarf:
- "Workshop-Leitfaden Bedarfs-Konsolidierung"
- "Bedarfssteckbrief (erweitert um Bedarfs-Gemeinschaft)"
schnittstelle_dpm: |
Der konsolidierte Bedarf wird mit Information zur Bedarfs-Gemeinschaft
an DPM übergeben. Details zur Übergabe werden in Phase 5
(D2P-Integration) spezifiziert.
# =============================================================================
# REAKTIVE FORMATE (RF) PLACEHOLDER
# =============================================================================
reaktive_formate:
beschreibung: |
Reaktive Formate regeln den Umgang mit ungeplanten Interaktionen:
Anfragen, Beschwerden, Eskalationen. Sie definieren, wann SHM
selbst reagiert, wann weitergeleitet wird, und wie eskaliert wird.
Grundprinzip: SHM agiert als "Auftraggeber-Anwalt" bei Key-Stakeholdern
bleibt SHM auch nach Weiterleitung aktiv involviert bis zur Lösung.
# ===========================================================================
# TRIAGE
# ===========================================================================
triage:
verantwortung: "Stakeholder-Manager"
beschreibung: |
Jede eingehende Eskalation wird durch den Stakeholder-Manager
initial kategorisiert (Triage). Die Kategorie bestimmt den
Eskalationspfad.
ablauf:
- schritt: 1
aktion: "Eingang erfassen"
beschreibung: "Eskalation wird dokumentiert (Absender, Thema, Dringlichkeit)"
- schritt: 2
aktion: "Stakeholder-Priorität prüfen"
beschreibung: "Key / Aktiv / Standard / Basis beeinflusst Pfad und Reaktionszeit"
- schritt: 3
aktion: "Trigger-Kategorie bestimmen"
beschreibung: "Zuordnung zu Kategorie A-E"
- schritt: 4
aktion: "Pfad einleiten"
beschreibung: "Weiterleitung oder Eigenbearbeitung gemäß Pfad-Definition"
# ===========================================================================
# TRIGGER-KATEGORIEN
# ===========================================================================
trigger_kategorien:
- id: "TRIG-A"
name: "Service-bezogene Beschwerde"
beschreibung: |
Kunde ist unzufrieden mit einem konkreten Service, meldet
wiederholte Probleme oder SLA-Verletzungen.
beispiele:
- "E-Mail-System funktioniert seit Tagen nicht richtig"
- "Zugesagte Reaktionszeit wird nie eingehalten"
- "Software XY stürzt ständig ab"
primaer_zustaendig: "Service Owner"
shm_rolle: "Weiterleitung, bei Key-Stakeholdern aktive Begleitung"
- id: "TRIG-B"
name: "Prozess-bezogene Beschwerde"
beschreibung: |
Bedarf/Demand wird nicht bearbeitet, Entscheidung ist unklar,
Prozess dauert zu lange.
beispiele:
- "Unser Demand liegt seit 6 Monaten ohne Rückmeldung"
- "Warum wurde unser Antrag abgelehnt?"
- "Niemand fühlt sich zuständig"
primaer_zustaendig: "DPM oder SPM (je nach Thema)"
shm_rolle: "Weiterleitung mit Nachverfolgung, Kundeninteresse vertreten"
- id: "TRIG-C"
name: "Beziehungs-bezogene Beschwerde"
beschreibung: |
Allgemeine Unzufriedenheit, Vertrauensverlust,
Kommunikationsprobleme, Konflikte mit DIGIT-Mitarbeitern.
beispiele:
- "Wir fühlen uns von DIGIT nicht ernst genommen"
- "Die Kommunikation ist katastrophal"
- "Mit Herrn X kann man nicht zusammenarbeiten"
primaer_zustaendig: "SHM"
shm_rolle: "Eigenbearbeitung, Mediation, Beziehungsklärung"
- id: "TRIG-D"
name: "Governance-Konflikt"
beschreibung: |
Kunde akzeptiert Gremienentscheidung nicht, Priorisierungskonflikt,
Zuständigkeitskonflikt.
beispiele:
- "Warum wurde das Amt X priorisiert und wir nicht?"
- "Die DSR-Entscheidung ist nicht nachvollziehbar"
- "Wer ist eigentlich für dieses Thema verantwortlich?"
primaer_zustaendig: "SOR / DSR / MB (je nach Thema)"
shm_rolle: "Vorbereitung Gremienweg, Kundenposition vertreten"
- id: "TRIG-E"
name: "Politische/Strategische Eskalation"
beschreibung: |
Kunde droht mit politischer Eskalation, Thema hat politische
Brisanz, Reputationsrisiko für DIGIT.
beispiele:
- "Ich werde das dem Dezernenten melden"
- "Das wird im Gemeinderat Thema werden"
- "Die Presse wird sich dafür interessieren"
primaer_zustaendig: "Mission Board"
shm_rolle: "Direkte Eskalation an MB, ggf. vorab Abstimmung mit DIGIT-Amtsleitung"
# ===========================================================================
# ESKALATIONSPFADE
# ===========================================================================
eskalationspfade:
beschreibung: |
Jede Trigger-Kategorie hat einen definierten Eskalationspfad.
Der Pfad wird durch die Stakeholder-Priorität modifiziert:
- Key-Stakeholder: Schnellerer Pfad, SHM bleibt aktiv involviert
- Andere: Standard-Pfad, SHM leitet weiter und verfolgt nach
# -------------------------------------------------------------------------
# PFAD A: Service-bezogene Beschwerde
# -------------------------------------------------------------------------
pfad_a:
trigger: "TRIG-A"
name: "Service-Eskalationspfad"
standard_ablauf:
- stufe: 1
akteur: "Service Owner"
aktion: |
SHM leitet Beschwerde an zuständigen Service Owner weiter.
SO klärt mit Kunde und behebt Problem.
eskalation_wenn: "SO kann nicht lösen oder Kunde bleibt unzufrieden"
- stufe: 2
akteur: "SPM (Funktion)"
aktion: |
SPM prüft systemische Ursachen, ggf. Service-Review.
eskalation_wenn: "Grundsätzliches Service-Problem oder Governance-Frage"
- stufe: 3
akteur: "Mission Board"
aktion: |
MB entscheidet über grundsätzliche Maßnahmen
(Service-Änderung, Ressourcen, Priorisierung).
modifikation_key_stakeholder:
beschreibung: |
Bei Key-Stakeholdern bleibt SHM aktiv involviert:
- SHM informiert SO über Stakeholder-Priorität
- SHM bleibt in Kommunikation mit Kunde (nicht nur SO)
- SHM eskaliert proaktiv, wenn Lösung nicht zeitnah erfolgt
schnellerer_pfad: |
Bei anhaltender Unzufriedenheit kann SHM direkt Stufe 2
einschalten, ohne auf SO-Rückmeldung zu warten.
# -------------------------------------------------------------------------
# PFAD B: Prozess-bezogene Beschwerde
# -------------------------------------------------------------------------
pfad_b:
trigger: "TRIG-B"
name: "Prozess-Eskalationspfad"
differenzierung:
- wenn: "Beschwerde betrifft Demand-Prozess"
dann: "Weiterleitung an DPM"
- wenn: "Beschwerde betrifft Service-Änderung/Change"
dann: "Weiterleitung an SPM / Service Owner"
- wenn: "Unklar"
dann: "SOR zur Klärung"
standard_ablauf:
- stufe: 1
akteur: "DPM oder SPM (je nach Thema)"
aktion: |
Zuständige Funktion prüft Status, klärt mit Kunde,
gibt Rückmeldung zu Zeitrahmen/Entscheidung.
eskalation_wenn: "Kunde akzeptiert Erklärung nicht oder Prozess ist blockiert"
- stufe: 2
akteur: "DSR (bei Demand) oder SOR (bei Service)"
aktion: |
Gremium prüft Priorisierung, ggf. Neubewertung.
eskalation_wenn: "Grundsätzlicher Priorisierungskonflikt"
- stufe: 3
akteur: "Mission Board"
aktion: |
MB entscheidet über Ressourcenallokation oder
grundsätzliche Prozessanpassung.
modifikation_key_stakeholder:
beschreibung: |
SHM vertritt Kundeninteresse aktiv im Prozess:
- SHM fragt proaktiv Status nach
- SHM bereitet ggf. Gremienvorlage mit vor
- SHM kommuniziert Zwischenstände an Kunde
# -------------------------------------------------------------------------
# PFAD C: Beziehungs-bezogene Beschwerde
# -------------------------------------------------------------------------
pfad_c:
trigger: "TRIG-C"
name: "Beziehungs-Eskalationspfad"
beschreibung: |
Beziehungsthemen werden primär durch SHM selbst bearbeitet.
SHM agiert als Mediator und Beziehungsmanager.
standard_ablauf:
- stufe: 1
akteur: "Stakeholder-Manager"
aktion: |
SHM führt klärendes Gespräch mit Kunde.
Ursachenanalyse: Was ist der Kern der Unzufriedenheit?
Ggf. Vermittlung zwischen Kunde und DIGIT-Mitarbeiter.
eskalation_wenn: "Konflikt nicht lösbar oder strukturelles Problem"
- stufe: 2
akteur: "SHM + DIGIT-Amtsleitung"
aktion: |
SHM stimmt sich mit DIGIT-Amtsleitung ab.
Ggf. gemeinsames Gespräch mit Kunde auf Leitungsebene.
eskalation_wenn: "Amtsleiter-Gespräch löst nicht oder strategische Dimension"
- stufe: 3
akteur: "Mission Board"
aktion: |
MB wird informiert, entscheidet über weitere Maßnahmen.
modifikation_key_stakeholder:
beschreibung: |
Bei Key-Stakeholdern höhere Aufmerksamkeit:
- Schnellere Reaktion
- Frühzeitige Einbindung DIGIT-Amtsleitung
- Proaktive Nachverfolgung der Beziehungsqualität
# -------------------------------------------------------------------------
# PFAD D: Governance-Konflikt
# -------------------------------------------------------------------------
pfad_d:
trigger: "TRIG-D"
name: "Governance-Eskalationspfad"
differenzierung:
- wenn: "Konflikt betrifft Service/Demand-Routing"
dann: "SOR"
- wenn: "Konflikt betrifft Demand-Priorisierung"
dann: "DSR"
- wenn: "Konflikt betrifft übergreifende Governance"
dann: "Mission Board"
standard_ablauf:
- stufe: 1
akteur: "Zuständiges Gremium (SOR/DSR)"
aktion: |
SHM bringt Konflikt ins zuständige Gremium ein.
Gremium prüft und entscheidet.
eskalation_wenn: "Gremium kann nicht entscheiden oder Kunde akzeptiert nicht"
- stufe: 2
akteur: "Mission Board"
aktion: |
MB als höchste Eskalationsstufe entscheidet final.
shm_rolle: |
SHM bereitet Gremienvorlage vor, vertritt Kundenperspektive
im Gremium, kommuniziert Entscheidung und Begründung an Kunden.
# -------------------------------------------------------------------------
# PFAD E: Politische/Strategische Eskalation
# -------------------------------------------------------------------------
pfad_e:
trigger: "TRIG-E"
name: "Politischer Eskalationspfad"
beschreibung: |
Bei politischer Brisanz wird direkt an höchste Ebene eskaliert.
Keine Zwischenstufen Zeit- und Reputationsrisiko zu hoch.
ablauf:
- stufe: 1
akteur: "SHM + DIGIT-Amtsleitung"
aktion: |
SHM informiert umgehend DIGIT-Amtsleitung.
Gemeinsame Lageeinschätzung: Wie ernst ist die Drohung?
Abstimmung der Reaktionsstrategie.
zeitrahmen: "Innerhalb von Stunden, nicht Tagen"
- stufe: 2
akteur: "Mission Board (ggf. ad-hoc)"
aktion: |
MB wird informiert, ggf. ad-hoc-Sitzung.
Entscheidung über Reaktion und Kommunikation.
hinweis: |
Bei politischen Eskalationen ist die Stakeholder-Priorität
sekundär die Brisanz des Themas bestimmt den Pfad.
# ===========================================================================
# REAKTIONSZEITEN (QUALITATIV)
# ===========================================================================
reaktionszeiten:
beschreibung: |
Reaktionszeiten sind qualitativ definiert und differenzieren
nach Stakeholder-Priorität und Trigger-Kategorie.
Konkrete SLA-Zeiten werden im Rahmen der Pilotierung festgelegt.
referenz_annahme: "ANNAHME-EF-001"
matrix:
- trigger: "TRIG-E (Politisch)"
stakeholder_alle:
erstreaktion: "Sofort (innerhalb Stunden)"
beschreibung: "Priorität übersteuert alle anderen Kategorien"
- trigger: "TRIG-A bis TRIG-D"
stakeholder_key:
erstreaktion: "Zeitnah (innerhalb 1 Arbeitstag)"
nachverfolgung: "Aktiv, proaktive Updates an Kunde"
beschreibung: "Höchste Priorität nach politischen Eskalationen"
stakeholder_aktiv:
erstreaktion: "Kurzfristig (innerhalb 2 Arbeitstage)"
nachverfolgung: "Regelmäßig, auf Anfrage"
beschreibung: "Priorisierte Bearbeitung"
stakeholder_standard:
erstreaktion: "Normal (innerhalb 1 Woche)"
nachverfolgung: "Nach Abschluss relevanter Schritte"
beschreibung: "Standardbearbeitung"
stakeholder_basis:
erstreaktion: "Normal (innerhalb 1 Woche)"
nachverfolgung: "Nur bei expliziter Nachfrage"
beschreibung: "Reaktive Bearbeitung"
# ===========================================================================
# SHM-ROLLENVERSTÄNDNIS BEI ESKALATIONEN
# ===========================================================================
shm_rollenverstaendnis:
grundprinzip: "Auftraggeber-Anwalt"
beschreibung: |
SHM agiert bei Eskalationen als "Anwalt des Auftraggebers" nicht als
neutraler Vermittler, sondern als Vertreter der Auftraggeber-Perspektive
innerhalb von DIGIT. Dabei bleibt SHM sachlich und lösungsorientiert.
differenzierung_nach_prioritaet:
key_stakeholder:
involvierung: "Aktiv durchgängig"
beschreibung: |
SHM bleibt bis zur Lösung aktiv involviert, auch wenn
das Thema an andere Funktionen weitergeleitet wurde.
SHM kommuniziert proaktiv mit dem Auftraggeber.
aktiv_stakeholder:
involvierung: "Begleitend"
beschreibung: |
SHM leitet weiter, verfolgt nach und ist Ansprechpartner
für den Kunden bei Rückfragen.
standard_basis_stakeholder:
involvierung: "Punktuell"
beschreibung: |
SHM leitet weiter und dokumentiert. Weitere Involvierung
nur bei expliziter Kundenanfrage oder wenn Thema eskaliert.
grenzen:
- |
SHM vertritt Kundenperspektive, aber akzeptiert Gremienentscheidungen.
SHM erklärt dem Auftraggeber die Entscheidung, auch wenn sie nicht im
Kundensinne ist.
- |
SHM übernimmt keine operative Problemlösung (das ist SO/Service Desk).
SHM sorgt dafür, dass das Problem an der richtigen Stelle bearbeitet wird.
# ===========================================================================
# DOKUMENTATION UND NACHVERFOLGUNG
# ===========================================================================
dokumentation:
beschreibung: |
Jede Eskalation wird dokumentiert, um Nachverfolgung zu ermöglichen
und Muster zu erkennen.
zu_dokumentieren:
- "Datum und Eingangskanal"
- "Absender (Amt, Person)"
- "Stakeholder-Priorität"
- "Trigger-Kategorie"
- "Kurzbeschreibung des Themas"
- "Eingeleiteter Pfad"
- "Status und Verlauf"
- "Abschluss und Ergebnis"
ablageort: "SIMS (Stakeholder-Informations-Management-System)"
auswertung: |
Aggregierte Auswertung der Eskalationen (Häufigkeit, Kategorien,
Durchlaufzeiten) fließt in die Koordinations- und Steuerungsstruktur
(shm_koordinations-und-steuerungsstruktur.yaml) ein.
# =============================================================================
# FREQUENZ-MATRIX: BETREUUNGSMODUS → FORMATE
# =============================================================================
frequenz_matrix:
beschreibung: |
Übersicht, welche Formate für welchen Betreuungsmodus vorgesehen sind
und in welcher Frequenz.
referenz_annahme: "ANNAHME-EF-001"
matrix:
- betreuungsmodus: "Key (Proaktiv/Dediziert)"
turnus_formate:
- format: "TF-01 Strategisches Turnus-Gespräch"
frequenz: "Quartalsweise"
strategische_formate:
- format: "SF-01 Digitalisierungs-Strategie-Workshop"
frequenz: "Alle 1-2 Jahre (anlassbezogen)"
- format: "SF-02 Bedarfs-Vertiefungs-Workshop"
frequenz: "Anlassbezogen"
kollektive_formate:
- format: "KF-01 Auftraggeber-Forum Basisservices"
frequenz: "Optional (primär für Standard/Basis)"
- format: "KF-02 Auftraggeber-Forum [Service]"
frequenz: "Bei Nutzung von Kat-B-Services"
thematische_formate:
- format: "ThF-01 Bedarfs-Konsolidierungs-Workshop"
frequenz: "Anlassbezogen"
reaktive_formate: "Ja (Details s. RF)"
- betreuungsmodus: "Aktiv (Regelmäßig)"
turnus_formate:
- format: "TF-02 Operatives Turnus-Gespräch"
frequenz: "Halbjährlich"
strategische_formate: "Nicht vorgesehen (bei Bedarf Upgrade auf Key prüfen)"
kollektive_formate:
- format: "KF-01 Auftraggeber-Forum Basisservices"
frequenz: "Optional, zusätzlich zu Turnus"
- format: "KF-02 Auftraggeber-Forum [Service]"
frequenz: "Bei Nutzung von Kat-B-Services"
thematische_formate:
- format: "ThF-01 Bedarfs-Konsolidierungs-Workshop"
frequenz: "Anlassbezogen"
reaktive_formate: "Ja (Details s. RF)"
- betreuungsmodus: "Standard (Eingebunden)"
turnus_formate: "Nicht vorgesehen"
strategische_formate: "Nicht vorgesehen"
kollektive_formate:
- format: "KF-01 Auftraggeber-Forum Basisservices"
frequenz: "Jährlich"
thematische_formate:
- format: "ThF-01 Bedarfs-Konsolidierungs-Workshop"
frequenz: "Anlassbezogen"
proaktive_formate:
- format: "KF-03 Basis-Puls-Check"
frequenz: "Nicht vorgesehen (Puls-Check nur für Basis)"
reaktive_formate: "Ja (Details s. RF)"
- betreuungsmodus: "Basis (Reaktiv)"
turnus_formate: "Nicht vorgesehen"
strategische_formate: "Nicht vorgesehen"
kollektive_formate:
- format: "KF-01 Auftraggeber-Forum Basisservices"
frequenz: "Jährlich (Einladung, Teilnahme optional)"
thematische_formate:
- format: "ThF-01 Bedarfs-Konsolidierungs-Workshop"
frequenz: "Anlassbezogen (wenn Bedarf erkannt)"
proaktive_formate:
- format: "KF-03 Basis-Puls-Check"
frequenz: "Jährlich"
reaktive_formate: "Ja (Details s. RF)"
# =============================================================================
# BEZIEHUNGSQUALITÄTSSICHERUNG
# =============================================================================
beziehungsqualitaetssicherung:
beschreibung: |
Die Beziehungsqualitätssicherung ermöglicht die systematische Erfassung
und Bewertung der Kundenbeziehungen sowie die frühzeitige Erkennung
von Problemen. Sie unterstützt die Kernentscheidung EF-E3:
"Woran erkenne ich Beziehungsprobleme, wann interveniere ich?"
grundprinzip: |
SHM gibt eine Einschätzung für alle Ämter im Portfolio nicht nur
für aktiv betreute. Die Erfassungstiefe und -frequenz variiert
nach Betreuungsmodus.
# ===========================================================================
# BEWERTUNGSSKALA
# ===========================================================================
bewertungsskala:
beschreibung: |
Die Beziehungsqualität wird auf einer 4-Stufen-Skala bewertet.
Die Stufen sind qualitativ definiert und ermöglichen eine
differenzierte Einschätzung ohne Pseudo-Präzision.
stufen:
- stufe: "Exzellent"
kuerzel: "EX"
beschreibung: |
Vertrauensvolle, partnerschaftliche Beziehung. Kunde ist
sehr zufrieden, kommuniziert offen, bringt sich aktiv ein.
Keine offenen Konflikte oder Irritationen.
indikatoren:
- "Kunde äußert aktiv Zufriedenheit"
- "Konstruktive, offene Kommunikation"
- "Kunde empfiehlt DIGIT-Leistungen weiter"
- "Proaktive Beteiligung an Formaten"
- stufe: "Gut"
kuerzel: "GU"
beschreibung: |
Stabile, funktionale Beziehung. Kunde ist grundsätzlich
zufrieden, Zusammenarbeit läuft ohne größere Probleme.
Punktuelle Kritik wird konstruktiv geäußert.
indikatoren:
- "Regelkommunikation funktioniert"
- "Kritik wird sachlich vorgebracht"
- "Termine werden eingehalten"
- "Keine Eskalationen"
- stufe: "Angespannt"
kuerzel: "AN"
beschreibung: |
Beziehung zeigt Belastungszeichen. Kunde äußert Unzufriedenheit,
Kommunikation ist erschwert, es gibt offene Themen oder
ungelöste Konflikte. Intervention empfohlen.
indikatoren:
- "Wiederholte Kritik oder Beschwerden"
- "Kommunikation wird förmlicher oder distanzierter"
- "Termine werden verschoben oder abgesagt"
- "Offene Konflikte oder ungelöste Themen"
- stufe: "Kritisch"
kuerzel: "KR"
beschreibung: |
Beziehung ist ernsthaft gefährdet. Massiver Vertrauensverlust,
Kommunikationsabbruch, Eskalationsdrohungen.
Sofortige Intervention erforderlich.
indikatoren:
- "Kunde verweigert Kommunikation oder Kooperation"
- "Eskalation an höhere Ebenen (Dezernent, Politik)"
- "Öffentliche Kritik oder Beschwerden"
- "Grundsätzliche Infragestellung der Zusammenarbeit"
# ===========================================================================
# INDIKATOR-KATEGORIEN
# ===========================================================================
indikator_kategorien:
beschreibung: |
Die Bewertung der Beziehungsqualität speist sich aus drei
Indikator-Kategorien, die je nach Betreuungsmodus unterschiedlich
gewichtet werden.
kategorien:
- id: "IND-1"
name: "Direkte Einschätzung"
typ: "Subjektiv, durch SHM"
beschreibung: |
Der Stakeholder-Manager schätzt die Beziehungsqualität auf
Basis seiner Interaktionen und Wahrnehmungen ein.
basis:
- "Gesprächseindrücke (Tonalität, Offenheit)"
- "Kooperationsbereitschaft"
- "Allgemeine Stimmung in der Zusammenarbeit"
anwendung: "Alle Betreuungsmodi"
erfassung: "Nach Interaktionen, mindestens jährlich"
- id: "IND-2"
name: "Interaktions-Signale"
typ: "Beobachtbar, prozessbasiert"
beschreibung: |
Objektiv beobachtbare Signale aus den Interaktionen und
Prozessen, die auf Beziehungsqualität hinweisen.
signale:
- signal: "Eskalationen"
positiv: "Keine Eskalationen"
negativ: "Häufige oder wiederkehrende Eskalationen"
- signal: "Beschwerden"
positiv: "Keine oder konstruktive Kritik"
negativ: "Beziehungs-bezogene Beschwerden (TRIG-C)"
- signal: "Teilnahme"
positiv: "Regelmäßige Teilnahme an Formaten"
negativ: "Wiederholtes Absagen oder Fernbleiben"
- signal: "Reaktionsverhalten"
positiv: "Zeitnahe Antworten, Termintreue"
negativ: "Keine Reaktion, verschobene Termine"
anwendung: "Alle Betreuungsmodi (soweit Daten anfallen)"
erfassung: "Kontinuierlich, bei Auftreten"
- id: "IND-3"
name: "Strukturiertes Feedback"
typ: "Explizit erhoben"
beschreibung: |
Gezielte Abfrage der Kundenzufriedenheit und
Beziehungswahrnehmung beim Kunden selbst.
methoden:
- "Zufriedenheits-Check im Turnus-Gespräch"
- "Strukturierte Feedback-Fragen"
- "Ggf. kurze schriftliche Abfrage"
anwendung: "Key-Stakeholder"
erfassung: "Jährlich (im Rahmen eines Turnus-Gesprächs)"
# ===========================================================================
# ERFASSUNG NACH BETREUUNGSMODUS
# ===========================================================================
erfassung_nach_betreuungsmodus:
beschreibung: |
Die Erfassungstiefe und -frequenz variiert nach Betreuungsmodus.
Für alle Ämter wird mindestens jährlich eine Einschätzung abgegeben.
matrix:
- betreuungsmodus: "Key (Proaktiv/Dediziert)"
indikator_kategorien:
- kategorie: "IND-1 (Direkte Einschätzung)"
anwendung: "Ja"
frequenz: "Nach jedem Turnus-Gespräch (quartalsweise)"
- kategorie: "IND-2 (Interaktions-Signale)"
anwendung: "Ja"
frequenz: "Kontinuierlich, systematische Auswertung"
- kategorie: "IND-3 (Strukturiertes Feedback)"
anwendung: "Ja"
frequenz: "Jährlich"
gesamtbewertung: "Quartalsweise aktualisiert"
trigger_sensitivitaet: "Hoch niedrige Schwellen"
- betreuungsmodus: "Aktiv (Regelmäßig)"
indikator_kategorien:
- kategorie: "IND-1 (Direkte Einschätzung)"
anwendung: "Ja"
frequenz: "Nach jedem Turnus-Gespräch (halbjährlich)"
- kategorie: "IND-2 (Interaktions-Signale)"
anwendung: "Ja"
frequenz: "Kontinuierlich, bei Auftreten"
- kategorie: "IND-3 (Strukturiertes Feedback)"
anwendung: "Optional"
frequenz: "Bei Bedarf"
gesamtbewertung: "Halbjährlich aktualisiert"
trigger_sensitivitaet: "Mittel"
- betreuungsmodus: "Standard (Eingebunden)"
indikator_kategorien:
- kategorie: "IND-1 (Direkte Einschätzung)"
anwendung: "Ja"
frequenz: "Nach Advisory Board oder bei Kontakt, mind. jährlich"
- kategorie: "IND-2 (Interaktions-Signale)"
anwendung: "Ja, soweit Daten anfallen"
frequenz: "Bei Auftreten"
- kategorie: "IND-3 (Strukturiertes Feedback)"
anwendung: "Nein"
frequenz: ""
gesamtbewertung: "Jährlich aktualisiert"
trigger_sensitivitaet: "Normal"
- betreuungsmodus: "Basis (Reaktiv)"
indikator_kategorien:
- kategorie: "IND-1 (Direkte Einschätzung)"
anwendung: "Ja"
frequenz: "Bei Kontakt, mind. jährlich (Schätzung)"
- kategorie: "IND-2 (Interaktions-Signale)"
anwendung: "Ja, soweit Daten anfallen"
frequenz: "Bei Auftreten"
- kategorie: "IND-3 (Strukturiertes Feedback)"
anwendung: "Nein"
frequenz: ""
gesamtbewertung: "Jährlich aktualisiert"
trigger_sensitivitaet: "Nur bei expliziten Signalen"
# ===========================================================================
# INTERVENTIONS-TRIGGER
# ===========================================================================
interventions_trigger:
beschreibung: |
Interventions-Trigger sind definierte Schwellen oder Muster,
die eine proaktive Intervention durch SHM auslösen.
Die Trigger-Sensitivität variiert nach Betreuungsmodus.
trigger:
- id: "INTTRIG-01"
name: "Bewertungsverschlechterung"
beschreibung: |
Die SHM-Einschätzung der Beziehungsqualität verschlechtert
sich um mindestens eine Stufe.
schwelle:
key_stakeholder: "Jede Verschlechterung"
aktiv_stakeholder: "Jede Verschlechterung"
standard_basis: "Verschlechterung auf 'Angespannt' oder 'Kritisch'"
intervention: "Klärungsgespräch"
- id: "INTTRIG-02"
name: "Kritische Bewertung"
beschreibung: |
Die Beziehungsqualität wird als 'Kritisch' eingestuft.
schwelle: "Alle Betreuungsmodi"
intervention: "Sofortige Intervention (Klärungsgespräch mit Amtsleitung)"
- id: "INTTRIG-03"
name: "Beziehungs-Beschwerde"
beschreibung: |
Eine Beschwerde der Kategorie TRIG-C (Beziehungs-bezogen)
geht ein.
schwelle: "Alle Betreuungsmodi jede Beschwerde ist ein Trigger"
intervention: "Klärungsgespräch"
verweis: "Eskalationspfad C"
- id: "INTTRIG-04"
name: "Eskalationshäufung"
beschreibung: |
Mehrere Eskalationen (beliebiger Kategorie) innerhalb
eines definierten Zeitraums.
schwelle:
key_stakeholder: "2+ Eskalationen in 6 Monaten"
aktiv_stakeholder: "3+ Eskalationen in 12 Monaten"
standard_basis: "3+ Eskalationen in 12 Monaten"
intervention: "Klärungsgespräch, Ursachenanalyse"
- id: "INTTRIG-05"
name: "Teilnahme-Rückzug"
beschreibung: |
Kunde sagt wiederholt Termine ab oder erscheint nicht
zu vereinbarten Formaten.
schwelle:
key_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows"
aktiv_stakeholder: "2 aufeinanderfolgende Absagen/No-Shows"
standard_basis: "Nicht anwendbar (keine festen Termine)"
intervention: "Telefonische Nachfrage, ggf. Klärungsgespräch"
- id: "INTTRIG-06"
name: "Kommunikationsabbruch"
beschreibung: |
Kunde reagiert nicht mehr auf Kontaktversuche.
schwelle:
key_stakeholder: "Keine Reaktion auf 2 Kontaktversuche"
aktiv_stakeholder: "Keine Reaktion auf 3 Kontaktversuche"
standard_basis: "Keine Reaktion auf 3 Kontaktversuche"
intervention: "Eskalation an Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung einbinden"
# ===========================================================================
# INTERVENTIONS-REPERTOIRE
# ===========================================================================
interventions_repertoire:
beschreibung: |
Bei Auslösung eines Interventions-Triggers stehen folgende
Interventionen zur Verfügung. Die Wahl der Intervention
richtet sich nach Schwere und Kontext.
interventionen:
- id: "INTV-01"
name: "Klärungsgespräch"
beschreibung: |
Persönliches Gespräch zwischen SHM und Kundenvertreter
zur Klärung der Situation und Ursachenanalyse.
ziel: "Verständnis der Ursachen, Wiederherstellung des Dialogs"
teilnehmer: "SHM + Kundenvertreter (operative Ebene)"
eskalation_zu: "Klärungsgespräch mit Amtsleitung"
typische_trigger: ["INTTRIG-01", "INTTRIG-03", "INTTRIG-04", "INTTRIG-05"]
- id: "INTV-02"
name: "Klärungsgespräch mit Amtsleitung"
beschreibung: |
Gespräch auf Leitungsebene, wenn operative Klärung nicht
ausreicht oder die Beziehung kritisch ist.
ziel: "Verbindliche Klärung auf Entscheidungsebene"
teilnehmer: "SHM + Amtsleitung (Kunde), ggf. DIGIT-Amtsleitung"
voraussetzung: |
Operative Klärung war nicht erfolgreich ODER
Bewertung ist 'Kritisch' ODER
Thema erfordert Leitungsentscheidung
typische_trigger: ["INTTRIG-02", "INTTRIG-06"]
- id: "INTV-03"
name: "Maßnahmenplan"
beschreibung: |
Strukturierter Plan mit konkreten Maßnahmen zur
Verbesserung der Beziehungsqualität.
ziel: "Nachvollziehbare, terminierte Maßnahmen mit Verantwortlichkeiten"
inhalt:
- "Identifizierte Ursachen"
- "Vereinbarte Maßnahmen"
- "Verantwortlichkeiten (DIGIT-seitig und Kunden-seitig)"
- "Termine / Meilensteine"
- "Review-Termin"
typische_massnahmen:
- "Erhöhte Kontaktfrequenz"
- "Dedizierter Ansprechpartner für offene Themen"
- "Priorisierung offener Bedarfe/Tickets"
- "Regelmäßige Status-Updates"
- "Gemeinsamer Workshop zur Neuausrichtung"
anwendung: |
Bei 'Angespannt' oder 'Kritisch', wenn einzelnes
Klärungsgespräch nicht ausreicht.
eskalation_bei_misserfolg: |
Wenn Interventionen nicht zur Verbesserung führen, wird das
Thema ins Mission Board eingebracht (analog Eskalationspfad C, Stufe 3).
# ===========================================================================
# DOKUMENTATION
# ===========================================================================
dokumentation:
beschreibung: |
Die Beziehungsqualität wird im Amts-Steckbrief (SIMS) dokumentiert
und historisch nachvollziehbar geführt.
zu_dokumentieren:
- attribut: "beziehungsqualitaet_aktuell"
beschreibung: "Aktuelle Bewertung (EX/GU/AN/KR)"
aktualisierung: "Gemäß Erfassungsfrequenz"
- attribut: "beziehungsqualitaet_historie"
beschreibung: "Verlauf der Bewertungen mit Datum"
zweck: "Trends erkennen"
- attribut: "interventionen"
beschreibung: "Durchgeführte Interventionen mit Datum und Ergebnis"
zweck: "Nachvollziehbarkeit, Lernen"
- attribut: "massnahmenplan"
beschreibung: "Aktiver Maßnahmenplan (falls vorhanden)"
zweck: "Nachverfolgung"
ablageort: "SIMS (Stakeholder-Informations-Management-System)"
verweis_schema: |
Attribute sind im shm_schema_amtssteckbrief.yaml zu ergänzen
(Kategorie: Betreuung).
# ===========================================================================
# REVIEW UND REPORTING
# ===========================================================================
review_und_reporting:
beschreibung: |
Die aggregierten Beziehungsqualitätsdaten fließen in die
Koordinations- und Steuerungsstruktur
(shm_koordinations-und-steuerungsstruktur.yaml) ein.
aggregierte_auswertungen:
- "Verteilung der Bewertungen über alle Stakeholder"
- "Veränderungen gegenüber Vorperiode"
- "Anzahl aktiver Interventionen/Maßnahmenpläne"
- "Korrelation mit Eskalationshäufigkeit"
berichtsrhythmus: "Quartalsweise (für Management-Reporting)"
strategischer_input: |
Systematische Beziehungsprobleme (z.B. häufige Kritik an
bestimmten Services oder Prozessen) werden als Input für
DIGIT-Strategieprozess aufbereitet.
[Verweis: Strategieprozess noch nicht modelliert]
# =============================================================================
# TEMPLATE-BEDARFE (Übersicht für Phase 11)
# =============================================================================
template_bedarfe:
beschreibung: |
Übersicht der identifizierten Template-Bedarfe.
Ausarbeitung erfolgt in Phase 11 (Arbeitsmaterialien).
templates:
- id: "TPL-EF-01"
name: "Agenda-Vorlage Strategisches Turnus-Gespräch"
format_referenz: "TF-01"
- id: "TPL-EF-02"
name: "Protokoll-Vorlage Turnus-Gespräch"
format_referenz: "TF-01, TF-02"
- id: "TPL-EF-03"
name: "Agenda-Vorlage Operatives Turnus-Gespräch"
format_referenz: "TF-02"
- id: "TPL-EF-04"
name: "Workshop-Leitfaden Digitalisierungs-Strategie"
format_referenz: "SF-01"
- id: "TPL-EF-05"
name: "Canvas: Digitalisierungspotenziale"
format_referenz: "SF-01"
- id: "TPL-EF-06"
name: "Ergebnisdokumentation Strategie-Workshop"
format_referenz: "SF-01"
- id: "TPL-EF-07"
name: "Workshop-Leitfaden Bedarfs-Vertiefung"
format_referenz: "SF-02"
- id: "TPL-EF-08"
name: "Erweiterter Bedarfssteckbrief"
format_referenz: "SF-02"
- id: "TPL-EF-09"
name: "Einladungs-Vorlage Advisory Board"
format_referenz: "KF-01"
- id: "TPL-EF-10"
name: "Agenda-Vorlage Advisory Board"
format_referenz: "KF-01"
- id: "TPL-EF-11"
name: "Protokoll-Vorlage Advisory Board"
format_referenz: "KF-01"
- id: "TPL-EF-12"
name: "Workshop-Leitfaden Bedarfs-Konsolidierung"
format_referenz: "ThF-01"
- id: "TPL-EF-13"
name: "Eskalations-Erfassungsbogen"
beschreibung: "Strukturierte Erfassung eingehender Eskalationen"
- id: "TPL-EF-14"
name: "Eskalations-Statusbericht"
beschreibung: "Vorlage für Statusupdates bei laufenden Eskalationen"
- id: "TPL-EF-15"
name: "Gremienvorlage Eskalation"
beschreibung: "Vorlage für Eskalationen an SOR/DSR/MB"
- id: "TPL-EF-16"
name: "Feedback-Fragen Key-Stakeholder"
beschreibung: "Strukturierte Fragen für jährliches Feedback-Gespräch"
- id: "TPL-EF-17"
name: "Maßnahmenplan Beziehungsqualität"
beschreibung: "Vorlage für strukturierten Maßnahmenplan"
- id: "TPL-EF-18"
name: "Interventions-Dokumentation"
beschreibung: "Vorlage zur Dokumentation durchgeführter Interventionen"
- id: "TPL-EF-19"
name: "Einladungs-Vorlage Auftraggeber-Forum"
format_referenz: "KF-01"
- id: "TPL-EF-20"
name: "Agenda-Vorlage Auftraggeber-Forum (integriert)"
format_referenz: "KF-01"
beschreibung: "Kombinierte Agenda für SLA-Review und SHM-Themen"
- id: "TPL-EF-21"
name: "Protokoll-Vorlage Auftraggeber-Forum"
format_referenz: "KF-01"
- id: "TPL-EF-22"
name: "Basis-Puls-Check Fragebogen"
format_referenz: "KF-03"
- id: "TPL-EF-23"
name: "Basis-Puls-Check Auswertungs-Template"
format_referenz: "KF-03"
- id: "TPL-EF-24"
name: "Basis-Puls-Check Anschreiben"
format_referenz: "KF-03"
# =============================================================================
# OFFENE PUNKTE
# =============================================================================
offene_punkte:
- id: "OPEN-EF-003"
thema: "Ressourcen-Implikationen"
beschreibung: |
Die Formate haben unterschiedlichen Ressourcenbedarf.
Eine Überschlagsrechnung (wie viele Key-Stakeholder kann ein
Stakeholder-Manager betreuen?) fehlt noch.
prioritaet: "niedrig"
naechster_schritt: "Nach Pilotierung evaluieren"
# =============================================================================
# ÄNDERUNGSHISTORIE
# =============================================================================
aenderungshistorie:
- version: "0.1"
datum: "2025-12-09"
autor: "Chat-Session Phase 2"
aenderung: "Initiale Erstellung als Arbeitsstand"
- version: "0.2"
datum: "2025-12-09"
autor: "Chat-Session Phase 2"
aenderung: "Eskalationslogik in reaktive Formate integriert"
- version: "0.3"
datum: "2025-12-09"
autor: "Chat-Session Phase 2"
aenderung: "Beziehungsqualitätssicherung als neuer Abschnitt ergänzt"
- version: "0.4"
datum: "2025-12-09"
autor: "Review-Feedback Integration"
aenderung: |
- Kollektive Formate: Integration mit SLM-Auftraggeber-Vertretungen
zu einheitlichem Auftraggeber-Forum-Konzept
- Frequenz Auftraggeber-Forum auf jährlich angepasst (Pilotierungs-Vorbehalt)
- Neues Format KF-03 "Basis-Puls-Check" für Basis-Stakeholder
- Template-Bedarfe ergänzt
- version: "0.5"
datum: "2025-12-10"
autor: "Cross-Check Phase 5"
aenderung: |
- Veraltete Phase-7-Referenzen aktualisiert auf
shm_koordinations-und-steuerungsstruktur.yaml
- VoC-Schnittstelle in Meta-Sektion ergänzt
- Querverweise zu Koordinations- und Steuerungsstruktur harmonisiert