digitom_cc/#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml
2026-03-23 22:28:45 +01:00

1071 lines
No EOL
38 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 VOICE OF CUSTOMER (VoC) - KONZEPT
# =============================================================================
# Modul: Stakeholder-Management (SHM)
# Typ: Konzept
# Version: 1.0
# Datum: 2025-12-10
# Status: Final (Phase 5)
# =============================================================================
meta:
modul_id: "SHM-K-04"
name: "Voice of Customer"
typ: "Konzept"
zweck: |
Das Voice-of-Customer-Konzept (VoC) systematisiert die Erfassung,
Verarbeitung und Nutzung von Stakeholder-Feedback innerhalb der
SHM-Funktion. Es macht die Stakeholder-Stimme als zentralen
Erfolgsindikator nutzbar.
VoC ist kein isoliertes Erfassungssystem, sondern integraler
Bestandteil der SHM Koordinations- und Steuerungsstruktur.
itil4_referenz:
konzept: "Voice of Customer"
quelle: "ITIL 4 Drive Stakeholder Value (DSV)"
adaption: |
Das ITIL4-VoC-Konzept wurde für den kommunalen Verwaltungskontext
adaptiert. Insbesondere die Unterscheidung Customer/User wurde
auf die DIGIT-Stakeholder-Landschaft übertragen.
entwicklungsprinzip: |
Das VoC-Konzept folgt dem Prinzip "Start simple, dann nachziehen":
Die Erfassung wird so niedrigschwellig wie möglich gestaltet.
Komplexität wird nur dort ergänzt, wo sich in der Praxis zeigt,
dass sie notwendig ist.
governance_referenzen:
- id: "GOV-SHM-023"
thema: "Fokus auf Ergebnis-Indikatoren"
- id: "GOV-SHM-024"
thema: "Abgrenzung SHM/SPM im Reporting"
konzept_referenzen:
- dokument: "shm_koordinations-und-steuerungsstruktur.yaml"
beschreibung: "Integration in Review-Struktur (REV-1, REV-2, REV-3)"
- dokument: "shm_engagement-framework.yaml"
beschreibung: "Feedback-Quellen (Turnus-Gespräche, Auftraggeber-Forum)"
- dokument: "shm_stakeholder-portfolio.yaml"
beschreibung: "Beziehungsqualität als VoC-Indikator"
# =============================================================================
# ZWECK UND FUNKTION
# =============================================================================
zweck_und_funktion:
beschreibung: |
VoC erfüllt drei primäre Funktionen für SHM. Die Reihenfolge
reflektiert die Priorität: Steuerung und Lernen stehen vor
Legitimation.
primaere_funktionen:
- id: "VOC-F-01"
name: "Steuerung"
beschreibung: |
VoC liefert Signale für Handlungsbedarf. Wenn Stakeholder
unzufrieden sind oder Probleme melden, muss SHM reagieren.
VoC ermöglicht proaktives Handeln statt reaktiver Krisenbewältigung.
leitfrage: "Wo müssen wir nachsteuern?"
output: "Interventionsbedarf, Maßnahmenableitung"
- id: "VOC-F-02"
name: "Lernen"
beschreibung: |
VoC hilft zu verstehen, was Stakeholder brauchen, wie sie
DIGIT wahrnehmen und wo Erwartungslücken bestehen. Dieses
Verständnis verbessert die Betreuungsqualität kontinuierlich.
leitfrage: "Was lernen wir über unsere Stakeholder?"
output: "Muster, Erkenntnisse, Anpassungsbedarf"
- id: "VOC-F-03"
name: "Strategie-Input"
beschreibung: |
SHM fungiert als "Ohr an der Kundschaft" für DIGIT. Aggregierte
VoC-Erkenntnisse fließen in die strategische Planung ein und
helfen, das DIGIT-Angebot an den Bedürfnissen auszurichten.
leitfrage: "Was sagt uns das über die Gesamtentwicklung?"
output: "Strategische Impulse, Priorisierungs-Input"
nachgelagerte_funktion:
- id: "VOC-F-04"
name: "Legitimation"
beschreibung: |
VoC kann auch zur Rechtfertigung des SHM-Aufwands dienen
("Die Stakeholder bestätigen den Wert der Betreuung").
Dies ist ein Nebeneffekt, nicht der Hauptzweck.
leitfrage: "Können wir zeigen, dass SHM wirkt?"
output: "Erfolgsnachweise für E1-Review"
anmerkung: |
Bewusst nachgelagert, um zu vermeiden, dass VoC zur
Rechtfertigungs-Übung wird.
# =============================================================================
# VERANTWORTUNGSABGRENZUNG: CUSTOMER VS. USER
# =============================================================================
verantwortungsabgrenzung:
grundsatz: |
SHM verantwortet die Customer-Stimme (Amtsleitungen, SLA-Partner).
Die User-Stimme wird durch Support/Service Desk erfasst und
steht SHM als Kontext-Information zur Verfügung.
customer_stimme:
definition: |
Feedback von Entscheidern, die Services beauftragen und
strategische Bedarfe formulieren (SLA-Partner, Amtsleitungen,
IT-Koordinatoren mit Entscheidungsbefugnis).
verantwortung: "SHM"
primaere_kanaele:
- "Turnus-Gespräche (TF-01, TF-02)"
- "Auftraggeber-Forum Basisservices (KF-01)"
- "SLA-Reviews (slm_09)"
- "Strategische Formate"
charakteristik: |
Customer-Feedback ist typischerweise strategischer,
beziehungsorientierter und weniger transaktional als
User-Feedback.
user_stimme:
definition: |
Feedback von Endanwendern, die Services täglich nutzen
(Sachbearbeiter, Mitarbeitende in den Ämtern).
verantwortung: "Support / Service Desk"
nutzung_durch_shm: |
Als Kontext-Information, nicht als Primärquelle.
User-Feedback kann Hinweise auf Service-Probleme geben,
die die Beziehungsqualität belasten.
primaere_kanaele:
- "Service Desk Tickets"
- "Zufriedenheitsabfragen nach Incidents"
- "Self-Service-Bewertungen"
status: "Bestätigt"
datum: "2025-12-10"
# =============================================================================
# FEEDBACK-DIMENSIONEN
# =============================================================================
feedback_dimensionen:
beschreibung: |
VoC unterscheidet vier inhaltliche Dimensionen, die unterschiedliche
Aspekte der Stakeholder-Wahrnehmung erfassen. Die Dimensionen sind
trennscharf, können aber im Einzelfall zusammenhängen.
dimensionen:
# -------------------------------------------------------------------------
# D1: BEZIEHUNGSQUALITÄT
# -------------------------------------------------------------------------
- id: "D1"
name: "Beziehungsqualität"
kernfrage: "Wie wird die Zusammenarbeit mit SHM/DIGIT wahrgenommen?"
beispiel_aussagen:
positiv:
- "Wir fühlen uns gut betreut"
- "DIGIT versteht unsere Situation"
- "Die Kommunikation ist offen und ehrlich"
negativ:
- "Die Kommunikation ist schwierig"
- "Wir werden nicht ernst genommen"
- "Absprachen werden nicht eingehalten"
shm_verantwortung: "Direkt"
anmerkung: |
Kernauftrag von SHM. Hier liegt die unmittelbare
Einflussmöglichkeit und Verantwortung.
cluster_referenz: "cluster_d1_beziehungsqualitaet"
# -------------------------------------------------------------------------
# D2: SERVICE-QUALITÄT
# -------------------------------------------------------------------------
- id: "D2"
name: "Service-Qualität"
kernfrage: "Wie werden die IT-Services bewertet?"
beispiel_aussagen:
positiv:
- "Das System läuft stabil"
- "Der Support reagiert schnell"
- "Die Performance hat sich verbessert"
negativ:
- "Die Performance ist schlecht"
- "Häufige Ausfälle"
- "Der Support ist nicht erreichbar"
shm_verantwortung: "Indirekt (Kontext)"
anmerkung: |
Primär SPM/Service Owner-Verantwortung. SHM erfasst
D2-Feedback als Kontext, berichtet es aber nicht
eigenständig, sondern leitet es weiter.
weiterleitung_an: "SPM / Service Owner"
cluster_referenz: "cluster_d2_servicequalitaet"
# -------------------------------------------------------------------------
# D3: BEDARFSERFÜLLUNG
# -------------------------------------------------------------------------
- id: "D3"
name: "Bedarfserfüllung"
kernfrage: "Werden die Anforderungen des Amtes erfüllt?"
beispiel_aussagen:
positiv:
- "Unsere Digitalisierungsprojekte kommen voran"
- "Unsere Prioritäten werden berücksichtigt"
- "Wir bekommen zeitnah Rückmeldung"
negativ:
- "Wir warten seit Monaten auf Rückmeldung"
- "Unsere Anforderungen verschwinden im Nichts"
- "Andere werden bevorzugt"
shm_verantwortung: "Geteilt"
anmerkung: |
SHM verantwortet Bedarfserkennung und -qualifizierung.
DPM/SPM verantworten Umsetzung und Priorisierung.
cluster_referenz: "cluster_d3_bedarfserfuellung"
# -------------------------------------------------------------------------
# D4: STRATEGISCHE PASSUNG
# -------------------------------------------------------------------------
- id: "D4"
name: "Strategische Eignung"
kernfrage: "Passt das DIGIT-Angebot zur Amtsstrategie?"
beispiel_aussagen:
positiv:
- "DIGIT versteht unsere Richtung"
- "Wir bekommen proaktive Impulse"
- "Die IT-Strategie passt zu unseren Zielen"
negativ:
- "Die Prioritäten passen nicht zu unserer Entwicklung"
- "DIGIT denkt nicht mit uns mit"
- "Wir werden von Entwicklungen überrascht"
shm_verantwortung: "Direkt (bei Key-Stakeholdern)"
anmerkung: |
Teil der strategischen Beratungsfunktion bei Key-Stakeholdern.
Bei Standard/Basis-Stakeholdern weniger relevant.
cluster_referenz: "cluster_d4_strategische_passung"
# =============================================================================
# FEEDBACK-QUELLEN
# =============================================================================
feedback_quellen:
beschreibung: |
Die folgenden Quellen liefern Feedback für das VoC-System.
Sie unterscheiden sich in Erhebungsart, Reichweite und
Strukturierungsgrad.
quellen:
- id: "Q-01"
name: "Turnus-Gespräch (TF-01/02)"
typ: "Aktiv erhoben"
reichweite: "Key, Aktiv"
dimensionen: ["D1", "D3", "D4"]
strukturierungsgrad: "Gering (narrativ)"
frequenz: "Quartalsweise (Key) / Halbjährlich (Aktiv)"
quelle_dokument: "shm_engagement-framework.yaml"
template_referenz: "TPL-EF-01, TPL-EF-02, TPL-EF-03"
erfassungshinweis: |
Feedback wird als Bestandteil des Gesprächsprotokolls erfasst.
Kein separater Erfassungsaufwand erforderlich.
- id: "Q-02"
name: "Auftraggeber-Forum Basisservices (KF-01)"
typ: "Aktiv erhoben"
reichweite: "Standard, Basis"
dimensionen: ["D1", "D2"]
strukturierungsgrad: "Gering (narrativ)"
frequenz: "Jährlich"
quelle_dokument: "shm_engagement-framework.yaml"
erfassungshinweis: |
Feedback aus Diskussionen und Q&A-Runden wird im
Veranstaltungsprotokoll dokumentiert.
- id: "Q-03"
name: "Externer SLA-Review (slm_09)"
typ: "Aktiv erhoben"
reichweite: "Alle mit SLA"
dimensionen: ["D2"]
strukturierungsgrad: "Mittel (strukturiert)"
frequenz: "Jährlich"
quelle_dokument: "spm_practice_service-level-management.yaml"
erfassungshinweis: |
D2-Feedback aus SLA-Reviews wird von SPM erfasst und
an SHM als Kontext weitergegeben.
- id: "Q-04"
name: "Strukturiertes Feedback (IND-3)"
typ: "Aktiv erhoben"
reichweite: "Key"
dimensionen: ["D1"]
strukturierungsgrad: "Mittel (Skala + Kommentar)"
frequenz: "Jährlich"
quelle_dokument: "shm_engagement-framework.yaml"
erfassungshinweis: |
Kurze strukturierte Abfrage (3-5 Fragen) zur
Beziehungsqualität im Rahmen eines Turnus-Gesprächs.
- id: "Q-05"
name: "Beschwerden (TRIG-C)"
typ: "Passiv eingehend"
reichweite: "Alle"
dimensionen: ["D1", "D2", "D3"]
strukturierungsgrad: "Gering (unstrukturiert)"
frequenz: "Anlassbezogen"
quelle_dokument: "shm_engagement-framework.yaml"
erfassungshinweis: |
Beschwerden werden im Ticketsystem erfasst und
automatisch als VoC-relevant markiert.
- id: "Q-06"
name: "Service Desk Tickets"
typ: "Passiv eingehend"
reichweite: "User-Ebene"
dimensionen: ["D2"]
strukturierungsgrad: "Hoch (kategorisiert)"
frequenz: "Kontinuierlich"
quelle_dokument: "spm_practice_service-support-management.yaml"
anmerkung: |
Kontext-Information, nicht Primärquelle für SHM.
Aggregierte Ticket-Daten können Hinweise auf
Service-Probleme geben, die Beziehungen belasten.
template_implikation: |
Die Templates für Turnus-Gespräche (TPL-EF-01 bis 03) werden
so gestaltet, dass VoC-relevante Informationen ohne zusätzlichen
Aufwand erfasst werden. Ein Abschnitt "Feedback-Notizen" mit
den Mindestattributen wird integriert.
# =============================================================================
# AGGREGATIONSLOGIK
# =============================================================================
aggregationslogik:
beschreibung: |
Das Feedback durchläuft drei Verdichtungsstufen, von der
Einzelerfassung bis zur strategischen Verdichtung.
designprinzip: |
Die Erfassung (Stufe 1) ist bewusst niedrigschwellig gestaltet.
Komplexität entsteht erst in der Verdichtung (Stufe 2-3), die
zentral und periodisch erfolgt.
# ---------------------------------------------------------------------------
# STUFE 1: ERFASSUNG
# ---------------------------------------------------------------------------
stufe_1_erfassung:
name: "Erfassung"
ort: "Am Entstehungsort (Gespräch, Ticket, Forum)"
verantwortung: "Stakeholder-Manager / Protokollant"
frequenz: "Laufend / anlassbezogen"
beschreibung: |
Feedback wird dort erfasst, wo es entsteht als Teil des
normalen Arbeitsprozesses. Kein separates "VoC-Erfassungs-
System" im MVP.
mindestattribute:
- attribut: "datum"
beschreibung: "Wann wurde das Feedback gegeben?"
pflicht: true
erfassung: "Automatisch (Protokolldatum)"
- attribut: "quelle"
beschreibung: "Woher stammt das Feedback?"
pflicht: true
erfassung: "Automatisch (Dokumenttyp)"
werteliste: ["Q-01", "Q-02", "Q-03", "Q-04", "Q-05", "Q-06"]
- attribut: "stakeholder"
beschreibung: "Wer hat das Feedback gegeben?"
pflicht: true
erfassung: "Automatisch (Gesprächspartner)"
- attribut: "kernaussage"
beschreibung: "Was wurde gesagt? (Paraphrase oder Zitat)"
pflicht: true
erfassung: "Manuell"
- attribut: "tonalitaet"
beschreibung: "Wie war der Grundton?"
pflicht: false
erfassung: "Bei Sichtung ergänzt"
werteliste: ["positiv", "neutral", "kritisch"]
- attribut: "dimension"
beschreibung: "Welche VoC-Dimension betrifft es?"
pflicht: false
erfassung: "Bei Sichtung ergänzt"
werteliste: ["D1", "D2", "D3", "D4"]
erfassungsprinzip: |
Tonalität und Dimension werden bei der Sichtung (Stufe 2)
ergänzt, nicht bei der Erfassung. So bleibt die Erfassung
maximal einfach.
# ---------------------------------------------------------------------------
# STUFE 2: CLUSTERUNG & BEWERTUNG
# ---------------------------------------------------------------------------
stufe_2_clusterung:
name: "Clusterung & Bewertung"
ort: "SHM-intern"
verantwortung: "SHM-Leitung / designierter VoC-Verantwortlicher"
frequenz: "Laufend (Sichtung) / Quartalsweise (Konsolidierung)"
beschreibung: |
Erfasste Feedbacks werden thematisch gruppiert, mit einer
Kritikalitäts-Ampel bewertet und besonders relevante Aussagen
als Highlights extrahiert.
# .........................................................................
# KRITIKALITÄTS-AMPEL
# .........................................................................
kritikalitaets_ampel:
beschreibung: |
Die Ampel ist eine qualitative Einschätzung, keine
mathematische Aggregation. Sie basiert auf dem Gesamteindruck
unter Berücksichtigung der Bewertungskriterien.
stufen:
- stufe: "gruen"
label: "Grün"
bedeutung: "Überwiegend positives Feedback, kein Handlungsbedarf"
handlungsimplikation: "Weiter beobachten, positive Aspekte verstärken"
- stufe: "gelb"
label: "Gelb"
bedeutung: "Gemischtes Feedback, Aufmerksamkeit erforderlich"
handlungsimplikation: "Ursachen verstehen, präventiv handeln"
- stufe: "rot"
label: "Rot"
bedeutung: "Überwiegend negatives Feedback, akuter Handlungsbedarf"
handlungsimplikation: "Sofortige Analyse, Maßnahmenplanung"
- stufe: "grau"
label: "Grau"
bedeutung: "Keine oder unzureichende Datenbasis"
handlungsimplikation: "Datenerhebung intensivieren"
bewertungskriterien:
- kriterium: "Stakeholder-Priorität"
beschreibung: "Feedback von Key-Stakeholdern wiegt schwerer"
- kriterium: "Konsistenz"
beschreibung: "Wiederholte Kritik ist ernster als Einzelfall"
- kriterium: "Trend"
beschreibung: "Verschlechterung ist kritischer als stabiles Niveau"
- kriterium: "Handlungsrelevanz"
beschreibung: "Feedback zu beeinflussbaren Themen ist relevanter"
# .........................................................................
# HIGHLIGHT-EXTRAKTION
# .........................................................................
highlight_extraktion:
beschreibung: |
Besonders relevante Einzelaussagen werden als "Highlights"
markiert und in die Verdichtung übernommen.
highlight_typen:
- typ: "positiv"
kriterium: "Besonders lobende Aussage, Best Practice"
verwendung: "Erfolgsnachweis, Motivation"
- typ: "kritik"
kriterium: "Scharfe Kritik, Eskalationsrisiko"
verwendung: "Handlungsbedarf, Priorisierung"
- typ: "insight"
kriterium: "Überraschende Erkenntnis, neuer Blickwinkel"
verwendung: "Lernen, Strategieentwicklung"
- typ: "trend"
kriterium: "Hinweis auf größere Entwicklung"
verwendung: "Früherkennung, Prävention"
dokumentation: |
Highlights werden mit Quelle dokumentiert, um Rückfragen
zu ermöglichen und Kontext zu bewahren.
# ---------------------------------------------------------------------------
# STUFE 3: VERDICHTUNG FÜR ADRESSATEN
# ---------------------------------------------------------------------------
stufe_3_verdichtung:
name: "Verdichtung für Adressaten"
ort: "SHM-Leitung"
verantwortung: "SHM-Leitung"
frequenz: "Quartalsweise (E2) / Jährlich (E1)"
beschreibung: |
Die geclusterten und bewerteten Feedbacks werden für
unterschiedliche Adressaten verdichtet.
verdichtungen:
- adressat: "E2 (Quartals-Review)"
inhalt:
- "Cluster-Übersicht mit Ampel-Status"
- "Veränderungen gegenüber Vorquartal"
- "Highlights (alle Typen)"
- "Identifizierte Handlungsbedarfe"
format: "Abschnitt im SHM-Quartalsbericht"
- adressat: "E1 (Jahres-Review)"
inhalt:
- "VoC-Gesamtbild des Jahres"
- "Dimension-Überblick (D1-D4)"
- "Jahrestrend je Cluster"
- "Strategische Erkenntnisse"
format: "Kapitel im SHM-Jahresbericht"
- adressat: "DIGIT-Strategie"
inhalt:
- "Übergreifende Themenfelder"
- "Strategische Impulse aus Stakeholder-Sicht"
- "Priorisierungs-Input"
format: "Input-Dokument für Strategieprozess"
schnittstelle_status: "Platzhalter Strategieprozess noch nicht modelliert"
# =============================================================================
# THEMATISCHE CLUSTER
# =============================================================================
thematische_cluster:
status: "Annahme für Startpunkt Validierung mit SHM-Team erforderlich"
entwicklungshinweis: |
Die folgenden Cluster sind ein initialer Vorschlag basierend auf
typischen Feedback-Themen. Sie müssen mit dem SHM-Team validiert
und in der Praxis verprobt werden. Anpassungen (Ergänzung,
Zusammenlegung, Umbenennung) sind explizit vorgesehen.
# ---------------------------------------------------------------------------
# D1: BEZIEHUNGSQUALITÄT
# ---------------------------------------------------------------------------
cluster_d1_beziehungsqualitaet:
dimension: "D1"
dimension_name: "Beziehungsqualität"
cluster:
- id: "D1-C1"
name: "Erreichbarkeit & Reaktionszeit"
typische_aussagen:
- "Schnelle Rückmeldung"
- "Schwer erreichbar"
- "Muss lange auf Antwort warten"
- id: "D1-C2"
name: "Kommunikationsqualität"
typische_aussagen:
- "Verständliche Erklärungen"
- "Zu technisch"
- "Gute Gesprächsatmosphäre"
- id: "D1-C3"
name: "Verbindlichkeit & Verlässlichkeit"
typische_aussagen:
- "Zusagen werden eingehalten"
- "Termine platzen"
- "Kann mich auf Absprachen verlassen"
- id: "D1-C4"
name: "Partnerschaftlichkeit"
typische_aussagen:
- "Fühlen uns ernst genommen"
- "Werden übergangen"
- "Begegnung auf Augenhöhe"
# ---------------------------------------------------------------------------
# D2: SERVICE-QUALITÄT
# ---------------------------------------------------------------------------
cluster_d2_servicequalitaet:
dimension: "D2"
dimension_name: "Service-Qualität"
anmerkung: |
D2-Cluster werden primär durch SPM/SLM bearbeitet.
SHM erfasst sie als Kontext für die Beziehungsqualität.
cluster:
- id: "D2-C1"
name: "Verfügbarkeit & Stabilität"
typische_aussagen:
- "Läuft stabil"
- "Häufige Ausfälle"
- "System ist zuverlässig"
- id: "D2-C2"
name: "Performance"
typische_aussagen:
- "Schnelle Reaktionszeiten"
- "System ist langsam"
- "Ladezeiten sind akzeptabel"
- id: "D2-C3"
name: "Support-Qualität"
typische_aussagen:
- "Kompetente Hilfe"
- "Tickets dauern zu lange"
- "Problem wurde schnell gelöst"
- id: "D2-C4"
name: "Funktionalität"
typische_aussagen:
- "Deckt unsere Anforderungen ab"
- "Wichtige Funktionen fehlen"
- "Gute Weiterentwicklung"
# ---------------------------------------------------------------------------
# D3: BEDARFSERFÜLLUNG
# ---------------------------------------------------------------------------
cluster_d3_bedarfserfuellung:
dimension: "D3"
dimension_name: "Bedarfserfüllung"
cluster:
- id: "D3-C1"
name: "Bedarfserkennung"
typische_aussagen:
- "Unsere Anforderungen werden verstanden"
- "Müssen uns wiederholen"
- "Gute Beratung bei der Bedarfsklärung"
- id: "D3-C2"
name: "Umsetzungsgeschwindigkeit"
typische_aussagen:
- "Projekte kommen voran"
- "Dauert alles ewig"
- "Gute Fortschritte"
- id: "D3-C3"
name: "Priorisierung"
typische_aussagen:
- "Unsere Prioritäten werden berücksichtigt"
- "Andere werden bevorzugt"
- "Faire Ressourcenverteilung"
- id: "D3-C4"
name: "Transparenz"
typische_aussagen:
- "Wissen immer, woran wir sind"
- "Anforderungen verschwinden"
- "Gute Status-Updates"
# ---------------------------------------------------------------------------
# D4: STRATEGISCHE PASSUNG
# ---------------------------------------------------------------------------
cluster_d4_strategische_passung:
dimension: "D4"
dimension_name: "Strategische Passung"
anmerkung: |
D4-Cluster sind primär für Key-Stakeholder relevant.
Bei Standard/Basis-Stakeholdern werden sie selten erhoben.
cluster:
- id: "D4-C1"
name: "Strategisches Verständnis"
typische_aussagen:
- "DIGIT versteht unsere Richtung"
- "Kennen unsere Strategie nicht"
- "Gutes Verständnis unserer Ziele"
- id: "D4-C2"
name: "Zukunftsorientierung"
typische_aussagen:
- "Bekommen proaktive Impulse"
- "Nur reaktiv"
- "Denken mit uns voraus"
- id: "D4-C3"
name: "Strategische Abstimmung"
typische_aussagen:
- "IT-Strategie passt zu unseren Zielen"
- "Prioritäten passen nicht"
- "Gute strategische Zusammenarbeit"
# =============================================================================
# RÜCKFLUSS-MECHANISMUS
# =============================================================================
rueckfluss_mechanismus:
beschreibung: |
VoC ist kein Einweg-System. Die Erkenntnisse müssen zurück zu
den Stakeholdern fließen und in konkrete Maßnahmen münden.
# ---------------------------------------------------------------------------
# RÜCKSPIELUNG AN STAKEHOLDER
# ---------------------------------------------------------------------------
rueckspielung_stakeholder:
grundsatz: |
Stakeholder sollen erfahren, dass ihr Feedback gehört wurde
und welche Konsequenzen es hatte.
mechanismen:
- kanal: "Turnus-Gespräch"
beschreibung: |
Zu Beginn jedes Turnus-Gesprächs Rückbezug auf frühere
Rückmeldungen: "Beim letzten Mal hatten Sie X angemerkt.
Wir haben Y unternommen."
frequenz: "Bei jedem Gespräch"
verantwortung: "Stakeholder-Manager"
- kanal: "Auftraggeber-Forum"
beschreibung: |
Jährliche Zusammenfassung: "Was haben wir aufgrund Ihres
Feedbacks verändert?" als fester Agenda-Punkt.
frequenz: "Jährlich"
verantwortung: "SHM-Leitung"
- kanal: "Direkte Rückmeldung"
beschreibung: |
Bei Kritik-Highlights proaktive Information über
eingeleitete Maßnahmen, ohne auf den nächsten Turnus
zu warten.
frequenz: "Anlassbezogen"
verantwortung: "Stakeholder-Manager"
# ---------------------------------------------------------------------------
# MASSNAHMENABLEITUNG
# ---------------------------------------------------------------------------
massnahmenableitung:
grundsatz: |
Nicht jedes Feedback erfordert eine Maßnahme. Die Ableitung
erfolgt auf Basis der Cluster-Bewertung und Highlights.
ableitungslogik:
- ausloeser: "Einzelnes Kritik-Highlight"
massnahme: "Intervention"
verantwortung: "Stakeholder-Manager"
zeithorizont: "Kurzfristig (Tage/Wochen)"
- ausloeser: "Cluster Gelb"
massnahme: "Beobachtung verstärken"
verantwortung: "SHM-Leitung (E2-Review)"
zeithorizont: "Mittelfristig (Quartal)"
- ausloeser: "Cluster Rot"
massnahme: "Maßnahmenplanung"
verantwortung: "SHM-Leitung (E2-Review)"
zeithorizont: "Mittelfristig (Quartal)"
- ausloeser: "Systematisches Muster"
massnahme: "Strukturelle Verbesserung"
verantwortung: "Erweiterter E2-Review (Q2/Q4)"
zeithorizont: "Langfristig (Halbjahr)"
- ausloeser: "Strategie-relevante Erkenntnis"
massnahme: "Weiterleitung an Strategieprozess"
verantwortung: "SHM-Leitung"
zeithorizont: "Strategiezyklus"
# ---------------------------------------------------------------------------
# WIRKSAMKEITSVALIDIERUNG
# ---------------------------------------------------------------------------
wirksamkeitsvalidierung:
grundsatz: |
Maßnahmen müssen auf ihre Wirksamkeit überprüft werden.
Die Validierung erfolgt über das VoC-System selbst
der Kreis schließt sich.
validierungsmechanismen:
- mechanismus: "Cluster-Entwicklung"
beschreibung: |
Beobachtung der Ampel-Entwicklung im Folgequartal.
Hat sich ein Rot-Cluster nach Maßnahmenumsetzung
auf Gelb oder Grün verbessert?
pruefung_durch: "SHM-Leitung im E2-Review"
dokumentation: "Trend-Kommentar in Cluster-Übersicht"
- mechanismus: "Stakeholder-Rückmeldung"
beschreibung: |
Direkte Bestätigung durch den betroffenen Stakeholder
im nächsten Turnus-Gespräch: "Hat sich aus Ihrer Sicht
etwas verbessert?"
pruefung_durch: "Stakeholder-Manager"
dokumentation: "Notiz im Gesprächsprotokoll"
- mechanismus: "Highlight-Tracking"
beschreibung: |
Beobachtung, ob ein Kritik-Highlight in Folgeperioden
erneut auftaucht. Wiederholtes Auftauchen = Maßnahme
nicht wirksam.
pruefung_durch: "SHM-Leitung"
dokumentation: "Verweis auf frühere Highlights in E2-Review"
- mechanismus: "Maßnahmen-Review"
beschreibung: |
Explizite Überprüfung offener Maßnahmen im E2-Review:
Status, Wirkung, ggf. Nachjustierung.
pruefung_durch: "SHM-Leitung"
dokumentation: "Maßnahmen-Status in E2-Protokoll"
eskalation_bei_unwirksamkeit: |
Wenn eine Maßnahme nach zwei Quartalen keine erkennbare
Wirkung zeigt, wird das Thema im erweiterten E2-Review (Q2/Q4)
als strukturelles Verbesserungsthema behandelt.
# =============================================================================
# UMGANG MIT WIDERSPRÜCHLICHEM FEEDBACK
# =============================================================================
umgang_mit_widerspruechen:
grundsatz: |
Widersprüche sind Informationsquelle, nicht Problem. Sie werden
nicht eliminiert oder geglättet, sondern als Hinweis auf
unterschiedliche Perspektiven oder Kontexte interpretiert.
situationen:
- situation: "Gleicher Sachverhalt, unterschiedliche Bewertung"
beispiel: "Amt A findet Support schnell, Amt B findet ihn langsam"
interpretation: "Unterschiedliche Erwartungen oder Kontexte"
handlung: "Erwartungsklärung, ggf. Segmentierung der Ansprache"
- situation: "Unterschiedliche Sachverhalte"
beispiel: "Lob für Service X, Kritik an Service Y"
interpretation: "Kein echter Widerspruch"
handlung: "Getrennt behandeln"
- situation: "Feedback vs. Selbstwahrnehmung SHM"
beispiel: "Stakeholder kritisiert Erreichbarkeit, SHM sieht kein Problem"
interpretation: "Möglicher blinder Fleck bei SHM"
handlung: "Ernstnehmen, reflektieren, ggf. externe Perspektive einholen"
- situation: "Feedback von verschiedenen Ebenen"
beispiel: "Amtsleitung zufrieden, Sachbearbeiter kritisch"
interpretation: "Unterschiedliche Perspektiven auf gleiche Realität"
handlung: "Beide dokumentieren, nicht gegeneinander ausspielen"
# =============================================================================
# INTEGRATION IN STEUERUNGSSTRUKTUR
# =============================================================================
integration_steuerungsstruktur:
beschreibung: |
VoC ist kein isoliertes Erfassungssystem, sondern integraler
Bestandteil der SHM Koordinations- und Steuerungsstruktur.
Die folgende Zuordnung zeigt, wie VoC in die Entscheidungstypen
einfließt.
zuordnung:
- entscheidungstyp: "E1 (Auftragserfüllung)"
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
voc_beitrag: |
VoC liefert die aggregierte Stakeholder-Stimme als zentralen
Erfolgsindikator. Die Frage "Erfüllen wir unseren Auftrag?"
wird wesentlich durch "Was sagen die Stakeholder?" beantwortet.
voc_output: "Verdichtung E1 (Jahres-Review)"
- entscheidungstyp: "E2 (Portfolio-Qualität, Lernen & Verbesserung)"
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
voc_beitrag: |
VoC informiert sowohl die Portfolio-Betrachtung als auch die
Verbesserungsplanung:
- Portfolio: Welche Beziehungen sind belastet? Welche Muster?
- CI: Systematische Muster, die auf Prozessprobleme hindeuten
voc_output: "Verdichtung E2 (Quartals-Review)"
- entscheidungstyp: "E3 (Operative Koordination)"
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
voc_beitrag: |
Aktuelle Highlights (insbesondere Kritik-Highlights) fließen
in die Team-Koordination ein. Interventionsfälle werden auf
Basis von VoC-Signalen identifiziert.
voc_output: "Highlights (laufend)"
# =============================================================================
# VISUALISIERUNG
# =============================================================================
visualisierung:
beschreibung: |
Die Cluster-Ampel-Matrix bietet eine kompakte Übersicht über
den VoC-Status. Sie wird im Quartals-Review (E2) verwendet.
beispiel_darstellung: |
VoC Cluster-Status Q1/2025
═══════════════════════════════════════════════════════════
│ Grün │ Gelb │ Rot │ Grau │
────────────────────────┼──────┼──────┼─────┼──────┤
D1 Beziehungsqualität │ │ │ │ │
├─ Erreichbarkeit │ ● │ │ │ │
├─ Kommunikation │ ● │ │ │ │
├─ Verbindlichkeit │ │ ● │ │ │
└─ Partnerschaftl. │ ● │ │ │ │
────────────────────────┼──────┼──────┼─────┼──────┤
D2 Service-Qualität │ │ │ │ │
├─ Verfügbarkeit │ ● │ │ │ │
├─ Performance │ │ ● │ │ │
├─ Support │ │ │ ● │ │
└─ Funktionalität │ │ ● │ │ │
────────────────────────┼──────┼──────┼─────┼──────┤
D3 Bedarfserfüllung │ │ │ │ │
├─ Bedarfserkennung │ ● │ │ │ │
├─ Umsetzungsgeschw. │ │ │ ● │ │
├─ Priorisierung │ │ ● │ │ │
└─ Transparenz │ │ ● │ │ │
────────────────────────┼──────┼──────┼─────┼──────┤
D4 Strateg. Passung │ │ │ │ │
├─ Verständnis │ ● │ │ │ │
├─ Zukunftsorient. │ │ ● │ │ │
└─ Abstimmung │ ● │ │ │ │
═══════════════════════════════════════════════════════════
Legende: ● = aktuelle Bewertung
Trend-Indikatoren (optional):
▲ = Verbesserung ggü. Vorquartal
▼ = Verschlechterung ggü. Vorquartal
─ = Unverändert
anwendungshinweis: |
Die Matrix dient der schnellen Orientierung. Details zu einzelnen
Clustern (Highlights, Handlungsbedarf) werden im Fließtext des
Quartalsberichts erläutert.
# =============================================================================
# SCHEMA-HINWEIS
# =============================================================================
schema_hinweis:
id: "VOC-MOD-02"
status: "Informelles Schema ausreichend für MVP"
beschreibung: |
Für den MVP-Start ist kein formales Datenbank-Schema erforderlich.
Die Mindestattribute (siehe Aggregationslogik Stufe 1) definieren
die erwartete Struktur hinreichend.
bei_tool_einfuehrung: |
Wenn ein dediziertes VoC-Tool oder eine SIMS-Integration eingeführt
wird, ist ein formales Schema zu entwickeln. Dieses sollte auf den
hier definierten Mindestattributen aufbauen.
referenz_arbeitsmaterialien: |
Die Template-Anpassungen (Feedback-Notizen-Abschnitt in Turnus-
Gespräch-Templates) werden in Phase 10 umgesetzt.
# =============================================================================
# ÄNDERUNGSHISTORIE
# =============================================================================
aenderungshistorie:
- version: "1.0"
datum: "2025-12-10"
autor: "Konzept-Sprint Phase 5"
aenderung: |
Initiale Erstellung basierend auf Working Document:
- Zweck und Funktion definiert
- Verantwortungsabgrenzung Customer/User dokumentiert
- Feedback-Dimensionen D1-D4 spezifiziert
- Feedback-Quellen Q-01 bis Q-06 inventarisiert
- Dreistufige Aggregationslogik entwickelt
- Thematische Cluster als Annahmen dokumentiert
- Kritikalitäts-Ampel mit Bewertungskriterien definiert
- Rückfluss-Mechanismus konzipiert
- Integration in Steuerungsstruktur beschrieben
- Visualisierung (Cluster-Ampel-Matrix) beispielhaft dargestellt