Ihr Daten-Template für das Incident Management

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

Ihr Daten-Template für das Incident Management

Dieses Template bietet eine strukturierte Anleitung, mit der Sie die wichtigsten Daten für die Analyse Ihres Incident-Management-Prozesses erfassen. Es beschreibt die zentralen Attribute und Aktivitäten, die Sie berücksichtigen sollten, und zeigt, wie Sie die Informationen aus Ihrem Quellsystem extrahieren. Damit erhalten Sie alle nötigen Grundlagen, um Ihre Workflows zur Incident-Lösung zu optimieren.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Anleitung zur Datenextraktion aus Jira Service Management
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für das Incident Management

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Incident-Management-Prozess umfassend zu analysieren.
5 Erforderlich 6 Empfohlen 12 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name des konkreten Ereignisses oder der Statusänderung beim Vorfall.
Beschreibung

Die Aktivität bezeichnet einen einzelnen Schritt oder ein Ereignis im Lebenszyklus des Vorfallmanagements, etwa „Vorfall erstellt“, „Vorfall zugewiesen“ oder „Lösung vorgeschlagen“. Diese Aktivitäten werden in der Regel aus Statusübergängen oder bestimmten Aktualisierungen im Verlauf beziehungsweise Änderungsprotokoll des Jira-Vorgangs abgeleitet. Die Analyse ihrer Reihenfolge und Dauer ist das zentrale Ziel des Process Mining. Sie macht den tatsächlichen Prozessablauf, Engpässe und Abweichungen sichtbar.

Warum das wichtig ist

Aktivitäten bilden das Grundgerüst der Prozessübersicht und ermöglichen es, den Lebenszyklus eines Vorfalls darzustellen und zu analysieren.

Woher beziehen

Aus dem Verlauf und den Änderungsprotokolldaten des Jira-Vorgangs abgeleitet. Erfasst werden Statusübergänge und wichtige Änderungen an Feldern.

Beispiele
Vorfall zugewiesenUntersuchung begonnenVorfall gelöst
Startzeit
EventTimestamp
Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung

Dieses Attribut erfasst den Timestamp jeder Aktivität im Lebenszyklus eines Vorfalls. Es ist entscheidend, um die Dauer einzelner Schritte sowie Zyklus- und Wartezeiten zwischen ihnen zu berechnen. Genaue Timestamps ermöglichen detaillierte Leistungsanalysen, die Überwachung von SLAs und die Ermittlung von Engpässen. Alle Leistungskennzahlen, etwa die Lösungszeit und die Dauer der Diagnose, werden aus diesen Timestamps berechnet.

Warum das wichtig ist

Timestamps sind unverzichtbar, um zeitbasierte Kennzahlen zu berechnen, die Prozessdauer zu verstehen und Leistungsengpässe aufzudecken.

Woher beziehen

Dies ist das Erstellungsdatum des jeweiligen Eintrags im Änderungsprotokoll oder Verlauf des Jira-Vorgangs.

Beispiele
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Vorfall-ID
IncidentId
Die eindeutige Kennung für jedes Vorfallticket in Jira Service Management.
Beschreibung

Die Vorfall-ID, in Jira häufig als Vorgangsschlüssel bezeichnet, ist die eindeutige Kennung jedes gemeldeten Vorfalls. Sie verknüpft alle zugehörigen Aktivitäten, Kommentare und Statusänderungen vom Zeitpunkt der Erstellung bis zum endgültigen Abschluss. Beim Process Mining ist diese ID entscheidend, um den gesamten Lebenszyklus jedes einzelnen Vorfalls nachzuvollziehen und den Prozess vollständig zu analysieren.

Warum das wichtig ist

Diese zentrale Kennung führt alle zugehörigen Ereignisse zu einem einzelnen Case zusammen und bildet damit die Grundlage jeder Process-Mining-Analyse.

Woher beziehen

Dies ist das Standardfeld „Key“ für einen Vorgang in Jira Service Management, zum Beispiel „ITSM-123“.

Beispiele
INC-10234HELPDESK-5678OPS-9901
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp der letzten Aktualisierung der Daten aus dem Quellsystem.
Beschreibung

Dieses Attribut erfasst, wann der Datensatz zuletzt aktualisiert wurde. Es zeigt allen, die den Prozess analysieren, wie aktuell die Daten sind. Das ist besonders wichtig für Dashboards zur laufenden Überwachung, bei denen aktuelle Informationen zeitnahe Entscheidungen ermöglichen. Innerhalb eines einzelnen Datenextraktionslaufs ist der Wert in der Regel für alle Ereignisse gleich.

Warum das wichtig ist

Informiert Benutzer darüber, wie aktuell die Daten sind. Das ist entscheidend für die Aussagekraft und Genauigkeit der Analyse.

Woher beziehen

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 an, woher die Daten stammen, in diesem Fall aus Jira Service Management. Es ist besonders hilfreich, wenn Daten aus mehreren Systemen für eine umfassende Prozesssicht zusammengeführt werden. Die Angabe des Quellsystems sorgt für eine nachvollziehbare Datenherkunft und erleichtert die Untersuchung von Problemen mit der Datenqualität oder Datenextraktion. In diesem Modell ist der Wert statisch.

Warum das wichtig ist

Gibt wichtigen Kontext zur Herkunft der Daten und sorgt für Klarheit und Nachvollziehbarkeit, besonders bei Analysen über mehrere Systeme hinweg.

Woher beziehen

Dies ist ein statischer Wert, der bei der Datenextraktion hinzugefügt werden sollte.

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

Dieses Attribut kennzeichnet den offiziellen Beginn des Lebenszyklus eines Vorfalls. Es ist der Ausgangs-Timestamp für Kennzahlen wie die gesamte Lösungszeit. Das Erstellungsdatum bleibt für jeden Vorfall unverändert und bildet den Startpunkt des gesamten Case in der Process-Mining-Analyse.

Warum das wichtig ist

Dient als Ausgangspunkt für die Berechnung der durchgängigen Zykluszeit und der SLA-Messwerte.

Woher beziehen

Das Standardfeld „Created“ eines Jira-Vorgangs.

Beispiele
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Lösungsdatum
ResolutionDate
Datum und Uhrzeit, zu denen der Vorfall als gelöst markiert wurde.
Beschreibung

Dieses Attribut erfasst den Timestamp, zu dem der Vorfall erstmals in einen gelösten Status versetzt wurde. Damit endet die aktive Bearbeitungsphase und der Endpunkt für die Berechnung der Lösungszeit ist festgelegt. Der Vergleich des Lösungsdatums mit dem Erstellungsdatum liefert das wichtigste Maß für die Prozesseffizienz. Außerdem ist das Lösungsdatum ein wichtiger Faktor bei der Prüfung der SLA-Konformität.

Warum das wichtig ist

Kennzeichnet das Ende des Lösungsprozesses und ermöglicht die Berechnung der gesamten Zykluszeit und der SLA-Leistung.

Woher beziehen

Das Standardfeld „Resolved“ eines Jira-Vorgangs.

Beispiele
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Priorität
Priority
Die dem Vorfall zugewiesene Prioritätsstufe, die angibt, wie dringend eine Lösung erforderlich ist.
Beschreibung

Die Priorität bestimmt, wie schnell ein Vorfall bearbeitet werden muss. Sie ergibt sich häufig aus den Auswirkungen und der Dringlichkeit und beeinflusst direkt die SLA-Ziele. Eine Analyse nach Priorität zeigt, ob Vorfälle mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität und ob die Priorisierung einheitlich erfolgt. Sie ist eine wichtige Dimension, um die Prozessleistung zu filtern und zu vergleichen.

Warum das wichtig ist

Wichtig für die Analyse der SLA-Leistung und zur Prüfung, ob Ressourcen den kritischsten Vorfällen angemessen zugewiesen werden.

Woher beziehen

Das Standardfeld „Priority“ eines Jira-Vorgangs.

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

Das Feld „Status“ zeigt die aktuelle Phase eines Vorfalls im festgelegten Workflow an, zum Beispiel „Offen“, „In Bearbeitung“, „Warten auf Kunden“ oder „Gelöst“. Statusänderungen sind die wichtigste Quelle für das Aktivitätsprotokoll beim Process Mining. Die Analyse der Verweildauer in den einzelnen Status ist grundlegend, um Engpässe zu erkennen und festzustellen, wo Vorfälle die meiste Zeit verbringen.

Warum das wichtig ist

Zeigt direkt den Fortschritt des Vorfalls und ist die wichtigste Quelle, um Prozessschritte und Wartezeiten zu ermitteln.

Woher beziehen

Das Standardfeld „Status“ eines Jira-Vorgangs.

Beispiele
In BearbeitungWarten auf KundenGelöstGeschlossen
Zuständige Gruppe
AssignmentGroup
Das Team oder die Gruppe, die für die Bearbeitung des Vorfalls zuständig ist.
Beschreibung

Die zuständige Gruppe bezeichnet das Team, dem der Vorfall zugewiesen wurde. Das kann eine Supportstufe wie „L1 Helpdesk“, ein spezialisiertes Team wie „Netzwerkbetrieb“ oder ein Entwicklungsteam sein. Die Analyse von Wechseln zwischen zuständigen Gruppen ist wichtig, um Eskalationen und Übergaben im Prozess zu verstehen. So lassen sich die Teamleistung messen, Engpässe auf Teamebene erkennen und Abhängigkeiten zwischen Teams untersuchen.

Warum das wichtig ist

Wichtig für die Analyse der Teamleistung, des Durchsatzes und des Arbeitsflusses zwischen verschiedenen Supportstufen oder spezialisierten Gruppen.

Woher beziehen

In Jira wird dies häufig über ein benutzerdefiniertes Feld wie „Team“ oder „Assignment Group“ abgebildet. Der Wert lässt sich mitunter aus Jira-Komponenten oder Projektrollen ableiten.

Beispiele
Supportstufe 1InfrastrukturteamDatenbankadministratoren
Zuständige Person
Assignee
Der Benutzer, der aktuell für die Bearbeitung des Vorfalls zuständig ist.
Beschreibung

Die zuständige Person ist der Mitarbeiter oder Benutzer, der zu einem bestimmten Zeitpunkt für den Vorfall verantwortlich ist. Änderungen der Zuständigkeit sind wichtig, um Übergaben und die Arbeitsverteilung zu analysieren und festzustellen, welche Personen an bestimmten Prozessschritten beteiligt sind. Mit diesem Attribut lassen sich Fragen zur individuellen Leistung und zur Ressourcenverteilung in den Supportteams beantworten.

Warum das wichtig ist

Hilft dabei, die Arbeitslast einzelner Personen nachzuverfolgen, Engpässe bei bestimmten Mitarbeitern zu erkennen und die Auswirkungen von Übergaben auf die Lösungszeit zu analysieren.

Woher beziehen

Das Standardfeld „Assignee“ eines Jira-Vorgangs.

Beispiele
John SmithEmily JonesServiceDeskAgent1
Anzahl der Übergaben
HandoffCount
Wie oft der Vorfall einer anderen Gruppe oder einem anderen Benutzer zugewiesen wurde.
Beschreibung

Diese berechnete Kennzahl zählt, wie oft sich das Feld „Assignee“ oder „AssignmentGroup“ im Lebenszyklus des Vorfalls geändert hat. Eine hohe Zahl an Übergaben deutet häufig auf ineffiziente Abläufe, eine geringe Lösungsquote beim Erstkontakt oder Wissenslücken hin und führt zu längeren Lösungszeiten. Die Analyse dieser KPI hilft, den Zuweisungsprozess zu verbessern und die Zusammenarbeit zwischen Teams zu stärken.

Warum das wichtig ist

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

Woher beziehen

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

Beispiele
015
Ist Nacharbeit
IsRework
Kennzeichnet, ob der Incident nachbearbeitet wurde, zum Beispiel durch erneutes Öffnen.
Beschreibung

Dieses berechnete boolesche Attribut kennzeichnet Incidents, die im Prozess an eine frühere Phase zurückgesetzt wurden. Am häufigsten geschieht dies, wenn ein Incident nach seiner Lösung erneut geöffnet wird. Nacharbeitsschleifen sind eine wesentliche Ursache für Ineffizienz und Unzufriedenheit bei Kunden. Mit dieser Kennzeichnung lässt sich die Nacharbeitsquote einfach ermitteln. Außerdem können Sie gezielt untersuchen, warum Incidents nicht gleich beim ersten Mal korrekt gelöst werden.

Warum das wichtig ist

Macht Probleme mit der Prozessqualität und Ineffizienzen sichtbar, indem Incidents gekennzeichnet werden, die wiederholt bearbeitet werden müssen. So unterstützt das Attribut direkt die Nacharbeitsanalyse.

Woher beziehen

Berechnet durch Erkennung bestimmter Abfolgen von Statusänderungen im Event Log, zum Beispiel „Resolved“ -> „Reopened“.

Beispiele
truefalse
Kategorie der Grundursache
RootCauseCategory
Die Einordnung der zugrunde liegenden Ursache des Vorfalls.
Beschreibung

Dieses Attribut erfasst den grundlegenden Grund für den Vorfall, etwa „Softwarefehler“, „Hardwareausfall“ oder „Benutzerfehler“. Es wird üblicherweise nach einer Untersuchung ausgefüllt und ist wichtig für ein wirksames Problemmanagement und die Vermeidung künftiger Vorfälle. Die Analyse der Grundursachenkategorien hilft, systemische Schwachstellen zu erkennen und Verbesserungsmaßnahmen zu priorisieren. Ein hoher Anteil unbekannter Grundursachen kann auf Verbesserungsbedarf bei den Untersuchungsprozessen hindeuten.

Warum das wichtig ist

Ermöglicht die Ursachenanalyse und unterstützt den Wechsel von einem reaktiven zu einem proaktiven Vorgehen, indem die Ursachen von Vorfällen erkannt und behoben werden.

Woher beziehen

In Jira ist dies fast immer ein benutzerdefiniertes Feld. Name und Auswahlmöglichkeiten hängen stark von der jeweiligen Konfiguration der Organisation ab.

Beispiele
KonfigurationsfehlerNetzwerkausfallSoftwarefehler
Komponente
Component
Das System, die Anwendung oder der Teil der Infrastruktur, der vom Vorfall betroffen ist.
Beschreibung

Komponenten sind Unterbereiche eines Jira-Projekts, mit denen Vorgänge gruppiert werden, etwa „Benutzeroberfläche“, „Datenbank“ oder „API“. Eine Analyse der Vorfälle nach Komponente zeigt, welche Teile eines Systems besonders häufig Probleme verursachen. 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 Filter und Analysen nach dem betroffenen Produkt oder Systembereich und hilft, technische Problembereiche zu erkennen.

Woher beziehen

Das Standardfeld „Components“ eines Jira-Vorgangs.

Beispiele
AuthentifizierungsdienstBerichts-DashboardMobile App
Kundenanfragetyp
CustomerRequestType
Die konkrete Art 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, zum Beispiel „Systemproblem melden“. Es bietet eine benutzerfreundliche Einordnung des Vorfalls, die sich vom internen „Vorgangstyp“ unterscheiden kann. Die Analyse dieses Attributs zeigt, wie Kunden Probleme wahrnehmen und melden. Daraus lassen sich Verbesserungen am Portal und am Serviceangebot ableiten.

Warum das wichtig ist

Zeigt Vorfallkategorien aus Kundensicht und eignet sich zur Analyse der Nachfrage und zur Verbesserung der Customer Experience.

Woher beziehen

Das Feld „Customer Request Type“, das speziell für Jira-Service-Management-Projekte vorgesehen ist.

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

Das Feld „Lösung“ gibt an, warum ein Vorfall in einen gelösten Status versetzt wurde. Häufige Lösungen sind „Behoben“, „Duplikat“, „Wird nicht umgesetzt“ oder „Nicht reproduzierbar“. Die Verteilung der Lösungsarten kann Erkenntnisse zur Qualität eingehender Meldungen und zur Wirksamkeit des Lösungsprozesses liefern. Eine hohe Zahl von Fällen mit der Lösung „Duplikat“ kann beispielsweise auf Probleme bei der Erstellung oder Triage von Vorfällen hindeuten.

Warum das wichtig ist

Liefert Kontext zum Ergebnis eines Vorfalls, erleichtert die Einordnung der Lösungen und zeigt Trends beim Abschluss von Vorfällen.

Woher beziehen

Das Standardfeld „Resolution“ eines Jira-Vorgangs. Dieses Feld wird üblicherweise gesetzt, wenn ein Vorgang in eine Statuskategorie „Erledigt“ wechselt.

Beispiele
ErledigtBehobenDuplikatWird nicht behoben
Meldender
Reporter
Der Benutzer, der den Vorfall ursprünglich erstellt oder gemeldet hat.
Beschreibung

Der Meldende ist die Person, häufig ein Endbenutzer, oder ein anderes System, das den Vorfall zuerst erfasst hat. Eine Analyse nach Meldenden kann zeigen, welche Benutzer oder Abteilungen besonders häufig von Problemen betroffen sind. Sie hilft auch dabei, Kommunikationsmuster zu verstehen, insbesondere bei Aktivitäten wie „Warten auf Kunden“ und „Kunde hat geantwortet“.

Warum das wichtig ist

Hilft dabei, die Quellen von Vorfällen zu analysieren, Muster bei bestimmten Benutzern oder Abteilungen zu erkennen und Verzögerungen in der Kundenkommunikation zu verstehen.

Woher beziehen

Das Standardfeld „Reporter“ eines Jira-Vorgangs.

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

Der Schweregrad gibt an, wie stark ein Vorfall das Unternehmen beeinträchtigt, von der Betroffenheit eines einzelnen Benutzers bis zum Ausfall eines kritischen Systems. Während die Priorität die Reihenfolge der Bearbeitung festlegt, beschreibt der Schweregrad die geschäftlichen Auswirkungen insgesamt. Eine Analyse nach Schweregrad zeigt, wie gut der Prozess bei Vorfällen funktioniert, die für das Unternehmen besonders wichtig sind. Häufig wird der Schweregrad zusammen mit der Priorität ausgewertet, um ein differenzierteres Bild zu erhalten.

Warum das wichtig ist

Zeigt die geschäftlichen Auswirkungen und ermöglicht Analysen mit Fokus auf Vorfälle, die den Geschäftsbetrieb besonders stark beeinträchtigen.

Woher beziehen

In Jira ist dies üblicherweise ein benutzerdefiniertes Feld, da es kein Standardfeld des Systems ist. Prüfen Sie die Projektkonfiguration in Jira Service Management.

Beispiele
KritischSchwerwiegendGeringfügigUnbedeutend
SLA-Verletzung
SlaBreach
Kennzeichnet, ob die Lösungszeit des Vorfalls den SLA-Zielwert überschritten hat.
Beschreibung

Dieses berechnete boolesche Attribut gibt an, ob die SLA „Time to Resolution“ für einen Vorfall verletzt wurde. Der Wert ist wahr, wenn „IncidentResolutionCycleTime“ größer ist als „TimeToResolutionTarget“. Das Kennzeichen vereinfacht Analyse und Visualisierung: Durch Filtern und Aggregieren lässt sich die KPI zur SLA-Verletzungsrate leicht berechnen. Es ist die zentrale Ergebniskennzahl für das Dashboard zur Überwachung der SLA-Leistung.

Warum das wichtig ist

Liefert ein eindeutiges Ja-Nein-Ergebnis zur SLA-Leistung und erleichtert so die Berechnung der Verletzungsrate und die Erkennung von Problembereichen.

Woher beziehen

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

Beispiele
truefalse
Verknüpfte Problem-ID
LinkedProblemId
Die Kennung eines Problemtickets, das mit diesem Vorfall verknüpft ist.
Beschreibung

Vorfälle, die auf ein größeres zugrunde liegendes Problem zurückzuführen sind, werden häufig mit einem Problemticket verknüpft. Dieses Feld enthält die ID des zugehörigen Problems. Die Analyse dieser Verknüpfungen zeigt, wie Vorfälle und Probleme zusammenhängen, wie wirksam der Problemmanagementprozess ist und welche Vorfälle wiederholt auftreten und eine dauerhafte Lösung erfordern.

Warum das wichtig ist

Verknüpft Vorfälle mit zugrunde liegenden Problemen und ermöglicht so die Analyse, wie wirksam die Organisation Ursachen behebt, um künftige Vorfälle zu vermeiden.

Woher beziehen

Diese Informationen sind im Abschnitt „Issue Links“ eines Jira-Vorgangs gespeichert.

Beispiele
PROB-123PROB-456Keine
Vorgangstyp
IssueType
Die Art des Vorgangs, zum Beispiel Vorfall, Serviceanfrage oder Problem.
Beschreibung

Jira unterscheidet mit Vorgangstypen zwischen verschiedenen Arten von Aufgaben. Im Vorfallmanagement ist „Vorfall“ der wichtigste Typ, aber auch andere Typen wie „Unteraufgabe“ können relevant sein. Dieses Attribut ist entscheidend, um den Datensatz auf Vorfälle 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 Vorfälle beschränkt ist und andere Arbeitsarten wie Serviceanfragen oder Änderungen getrennt betrachtet werden.

Woher beziehen

Das Standardfeld „Issue Type“ eines Jira-Vorgangs.

Beispiele
VorfallIT-UnterstützungFehler
Zielwert für die Lösungszeit
TimeToResolutionTarget
Die SLA-Zieldauer für die Lösung des Vorfalls.
Beschreibung

Dieses Attribut legt die erwartete Höchstdauer fest, innerhalb derer ein Vorfall einer bestimmten Priorität oder Art gelöst werden sollte. Die tatsächliche Lösungszeit wird mit diesem Richtwert verglichen, um die SLA-Konformität zu bestimmen. Der Wert wird üblicherweise dynamisch anhand von Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Vorgangstyp berücksichtigen. Er ist eine wesentliche Grundlage für jedes Dashboard zur Überwachung der SLA-Leistung.

Warum das wichtig ist

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

Woher beziehen

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

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

Aktivitäten im Incident Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Ihre Workflows zur Incident-Lösung zuverlässig zu entdecken und zu analysieren.
7 Empfohlen 8 Optional
Aktivität Beschreibung
Lösung vorgeschlagen
Diese Aktivität zeigt an, dass eine Lösung gefunden und umgesetzt wurde und der Vorfall auf eine Bestätigung oder abschließende Prüfung wartet. Das Ereignis wird anhand des Statuswechsels zu „Resolved“ abgeleitet.
Warum das wichtig ist

Dieser wichtige Meilenstein kennzeichnet das Ende der aktiven Arbeit des Supportteams. Häufig wird damit auch die SLA-Zeitmessung beendet.

Woher beziehen

Das Ereignis wird aus dem Statusänderungsverlauf des Problems abgeleitet. Als Timestamp gilt der Zeitpunkt, an dem der Status zu „Resolved“ oder einem gleichwertigen Zustand wechselt.

Erfassung

Ermitteln Sie den Timestamp des Statuswechsels zu „Resolved“.

Ereignistyp inferred
Untersuchung begonnen
Zeigt an, dass eine zugewiesene Supportkraft mit der aktiven Diagnose des Vorfalls begonnen hat. Üblicherweise wird das Ereignis abgeleitet, wenn der Status des Vorfalls von „Open“ oder „New“ zu „In Progress“ wechselt.
Warum das wichtig ist

Dieser wichtige Meilenstein markiert den Beginn der aktiven Lösungsarbeit. Die Zeit bis zu dieser Aktivität zeigt anfängliche Wartezeiten in Warteschlangen und Probleme bei der Verfügbarkeit von Ressourcen auf.

Woher beziehen

Das Ereignis wird aus dem Statusänderungsverlauf des Problems abgeleitet. Als Timestamp gilt der Zeitpunkt, an dem der Status zu einem Zustand wechselt, der aktive Arbeit kennzeichnet, etwa „In Progress“.

Erfassung

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

Ereignistyp inferred
Vorfall erstellt
Kennzeichnet den offiziellen Beginn des Vorfalllebenszyklus: Ein Vorfall wird gemeldet und in Jira ein neues Problem erstellt. Das Ereignis wird ausdrücklich erfasst, wenn im System ein neues Problem vom Typ „Incident“ angelegt wird.
Warum das wichtig ist

Dies ist das primäre Start-Event des Prozesses. Die Zeit von dieser Aktivität bis zur Lösung ist entscheidend, um die gesamte Durchlaufzeit und die SLA-Einhaltung zu messen.

Woher beziehen

Dieses Ereignis wird ausdrücklich anhand des Erstellungs-Timestamps des Vorfalls in Jira erfasst. Die Erstellung des Problems wird im Verlauf des Problems protokolliert.

Erfassung

Verwenden Sie den Timestamp der Problemerstellung.

Ereignistyp explicit
Vorfall gelöst
Diese Aktivität bestätigt, dass der Vorfall 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 am häufigsten verwendete Kennzahl und entspricht der Zeit bis zur Lösung (TTR).

Woher beziehen

Das Ereignis wird aus dem Statuswechsel zu „Resolved“ abgeleitet. In vielen Workflows ist es identisch mit „Lösung vorgeschlagen“ und kennzeichnet den zentralen Zeitpunkt der Lösung.

Erfassung

Ermitteln Sie den Timestamp des Statuswechsels zu „Resolved“.

Ereignistyp inferred
Vorfall geschlossen
Kennzeichnet den endgültigen administrativen Abschluss des Vorfall-Tickets, nachdem der Vorfall gelöst und geprüft wurde. Das Ereignis wird anhand des Statuswechsels zu „Closed“ abgeleitet.
Warum das wichtig ist

Dies ist das abschließende Ereignis des Prozesses. Die Analyse der Zeit zwischen „Resolved“ und „Closed“ kann Verzögerungen bei administrativen Abschlussarbeiten oder bei der Bestätigung durch Benutzer aufzeigen.

Woher beziehen

Aus dem Änderungsverlauf des Vorgangsstatus abgeleitet. Das Ereignis entspricht dem Timestamp, zu dem der Status in den abschließenden Zustand „Geschlossen“ wechselt.

Erfassung

Ermitteln Sie den Timestamp des Statuswechsels zu „Geschlossen“.

Ereignistyp inferred
Vorfall neu zugewiesen
Dieses Ereignis tritt ein, wenn ein Vorfall nach der ersten Zuweisung von einer Supportkraft oder Gruppe an eine andere übergeben wird. Es wird anhand jeder Änderung am Feld „Assignee“ oder „Assigned Group“ abgeleitet.
Warum das wichtig ist

Die Erfassung von Neuzuweisungen ist für die Analyse von Übergaben entscheidend. Eine hohe Zahl von Neuzuweisungen deutet häufig auf ineffiziente Prozesse, Wissenslücken oder eine falsche Erstzuweisung hin und kann die Lösung verzögern.

Woher beziehen

Das Ereignis wird aus dem Problemverlauf abgeleitet, indem jede Aktualisierung des Felds „Assignee“ nach dessen erstmaliger Befüllung ermittelt wird. Jede Änderung gilt als Neuzuweisung.

Erfassung

Ermitteln Sie alle Änderungen am Feld „Assignee“ nach der ersten Zuweisung.

Ereignistyp inferred
Warten auf Kunden
Kennzeichnet einen Zeitpunkt, an dem das Supportteam auf Informationen oder eine Aktion des Kunden wartet. Das Ereignis wird anhand eines Statuswechsels zu einem eigens dafür vorgesehenen Wartestatus wie „Waiting for customer“ abgeleitet.
Warum das wichtig ist

Die separate Erfassung dieser Wartezeit ist für eine genaue SLA-Messung entscheidend, da sie häufig nicht in die Berechnung der Lösungszeit einfließt. So lassen sich Verzögerungen bei Kundenantworten untersuchen.

Woher beziehen

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

Erfassung

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

Ereignistyp inferred
An spezialisiertes Team eskaliert
Zeigt an, dass der Vorfall zur erweiterten Unterstützung an ein spezialisiertes Team eskaliert wurde, etwa an den Support der Stufe 2 oder die Entwicklung. Das Ereignis wird anhand einer Änderung an einem benutzerdefinierten Feld „Support Team“ oder einer bestimmten Neuzuweisung abgeleitet.
Warum das wichtig ist

Macht Vorfälle sichtbar, für die spezielles Fachwissen erforderlich ist, und erfasst den Wechsel zwischen verschiedenen Supportstufen. So lassen sich Engpässe in spezialisierten Teams und Muster bei Eskalationen untersuchen.

Woher beziehen

Das Ereignis wird aus dem Problemverlauf abgeleitet. Dazu werden Änderungen an einem benutzerdefinierten Feld für das zuständige Team erfasst oder eine Änderung des Felds „Assignee“ zu einem Mitglied einer bekannten Spezialistengruppe ermittelt.

Erfassung

Ermitteln Sie eine Änderung am benutzerdefinierten Feld „Assigned Team“ oder bestimmte Änderungen der zuständigen Person.

Ereignistyp inferred
Kommentar hinzugefügt
Kennzeichnet eine Mitteilung oder Notiz, die ein Benutzer als Kommentar zum Vorfall hinzufügt. Dieses Ereignis wird jedes Mal ausdrücklich erfasst, wenn ein Kommentar veröffentlicht wird.
Warum das wichtig ist

Die Analyse der Kommentarhäufigkeit kann Erkenntnisse zu Kommunikationsmustern, zur Effizienz der Zusammenarbeit und zur Komplexität eines Vorfalls liefern. Sie kann Vorfälle aufzeigen, bei denen besonders viel Kommunikation erforderlich ist.

Woher beziehen

Dieses Ereignis wird ausdrücklich erfasst. Jira speichert jeden Kommentar mit Timestamp und Verfasser. Die Daten sind über den Kommentarverlauf des Problems oder die API verfügbar.

Erfassung

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 die Bearbeitung des Vorfalls fortgesetzt werden kann. Das Ereignis wird abgeleitet, wenn der Status von „Waiting for customer“ zurück zu einem aktiven Status wechselt.
Warum das wichtig ist

Diese Aktivität markiert das Ende einer durch den Kunden verursachten Verzögerung. Die Dauer zwischen „Warten auf Kunden“ und diesem Ereignis zeigt die durchschnittliche Antwortzeit des Kunden.

Woher beziehen

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

Erfassung

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

Ereignistyp inferred
Mit Problem-Ticket verknüpft
Dieses Ereignis tritt ein, wenn ein Vorfall zur Ursachenanalyse mit einem Problem verknüpft wird. Es wird ausdrücklich erfasst, sobald eine Verknüpfung vom Typ „relates to“ oder „caused by“ zu einem Problem erstellt wird.
Warum das wichtig ist

Die Erfassung dieser Verknüpfung ist wichtig, um zu verstehen, wie gut das Unternehmen von der Eindämmung eines Vorfalls zur Ursachenanalyse und Prävention übergeht.

Woher beziehen

Dieses Ereignis wird ausdrücklich im Verknüpfungsverlauf des Problems protokolliert. Jede erstellte Verknüpfung hat einen Timestamp und kann nach Verknüpfungen mit dem Problemtyp „Problem“ gefiltert werden.

Erfassung

Verwenden Sie den Timestamp, zu dem eine Verknüpfung mit einem Problem erstellt wurde.

Ereignistyp explicit
Vorfall erneut geöffnet
Kennzeichnet einen zuvor gelösten Vorfall, der erneut bearbeitet wird, weil das Problem wieder aufgetreten oder die Lösung unwirksam war. Das Ereignis wird anhand eines Statuswechsels von „Resolved“ oder „Closed“ zurück zu einem offenen Status abgeleitet.
Warum das wichtig ist

Erneut geöffnete Vorfälle sind ein direkter Indikator für die Lösungsqualität und ein wichtiges Zeichen für Nacharbeit. Ihre Analyse hilft, verfrühte Abschlüsse und unwirksame Lösungen zu erkennen.

Woher beziehen

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

Erfassung

Ermitteln Sie einen Statuswechsel von „Resolved“ oder „Closed“ zu einem offenen Status.

Ereignistyp inferred
Vorfall priorisiert
Zeigt an, wann die Priorität und/oder der Schweregrad des Vorfalls festgelegt wird. Diese Einstufung bestimmt die Dringlichkeit und die geschäftlichen Auswirkungen. Üblicherweise wird das Ereignis anhand der ersten Befüllung oder Aktualisierung der Felder „Priority“ oder „Severity“ nach der Erstellung ermittelt.
Warum das wichtig ist

Die Erfassung der Priorisierung zeigt, ob Vorfälle zeitnah und einheitlich bewertet werden. Verzögerungen bei diesem Schritt können sich direkt auf SLA-Berechnungen und die Ressourcenverteilung auswirken.

Woher beziehen

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

Erfassung

Ermitteln Sie die erste Änderung am Feld „Priority“ im Problemverlauf.

Ereignistyp inferred
Vorfall zugewiesen
Diese Aktivität kennzeichnet die erstmalige Zuweisung des Vorfalls an eine Supportkraft oder Gruppe. Sie wird erfasst, sobald das Feld „Assignee“ oder „Assigned Group“ zum ersten Mal 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.

Woher beziehen

Das Ereignis wird aus dem Problemverlauf abgeleitet. Dazu wird die erste Änderung am Feld „Assignee“ ermittelt, bei der der vorherige Wert „Unassigned“ war.

Erfassung

Ermitteln Sie die erste Aktualisierung des Felds „Assignee“ im Problemverlauf.

Ereignistyp inferred
Workaround bereitgestellt
Kennzeichnet die Umsetzung einer vorübergehenden Lösung, mit der der Service wiederhergestellt wird, während eine dauerhafte Lösung entwickelt wird. Das Ereignis lässt sich anhand eines Statuswechsels oder eines bestimmten Kommentars ableiten.
Warum das wichtig ist

Die Zeit bis zur Bereitstellung eines Workarounds ist ein wichtiger Indikator dafür, wie schnell der Service wiederhergestellt wird. Sie hilft, vorübergehende Maßnahmen von dauerhaften Lösungen zu unterscheiden.

Woher beziehen

Dieses Ereignis wird häufig abgeleitet. Es kann sich um einen Wechsel zum Status „Workaround Provided“ oder um einen öffentlichen Kommentar mit bestimmten Schlüsselwörtern wie „workaround“ handeln.

Erfassung

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

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Jira Service Management

Möchten Sie loslegen?

Mit diesem Daten-Template können Sie Ihr Incident Management verbessern, Ineffizienzen aufdecken und Incidents schneller 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 Benutzer mit optimierten Prozessen.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich • Einrichtung in 5 Minuten