Interaction Mgmt, Request Mgmt, Incident Mgmt Flashcards
Was sind Probleme des Interaction Managements?
menschliche Kommunikation:
- Verlust von Detailinformationen bei der Aufnahme
- Missverständnisse
- Sprachprobleme, kulturelle Differenzen
- als Folge: falsches Routing
Sonstige:
- Qualität/Nutzen von automatisierten Antworten
- Druck, die Zeit und Häufigkeit des Kontakts zu minimieren
- unterschiedliche Wichtigkeit von Interaktionstypen
Was sind mögliche Metriken des Interaction Managements?
- Anzahl der Interaktionen pro Kanal
- Anteil der Antworten in einem definierten Zeitrahmen
Was sind die Ziele des Request Managements?
- genaues Bestimmen des Requests im Front-Line-Service
- Sammeln von Informationen; unter Umständen Problem direkt lösen
- Weiterleiten der Informationen zu Spezialisten
- Statusupdates an Nutzer weiterleiten
Was sind Probleme des Request Managements?
Probleme für Nutzer:
- lange Wartezeiten
- kein sichtbarer Bearbeitungsstatus
Probleme für Service Desk:
- unnötig viele Rückrufe/Nachfragen
- falsches Routing
- viele Kontakte zur Informationssammlung nötig
- Fehler bei Informationsaufnahme
Was sind mögliche Metriken des Request Managements?
- Anzahl der neu verteilten Requests (wegen falschem Routing)
- Requests mit unvollständigen Informationen
Was sind Beispiele für Requests?
- Fragen (nach Informationen)
- Request nach technischer Unterstützung
- Beschwerden
- Buchen von Ressourcen (Räume, Geräte, Druckerpatronen etc.)
Was sind die Ziele des Incident Management?
- schnelles Wiederherstellen des Service auf dem gewünschten Level
- Minimieren von geschäftsgefährdenden Unterbrechungen
- Implementierung von permanenten Fixes
- möglichst im ersten Anlauf Lösung/Fix finden
- Anzahl der wieder zu öffnenden Incidents minimieren
Was sind Probleme des Incident Managements?
für den Nutzer:
- lange Problemlösungszeiten
- schlechte Kategorisierung der Incidents
- kein sichtbarer Bearbeitungsstatus
- falsches Routing
für den Service Provider:
- schlecht verteilter Workload
- kaum Nutzung der Wissensdatenbanken
- temporäre Workarounds statt permanenter Fixes
- unnötig viele Rückrufe/Nachfragen
Was sind mögliche Metriken des Incident Managements?
- Verteilung der Incidents über Tageszeit, Wochentag, etc.
- finanzielle Auswirkung des Incident
- Anzahl der Neuverteilungen (innerhalb eines Teams oder zwischen Teams)
Was sind mögliche Kategorisierungen von Incidents?
- symptombasiert (komische Geräusche; einfach für Nutzer)
- betroffene Einheit/Asset (Drucker, E-Mail etc.; möglicherweise zu technisch)
- Asset und Symptom kombiniert (großer Overhead, Gefahr einer zu großen Struktur)
- servicebasiert (Abbildung auf Servicekatalog, für Nutzer vielleicht zu verwirrend)
- nach Funktion/Abteilung (Wissen darüber erforderlich, Gefahr des falschen Routings)
- nach “root cause” (meist nicht ermittelbar)
Was sind mögliche Fehler bei der Erstellung einer Kategorisierung?
- Versuch, zu viele Dinge auf einmal aufzunehmen
- zu komplexe Kategorisierungsmodelle
- zu viele Ebenen der Kategorisierung
- technischer Jargon und Abkürzungen
- missverständliche oder zu ähnliche Kategorien
Wie können Incidents priorisiert werden?
- Anzahl der betroffenen Nutzer
- Grad der Behinderung des/der Nutzer(s) durch den Incident
- Gefährdung des Geschäfts
- Dringlichkeit
Was sind Probleme der Priorisierung?
- Über-/Unterpriorisierung
- willkürliche Nutzung von Standardprioritäten
- wechselnde Priorisierung während der Bearbeitung des Tickets
- interne Priorisierung anders als extern sichtbare
Wie kann die Priorität berechnet werden?
- Priorität = Schweregrad * Anzahl der Betroffenen * Dringlichkeit
Was sind Statusattribute in Tickets und wozu dienen sie?
- accepted, scheduled, assigned, in progress…
- den Anfragesteller informieren, an welcher Stelle sich ihr Ticket im Prozess befindet
- dem IT-Management erlauben, den Workload und Fortschritt zu berechnen
- andere am Incident arbeitende Personen über eigenen Fortschritt informieren
