Ihr Incident-Management Daten Template
Ihr Incident-Management Daten Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Anleitung zur Datenextraktion für Jira-Service-Management
Incident-Management-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
`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 eindeutige Kennung 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 vollständige Analyse des gesamten Prozesses zu ermöglichen.
Bedeutung
Dies ist die zentrale Kennung, die verwendet wird, um alle verknüpften Ereignisse zu einem einzigen Case zu korrelieren, was sie zur Grundlage für jede Process Mining-Analyse macht.
Datenquelle
Dies ist das Standard-'Key'-Feld für einen Issue in Jira-Service-Management (z.B. 'ITSM-123').
Beispiele
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Aktivität
ActivityName
|
Der Name des spezifischen Ereignisse oder den Antrag bearbeitet.er 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 in der Regel aus Statusübergängen oder spezifischen Aktualisierungsereignissen abgeleitet, die in der Historie oder den Antrag bearbeitet.em 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.
Bedeutung
Aktivitäten bilden das Basis der Prozessdarstellung und ermöglichen die Visualisierung und Analyse des Incident-Lebenszyklus.
Datenquelle
Abgeleitet aus der Jira-Issue-Historie und den Changelog-Daten, erfasst Statusübergänge und wichtige Feldaktualisierungen.
Beispiele
Incident zugewiesenErmittlung gestartetIncident gelöst
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut erfasst den Zeitstempel jeder Aktivität im Incident-Lebenszyklus. Es ist maßgeblich für die Berechnung von Dauern, Durchlaufzeits und Wartezeiten zwischen verschiedenen Prozessschritten. Präzise Zeitstempels ermöglichen eine detaillierte Leistungsfähigkeit-Analyse, SLA-Monitoring und die Identifizierung von Engpässe. Alle Leistungsfähigkeit-Metriken, wie Lösungszeit und Diagnosedauer, werden aus diesen Zeitstempels abgeleitet.
Bedeutung
Zeitstempels sind essenziell für die Berechnung aller zeitbasierten Metriken, das Verständnis der Prozessdauer und die Entdeckung von Leistungsfähigkeit-Engpässe.
Datenquelle
Dies ist das 'created' Datum, das mit jedem Eintrag im Changelog oder den Antrag bearbeitet.er 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 Zeitstempel, der den Antrag bearbeitet.en 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 analysierenn, 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 wichtig sind. Der Wert ist in der Regel derselbe für alle Ereignisse innerhalb eines einzelnen Datenextraktions-Batchs.
Bedeutung
Informiert Benutzer über die Aktualität der Daten, die wichtig für die Relevanz und Genauigkeit der Analyse ist.
Datenquelle
Dies ist der Zeitstempel 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 vollständige 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.
Bedeutung
Liefert wesentlichen Kontext zum Datenursprung und stellt ... sicher Klarheit und Nachvollziehbarkeit, insbesondere bei der Multi-System-Analyse.
Datenquelle
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 maßgeblich 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 Kundensupports zu beantworten.
Bedeutung
Hilft, die individuelle Arbeitslast zu verfolgen, Engpässe in Bezug auf bestimmte Agenten zu identifizieren und den Einfluss von Übergaben auf die Lösungszeit zu analysierenn.
Datenquelle
Das Standardfeld 'Bearbeiter' eines Jira-Issues.
Beispiele
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Bearbeitungsgruppe
AssignmentGroup
|
Das Team oder den Antrag bearbeitet.ie 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 maßgeblich, 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.
Bedeutung
Wesentlich für die Analyse der Teamleistung, des Durchsatzes und des Arbeitsflusses zwischen verschiedenen Support-Ebenen oder spezialisierten Gruppen.
Datenquelle
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-`Team`Datenbankadministratoren
|
|||
|
Datum der Behebung
ResolutionDate
|
Das Datum und die Uhrzeit, zu der den Antrag bearbeitet.er Incident als gelöst markiert wurde. | ||
|
Beschreibung
Dieses Attribut erfasst den Zeitstempel, zu dem der Incident erstmals in einen gelösten Status überführt wurde. Es markiert das Ende des Prozesses.kiert 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.
Bedeutung
Dies markiert das Ende des Lösungsprozesses und ermöglicht die Berechnung der Gesamtzykluszeit und der SLA-Leistungsfähigkeit.
Datenquelle
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 den Antrag bearbeitet.er Incident erstmals im System erstellt wurde. | ||
|
Beschreibung
Dieses Attribut markiert den offiziellen Beginn des Incident-Lebenszyklus. Es ist der Referenz-Zeitstempel, 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.
Bedeutung
Dient als Ausgangspunkt für alle End-to-End-Durchlaufzeitberechnungen und SLA-Messungen.
Datenquelle
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-Leistungsfähigkeit.
Bedeutung
Unerlässlich für die SLA-Leistungsanalyse und um zu überprüfen, ob die Ressourcen den kritischsten Vorfällen korrekt zugewiesen sind.
Datenquelle
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 die Basis für die Identifizierung von Engpässen und das Verständnis, wo Incidents die meiste Zeit verbringen.
Bedeutung
Spiegelt direkt den Fortschritt des Incidents wider und ist die primäre Quelle zur Identifizierung von Prozessschritten und Wartezeiten.
Datenquelle
Das Standardfeld 'Status' eines Jira-Issues.
Beispiele
In BearbeitungWarten auf KundenGelöstGeschlossen
|
|||
|
`Issue Typ`
IssueType
|
Die Art des Vorgangs, z. B. Incident, Service Request oder Problem. | ||
|
Beschreibung
Jira verwendet Issue Typs, 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 maßgeblich, um den Datensatz auf Incidents zu filtern und so sicherzustellen, dass die Process-Mining-Analyse auf den korrekten Prozess fokussiert ist.
Bedeutung
Stellt sicher, dass die Analyse korrekt auf Vorfälle ausgerichtet ist und diese von anderen Aufgabenarten wie Service-Requestnn oder Änderungen abgrenzt.
Datenquelle
Das Standardfeld 'Aufgabentyp' eines Jira-Issues.
Beispiele
VorfallIT-HilfeBug
|
|||
|
`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 Ja, 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-Leistungsfähigkeit-Monitoring-Dashboard.
Bedeutung
Bietet ein klares, binäres Ergebnis für die SLA-Leistungsfähigkeit, was die Berechnung von Verstoßraten und die Identifizierung von Problembereichen vereinfacht.
Datenquelle
Berechnet als ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Beispiele
JaNein
|
|||
|
Handoff-Anzahl
HandoffCount
|
Die Häufigkeit, mit der den Antrag bearbeitet.er 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 Übergaben 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.
Bedeutung
Quantifiziert Reibungsverluste und Ineffizienzen, die durch Neuzuweisungen entstehen, und hilft dabei, Möglichkeiten zur Prozessoptimierung zu identifizieren.
Datenquelle
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.
Bedeutung
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.
Datenquelle
Diese Informationen sind im Bereich 'Issue Links' eines Jira-Issues gespeichert.
Beispiele
PROB-123PROB-456Keine
|
|||
|
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.
Bedeutung
Hebt Prozessqualitätsmängel und Ineffizienzen hervor, indem Vorfälle markiert werden, die wiederholte Arbeit erfordern, und unterstützt so direkt die Nacharbeitsanalyse.
Datenquelle
Berechnet durch Erkennung spezifischer Statusübergangssequenzen im Event Log, wie 'Resolved' -> 'Reopened'.
Beispiele
JaNein
|
|||
|
Komponente
Component
|
Das System, die Anwendung oder den Antrag bearbeitet.er 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.
Bedeutung
Ermöglicht Filterung und Analyse basierend auf dem spezifisch betroffenen Produkt- oder Systembereich, um technologische Hotspots zu identifizieren.
Datenquelle
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 Typ' 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.
Bedeutung
Bietet eine kundenorientierte Ansicht der Incident-Kategorien, die nützlich für die Analyse der Nachfrage und die Verbesserung des Kundenerlebnisses ist.
Datenquelle
Das Feld 'Customer Request Typ', spezifisch für Jira-Service-Management-Projekte.
Beispiele
IT-Hilfe anfordern > Systemproblem meldenE-Mail > Zugriffsanfrage
|
|||
|
Lösung
Resolution
|
Das Endergebnis oder den Antrag bearbeitet.er 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', 'Duplizieren', '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 'Duplizieren'-Lösungen auf ein Problem in der Incident-Erstellungs- oder Triage-Phase hinweisen.
Bedeutung
Bietet Kontext zum Ergebnis eines Vorfalls und hilft so, Lösungen zu kategorisieren und Trends bei der Schließung von Vorfällen zu identifizieren.
Datenquelle
Das Standardfeld 'Lösung' eines Jira-Issues. Dieses Feld wird in der Regel gesetzt, wenn ein Issue in eine 'Erledigt'-Statuskategorie überführt wird.
Beispiele
ErledigtBehobenDuplikatWird nicht behoben
|
|||
|
Melder
Reporter
|
Der Benutzer, der den Antrag bearbeitet.en 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'.
Bedeutung
Hilft, Vorfallquellen zu analysierenn, Muster in Bezug auf bestimmte Benutzer oder Abteilungen zu identifizieren und Verzögerungen bei der Kundeninteraktion zu verstehen.
Datenquelle
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, Hinweisrmiert 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.
Bedeutung
Bietet eine Sicht auf den Geschäftseinfluss, die eine Analyse der für den Geschäftsbetrieb schädlichsten Incidents ermöglicht.
Datenquelle
Typischerweise ein Custom Field in Jira, da es kein Standard-Systemfeld ist. Konsultieren Sie die Jira-Service-Management-ProjektKonfiguration.
Beispiele
KritischSchwerwiegendGeringfügigTrivial
|
|||
|
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 in der Regel dynamisch basierend auf Regeln festgelegt, die Faktoren wie Priorität, Schweregrad oder Aufgabentyp berücksichtigen. Er ist die Basis für jedes SLA-Leistungsfähigkeit-Monitoring-Dashboard.
Bedeutung
Bietet den Benchmark für die Messung der SLA-Compliance und bildet die Grundlage für den Incident SLA Breach Rate KPI.
Datenquelle
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 'Benutzer Fehler'. Es wird in der Regel nach einer Untersuchung gefüllt und ist wichtig 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.
Bedeutung
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.
Datenquelle
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
KonfigurationsfehlerNetzwerkausfallSoftware-Bug
|
|||
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. | ||
|
Bedeutung
Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.as Ende der aktiven Arbeit des Supportteams markiert. Es ist oft das Event, das die SLA-Uhr stoppt.
Datenquelle
Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Zeitstempel ist der Zeitpunkt, zu dem der Status zu 'Resolved' oder einem äquivalenten Zustand übergeht.
Erfassen
Identifizieren Sie den Zeitstempel 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 in der Regel abgeleitet, wenn der Incident Issue Status von 'Open' oder 'New' zu 'In Progress' übergeht. | ||
|
Bedeutung
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.
Datenquelle
Abgeleitet aus der Statusänderungshistorie des Issues. Der Event-Zeitstempel ist der Zeitpunkt, zu dem der Status in einen Zustand übergeht, der aktive Arbeit darstellt, wie zum Beispiel 'In Progress'.
Erfassen
Identifizieren Sie den Zeitstempel 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. | ||
|
Bedeutung
Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity bis zur Resolution ist die Basis für die Messung der gesamten Durchlaufzeit und der SLA-Einhaltung.
Datenquelle
Dies ist ein explizites Event, das vom 'created' Zeitstempel des Incident-Issues in Jira erfasst wird. Das Issue-Creation-Event wird in der Historie des Issues protokolliert.
Erfassen
Verwenden Sie den Erstellungs-Zeitstempel 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. | ||
|
Bedeutung
Dies ist der primäre Erfolgs-Meilenstein im Prozess. Die Dauer bis zu diesem Punkt ist der häufigste KPI, der den Antrag bearbeitet.ie 'Time to Resolution' (TTR) darstellt.
Datenquelle
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 Zeitstempel 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. | ||
|
Bedeutung
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.
Datenquelle
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Zeitstempel, zu dem der Status in den finalen Zustand 'Closed' übergeht.
Erfassen
Identifizieren Sie den Zeitstempel 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. | ||
|
Bedeutung
Die Nachverfolgung von Reassignments ist maßgeblich für die Handoff-Analyse. Eine hohe Anzahl von Reassignments deutet oft auf Ineffizienzen im Prozess, Wissenslücken oder eine Neine anfängliche Zuweisung hin, was zu Lösungsverzögerungen führt.
Datenquelle
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 Kundensupport auf Informationen oder Aktionen des Kunden wartet. Dies wird durch einen Statusübergang zu einem dedizierten Wartestatus wie „Warten auf Kunde“ abgeleitet. | ||
|
Bedeutung
Die Isolierung dieser 'Wartezeit' ist maßgeblich für eine genaue SLA-Messung, da sie oft aus den Berechnungen der Lösungszeit ausgeschlossen wird. Sie hilft, Kundenantwortverzögerungen zu analysierenn.
Datenquelle
Abgeleitet aus der Statusänderungshistorie des Issues. Das Event entspricht dem Zeitstempel, zu dem sich der Status auf 'Waiting for customer' oder einen ähnlichen Zustand ändert.
Erfassen
Identifizieren Sie den Zeitstempel 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. | ||
|
Bedeutung
Hebt Vorfälle hervor, die spezialisiertes Wissen erfordern, und verfolgt den Fluss zwischen verschiedenen Support-Levels. Dies hilft, Engpässe innerhalb spezialisierter Teams zu identifizieren und Eskalationsmuster zu analysierenn.
Datenquelle
Abgeleitet aus der Issue-Historie durch Verfolgung von Änderungen an einem benutzerdefinierten Feld, das das zugewiesene Team repräsentiert, oder den Antrag bearbeitet.urch 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 den Antrag bearbeitet.ie Behebung ineffektiv war. Dies wird aus einer Statusänderung von 'Resolved' oder 'Closed' zurück zu einem offenen Status abgeleitet. | ||
|
Bedeutung
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.
Datenquelle
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. | ||
|
Bedeutung
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.
Datenquelle
Abgeleitet aus der Issue-Historie durch Identifizierung der ersten Änderung des Feldes 'Assignee', bei der den Antrag bearbeitet.er 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. | ||
|
Bedeutung
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.
Datenquelle
Dies ist ein explizites Event. Jira speichert jeden Kommentar mit einem Zeitstempel und Autor, verfügbar über die Kommentarhistorie des Issues oder den Antrag bearbeitet.ie API.
Erfassen
Verwenden Sie den Zeitstempel 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. | ||
|
Bedeutung
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.
Datenquelle
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. | ||
|
Bedeutung
Die Nachverfolgung dieses Links ist wichtig, um zu verstehen, wie effektiv die Organisation von der Incident-Minimierung zur Ursachenanalyse und Prävention übergeht.
Datenquelle
Dies ist ein explizites Event, das in der Link-Historie des Issues protokolliert wird. Jede Link-Creation hat einen Zeitstempel und kann nach Links zum 'Problem'-Issue-Typ gefiltert werden.
Erfassen
Verwenden Sie den Zeitstempel 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 in der Regel aus dem ersten Zeitpunkt abgeleitet, zu dem die Felder 'Priority' oder 'Severity' nach der Erstellung befüllt oder aktualisiert werden. | ||
|
Bedeutung
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.
Datenquelle
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. | ||
|
Bedeutung
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.
Datenquelle
Dies wird oft abgeleitet. Es könnte ein Übergang zu einem Status 'Workaround Provided' oder den Antrag bearbeitet.as 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
|
|||