Daten-Template: Incident Management
Ihr Incident Management Data Template
- Empfohlene Attribute zur Erfassung
- Schlüsselaktivitäten, die Sie für Ihren Prozess verfolgen sollten
- Extraktionsanleitung für Ihr Datensystem
Incident Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Incident-ID
IncidentId
|
Der eindeutige Identifikator für jeden Vorfalldatensatz. | ||
|
Beschreibung
Die Incident ID dient als Primärschlüssel für jeden Vorfall und identifiziert ihn eindeutig von der Erstellung bis zum Abschluss. Sie verknüpft alle zugehörigen Aktivitäten, Logs und Änderungen, was eine vollständige End-to-End-Ansicht des Vorfallslebenszyklus ermöglicht. Im Process Mining ist dieses Attribut grundlegend, da es den Case definiert. Jedes Event mit derselben Incident ID wird als Teil derselben Prozessinstanz betrachtet, was die Rekonstruktion und Analyse ermöglicht, wie individuelle Vorfälle bearbeitet werden.
Warum es wichtig ist
Dies ist der wesentliche Case-Identifikator, der alle Events im Lebenszyklus eines Vorfalls miteinander verbindet und so eine End-to-End-Prozessanalyse ermöglicht.
Woher erhalten
Dies ist das Feld Incident Number (Field ID: 1000000161) im Formular HPD:Help Desk.
Beispiele
INC000001234567INC000002345678INC000003456789
|
|||
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Events oder der Aufgabe, das/die innerhalb des Vorfallslebenszyklus aufgetreten ist. | ||
|
Beschreibung
Dieses Attribut beschreibt die Aktivität, die zu einem bestimmten Zeitpunkt für einen Vorfall durchgeführt wurde, wie zum Beispiel 'Incident Reported', 'Group Assigned' oder 'Incident Resolved'. Diese Aktivitäten sind die Bausteine der Prozesslandkarte. Die Analyse der Sequenz und Häufigkeit dieser Aktivitäten enthüllt den tatsächlichen Prozessfluss, identifiziert gängige Pfade und hebt Abweichungen vom Standardverfahren hervor. Es ist entscheidend, um zu verstehen, welche Aktionen zur Lösung eines Vorfalls unternommen werden.
Warum es wichtig ist
Aktivitäten definieren die Schritte in der Prozesskarte und ermöglichen die Visualisierung und Analyse des Incident Management Workflows.
Woher erhalten
In der Regel abgeleitet aus Änderungen der Felder 'Status' (Field ID: 7) und 'Status_Reason' im Formular 'HPD:Help Desk' oder aus dem Formular 'HPD:Help Desk Audit Log'.
Beispiele
Incident gemeldetGruppe zugewiesenLösung implementiertIncident geschlossen
|
|||
|
Ereignis-Timestamp
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieser Timestamp protokolliert, wann ein bestimmtes Event im Incident-Lebenszyklus stattgefunden hat. Er liefert die zeitliche Reihenfolge, die benötigt wird, um den Prozessfluss aus Rohdaten zu rekonstruieren. Der Event Timestamp ist die Grundlage aller zeitbezogenen Analysen: Er ermöglicht die Berechnung von Durchlaufzeiten zwischen Aktivitäten, das Erkennen von Engpässen mit langen Wartezeiten und das Messen der gesamten Lösungszeit. Er bildet das zeitliche Rückgrat der Prozessanalyse.
Warum es wichtig ist
Dieser Timestamp liefert die zeitliche Reihenfolge der Events – entscheidend, um Dauern zu berechnen, Engpässe zu erkennen und den Prozessverlauf nachzuvollziehen.
Woher erhalten
Das 'Last Modified Date' (Feld-ID: 6) oder spezifische Datumsfelder aus dem 'HPD:Help Desk'-Formular. Für historische Events wird dies aus dem Timestamp-Feld des Audit Logs bezogen.
Beispiele
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
|
|||
|
Assignee
Assignee
|
Der einzelne Benutzer, der zur Bearbeitung des Vorfalls zugewiesen ist. | ||
|
Beschreibung
Der Bearbeiter ist der spezifische Supportmitarbeiter oder Techniker, der zu einem bestimmten Zeitpunkt für den Vorfall verantwortlich ist. Dies bietet einen detaillierteren Detaillierungsgrad als die zugewiesene Gruppe. Die Analyse der Leistung nach Bearbeiter kann helfen, Top-Performer zu identifizieren, Mitarbeiter, die zusätzlichen Schulungsbedarf haben, sowie Ungleichgewichte in der Arbeitslastverteilung. Sie wird auch verwendet, um die genaue Abfolge der Aktionen nachzuvollziehen, die von Personen bei der Bearbeitung eines komplexen Vorfalls durchgeführt wurden.
Warum es wichtig ist
Bietet eine detaillierte Ansicht der Arbeitslastverteilung und individuellen Leistung und hilft, Top-Performer oder Agenten zu identifizieren, die Unterstützung benötigen.
Woher erhalten
Dies ist das Feld Assignee (Field ID: 1000000218) im Formular HPD:Help Desk.
Beispiele
Bob SmithAlice JohnsonCharlie Brown
|
|||
|
Incident-Kategorie
IncidentCategory
|
Die Klassifizierung des Vorfalls, oft in einer gestuften Struktur. | ||
|
Beschreibung
Die Incident-Kategorisierung bietet eine strukturierte Möglichkeit zur Klassifizierung von Incidents, typischerweise unter Verwendung einer mehrstufigen Hierarchie (z.B. Stufe 1: Hardware, Stufe 2: Laptop, Stufe 3: Batterie). Diese Daten sind essenziell für Routing, Reporting und Trendanalyse. Im Process Mining wird die Kategorisierung verwendet, um verschiedene Arten von Incidents separat zu analysieren. Sie unterstützt das Dashboard zur Incident Categorization Accuracy, indem sie anfängliche und endgültige Kategorien vergleicht, und hilft bei der Identifizierung von Trends für das Root Cause Trends Dashboard.
Warum es wichtig ist
Die Kategorisierung ermöglicht präzises Routing, Trendanalysen und den Leistungsvergleich über verschiedene Incident-Typen hinweg.
Woher erhalten
Dies sind die Felder 'Operational Categorization Tier 1/2/3' im Formular 'HPD:Help Desk'.
Beispiele
Hardware > Laptop > AkkuSoftware > Enterprise App > Login-FehlerNetwork > Connectivity > Wi-Fi
|
|||
|
Incident-Lösungszeit
IncidentResolutionTime
|
Die gesamte verstrichene Zeit von der erstmaligen Meldung eines Vorfalls bis zu seiner Lösung. | ||
|
Beschreibung
Dies ist eine berechnete Metrik, die die Dauer zwischen den Aktivitäten Incident Reported und Incident Resolved darstellt. Sie ist einer der häufigsten und wichtigsten KPIs im Incident Management. Diese Metrik misst direkt die Effizienz des Lösungsprozesses. Im Process Mining wird sie als primärer Leistungsindikator verwendet, der über verschiedene Vorfallkategorien, Prioritäten und Teams hinweg analysiert wird, um Verbesserungsbereiche zu identifizieren und die Auswirkungen von Prozessänderungen im Laufe der Zeit zu verfolgen.
Warum es wichtig ist
Dies ist ein entscheidender KPI, der die End-to-End-Effizienz des Incident Management-Prozesses misst und sich direkt auf die Benutzerzufriedenheit auswirkt.
Woher erhalten
Berechnet durch Subtraktion des Timestamps des ersten Events vom Timestamp des 'Incident Resolved' Events für jede Incident ID.
Beispiele
2592003600864000
|
|||
|
Incident-Status
IncidentStatus
|
Der aktuelle oder historische Status des Vorfalls zum Zeitpunkt des Events. | ||
|
Beschreibung
Dieses Attribut zeigt den Status des Vorfalls an, wie zum Beispiel 'New', 'In Progress', 'Pending', 'Resolved' oder 'Closed'. Es bietet einen Snapshot darüber, wo sich der Vorfall in seinem Lebenszyklus befindet. Die Analyse von Statusänderungen ist grundlegend, um den Incident Management Prozess zu verstehen. Es wird verwendet, um Aktivitäten zu definieren, Zeit zu messen, die in verschiedenen Status verbracht wurde (z.B. wie lange Vorfälle 'Pending' sind), und Vorfälle zu identifizieren, die möglicherweise feststecken oder inaktiv sind.
Warum es wichtig ist
Das Nachverfolgen von Statusänderungen ist entscheidend, um den Fortschritt eines Incidents zu verstehen und zu messen, wie lange er in Zuständen wie 'Pending' oder 'In Progress' verbringt.
Woher erhalten
Dies ist das Feld Status (Field ID: 7) im Formular HPD:Help Desk.
Beispiele
NewZugewiesenIn BearbeitungPendingGelöstGeschlossen
|
|||
|
Is Reopened
IsReopened
|
Ein Flag, das anzeigt, ob ein Incident nach dem Status 'Gelöst' erneut geöffnet wurde. | ||
|
Beschreibung
Dieses boolesche Attribut ist auf 'wahr' gesetzt, wenn sich der Status eines Vorfalls nach der Markierung als 'Resolved' wieder in einen aktiven Status (z.B. 'In Progress') ändert. Dies deutet darauf hin, dass die ursprüngliche Fehlerbehebung nicht effektiv oder vollständig war. Dies ist ein direktes Maß für Nacharbeit und wird zur Berechnung des KPIs Incident Rework Rate verwendet. Die Analyse wiedereröffneter Vorfälle hilft dabei, fehlerhafte Behebungen, unzureichende Tests oder wiederkehrende Probleme zu identifizieren, die nicht angemessen behandelt wurden, und unterstützt das Dashboard 'Nacharbeits- und Eskalationspfade'.
Warum es wichtig ist
Misst direkt die Nacharbeit und die Qualität der Lösungen. Eine hohe Wiederöffnungsrate deutet auf ineffektive Korrekturen und Prozessschwächen hin.
Woher erhalten
Berechnet durch die Analyse der Abfolge von Aktivitäten für einen Incident. Wenn eine Aktivität 'Incident Reopened' oder eine ähnliche Aktivität nach der Aktivität 'Resolution Implemented' erscheint, wird dieses Flag auf 'true' gesetzt.
Beispiele
truefalsch
|
|||
|
Is SLA Breached
IsSlaBreached
|
Ein Flag, das anzeigt, ob der Incident nach seinem SLA-Zieldatum gelöst wurde. | ||
|
Beschreibung
Dieses boolesche Attribut ist auf 'wahr' gesetzt, wenn die Lösungszeit eines Vorfalls die definierte SLA überschritten hat. Es liefert ein klares, binäres Ergebnis für die SLA-Leistung pro Vorfall. Dieser Indikator ist entscheidend für die Erstellung des Dashboards 'Übersicht der Incident SLA-Performance' und die Berechnung des KPIs Incident SLA Compliance Rate. Er vereinfacht die Analyse, indem er eine direkte Filterung und Aggregation aller Vorfälle ermöglicht, die ihre Service-Level-Ziele nicht erreicht haben, was die Untersuchung der Ursachen für Verstöße erleichtert.
Warum es wichtig ist
Dieser Indikator vereinfacht die SLA-Konformitätsanalyse, da er das Filtern nach allen Vorfällen mit SLA-Verletzung und die Untersuchung der Ursachen erleichtert.
Woher erhalten
Berechnet durch Vergleich des Event-Timestamps von 'Incident Resolved' mit dem 'SlaTargetDate'. Wenn der Lösungs-Timestamp nach dem Zieldatum liegt, ist dieses Flag 'true'.
Beispiele
truefalsch
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe, die dem Vorfall zugewiesen wurde und dessen Bearbeitungsdringlichkeit bestimmt. | ||
|
Beschreibung
Die Priorität ergibt sich typischerweise aus einer Kombination von Auswirkungen und Dringlichkeit und bestimmt die Reihenfolge und Geschwindigkeit der Behebung von Incidents. Gängige Werte reichen von 'Kritisch' bis 'Niedrig'. Im Process Mining ist die Analyse von Incidents nach Priorität entscheidend für die Leistungsanalyse. Sie hilft, Fragen wie 'Erfüllen wir die SLAs für hochprioritäre Incidents?' und 'Gibt es bei Incidents mit niedriger Priorität längere Verzögerungen?' zu beantworten. Die Filterung nach Priorität ermöglicht eine fokussierte Analyse der kritischsten Geschäftsprobleme.
Warum es wichtig ist
Dieses Attribut ist entscheidend für die Analyse-Segmentierung, um sicherzustellen, dass Vorfälle mit hoher Priorität schneller bearbeitet werden und die jeweiligen Service-Level-Ziele erreicht werden.
Woher erhalten
Dies ist das Feld Priority (Field ID: 1000000164) im Formular HPD:Help Desk.
Beispiele
KritischHochMittelNiedrig
|
|||
|
Service
Service
|
Der Geschäfts- oder technische Service, der vom Vorfall betroffen ist. | ||
|
Beschreibung
Dieses Attribut verknüpft einen Vorfall mit einem in der Configuration Management Database (CMDB) definierten spezifischen Dienst, wie z.B. 'Email Service', 'VPN Access' oder 'SAP Financials'. Diese Verknüpfung ist entscheidend, um die geschäftlichen Auswirkungen von Vorfällen zu verstehen. Die Analyse von Vorfällen nach Diensten hilft dabei, problematische Dienste zu identifizieren, die eine hohe Anzahl von Vorfällen verursachen, zeigt wiederkehrende Probleme auf, die mit bestimmten Technologien verbunden sind, und unterstützt die Trendanalyse im Problemmanagement.
Warum es wichtig ist
Die Verknüpfung von Incidents mit Business-Services ist entscheidend für die Auswirkungsanalyse und um zu erkennen, welche Services am anfälligsten für Probleme sind.
Woher erhalten
Dies ist das Feld ServiceCI oder ein ähnliches Feld, das das betroffene Configuration Item (CI) im Formular HPD:Help Desk darstellt.
Beispiele
Unternehmens-E-MailSAP ERPRemote Access VPNPersonalportal
|
|||
|
Zugewiesene Gruppe
AssignedGroup
|
Die Supportgruppe, die für die Bearbeitung des Vorfalls verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut identifiziert das Team oder die Abteilung, die dem Vorfall zugewiesen ist, wie zum Beispiel 'Service Desk', 'Network Team' oder 'Database Administrators'. Das Verfolgen von Zuweisungen ist entscheidend, um den Arbeitsfluss zwischen Teams zu verstehen. Dieses Attribut wird verwendet, um Inter-Team-Übergaben zu analysieren, Bottlenecks zu identifizieren, die durch spezifische Gruppen verursacht werden, und die Incident Reassignment Rate zu messen. Es hilft, den Pfad zu visualisieren, den ein Vorfall innerhalb der Organisation nimmt, und hebt Bereiche mit ineffizientem Routing oder Wissenslücken hervor.
Warum es wichtig ist
Wenn Sie die zugewiesene Gruppe verfolgen, können Sie Übergaben analysieren, Schleifen bei Neuzuweisungen erkennen und Engpässe in einzelnen Teams gezielt benennen.
Woher erhalten
Dies ist das Feld Assigned Group (Field ID: 1000000217) im Formular HPD:Help Desk.
Beispiele
Service DeskNetzwerkbetriebApplication Support Tier 2Infrastrukturdienste
|
|||
|
Abschluss-Code
CloseCode
|
Der Code, der beim Abschließen eines Vorfalls ausgewählt wird und das Lösungsergebnis angibt. | ||
|
Beschreibung
Der Abschlusscode bietet eine strukturierte Zusammenfassung, wie ein Vorfall gelöst wurde. Beispiele sind 'Resolved by User', 'No Fault Found', 'Duplicate Incident' oder 'Permanent Fix Applied'. Dieses Attribut ist wertvoll für die Analyse der Lösungseffektivität und -ergebnisse. Es kann helfen, Vorfälle zu identifizieren, die ohne echte Lösung abgeschlossen wurden, oder Kategorien hervorheben, in denen Benutzer ihre Probleme häufig selbst lösen, was auf Möglichkeiten für bessere Knowledge-Base-Artikel oder Self-Service-Tools hindeuten könnte.
Warum es wichtig ist
Bietet strukturierte Daten zu Lösungsergebnissen und hilft, die Effektivität von Korrekturen zu analysieren sowie Trends bei der Schließung von Incidents zu identifizieren.
Woher erhalten
Dies ist typischerweise Teil der Lösungs- oder Abschlussinformationen im Formular HPD:Help Desk.
Beispiele
Fernwartung gelöstDoppeltes ProblemAnwenderfehlerKeine Aktion erforderlich
|
|||
|
Anzahl der Neuzuweisungen
ReassignmentCount
|
Die Gesamtzahl der Neuzuweisungen eines Vorfalls an eine andere Gruppe. | ||
|
Beschreibung
Diese Metrik zählt, wie oft sich das Feld 'AssignedGroup' im Lebenszyklus eines Incidents geändert hat. Eine hohe Anzahl deutet auf Probleme bei der anfänglichen Zuordnung, fehlende Lösung beim ersten Kontakt oder auf komplexe Fälle hin, die Beiträge mehrerer Teams erfordern. Dieses Attribut unterstützt direkt den KPI 'Incident Reassignment Rate' sowie das Dashboard 'Incident Reassignment Cycle Analysis'. Es quantifiziert den 'Ping-Pong'-Effekt, bei dem Tickets zwischen Teams hin- und hergereicht werden – mit deutlichen Verzögerungen und Ineffizienzen im Prozess.
Warum es wichtig ist
Quantifiziert ineffizientes Routing und Handoffs und hilft, Incidents zu identifizieren, die in Neuzuweisungsschleifen zwischen Teams stecken bleiben.
Woher erhalten
Berechnet durch Zählen, wie oft sich der Wert der 'AssignedGroup' für eine bestimmte Incident ID im Event Log ändert.
Beispiele
0135
|
|||
|
Auswirkung
Impact
|
Das Maß der Auswirkung des Vorfalls auf Geschäftsprozesse. | ||
|
Beschreibung
Auswirkung bewertet das Ausmaß der nachteiligen Effekte eines Incidents auf das Geschäft. Sie wird oft auf einer Skala definiert, wie z.B. 'Umfassend/Weitreichend', 'Erheblich/Groß', 'Mäßig/Begrenzt', oder 'Gering/Lokalisiert'. In Kombination mit der Dringlichkeit bestimmt die Auswirkung die Priorität des Incidents. Eine Analyse nach Auswirkung hilft zu verstehen, welche Incidents die größte Geschäftsunterbrechung verursachen, unabhängig von ihrer technischen Komplexität. Dies ist entscheidend für die Priorisierung von Prozessverbesserungsmaßnahmen.
Warum es wichtig ist
Hilft, die geschäftliche Kritikalität eines Incidents zu quantifizieren, und ist eine Schlüsselkomponente bei der Prioritätsfestlegung sowie der Konzentration der Analyse auf hochwirksame Probleme.
Woher erhalten
Dies ist das Feld Impact (Field ID: 1000000163) im Formular HPD:Help Desk.
Beispiele
1-Umfassend/Weit verbreitet2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
Einreicher
Submitter
|
Die Person, die den Vorfall ursprünglich gemeldet hat. | ||
|
Beschreibung
Der Melder ist der Endbenutzer oder Kunde, der das Problem erlebt und gemeldet hat. Dies unterscheidet sich vom Bearbeiter, der am Vorfall arbeitet. Die Analyse von Daten nach Melder oder deren Abteilung kann helfen, spezifische Benutzergruppen zu identifizieren, die zusätzlichen Schulungsbedarf haben, oder Gruppen, die von einer bestimmten Art von Problem betroffen sind. Es bietet eine kundenorientierte Sichtweise auf den Incident Management Prozess.
Warum es wichtig ist
Identifiziert den Benutzer, der das Problem gemeldet hat, und ermöglicht so eine Analyse basierend auf Benutzerabteilung, Standort oder Rolle, um benutzerspezifische Trends zu finden.
Woher erhalten
Diese Informationen werden im Feld Submitter oder in Feldern erfasst, die sich auf die Kundeninformationen im Formular HPD:Help Desk beziehen.
Beispiele
John DoeJane SmithPeter Jones
|
|||
|
Grundursache
RootCause
|
Der zugrunde liegende Grund oder die ultimative Ursache des Vorfalls. | ||
|
Beschreibung
Die Grundursache ist das grundlegende Problem, das, wenn es behoben wird, verhindern würde, dass der Vorfall erneut auftritt. Dies wird oft im Rahmen eines zugehörigen Problemuntersuchungsprozesses identifiziert. Obwohl nicht alle Vorfälle eine dokumentierte Grundursache haben werden, ist die Analyse dieses Attributs entscheidend für ein proaktives Problem Management. Es unterstützt den KPI 'Grundursachen-Identifikationsrate' und hilft bei der Erstellung von Dashboards, die Trends bei wiederkehrenden Problemen verfolgen und Bemühungen zur Implementierung dauerhafter Lösungen leiten.
Warum es wichtig ist
Die Identifizierung der Grundursache ist essenziell für das Problem Management und für Analysen, die darauf abzielen, das Volumen wiederkehrender Incidents zu reduzieren.
Woher erhalten
Diese Informationen könnten sich in einem dedizierten Root Cause-Feld des Vorfalls oder, häufiger, in einem verknüpften Formular PBI:Problem Investigation befinden.
Beispiele
Unzureichender Festplattenspeicher auf dem ServerNetzwerkkonfigurationsfehlerSoftware-Bug in Version 2.1Abgelaufenes Sicherheitszertifikat
|
|||
|
Kanal
Channel
|
Die Methode, die zur Meldung des Vorfalls verwendet wurde. | ||
|
Beschreibung
Dieses Attribut gibt an, auf welchem Weg der Vorfall übermittelt wurde, z.B. per Telefonanruf, E-Mail, über ein Self-Service-Portal oder durch persönliche Vorsprache. Es kennzeichnet den Eintrittspunkt des Vorfalls in den Supportprozess. Die Analyse von Vorfällen nach Einreichungskanal kann aufzeigen, welche Kanäle die effektivsten sind oder welche Vorfälle verursachen, die einfacher oder schwieriger zu lösen sind. Sie kann auch als Grundlage für Entscheidungen dienen, wo in Automatisierung oder Benutzerschulungen investiert werden soll, beispielsweise durch die Förderung der Nutzung eines Self-Service-Portals, das bessere Initialdaten erfasst.
Warum es wichtig ist
Wenn Sie den Eingangskanal kennen, können Sie die Effizienz der verschiedenen Meldewege vergleichen und gezielt in Self-Service oder Automatisierung investieren.
Woher erhalten
Dies ist das Feld Reported Source (Field ID: 1000000215) im Formular HPD:Help Desk.
Beispiele
E-MailTelefonSelf-ServiceDirekte Eingabe
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion. Es bietet Kontext zur Aktualität der analysierten Daten, was wichtig ist, um zu verstehen, wie aktuell die Prozesseinblicke sind. Die Kenntnis des letzten Aktualisierungszeitpunkts ist entscheidend für Reporting und die Dashboard-Erstellung, da sie die Nutzer über die Datenaktualität informiert und hilft, Erwartungen bezüglich der Berücksichtigung neuester Vorfallaktivitäten zu steuern.
Warum es wichtig ist
Zeigt die Aktualität der Daten an, um sicherzustellen, dass Benutzer verstehen, wie aktuell die Prozessanalyse und die daraus resultierenden Erkenntnisse sind.
Woher erhalten
Dieser Wert wird üblicherweise während der Datenextraktion (ETL) erzeugt und im Datensatz vermerkt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Lösungsbeschreibung
Resolution
|
Eine Freitextbeschreibung der zur Behebung des Incidents unternommenen Schritte. | ||
|
Beschreibung
Dieses Feld enthält die detaillierte, von Menschen verfasste Zusammenfassung der finalen Lösung. Es erklärt, welche Schritte unternommen wurden, um das Problem zu beheben und den Dienst für den Benutzer wiederherzustellen. Obwohl unstrukturiert, können diese Textdaten mittels Text Mining-Techniken analysiert werden, um gemeinsame Lösungsmuster zu identifizieren, Schlüsselwörter im Zusammenhang mit spezifischen Problemen zu extrahieren oder die Ursachenanalyse zu ergänzen. Es liefert einen qualitativen Kontext, der strukturierten Datenfeldern oft fehlt.
Warum es wichtig ist
Bietet qualitative Details zur Lösung, die im Text Mining verwendet werden können, um Muster zu finden, die in strukturierten Daten nicht sichtbar sind.
Woher erhalten
Dies ist das Feld Resolution (Field ID: 1000000156) im Formular HPD:Help Desk.
Beispiele
Das Passwort des Nutzers wurde über Active Directory zurückgesetzt.Cache und Cookies im Browser geleert, was das Login-Problem gelöst hat.Netzwerk-Switch in IDF-Schrank 3B neu gestartet.
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Vorfalldaten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert den Ursprung der Daten, was besonders nützlich in Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen ist. Es bestätigt, dass die Daten aus der erwarteten Quelle stammen, wie zum Beispiel einer spezifischen BMC Helix ITSM Instanz. In der Analyse hilft es, Prozesse oder Datenmerkmale zu differenzieren, die zwischen Produktions-, Entwicklungs- oder Legacy-Systemen variieren können, und stellt sicher, dass die Data Lineage klar und vertrauenswürdig ist.
Warum es wichtig ist
Identifiziert den Ursprung der Daten, was entscheidend für die Datenvalidierung und die Verwaltung von Analysen über mehrere integrierte Systeme hinweg ist.
Woher erhalten
In der Regel ist dies ein statischer Wert, der während des ETL-Prozesses (Extraktion, Transformation, Laden) hinzugefügt wird.
Beispiele
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
|
|||
|
SLA-Zieldatum
SlaTargetDate
|
Das Datum und die Uhrzeit, bis zu der der Vorfall gemäß seiner SLA voraussichtlich gelöst sein sollte. | ||
|
Beschreibung
Dieses Attribut speichert die Frist für die Vorfalllösung, die durch das geltende Service Level Agreement (SLA) definiert ist. Es wird basierend auf der Priorität des Vorfalls und den festgelegten Servicezeiten berechnet. Dieser Timestamp ist der Referenzpunkt, anhand dessen die tatsächliche Lösungszeit gemessen wird. Er ist entscheidend für die Berechnung des KPIs Incident SLA Compliance Rate und für die Erstellung von Dashboards, die die SLA-Performance visualisieren. Er ermöglicht die proaktive Überwachung von Vorfällen, deren Frist sich nähert.
Warum es wichtig ist
Dies ist der Benchmark zur Messung der SLA-Konformität. Er ermöglicht die Berechnung, ob ein Vorfall fristgerecht gelöst wurde oder gegen seine Vereinbarung verstoßen hat.
Woher erhalten
Diese Daten werden typischerweise im Formular SLM:Measurement gespeichert und mit dem Vorfall verknüpft. Es ist kein direktes Feld im Formular HPD:Help Desk.
Beispiele
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
Incident Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Gruppe zugewiesen
|
Diese Aktivität markiert die anfängliche Zuweisung des Vorfalls an eine spezifische Supportgruppe zur Untersuchung. Sie wird abgeleitet, wenn das Feld 'Assigned Group' zum ersten Mal nach der Erstellung des Vorfalls gefüllt wird. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der den Beginn der aktiven Arbeit kennzeichnet. Die Verfolgung der Zeit bis zur ersten Zuweisung ist entscheidend für die Bewertung der Reaktionszeiten und der Effizienz der initialen Routing-Prozesse.
Woher erhalten
Abgeleitet aus dem Audit-Log ('HPD:HelpDesk_AuditLogSystem') für das 'HPD:Help Desk'-Formular, wobei die erstmalige Zuweisung des Feldes 'Assigned Group' erfasst wird.
Erfassen
Vom Zeitstempel, an dem das Feld 'Assigned Group' erstmals gefüllt wurde.
Ereignistyp
inferred
|
|||
|
Incident gelöst
|
Diese Aktivität markiert die offizielle Lösung des Vorfalls aus Sicht des Service Desk, vor dem endgültigen Abschluss. Sie wird erfasst, wenn der Status des Vorfalls auf 'Resolved' gesetzt wird. | ||
|
Warum es wichtig ist
Dies ist der wichtigste Meilenstein zur Messung der SLA-Konformität und der Lösungszeit. Er signalisiert, dass der Dienst für den Benutzer wiederhergestellt wurde.
Woher erhalten
Dieses Event entspricht der Einstellung des Status-Feldes im Formular HPD:Help Desk auf 'Resolved'. Der Timestamp wird im Feld Last Resolved Date und im Audit-Log erfasst.
Erfassen
Vom Zeitstempel der Statusänderung auf 'Resolved' im Audit-Log.
Ereignistyp
inferred
|
|||
|
Incident gemeldet
|
Diese Aktivität markiert die anfängliche Erstellung des Vorfallsdatensatzes im System. Sie wird explizit vom Erstellungs-Timestamp des Vorfalls im zentralen Incident Management Formular erfasst. | ||
|
Warum es wichtig ist
Dies ist das primäre Start-Event für den Vorfalllebenszyklus. Es ist entscheidend für die Berechnung der gesamten Lösungszeiten und das Verständnis der Vorfall-Eingangsraten.
Woher erhalten
Dieses Event entspricht der Erstellung des Eintrags im Formular HPD:Help Desk. Der Timestamp wird typischerweise den Feldern Submit Date oder Reported Date entnommen.
Erfassen
Vom Zeitstempel 'Submit Date' auf dem Formular 'HPD:Help Desk'.
Ereignistyp
explicit
|
|||
|
Incident geschlossen
|
Dies ist die finale Aktivität, die den formellen Abschluss der Vorfallakte markiert, nachdem die Lösung bestätigt wurde oder eine Bestätigungsfrist abgelaufen ist. Sie wird erfasst, wenn der Status auf 'Closed' gesetzt wird. | ||
|
Warum es wichtig ist
Dies ist das definitive End-Event für den Vorfalllebenszyklus. Die Zeitspanne zwischen 'Resolved' und 'Closed' repräsentiert die Phase der Benutzerbestätigung und des administrativen Abschlusses.
Woher erhalten
Dieses Event entspricht der Einstellung des Status-Feldes im Formular HPD:Help Desk auf 'Closed'. Der Timestamp wird im Feld Closed Date und im Audit-Log erfasst.
Erfassen
Vom Zeitstempel 'Closed Date' oder der Statusänderung auf 'Closed'.
Ereignistyp
inferred
|
|||
|
Untersuchung eingeleitet
|
Zeigt an, dass ein Support-Mitarbeiter aktiv mit der Bearbeitung des Incidents begonnen hat. Dies wird typischerweise durch eine Statusänderung von 'Assigned' zu 'In Progress' abgeleitet. | ||
|
Warum es wichtig ist
Dieser Meilenstein markiert den Wechsel von der Warteschlange in die aktive Diagnose. Die Analyse der Wartezeit bis zum Beginn der Untersuchung hilft, Ressourcenengpässe zu erkennen und unterstützt das Dashboard 'Diagnosis & Investigation Bottlenecks'.
Woher erhalten
Abgeleitet von einer Statusänderung im 'HPD:Help Desk'-Formular. Das Ereignis wird ausgelöst, wenn das Feld 'Status' zu 'In Progress' wechselt, wobei der Zeitstempel aus dem Audit-Log erfasst wird.
Erfassen
Abgeleitet von einer Statusänderung zu 'In Progress' im HPD:HelpDesk_AuditLogSystem.
Ereignistyp
inferred
|
|||
|
An eine andere Gruppe übergeben
|
Diese Aktivität tritt auf, wenn ein Vorfall von einer Supportgruppe zu einer anderen neu zugewiesen wird. Sie wird abgeleitet, indem eine Änderung im Feld 'Assigned Group' nach der anfänglichen Zuweisung erkannt wird. | ||
|
Warum es wichtig ist
Häufige Übergaben deuten auf eine falsche initiale Weiterleitung oder Wissenslücken hin. Die Verfolgung dieser Aktivität ist unerlässlich für das Dashboard 'Analyse der Incident-Neuzuweisungszyklen' und den KPI 'Incident-Neuzuweisungsrate'.
Woher erhalten
Abgeleitet aus dem Audit-Log ('HPD:HelpDesk_AuditLogSystem') durch Identifizierung nachfolgender Änderungen am Feld 'Assigned Group' im 'HPD:Help Desk'-Formular, nachdem es erstmals befüllt wurde.
Erfassen
Identifizieren Sie Änderungen am Feld 'Zugewiesene Gruppe' nach der ursprünglichen Zuweisung.
Ereignistyp
inferred
|
|||
|
Benutzerbestätigung erhalten
|
Stellt die aktive Bestätigung des Benutzers dar, dass die bereitgestellte Lösung sein Problem behoben hat. Dies kann ein explizites Event sein oder aus Notizen oder einer zugehörigen Systemaktion vor der Schließung abgeleitet werden. | ||
|
Warum es wichtig ist
Das Nachverfolgen liefert ein deutlich genaueres Bild der Nutzerfreigabe als bloßes Warten auf die automatische Schließung. So messen Sie den KPI 'Average User Confirmation Time' und decken Kommunikationslücken auf.
Woher erhalten
Dies kann schwierig sein, zuverlässig zu erfassen. Es könnte sich aus einem Work Log-Eintrag oder einer spezifischen Aktualisierung des Statusgrunds ableiten lassen, kurz bevor der Vorfall auf 'Closed' gesetzt wird. Es kann eine Analyse des Formulars HPD:WorkLog erforderlich machen.
Erfassen
Abgeleitet von spezifischen Arbeitslog-Einträgen oder Statusgrund-Aktualisierungen vor dem Abschluss.
Ereignistyp
inferred
|
|||
|
Incident kategorisiert
|
Stellt den Punkt dar, an dem der Incident mit operativen und Produktkategorisierungen klassifiziert und eine Priorität festgelegt wurde. Dies wird typischerweise aus der Befüllung oder letzten Änderung von Kategorisierungsfeldern abgeleitet. | ||
|
Warum es wichtig ist
Eine genaue und zeitnahe Kategorisierung ist entscheidend für effizientes Routing und Reporting. Die Analyse dieser Aktivität hilft, Verzögerungen oder Ungenauigkeiten im initialen Triageprozess zu identifizieren und unterstützt das Dashboard 'Incident Categorization Accuracy'.
Woher erhalten
Abgeleitet aus dem Audit-Log ('HPD:HelpDesk_AuditLogSystem'), das Änderungen an Feldern wie 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' und 'Priority' im 'HPD:Help Desk'-Formular verfolgt.
Erfassen
Vom Zeitstempel der letzten Aktualisierung an den Kategorisierungs- oder Prioritätsfeldern nach der Erstellung.
Ereignistyp
inferred
|
|||
|
Incident storniert
|
Diese Aktivität stellt die Beendigung eines Vorfalls dar, der fehlerhaft erstellt wurde oder nicht mehr relevant ist. Sie wird erfasst, wenn der Status des Vorfalls auf 'Cancelled' gesetzt wird. | ||
|
Warum es wichtig ist
Dies ist ein finaler Endzustand für einen Vorfall, der sich von einer erfolgreichen Lösung unterscheidet. Die Analyse stornierter Vorfälle kann Probleme mit den Kanälen der Vorfallerstellung oder doppelten Meldungen aufzeigen.
Woher erhalten
Abgeleitet aus dem 'HPD:Help Desk'-Formular, wenn das Feld 'Status' auf 'Cancelled' aktualisiert wird. Der Zeitstempel wird im Audit-Log erfasst.
Erfassen
Abgeleitet von einer Statusänderung zu 'Cancelled' im Audit-Log.
Ereignistyp
inferred
|
|||
|
Incident wiedereröffnet
|
Stellt einen Incident dar, der zuvor als gelöst (Resolved) markiert, aber reaktiviert wurde, weil das Problem weiterhin besteht. Dies wird aus einer Statusänderung von 'Gelöst' (Resolved) zurück in einen aktiven Status wie 'In Bearbeitung' (In Progress) oder 'Zugewiesen' (Assigned) abgeleitet. | ||
|
Warum es wichtig ist
Diese Aktivität misst direkt Nacharbeit und die Effektivität initialer Lösungen. Eine hohe Anzahl wiedereröffneter Vorfälle ist ein wichtiger Indikator für schlechte Lösungsqualität und unterstützt den KPI 'Incident Rework Rate'.
Woher erhalten
Abgeleitet aus dem Audit-Log ('HPD:HelpDesk_AuditLogSystem') durch Erkennen einer 'Status'-Änderung von 'Resolved' zu 'In Progress' oder 'Assigned' für eine bestimmte Incident-ID.
Erfassen
Abgeleitet vom Statusübergang von 'Resolved' in einen aktiven Zustand.
Ereignistyp
inferred
|
|||
|
Kunden-Input ausstehend
|
Stellt einen Punkt dar, an dem der Incident-Verlauf unterbrochen wird, während auf Informationen oder Aktionen des Benutzers gewartet wird. Dies wird aus einer Statusänderung in den Status 'Ausstehend' (Pending) abgeleitet. | ||
|
Warum es wichtig ist
Diese Aktivität hilft, die Arbeitszeit des Agenten von der Wartezeit des Kunden zu trennen. Die Analyse der in diesem Status verbrachten Zeit ist entscheidend, um zu verstehen, wie Verzögerungen bei der Benutzerantwort die gesamten Lösungszeiten beeinflussen.
Woher erhalten
Abgeleitet aus dem 'HPD:Help Desk'-Formular, wenn das Feld 'Status' auf 'Pending' aktualisiert wird. Der spezifische Grund ist oft im Feld 'Status_Reason' zu finden.
Erfassen
Abgeleitet von einer Statusänderung zu 'Pending' im HPD:HelpDesk_AuditLogSystem.
Ereignistyp
inferred
|
|||
|
Lösung implementiert
|
Diese Aktivität bedeutet, dass ein Fix oder Workaround vom Supportteam angewendet wurde. Dies wird oft abgeleitet, wenn der Vorfallsstatus zu 'Resolved' wechselt. | ||
|
Warum es wichtig ist
Dies ist ein entscheidender Meilenstein, der anzeigt, dass eine Lösung geliefert wurde. Er ist ein wichtiger Datenpunkt zur Messung der Zeit, die für die Anwendung einer Behebung nach Abschluss der Untersuchung benötigt wird.
Woher erhalten
Dies wird typischerweise abgeleitet, wenn der Status im Formular HPD:Help Desk auf 'Resolved' geändert wird. Der Timestamp wird im Feld Last Resolved Date und im Audit-Log erfasst.
Erfassen
Vom Zeitstempel 'Last Resolved Date' oder der Statusänderung auf 'Resolved'.
Ereignistyp
inferred
|
|||
|
SLA-Verstoß
|
Dies ist ein berechnetes Event, das auftritt, wenn die Lösungszeit eines Vorfalls dessen definiertes Service Level Agreement-Ziel überschreitet. Es wird abgeleitet durch den Vergleich des Lösungs-Timestamps mit dem SLA-Fälligkeitsdatum. | ||
|
Warum es wichtig ist
Diese Aktivität ist grundlegend für das Dashboard 'Leistungsübersicht der Incident SLA' und den KPI 'SLA-Erfüllungsrate für Incidents'. Es markiert direkt Vorfälle, die Service-Verpflichtungen nicht erfüllt haben.
Woher erhalten
Berechnet durch Vergleich des 'Last Resolved Date' mit dem 'Target Date' (SLA-Fälligkeitsdatum) auf dem Formular 'HPD:Help Desk'. Ist der Incident noch nicht gelöst, kann die Berechnung anhand der aktuellen Uhrzeit erfolgen.
Erfassen
Berechnetes Event: tritt auf, wenn 'Last Resolved Date' > 'Target Date'.
Ereignistyp
calculated
|
|||
|
Warten auf Benutzerbestätigung
|
Tritt ein, nachdem eine Lösung implementiert wurde und das Support-Team auf die Bestätigung des Benutzers wartet, dass die Behebung erfolgreich war. Dies wird oft durch den Status 'Resolved' selbst dargestellt, bei dem die Uhr für die automatische Schließung beginnt. | ||
|
Warum es wichtig ist
Diese Aktivität ist entscheidend für das Dashboard 'Verzögerungen bei Benutzerbestätigung und Verifizierung'. Es hilft, Verzögerungen zwischen der Bereitstellung einer Lösung und der Benutzervalidierung zu quantifizieren, die den Vorfallslebenszyklus künstlich verlängern können.
Woher erhalten
Dieser Zustand beginnt, wenn der 'Status' im Formular 'HPD:Help Desk' auf 'Resolved' wechselt. Die Dauer wird vom 'Last Resolved Date' bis zu dem Zeitpunkt gemessen, an dem der Incident entweder 'Closed' ist oder erneut geöffnet ('Reopened') wird.
Erfassen
Beginnt mit der Statusänderung zu 'Resolved', endet mit der Statusänderung zu 'Closed' oder 'In Progress'.
Ereignistyp
inferred
|
|||