Daten-Template: Incident Management
Ihr Incident Management Data Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung für ServiceNow Problem Management
Incident Management-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Events oder der Aufgabe, das/die zu einem bestimmten Zeitpunkt innerhalb des Vorfall-Lebenszyklus stattfand. | ||
|
Beschreibung
Der Activity Name 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 typischerweise aus Änderungen in wichtigen Incident Fields wie „State“ oder „Assignment Group“ oder aus spezifischen Log Entries abgeleitet. Dieses Attribut ist entscheidend für den Aufbau der Process Map. Es definiert die Knoten im Process Graph und ermöglicht Analysten, den Flow von Incidents zu visualisieren, gängige Pfade zu identifizieren, Bottlenecks zwischen Activities zu entdecken und Prozessvarianten zu analysieren. Die Granularität und Genauigkeit dieser Activity Names wirken sich direkt auf die Qualität der Process Analysis aus.
Warum es wichtig ist
Es definiert die Schritte in der Process Map, die die Grundlage für alle Process Mining Analysen und Visualisierungen bildet.
Woher erhalten
Dies ist ein abgeleitetes Attribut, das typischerweise 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ändertLösung vorgeschlagenIncident geschlossen
|
|||
|
Ereigniszeit
EventTime
|
Der präzise Timestamp, der anzeigt, wann die Aktivität stattfand. | ||
|
Beschreibung
Event Time, oft als Timestamp bezeichnet, erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen oder eine Statusänderung erfolgte. In ServiceNow wird dies typischerweise 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 Events und für alle zeitbasierten Analysen. Es wird verwendet, um Zykluszeiten, Wartezeiten und Dauern 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 Timestamps ist entscheidend für die Gültigkeit aller dauernbasierten Metriken.
Warum es wichtig ist
Dieser Timestamp ordnet alle Activities chronologisch und ermöglicht die Berechnung aller dauerbasierten Metriken, wie Cycle Times und Bottlenecks.
Woher erhalten
ServiceNow sys_audit-Tabelle, Feld sys_created_on oder das 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
|
|||
|
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-Identifikator, der alle zugehörigen Aktivitäten, Aktualisierungen und Kommunikationen 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 Events für jeden einzelnen Case zusammenzufügen und bildet die Basis für die Entdeckung von Prozesslandkarten, 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.
Warum es wichtig ist
Dies ist die essentielle Case ID, die alle Events im Lebenszyklus eines Incidents miteinander verbindet und so eine End-to-End-Prozessanalyse ermöglicht.
Woher erhalten
ServiceNow incident-Tabelle, Feld number.
Beispiele
INC0010001INC0010045INC0010239
|
|||
|
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 entscheidend 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 Events ist. Sie hilft, Erwartungen an die Relevanz und Aktualität der Daten zu steuern.
Warum es wichtig ist
Es informiert Benutzer über die Aktualität der Daten, was entscheidend für die Relevanz und Genauigkeit der Analyse ist.
Woher erhalten
Dieser Timestamp 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 Problem Management. Es ist typischerweise 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 entscheidend 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.
Warum es wichtig ist
Es liefert entscheidenden Kontext zur Datenherkunft, sichert die Data Lineage und ermöglicht eine korrekte Interpretation in Multi-System-Umgebungen.
Woher erhalten
Dies ist typischerweise ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird.
Beispiele
ServiceNow Problem ManagementServiceNow
|
|||
|
Incident-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 Prozesslandkarte und zeigt, wie Vorfälle bis zur Lösung voranschreiten.
Warum es wichtig ist
Es verfolgt den Fortschritt des Incidents und ist entscheidend für die Analyse der in verschiedenen Phasen verbrachten Zeit und die Identifizierung von Process Bottlenecks.
Woher erhalten
ServiceNow incident-Tabelle, Feld incident_state oder state.
Beispiele
NeuIn BearbeitungWartet auf BenutzerinformationenResolvedGeschlossen
|
|||
|
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 typischerweise aus dem Impact und der Urgency des Incidents ab und beeinflusst direkt die SLA-Ziele. Dieses Attribut ist grundlegend für die Segmentierung und Performance-Analyse. Das Dashboard "SLA Compliance Overview" nutzt die Priorität, um zu bewerten, ob hochpriorisierte Incidents innerhalb ihrer Zielzeiten gelöst werden. Die Analyse der Cycle Times nach Priorität hilft zu bestätigen, dass kritische Incidents tatsächlich schneller bearbeitet werden als weniger wichtige. Es ist eine entscheidende Dimension für fast jedes KPI und Dashboard.
Warum es wichtig ist
Es ermöglicht die Segmentierung von Incidents nach geschäftlicher Bedeutung, was für die Überwachung der SLA-Compliance und die Ressourcenzuweisung entscheidend ist.
Woher erhalten
ServiceNow incident-Tabelle, Feld priority.
Beispiele
1 - Kritisch2 - Hoch3 - Moderat4 - Niedrig
|
|||
|
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 entscheidend, 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.
Warum es wichtig ist
Es ermöglicht die Analyse der Agentenarbeitslast, Leistung und individuellen Übergaben, die entscheidend für das Verständnis der Ressourceneffizienz sind.
Woher erhalten
ServiceNow incident-Tabelle, Feld assigned_to.
Beispiele
Beth AnglinDavid LooHoward Johnson
|
|||
|
Zuweisungsgruppe
AssignmentGroup
|
Das Support-Team oder die 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 entscheidend 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.
Warum es wichtig ist
Dies verfolgt, welches Team verantwortlich ist, und ermöglicht die Analyse von Teamleistung, Arbeitslast und Handoffs zwischen Gruppen.
Woher erhalten
ServiceNow incident-Tabelle, Feld assignment_group.
Beispiele
Service Desk**Netzwerk-Support**Datenbankadministratoren
|
|||
|
Anrufer
CallerId
|
Der Benutzer, der den 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.
Warum es wichtig ist
Es identifiziert den betroffenen Benutzer, was eine Analyse nach Abteilung oder Individuum ermöglicht und Kontext für die Benutzerkommunikation bietet.
Woher erhalten
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 primäre Treiber für das Handoff and Reassignment Rate Dashboard und den KPI Average Handoffs per Incident. Eine hohe Anzahl von Neuzuordnungen deutet oft auf Probleme wie falsche anfängliche Weiterleitung, mangelnde Fähigkeiten in einer Supportstufe oder unklare Prozessverantwortung hin. Die Reduzierung dieser Zahl ist ein häufiges Ziel für Prozessverbesserungsinitiativen, da sie typischerweise zu schnelleren Lösungszeiten führt.
Warum es wichtig ist
Dies misst direkt Prozessübergaben (Handoffs), einen Schlüsselindikator für Ineffizienz, falsche Weiterleitung und Verbesserungspotenziale.
Woher erhalten
ServiceNow incident-Tabelle, Feld reassignment_count.
Beispiele
0135
|
|||
|
Durchlaufzeit
CycleTime
|
Die Gesamtdauer von der Erstellung eines Vorfalls bis zu seinem Abschluss. | ||
|
Beschreibung
Die Cycle Time ist eine berechnete Metrik, die die End-to-End-Dauer des Incident Management Prozesses für einen einzelnen Case darstellt. Sie wird typischerweise als Differenz zwischen dem 'Closed'-Timestamp und dem 'Created'-Timestamp berechnet. Dies ist eine der fundamentalsten KPIs im Process Mining, die das 'Incident Resolution Cycle Time'-Dashboard direkt unterstützt. Die Analyse der durchschnittlichen Cycle Time sowie ihrer Verteilung hilft Organisationen, die Gesamteffizienz zu messen, Leistungs-Baselines festzulegen und die Auswirkungen von Prozessänderungen zu identifizieren. Die Aufschlüsselung dieser Metrik nach Attributen wie Priorität oder Kategorie zeigt, welche Arten von Vorfällen am längsten zur Behebung benötigen.
Warum es wichtig ist
Dieser zentrale KPI misst die End-to-End-Effizienz des Prozesses und wird verwendet, um langwierige Cases zu identifizieren und die Gesamtleistung zu verfolgen.
Woher erhalten
Berechnet durch Subtraktion des ersten Event-Timestamps vom letzten Event-Timestamps für jede Incident ID.
Beispiele
2592008640001209600
|
|||
|
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 Support-Team und wird für die Berichterstattung und Trendanalyse verwendet. Für Process Mining ist dieses Attribut entscheidend 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 Prozesslandkarte nach Kategorie kann auch aufzeigen, ob bestimmte Arten von Vorfällen unterschiedliche Lösungspfade verfolgen oder einzigartige Engpässe aufweisen.
Warum es wichtig ist
Es ermöglicht die Analyse von Incident-Typen, hilft bei der Messung der Kategorisierungsgenauigkeit und ist entscheidend für das Routing und die Trendanalyse.
Woher erhalten
ServiceNow incident-Tabelle, Feld category.
Beispiele
HardwareSoftware**Netzwerk**Datenbank
|
|||
|
Konfigurationselement
ConfigurationItem
|
Die spezifische IT-Komponente, der Service oder das Asset, die/das vom Vorfall betroffen ist. | ||
|
Beschreibung
Das Konfigurationselement (CI) ist das Asset aus der Configuration Management Database (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 unzuverlässige Assets oder Services zu identifizieren. Sie hilft dabei, die Teile der IT-Infrastruktur zu lokalisieren, 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.
Warum es wichtig ist
Es identifiziert das betroffene Asset, was hilft, problematische Komponenten in der IT-Infrastruktur zu lokalisieren und Verbesserungsbemühungen zu fokussieren.
Woher erhalten
ServiceNow incident-Tabelle, Feld cmdb_ci.
Beispiele
SAP ERP ProductionOracle DB Server 05E-Mail-Dienst
|
|||
|
Lösungscode
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 typischerweise 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.
Warum es wichtig ist
Es klärt die Lösungsmethode, was die Analyse dauerhafter Lösungen gegenüber temporären Workarounds ermöglicht und die Ursachenanalyse unterstützt.
Woher erhalten
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**
|
|||
|
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 Services betrifft. Diese Verknüpfung ist entscheidend 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.
Warum es wichtig ist
Es verknüpft Incidents mit einer Ursache, was wesentlich für die Analyse wiederkehrender Probleme und die Messung des Einflusses des Problem Managements ist.
Woher erhalten
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 Overview". 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 Performance und ergänzt die operative Sicht, die durch die Priorität gegeben ist.
Warum es wichtig ist
Es misst die geschäftlichen Auswirkungen eines Incidents und bietet eine entscheidende Dimension für die Priorisierung von Anstrengungen und die Analyse der Leistung bei kritischen Problemen.
Woher erhalten
ServiceNow incident-Tabelle, Feld severity.
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
SLA Due Date
SlaDueDate
|
Das Zieldatum und die Zielzeit, bis zu der der Vorfall gemäß seinem SLA voraussichtlich gelöst werden soll. | ||
|
Beschreibung
Das SLA-Fälligkeitsdatum ist ein berechneter Timestamp, der die 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 Maßstab, 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.
Warum es wichtig ist
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.
Woher erhalten
Dieser Wert findet sich typischerweise in der task_sla-Tabelle, die mit der incident-Tabelle verknüpft ist. Das Feld planned_end_time ist der relevante Timestamp.
Beispiele
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
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-Timestamp mit dem 'SLA Due Date' verglichen wird. Liegt die Lösungszeit nach dem Fälligkeitsdatum, wird das Flag auf „true“ gesetzt. Dieses Attribut ist die Grundlage für das SLA Compliance Overview Dashboard und verwandte KPIs. Es vereinfacht die Analyse, indem ein komplexer Zeitvergleich in eine einfache „wahr/falsch“-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.
Warum es wichtig ist
Es vereinfacht die SLA-Compliance-Analyse, ermöglicht einfaches Filtern und eine detaillierte Analyse aller Incidents, die ihre Ziele nicht erreicht haben.
Woher erhalten
Berechnet durch den Vergleich des 'Resolved At'-Timestamps mit dem 'SlaDueDate'-Timestamp. (Resolved At > SlaDueDate).
Beispiele
truefalsch
|
|||
|
Wiedereröffnet
IsReopened
|
Ein Kennzeichen, das angibt, ob ein Incident nach seiner Lösung wiedereröffnet wurde. | ||
|
Beschreibung
Dieses boolesche Flag wird auf „true“ 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 typischerweise 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 Cases 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.
Warum es wichtig ist
Dieses Flag identifiziert Fehler im Lösungsprozess und hebt Incidents hervor, die nach ihrer vermeintlichen Lösung zusätzliche Arbeit erforderten.
Woher erhalten
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
truefalsch
|
|||
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. | ||
|
Warum es wichtig ist
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 entscheidend für die Bottleneck-Analyse.
Woher erhalten
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 Timestamp, wenn sich das Feld 'state' in 'In Progress' oder einen ähnlichen Wert ändert.
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. | ||
|
Warum es wichtig ist
Die Verfolgung von Zuweisungen ist unerlässlich, um Handoffs, Wartezeiten (Queue Times) für jede Gruppe und Ineffizienzen bei der Weiterleitung oder Bottlenecks zu analysieren.
Woher erhalten
Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assignment_group' in der Tabelle 'incident' gefüllt oder geändert wird.
Erfassen
Nutzen Sie den Timestamp 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-Timestamp** des Incident Records erfasst. | ||
|
Warum es wichtig ist
Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Lösung ist grundlegend für die Messung der gesamten Cycle Time und SLA Compliance.
Woher erhalten
Der sys_created_on-Timestamp in der incident-Tabelle dient als expliziter Event Timestamp für diese Activity.
Erfassen
Nutzen Sie den 'sys_created_on' Timestamp 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-Timestamp erfasst. | ||
|
Warum es wichtig ist
Als definitiver End-Event ist diese Aktivität entscheidend 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.
Woher erhalten
Der closed_at-Timestamp in der incident-Tabelle dient als expliziter Event Timestamp. Dieser wird typischerweise gesetzt, wenn sich das state-Feld in „Closed“ ändert.
Erfassen
Nutzen Sie den 'closed_at' Timestamp aus dem Incident-Datensatz.
Ereignistyp
explicit
|
|||
|
Lösung 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**. | ||
|
Warum es wichtig ist
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.
Woher erhalten
Abgeleitet aus der Tabelle 'sys_audit', wenn das Feld 'state' in der Tabelle 'incident' zu 'Gelöst' wechselt. Der 'resolved_at' Timestamp wird oft zu diesem Zeitpunkt gefüllt.
Erfassen
Nutzen Sie den Timestamp, wenn das Statusfeld 'Resolved' wird, oder den 'resolved_at' Timestamp.
Ereignistyp
inferred
|
|||
|
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. | ||
|
Warum es wichtig ist
Häufige Neuvergaben können auf eine falsche anfängliche Weiterleitung, Prozesskomplexität oder Wissenslücken hindeuten. Diese Aktivität ist entscheidend für die Messung des KPI 'Durchschnittliche Übergaben pro Incident'.
Woher erhalten
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 Timestamp 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. | ||
|
Warum es wichtig ist
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.
Woher erhalten
Abgeleitet aus der Tabelle 'sys_audit' durch Nachverfolgung, wann das Feld 'assigned_to' in der Tabelle 'incident' gefüllt oder geändert wird.
Erfassen
Nutzen Sie den Timestamp 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. | ||
|
Warum es wichtig ist
Eskalationen deuten oft darauf hin, dass ein Incident schwerwiegender ist als ursprünglich angenommen oder kurz vor einer SLA-Verletzung steht. Die Analyse dieser Events hilft, Prozessausnahmen zu verstehen.
Woher erhalten
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 typischerweise aus dem Audit Trail abgeleitet, wenn diese Felder erstmals befüllt oder kurz nach der Erstellung aktualisiert werden. | ||
|
Warum es wichtig ist
Eine präzise Kategorisierung ist entscheidend für die korrekte Weiterleitung und Priorisierung. Das Verfolgen dieser Aktivität hilft, Rekategorisierungsraten und deren Auswirkungen auf die Lösungszeit zu analysieren.
Woher erhalten
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 Timestamp 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. | ||
|
Warum es wichtig ist
Die Verknüpfung mit einem Problem ist ein entscheidender Schritt, um von der reaktiven Incident-Behebung zur proaktiven Ursachenanalyse überzugehen. Sie unterstützt das Dashboard 'Wiederkehrendes Incident-Volumen'.
Woher erhalten
Abgeleitet durch die Erkennung, wenn das Referenzfeld 'problem_id' in der Tabelle 'incident' mit einem Wert gefüllt wird.
Erfassen
Identifizieren Sie den Timestamp 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. | ||
|
Warum es wichtig ist
Wiedereröffnete Incidents deuten auf gescheiterte Lösungen und Nacharbeit (Rework) hin. Die Verfolgung dieser Activity ist entscheidend für die Messung der Lösungsqualität und der First-Time Fix Rates.
Woher erhalten
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 Timestamp, 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. | ||
|
Warum es wichtig ist
Verfolgt Kommunikations- und Untersuchungsbemühungen des Support-Teams. Die Analyse der Häufigkeit und des Zeitpunkts dieser Kommentare liefert Einblicke in den Untersuchungsprozess.
Woher erhalten
Erfasst aus der Tabelle 'sys_journal_field', die Einträge für die Felder 'work_notes' und 'comments' in der Tabelle 'incident' protokolliert.
Erfassen
Nutzen Sie den Erstellungs-Timestamp 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 typischerweise aus einem bestimmten Status wie 'Warten auf Benutzerinformationen' nach der Lösung abgeleitet. | ||
|
Warum es wichtig ist
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.
Woher erhalten
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 Timestamp, wenn sich 'state' in einen Wert ändert, der auf eine Benutzeraktion wartet.
Ereignistyp
inferred
|
|||