# ============================================================================= # 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