Ihr Incident-Management Daten Template

Jira-Service-Management
Ihr Incident-Management Daten Template

Ihr Incident-Management Daten Template

Diese Datenvorlage bietet einen strukturierten Ansatz zur Erfassung der relevanten Daten für die Analyse Ihres Incident-Management-Prozesses. Es beschreibt die wichtigen Attribute, die gesammelt werden müssen, die wichtigen Aktivitäten, die verfolgt werden sollen, und bietet praktische Anleitungen zur Extraktion dieser Informationen aus Ihrem Quellsystem. Dies stellt sicher, dass Sie alle notwendigen Komponenten haben, um Ihre Workflows zur Störungsbehebung zu optimieren.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten für das Tracking
  • Anleitung zur Datenextraktion für Jira-Service-Management
Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Incident-Management-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihr Event Log aufgenommen werden sollten, um eine vollständige Analyse Ihres Incident-Management Prozesses zu ermöglichen.
5 Erforderlich 6 Empfohlen 12 Optional
Name Beschreibung
`Incident`-ID
IncidentId
Die eindeutige Kennung für jedes Incident-Ticket in Jira-Service-Management.
Beschreibung

Die Incident-ID, oft als Issue Key in Jira bezeichnet, dient als primärer eindeutige Kennung für jeden gemeldeten Incident. Sie verknüpft alle zugehörigen Aktivitäten, Kommentare und Statusänderungen vom Zeitpunkt der Erstellung bis zum endgültigen Abschluss. Im Process Mining ist diese ID unerlässlich, um den End-to-End-Lebenszyklus jedes einzelnen Incidents zu rekonstruieren und eine vollständige Analyse des gesamten Prozesses zu ermöglichen.

Bedeutung

Dies ist die zentrale Kennung, die verwendet wird, um alle verknüpften Ereignisse zu einem einzigen Case zu korrelieren, was sie zur Grundlage für jede Process Mining-Analyse macht.

Datenquelle

Dies ist das Standard-'Key'-Feld für einen Issue in Jira-Service-Management (z.B. 'ITSM-123').

Beispiele
INC-10234HELPDESK-5678OPS-9901
Aktivität
ActivityName
Der Name des spezifischen Ereignisse oder den Antrag bearbeitet.er Statusänderung, die für den Incident aufgetreten ist.
Beschreibung

Die Aktivität stellt einen separaten Schritt oder ein Ereignis im Incident-Management-Lebenszyklus dar, wie z. B. 'Incident Erstellt', 'Incident Zugewiesen' oder 'Behebung Vorgeschlagen'. Diese werden in der Regel aus Statusübergängen oder spezifischen Aktualisierungsereignissen abgeleitet, die in der Historie oder den Antrag bearbeitet.em Changelog des Jira-Issues erfasst sind. Die Analyse der Abfolge und Dauer dieser Aktivitäten ist das primäre Ziel des Process Mining, wobei der tatsächliche Prozessfluss, Engpässe und Abweichungen aufgedeckt werden.

Bedeutung

Aktivitäten bilden das Basis der Prozessdarstellung und ermöglichen die Visualisierung und Analyse des Incident-Lebenszyklus.

Datenquelle

Abgeleitet aus der Jira-Issue-Historie und den Changelog-Daten, erfasst Statusübergänge und wichtige Feldaktualisierungen.

Beispiele
Incident zugewiesenErmittlung gestartetIncident gelöst
Startzeit
EventTimestamp
Das genaue Datum und die Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität stattgefunden hat.
Beschreibung

Dieses Attribut erfasst den Zeitstempel jeder Aktivität im Incident-Lebenszyklus. Es ist maßgeblich für die Berechnung von Dauern, Durchlaufzeits und Wartezeiten zwischen verschiedenen Prozessschritten. Präzise Zeitstempels ermöglichen eine detaillierte Leistungsfähigkeit-Analyse, SLA-Monitoring und die Identifizierung von Engpässe. Alle Leistungsfähigkeit-Metriken, wie Lösungszeit und Diagnosedauer, werden aus diesen Zeitstempels abgeleitet.

Bedeutung

Zeitstempels sind essenziell für die Berechnung aller zeitbasierten Metriken, das Verständnis der Prozessdauer und die Entdeckung von Leistungsfähigkeit-Engpässe.

Datenquelle

Dies ist das 'created' Datum, das mit jedem Eintrag im Changelog oder den Antrag bearbeitet.er Historie des Jira-Issues verknüpft ist.

Beispiele
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, der den Antrag bearbeitet.en letzten Zeitpunkt angibt, zu dem die Daten aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst den Zeitpunkt der letzten Aktualisierung des Datensatzes. Es liefert wichtigen Kontext für alle, die den Prozess analysierenn, und stellt sicher, dass sie über die Aktualität der Daten Bescheid wissen. Dies ist besonders wichtig für fortlaufende Monitoring-Dashboards, bei denen aktuelle Informationen für zeitnahe Entscheidungen wichtig sind. Der Wert ist in der Regel derselbe für alle Ereignisse innerhalb eines einzelnen Datenextraktions-Batchs.

Bedeutung

Informiert Benutzer über die Aktualität der Daten, die wichtig für die Relevanz und Genauigkeit der Analyse ist.

Datenquelle

Dies ist der Zeitstempel des Datenextraktionslaufs, der während des Datentransformationsprozesses hinzugefügt wird.

Beispiele
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Quellsystem
SourceSystem
Das System, aus dem die Daten extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert die Datenherkunft, die in diesem Fall Jira-Service-Management ist. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine vollständige Prozessansicht kombiniert werden. Die Angabe des Quellsystems stellt eine klare Datenherkunft sicher und hilft bei der Diagnose von Datenqualitäts- oder Extraktionsproblemen. Für dieses Modell wäre der Wert statisch.

Bedeutung

Liefert wesentlichen Kontext zum Datenursprung und stellt ... sicher Klarheit und Nachvollziehbarkeit, insbesondere bei der Multi-System-Analyse.

Datenquelle

Dies ist ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt werden sollte.

Beispiele
Jira-Service-ManagementJira Cloud
Assignee
Assignee
Der Benutzer, der aktuell für die Bearbeitung des Incidents zugewiesen ist.
Beschreibung

Der Zuständige ist der einzelne Agent oder Nutzer, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen des Zuständigen zu verfolgen, ist maßgeblich für die Analyse von Übergaben, das Verständnis der Arbeitslastverteilung und die Identifizierung, welche Personen an bestimmten Prozessschritten beteiligt sind. Dieses Attribut hilft, Fragen zur individuellen Leistung und Ressourcenzuweisung innerhalb der Kundensupports zu beantworten.

Bedeutung

Hilft, die individuelle Arbeitslast zu verfolgen, Engpässe in Bezug auf bestimmte Agenten zu identifizieren und den Einfluss von Übergaben auf die Lösungszeit zu analysierenn.

Datenquelle

Das Standardfeld 'Bearbeiter' eines Jira-Issues.

Beispiele
John SmithEmily JonesServiceDeskAgent1
Bearbeitungsgruppe
AssignmentGroup
Das Team oder den Antrag bearbeitet.ie Gruppe, die für die Bearbeitung des Incidents zuständig ist.
Beschreibung

Die Bearbeitungsgruppe repräsentiert das Team, das einem Incident zugewiesen ist. Dies kann eine Support-Ebene wie 'L1 Helpdesk', ein spezialisiertes Team wie 'Network Operations' oder ein Entwicklungsteam sein. Die Analyse von Übergängen zwischen Bearbeitungsgruppen ist maßgeblich, um Prozesseskalationen und Übergaben zu verstehen. Sie ermöglicht die Messung der Teamleistung, die Identifizierung von Engpässen auf Teamebene und die Analyse von Abhängigkeiten zwischen Teams.

Bedeutung

Wesentlich für die Analyse der Teamleistung, des Durchsatzes und des Arbeitsflusses zwischen verschiedenen Support-Ebenen oder spezialisierten Gruppen.

Datenquelle

Dies wird oft als Custom Field in Jira implementiert, wie z.B. 'Team' oder 'Assignment Group'. Es kann manchmal aus Jira-Components oder Project-Roles abgeleitet werden.

Beispiele
Tier 1 SupportInfrastruktur-`Team`Datenbankadministratoren
Datum der Behebung
ResolutionDate
Das Datum und die Uhrzeit, zu der den Antrag bearbeitet.er Incident als gelöst markiert wurde.
Beschreibung

Dieses Attribut erfasst den Zeitstempel, zu dem der Incident erstmals in einen gelösten Status überführt wurde. Es markiert das Ende des Prozesses.kiert das Ende der aktiven Arbeitsphase und ist der Endpunkt für die Berechnung der Time to Resolution. Der Vergleich des Lösungsdatums mit dem Erstellungsdatum liefert das primäre Maß für die Prozesseffizienz. Es ist auch eine Schlüsselkomponente bei der Bestimmung der SLA-Compliance.

Bedeutung

Dies markiert das Ende des Lösungsprozesses und ermöglicht die Berechnung der Gesamtzykluszeit und der SLA-Leistungsfähigkeit.

Datenquelle

Das Standardfeld 'Gelöst' eines Jira-Issues.

Beispiele
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Erstellungsdatum
CreatedDate
Das Datum und die Uhrzeit, zu der den Antrag bearbeitet.er Incident erstmals im System erstellt wurde.
Beschreibung

Dieses Attribut markiert den offiziellen Beginn des Incident-Lebenszyklus. Es ist der Referenz-Zeitstempel, von dem aus Gesamtmetriken wie die Gesamtlösungszeit berechnet werden. Das Erstellungsdatum ist für jeden Incident ein statischer Wert und dient als Startpunkt für den gesamten Case in der Process Mining-Analyse.

Bedeutung

Dient als Ausgangspunkt für alle End-to-End-Durchlaufzeitberechnungen und SLA-Messungen.

Datenquelle

Das Standardfeld 'Erstellt' eines Jira-Issues.

Beispiele
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Priorität
Priority
Die Prioritätsstufe, die dem Incident zugewiesen wurde und die Dringlichkeit der Lösung angibt.
Beschreibung

Die Priorität bestimmt die erforderliche Geschwindigkeit bei der Bearbeitung eines Incidents. Sie ist oft eine Kombination aus Auswirkung und Dringlichkeit und beeinflusst direkt die SLA-Ziele. Die Analyse von Incidents nach Priorität hilft zu verstehen, ob hochpriorisierte Incidents schneller als niedrigpriorisierte bearbeitet werden und ob die Priorisierung konsistent angewendet wird. Sie ist eine kritische Dimension für das Filtern und Vergleichen der Prozess-Leistungsfähigkeit.

Bedeutung

Unerlässlich für die SLA-Leistungsanalyse und um zu überprüfen, ob die Ressourcen den kritischsten Vorfällen korrekt zugewiesen sind.

Datenquelle

Das Standardfeld 'Priorität' eines Jira-Issues.

Beispiele
HöchsteHochMittelNiedrig
Status
Status
Der aktuelle Status des Incidents in seinem Lebenszyklus.
Beschreibung

Das Statusfeld gibt den aktuellen Zustand eines Incidents innerhalb des definierten Workflows an, z. B. 'Open', 'In Progress', 'Pending Customer' oder 'Resolved'. Statusänderungen sind die primäre Quelle für die Generierung des Aktivitäten-Logs für das Process Mining. Die Analyse der Verweildauer in jedem Status ist die Basis für die Identifizierung von Engpässen und das Verständnis, wo Incidents die meiste Zeit verbringen.

Bedeutung

Spiegelt direkt den Fortschritt des Incidents wider und ist die primäre Quelle zur Identifizierung von Prozessschritten und Wartezeiten.

Datenquelle

Das Standardfeld 'Status' eines Jira-Issues.

Beispiele
In BearbeitungWarten auf KundenGelöstGeschlossen
`Issue Typ`
IssueType
Die Art des Vorgangs, z. B. Incident, Service Request oder Problem.
Beschreibung

Jira verwendet Issue Typs, um verschiedene Aufgabenarten zu unterscheiden. Im Rahmen des Incident-Managements ist der primäre Typ 'Incident', jedoch könnten auch andere, wie 'Sub-task', relevant sein. Dieses Attribut ist maßgeblich, um den Datensatz auf Incidents zu filtern und so sicherzustellen, dass die Process-Mining-Analyse auf den korrekten Prozess fokussiert ist.

Bedeutung

Stellt sicher, dass die Analyse korrekt auf Vorfälle ausgerichtet ist und diese von anderen Aufgabenarten wie Service-Requestnn oder Änderungen abgrenzt.

Datenquelle

Das Standardfeld 'Aufgabentyp' eines Jira-Issues.

Beispiele
VorfallIT-HilfeBug
`SLA-Verstoß`
SlaBreach
Eine Kennzeichnung, ob die Incident-Lösungszeit das SLA-Ziel überschritten hat.
Beschreibung

Dieses berechnete boolesche Attribut zeigt an, ob ein Incident sein 'Time to Resolution' SLA verletzt hat. Der Wert ist Ja, wenn die 'IncidentResolutionCycleTime' größer ist als der 'TimeToResolutionTarget'. Dieses Flag vereinfacht die Analyse und Visualisierung, ermöglicht einfaches Filtern und Aggregieren zur Berechnung des gesamten SLA Breach Rate KPI. Es ist die wichtigste Ergebnisgröße für das SLA-Leistungsfähigkeit-Monitoring-Dashboard.

Bedeutung

Bietet ein klares, binäres Ergebnis für die SLA-Leistungsfähigkeit, was die Berechnung von Verstoßraten und die Identifizierung von Problembereichen vereinfacht.

Datenquelle

Berechnet als ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').

Beispiele
JaNein
Handoff-Anzahl
HandoffCount
Die Häufigkeit, mit der den Antrag bearbeitet.er Incident einer anderen Gruppe oder einem anderen Benutzer neu zugewiesen wurde.
Beschreibung

Diese berechnete Metrik zählt die Anzahl der Änderungen des Feldes 'Assignee' oder 'AssignmentGroup' während des Incident-Lebenszyklus. Eine hohe Anzahl von Übergaben deutet oft auf Ineffizienzen im Prozess, mangelnde First-Call-Resolution oder Wissenslücken hin, was zu längeren Lösungszeiten führt. Die Analyse dieses KPIs hilft dabei, den Zuweisungsprozess zu optimieren und die Teamzusammenarbeit zu verbessern.

Bedeutung

Quantifiziert Reibungsverluste und Ineffizienzen, die durch Neuzuweisungen entstehen, und hilft dabei, Möglichkeiten zur Prozessoptimierung zu identifizieren.

Datenquelle

Berechnet durch Zählen der Änderungen am Feld 'Bearbeiter' oder 'Bearbeitungsgruppe' im Issue-Changelog.

Beispiele
015
ID des verknüpften Problems
LinkedProblemId
Die Kennung eines Problem-Tickets, das mit diesem Incident verknüpft ist.
Beschreibung

Incidents, die Symptome eines größeren, zugrunde liegenden Problems sind, sind oft mit einem Problem-Ticket verknüpft. Dieses Feld speichert die ID dieses zugehörigen Problems. Die Analyse dieser Links hilft, die Beziehung zwischen Incidents und Problemen zu verstehen, die Effektivität des Problem-Management-Prozesses zu messen und wiederkehrende Incidents zu identifizieren, die eine dauerhafte Lösung erfordern.

Bedeutung

Verknüpft Incidents mit zugrunde liegenden Problemen und ermöglicht so die Analyse, wie effektiv die Organisation Ursachen adressiert, um zukünftige Incidents zu verhindern.

Datenquelle

Diese Informationen sind im Bereich 'Issue Links' eines Jira-Issues gespeichert.

Beispiele
PROB-123PROB-456Keine
Ist Nacharbeit
IsRework
Eine Kennzeichnung, ob der Incident überarbeitet wurde, z.B. durch eine Wiedereröffnung.
Beschreibung

Dieses berechnete boolesche Attribut identifiziert Incidents, die in einen früheren Prozessschritt zurückgeschickt wurden, meist durch die Wiedereröffnung, nachdem sie gelöst wurden. Rework Loops sind eine erhebliche Quelle für Ineffizienz und Kundenunzufriedenheit. Dieses Flag ermöglicht eine einfache Quantifizierung der Rework Rate und hilft, die Analyse darauf zu konzentrieren, warum Incidents nicht auf Anhieb korrekt gelöst werden.

Bedeutung

Hebt Prozessqualitätsmängel und Ineffizienzen hervor, indem Vorfälle markiert werden, die wiederholte Arbeit erfordern, und unterstützt so direkt die Nacharbeitsanalyse.

Datenquelle

Berechnet durch Erkennung spezifischer Statusübergangssequenzen im Event Log, wie 'Resolved' -> 'Reopened'.

Beispiele
JaNein
Komponente
Component
Das System, die Anwendung oder den Antrag bearbeitet.er Teil der Infrastruktur, der vom Incident betroffen ist.
Beschreibung

Komponenten sind Unterabschnitte eines Jira-Projekts, die zur Gruppierung von Issues in kleinere Einheiten verwendet werden, wie 'Benutzeroberfläche', 'Datenbank' oder 'API'. Die Analyse von Incidents nach Komponente hilft, jene Systemteile zu identifizieren, die am anfälligsten für Probleme sind. Diese Informationen sind wertvoll für die Ursachenanalyse und können Bemühungen zur Serviceverbesserung oder zur Reduzierung technischer Schulden leiten.

Bedeutung

Ermöglicht Filterung und Analyse basierend auf dem spezifisch betroffenen Produkt- oder Systembereich, um technologische Hotspots zu identifizieren.

Datenquelle

Das Standardfeld 'Komponenten' eines Jira-Issues.

Beispiele
AuthentifizierungsdienstReporting DashboardMobile App
Kundenanfragetyp
CustomerRequestType
Die spezifische Art der Anfrage, die vom Kunden über das Serviceportal eingereicht wurde.
Beschreibung

Dieses Feld kategorisiert Anfragen aus Kundensicht, wie sie auf dem Jira-Service-Management-Portal präsentiert werden (z.B. 'Ein Systemproblem melden'). Es bietet eine benutzerfreundliche Klassifizierung des Incidents, die sich von der internen 'Issue Typ' unterscheiden kann. Die Analyse dieses Attributs kann Einblicke geben, wie Kunden Probleme wahrnehmen und melden, was zur Verbesserung des Portal-Designs und der Serviceangebote beiträgt.

Bedeutung

Bietet eine kundenorientierte Ansicht der Incident-Kategorien, die nützlich für die Analyse der Nachfrage und die Verbesserung des Kundenerlebnisses ist.

Datenquelle

Das Feld 'Customer Request Typ', spezifisch für Jira-Service-Management-Projekte.

Beispiele
IT-Hilfe anfordern > Systemproblem meldenE-Mail > Zugriffsanfrage
Lösung
Resolution
Das Endergebnis oder den Antrag bearbeitet.er Grund für die Lösung des Incidents.
Beschreibung

Das Lösungsfeld erklärt, warum ein Incident in einen gelösten Status überführt wurde. Gängige Lösungen umfassen 'Fixed', 'Duplizieren', 'Won't Do' oder 'Cannot Reproduce'. Die Analyse der Verteilung von Lösungstypen kann Einblicke in die Qualität eingehender Meldungen und die Effektivität des Lösungsprozesses geben. Zum Beispiel kann eine hohe Anzahl von 'Duplizieren'-Lösungen auf ein Problem in der Incident-Erstellungs- oder Triage-Phase hinweisen.

Bedeutung

Bietet Kontext zum Ergebnis eines Vorfalls und hilft so, Lösungen zu kategorisieren und Trends bei der Schließung von Vorfällen zu identifizieren.

Datenquelle

Das Standardfeld 'Lösung' eines Jira-Issues. Dieses Feld wird in der Regel gesetzt, wenn ein Issue in eine 'Erledigt'-Statuskategorie überführt wird.

Beispiele
ErledigtBehobenDuplikatWird nicht behoben
Melder
Reporter
Der Benutzer, der den Antrag bearbeitet.en Incident ursprünglich erstellt oder gemeldet hat.
Beschreibung

Der Melder ist die Person, oft ein Endbenutzer oder ein anderes System, die den Incident zuerst gemeldet hat. Die Analyse von Incidents nach Melder kann helfen, Benutzer oder Abteilungen zu identifizieren, die häufig Probleme erleben. Sie kann auch verwendet werden, um Kommunikationsmuster zu verstehen, insbesondere bei der Analyse von Aktivitäten wie 'Waiting for Customer' und 'Customer Responded'.

Bedeutung

Hilft, Vorfallquellen zu analysierenn, Muster in Bezug auf bestimmte Benutzer oder Abteilungen zu identifizieren und Verzögerungen bei der Kundeninteraktion zu verstehen.

Datenquelle

Das Standardfeld 'Melder' eines Jira-Issues.

Beispiele
Alice JohnsonBob Williamsmonitoring-tool@example.com
Schweregrad
Severity
Das Maß der geschäftlichen Auswirkungen des Incidents.
Beschreibung

Der Schweregrad definiert, welche Auswirkungen ein Incident auf das Geschäft hat, von einem einzelnen betroffenen Nutzer bis zu einem kritischen Systemausfall. Während die Priorität die Arbeitsreihenfolge bestimmt, Hinweisrmiert der Schweregrad über die gesamten geschäftlichen Auswirkungen. Die Analyse nach Schweregrad hilft, die Prozessleistung für Incidents zu verstehen, die für das Geschäft am wichtigsten sind, und wird oft in Kombination mit der Priorität für eine nuanciertere Analyse verwendet.

Bedeutung

Bietet eine Sicht auf den Geschäftseinfluss, die eine Analyse der für den Geschäftsbetrieb schädlichsten Incidents ermöglicht.

Datenquelle

Typischerweise ein Custom Field in Jira, da es kein Standard-Systemfeld ist. Konsultieren Sie die Jira-Service-Management-ProjektKonfiguration.

Beispiele
KritischSchwerwiegendGeringfügigTrivial
TimeToResolutionTarget
TimeToResolutionTarget
Die SLA-Zieldauer für die Lösung des Incidents.
Beschreibung

Dieses Attribut definiert die erwartete Maximalzeit, innerhalb der ein Incident einer bestimmten Priorität oder Art gelöst werden sollte. Es ist der Benchmark, an dem die tatsächliche Lösungszeit gemessen wird, um die SLA-Compliance zu bestimmen. Dieser Wert wird in der Regel dynamisch basierend auf Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Aufgabentyp berücksichtigen. Er ist die Basis für jedes SLA-Leistungsfähigkeit-Monitoring-Dashboard.

Bedeutung

Bietet den Benchmark für die Messung der SLA-Compliance und bildet die Grundlage für den Incident SLA Breach Rate KPI.

Datenquelle

Dies wird aus der SLA-Konfiguration innerhalb von Jira-Service-Management abgeleitet. Das spezifische Ziel (z.B. 'Time to resolution') muss identifiziert werden.

Beispiele
4h8h3d
Ursachenkategorie
RootCauseCategory
Die Klassifizierung der zugrunde liegenden Grundursache des Incidents.
Beschreibung

Dieses Attribut erfasst die grundlegende Ursache dafür, warum der Incident aufgetreten ist, wie z. B. 'Software Defect', 'Hardware Failure' oder 'Benutzer Fehler'. Es wird in der Regel nach einer Untersuchung gefüllt und ist wichtig für ein effektives Problemmanagement und die Prävention zukünftiger Incidents. Die Analyse von Grundursachenkategorien hilft, systemische Schwachstellen zu identifizieren und Verbesserungsinitiativen zu priorisieren. Eine hohe Rate an 'Unknown'-Grundursachen kann auf die Notwendigkeit besserer Untersuchungsprozesse hinweisen.

Bedeutung

Ermöglicht die Ursachenanalyse und fördert den Übergang von einem reaktiven zu einem proaktiven Ansatz, indem die Ursachen von Incidents identifiziert und behoben werden.

Datenquelle

Dies ist fast immer ein Custom Field in Jira. Der Name und die Optionen hängen stark von der spezifischen Konfiguration der Organisation ab.

Beispiele
KonfigurationsfehlerNetzwerkausfallSoftware-Bug
Erforderlich Empfohlen Optional

Incident-Management-Aktivitäten

Dies sind die wichtigen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um Ihre Incident-Lösungs-Workflows präzise zu erkennen und zu analysierenn.
7 Empfohlen 8 Optional
Aktivität Beschreibung
Behebung Vorgeschlagen
Diese Aktivität zeigt an, dass eine Lösung identifiziert und implementiert wurde und der Incident auf Bestätigung oder finale Validierung wartet. Sie wird aus dem Statusübergang zu 'Resolved' abgeleitet.
Bedeutung

Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.as Ende der aktiven Arbeit des Supportteams markiert. Es ist oft das Event, das die SLA-Uhr stoppt.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Zeitstempel ist der Zeitpunkt, zu dem der Status zu 'Resolved' oder einem äquivalenten Zustand übergeht.

Erfassen

Identifizieren Sie den Zeitstempel des Statusübergangs zu 'Gelöst'.

Ereignistyp inferred
Ermittlung gestartet
Zeigt an, dass ein zugewiesener Bearbeiter aktiv mit der Diagnose des Incidents begonnen hat. Dies wird in der Regel abgeleitet, wenn der Incident Issue Status von 'Open' oder 'New' zu 'In Progress' übergeht.
Bedeutung

Dieser wichtige Meilenstein markiert den Beginn aktiver Lösungsbemühungen. Die Messung der Zeit bis zu dieser Activity hilft, anfängliche Warteschlangenverzögerungen und Probleme mit der Ressourcenverfügbarkeit zu identifizieren.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Zeitstempel ist der Zeitpunkt, zu dem der Status in einen Zustand übergeht, der aktive Arbeit darstellt, wie zum Beispiel 'In Progress'.

Erfassen

Identifizieren Sie den Zeitstempel des Statusübergangs zu 'In Bearbeitung'.

Ereignistyp inferred
Incident erstellt
Dies kennzeichnet den offiziellen Start des Incident-Lebenszyklus, wenn ein Incident-Report eingereicht und ein neuer Vorgang in Jira erstellt wird. Dieses Event wird explizit erfasst, wenn ein neuer Vorgang vom Typ 'Incident' im System protokolliert wird.
Bedeutung

Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Resolution ist die Basis für die Messung der gesamten Durchlaufzeit und der SLA-Einhaltung.

Datenquelle

Dies ist ein explizites Event, das vom 'created' Zeitstempel des Incident-Issues in Jira erfasst wird. Das Issue-Creation-Event wird in der Historie des Issues protokolliert.

Erfassen

Verwenden Sie den Erstellungs-Zeitstempel des Issues.

Ereignistyp explicit
Incident gelöst
Diese Aktivität markiert die Bestätigung, dass der Incident erfolgreich gelöst und der Service wiederhergestellt ist. Sie fällt oft mit dem Übergang in den Status 'Resolved' zusammen.
Bedeutung

Dies ist der primäre Erfolgs-Meilenstein im Prozess. Die Dauer bis zu diesem Punkt ist der häufigste KPI, der den Antrag bearbeitet.ie 'Time to Resolution' (TTR) darstellt.

Datenquelle

Abgeleitet aus der Statusänderung zu 'Resolved'. In vielen Workflows ist dies dasselbe Event wie 'Resolution Proposed', das den Hauptlösungspunkt darstellt.

Erfassen

Identifizieren Sie den Zeitstempel des Statusübergangs zu 'Gelöst'.

Ereignistyp inferred
Incident geschlossen
Stellt die endgültige, administrative Schließung des Incident-Tickets dar, nachdem es behoben und verifiziert wurde. Dies wird aus dem Statusübergang zu 'Closed' abgeleitet.
Bedeutung

Dies ist das End-Event des Prozesses. Die Analyse der Zeit zwischen 'Resolved' und 'Closed' kann Verzögerungen bei administrativen Bereinigungen oder Benutzerbestätigungsprozessen aufzeigen.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Zeitstempel, zu dem der Status in den finalen Zustand 'Closed' übergeht.

Erfassen

Identifizieren Sie den Zeitstempel des Statusübergangs zu 'Geschlossen'.

Ereignistyp inferred
Incident neu zugewiesen
Tritt auf, wenn ein Incident nach der ersten Zuweisung von einem Agenten oder einer Gruppe an eine andere übertragen wird. Dieses Event wird aus jeder Änderung im Feld „Bearbeiter“ (Assignee) oder „Zuständige Gruppe“ (Assigned Group) abgeleitet.
Bedeutung

Die Nachverfolgung von Reassignments ist maßgeblich für die Handoff-Analyse. Eine hohe Anzahl von Reassignments deutet oft auf Ineffizienzen im Prozess, Wissenslücken oder eine Neine anfängliche Zuweisung hin, was zu Lösungsverzögerungen führt.

Datenquelle

Abgeleitet aus der Issue-Historie durch Erkennung jeder Aktualisierung des Feldes 'Assignee', nachdem es zuerst befüllt wurde. Jede Änderung stellt ein Neu-Zuweisungs-Event dar.

Erfassen

Identifizieren Sie nachträgliche Änderungen am Feld Assignee nach der initialen Zuweisung.

Ereignistyp inferred
Warten Auf Kunden
Dies kennzeichnet einen Zeitpunkt, an dem das Kundensupport auf Informationen oder Aktionen des Kunden wartet. Dies wird durch einen Statusübergang zu einem dedizierten Wartestatus wie „Warten auf Kunde“ abgeleitet.
Bedeutung

Die Isolierung dieser 'Wartezeit' ist maßgeblich für eine genaue SLA-Messung, da sie oft aus den Berechnungen der Lösungszeit ausgeschlossen wird. Sie hilft, Kundenantwortverzögerungen zu analysierenn.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Zeitstempel, zu dem sich der Status auf 'Waiting for customer' oder einen ähnlichen Zustand ändert.

Erfassen

Identifizieren Sie den Zeitstempel des Statusübergangs zu 'Warten auf Kunden'.

Ereignistyp inferred
An Spezialistenteam eskaliert
Bedeutet, dass der Incident zur erweiterten Unterstützung an ein spezialisiertes Team (z. B. Tier 2, Entwicklung) eskaliert wurde. Dies wird aus einer Änderung in einem benutzerdefinierten Feld 'Support Team' oder einer spezifischen Neuzuweisung abgeleitet.
Bedeutung

Hebt Vorfälle hervor, die spezialisiertes Wissen erfordern, und verfolgt den Fluss zwischen verschiedenen Support-Levels. Dies hilft, Engpässe innerhalb spezialisierter Teams zu identifizieren und Eskalationsmuster zu analysierenn.

Datenquelle

Abgeleitet aus der Issue-Historie durch Verfolgung von Änderungen an einem benutzerdefinierten Feld, das das zugewiesene Team repräsentiert, oder den Antrag bearbeitet.urch Identifizierung einer 'Assignee'-Änderung zu einem Mitglied einer bekannten Spezialistengruppe.

Erfassen

Erkennt eine Änderung in einem benutzerdefinierten Feld für 'Zugewiesenes Team' oder spezifische Bearbeiteränderungen.

Ereignistyp inferred
Incident wiedereröffnet
Stellt eine Situation dar, in der ein zuvor behobener Incident reaktiviert wird, weil das Problem erneut aufgetreten oder den Antrag bearbeitet.ie Behebung ineffektiv war. Dies wird aus einer Statusänderung von 'Resolved' oder 'Closed' zurück zu einem offenen Status abgeleitet.
Bedeutung

Wiedereröffnete Incidents sind ein direktes Maß für die Lösungsqualität und ein Hauptindikator für Nacharbeit. Die Analyse dieser Ereignisse hilft, verfrühte Abschlüsse und ineffektive Lösungen zu identifizieren.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Das Event wird protokolliert, wenn der Status von einem finalen Zustand wie 'Resolved' oder 'Closed' zurück zu 'Open' oder 'In Progress' wechselt.

Erfassen

Erkennt einen Statuswechsel von 'Resolved' oder 'Closed' zu einem offenen Status.

Ereignistyp inferred
Incident zugewiesen
Diese Aktivität kennzeichnet die Erstzuweisung des Incidents an einen Support-Mitarbeiter oder eine Gruppe zur Bearbeitung. Sie wird erfasst, indem der erste Zeitpunkt verfolgt wird, an dem das Feld 'Assignee' oder 'Assigned Group' gefüllt wird.
Bedeutung

Misst die anfängliche Reaktions- und Zuweisungszeit, die eine Schlüsselkomponente der SLA-Metriken ist. Es hilft, Verzögerungen zu erkennen, bevor die aktive Untersuchung beginnt.

Datenquelle

Abgeleitet aus der Issue-Historie durch Identifizierung der ersten Änderung des Feldes 'Assignee', bei der den Antrag bearbeitet.er vorherige Wert 'Unassigned' war.

Erfassen

Erkennt die erste Aktualisierung des Feldes 'Bearbeiter' in der Issue-Historie.

Ereignistyp inferred
Kommentar hinzugefügt
Stellt jedes Kommunikations- oder Notizereignis dar, bei dem ein Nutzer einen Kommentar zum Incident-Ticket hinzufügt. Dies ist ein explizites Ereignis, das jedes Mal erfasst wird, wenn ein Kommentar veröffentlicht wird.
Bedeutung

Die Analyse der Kommentarhäufigkeit liefert Einblicke in Kommunikationsmuster, die Effizienz der Zusammenarbeit und die Komplexität eines Incidents. Sie kann Incidents hervorheben, die übermäßige Kommunikation erfordern.

Datenquelle

Dies ist ein explizites Event. Jira speichert jeden Kommentar mit einem Zeitstempel und Autor, verfügbar über die Kommentarhistorie des Issues oder den Antrag bearbeitet.ie API.

Erfassen

Verwenden Sie den Zeitstempel jedes zum Issue hinzugefügten Kommentars.

Ereignistyp explicit
Kunde hat geantwortet
Zeigt an, dass der Kunde die angefragten Informationen bereitgestellt hat und der Incident fortgesetzt werden kann. Dies wird abgeleitet, wenn der Status von 'Waiting for customer' wieder in einen aktiven Status übergeht.
Bedeutung

Diese Aktivität markiert das Ende einer kundeninduzierten Verzögerung. Die Analyse der Dauer zwischen 'Waiting For Customer' und diesem Event zeigt die durchschnittliche Kundenreaktionszeit.

Datenquelle

Abgeleitet aus der Statusänderungshistorie des Issues. Das Event tritt auf, wenn der Status von 'Waiting for customer' zu einem Status wie 'In Progress' übergeht, oft ausgelöst durch das Hinzufügen eines Kommentars durch den Kunden.

Erfassen

Erkennt einen Statuswechsel von 'Wartet auf Kunde' zu 'In Bearbeitung'.

Ereignistyp inferred
Mit Problem-Ticket verknüpft
Tritt auf, wenn ein Incident mit einem Problem-Vorgang zur Ursachenanalyse verknüpft wird. Dies ist ein explizites Event, das erfasst wird, wenn eine „bezieht sich auf“- oder „verursacht durch“-Verknüpfung zu einem Problem-Vorgangstyp erstellt wird.
Bedeutung

Die Nachverfolgung dieses Links ist wichtig, um zu verstehen, wie effektiv die Organisation von der Incident-Minimierung zur Ursachenanalyse und Prävention übergeht.

Datenquelle

Dies ist ein explizites Event, das in der Link-Historie des Issues protokolliert wird. Jede Link-Creation hat einen Zeitstempel und kann nach Links zum 'Problem'-Issue-Typ gefiltert werden.

Erfassen

Verwenden Sie den Zeitstempel der Erstellung einer Issue-Verknüpfung zu einem Issue-Typ 'Problem'.

Ereignistyp explicit
Vorfall priorisiert
Stellt die Festlegung der Priorität und/oder Schwere des Incidents dar, die dessen Dringlichkeit und geschäftliche Auswirkungen bestimmt. Dies wird in der Regel aus dem ersten Zeitpunkt abgeleitet, zu dem die Felder 'Priority' oder 'Severity' nach der Erstellung befüllt oder aktualisiert werden.
Bedeutung

Die Nachverfolgung der Priorisierung hilft bei der Analyse, ob Incidents zeitnah und konsistent bewertet werden. Verzögerungen in diesem Schritt können sich direkt auf SLA-Berechnungen und die Ressourcenallokation auswirken.

Datenquelle

Abgeleitet aus dem Issue-Historien-Log, das Änderungen an allen Feldern verfolgt. Suchen Sie nach der ersten Aktualisierung des Feldes 'Priority' oder eines Custom-Severity-Feldes nach dem Issue-Erstellungs-Event.

Erfassen

Erkennt die erste Änderung des Feldes 'Priorität' in der Issue-Historie.

Ereignistyp inferred
Workaround bereitgestellt
Stellt die Implementierung einer temporären Lösung dar, um den Dienst wiederherzustellen, während eine dauerhafte Lösung entwickelt wird. Dies kann aus einer Statusänderung oder einem spezifischen Kommentar abgeleitet werden.
Bedeutung

Die Messung der Zeit bis zur Bereitstellung eines Workarounds ist ein Schlüsselindikator für die Geschwindigkeit der Service-Wiederherstellung. Sie hilft, zwischen einer temporären Entschärfung und einer permanenten Lösung zu unterscheiden.

Datenquelle

Dies wird oft abgeleitet. Es könnte ein Übergang zu einem Status 'Workaround Provided' oder den Antrag bearbeitet.as Hinzufügen eines öffentlichen Kommentars sein, der spezifische Schlüsselwörter wie 'Workaround' enthält.

Erfassen

Identifizieren Sie einen spezifischen Statusübergang oder ein Keyword in einem Kommentar.

Ereignistyp inferred
Empfohlen Optional

Extraktionsanleitungen

So erhalten Sie Ihre Daten aus Jira-Service-Management