Daten-Template: Incident Management
Ihr Incident Management Data Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung für BMC Helix
Incident-Management-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name der spezifischen Aktion oder des Events, die/das zu einem bestimmten Zeitpunkt im Lebenszyklus des Vorfalls aufgetreten ist. | ||
|
Beschreibung
Der Activity Name beschreibt einen Schritt im Incident Management-Prozess, wie z. B. 'Incident Categorized', 'Assigned to Support Group' oder 'Incident Resolved'. Diese Activities bilden die Knoten in der entdeckten Prozesslandkarte. Die Analyse der Abfolge und Häufigkeit dieser Activities ist zentral für Process Mining. Sie hilft, den tatsächlichen Prozessfluss aufzudecken, Engpässe zwischen den Schritten zu identifizieren, Abweichungen von der Standardvorgehensweise zu erkennen und die Dauer spezifischer Phasen innerhalb des Vorfall-Lebenszyklus zu messen.
Warum es wichtig ist
Dieses Attribut definiert die Schritte im Prozess und ermöglicht die Visualisierung der Prozesslandkarte sowie die Analyse von Abläufen, Bottlenecks und Abweichungen.
Woher erhalten
Typischerweise abgeleitet aus Statusänderungen, Audit Logs oder spezifischen Event Records, die mit dem Incident in der 'HPD:HelpDesk_AuditLogSystem' oder ähnlichen Audit-Tabellen verknüpft sind.
Beispiele
Incident gemeldetSupportgruppe zugewiesenErmittlung gestartetIncident gelöstIncident geschlossen
|
|||
|
Incident-ID
IncidentId
|
Die eindeutige Kennung für jeden gemeldeten Vorfall, die als Primärschlüssel zur Verfolgung des gesamten Lebenszyklus des Vorfalls dient. | ||
|
Beschreibung
Die Incident ID ist der Eckpfeiler der Incident Management-Analyse. Sie identifiziert jeden Case eindeutig und ermöglicht die Aggregation aller zugehörigen Events, Statusänderungen und Activities zu einer einzigen, kohärenten Prozessinstanz. Im Process Mining verknüpft diese ID jeden Schritt, von 'Incident Reported' bis 'Incident Closed', und ermöglicht eine vollständige End-to-End-Ansicht des Vorfallverlaufs. Sie ist unerlässlich für die Berechnung von Case-Level-Metriken wie der gesamten Lösungszeit, der Anzahl der Neu-Zuweisungen und der Identifizierung von Prozessvarianten.
Warum es wichtig ist
Dieses Attribut ist die grundlegende Case-Kennung, die es ermöglicht, den gesamten Lebenszyklus eines Vorfalls zu verfolgen und seinen Ablauf durch den Managementprozess zu analysieren.
Woher erhalten
Dies ist ein Kern-Feld im primären Incident Management-Modul oder -Formular, oft als „Incident Number“ oder „Incident ID“ bezeichnet.
Beispiele
INC000012345678INC000009876543INC000011223344
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der eine spezifische Activity oder ein Event für einen Vorfall aufgetreten ist. | ||
|
Beschreibung
Der Event Timestamp zeichnet den Zeitpunkt auf, zu dem jede Activity stattfand. Diese zeitlichen Daten sind entscheidend, um Events chronologisch zu ordnen und den Prozessfluss präzise zu konstruieren. Bei der Analyse werden Timestamps verwendet, um Dauern zwischen Activities zu berechnen, die gesamte Zykluszeit von Vorfällen zu messen und Verzögerungen oder Wartezeiten im Prozess zu identifizieren. Der Vergleich von Timestamps mit Service Level Agreements (SLAs) ist auch unerlässlich für das Performance Monitoring und Compliance Checks.
Warum es wichtig ist
Timestamps liefern die chronologische Reihenfolge der Events und sind essenziell für alle zeitbasierten Analysen, einschließlich Leistungsmessung, Bottleneck-Identifizierung und SLA Compliance.
Woher erhalten
Diese Informationen finden Sie in den Audit Log-Tabellen, wie z.B. „HPD:HelpDesk_AuditLogSystem“, die jeder protokollierten Aktion oder Statusänderung entsprechen.
Beispiele
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut liefert den Timestamp der letzten Datenextraktion. Es handelt sich um ein Metadatenfeld, das wesentlich ist, um die Aktualität der analysierten Daten zu verstehen. Das Wissen, wann die Daten zuletzt aktualisiert wurden, hilft Analysten und Geschäftsbenutzern, den aus dem Process Mining Tool abgeleiteten Erkenntnissen zu vertrauen. Es bestätigt, ob die Analyse den aktuellsten Betriebszustand widerspiegelt oder auf älteren Daten basiert.
Warum es wichtig ist
Gewährleistet Transparenz bezüglich der Datenaktualität, was entscheidend ist, um auf Grundlage der Prozessanalyse zeitnahe und präzise Geschäftsentscheidungen zu treffen.
Woher erhalten
Dieser Timestamp wird während des Daten-Extraktions-, Transformations- und Ladevorgangs (ETL-Prozess) generiert und hinzugefügt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Incident-Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert den Datenursprung, was in Umgebungen entscheidend ist, in denen Daten aus mehreren Systemen für die Analyse konsolidiert werden. Es hilft, die Data Lineage sicherzustellen und bietet Kontext für die Datenstruktur und den Inhalt. Für Bmc Helix wäre dies typischerweise ein statischer Wert, der die spezifische Instanz oder Umgebung identifiziert, z. B. 'BmcHelix_Production'. Es ist nützlich zum Filtern und Segmentieren von Daten, falls jemals mehrere Quellsysteme integriert werden.
Warum es wichtig ist
Bietet Rückverfolgbarkeit und Kontext für den Ursprung der Daten, was wichtig für die Data Governance und Fehlerbehebung in Multi-System-Umgebungen ist.
Woher erhalten
Dies ist typischerweise ein statischer Wert, der während des Data Extraction, Transformation, and Loading (ETL)-Prozesses hinzugefügt wird, um die Datenquelle zu identifizieren.
Beispiele
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
|
|||
|
Incident-Kategorie
IncidentCategory
|
Die Klassifizierung des Vorfalls, typischerweise in einer hierarchischen Struktur organisiert. | ||
|
Beschreibung
Die Incident-Kategorie bietet eine strukturierte Möglichkeit, Incidents basierend auf dem betroffenen Service, der Komponente oder der Art des Problems zu klassifizieren, beispielsweise 'Hardware', 'Software' oder 'Netzwerk'. Diese Kategorisierung ist entscheidend, um Incidents dem richtigen Team zuzuweisen und zukünftige Incident-Trends zu analysieren. Das Dashboard 'Genauigkeit der Incident-Kategorisierung' stützt sich auf dieses Attribut, wobei oft der ursprüngliche Wert mit dem Wert bei der Lösung verglichen wird, um die Qualität der Ersttriage zu messen. Eine genaue Kategorisierung hilft, wiederkehrende Probleme zu identifizieren und ein effektiveres Problem Management zu ermöglichen.
Warum es wichtig ist
Eine korrekte Kategorisierung ist entscheidend für effizientes Routing, Trendanalysen und die Bewertung der Genauigkeit der initialen Diagnose.
Woher erhalten
Dies sind Standardfelder im Formular 'HPD:Help Desk', oft eine Reihe von miteinander verknüpften Feldern wie 'Categorization Tier 1', 'Categorization Tier 2' usw.
Beispiele
Software > Enterprise Apps > ERPHardware > Laptop > TastaturNetwork > Connectivity > Wi-Fi
|
|||
|
Incident-Status
IncidentStatus
|
Der aktuelle oder historische Status des Vorfalls innerhalb seines Lebenszyklus, wie z. B. 'New', 'In Progress' oder 'Closed'. | ||
|
Beschreibung
Der Incident Status gibt den Status eines Vorfalls zu einem bestimmten Zeitpunkt an. Er ist oft die Quelle für die Generierung des Activity Logs, wobei eine Statusänderung einem Prozessschritt entspricht. Die Analyse des Status ermöglicht es, Vorfälle nach ihrem aktuellen Zustand zu filtern, zu verstehen, wie viel Zeit in verschiedenen Status verbracht wird, und festsitzende Vorfälle zu identifizieren. Zum Beispiel könnte ein Dashboard Vorfälle hervorheben, die sich über einen ungewöhnlich langen Zeitraum im Status 'Pending' befunden haben.
Warum es wichtig ist
Es bietet eine Momentaufnahme des Incident-Fortschritts und ist entscheidend für die Identifizierung stagnierender Incidents sowie die Analyse der in verschiedenen Phasen verbrachten Zeit.
Woher erhalten
Ein Kernfeld im Haupt-Incident-Formular, typischerweise 'HPD:Help Desk'. Das Feld wird oft 'Status' genannt.
Beispiele
NeuZugewiesenIn BearbeitungAusstehendResolvedGeschlossen
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe des Vorfalls, die die erforderliche Lösungsgeschwindigkeit bestimmt. | ||
|
Beschreibung
Priorität ist ein zentrales Attribut, das die Dringlichkeit eines Incidents bestimmt. Sie wird oft aus dem Einfluss und der Dringlichkeit des Incidents abgeleitet und dient dazu, Ressourcen zuzuweisen sowie Service-Level-Agreement-(SLA)-Ziele zu definieren. In der Process Mining-Analyse wird die Priorität verwendet, um Incidents zu segmentieren und die Prozessflüsse von Fällen mit hoher bzw. niedriger Priorität zu vergleichen. Dies hilft zu überprüfen, ob kritische Incidents tatsächlich schneller bearbeitet werden, und Abweichungen in ihren Prozesspfaden zu identifizieren. Dies ist unerlässlich für das „High-Priority Incident Performance“-Dashboard und verwandte KPIs.
Warum es wichtig ist
Dieses Attribut ist entscheidend für die Segmentierung der Analyse, um sicherzustellen, dass Vorfälle hoher Dringlichkeit gemäß definierten Verfahren und SLAs bearbeitet werden.
Woher erhalten
Ein Standardfeld im HPD:Help Desk-Formular, typischerweise 'Priority' genannt.
Beispiele
KritischHochMittelNiedrig
|
|||
|
Schweregrad
Severity
|
Das Maß für die geschäftlichen Auswirkungen des Vorfalls. | ||
|
Beschreibung
Der Schweregrad definiert, wie stark ein Vorfall den Geschäftsbetrieb beeinträchtigt. Er ist zusammen mit der Dringlichkeit eine entscheidende Eingabe zur Bestimmung der Priorität des Vorfalls und der damit verbundenen SLAs. Die Analyse von Vorfällen nach Schweregrad hilft, die Prozessleistung für die schwerwiegendsten Probleme zu verstehen. Er wird in Dashboards wie der 'Übersicht über kritische SLA-Verletzungen' verwendet, um Vorfälle zu kategorisieren und sich auf jene zu konzentrieren, die das größte Risiko für das Unternehmen darstellen.
Warum es wichtig ist
Der Schweregrad hilft, die geschäftlichen Auswirkungen von Vorfällen zu quantifizieren und ermöglicht eine Analyse, die darauf abzielt, die bedeutendsten operationellen Risiken zu mindern.
Woher erhalten
Konsultieren Sie die BMC Helix Dokumentation. Dies ist oft ein Standardfeld im Incident-Formular, das möglicherweise als Impact oder Severity bezeichnet wird.
Beispiele
1-Umfassend/Weit verbreitet2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
SLA-Status
SLAStatus
|
Gibt an, ob der Incident die Service-Level-Agreement (SLA)-Ziele einhält oder diese verletzt hat. | ||
|
Beschreibung
Der SLA Status bietet einen klaren Indikator für die Serviceleistung jedes Vorfalls. Er zeigt typischerweise Zustände wie 'Within Target', 'Warning' oder 'Breached' an und ist oft ein dynamisch berechnetes Feld innerhalb von Bmc Helix. Dieses Attribut ist unerlässlich für das Dashboard 'Critical SLA Breach Overview' und den KPI 'Critical Incident SLA Breach Rate'. Es ermöglicht die sofortige Identifizierung und Priorisierung von Vorfällen, bei denen Servicezusagen nicht eingehalten werden, und erleichtert eine gezielte Analyse der Ursachen für Verzögerungen.
Warum es wichtig ist
Misst die Leistung direkt im Vergleich zu den eingegangenen Verpflichtungen und ist grundlegend für das Compliance Monitoring sowie die Identifizierung von Prozessen, die zu SLA-Verletzungen führen.
Woher erhalten
Dies ist oft ein berechnetes Feld innerhalb von Bmc Helix, das aus der Priorität und dem Alter des Incidents abgeleitet wird. Der Status kann in einem zugehörigen SLA Management Modul gespeichert werden.
Beispiele
Innerhalb des ZielsWarnungVerletzt
|
|||
|
Zugewiesene Supportgruppe
AssignedSupportGroup
|
Das Support-Team oder die Gruppe, die für die Bearbeitung des Vorfalls verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut identifiziert das dem Vorfall zugewiesene Team. Im Verlauf eines Vorfalls kann dieser an verschiedene Support-Gruppen wie das Service Desk, Network Team oder Application Support neu zugewiesen werden. Die Verfolgung von Änderungen in diesem Attribut ist grundlegend für das 'Incident Reassignment Analysis' Dashboard. Es ermöglicht die Visualisierung von Übergaben zwischen Teams, die Messung der Anzahl von Übertragungen pro Vorfall und die Identifizierung von Bottlenecks oder Wissenslücken, die zu übermäßigen Neuzuweisungen führen. Zudem unterstützt es die Workload-Verteilungsanalyse über Teams hinweg.
Warum es wichtig ist
Dieses Attribut ist entscheidend für die Analyse der Teamleistung, der Arbeitslastverteilung sowie der Effizienz von Incident-Weiterleitung und -Übergaben.
Woher erhalten
Ein Standardfeld im HPD:Help Desk-Formular, typischerweise 'Assigned Group' genannt.
Beispiele
Service DeskNetzwerkbetriebDatenbankverwaltungApplication Support Tier 2
|
|||
|
Zugewiesener Agent
AssignedAgent
|
Der individuelle Support Agent, der zur Bearbeitung des Vorfalls zugewiesen wurde. | ||
|
Beschreibung
Der zugewiesene Agent ist die spezifische Person, die zu einem bestimmten Zeitpunkt für den Vorfall verantwortlich ist. Dies bietet einen granulareren Detaillierungsgrad als die Support Group und ermöglicht die Analyse der individuellen Leistung und Arbeitslast. Dieses Attribut ist unerlässlich für das Dashboard 'Team Workload Distribution' und den KPI 'Activity Volume per Agent StdDev'. Durch die Analyse des Umfangs und der Arten von Vorfällen, die jeder Agent bearbeitet, können Manager überlastete Personen identifizieren, eine gerechte Arbeitslastverteilung gewährleisten und Coaching-Möglichkeiten erkennen.
Warum es wichtig ist
Ermöglicht eine granulare Analyse der individuellen Arbeitslast und Leistung, was bei der Optimierung der Ressourcenzuweisung hilft und Top-Performer oder Unterstützungsbedürftige identifiziert.
Woher erhalten
Ein Standardfeld im HPD:Help Desk-Formular, üblicherweise 'Assignee' genannt.
Beispiele
Alice SmithBob JohnsonCharlie Brown
|
|||
|
Anzahl der Neuzuordnungen
ReassignmentCount
|
Die Gesamtzahl der Übertragungen eines Vorfalls zwischen verschiedenen Support-Gruppen. | ||
|
Beschreibung
Dieses berechnete Attribut zählt, wie oft das Feld AssignedSupportGroup während des Lebenszyklus eines Vorfalls geändert wurde. Eine hohe Anzahl von Neuzuweisungen, oft als 'Ticket-Ping-Pong' bezeichnet, deutet auf Prozessineffizienzen wie eine fehlerhafte anfängliche Weiterleitung oder Wissenslücken innerhalb der Support-Teams hin. Diese Metrik ist der Kern des Average Reassignments per Incident KPI und des Incident Reassignment Analysis Dashboards. Die Verfolgung dieser Anzahl hilft, Möglichkeiten zur Verbesserung der Erstlösungsraten und zur Optimierung des Weiterleitungsprozesses zu identifizieren, wodurch letztendlich die Lösungszeit reduziert wird.
Warum es wichtig ist
Quantifiziert Prozessineffizienz und Reibungsverluste und hebt Incidents hervor, die durch Teamübergaben in ihrer Lösung verzögert werden.
Woher erhalten
Die Berechnung erfolgt während der Datentransformation, indem die Anzahl der eindeutigen Werte oder Änderungen im Feld AssignedSupportGroup über den Lebenszyklus jedes Incidents gezählt wird.
Beispiele
0135
|
|||
|
Ist SLA verletzt
IsSlaBreached
|
Ein boolesches Flag, das anzeigt, ob die Incident-Lösungszeit das SLA-Ziel überschritten hat. | ||
|
Beschreibung
Dies ist ein vereinfachtes Flag, das vom Attribut „SLAStatus“ abgeleitet wird, wobei „true“ anzeigt, dass das SLA verletzt wurde. Dies liefert ein klares, binäres Ergebnis für einfaches Filtern und Aggregieren. Dieses Attribut wird zur Berechnung des KPI „Critical Incident SLA Breach Rate“ verwendet. Es ermöglicht eine unkomplizierte Segmentierung aller Incidents in zwei Gruppen, verletzt und nicht verletzt, um die Prozessmerkmale zu analysieren, die am häufigsten unter Incidents auftreten, die die Serviceziele nicht erreichen.
Warum es wichtig ist
Liefert ein einfaches, binäres Ergebnis für die SLA-Compliance. Dadurch lassen sich Verletzungsraten leicht berechnen und die gängigen Pfade nicht-konformer Fälle analysieren.
Woher erhalten
Wird vom Attribut SLAStatus während der Datentransformation abgeleitet. Wenn SLAStatus Breached ist, wird dieses Flag auf true gesetzt.
Beispiele
truefalsch
|
|||
|
Ist wiedereröffnet
IsReopened
|
Ein Flag, das anzeigt, ob ein Incident nach seiner Lösung wiedereröffnet wurde. | ||
|
Beschreibung
Dieses berechnete Attribut ist ein Boolean Flag, das wahr ist, wenn ein Vorfall in seiner Historie eine 'Incident Reopened' Activity aufweist. Eine hohe Rate wiedereröffneter Vorfälle kann auf Probleme mit der Qualität der Lösungen oder eine vorzeitige Schließung von Tickets hindeuten. Dieses Flag wird direkt zur Berechnung des 'Incident Re-opening Rate' KPI und für das 'Incident Re-opening Rate Trend' Dashboard verwendet. Es ermöglicht Analysten, wiedereröffnete Vorfälle einfach zu filtern und zu untersuchen, um die Grundursachen wie unvollständige Korrekturen oder Missverständnisse mit dem Benutzer zu verstehen.
Warum es wichtig ist
Dieses Flag misst direkt die Lösungsqualität und Kundenzufriedenheit und hebt Fälle hervor, in denen die ursprüngliche Korrektur nicht wirksam war.
Woher erhalten
Dies ist ein berechnetes Feld, das während der Daten-Transformation abgeleitet wird, indem überprüft wird, ob das Event Log eines Incidents eine „Reopened“-Aktivität oder einen Statusübergang enthält.
Beispiele
truefalsch
|
|||
|
Kanal
Channel
|
Die Methode oder der Channel, über den der Vorfall gemeldet wurde. | ||
|
Beschreibung
Das Attribut Channel gibt an, wie ein Vorfall initiiert wurde, zum Beispiel per Telefonanruf, E-Mail, Self-Service-Portal oder automatisiertes Monitoring. Die Analyse des Prozesses nach Channel kann wichtige Unterschiede bei den Lösungszeiten oder Prozesspfaden aufzeigen. Zum Beispiel könnten Vorfälle, die über das Self-Service-Portal gemeldet werden, aufgrund einer besseren anfänglichen Datenqualität schneller gelöst werden. Diese Analyse kann Entscheidungen darüber beeinflussen, welche Channels gefördert oder verbessert werden sollen.
Warum es wichtig ist
Hilft zu verstehen, wie die Berichtsmethode den Incident-Lebenszyklus beeinflusst, und deckt Möglichkeiten auf, spezifische Kanäle für mehr Effizienz zu optimieren.
Woher erhalten
Ein Standardfeld im HPD:Help Desk-Formular, oft 'Reported Source' genannt.
Beispiele
E-MailTelefonSelf-service PortalSystem Monitoring
|
|||
|
Lösungscode
ResolutionCode
|
Ein Code oder eine Kategorie, die angibt, wie der Incident letztendlich gelöst wurde. | ||
|
Beschreibung
Der Resolution Code erfasst das Endergebnis oder die Art der auf einen Vorfall angewendeten Lösung. Diese strukturierten Daten sind wertvoll für die Ursachenanalyse und das Verständnis der am häufigsten benötigten Lösungsarten.
Warum es wichtig ist
Liefert strukturierte Daten zu Incident-Ergebnissen, was die Ursachenanalyse sowie die Verbesserung von Wissensmanagement und Automatisierung unterstützt.
Woher erhalten
Konsultieren Sie die BMC Helix Dokumentation. Dieses Feld befindet sich typischerweise auf der Registerkarte 'Lösung' oder im Abschnitt des Incident-Formulars.
Beispiele
Benutzerfehler - Schulung bereitgestelltSoftware-Patch angewendetHardware ersetztKein Fehler gefunden
|
|||
|
Lösungsdauer
ResolutionDuration
|
Die Gesamtzeit, die von der ersten Meldung eines Vorfalls bis zu seiner Lösung vergangen ist. | ||
|
Beschreibung
Diese Metrik misst die Dauer von der Aktivität „Incident Reported“ bis zur Aktivität „Incident Resolved“. Sie ist ein Key Performance Indicator für die Effizienz des gesamten Incident Management-Prozesses. Dieses berechnete Attribut ist die Grundlage für den KPI „Average Incident Resolution Time“ und das Dashboard „Incident Resolution Cycle Time“. Die Analyse dieser Dauer über verschiedene Incident-Kategorien, Prioritäten oder Teams hinweg hilft, systemische Verzögerungsquellen zu identifizieren und die Auswirkungen von Prozessverbesserungsinitiativen zu messen.
Warum es wichtig ist
Dies ist ein primäres Maß für die Prozesseffizienz und das Kundenerlebnis, das direkt widerspiegelt, wie lange es dauert, den Service für Benutzer wiederherzustellen.
Woher erhalten
Die Berechnung erfolgt während der Datentransformation, indem die Zeitdifferenz zwischen dem Timestamp der Aktivität Incident Resolved und dem der Aktivität Incident Reported für jeden Case ermittelt wird.
Beispiele
25920000086400000604800000
|
|||
|
Unternehmensdienstleistung
BusinessService
|
Der Business Service oder die Anwendung, die vom Vorfall betroffen ist. | ||
|
Beschreibung
Dieses Attribut verknüpft einen Vorfall mit einem spezifischen Geschäftsservice, der in der Configuration Management Database (CMDB) definiert ist, wie z. B. 'Email Service' oder 'ERP System'. Die Analyse von Vorfällen nach dem betroffenen Geschäftsservice ist entscheidend, um die Auswirkungen auf die Organisation zu verstehen. Sie hilft, die Bemühungen im Problemmanagement auf die Services zu konzentrieren, die die meisten Vorfälle generieren oder die längsten Ausfallzeiten erleiden. Diese Sichtweise ist wesentlich für die Berichterstattung über die Leistung der IT aus geschäftsorientierter Sicht.
Warum es wichtig ist
Verbindet technische Incidents mit ihrem Business Impact und ermöglicht so eine Analyse, die Aufgaben nach ihrer Kritikalität für die Organisation priorisiert.
Woher erhalten
Dies ist ein Configuration Item (CI)-Feld im Incident-Formular, das mit der CMDB verknüpft ist. Das Feld könnte als „Service“ oder „CI“ bezeichnet sein.
Beispiele
Unternehmens-E-Mail-DienstSAP ERP FinancialsKundenbeziehungsmanagement
|
|||
Incident-Management-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Incident gelöst
|
Zeigt an, dass eine Lösung implementiert und der Service für den Benutzer wiederhergestellt wurde. Dies ist ein wichtiger Meilenstein, der typischerweise durch eine Statusänderung auf 'Gelöst' erfasst wird. | ||
|
Warum es wichtig ist
Dies ist ein primärer Meilenstein zur Messung der Kern-Lösungszeit. Er kennzeichnet das Ende der aktiven Arbeitsphase und startet oft die Zeitmessung für die Benutzerbestätigung oder automatische Abschlussverfahren.
Woher erhalten
Dies ist ein eigenständiges Event, das vom Timestamp abgeleitet wird, wenn das Feld „Status“ auf „Resolved“ aktualisiert wird. Diese Änderung wird in der Audit-Historie erfasst.
Erfassen
Filtern Sie Audit-Logs nach der Statusänderung zu Resolved.
Ereignistyp
inferred
|
|||
|
Incident gemeldet
|
Kennzeichnet die Erstellung eines neuen Incident-Eintrags im System. Dies ist der Startpunkt des Incident-Lebenszyklus, der typischerweise durch eine Meldung eines Benutzers über ein Portal, eine E-Mail oder durch die manuelle Erstellung des Tickets durch einen Service Desk-Mitarbeiter ausgelöst wird. | ||
|
Warum es wichtig ist
Diese Activity ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von diesem Event bis zur Lösung ist grundlegend, um die gesamte Dauer des Incident-Lebenszyklus zu messen und vorgelagerte Verzögerungen zu identifizieren.
Woher erhalten
Dies ist ein explizites Erstellungs-Event, das vom Timestamp „Submit Date“ oder „Reported Date“ im „HPD:Help Desk“-Formular erfasst wird. Es ist eines der zuverlässigsten und fundamentalsten Events im System.
Erfassen
Wird vom Erstellungs-Timestamp des Incident-Eintrags in der HPD:Help Desk-Tabelle erfasst.
Ereignistyp
explicit
|
|||
|
Incident geschlossen
|
Die letzte Activity im Lebenszyklus, bei der der Vorfall formal geschlossen wird und zu einem schreibgeschützten historischen Datensatz wird. Dies geschieht oft automatisch nach einer festgelegten Zeitspanne im Status 'Resolved'. | ||
|
Warum es wichtig ist
Diese Activity markiert das definitive Ende des Prozesses. Die Zeit zwischen 'Resolved' und 'Closed' kann auf Verzögerungen in administrativen Prozessen oder bei Bestätigungsfristen für den Benutzer hinweisen.
Woher erhalten
Dies ist ein eigenständiges Event, das vom Timestamp abgeleitet wird, wenn das Feld „Status“ auf „Closed“ aktualisiert wird. Dies wird in der Audit-Historie verfolgt.
Erfassen
Filtern Sie Audit-Logs nach der Statusänderung zu Closed.
Ereignistyp
inferred
|
|||
|
Lösung identifiziert
|
Stellt den Moment dar, in dem ein Support-Agent eine Lösung gefunden und im Incident-Eintrag dokumentiert hat. Der Incident ist nun bereit, in den Status „Resolved“ verschoben zu werden. | ||
|
Warum es wichtig ist
Dieser Meilenstein kennzeichnet das Ende der technischen Untersuchungsphase. Die Dauer von diesem Zeitpunkt bis zum Closure kann Engpässe in der Kommunikation, Verifizierung und in administrativen Prozessen aufzeigen.
Woher erhalten
Dies wird oft aus dem Timestamp abgeleitet, zu dem die Lösungsdetails eingegeben und gespeichert werden, kurz bevor der Status auf „Resolved“ geändert wird.
Erfassen
Verwenden Sie den Timestamp der letzten Modifikation, bevor sich der Status in 'Resolved' ändert.
Ereignistyp
inferred
|
|||
|
Supportgruppe zugewiesen
|
Diese Activity kennzeichnet die anfängliche Zuweisung des Vorfalls an eine spezifische Support Group zur Untersuchung und Lösung. Sie stellt die erste Übergabe vom Service Desk an ein technisches Team dar. | ||
|
Warum es wichtig ist
Dies ist ein entscheidender Meilenstein zur Verfolgung der First-Touch Resolution Rate und der anfänglichen Reaktionszeiten. Er hilft, Verzögerungen bei der Zuweisung des Incidents an das richtige Team zu identifizieren.
Woher erhalten
Erfolgt durch die Erfassung der erstmaligen Befüllung des Feldes Assigned Group in der Audit-Historie des Incidents (HPD:HelpDesk_AuditLogSystem).
Erfassen
Abgeleitet aus der ersten aufgezeichneten Änderung des Feldes 'Zugewiesene Gruppe' in den Audit-Logs.
Ereignistyp
inferred
|
|||
|
Workaround implementiert
|
Bedeutet, dass dem Benutzer eine temporäre Lösung bereitgestellt wurde, die die Servicefunktionalität wiederherstellt, während eine dauerhafte Lösung entwickelt wird. Dies wird oft durch das Setzen eines spezifischen Flags oder Status vermerkt. | ||
|
Warum es wichtig ist
Dessen Verfolgung hilft, die Geschwindigkeit der Dienstwiederherstellung zu messen, die für die Benutzerzufriedenheit entscheidend ist. Sie trennt temporäre Lösungen von dauerhaften Behebungen in der Prozessanalyse.
Woher erhalten
Dies kann aus dem Timestamp abgeleitet werden, wenn das 'Workaround'-Feld in den Incident-Lösungsdetails gefüllt wird oder wenn ein spezifischer Status 'Workaround Provided' verwendet wird.
Erfassen
Verwenden Sie den Timestamp einer Statusänderung in den Zustand 'Workaround' oder wenn Lösungsvermerke, die einen Workaround anzeigen, erstmalig gespeichert werden.
Ereignistyp
inferred
|
|||
|
An eine andere Gruppe übertragen
|
Stellt die Neuzuordnung eines Incidents von einer Supportgruppe zu einer anderen dar. Dies geschieht typischerweise, wenn die ursprüngliche Gruppe das Problem nicht lösen kann und Fachwissen von einem anderen Team benötigt. | ||
|
Warum es wichtig ist
Häufige Übertragungen oder wiederholte Weiterleitungen sind eine Hauptursache für Verzögerungen und Ineffizienz. Die Analyse dieser Aktivitäten hilft, Routing-Probleme, Qualifikationslücken und Prozess-Bottlenecks zu identifizieren.
Woher erhalten
Abgeleitet aus einer Änderung des Wertes des Feldes 'Zugewiesene Gruppe' in der Audit-Historie des Incidents, nach der Erstzuweisung.
Erfassen
Jede Änderung des Feldes Assigned Group im Audit-Log nach der ersten Zuordnung stellt eine Übertragung dar.
Ereignistyp
inferred
|
|||
|
Benutzerbestätigung erhalten
|
Stellt die Bestätigung des Benutzers dar, dass die bereitgestellte Lösung sein Problem behoben hat. Dies ist oft ein optionaler Schritt und kann durch eine Portal-Aktion oder durch einen Agenten erfasst werden. | ||
|
Warum es wichtig ist
Die Analyse der Rate und Geschwindigkeit von Benutzerbestätigungen hilft, die Effektivität der Kommunikation und die Lösungsqualität zu bewerten. Eine niedrige Bestätigungsrate könnte zu einer höheren Wiedereröffnungsrate führen.
Woher erhalten
Dies ist direkt schwer zu erfassen und muss möglicherweise abgeleitet werden. Es könnte ein spezifischer Status wie „Resolved - Confirmed“ sein oder eine Notiz, die dem Incident Work Log hinzugefügt wurde.
Erfassen
Erfordert Systemanalyse. Suchen Sie nach Worklog-Einträgen oder Statusänderungen, die Benutzerfeedback anzeigen.
Ereignistyp
inferred
|
|||
|
Ermittlung gestartet
|
Zeigt an, dass ein zugewiesener Agent aktiv mit der Bearbeitung des Incidents begonnen hat. Dies wird oft durch eine Statusänderung von 'Zugewiesen' zu 'In Bearbeitung' oder einem ähnlichen Zustand dargestellt. | ||
|
Warum es wichtig ist
Die Messung der Zeit zwischen Zuweisung und Beginn der Untersuchung deckt Warteschlangenverzögerungen auf und hilft, die Reaktionsfähigkeit der Agenten und die Workload-Kapazität zu beurteilen.
Woher erhalten
Dies wird aus einer Änderung im Feld „Status“ von „Assigned“ zu „In Progress“ abgeleitet. Der Timestamp dieser Statusänderung wird im Audit Log erfasst.
Erfassen
Filtern Sie Audit-Logs nach der ersten Statusänderung zu In Progress nach einer Zuordnung.
Ereignistyp
inferred
|
|||
|
Incident kategorisiert
|
Stellt die initiale Klassifizierung des Incidents dar, einschließlich der Festlegung von Kategorie, Typ und Element. Diese Aktivität wird typischerweise von einem Level-1-Service Desk-Agenten kurz nachdem der Incident gemeldet wurde, durchgeführt. | ||
|
Warum es wichtig ist
Die Verfolgung dieser Aktivität hilft, die Genauigkeit anfänglicher Klassifizierungen und deren Auswirkungen auf die Weiterleitung und Lösung zu analysieren. Änderungen der Kategorisierung später im Prozess deuten auf Nacharbeiten und potenzielle Wissenslücken hin.
Woher erhalten
Abgeleitet aus dem ersten Zeitpunkt, zu dem die Felder für die operative und Produktkategorisierung ('OpCat', 'ProdCat') im Audit-Log des Incidents (HPD:HelpDesk_AuditLogSystem) ausgefüllt werden.
Erfassen
Den ersten Timestamp identifizieren, an dem Kategorisierungsfelder im Audit-Log gesetzt werden.
Ereignistyp
inferred
|
|||
|
Incident wiedereröffnet
|
Tritt auf, wenn ein zuvor gelöster oder geschlossener Incident in einen aktiven Zustand zurückversetzt wird. Dies geschieht normalerweise, wenn der Benutzer meldet, dass das Problem erneut aufgetreten ist. | ||
|
Warum es wichtig ist
Eine hohe Wiedereröffnungsrate deutet auf Probleme mit der Qualität der Lösungen hin. Die Verfolgung dieser Nacharbeitschleife ist entscheidend, um die Grundursachen ineffektiver Behebungen zu identifizieren und die Erstlösungsrate zu verbessern.
Woher erhalten
Abgeleitet aus einer Statusänderung von 'Gelöst' oder 'Geschlossen' zurück in einen aktiven Zustand wie 'In Bearbeitung' oder 'Zugewiesen'. Dieser Übergang wird in der Audit-Historie protokolliert.
Erfassen
Filtern Sie Audit-Logs nach einer Statusänderung von einem gelösten/geschlossenen Status zu einem offenen Status.
Ereignistyp
inferred
|
|||
|
Incident zurückgestellt
|
Diese Activity tritt auf, wenn der Fortschritt bei einem Vorfall pausiert wird, typischerweise während auf Informationen vom Benutzer oder einem externen Anbieter gewartet wird. Dies wird üblicherweise durch eine Statusänderung zu 'Pending' angezeigt. | ||
|
Warum es wichtig ist
Diese Activity ist entscheidend für die genaue Berechnung der Lösungszeiten. Die Zeit, die in einem 'Pending'-Status verbracht wird, sollte oft von SLA-Berechnungen ausgeschlossen werden, um die Leistung des Support-Teams fair zu bewerten.
Woher erhalten
Abgeleitet aus einer Änderung des Feldes 'Status' in den Zustand 'In Wartestellung'. Das Audit-Log verfolgt den Timestamp dieser Änderung.
Erfassen
Filtern Sie Audit-Logs nach Statusänderungen zu Pending oder einem ähnlichen Halte-Status.
Ereignistyp
inferred
|
|||
|
SLA Breach Detected
|
Ein berechnetes Event, das auftritt, wenn die für die Reaktion oder Lösung eines Incidents benötigte Zeit die in der Service Level Agreement (SLA) definierten Ziele überschreitet. Dies ist kein direktes System-Event. | ||
|
Warum es wichtig ist
Das Identifizieren von SLA-Verletzungen ist entscheidend für die Compliance-Überwachung und die Priorisierung kritischer Incidents. Dies hilft, die Prozessschritte zu erkennen, die am meisten zu Verletzungen beitragen.
Woher erhalten
Dieses Event wird berechnet, indem der Timestamp der 'Incident Resolved' Activity (oder anderer SLA-Meilensteine) mit dem Reported Date und dem definierten SLA-Ziel für die Priorität des jeweiligen Vorfalls verglichen wird.
Erfassen
Wird abgeleitet durch den Vergleich des Lösungs-Timestamp mit dem Start-Timestamp zuzüglich der SLA-Dauer.
Ereignistyp
calculated
|
|||
|
Status "Ausstehend" wieder aufgenommen
|
Kennzeichnet den Zeitpunkt, an dem ein in Wartestellung befindlicher Incident reaktiviert wird. Dies geschieht, wenn die benötigten Informationen eingegangen sind, und wird typischerweise durch den Statuswechsel von „Pending“ zurück zu „In Progress“ angezeigt. | ||
|
Warum es wichtig ist
Dieses Event, gepaart mit 'Incident Put On Hold', ermöglicht die präzise Messung von Wartezeiten. Die Analyse langer Wartezeiten kann auf Kommunikationsprobleme mit Benutzern oder Dritten hinweisen.
Woher erhalten
Abgeleitet aus einer Statusänderung von 'In Wartestellung' zu einem aktiven Zustand wie 'In Bearbeitung'. Der Timestamp ist im Audit-Log verfügbar.
Erfassen
Filtern Sie Audit-Logs nach einer Statusänderung von Pending zu In Progress oder Assigned.
Ereignistyp
inferred
|
|||