Ihr Daten-Template für Incident Management

Jira Service Management
Ihr Daten-Template für Incident Management

Ihr Daten-Template für Incident Management

Dieses Template bietet einen strukturierten Ansatz, um die für die Analyse Ihres Incident-Management-Prozesses erforderlichen Daten zu erfassen. Es zeigt, welche wichtigen Attribute Sie sammeln und welche zentralen Aktivitäten Sie verfolgen sollten. Außerdem enthält es praktische Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Damit stehen Ihnen alle erforderlichen Komponenten zur Verfügung, um Ihre Workflows zur Incident-Lösung zu optimieren.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Hinweise zur Extraktion für Jira Service Management
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Attribute des Incident Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse Ihres Incident-Management-Prozesses in Ihr Event Log aufnehmen sollten.
5 Erforderlich 6 Empfohlen 12 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name des konkreten Ereignisses oder der Statusänderung, die für den Incident eingetreten ist.
Beschreibung

Die Aktivität bezeichnet einen einzelnen Schritt oder ein Ereignis im Lebenszyklus des Incident Managements, etwa „Incident Created“, „Incident Assigned“ oder „Resolution Proposed“. Diese Aktivitäten werden typischerweise aus Statuswechseln oder bestimmten Aktualisierungsereignissen abgeleitet, die in der Historie oder im Changelog des Jira-Problems erfasst sind. Die Analyse der Reihenfolge und Dauer dieser Aktivitäten ist das zentrale Ziel von Process Mining. Sie macht den tatsächlichen Prozessablauf, Bottlenecks und Abweichungen sichtbar.

Warum das wichtig ist

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

Bezugsquelle

Abgeleitet aus der Problemhistorie und den Changelog-Daten von Jira, die Statuswechsel und wichtige Aktualisierungen von Feldern erfassen.

Beispiele
Incident zugewiesenUntersuchung gestartetIncident gelöst
Incident-ID
IncidentId
Die eindeutige Kennung für jedes Incident-Ticket in Jira Service Management.
Beschreibung

Die Incident-ID, in Jira häufig als Issue Key bezeichnet, dient als primäre eindeutige Kennung für jeden gemeldeten Incident. Sie verknüpft alle zugehörigen Aktivitäten, Kommentare und Statusänderungen von der Erstellung bis zum endgültigen Abschluss. Im Process Mining ist diese ID entscheidend, um den End-to-End-Lebenszyklus jedes einzelnen Incidents zu rekonstruieren und den gesamten Prozess umfassend zu analysieren.

Warum das wichtig ist

Dies ist die zentrale Kennung, mit der alle zugehörigen Ereignisse zu einem einzelnen Case zusammengeführt werden. Sie bildet damit die Grundlage jeder Process-Mining-Analyse.

Bezugsquelle

Dies ist das standardmäßige Feld „Key“ für ein Problem in Jira Service Management, zum Beispiel „ITSM-123“.

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

Dieses Attribut erfasst den Timestamp jeder Aktivität im Lebenszyklus eines Incidents. Es ist entscheidend für die Berechnung von Dauern, Durchlaufzeiten und Wartezeiten zwischen verschiedenen Prozessschritten. Präzise Timestamps ermöglichen eine detaillierte Leistungsanalyse, SLA-Überwachung und Identifizierung von Bottlenecks. Alle zeitbezogenen Kennzahlen, etwa Lösungszeit und Diagnosedauer, werden aus diesen Timestamps abgeleitet.

Warum das wichtig ist

Timestamps sind unverzichtbar für die Berechnung aller zeitbezogenen Kennzahlen, das Verständnis der Prozessdauer und die Erkennung von Leistungs-Bottlenecks.

Bezugsquelle

Dies ist das Datum „created“, das jedem Eintrag im Änderungsprotokoll oder Verlauf des Jira-Vorgangs zugeordnet ist.

Beispiele
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst, wann der Datensatz zuletzt aktualisiert wurde. Es liefert wichtigen Kontext für die Prozessanalyse und zeigt, wie aktuell die verwendeten Daten sind. Das ist besonders für Dashboards zur laufenden Überwachung relevant, bei denen aktuelle Informationen für zeitnahe Entscheidungen erforderlich sind. Der Wert ist in der Regel für alle Events innerhalb eines einzelnen Datenextraktionslaufs identisch.

Warum das wichtig ist

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

Bezugsquelle

Dies ist der Timestamp des Datenextraktionslaufs, der während der Datentransformation 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 gibt den Ursprung der Daten an, in diesem Fall Jira Service Management. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine umfassende Prozesssicht zusammengeführt werden. Die Angabe des Quellsystems sorgt für eine klare Datenherkunft und unterstützt die Diagnose von Problemen bei Datenqualität oder Extraktion. Für dieses Modell wäre der Wert statisch.

Warum das wichtig ist

Liefert wichtigen Kontext zum Ursprung der Daten und sorgt insbesondere bei Analysen über mehrere Systeme hinweg für Klarheit und Nachvollziehbarkeit.

Bezugsquelle

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

Beispiele
Jira Service ManagementJira Cloud
Erstellungsdatum
CreatedDate
Das Datum und die Uhrzeit, zu denen der Incident erstmals im System erstellt wurde.
Beschreibung

Dieses Attribut markiert den offiziellen Beginn des Incident-Lebenszyklus. Es ist der Ausgangs-Timestamp für die Berechnung zentraler Kennzahlen wie der gesamten Lösungszeit. Das Erstellungsdatum ist für jeden Incident statisch und dient in der Process-Mining-Analyse als Startpunkt für den gesamten Case.

Warum das wichtig ist

Dient als Ausgangspunkt für alle End-to-End-Berechnungen der Durchlaufzeit und für SLA-Messungen.

Bezugsquelle

Das standardmäßige Feld „Created“ eines Jira-Vorgangs.

Beispiele
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Lösungsdatum
ResolutionDate
Das Datum und die Uhrzeit, zu denen 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 Bearbeitungsphase und bildet den Endpunkt für die Berechnung der Lösungszeit. Der Vergleich von Lösungsdatum und Erstellungsdatum liefert das wichtigste Maß für die Prozesseffizienz. Außerdem ist dieser Wert ein zentraler Bestandteil zur Bestimmung der SLA-Konformität.

Warum das wichtig ist

Markiert das Ende des Lösungsprozesses und ermöglicht die Berechnung der gesamten Durchlaufzeit sowie der SLA-Leistung.

Bezugsquelle

Das standardmäßige Feld „Resolved“ eines Jira-Vorgangs.

Beispiele
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Priorität
Priority
Die dem Incident zugewiesene Prioritätsstufe, die die Dringlichkeit der Lösung angibt.
Beschreibung

Die Priorität bestimmt, wie schnell ein Incident bearbeitet werden muss. Sie ergibt sich häufig aus einer Kombination von Auswirkung und Dringlichkeit und beeinflusst direkt die SLA-Ziele. Die Analyse von Incidents nach Priorität zeigt, ob Incidents mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität und ob die Priorisierung einheitlich angewendet wird. Sie ist eine wichtige Dimension zum Filtern und Vergleichen der Prozessleistung.

Warum das wichtig ist

Unverzichtbar für die Analyse der SLA-Leistung und zur Überprüfung, ob Ressourcen den kritischsten Incidents korrekt zugewiesen werden.

Bezugsquelle

Das standardmäßige Feld „Priority“ eines Jira-Vorgangs.

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

Das Feld „Status“ gibt den aktuellen Zustand eines Incidents innerhalb des definierten Workflows an, etwa „Open“, „In Progress“, „Pending Customer“ oder „Resolved“. Statusänderungen bilden die wichtigste Quelle für das Aktivitätsprotokoll im Process Mining. Die Analyse der Verweildauer in den einzelnen Status ist grundlegend, um Engpässe zu erkennen und zu verstehen, in welchen Prozessabschnitten Incidents die meiste Zeit verbringen.

Warum das wichtig ist

Spiegelt den Fortschritt des Incidents direkt wider und bildet die wichtigste Quelle für die Identifizierung von Prozessschritten und Wartezeiten.

Bezugsquelle

Das standardmäßige Feld „Status“ eines Jira-Vorgangs.

Beispiele
In BearbeitungWarten auf den KundenGelöstGeschlossen
Zuständige Person
Assignee
Der Benutzer, der aktuell für die Bearbeitung des Incidents zuständig ist.
Beschreibung

Die zuständige Person ist der Agent oder Benutzer, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Die Nachverfolgung von Änderungen an dieser Zuordnung ist entscheidend, um Übergaben zu analysieren, die Arbeitslast zu verstehen und die an bestimmten Prozessschritten beteiligten Personen zu identifizieren. Dieses Attribut hilft dabei, Fragen zur individuellen Leistung und zur Ressourcenverteilung in Supportteams zu beantworten.

Warum das wichtig ist

Unterstützt die Analyse der individuellen Arbeitslast, die Identifizierung von Engpässen bei bestimmten Agents sowie die Bewertung des Einflusses von Übergaben auf die Lösungszeit.

Bezugsquelle

Das standardmäßige Feld „Assignee“ eines Jira-Vorgangs.

Beispiele
John SmithEmily JonesServiceDeskAgent1
Zuweisungsgruppe
AssignmentGroup
Das Team oder die Gruppe, die für die Bearbeitung des Incidents zuständig ist.
Beschreibung

Die Zuweisungsgruppe bezeichnet das Team, dem der Incident zugewiesen ist. Dabei kann es sich um eine Supportstufe wie „L1 Helpdesk“, ein spezialisiertes Team wie „Network Operations“ oder ein Entwicklungsteam handeln. Die Analyse von Wechseln zwischen Zuweisungsgruppen ist entscheidend, um Eskalationen und Übergaben im Prozess zu verstehen. Sie ermöglicht die Messung der Teamleistung, die Identifizierung von Engpässen auf Teamebene sowie die Analyse von Abhängigkeiten zwischen Teams.

Warum das wichtig ist

Entscheidend für die Analyse von Teamleistung, Durchsatz und Arbeitsfluss zwischen verschiedenen Supportstufen oder spezialisierten Gruppen.

Bezugsquelle

Dies wird in Jira häufig als benutzerdefiniertes Feld wie „Team“ oder „Assignment Group“ umgesetzt. Mitunter lässt sich der Wert aus Jira Components oder Project Roles ableiten.

Beispiele
Support, Stufe 1InfrastrukturteamDatenbankadministratoren
Anzahl der Übergaben
HandoffCount
Die Anzahl der Fälle, in denen der Incident einer anderen Gruppe oder einem anderen Benutzer zugewiesen wurde.
Beschreibung

Diese berechnete Kennzahl zählt, wie oft sich das Feld „Assignee“ oder „AssignmentGroup“ während des Lebenszyklus eines Incidents geändert hat. Eine hohe Anzahl von Übergaben weist häufig auf ineffiziente Prozesse, eine geringe Lösungsquote beim Erstkontakt oder Wissenslücken hin und führt zu längeren Lösungszeiten. Die Analyse dieser KPI unterstützt die Optimierung des Zuweisungsprozesses und die Verbesserung der Zusammenarbeit zwischen Teams.

Warum das wichtig ist

Quantifiziert Reibungsverluste und Ineffizienzen durch Neuzuweisungen und hilft, Ansatzpunkte für Prozessverbesserungen zu erkennen.

Bezugsquelle

Berechnet durch Zählen der Änderungen am Feld „Assignee“ oder „AssignmentGroup“ im Änderungsprotokoll des Vorgangs.

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, werden häufig mit einem Problem-Ticket verknüpft. Dieses Feld speichert die ID des zugehörigen Problems. Die Analyse dieser Verknüpfungen zeigt die Beziehung zwischen Incidents und Problemen, ermöglicht die Messung der Wirksamkeit des Problem Managements und hilft, wiederkehrende Incidents zu identifizieren, die eine dauerhafte Lösung erfordern.

Warum das wichtig ist

Verknüpft Incidents mit zugrunde liegenden Problemen und ermöglicht die Analyse, wie wirksam die Organisation Grundursachen behebt, um künftige Incidents zu vermeiden.

Bezugsquelle

Diese Information wird im Abschnitt „Issue Links“ eines Jira-Vorgangs gespeichert.

Beispiele
PROB-123PROB-456Keine
Ist Nacharbeit
IsRework
Ein Kennzeichen dafür, ob der Incident Nacharbeit erfordert hat, etwa weil er erneut geöffnet wurde.
Beschreibung

Dieses berechnete boolesche Attribut identifiziert Incidents, die an eine frühere Prozessphase zurückgegeben wurden, meist durch eine erneute Öffnung nach ihrer Lösung. Nacharbeitsschleifen sind eine wesentliche Ursache für Ineffizienz und Unzufriedenheit bei Kunden. Das Kennzeichen ermöglicht die einfache Quantifizierung der Nacharbeitsquote und lenkt die Analyse auf die Gründe, warum Incidents nicht beim ersten Mal korrekt gelöst werden.

Warum das wichtig ist

Macht Probleme bei Prozessqualität und Effizienz sichtbar, indem Incidents mit wiederholtem Arbeitsaufwand gekennzeichnet werden, und unterstützt direkt die Nacharbeitsanalyse.

Bezugsquelle

Berechnet durch die Erkennung bestimmter Sequenzen von Statusübergängen im Event Log, etwa „Resolved“ -> „Reopened“.

Beispiele
truefalse
Kategorie der Grundursache
RootCauseCategory
Die Klassifizierung der zugrunde liegenden Grundursache des Incidents.
Beschreibung

Dieses Attribut erfasst den grundlegenden Grund für das Auftreten des Incidents, etwa „Software Defect“, „Hardware Failure“ oder „User Error“. Es wird in der Regel nach der Untersuchung ausgefüllt und ist für ein wirksames Problem Management sowie die Vermeidung künftiger Incidents entscheidend. Die Analyse von Grundursachenkategorien hilft, systemische Schwachstellen zu erkennen und Verbesserungsmaßnahmen zu priorisieren. Ein hoher Anteil unbekannter Grundursachen kann auf einen Verbesserungsbedarf bei den Untersuchungsprozessen hinweisen.

Warum das wichtig ist

Ermöglicht die Ursachenanalyse und unterstützt den Wechsel von einem reaktiven zu einem proaktiven Vorgehen, indem die Quellen von Incidents identifiziert und behoben werden.

Bezugsquelle

Dies ist in Jira fast immer ein benutzerdefiniertes Feld. Name und Optionen hängen stark von der spezifischen Konfiguration der Organisation ab.

Beispiele
KonfigurationsfehlerNetzwerkausfallSoftwarefehler
Komponente
Component
Das System, die Anwendung oder der betroffene Teil der Infrastruktur.
Beschreibung

Components sind Teilbereiche eines Jira-Projekts, mit denen Vorgänge in kleinere Einheiten wie „User Interface“, „Database“ oder „API“ gruppiert werden. Die Analyse von Incidents nach Component zeigt, welche Teile eines Systems besonders häufig von Problemen betroffen sind. Diese Informationen sind für die Ursachenanalyse wertvoll und können Maßnahmen zur Serviceverbesserung oder zum Abbau technischer Schulden unterstützen.

Warum das wichtig ist

Ermöglicht die Filterung und Analyse nach dem betroffenen Produkt- oder Systembereich und hilft dabei, technische Schwerpunkte zu identifizieren.

Bezugsquelle

Das standardmäßige Feld „Components“ eines Jira-Vorgangs.

Beispiele
AuthentifizierungsdienstReporting-DashboardMobile App
Kundenanfragetyp
CustomerRequestType
Der spezifische Typ der Anfrage, die der Kunde über das Serviceportal eingereicht hat.
Beschreibung

Dieses Feld kategorisiert Anfragen aus Sicht des Kunden, wie sie im Portal von Jira Service Management angezeigt werden, etwa „Report a system issue“. Es bietet eine benutzerfreundliche Klassifizierung des Incidents, die vom internen „Issue Type“ abweichen kann. Die Analyse dieses Attributs zeigt, wie Kunden Probleme wahrnehmen und melden, und unterstützt die Verbesserung von Portalgestaltung und Serviceangeboten.

Warum das wichtig ist

Bietet eine kundenorientierte Sicht auf Incident-Kategorien und unterstützt die Analyse der Nachfrage sowie die Verbesserung der Customer Experience.

Bezugsquelle

Das für Jira-Service-Management-Projekte spezifische Feld „Customer Request Type“.

Beispiele
IT-Hilfe erhalten > Systemproblem meldenE-Mail > Zugriffsanfrage
Lösung
Resolution
Das endgültige Ergebnis oder der Grund für die Lösung des Incidents.
Beschreibung

Das Feld „Resolution“ erklärt, warum ein Incident in einen gelösten Zustand versetzt wurde. Häufige Lösungen sind „Fixed“, „Duplicate“, „Won't Do“ oder „Cannot Reproduce“. Die Analyse der Verteilung von Lösungstypen kann Erkenntnisse über die Qualität eingehender Meldungen und die Wirksamkeit des Lösungsprozesses liefern. Eine hohe Zahl von Lösungen mit dem Wert „Duplicate“ kann beispielsweise auf ein Problem bei der Erstellung oder Triage von Incidents hinweisen.

Warum das wichtig ist

Liefert Kontext zum Ergebnis eines Incidents, unterstützt die Kategorisierung von Lösungen und zeigt Trends beim Schließen von Incidents.

Bezugsquelle

Das standardmäßige Feld „Resolution“ eines Jira-Vorgangs. Dieses Feld wird in der Regel gesetzt, wenn ein Vorgang in eine Statuskategorie „Done“ überführt wird.

Beispiele
ErledigtBehobenDuplikatWird nicht behoben
Meldende Person
Reporter
Der Benutzer, der den Incident ursprünglich erstellt oder gemeldet hat.
Beschreibung

Die meldende Person ist der Benutzer, häufig ein Endbenutzer oder ein anderes System, der den Incident zuerst erfasst hat. Die Analyse von Incidents nach meldender Person kann zeigen, welche Benutzer oder Abteilungen besonders häufig Probleme melden. Sie hilft auch dabei, Kommunikationsmuster zu verstehen, insbesondere bei der Analyse von Aktivitäten wie „Waiting for Customer“ und „Customer Responded“.

Warum das wichtig ist

Unterstützt die Analyse von Incident-Quellen, die Identifizierung von Mustern bei bestimmten Benutzern oder Abteilungen sowie das Verständnis von Verzögerungen in der Kundeninteraktion.

Bezugsquelle

Das standardmäßige Feld „Reporter“ eines Jira-Vorgangs.

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

Der Schweregrad beschreibt, wie stark sich ein Incident auf das Geschäft auswirkt, von der Beeinträchtigung eines einzelnen Benutzers bis zum Ausfall eines kritischen Systems. Während die Priorität die Reihenfolge der Bearbeitung bestimmt, beschreibt der Schweregrad die geschäftlichen Gesamtauswirkungen. Die Analyse nach Schweregrad zeigt, wie leistungsfähig der Prozess bei den für das Unternehmen wichtigsten Incidents ist. Häufig wird sie mit der Priorität kombiniert, um eine differenziertere Analyse zu ermöglichen.

Warum das wichtig ist

Zeigt die geschäftlichen Auswirkungen und ermöglicht eine Analyse der Incidents, die den Geschäftsbetrieb am stärksten beeinträchtigen.

Bezugsquelle

In Jira handelt es sich in der Regel um ein benutzerdefiniertes Feld, da es kein standardmäßiges Systemfeld ist. Prüfen Sie die Projektkonfiguration von Jira Service Management.

Beispiele
KritischSchwerwiegendGeringfügigUnbedeutend
SLA-Verletzung
SlaBreach
Ein Kennzeichen dafür, ob die Lösungszeit des Incidents den SLA-Zielwert überschritten hat.
Beschreibung

Dieses berechnete boolesche Attribut gibt an, ob ein Incident sein SLA für die Lösungszeit verletzt hat. Der Wert ist wahr, wenn „IncidentResolutionCycleTime“ größer als „TimeToResolutionTarget“ ist. Das Kennzeichen vereinfacht Analyse und Visualisierung und ermöglicht das einfache Filtern und Aggregieren zur Berechnung der KPI zur SLA-Verletzungsrate. Es ist die zentrale Ergebniskennzahl für das Dashboard zur Überwachung der SLA-Leistung.

Warum das wichtig ist

Liefert ein eindeutiges binäres Ergebnis zur SLA-Leistung und erleichtert dadurch die Berechnung von Verletzungsraten sowie die Identifizierung problematischer Bereiche.

Bezugsquelle

Berechnet als („IncidentResolutionCycleTime“ > „TimeToResolutionTarget“).

Beispiele
truefalse
Vorgangstyp
IssueType
Der Typ des Vorgangs, etwa Incident, Service Request oder Problem.
Beschreibung

Jira verwendet Issue Types, um verschiedene Arten von Aufgaben zu unterscheiden. Im Kontext des Incident Managements ist „Incident“ der wichtigste Typ, aber auch andere Typen wie „Sub-task“ können relevant sein. Dieses Attribut ist entscheidend, um den Datensatz auf Incidents zu beschränken und sicherzustellen, dass sich die Process-Mining-Analyse auf den richtigen Prozess konzentriert.

Warum das wichtig ist

Stellt sicher, dass die Analyse auf Incidents begrenzt bleibt und andere Arbeitsarten wie Service Requests oder Changes getrennt betrachtet werden.

Bezugsquelle

Das standardmäßige Feld „Issue Type“ eines Jira-Vorgangs.

Beispiele
IncidentIT-HilfeFehler
Zielwert für die Lösungszeit
TimeToResolutionTarget
Die SLA-Zieldauer für die Lösung des Incidents.
Beschreibung

Dieses Attribut definiert die erwartete maximale Zeit, innerhalb der ein Incident einer bestimmten Priorität oder eines bestimmten Typs gelöst werden sollte. Es ist der Referenzwert, mit dem die tatsächliche Lösungszeit verglichen wird, um die SLA-Konformität zu bestimmen. Der Wert wird in der Regel dynamisch anhand von Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Vorgangstyp berücksichtigen. Er ist eine zentrale Grundlage für jedes Dashboard zur Überwachung der SLA-Leistung.

Warum das wichtig ist

Liefert den Referenzwert für die Messung der SLA-Konformität und bildet die Grundlage für die KPI zur SLA-Verletzungsrate bei Incidents.

Bezugsquelle

Dieser Wert wird aus der SLA-Konfiguration in Jira Service Management abgeleitet. Das konkrete Ziel, etwa „Time to resolution“, muss identifiziert werden.

Beispiele
4 Std.8 Std.3 Tage
Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Erkennung und Analyse Ihrer Incident-Lösungs-Workflows in Ihrem Event Log erfassen sollten.
7 Empfohlen 8 Optional
Aktivität Beschreibung
Incident erneut zugewiesen
Tritt auf, wenn ein Incident nach der erstmaligen Zuweisung von einem Mitarbeiter oder einer Gruppe an einen anderen Mitarbeiter oder eine andere Gruppe übertragen wird. Das Ereignis wird aus jeder Änderung des Felds „Assignee“ oder „Assigned Group“ abgeleitet.
Warum das wichtig ist

Die Nachverfolgung von Neuzuweisungen ist für die Analyse von Übergaben entscheidend. Eine hohe Zahl an Neuzuweisungen weist häufig auf Prozesseffizienzen, Wissenslücken oder eine fehlerhafte anfängliche Weiterleitung hin und führt zu Verzögerungen bei der Lösung.

Bezugsquelle

Das Ereignis wird aus der Problemhistorie abgeleitet, indem jede Aktualisierung des Felds „Assignee“ nach dessen erstmaliger Befüllung erkannt wird. Jede Änderung stellt ein Ereignis zur Neuzuweisung dar.

Erfassen

Erkennen Sie nach der erstmaligen Zuweisung weitere Änderungen des Felds „Assignee“.

Ereignistyp inferred
Incident erstellt
Kennzeichnet den offiziellen Beginn des Incident-Lebenszyklus, sobald ein Incident-Bericht eingereicht und in Jira ein neues Problem erstellt wird. Dieses Ereignis wird ausdrücklich erfasst, wenn im System ein neues Problem des Typs „Incident“ protokolliert wird.
Warum das wichtig ist

Dies ist das primäre Start-Ereignis des Prozesses. Die Zeit von dieser Aktivität bis zur Lösung ist grundlegend für die Messung der gesamten Durchlaufzeit und der SLA-Einhaltung.

Bezugsquelle

Dies ist ein ausdrücklich erfasstes Ereignis, das aus dem Timestamp „created“ des Incident-Problems in Jira übernommen wird. Das Ereignis der Problemerstellung wird in der Historie des Problems protokolliert.

Erfassen

Verwenden Sie den Timestamp der Problemerstellung.

Ereignistyp explicit
Incident gelöst
Diese Aktivität bestätigt, dass der Incident erfolgreich gelöst und der Service wiederhergestellt wurde. Häufig fällt sie mit dem Wechsel zum Status „Resolved“ zusammen.
Warum das wichtig ist

Dies ist der wichtigste Erfolgsmeilenstein des Prozesses. Die Dauer bis zu diesem Zeitpunkt ist die gängigste KPI und entspricht der Time to Resolution (TTR).

Bezugsquelle

Das Ereignis wird aus dem Statuswechsel zu „Resolved“ abgeleitet. In vielen Workflows entspricht es dem Ereignis „Resolution Proposed“ und markiert den zentralen Lösungspunkt.

Erfassen

Ermitteln Sie den Timestamp des Statuswechsels zu „Resolved“.

Ereignistyp inferred
Incident geschlossen
Bezeichnet den abschließenden administrativen Abschluss des Incident-Tickets, nachdem der Incident gelöst und verifiziert wurde. Das Ereignis wird aus dem Statuswechsel zu „Closed“ abgeleitet.
Warum das wichtig ist

Dies ist das Endereignis des Prozesses. Die Analyse der Zeit zwischen „Resolved“ und „Closed“ kann Verzögerungen bei administrativen Bereinigungen oder bei der Bestätigung durch Benutzer sichtbar machen.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Es entspricht dem Timestamp, an dem der Status in den endgültigen Zustand „Closed“ wechselt.

Erfassen

Ermitteln Sie den Timestamp des Statuswechsels zu „Closed“.

Ereignistyp inferred
Lösung vorgeschlagen
Diese Aktivität zeigt an, dass eine Lösung identifiziert und umgesetzt wurde und der Incident auf Bestätigung oder abschließende Validierung wartet. Das Ereignis wird aus dem Statuswechsel zu „Resolved“ abgeleitet.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein und kennzeichnet das Ende der aktiven Arbeit des Support-Teams. Häufig stoppt dieses Ereignis die SLA-Uhr.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Der Ereignis-Timestamp entspricht dem Zeitpunkt, an dem der Status zu „Resolved“ oder einem gleichwertigen Zustand wechselt.

Erfassen

Ermitteln Sie den Timestamp des Statuswechsels zu „Resolved“.

Ereignistyp inferred
Untersuchung gestartet
Zeigt an, dass ein zugewiesener Mitarbeiter mit der aktiven Diagnose des Incidents begonnen hat. In der Regel wird dies abgeleitet, wenn der Status des Incident-Problems von „Open“ oder „New“ zu „In Progress“ wechselt.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert den Beginn der aktiven Lösungsarbeit. Die Messung der Zeit bis zu dieser Aktivität hilft, anfängliche Wartezeiten in der Warteschlange und Probleme bei der Ressourcenverfügbarkeit zu erkennen.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Der Ereignis-Timestamp entspricht dem Zeitpunkt, an dem der Status in einen Zustand für aktive Arbeit wechselt, etwa „In Progress“.

Erfassen

Ermitteln Sie den Timestamp des Statuswechsels zu „In Progress“.

Ereignistyp inferred
Warten auf den Kunden
Kennzeichnet einen Zeitpunkt, an dem das Support-Team auf Informationen oder eine Handlung des Kunden wartet. Das Ereignis wird aus einem Statuswechsel zu einem speziellen Wartestatus wie „Waiting for customer“ abgeleitet.
Warum das wichtig ist

Die Isolierung dieser Wartezeit ist für eine präzise SLA-Messung entscheidend, da sie häufig aus den Berechnungen der Lösungszeit ausgeschlossen wird. So lassen sich Verzögerungen bei der Kundenreaktion analysieren.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Es entspricht dem Timestamp, an dem der Status zu „Waiting for customer“ oder einem ähnlichen Zustand wechselt.

Erfassen

Ermitteln Sie den Timestamp des Statuswechsels zu „Waiting for customer“.

Ereignistyp inferred
An spezialisiertes Team eskaliert
Bezeichnet die Eskalation eines Incidents an ein spezialisiertes Team, etwa Tier 2 oder die Entwicklung, zur weiterführenden Unterstützung. Das Ereignis wird aus einer Änderung eines benutzerdefinierten Felds „Support Team“ oder einer bestimmten Neuzuweisung abgeleitet.
Warum das wichtig ist

Macht Incidents sichtbar, die spezielles Wissen erfordern, und verfolgt den Übergang zwischen verschiedenen Support-Ebenen. So lassen sich Bottlenecks in spezialisierten Teams erkennen und Eskalationsmuster analysieren.

Bezugsquelle

Das Ereignis wird aus der Problemhistorie abgeleitet, indem Änderungen an einem benutzerdefinierten Feld für das zugewiesene Team verfolgt oder Änderungen des Felds „Assignee“ zu einem Mitglied einer bekannten Spezialistengruppe erkannt werden.

Erfassen

Erkennen Sie eine Änderung in einem benutzerdefinierten Feld für „Assigned Team“ oder bestimmte Änderungen des Felds „Assignee“.

Ereignistyp inferred
Incident erneut geöffnet
Bezeichnet eine Situation, in der ein zuvor gelöster Incident reaktiviert wird, weil das Problem erneut aufgetreten oder die Korrektur unwirksam war. Das Ereignis wird aus einem Statuswechsel von „Resolved“ oder „Closed“ zurück in einen offenen Status abgeleitet.
Warum das wichtig ist

Erneut geöffnete Incidents sind ein direktes Maß für die Lösungsqualität und ein wichtiger Indikator für Nacharbeit. Die Analyse dieser Ereignisse hilft, verfrühte Abschlüsse und unwirksame Lösungen zu erkennen.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Es wird protokolliert, wenn der Status von einem Endzustand wie „Resolved“ oder „Closed“ zurück zu „Open“ oder „In Progress“ wechselt.

Erfassen

Erkennen Sie den Statuswechsel von „Resolved“ oder „Closed“ zu einem offenen Status.

Ereignistyp inferred
Incident priorisiert
Bezeichnet die Festlegung der Priorität und/oder des Schweregrads eines Incidents. Diese Einstufung bestimmt seine Dringlichkeit und geschäftlichen Auswirkungen. In der Regel wird das Ereignis aus dem ersten Befüllen oder Aktualisieren der Felder „Priority“ oder „Severity“ nach der Erstellung abgeleitet.
Warum das wichtig ist

Die Nachverfolgung der Priorisierung zeigt, ob Incidents zeitnah und einheitlich bewertet werden. Verzögerungen in diesem Schritt können sich direkt auf SLA-Berechnungen und die Ressourcenzuweisung auswirken.

Bezugsquelle

Das Ereignis wird aus dem Verlauf des Problems abgeleitet, in dem Änderungen an allen Feldern erfasst werden. Suchen Sie nach der ersten Aktualisierung des Felds „Priority“ oder eines benutzerdefinierten Felds „Severity“ nach dem Ereignis der Problemerstellung.

Erfassen

Erkennen Sie die erste Änderung des Felds „Priority“ in der Problemhistorie.

Ereignistyp inferred
Incident zugewiesen
Diese Aktivität bezeichnet die erstmalige Zuweisung des Incidents an einen Support-Mitarbeiter oder eine Support-Gruppe zur Bearbeitung. Sie wird erfasst, indem der erste Zeitpunkt ermittelt wird, an dem das Feld „Assignee“ oder „Assigned Group“ befüllt wird.
Warum das wichtig ist

Misst die Zeit bis zur ersten Reaktion und Zuweisung, die ein wichtiger Bestandteil der SLA-Kennzahlen ist. So lassen sich Verzögerungen erkennen, bevor die aktive Untersuchung beginnt.

Bezugsquelle

Das Ereignis wird aus der Problemhistorie abgeleitet, indem die erste Änderung des Felds „Assignee“ erkannt wird, bei der der vorherige Wert „Unassigned“ war.

Erfassen

Erkennen Sie die erste Aktualisierung des Felds „Assignee“ in der Problemhistorie.

Ereignistyp inferred
Kommentar hinzugefügt
Bezeichnet jedes Kommunikations- oder Dokumentationsereignis, bei dem ein Benutzer einen Kommentar zum Incident-Ticket hinzufügt. Dieses ausdrücklich erfasste Ereignis tritt bei jedem veröffentlichten Kommentar auf.
Warum das wichtig ist

Die Analyse der Kommentierhäufigkeit kann Erkenntnisse über Kommunikationsmuster, die Effizienz der Zusammenarbeit und die Komplexität eines Incidents liefern. Sie kann Incidents sichtbar machen, die übermäßig viel Kommunikation erfordern.

Bezugsquelle

Dies ist ein ausdrücklich erfasstes Ereignis. Jira speichert jeden Kommentar mit Timestamp und Autor. Diese Informationen sind über die Kommentarhistorie des Problems oder die API verfügbar.

Erfassen

Verwenden Sie den Timestamp jedes zum Problem hinzugefügten Kommentars.

Ereignistyp explicit
Kunde hat geantwortet
Zeigt an, dass der Kunde die angeforderten Informationen bereitgestellt hat und der Incident fortgesetzt werden kann. Das Ereignis wird abgeleitet, wenn der Status von „Waiting for customer“ zurück in einen aktiven Status wechselt.
Warum das wichtig ist

Diese Aktivität markiert das Ende einer durch den Kunden verursachten Verzögerung. Die Analyse der Dauer zwischen „Waiting For Customer“ und diesem Ereignis zeigt die durchschnittliche Reaktionszeit des Kunden.

Bezugsquelle

Das Ereignis wird aus der Statusänderungshistorie des Problems abgeleitet. Es tritt auf, wenn der Status von „Waiting for customer“ zu einem Status wie „In Progress“ wechselt, häufig ausgelöst durch einen Kommentar des Kunden.

Erfassen

Erkennen Sie den Statuswechsel von „Waiting for customer“ zu „In Progress“.

Ereignistyp inferred
Mit Problem-Ticket verknüpft
Tritt auf, wenn ein Incident zur Ursachenanalyse mit einem „Problem“-Problem verknüpft wird. Dieses ausdrücklich erfasste Ereignis entsteht, wenn ein Link „relates to“ oder „caused by“ zu einem Problem-Typ erstellt wird.
Warum das wichtig ist

Die Nachverfolgung dieses Links ist entscheidend, um zu verstehen, wie wirksam ein Unternehmen von der Eindämmung eines Incidents zu Ursachenanalyse und Prävention übergeht.

Bezugsquelle

Dies ist ein ausdrücklich erfasstes Ereignis in der Linkhistorie des Problems. Jede Link-Erstellung verfügt über einen Timestamp und kann nach Links zum Problem-Typ „Problem“ gefiltert werden.

Erfassen

Verwenden Sie den Timestamp der Erstellung eines Problem-Links zum Problem-Typ „Problem“.

Ereignistyp explicit
Workaround bereitgestellt
Bezeichnet die Umsetzung einer vorübergehenden Korrektur, durch die der Service wiederhergestellt wird, während eine dauerhafte Lösung entwickelt wird. Das Ereignis kann aus einer Statusänderung oder einem bestimmten Kommentar abgeleitet werden.
Warum das wichtig ist

Die Messung der Zeit bis zur Bereitstellung eines Workarounds ist ein wichtiger Indikator für die Geschwindigkeit der Service-Wiederherstellung. So lässt sich zwischen einer vorübergehenden Abhilfe und einer dauerhaften Lösung unterscheiden.

Bezugsquelle

Dieses Ereignis wird häufig abgeleitet. Möglich ist ein Wechsel zu einem Status wie „Workaround Provided“ oder ein öffentlicher Kommentar mit bestimmten Schlüsselwörtern wie „workaround“.

Erfassen

Erkennen Sie einen bestimmten Statuswechsel oder ein Schlüsselwort in einem Kommentar.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Extraktion

So extrahieren Sie Ihre Daten aus Jira Service Management

Bereit für den Start?

Verwenden Sie dieses Daten-Template, um Ihr Incident Management zu verbessern, Ineffizienzen zu identifizieren und Incidents schneller zu lösen. Beginnen Sie noch heute mit der Optimierung Ihres Prozesses.

Optimieren Sie Ihr Incident Management und lösen Sie Incidents schneller

Senken Sie die MTTR um 35 % und steigern Sie die Zufriedenheit der Anwender durch effizientere Prozesse.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich • Einrichtung in 5 Minuten