Datentemplate: Incident Management

Jira Service Management
Datentemplate: Incident Management

Ihr Incident Management Data Template

Dieses Template bietet einen strukturierten Ansatz zur Erfassung der essenziellen Daten für die Analyse Ihres Incident-Management-Prozesses. Es beschreibt die entscheidenden Attribute, die gesammelt werden müssen, die wichtigen Activities, 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 Incident-Resolution-Workflows zu optimieren.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten zur Verfolgung
  • Anleitung zur Datenextraktion für Jira Service Management
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Incident-Management-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihr Event Log aufgenommen werden sollten, um eine umfassende Analyse Ihres Incident Management Prozesses zu ermöglichen.
5 Erforderlich 7 Empfohlen 12 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name des spezifischen Events oder der 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 typischerweise aus Statusübergängen oder spezifischen Aktualisierungsereignissen abgeleitet, die in der Historie oder dem 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.

Warum es wichtig ist

Aktivitäten bilden das Rückgrat der Prozesskarte und ermöglichen die Visualisierung und Analyse des Incident-Lebenszyklus.

Woher erhalten

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

Beispiele
Incident zugewiesenErmittlung gestartetIncident gelöst
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 eindeutiger Identifikator 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 umfassende Analyse des gesamten Prozesses zu ermöglichen.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
INC-10234HELPDESK-5678OPS-9901
Startzeit
EventTimestamp
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung

Dieses Attribut erfasst den Timestamp jeder Activity im Incident-Lebenszyklus. Es ist entscheidend für die Berechnung von Dauern, Cycle Times und Wartezeiten zwischen verschiedenen Prozessschritten. Präzise Timestamps ermöglichen eine detaillierte Performance-Analyse, SLA-Monitoring und die Identifizierung von Bottlenecks. Alle Performance-Metriken, wie Lösungszeit und Diagnosedauer, werden aus diesen Timestamps abgeleitet.

Warum es wichtig ist

Timestamps sind essenziell für die Berechnung aller zeitbasierten Metriken, das Verständnis der Prozessdauer und die Entdeckung von Performance-Bottlenecks.

Woher erhalten

Dies ist das 'created' Datum, das mit jedem Eintrag im Changelog oder der 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 Timestamp, der den 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 analysieren, 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 entscheidend sind. Der Wert ist typischerweise derselbe für alle Events innerhalb eines einzelnen Datenextraktions-Batchs.

Warum es wichtig ist

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

Woher erhalten

Dies ist der Timestamp 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 ganzheitliche 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.

Warum es wichtig ist

Liefert wesentlichen Kontext zum Datenursprung und gewährleistet Klarheit und Nachvollziehbarkeit, insbesondere bei der Multi-System-Analyse.

Woher erhalten

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 entscheidend 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 Support-Teams zu beantworten.

Warum es wichtig ist

Hilft, die individuelle Arbeitslast zu verfolgen, Bottlenecks in Bezug auf bestimmte Agenten zu identifizieren und den Einfluss von Handoffs auf die Lösungszeit zu analysieren.

Woher erhalten

Das Standardfeld 'Bearbeiter' eines Jira-Issues.

Beispiele
John SmithEmily JonesServiceDeskAgent1
Bearbeitungsgruppe
AssignmentGroup
Das Team oder die 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 entscheidend, 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.

Warum es wichtig ist

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

Woher erhalten

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-TeamDatenbankadministratoren
Bearbeitungszeit für die Behebung
IncidentResolutionCycleTime
Die Gesamtzeit, die von der Incident-Erstellung bis zur Lösung verstrichen ist.
Beschreibung

Dies ist eine berechnete Metrik, die die Dauer vom 'CreatedDate' bis zum 'ResolutionDate' darstellt. Sie ist eine der wichtigsten KPIs im Incident Management und misst direkt die Effizienz des gesamten Prozesses. Die Analyse dieser Metrik über verschiedene Dimensionen wie Priorität, Zuweisungsgruppe oder Komponente hilft, die Faktoren zu identifizieren, die den größten Einfluss auf die Performance haben.

Warum es wichtig ist

Misst direkt die End-to-End-Effizienz des Incident Management Prozesses und ist ein primärer KPI für die Leistungsverfolgung.

Woher erhalten

Berechnet als ('ResolutionDate' - 'CreatedDate').

Beispiele
2h 30m1d 4h5d 1h 15m
Datum der Behebung
ResolutionDate
Das Datum und die Uhrzeit, zu der der Incident als gelöst markiert wurde.
Beschreibung

Dieses Attribut erfasst den Timestamp, zu dem der Incident erstmals in einen gelösten Status überführt wurde. Es markiert 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.

Warum es wichtig ist

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

Woher erhalten

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 der Incident erstmals im System erstellt wurde.
Beschreibung

Dieses Attribut markiert den offiziellen Beginn des Incident-Lebenszyklus. Es ist der Referenz-Timestamp, 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.

Warum es wichtig ist

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

Woher erhalten

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-Performance.

Warum es wichtig ist

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

Woher erhalten

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 grundlegend für die Identifizierung von Engpässen und das Verständnis, wo Incidents die meiste Zeit verbringen.

Warum es wichtig ist

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

Woher erhalten

Das Standardfeld 'Status' eines Jira-Issues.

Beispiele
In BearbeitungWarten auf KundenResolvedGeschlossen
Behebung
Resolution
Das Endergebnis oder der 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', 'Duplicate', '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 'Duplicate'-Lösungen auf ein Problem in der Incident-Erstellungs- oder Triage-Phase hinweisen.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
ErledigtBehobenDuplikatWird nicht behoben
Handoff-Anzahl
HandoffCount
Die Häufigkeit, mit der der 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 Handoffs 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.

Warum es wichtig ist

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

Woher erhalten

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.

Warum es wichtig ist

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.

Woher erhalten

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

Beispiele
PROB-123PROB-456Keine
Issue Type
IssueType
Die Art des Vorgangs, z. B. Incident, Service Request oder Problem.
Beschreibung

Jira nutzt Issue Types, 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 entscheidend, um den Datensatz auf Incidents zu filtern und so sicherzustellen, dass die Process Mining Analyse auf den korrekten Prozess fokussiert ist.

Warum es wichtig ist

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

Woher erhalten

Das Standardfeld 'Aufgabentyp' eines Jira-Issues.

Beispiele
VorfallIT-HilfeBug
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.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
truefalsch
Komponente
Component
Das System, die Anwendung oder der 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.

Warum es wichtig ist

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

Woher erhalten

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 Type' 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.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
IT-Hilfe anfordern > Systemproblem meldenE-Mail > Zugriffsanfrage
Melder
Reporter
Der Benutzer, der den 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'.

Warum es wichtig ist

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

Woher erhalten

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, informiert 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.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
KritischSchwerwiegendGeringfügigTrivial
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 true, 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-Performance-Monitoring-Dashboard.

Warum es wichtig ist

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

Woher erhalten

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

Beispiele
truefalsch
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 typischerweise dynamisch basierend auf Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Aufgabentyp berücksichtigen. Er ist grundlegend für jedes SLA-Performance-Monitoring-Dashboard.

Warum es wichtig ist

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

Woher erhalten

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 'User Error'. Es wird typischerweise nach einer Untersuchung gefüllt und ist essenziell 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.

Warum es wichtig ist

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.

Woher erhalten

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
KonfigurationsfehlerNetzwerkausfallSoftwarefehler
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 analysieren.
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.
Warum es wichtig ist

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

Woher erhalten

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

Erfassen

Identifizieren Sie den Timestamp 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 typischerweise abgeleitet, wenn der Incident Issue Status von 'Open' oder 'New' zu 'In Progress' übergeht.
Warum es wichtig ist

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.

Woher erhalten

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

Erfassen

Identifizieren Sie den Timestamp 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.
Warum es wichtig ist

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

Woher erhalten

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

Erfassen

Verwenden Sie den Erstellungs-Timestamp 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.
Warum es wichtig ist

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

Woher erhalten

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 Timestamp 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.
Warum es wichtig ist

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.

Woher erhalten

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

Erfassen

Identifizieren Sie den Timestamp 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.
Warum es wichtig ist

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

Woher erhalten

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 Support-Team auf Informationen oder Aktionen des Kunden wartet. Dies wird durch einen Statusübergang zu einem dedizierten Wartestatus wie „Warten auf Kunde“ abgeleitet.
Warum es wichtig ist

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

Woher erhalten

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

Erfassen

Identifizieren Sie den Timestamp 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.
Warum es wichtig ist

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

Woher erhalten

Abgeleitet aus der Issue-Historie durch Verfolgung von Änderungen an einem benutzerdefinierten Feld, das das zugewiesene Team repräsentiert, oder durch 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 die Behebung ineffektiv war. Dies wird aus einer Statusänderung von 'Resolved' oder 'Closed' zurück zu einem offenen Status abgeleitet.
Warum es wichtig ist

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.

Woher erhalten

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.
Warum es wichtig ist

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.

Woher erhalten

Abgeleitet aus der Issue-Historie durch Identifizierung der ersten Änderung des Feldes 'Assignee', bei der der 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.
Warum es wichtig ist

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.

Woher erhalten

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

Erfassen

Verwenden Sie den Timestamp 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.
Warum es wichtig ist

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.

Woher erhalten

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.
Warum es wichtig ist

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

Woher erhalten

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

Erfassen

Verwenden Sie den Timestamp 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 typischerweise aus dem ersten Zeitpunkt abgeleitet, zu dem die Felder 'Priority' oder 'Severity' nach der Erstellung befüllt oder aktualisiert werden.
Warum es wichtig ist

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.

Woher erhalten

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.
Warum es wichtig ist

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.

Woher erhalten

Dies wird oft abgeleitet. Es könnte ein Übergang zu einem Status 'Workaround Provided' oder das 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

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus Jira Service Management