Ihr Incident-Management Daten Template
Ihr Incident-Management Daten Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsanleitung für ServiceNow – Problemmanagement
Incident-Management-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
`Incident`-ID
IncidentId
|
Die eindeutige Kennung für jeden Vorfall-Datensatz, die als Primärschlüssel für die Verfolgung des gesamten Lebenszyklus dient. | ||
|
Beschreibung
Die Vorfall-ID ist die eindeutige Referenznummer, die jedem gemeldeten Vorfall in ServiceNow zugewiesen wird. Sie fungiert als zentraler Case-ID, der alle zugehörigen Aktivitäten, Aktualisierungen und Mitteilungen vom Zeitpunkt der Erstellung eines Vorfalls bis zu dessen Abschluss verknüpft. In der Process Mining-Analyse ist diese ID grundlegend. Sie ermöglicht es dem Tool, die Abfolge der Ereignisse für jeden einzelnen Case zusammenzufügen und bildet die Basis für die Entdeckung von Prozessablaufn, die Analyse von Varianten und die Berechnung der Ende-zu-Ende-Dauer. Ohne eine eindeutige Vorfall-ID für jeden Case wäre es unmöglich, den Weg eines Vorfalls durch den Lösungsprozess nachzuvollziehen.
Bedeutung
Dies ist die zentrale Case-ID, die alle Ereignisse im Lebenszyklus eines Incidents miteinander verbindet und so eine End-to-End-Prozessanalyse ermöglicht.
Datenquelle
ServiceNow incident-Tabelle, Feld number.
Beispiele
INC0010001INC0010045INC0010239
|
|||
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Ereignisse oder den Antrag bearbeitet.er Aufgabe, das/die zu einem bestimmten Zeitpunkt innerhalb des Vorfall-Lebenszyklus stattfand. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen spezifischen Schritt oder eine Statusänderung im Incident-Management Process, wie z. B. „Incident Created“, „Assigned To Agent“ oder „Incident Closed“. Diese Daten werden in der Regel aus Änderungen in wichtigen Incident Fields wie „State“ oder „Assignment Group“ oder aus spezifischen Log-Einträge abgeleitet. Dieses Attribut ist wesentlich für den Aufbau der Prozessdarstellung (Process Map). Es definiert die Knoten im Process Graph und ermöglicht Analysten, den Fluss der Incidents zu visualisieren, gängige Pfade zu identifizieren, Engpässe zwischen Aktivitäten zu entdecken und Prozessvarianten zu analysierenn. Die Granularität und Genauigkeit dieser Aktivitätsnames wirken sich direkt auf die Qualität der Prozessanalyse aus.
Bedeutung
Es definiert die Schritte in der Prozessdarstellung (Process Map), die die Grundlage für alle Process Mining Analysen und Visualisierungen bildet.
Datenquelle
Dies ist ein abgeleitetes Attribut, das in der Regel durch die Datentransformationslogik basierend auf Änderungen in Feldern wie state, assignment_group und assigned_to in den sys_audit- oder incident-Tabellen generiert wird.
Beispiele
Incident erstelltZuweisungsgruppe geändertBehebung VorgeschlagenIncident geschlossen
|
|||
|
Ereigniszeit
EventTime
|
Der präzise Zeitstempel, der anzeigt, wann die Aktivität stattfand. | ||
|
Beschreibung
Event Time, oft als Zeitstempel bezeichnet, erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen oder eine Statusänderung erfolgte. In ServiceNow wird dies in der Regel im Feld sys_updated_on für jede im Audit-Trail erfasste Änderung festgehalten. Dieses Attribut ist unerlässlich für die korrekte Reihenfolge von Ereignisse und für alle zeitbasierten Analysen. Es wird verwendet, um Durchlaufzeiten, Wartezeiten und Zeitspannen zwischen Aktivitäten zu berechnen, die grundlegend sind für die Identifizierung von Engpässen, die Leistungsmessung gegenüber SLAs und das Verständnis der Prozesseffizienz. Die Genauigkeit dieser Zeitstempels ist maßgeblich für die Gültigkeit aller dauernbasierten Metriken.
Bedeutung
Dieser Zeitstempel ordnet alle Aktivitäten chronologisch und ermöglicht die Berechnung aller zeitbasierten Kennzahlen, wie Durchlaufzeits und Engpässe.
Datenquelle
ServiceNow sys_audit-Tabelle, Feld sys_created_on oder den Antrag bearbeitet.as sys_updated_on-Feld aus der incident-Tabelle für den letzten Status.
Beispiele
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Datenaktualisierung aus ServiceNow. Es handelt sich um ein MetaDatenfeld, das die Aktualität der analysierten Daten widerspiegelt und kein Event im Prozess selbst darstellt. Diese Information ist maßgeblich für das Verständnis der Aktualität der Analyse. Sie zeigt den Nutzern, wie aktuell die Daten sind, was wichtig für operative Dashboards und die Entscheidungsfindung basierend auf aktuellen Ereignisse ist. Sie hilft, Erwartungen an die Relevanz und Aktualität der Daten zu steuern.
Bedeutung
Es Hinweisrmiert Benutzer über die Aktualität der Daten, was wichtig für die Relevanz und Genauigkeit der Analyse ist.
Datenquelle
Dieser Zeitstempel wird vom Datenextraktions-Tool oder Datenextraktionsprozess zum Zeitpunkt des Datenladevorgangs generiert und befüllt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem diese Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert die Herkunft der IncidentDaten, in diesem Fall aus dem ServiceNow – Problemmanagement. Es ist in der Regel ein statischer Wert, der während der Datenextraktions- und Transformationsphase hinzugefügt wird. In Umgebungen, in denen Daten aus mehreren Systemen für die Analyse kombiniert werden, ist dieses Feld wichtig für die Datenherkunft und Datentrennung. Es stellt sicher, dass Kennzahlen und Prozesse im richtigen Kontext analysiert werden und ermöglicht es Analysten, Prozesse über verschiedene Quellsysteme hinweg zu vergleichen.
Bedeutung
Es liefert wichtigen Kontext zur Datenherkunft, sichert die Daten Lineage und ermöglicht eine korrekte Interpretation in Multi-System-Umgebungen.
Datenquelle
Dies ist in der Regel ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird.
Beispiele
ServiceNow – ProblemmanagementServiceNow
|
|||
|
Bearbeitungsgruppe
AssignmentGroup
|
Das Kundensupport oder den Antrag bearbeitet.ie Gruppe, die für die Bearbeitung des Vorfalls verantwortlich ist. | ||
|
Beschreibung
Die Zuweisungsgruppe stellt das Agententeam dar, das für die Behebung eines Vorfalls zuständig ist. Vorfälle werden oft zwischen verschiedenen Gruppen weitergeleitet, z. B. von einem Level-1-Helpdesk an ein spezialisiertes Level-2-Netzwerkteam. Dieses Attribut ist maßgeblich für die Analyse von teamübergreifenden Übergaben und die Identifizierung systemischer Engpässe. Das Dashboard 'Übergabe- und Neuzuweisungsrate' stützt sich stark auf diese Daten, um zu zeigen, welche Teams häufig in Weiterleitungen involviert sind. Es ermöglicht auch Leistungsvergleiche zwischen verschiedenen Support-Gruppen und hilft zu verstehen, wo die Lösungskompetenz innerhalb der Organisation liegt.
Bedeutung
Dies verfolgt, welches Team verantwortlich ist, und ermöglicht die Analyse von Teamleistung, Arbeitslast und Übergaben zwischen Gruppen.
Datenquelle
ServiceNow incident-Tabelle, Feld assignment_group.
Beispiele
`Service Desk`**Netzwerk-Support**Datenbankadministratoren
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe des Vorfalls, die die erforderliche Dringlichkeit der Reaktion vorgibt. | ||
|
Beschreibung
Priorität ist ein zentrales Feld in ServiceNow, das die Reihenfolge und Geschwindigkeit der Incident-Bearbeitung festlegt. Sie leitet sich in der Regel aus dem Impact und der Urgency des Incidents ab und beeinflusst direkt die SLA-Ziele. Dieses Attribut ist die Basis für die Segmentierung und Leistungsfähigkeit-Analyse. Das Dashboard "SLA Compliance Übersicht" verwendet die Priorität, um zu bewerten, ob hochpriorisierte Incidents innerhalb ihrer Zielzeiten gelöst werden. Die Analyse der Durchlaufzeits nach Priorität hilft zu bestätigen, dass kritische Incidents tatsächlich schneller bearbeitet werden als weniger wichtige. Es ist eine wichtige Dimension für fast jedes KPI und Dashboard.
Bedeutung
Es ermöglicht die Segmentierung von Incidents nach geschäftlicher Bedeutung, was für die Überwachung der SLA-Compliance und die Ressourcenzuweisung wichtig ist.
Datenquelle
ServiceNow incident-Tabelle, Feld priority.
Beispiele
1 – Kritisch2 – Hoch3 – Moderat4 – Niedrig
|
|||
|
Vorfall-Status
IncidentState
|
Der aktuelle Status des Vorfalls in seinem Lebenszyklus. | ||
|
Beschreibung
Der Vorfallstatus gibt das aktuelle Stadium des Vorfalls an, z. B. 'Neu', 'In Bearbeitung', 'In Wartestellung' oder 'Gelöst'. Statusänderungen sind oft die primäre Quelle für die Generierung von Aktivitäten im Event Log für Process Mining. Die Analyse der in jedem Status verbrachten Zeit ist eine effektive Methode, um Engpässe zu identifizieren. Eine lange Dauer im Status 'In Wartestellung' könnte beispielsweise auf Abhängigkeiten von externen Faktoren oder Benutzern hinweisen. Die Abfolge der Statusänderungen bildet auch die Basis der Prozessablauf und zeigt, wie Vorfälle bis zur Lösung voranschreiten.
Bedeutung
Es verfolgt den Fortschritt des Incidents und ist maßgeblich für die Analyse der in verschiedenen Phasen verbrachten Zeit und die Identifizierung von Process Engpässe.
Datenquelle
ServiceNow incident-Tabelle, Feld incident_state oder state.
Beispiele
NeuIn BearbeitungWartet auf BenutzerHinweisrmationenGelöstGeschlossen
|
|||
|
Zugeordnet an
AssignedTo
|
Der einzelne Benutzer oder Agent, dem derzeit die Bearbeitung des Vorfalls zugewiesen ist. | ||
|
Beschreibung
Dieses Attribut identifiziert den jeweils für den Incident zuständigen Supportmitarbeiter. Diese Information ist maßgeblich, um die Arbeitslastverteilung, die Mitarbeiterleistung und Übergaben zwischen Mitarbeitenden zu verstehen. In der Analyse hilft 'Assigned To' bei der Visualisierung der Ressourcenallokation und der Identifizierung überlasteter Mitarbeiter. Es wird auch im Handoff and Reassignment Dashboard verwendet, um zu verfolgen, wie oft ein Incident seinen Bearbeiter wechselt, was ein Indikator für Ineffizienz oder Wissenslücken sein kann. Die Analyse der Lösungszeiten pro Mitarbeiter kann zudem Spitzenleistungen hervorheben oder Mitarbeiter mit Schulungsbedarf aufzeigen.
Bedeutung
Es ermöglicht die Analyse der Agentenarbeitslast, Leistung und individuellen Übergaben, die wichtig für das Verständnis der Ressourceneffizienz sind.
Datenquelle
ServiceNow incident-Tabelle, Feld assigned_to.
Beispiele
Beth AnglinDavid LooHoward Johnson
|
|||
|
Anrufer
CallerId
|
Der Benutzer, der den Antrag bearbeitet.en Vorfall ursprünglich gemeldet hat. | ||
|
Beschreibung
Der Melder identifiziert den Endbenutzer oder Kunden, der vom Vorfall betroffen ist und ihn gemeldet hat. Diese Information gibt Aufschluss darüber, wer von Serviceunterbrechungen betroffen ist. Obwohl nicht immer zentral für den Prozessfluss selbst, kann die Analyse von Vorfällen nach Melder aufzeigen, ob spezifische Einzelpersonen oder Abteilungen unverhältnismäßig stark von Problemen betroffen sind. Dies kann auf Schulungsbedarf oder lokale Umgebungsprobleme hinweisen. Es bietet auch eine direkte Verbindung zum Kunden für Zufriedenheitsumfragen und Kommunikation.
Bedeutung
Es identifiziert den betroffenen Benutzer, was eine Analyse nach Abteilung oder Individuum ermöglicht und Kontext für die Benutzerkommunikation bietet.
Datenquelle
ServiceNow incident-Tabelle, Feld caller_id.
Beispiele
Abel TuterCarolina PashDon Goodliffe
|
|||
|
Anzahl der Neuzuweisungen
ReassignmentCount
|
Die Anzahl der Neuzuweisungen des Vorfalls an eine andere Gruppe oder einen anderen Agenten. | ||
|
Beschreibung
Dieses Feld verfolgt die gesamte Anzahl der Übertragungen eines Incidents zwischen verschiedenen Zuordnungsgruppen (Assignment Groups). Es ist ein direktes Maß für Prozessreibung und wird oft als wichtiger Leistungsindikator (KPI) verwendet. Dieses Attribut ist der Hauptfaktor für das Handoff and Reassignment Rate Dashboard und den KPI Average Übergaben per Incident. Eine hohe Anzahl von Neuzuordnungen deutet oft auf Probleme wie Neine anfängliche Weiterleitung, mangelnde Fähigkeiten in einer Supportstufe oder unklare Prozessverantwortung hin. Die Reduzierung dieser Zahl ist ein häufiges Ziel für Prozessoptimierungsinitiativen, da sie in der Regel zu schnelleren Lösungszeiten führt.
Bedeutung
Dies misst direkt Prozessübergaben (Übergaben), einen Schlüsselindikator für Ineffizienz, Neine Weiterleitung und Verbesserungspotenziale.
Datenquelle
ServiceNow incident-Tabelle, Feld reassignment_count.
Beispiele
0135
|
|||
|
Behebungscode
ResolutionCode
|
Ein Code, der angibt, wie der Incident letztendlich gelöst wurde. | ||
|
Beschreibung
Der Lösungscode gibt die Art der angewendeten Lösung an, z. B. ob sie durch einen Benutzer gelöst, durch einen bekannten Fehler behoben oder ob eine Problemumgehung bereitgestellt wurde. Dieses Feld wird in der Regel vom Agenten beim Schließen des Vorfalls ausgefüllt. Dieses Attribut unterstützt direkt das Dashboard 'Effektivität der Lösungsart'. Es ermöglicht die Analyse, wie viele Vorfälle mit dauerhaften Lösungen im Vergleich zu temporären Problemumgehungen geschlossen werden, was ein Schlüsselindikator für Servicequalität und langfristige Stabilität ist. Eine hohe Rate an Problemumgehungen könnte darauf hindeuten, dass zugrunde liegende Probleme nicht angemessen behandelt werden.
Bedeutung
Es klärt die Lösungsmethode, was die Analyse dauerhafter Lösungen gegenüber temporären Workarounds ermöglicht und die Ursachenanalyse unterstützt.
Datenquelle
ServiceNow incident-Tabelle, Feld close_code oder ein benutzerdefiniertes Lösungs-Code-Feld.
Beispiele
Gelöst (`Workaround`)Gelöst (Dauerhaft)Nicht gelöst (**Benutzer** abgebrochen)Bekannter **Fehler**
|
|||
|
Kategorie
Category
|
Die übergeordnete Klassifizierung des Vorfalls, wie Hardware, Software oder Netzwerk. | ||
|
Beschreibung
Die Kategorie bietet eine allgemeine Klassifizierung der Vorfallart. Dies hilft, oft in Kombination mit einer Unterkategorie, bei der Weiterleitung des Vorfalls an das richtige Kundensupport und wird für die Berichterstattung und Trendanalyse verwendet. Für Process Mining ist dieses Attribut wichtig für die Dashboards 'Genauigkeit der Vorfallkategorisierung' und 'Volumen wiederkehrender Vorfälle'. Durch die Analyse von Vorfällen, bei denen die Kategorie während des Prozesses geändert wird, können Organisationen Probleme bei der initialen Triage identifizieren. Das Filtern der Prozessablauf nach Kategorie kann auch aufzeigen, ob bestimmte Arten von Vorfällen unterschiedliche Lösungspfade verfolgen oder einzigartige Engpässe aufweisen.
Bedeutung
Es ermöglicht die Analyse von Incident-Typn, hilft bei der Messung der Kategorisierungsgenauigkeit und ist maßgeblich für das Routing und die Trendanalyse.
Datenquelle
ServiceNow incident-Tabelle, Feld category.
Beispiele
`Hardware``Software`**Netzwerk**Datenbank
|
|||
|
Konfigurationselement
ConfigurationItem
|
Die spezifische IT-Komponente, der Service oder den Antrag bearbeitet.as Asset, die/das vom Vorfall betroffen ist. | ||
|
Beschreibung
Das Konfigurationselement (CI) ist das Asset aus der Configuration Management Datenbase (CMDB), das vom Vorfall betroffen ist. Dies kann ein Server, eine Anwendung, ein Laptop oder ein Netzwerkgerät sein. Die Analyse von Vorfällen nach CI ist äußerst wertvoll, um unleistungsstarke Assets oder Dienste zu identifizieren. Sie hilft dabei, die Teile der IT-Infrastruktur zu finden, die die meisten Vorfälle verursachen. Dies kann Investitionen in Upgrades oder Ersetzungen steuern. Im Process Mining kann das Filtern nach CI aufzeigen, ob Vorfälle im Zusammenhang mit kritischen Anwendungen anders oder effizienter behandelt werden als andere.
Bedeutung
Es identifiziert das betroffene Asset, was hilft, problematische Komponenten in der IT-Infrastruktur zu finden und Verbesserungsbemühungen zu fokussieren.
Datenquelle
ServiceNow incident-Tabelle, Feld cmdb_ci.
Beispiele
SAP ERP ProductionOracle DB Server 05E-Mail-Dienst
|
|||
|
Problem-ID
ProblemId
|
Die Kennung des zugehörigen ProblemDatensatzes, wenn der Vorfall mit einem größeren Problem verknüpft ist. | ||
|
Beschreibung
Die Problem-ID verknüpft einen Vorfall mit einem entsprechenden Datensatz im Problemmanagement-Modul. Dies geschieht, wenn ein Vorfall als Symptom eines größeren, zugrunde liegenden Problems identifiziert wird, das mehrere Benutzer oder Dienste betrifft. Diese Verknüpfung ist maßgeblich für das Dashboard 'Volumen wiederkehrender Vorfälle' und den KPI 'Rate wiederkehrender Vorfälle'. Sie ermöglicht es Analysten, Vorfälle zu gruppieren, die aus derselben Grundursache stammen, die vollen Auswirkungen eines Problems zu messen und die Wirksamkeit der Problemlösungsbemühungen zu verfolgen. Eine hohe Anzahl von Vorfällen, die mit Problemen verknüpft sind, weist auf eine reaktive Support-Umgebung hin.
Bedeutung
Es verknüpft Incidents mit einer Ursache, was wesentlich für die Analyse wiederkehrender Probleme und die Messung des Einflusses des Problemmanagements ist.
Datenquelle
ServiceNow incident-Tabelle, Feld problem_id.
Beispiele
PRB0040001PRB0040015PRB0040102
|
|||
|
Schweregrad
Severity
|
Das Ausmaß der geschäftlichen Auswirkungen, die durch den Vorfall verursacht wurden. | ||
|
Beschreibung
Severity definiert, wie stark ein Incident die Geschäftsabläufe beeinträchtigt. Zusammen mit der Urgency wird sie oft verwendet, um die Priorität des Incidents automatisch zu berechnen. In der Analyse ist die Severity eine Schlüsseldimension für das Dashboard "SLA Compliance Übersicht". Sie hilft Organisationen zu verstehen, ob sie die Service Levels für die störendsten Incidents einhalten. Sie bietet eine geschäftszentrierte Sicht auf die Leistungsfähigkeit und ergänzt die operative Sicht, die durch die Priorität gegeben ist.
Bedeutung
Es misst die geschäftlichen Auswirkungen eines Incidents und bietet eine wichtige Dimension für die Priorisierung von Anstrengungen und die Analyse der Leistung bei kritischen Problemen.
Datenquelle
ServiceNow incident-Tabelle, Feld severity.
Beispiele
1 – Hoch2 – Mittel3 – Niedrig
|
|||
|
SLA verletzt?
IsSlaBreached
|
Ein Kennzeichen, das anzeigt, ob die Incident-Lösung das fällige SLA-Datum überschritten hat. | ||
|
Beschreibung
Dies ist ein berechnetes boolesches Attribut, das Incidents als SLA-verstoßend kennzeichnet. Es wird abgeleitet, indem der tatsächliche Lösungs-Zeitstempel mit dem 'SLA-Fälligkeitsdatum (SLA-Fälligkeitsdatum)' verglichen wird. Liegt die Lösungszeit nach dem Fälligkeitsdatum, wird das Flag auf „Ja“ gesetzt. Dieses Attribut ist die Grundlage für das SLA Compliance Übersicht Dashboard und verwandte KPIs. Es vereinfacht die Analyse, indem ein komplexer Zeitvergleich in eine einfache „wahr/Nein“-Dimension umgewandelt wird. Dies erleichtert das Filtern aller SLA-verstoßenden Incidents und die Analyse ihrer gemeinsamen Merkmale wie Kategorie, Zuordnungsgruppe (Assignment Group) oder Priorität.
Bedeutung
Es vereinfacht die SLA-Compliance-Analyse, ermöglicht einfaches Filtern und eine detaillierte Analyse aller Incidents, die ihre Ziele nicht erreicht haben.
Datenquelle
Berechnet durch den Vergleich des 'Resolved At'-Zeitstempels mit dem 'SLA-Fälligkeitsdatum'-Zeitstempel. (Resolved At > SLA-Fälligkeitsdatum).
Beispiele
JaNein
|
|||
|
SLA-Fälligkeitsdatum (SLA-Fälligkeitsdatum)
SlaDueDate
|
Das Zieldatum und die Zielzeit, bis zu der den Antrag bearbeitet.er Vorfall gemäß seinem SLA voraussichtlich gelöst werden soll. | ||
|
Beschreibung
Das SLA-Fälligkeitsdatum ist ein berechneter Zeitstempel, der den Antrag bearbeitet.ie Lösungsfrist für einen Vorfall darstellt. Dieses Datum wird durch das Service Level Agreement (SLA) bestimmt, das mit den Merkmalen des Vorfalls wie seiner Priorität verbunden ist. Dieses Attribut ist unerlässlich für das Dashboard 'SLA-Compliance-Übersicht' und den KPI 'Rate der Nichteinhaltung von SLAs bei kritischen Vorfällen'. Es dient als Referenzwert, mit dem die tatsächliche Lösungszeit verglichen wird. Die Analyse von Vorfällen, die kurz vor ihrem SLA-Fälligkeitsdatum stehen, kann bei der proaktiven Eskalation und Priorisierung helfen.
Bedeutung
Es definiert das Lösungsziel, wodurch die Messung der SLA-Compliance und die Identifizierung von Incidents, die Gefahr laufen, ihre Ziele zu überschreiten, ermöglicht wird.
Datenquelle
Dieser Wert findet sich in der Regel in der task_sla-Tabelle, die mit der incident-Tabelle verknüpft ist. Das Feld planned_end_time ist der relevante Zeitstempel.
Beispiele
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
Wiedereröffnet
IsReopened
|
Ein Kennzeichen, das angibt, ob ein Incident nach seiner Lösung wiedereröffnet wurde. | ||
|
Beschreibung
Dieses boolesche Flag wird auf „Ja“ gesetzt, wenn der Status eines Incidents wieder auf „aktiv“ (z. B. 'In Progress') geändert wurde, nachdem er zuvor den Status 'Resolved' oder 'Closed' erreicht hatte. Dies wird in der Regel durch die Suche nach der 'Incident Reopened'-Activity im Event Log identifiziert. Wiedereröffnete Incidents sind ein starker Indikator für unvollständige oder ineffektive Lösungen. Die Analyse dieser Fälle hilft, vorzeitige Abschlüsse oder wiederkehrende Probleme zu identifizieren, die beim ersten Mal nicht richtig behoben wurden. Eine hohe Wiedereröffnungsrate kann die Benutzerzufriedenheit und TeamProduktivität negativ beeinflussen, was dies zu einer Schlüsselmetrik für die Qualitätskontrolle macht.
Bedeutung
Dieses Flag identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, die nach ihrer vermeintlichen Lösung zusätzliche Arbeit erforderten.
Datenquelle
Berechnet durch Überprüfung der Abfolge von Aktivitäten für jeden Vorfall, um festzustellen, ob ein 'offener' Status einem 'gelösten' Status folgt.
Beispiele
JaNein
|
|||
Incident-Management-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Arbeit begonnen
|
Zeigt an, dass ein **Agent** aktiv mit der **Untersuchung** oder **Bearbeitung** des **Incidents** begonnen hat. Dies wird in der **Regel** abgeleitet, wenn der **Status** des **Incidents** von 'Neu' oder 'Zugewiesen' in einen aktiven **Status** wie 'In Bearbeitung' wechselt. | ||
|
Bedeutung
Dieser Meilenstein markiert das Ende der anfänglichen Wartezeit (Queue Time) und den Beginn der aktiven Lösungsbemühungen. Die Messung der Zeit, bis Arbeit beginnt, ist maßgeblich für die Engpassanalyse.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung, wann das Feld 'state' in der Tabelle 'incident' in einen Wert wechselt, der aktive Arbeit darstellt, wie 'In Bearbeitung'.
Erfassen
Identifizieren Sie den Zeitstempel, wenn sich das Feld 'state' in 'In Progress' oder einen ähnlichen Wert ändert.
Ereignistyp
inferred
|
|||
|
Behebung Vorgeschlagen
|
Markiert den **Zeitpunkt**, an dem ein **Support-Agent** eine **Lösung** implementiert und den **Incident** in den **Status** 'Gelöst' versetzt hat. Dies ist ein wichtiger **Meilenstein** vor dem endgültigen **Abschluss**. | ||
|
Bedeutung
Diese Aktivität signalisiert das Ende der aktiven Arbeit und den Beginn der Bestätigungsphase. Die Zeit zwischen diesem Status und 'Vorfall geschlossen' kann Verzögerungen bei der Benutzerbestätigung oder –verifizierung aufzeigen.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit', wenn das Feld 'state' in der Tabelle 'incident' zu 'Gelöst' wechselt. Der 'resolved_at' Zeitstempel wird oft zu diesem Zeitpunkt gefüllt.
Erfassen
Verwenden Sie den Zeitstempel, wenn das Statusfeld 'Resolved' wird, oder den Antrag bearbeitet.en 'resolved_at' Zeitstempel.
Ereignistyp
inferred
|
|||
|
Incident an Gruppe zugewiesen
|
Diese Aktivität tritt auf, wenn ein Vorfall einer spezifischen Support-Gruppe zur Bearbeitung zugewiesen wird. Sie ist ein Schlüsselschritt im Routing-Prozess und wird durch die Beobachtung von Änderungen im Feld der Zuweisungsgruppe erfasst. | ||
|
Bedeutung
Die Verfolgung von Zuweisungen ist unerlässlich, um Übergaben, Wartezeiten (Queue Times) für jede Gruppe und Ineffizienzen bei der Weiterleitung oder Engpässe zu analysierenn.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assignment_group' in der Tabelle 'incident' gefüllt oder geändert wird.
Erfassen
Verwenden Sie den Zeitstempel aus dem Audit-Log für Änderungen am Feld 'assignment_group'.
Ereignistyp
inferred
|
|||
|
Incident erstellt
|
Markiert den **Beginn** des Incident-**Lebenszyklus**, wenn ein neuer Incident formal in **ServiceNow** protokolliert wird. Dieses Event wird explizit mit dem **Erstellungs-Zeitstempel** des Incident Datensatzs erfasst. | ||
|
Bedeutung
Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Lösung ist die Basis für die Messung der gesamten Durchlaufzeit und SLA Compliance.
Datenquelle
Der sys_created_on-Zeitstempel in der incident-Tabelle dient als expliziter Event Zeitstempel für diese Activity.
Erfassen
Verwenden Sie den 'sys_created_on' Zeitstempel aus dem Incident-Datensatz.
Ereignistyp
explicit
|
|||
|
Incident geschlossen
|
Dies ist die abschließende Activity im Lebenszyklus, die anzeigt, dass der Incident vollständig gelöst, bestätigt und keine weiteren Maßnahmen erforderlich sind. Das Event wird explizit über den Abschluss-Zeitstempel erfasst. | ||
|
Bedeutung
Als definitiver End-Event ist diese Aktivität wichtig für die Berechnung der gesamten Lebenszyklusdauer von Vorfällen und die Analyse der Zeit, die für die Nachbearbeitung nach der Lösung benötigt wird.
Datenquelle
Der closed_at-Zeitstempel in der incident-Tabelle dient als expliziter Event Zeitstempel. Dieser wird in der Regel gesetzt, wenn sich das state-Feld in „Closed“ ändert.
Erfassen
Verwenden Sie den 'closed_at' Zeitstempel aus dem Incident-Datensatz.
Ereignistyp
explicit
|
|||
|
Zuweisungsgruppe geändert
|
Stellt eine Übergabe (Handoff) dar, bei der ein Incident von einer Support-Gruppe an eine andere übertragen wird. Dies wird durch die Beobachtung nachfolgender Änderungen im assignment_group-Feld nach dessen Erstbefüllung erfasst. | ||
|
Bedeutung
Häufige Neuvergaben können auf eine Neine anfängliche Weiterleitung, Prozesskomplexität oder Wissenslücken hindeuten. Diese Aktivität ist maßgeblich für die Messung des KPI 'Durchschnittliche Übergaben pro Incident'.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung jeder Änderung am Feld 'assignment_group' nach der anfänglichen Zuweisung.
Erfassen
Identifizieren Sie jede mit einem Zeitstempel versehene Änderung des Feldes 'assignment_group' im Audit-Log.
Ereignistyp
inferred
|
|||
|
Incident an Agent zugewiesen
|
Stellt den Zeitpunkt dar, an dem ein spezifischer Agent innerhalb einer Support-Gruppe die Verantwortung für den Incident übernimmt. Dies wird durch die Überwachung von Änderungen im assigned_to-Feld erfasst. | ||
|
Bedeutung
Dies bietet einen detaillierten Einblick in die Arbeitslast der Mitarbeiter und die Erstkontaktlösung. Es hilft zu bestimmen, wie lange Incidents auf einen Mitarbeiter warten, bis die Arbeit beginnt, nachdem sie einer Gruppe zugewiesen wurden.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assigned_to' in der Tabelle 'incident' gefüllt oder geändert wird.
Erfassen
Verwenden Sie den Zeitstempel aus dem Audit-Log für Änderungen am Feld 'assigned_to'.
Ereignistyp
inferred
|
|||
|
Incident eskaliert
|
Tritt auf, wenn die **Priorität** oder **Schwere** eines **Incidents** erhöht wird, was oft eine schnellere **Reaktion** oder andere **Ressourcen** erfordert. Dies wird durch die **Erkennung** einer **Erhöhung** des **Wertes** im **Feld** 'Priorität' abgeleitet. | ||
|
Bedeutung
Eskalationen deuten oft darauf hin, dass ein Incident schwerwiegender ist als ursprünglich angenommen oder kurz vor einer SLA-Verletzung steht. Die Analyse dieser Ereignisse hilft, Prozessausnahmen zu verstehen.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung einer Änderung im Feld 'Priorität' zu einem Wert mit höherer Dringlichkeit.
Erfassen
Erkennt, wenn der Wert des Feldes 'priority' ansteigt (z.B. von '3 – Moderate' zu '2 – High').
Ereignistyp
inferred
|
|||
|
Incident kategorisiert
|
Stellt die initiale Klassifizierung des Incidents dar, bei der Felder wie Category, Subcategory und Priority festgelegt werden. Dieses Event wird in der Regel aus dem Audit-Trail abgeleitet, wenn diese Felder erstmals befüllt oder kurz nach der Erstellung aktualisiert werden. | ||
|
Bedeutung
Eine präzise Kategorisierung ist maßgeblich für die korrekte Weiterleitung und Priorisierung. Das Verfolgen dieser Aktivität hilft, Rekategorisierungsraten und deren Auswirkungen auf die Lösungszeit zu analysierenn.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung der ersten Änderung in Feldern wie 'Kategorie', 'Unterkategorie' oder 'Priorität' für einen bestimmten Incident.
Erfassen
Identifizieren Sie den Zeitstempel der ersten Aktualisierung von Klassifizierungsfeldern im Audit-Log.
Ereignistyp
inferred
|
|||
|
Incident mit Problem verknüpft
|
Diese Aktivität tritt auf, wenn ein Vorfall formal mit einem ProblemDatensatz verknüpft wird, was darauf hinweist, dass er Teil eines größeren, zugrunde liegenden Problems ist. Dies wird abgeleitet, wenn das Feld 'problem_id' im Vorfall-Datensatz gefüllt wird. | ||
|
Bedeutung
Die Verknüpfung mit einem Problem ist ein wichtiger Schritt, um von der reaktiven Incident-Behebung zur proaktiven Ursachenanalyse überzugehen. Sie unterstützt das Dashboard 'Wiederkehrendes Incident-Volumen'.
Datenquelle
Abgeleitet durch die Erkennung, wenn das Referenzfeld 'problem_id' in der Tabelle 'incident' mit einem Wert gefüllt wird.
Erfassen
Identifizieren Sie den Zeitstempel aus dem Audit-Log, wenn das Feld 'problem_id' gefüllt wird.
Ereignistyp
inferred
|
|||
|
Incident wiedereröffnet
|
Tritt auf, wenn ein **Benutzer** meldet, dass das **Problem** weiterhin besteht, nachdem es als gelöst markiert wurde. Dies wird abgeleitet, wenn der Incident-**Status** von 'Gelöst' zurück in einen aktiven **Status** wie 'In Bearbeitung' wechselt. | ||
|
Bedeutung
Wiedereröffnete Incidents deuten auf gescheiterte Lösungen und Nacharbeit (Rework) hin. Die Verfolgung dieser Activity ist maßgeblich für die Messung der Lösungsqualität und der First-Time Fix Rates.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Erkennung eines Statusfeld-Übergangs von 'Gelöst' zurück in einen aktiven Status wie 'In Bearbeitung' oder 'Zugewiesen'.
Erfassen
Identifizieren Sie den Zeitstempel, wenn 'state' von 'Resolved' zu einem aktiven Wert wechselt.
Ereignistyp
inferred
|
|||
|
Support-Kommentar hinzugefügt
|
Ein Support-Mitarbeiter fügt eine Arbeitsnotiz oder einen für den Benutzer sichtbaren Kommentar hinzu. Dies ist ein explizites Ereignis, das im Aktivitäten-Stream des Incidents protokolliert wird. | ||
|
Bedeutung
Verfolgt Kommunikations- und Untersuchungsbemühungen des Kundensupports. Die Analyse der Häufigkeit und des Zeitpunkts dieser Kommentare liefert Einblicke in den Untersuchungsprozess.
Datenquelle
Erfasst aus der Tabelle 'sys_journal_field', die Einträge für die Felder 'work_notes' und 'comments' in der Tabelle 'incident' protokolliert.
Erfassen
Verwenden Sie den Erstellungs-Zeitstempel von Journaleinträgen, bei denen das Element 'work_notes' oder 'comments' ist.
Ereignistyp
explicit
|
|||
|
Warten auf Benutzerbestätigung
|
Der Vorfall befindet sich in einem schwebenden Zustand und wartet darauf, dass der Benutzer bestätigt, dass die vorgeschlagene Lösung erfolgreich war. Dies wird in der Regel aus einem bestimmten Status wie 'Warten auf BenutzerHinweisrmationen' nach der Lösung abgeleitet. | ||
|
Bedeutung
Dieser Status kann ein erhebliches Bottleneck darstellen, wenn Benutzer langsam reagieren. Die Messung der in dieser Activity verbrachten Zeit hilft, Kommunikationslücken und Möglichkeiten zur Automatisierung des Abschlusses zu identifizieren.
Datenquelle
Abgeleitet aus der Tabelle 'sys_audit' durch Identifizierung einer Änderung in einen spezifischen Wartezustand nach der Lösung. Der Statusname kann benutzerdefiniert sein, wie zum Beispiel 'Wartet auf Anrufer'.
Erfassen
Identifizieren Sie den Zeitstempel, wenn sich 'state' in einen Wert ändert, der auf eine Benutzeraktion wartet.
Ereignistyp
inferred
|
|||