Datentemplate: Incident Management
Ihr Incident Management Data Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Anleitung zur Datenextraktion für Jira Service Management
Incident-Management-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name des spezifischen Events oder der Statusänderung, die für den Incident aufgetreten ist. | ||
|
Beschreibung
Die Aktivität stellt einen separaten Schritt oder ein Ereignis im Incident-Management-Lebenszyklus dar, wie z. B. 'Incident Erstellt', 'Incident Zugewiesen' oder 'Behebung Vorgeschlagen'. Diese werden typischerweise aus Statusübergängen oder spezifischen Aktualisierungsereignissen abgeleitet, die in der Historie oder dem Changelog des Jira-Issues erfasst sind. Die Analyse der Abfolge und Dauer dieser Aktivitäten ist das primäre Ziel des Process Mining, wobei der tatsächliche Prozessfluss, Engpässe und Abweichungen aufgedeckt werden.
Warum es wichtig ist
Aktivitäten bilden das Rückgrat der Prozesskarte und ermöglichen die Visualisierung und Analyse des Incident-Lebenszyklus.
Woher erhalten
Abgeleitet aus der Jira-Issue-Historie und den Changelog-Daten, erfasst Statusübergänge und wichtige Feldaktualisierungen.
Beispiele
Incident zugewiesenErmittlung gestartetIncident gelöst
|
|||
|
Incident-ID
IncidentId
|
Die eindeutige Kennung für jedes Incident-Ticket in Jira Service Management. | ||
|
Beschreibung
Die Incident-ID, oft als Issue Key in Jira bezeichnet, dient als primärer eindeutiger Identifikator für jeden gemeldeten Incident. Sie verknüpft alle zugehörigen Aktivitäten, Kommentare und Statusänderungen vom Zeitpunkt der Erstellung bis zum endgültigen Abschluss. Im Process Mining ist diese ID unerlässlich, um den End-to-End-Lebenszyklus jedes einzelnen Incidents zu rekonstruieren und eine umfassende Analyse des gesamten Prozesses zu ermöglichen.
Warum es wichtig ist
Dies ist die zentrale Kennung, die verwendet wird, um alle verknüpften Events zu einem einzigen Case zu korrelieren, was sie zur Grundlage für jede Process Mining-Analyse macht.
Woher erhalten
Dies ist das Standard-'Key'-Feld für einen Issue in Jira Service Management (z.B. 'ITSM-123').
Beispiele
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut erfasst den Timestamp jeder Activity im Incident-Lebenszyklus. Es ist entscheidend für die Berechnung von Dauern, Cycle Times und Wartezeiten zwischen verschiedenen Prozessschritten. Präzise Timestamps ermöglichen eine detaillierte Performance-Analyse, SLA-Monitoring und die Identifizierung von Bottlenecks. Alle Performance-Metriken, wie Lösungszeit und Diagnosedauer, werden aus diesen Timestamps abgeleitet.
Warum es wichtig ist
Timestamps sind essenziell für die Berechnung aller zeitbasierten Metriken, das Verständnis der Prozessdauer und die Entdeckung von Performance-Bottlenecks.
Woher erhalten
Dies ist das 'created' Datum, das mit jedem Eintrag im Changelog oder der Historie des Jira-Issues verknüpft ist.
Beispiele
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der den letzten Zeitpunkt angibt, zu dem die Daten aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst den Zeitpunkt der letzten Aktualisierung des Datensatzes. Es liefert wichtigen Kontext für alle, die den Prozess analysieren, und stellt sicher, dass sie über die Aktualität der Daten Bescheid wissen. Dies ist besonders wichtig für fortlaufende Monitoring-Dashboards, bei denen aktuelle Informationen für zeitnahe Entscheidungen entscheidend sind. Der Wert ist typischerweise derselbe für alle Events innerhalb eines einzelnen Datenextraktions-Batchs.
Warum es wichtig ist
Informiert Benutzer über die Aktualität der Daten, die entscheidend für die Relevanz und Genauigkeit der Analyse ist.
Woher erhalten
Dies ist der Timestamp des Datenextraktionslaufs, der während des Datentransformationsprozesses hinzugefügt wird.
Beispiele
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert die Datenherkunft, die in diesem Fall Jira Service Management ist. Es ist besonders nützlich in Umgebungen, in denen Daten aus mehreren Systemen für eine ganzheitliche Prozessansicht kombiniert werden. Die Angabe des Quellsystems stellt eine klare Datenherkunft sicher und hilft bei der Diagnose von Datenqualitäts- oder Extraktionsproblemen. Für dieses Modell wäre der Wert statisch.
Warum es wichtig ist
Liefert wesentlichen Kontext zum Datenursprung und gewährleistet Klarheit und Nachvollziehbarkeit, insbesondere bei der Multi-System-Analyse.
Woher erhalten
Dies ist ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt werden sollte.
Beispiele
Jira Service ManagementJira Cloud
|
|||
|
Assignee
Assignee
|
Der Benutzer, der aktuell für die Bearbeitung des Incidents zugewiesen ist. | ||
|
Beschreibung
Der Zuständige ist der einzelne Agent oder Nutzer, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Änderungen des Zuständigen zu verfolgen, ist entscheidend für die Analyse von Übergaben, das Verständnis der Arbeitslastverteilung und die Identifizierung, welche Personen an bestimmten Prozessschritten beteiligt sind. Dieses Attribut hilft, Fragen zur individuellen Leistung und Ressourcenzuweisung innerhalb der Support-Teams zu beantworten.
Warum es wichtig ist
Hilft, die individuelle Arbeitslast zu verfolgen, Bottlenecks in Bezug auf bestimmte Agenten zu identifizieren und den Einfluss von Handoffs auf die Lösungszeit zu analysieren.
Woher erhalten
Das Standardfeld 'Bearbeiter' eines Jira-Issues.
Beispiele
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Bearbeitungsgruppe
AssignmentGroup
|
Das Team oder die Gruppe, die für die Bearbeitung des Incidents zuständig ist. | ||
|
Beschreibung
Die Bearbeitungsgruppe repräsentiert das Team, das einem Incident zugewiesen ist. Dies kann eine Support-Ebene wie 'L1 Helpdesk', ein spezialisiertes Team wie 'Network Operations' oder ein Entwicklungsteam sein. Die Analyse von Übergängen zwischen Bearbeitungsgruppen ist entscheidend, um Prozesseskalationen und Übergaben zu verstehen. Sie ermöglicht die Messung der Teamleistung, die Identifizierung von Engpässen auf Teamebene und die Analyse von Abhängigkeiten zwischen Teams.
Warum es wichtig ist
Entscheidend für die Analyse der Teamleistung, des Durchsatzes und des Arbeitsflusses zwischen verschiedenen Support-Ebenen oder spezialisierten Gruppen.
Woher erhalten
Dies wird oft als Custom Field in Jira implementiert, wie z.B. 'Team' oder 'Assignment Group'. Es kann manchmal aus Jira-Components oder Project-Roles abgeleitet werden.
Beispiele
Tier 1 SupportInfrastruktur-TeamDatenbankadministratoren
|
|||
|
Bearbeitungszeit für die Behebung
IncidentResolutionCycleTime
|
Die Gesamtzeit, die von der Incident-Erstellung bis zur Lösung verstrichen ist. | ||
|
Beschreibung
Dies ist eine berechnete Metrik, die die Dauer vom 'CreatedDate' bis zum 'ResolutionDate' darstellt. Sie ist eine der wichtigsten KPIs im Incident Management und misst direkt die Effizienz des gesamten Prozesses. Die Analyse dieser Metrik über verschiedene Dimensionen wie Priorität, Zuweisungsgruppe oder Komponente hilft, die Faktoren zu identifizieren, die den größten Einfluss auf die Performance haben.
Warum es wichtig ist
Misst direkt die End-to-End-Effizienz des Incident Management Prozesses und ist ein primärer KPI für die Leistungsverfolgung.
Woher erhalten
Berechnet als ('ResolutionDate' - 'CreatedDate').
Beispiele
2h 30m1d 4h5d 1h 15m
|
|||
|
Datum der Behebung
ResolutionDate
|
Das Datum und die Uhrzeit, zu der der Incident als gelöst markiert wurde. | ||
|
Beschreibung
Dieses Attribut erfasst den Timestamp, zu dem der Incident erstmals in einen gelösten Status überführt wurde. Es markiert das Ende der aktiven Arbeitsphase und ist der Endpunkt für die Berechnung der Time to Resolution. Der Vergleich des Lösungsdatums mit dem Erstellungsdatum liefert das primäre Maß für die Prozesseffizienz. Es ist auch eine Schlüsselkomponente bei der Bestimmung der SLA-Compliance.
Warum es wichtig ist
Dies markiert das Ende des Lösungsprozesses und ermöglicht die Berechnung der Gesamtzykluszeit und der SLA-Performance.
Woher erhalten
Das Standardfeld 'Gelöst' eines Jira-Issues.
Beispiele
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Erstellungsdatum
CreatedDate
|
Das Datum und die Uhrzeit, zu der der Incident erstmals im System erstellt wurde. | ||
|
Beschreibung
Dieses Attribut markiert den offiziellen Beginn des Incident-Lebenszyklus. Es ist der Referenz-Timestamp, von dem aus Gesamtmetriken wie die Gesamtlösungszeit berechnet werden. Das Erstellungsdatum ist für jeden Incident ein statischer Wert und dient als Startpunkt für den gesamten Case in der Process Mining-Analyse.
Warum es wichtig ist
Dient als Ausgangspunkt für alle End-to-End-Durchlaufzeitberechnungen und SLA-Messungen.
Woher erhalten
Das Standardfeld 'Erstellt' eines Jira-Issues.
Beispiele
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe, die dem Incident zugewiesen wurde und die Dringlichkeit der Lösung angibt. | ||
|
Beschreibung
Die Priorität bestimmt die erforderliche Geschwindigkeit bei der Bearbeitung eines Incidents. Sie ist oft eine Kombination aus Auswirkung und Dringlichkeit und beeinflusst direkt die SLA-Ziele. Die Analyse von Incidents nach Priorität hilft zu verstehen, ob hochpriorisierte Incidents schneller als niedrigpriorisierte bearbeitet werden und ob die Priorisierung konsistent angewendet wird. Sie ist eine kritische Dimension für das Filtern und Vergleichen der Prozess-Performance.
Warum es wichtig ist
Unerlässlich für die SLA-Leistungsanalyse und um zu überprüfen, ob die Ressourcen den kritischsten Vorfällen korrekt zugewiesen sind.
Woher erhalten
Das Standardfeld 'Priorität' eines Jira-Issues.
Beispiele
HöchsteHochMittelNiedrig
|
|||
|
Status
Status
|
Der aktuelle Status des Incidents in seinem Lebenszyklus. | ||
|
Beschreibung
Das Statusfeld gibt den aktuellen Zustand eines Incidents innerhalb des definierten Workflows an, z. B. 'Open', 'In Progress', 'Pending Customer' oder 'Resolved'. Statusänderungen sind die primäre Quelle für die Generierung des Aktivitäten-Logs für das Process Mining. Die Analyse der Verweildauer in jedem Status ist grundlegend für die Identifizierung von Engpässen und das Verständnis, wo Incidents die meiste Zeit verbringen.
Warum es wichtig ist
Spiegelt direkt den Fortschritt des Incidents wider und ist die primäre Quelle zur Identifizierung von Prozessschritten und Wartezeiten.
Woher erhalten
Das Standardfeld 'Status' eines Jira-Issues.
Beispiele
In BearbeitungWarten auf KundenResolvedGeschlossen
|
|||
|
Behebung
Resolution
|
Das Endergebnis oder der Grund für die Lösung des Incidents. | ||
|
Beschreibung
Das Lösungsfeld erklärt, warum ein Incident in einen gelösten Status überführt wurde. Gängige Lösungen umfassen 'Fixed', 'Duplicate', 'Won't Do' oder 'Cannot Reproduce'. Die Analyse der Verteilung von Lösungstypen kann Einblicke in die Qualität eingehender Meldungen und die Effektivität des Lösungsprozesses geben. Zum Beispiel kann eine hohe Anzahl von 'Duplicate'-Lösungen auf ein Problem in der Incident-Erstellungs- oder Triage-Phase hinweisen.
Warum es wichtig ist
Bietet Kontext zum Ergebnis eines Vorfalls und hilft so, Lösungen zu kategorisieren und Trends bei der Schließung von Vorfällen zu identifizieren.
Woher erhalten
Das Standardfeld 'Lösung' eines Jira-Issues. Dieses Feld wird typischerweise gesetzt, wenn ein Issue in eine 'Erledigt'-Statuskategorie überführt wird.
Beispiele
ErledigtBehobenDuplikatWird nicht behoben
|
|||
|
Handoff-Anzahl
HandoffCount
|
Die Häufigkeit, mit der der Incident einer anderen Gruppe oder einem anderen Benutzer neu zugewiesen wurde. | ||
|
Beschreibung
Diese berechnete Metrik zählt die Anzahl der Änderungen des Feldes 'Assignee' oder 'AssignmentGroup' während des Incident-Lebenszyklus. Eine hohe Anzahl von Handoffs deutet oft auf Ineffizienzen im Prozess, mangelnde First-Call-Resolution oder Wissenslücken hin, was zu längeren Lösungszeiten führt. Die Analyse dieses KPIs hilft dabei, den Zuweisungsprozess zu optimieren und die Teamzusammenarbeit zu verbessern.
Warum es wichtig ist
Quantifiziert Reibungsverluste und Ineffizienzen, die durch Neuzuweisungen entstehen, und hilft dabei, Möglichkeiten zur Prozessverbesserung zu identifizieren.
Woher erhalten
Berechnet durch Zählen der Änderungen am Feld 'Bearbeiter' oder 'Bearbeitungsgruppe' im Issue-Changelog.
Beispiele
015
|
|||
|
ID des verknüpften Problems
LinkedProblemId
|
Die Kennung eines Problem-Tickets, das mit diesem Incident verknüpft ist. | ||
|
Beschreibung
Incidents, die Symptome eines größeren, zugrunde liegenden Problems sind, sind oft mit einem Problem-Ticket verknüpft. Dieses Feld speichert die ID dieses zugehörigen Problems. Die Analyse dieser Links hilft, die Beziehung zwischen Incidents und Problemen zu verstehen, die Effektivität des Problem-Management-Prozesses zu messen und wiederkehrende Incidents zu identifizieren, die eine dauerhafte Lösung erfordern.
Warum es wichtig ist
Verknüpft Incidents mit zugrunde liegenden Problemen und ermöglicht so die Analyse, wie effektiv die Organisation Ursachen adressiert, um zukünftige Incidents zu verhindern.
Woher erhalten
Diese Informationen sind im Bereich 'Issue Links' eines Jira-Issues gespeichert.
Beispiele
PROB-123PROB-456Keine
|
|||
|
Issue Type
IssueType
|
Die Art des Vorgangs, z. B. Incident, Service Request oder Problem. | ||
|
Beschreibung
Jira nutzt Issue Types, um verschiedene Aufgabenarten zu unterscheiden. Im Rahmen des Incident-Managements ist der primäre Typ 'Incident', jedoch könnten auch andere, wie 'Sub-task', relevant sein. Dieses Attribut ist entscheidend, um den Datensatz auf Incidents zu filtern und so sicherzustellen, dass die Process Mining Analyse auf den korrekten Prozess fokussiert ist.
Warum es wichtig ist
Stellt sicher, dass die Analyse korrekt auf Vorfälle ausgerichtet ist und diese von anderen Aufgabenarten wie Serviceanfragen oder Änderungen abgrenzt.
Woher erhalten
Das Standardfeld 'Aufgabentyp' eines Jira-Issues.
Beispiele
VorfallIT-HilfeBug
|
|||
|
Ist Nacharbeit
IsRework
|
Eine Kennzeichnung, ob der Incident überarbeitet wurde, z.B. durch eine Wiedereröffnung. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut identifiziert Incidents, die in einen früheren Prozessschritt zurückgeschickt wurden, meist durch die Wiedereröffnung, nachdem sie gelöst wurden. Rework Loops sind eine erhebliche Quelle für Ineffizienz und Kundenunzufriedenheit. Dieses Flag ermöglicht eine einfache Quantifizierung der Rework Rate und hilft, die Analyse darauf zu konzentrieren, warum Incidents nicht auf Anhieb korrekt gelöst werden.
Warum es wichtig ist
Hebt Prozessqualitätsmängel und Ineffizienzen hervor, indem Vorfälle markiert werden, die wiederholte Arbeit erfordern, und unterstützt so direkt die Nacharbeitsanalyse.
Woher erhalten
Berechnet durch Erkennung spezifischer Statusübergangssequenzen im Event Log, wie 'Resolved' -> 'Reopened'.
Beispiele
truefalsch
|
|||
|
Komponente
Component
|
Das System, die Anwendung oder der Teil der Infrastruktur, der vom Incident betroffen ist. | ||
|
Beschreibung
Komponenten sind Unterabschnitte eines Jira-Projekts, die zur Gruppierung von Issues in kleinere Einheiten verwendet werden, wie 'Benutzeroberfläche', 'Datenbank' oder 'API'. Die Analyse von Incidents nach Komponente hilft, jene Systemteile zu identifizieren, die am anfälligsten für Probleme sind. Diese Informationen sind wertvoll für die Ursachenanalyse und können Bemühungen zur Serviceverbesserung oder zur Reduzierung technischer Schulden leiten.
Warum es wichtig ist
Ermöglicht Filterung und Analyse basierend auf dem spezifisch betroffenen Produkt- oder Systembereich, um technologische Hotspots zu identifizieren.
Woher erhalten
Das Standardfeld 'Komponenten' eines Jira-Issues.
Beispiele
AuthentifizierungsdienstReporting DashboardMobile App
|
|||
|
Kundenanfragetyp
CustomerRequestType
|
Die spezifische Art der Anfrage, die vom Kunden über das Serviceportal eingereicht wurde. | ||
|
Beschreibung
Dieses Feld kategorisiert Anfragen aus Kundensicht, wie sie auf dem Jira Service Management-Portal präsentiert werden (z.B. 'Ein Systemproblem melden'). Es bietet eine benutzerfreundliche Klassifizierung des Incidents, die sich von der internen 'Issue Type' unterscheiden kann. Die Analyse dieses Attributs kann Einblicke geben, wie Kunden Probleme wahrnehmen und melden, was zur Verbesserung des Portal-Designs und der Serviceangebote beiträgt.
Warum es wichtig ist
Bietet eine kundenorientierte Ansicht der Incident-Kategorien, die nützlich für die Analyse der Nachfrage und die Verbesserung des Kundenerlebnisses ist.
Woher erhalten
Das Feld 'Customer Request Type', spezifisch für Jira Service Management-Projekte.
Beispiele
IT-Hilfe anfordern > Systemproblem meldenE-Mail > Zugriffsanfrage
|
|||
|
Melder
Reporter
|
Der Benutzer, der den Incident ursprünglich erstellt oder gemeldet hat. | ||
|
Beschreibung
Der Melder ist die Person, oft ein Endbenutzer oder ein anderes System, die den Incident zuerst gemeldet hat. Die Analyse von Incidents nach Melder kann helfen, Benutzer oder Abteilungen zu identifizieren, die häufig Probleme erleben. Sie kann auch verwendet werden, um Kommunikationsmuster zu verstehen, insbesondere bei der Analyse von Aktivitäten wie 'Waiting for Customer' und 'Customer Responded'.
Warum es wichtig ist
Hilft, Vorfallquellen zu analysieren, Muster in Bezug auf bestimmte Benutzer oder Abteilungen zu identifizieren und Verzögerungen bei der Kundeninteraktion zu verstehen.
Woher erhalten
Das Standardfeld 'Melder' eines Jira-Issues.
Beispiele
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Schweregrad
Severity
|
Das Maß der geschäftlichen Auswirkungen des Incidents. | ||
|
Beschreibung
Der Schweregrad definiert, welche Auswirkungen ein Incident auf das Geschäft hat, von einem einzelnen betroffenen Nutzer bis zu einem kritischen Systemausfall. Während die Priorität die Arbeitsreihenfolge bestimmt, informiert der Schweregrad über die gesamten geschäftlichen Auswirkungen. Die Analyse nach Schweregrad hilft, die Prozessleistung für Incidents zu verstehen, die für das Geschäft am wichtigsten sind, und wird oft in Kombination mit der Priorität für eine nuanciertere Analyse verwendet.
Warum es wichtig ist
Bietet eine Sicht auf den Geschäftseinfluss, die eine Analyse der für den Geschäftsbetrieb schädlichsten Incidents ermöglicht.
Woher erhalten
Typischerweise ein Custom Field in Jira, da es kein Standard-Systemfeld ist. Konsultieren Sie die Jira Service Management-Projektkonfiguration.
Beispiele
KritischSchwerwiegendGeringfügigTrivial
|
|||
|
SLA-Verstoß
SlaBreach
|
Eine Kennzeichnung, ob die Incident-Lösungszeit das SLA-Ziel überschritten hat. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut zeigt an, ob ein Incident sein 'Time to Resolution' SLA verletzt hat. Der Wert ist true, wenn die 'IncidentResolutionCycleTime' größer ist als der 'TimeToResolutionTarget'. Dieses Flag vereinfacht die Analyse und Visualisierung, ermöglicht einfaches Filtern und Aggregieren zur Berechnung des gesamten SLA Breach Rate KPI. Es ist die wichtigste Ergebnisgröße für das SLA-Performance-Monitoring-Dashboard.
Warum es wichtig ist
Bietet ein klares, binäres Ergebnis für die SLA-Performance, was die Berechnung von Verstoßraten und die Identifizierung von Problembereichen vereinfacht.
Woher erhalten
Berechnet als ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Beispiele
truefalsch
|
|||
|
TimeToResolutionTarget
TimeToResolutionTarget
|
Die SLA-Zieldauer für die Lösung des Incidents. | ||
|
Beschreibung
Dieses Attribut definiert die erwartete Maximalzeit, innerhalb der ein Incident einer bestimmten Priorität oder Art gelöst werden sollte. Es ist der Benchmark, an dem die tatsächliche Lösungszeit gemessen wird, um die SLA-Compliance zu bestimmen. Dieser Wert wird typischerweise dynamisch basierend auf Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Aufgabentyp berücksichtigen. Er ist grundlegend für jedes SLA-Performance-Monitoring-Dashboard.
Warum es wichtig ist
Bietet den Benchmark für die Messung der SLA-Compliance und bildet die Grundlage für den Incident SLA Breach Rate KPI.
Woher erhalten
Dies wird aus der SLA-Konfiguration innerhalb von Jira Service Management abgeleitet. Das spezifische Ziel (z.B. 'Time to resolution') muss identifiziert werden.
Beispiele
4h8h3d
|
|||
|
Ursachenkategorie
RootCauseCategory
|
Die Klassifizierung der zugrunde liegenden Grundursache des Incidents. | ||
|
Beschreibung
Dieses Attribut erfasst die grundlegende Ursache dafür, warum der Incident aufgetreten ist, wie z. B. 'Software Defect', 'Hardware Failure' oder 'User Error'. Es wird typischerweise nach einer Untersuchung gefüllt und ist essenziell für ein effektives Problemmanagement und die Prävention zukünftiger Incidents. Die Analyse von Grundursachenkategorien hilft, systemische Schwachstellen zu identifizieren und Verbesserungsinitiativen zu priorisieren. Eine hohe Rate an 'Unknown'-Grundursachen kann auf die Notwendigkeit besserer Untersuchungsprozesse hinweisen.
Warum es wichtig ist
Ermöglicht die Ursachenanalyse und fördert den Übergang von einem reaktiven zu einem proaktiven Ansatz, indem die Ursachen von Incidents identifiziert und behoben werden.
Woher erhalten
Dies ist fast immer ein Custom Field in Jira. Der Name und die Optionen hängen stark von der spezifischen Konfiguration der Organisation ab.
Beispiele
KonfigurationsfehlerNetzwerkausfallSoftwarefehler
|
|||
Incident-Management-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Behebung Vorgeschlagen
|
Diese Aktivität zeigt an, dass eine Lösung identifiziert und implementiert wurde und der Incident auf Bestätigung oder finale Validierung wartet. Sie wird aus dem Statusübergang zu 'Resolved' abgeleitet. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der das Ende der aktiven Arbeit des Supportteams markiert. Es ist oft das Event, das die SLA-Uhr stoppt.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Timestamp ist der Zeitpunkt, zu dem der Status zu 'Resolved' oder einem äquivalenten Zustand übergeht.
Erfassen
Identifizieren Sie den Timestamp des Statusübergangs zu 'Gelöst'.
Ereignistyp
inferred
|
|||
|
Ermittlung gestartet
|
Zeigt an, dass ein zugewiesener Bearbeiter aktiv mit der Diagnose des Incidents begonnen hat. Dies wird typischerweise abgeleitet, wenn der Incident Issue Status von 'Open' oder 'New' zu 'In Progress' übergeht. | ||
|
Warum es wichtig ist
Dieser wichtige Meilenstein markiert den Beginn aktiver Lösungsbemühungen. Die Messung der Zeit bis zu dieser Activity hilft, anfängliche Warteschlangenverzögerungen und Probleme mit der Ressourcenverfügbarkeit zu identifizieren.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Timestamp ist der Zeitpunkt, zu dem der Status in einen Zustand übergeht, der aktive Arbeit darstellt, wie zum Beispiel 'In Progress'.
Erfassen
Identifizieren Sie den Timestamp des Statusübergangs zu 'In Bearbeitung'.
Ereignistyp
inferred
|
|||
|
Incident erstellt
|
Dies kennzeichnet den offiziellen Start des Incident-Lebenszyklus, wenn ein Incident-Report eingereicht und ein neuer Vorgang in Jira erstellt wird. Dieses Event wird explizit erfasst, wenn ein neuer Vorgang vom Typ 'Incident' im System protokolliert wird. | ||
|
Warum es wichtig ist
Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Resolution ist grundlegend für die Messung der gesamten Cycle Time und der SLA-Einhaltung.
Woher erhalten
Dies ist ein explizites Event, das vom 'created' Timestamp des Incident-Issues in Jira erfasst wird. Das Issue-Creation-Event wird in der Historie des Issues protokolliert.
Erfassen
Verwenden Sie den Erstellungs-Timestamp des Issues.
Ereignistyp
explicit
|
|||
|
Incident gelöst
|
Diese Aktivität markiert die Bestätigung, dass der Incident erfolgreich gelöst und der Service wiederhergestellt ist. Sie fällt oft mit dem Übergang in den Status 'Resolved' zusammen. | ||
|
Warum es wichtig ist
Dies ist der primäre Erfolgs-Meilenstein im Prozess. Die Dauer bis zu diesem Punkt ist der häufigste KPI, der die 'Time to Resolution' (TTR) darstellt.
Woher erhalten
Abgeleitet aus der Statusänderung zu 'Resolved'. In vielen Workflows ist dies dasselbe Event wie 'Resolution Proposed', das den Hauptlösungspunkt darstellt.
Erfassen
Identifizieren Sie den Timestamp des Statusübergangs zu 'Gelöst'.
Ereignistyp
inferred
|
|||
|
Incident geschlossen
|
Stellt die endgültige, administrative Schließung des Incident-Tickets dar, nachdem es behoben und verifiziert wurde. Dies wird aus dem Statusübergang zu 'Closed' abgeleitet. | ||
|
Warum es wichtig ist
Dies ist das End-Event des Prozesses. Die Analyse der Zeit zwischen 'Resolved' und 'Closed' kann Verzögerungen bei administrativen Bereinigungen oder Benutzerbestätigungsprozessen aufzeigen.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Timestamp, zu dem der Status in den finalen Zustand 'Closed' übergeht.
Erfassen
Identifizieren Sie den Timestamp des Statusübergangs zu 'Geschlossen'.
Ereignistyp
inferred
|
|||
|
Incident neu zugewiesen
|
Tritt auf, wenn ein Incident nach der ersten Zuweisung von einem Agenten oder einer Gruppe an eine andere übertragen wird. Dieses Event wird aus jeder Änderung im Feld „Bearbeiter“ (Assignee) oder „Zuständige Gruppe“ (Assigned Group) abgeleitet. | ||
|
Warum es wichtig ist
Die Nachverfolgung von Reassignments ist entscheidend für die Handoff-Analyse. Eine hohe Anzahl von Reassignments deutet oft auf Ineffizienzen im Prozess, Wissenslücken oder eine falsche anfängliche Zuweisung hin, was zu Lösungsverzögerungen führt.
Woher erhalten
Abgeleitet aus der Issue-Historie durch Erkennung jeder Aktualisierung des Feldes 'Assignee', nachdem es zuerst befüllt wurde. Jede Änderung stellt ein Neu-Zuweisungs-Event dar.
Erfassen
Identifizieren Sie nachträgliche Änderungen am Feld Assignee nach der initialen Zuweisung.
Ereignistyp
inferred
|
|||
|
Warten Auf Kunden
|
Dies kennzeichnet einen Zeitpunkt, an dem das Support-Team auf Informationen oder Aktionen des Kunden wartet. Dies wird durch einen Statusübergang zu einem dedizierten Wartestatus wie „Warten auf Kunde“ abgeleitet. | ||
|
Warum es wichtig ist
Die Isolierung dieser 'Wartezeit' ist entscheidend für eine genaue SLA-Messung, da sie oft aus den Berechnungen der Lösungszeit ausgeschlossen wird. Sie hilft, Kundenantwortverzögerungen zu analysieren.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Timestamp, zu dem sich der Status auf 'Waiting for customer' oder einen ähnlichen Zustand ändert.
Erfassen
Identifizieren Sie den Timestamp des Statusübergangs zu 'Warten auf Kunden'.
Ereignistyp
inferred
|
|||
|
An Spezialistenteam eskaliert
|
Bedeutet, dass der Incident zur erweiterten Unterstützung an ein spezialisiertes Team (z. B. Tier 2, Entwicklung) eskaliert wurde. Dies wird aus einer Änderung in einem benutzerdefinierten Feld 'Support Team' oder einer spezifischen Neuzuweisung abgeleitet. | ||
|
Warum es wichtig ist
Hebt Vorfälle hervor, die spezialisiertes Wissen erfordern, und verfolgt den Fluss zwischen verschiedenen Support-Levels. Dies hilft, Bottlenecks innerhalb spezialisierter Teams zu identifizieren und Eskalationsmuster zu analysieren.
Woher erhalten
Abgeleitet aus der Issue-Historie durch Verfolgung von Änderungen an einem benutzerdefinierten Feld, das das zugewiesene Team repräsentiert, oder durch Identifizierung einer 'Assignee'-Änderung zu einem Mitglied einer bekannten Spezialistengruppe.
Erfassen
Erkennt eine Änderung in einem benutzerdefinierten Feld für 'Zugewiesenes Team' oder spezifische Bearbeiteränderungen.
Ereignistyp
inferred
|
|||
|
Incident wiedereröffnet
|
Stellt eine Situation dar, in der ein zuvor behobener Incident reaktiviert wird, weil das Problem erneut aufgetreten oder die Behebung ineffektiv war. Dies wird aus einer Statusänderung von 'Resolved' oder 'Closed' zurück zu einem offenen Status abgeleitet. | ||
|
Warum es wichtig ist
Wiedereröffnete Incidents sind ein direktes Maß für die Lösungsqualität und ein Hauptindikator für Nacharbeit. Die Analyse dieser Ereignisse hilft, verfrühte Abschlüsse und ineffektive Lösungen zu identifizieren.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event wird protokolliert, wenn der Status von einem finalen Zustand wie 'Resolved' oder 'Closed' zurück zu 'Open' oder 'In Progress' wechselt.
Erfassen
Erkennt einen Statuswechsel von 'Resolved' oder 'Closed' zu einem offenen Status.
Ereignistyp
inferred
|
|||
|
Incident zugewiesen
|
Diese Aktivität kennzeichnet die Erstzuweisung des Incidents an einen Support-Mitarbeiter oder eine Gruppe zur Bearbeitung. Sie wird erfasst, indem der erste Zeitpunkt verfolgt wird, an dem das Feld 'Assignee' oder 'Assigned Group' gefüllt wird. | ||
|
Warum es wichtig ist
Misst die anfängliche Reaktions- und Zuweisungszeit, die eine Schlüsselkomponente der SLA-Metriken ist. Es hilft, Verzögerungen zu erkennen, bevor die aktive Untersuchung beginnt.
Woher erhalten
Abgeleitet aus der Issue-Historie durch Identifizierung der ersten Änderung des Feldes 'Assignee', bei der der vorherige Wert 'Unassigned' war.
Erfassen
Erkennt die erste Aktualisierung des Feldes 'Bearbeiter' in der Issue-Historie.
Ereignistyp
inferred
|
|||
|
Kommentar hinzugefügt
|
Stellt jedes Kommunikations- oder Notizereignis dar, bei dem ein Nutzer einen Kommentar zum Incident-Ticket hinzufügt. Dies ist ein explizites Ereignis, das jedes Mal erfasst wird, wenn ein Kommentar veröffentlicht wird. | ||
|
Warum es wichtig ist
Die Analyse der Kommentarhäufigkeit liefert Einblicke in Kommunikationsmuster, die Effizienz der Zusammenarbeit und die Komplexität eines Incidents. Sie kann Incidents hervorheben, die übermäßige Kommunikation erfordern.
Woher erhalten
Dies ist ein explizites Event. Jira speichert jeden Kommentar mit einem Timestamp und Autor, verfügbar über die Kommentarhistorie des Issues oder die API.
Erfassen
Verwenden Sie den Timestamp jedes zum Issue hinzugefügten Kommentars.
Ereignistyp
explicit
|
|||
|
Kunde hat geantwortet
|
Zeigt an, dass der Kunde die angefragten Informationen bereitgestellt hat und der Incident fortgesetzt werden kann. Dies wird abgeleitet, wenn der Status von 'Waiting for customer' wieder in einen aktiven Status übergeht. | ||
|
Warum es wichtig ist
Diese Aktivität markiert das Ende einer kundeninduzierten Verzögerung. Die Analyse der Dauer zwischen 'Waiting For Customer' und diesem Event zeigt die durchschnittliche Kundenreaktionszeit.
Woher erhalten
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event tritt auf, wenn der Status von 'Waiting for customer' zu einem Status wie 'In Progress' übergeht, oft ausgelöst durch das Hinzufügen eines Kommentars durch den Kunden.
Erfassen
Erkennt einen Statuswechsel von 'Wartet auf Kunde' zu 'In Bearbeitung'.
Ereignistyp
inferred
|
|||
|
Mit Problem-Ticket verknüpft
|
Tritt auf, wenn ein Incident mit einem Problem-Vorgang zur Ursachenanalyse verknüpft wird. Dies ist ein explizites Event, das erfasst wird, wenn eine „bezieht sich auf“- oder „verursacht durch“-Verknüpfung zu einem Problem-Vorgangstyp erstellt wird. | ||
|
Warum es wichtig ist
Die Nachverfolgung dieses Links ist essenziell, um zu verstehen, wie effektiv die Organisation von der Incident-Minimierung zur Root Cause Analysis und Prävention übergeht.
Woher erhalten
Dies ist ein explizites Event, das in der Link-Historie des Issues protokolliert wird. Jede Link-Creation hat einen Timestamp und kann nach Links zum 'Problem'-Issue-Type gefiltert werden.
Erfassen
Verwenden Sie den Timestamp der Erstellung einer Issue-Verknüpfung zu einem Issue-Typ 'Problem'.
Ereignistyp
explicit
|
|||
|
Vorfall priorisiert
|
Stellt die Festlegung der Priorität und/oder Schwere des Incidents dar, die dessen Dringlichkeit und geschäftliche Auswirkungen bestimmt. Dies wird typischerweise aus dem ersten Zeitpunkt abgeleitet, zu dem die Felder 'Priority' oder 'Severity' nach der Erstellung befüllt oder aktualisiert werden. | ||
|
Warum es wichtig ist
Die Nachverfolgung der Priorisierung hilft bei der Analyse, ob Incidents zeitnah und konsistent bewertet werden. Verzögerungen in diesem Schritt können sich direkt auf SLA-Berechnungen und die Ressourcenallokation auswirken.
Woher erhalten
Abgeleitet aus dem Issue-Historien-Log, das Änderungen an allen Feldern verfolgt. Suchen Sie nach der ersten Aktualisierung des Feldes 'Priority' oder eines Custom-Severity-Feldes nach dem Issue-Erstellungs-Event.
Erfassen
Erkennt die erste Änderung des Feldes 'Priorität' in der Issue-Historie.
Ereignistyp
inferred
|
|||
|
Workaround bereitgestellt
|
Stellt die Implementierung einer temporären Lösung dar, um den Dienst wiederherzustellen, während eine dauerhafte Lösung entwickelt wird. Dies kann aus einer Statusänderung oder einem spezifischen Kommentar abgeleitet werden. | ||
|
Warum es wichtig ist
Die Messung der Zeit bis zur Bereitstellung eines Workarounds ist ein Schlüsselindikator für die Geschwindigkeit der Service-Wiederherstellung. Sie hilft, zwischen einer temporären Entschärfung und einer permanenten Lösung zu unterscheiden.
Woher erhalten
Dies wird oft abgeleitet. Es könnte ein Übergang zu einem Status 'Workaround Provided' oder das Hinzufügen eines öffentlichen Kommentars sein, der spezifische Schlüsselwörter wie 'Workaround' enthält.
Erfassen
Identifizieren Sie einen spezifischen Statusübergang oder ein Keyword in einem Kommentar.
Ereignistyp
inferred
|
|||