Ihr Daten-Template für das Incident Management
Ihr Daten-Template für das Incident Management
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Anleitung zur Datenextraktion aus Jira Service Management
Attribute für das Incident Management
| 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
|
|||
Aktivitäten im Incident Management
| 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
|
|||
Anleitungen zur Datenextraktion
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.
Keine Kreditkarte erforderlich • Einrichtung in 5 Minuten