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