Ihre Problem Management Datenvorlage
Jira Service ManagementIhre Problem Management Datenvorlage
- Empfohlene Attribute für eine tiefgehende Analyse
- Prozessmeilensteine, die in Ihrem Event Log erfasst werden müssen
- Technische Anleitung zur Datenextraktion
Problem Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Die spezifische Aktion oder Statusänderung, die für die Problemmeldung aufgetreten ist. | ||
|
Beschreibung
Dieses Attribut erfasst den Namen des Ereignisses oder Statusübergangs, der innerhalb des Problem Management Lebenszyklus auftritt. Beispiele sind 'Problem erfasst', 'Status auf Untersuchung geändert' oder 'Ursache identifiziert'. Es ist essenziell für die Abbildung des Prozessflusses und die Identifizierung der Schrittfolge zur Lösung eines Problems. Im Process Mining bilden diese Aktivitäten die Knoten der Prozesskarte.
Warum es wichtig ist
Definiert die Schritte in der
Woher erhalten
Jira
Beispiele
Problemmeldung erstelltErmittlung gestartet`Root Cause` identifiziertWorkaround aktualisiertProblemmeldung geschlossen
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, wann die Daten extrahiert oder zuletzt aktualisiert wurden. | ||
|
Beschreibung
Gibt an, wann der Es wird verwendet, um zu validieren, dass die Analyse den aktuellsten Status des Prozesses widerspiegelt und potenzielle
Warum es wichtig ist
Stellt die
Woher erhalten
ETL-Zeitstempel
Beispiele
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
Problemmeldung
ProblemKey
|
Der eindeutige Bezeichner, der der Problemmeldung in Jira Service Management zugewiesen ist. | ||
|
Beschreibung
Dieses Attribut dient als zentraler Case-Bezeichner für die Process Mining Analyse. Es repräsentiert den eindeutigen Schlüssel (z.B. PM-1001), der von Jira Service Management generiert wird, wenn eine neue Problemmeldung erstellt wird. Es wird verwendet, um alle zugehörigen Aktivitäten, Statusänderungen und Aktualisierungen zu einer einzigen End-to-End-Prozessinstanz zusammenzufassen. Die Analyse dieses Attributs ermöglicht die Visualisierung des gesamten Lebenszyklus eines Problems von der ersten Erkennung über die Untersuchung bis zum endgültigen Abschluss.
Warum es wichtig ist
Es ist der fundamentale
Woher erhalten
Issue
Beispiele
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
Quellsystem
SourceSystem
|
Der Name des Systems, aus dem die `data` stammen. | ||
|
Beschreibung
Identifiziert das Softwaresystem, aus dem die Dieses
Warum es wichtig ist
Bietet Kontext für die Datenherkunft, insbesondere beim Zusammenführen mit anderen IT Service Management Daten.
Woher erhalten
Hardcodiert oder Systemkonfiguration
Beispiele
`Jira Service Management``Jira Cloud`JSM-Prod
|
|||
|
Timestamp
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut zeichnet den genauen Zeitpunkt einer Aktivität auf. Es wird verwendet, um Events chronologisch zu sequenzieren und Dauern zwischen Schritten zu berechnen. Genaue Timestamps sind entscheidend für die Berechnung von Zykluszeiten, wie der Zeit von 'Problem erfasst' bis 'Ursache identifiziert', und für die Analyse des Durchsatzes über die Zeit.
Warum es wichtig ist
Ermöglicht die Berechnung aller zeitbasierten
Woher erhalten
Jira
Beispiele
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
Benutzer
UserKey
|
Der eindeutige Bezeichner oder Name des Benutzers, der die Aktivität durchgeführt hat. | ||
|
Beschreibung
Erfasst die Identität der Person oder des Systemkontos, die für die Ausführung der spezifischen Diese
Warum es wichtig ist
Entscheidend für die Analyse von Übergaben, Aufgabentrennung und
Woher erhalten
Jira 'author'-
Beispiele
j.smithsystem_automationm.doe
|
|||
|
Priorität
Priority
|
Das der Problemmeldung zugewiesene Kritikalitätsniveau. | ||
|
Beschreibung
Gibt die Dringlichkeit und den Die Analyse dieses
Warum es wichtig ist
Ermöglicht die Segmentierung der
Woher erhalten
Issue
Beispiele
HöchsteHochMittelNiedrig
|
|||
|
Problemzusammenfassung
ProblemSummary
|
Die Kurzbeschreibung oder der Titel der Problemmeldung. | ||
|
Beschreibung
Enthält die Titelzusammenfassung des Problem- Es ermöglicht die
Warum es wichtig ist
Bietet einen menschenlesbaren Kontext für den Case-Bezeichner.
Woher erhalten
Issue
Beispiele
Datenbankverbindungs-`timeout` in der Region EUE-Mail-`service latency spike`Auftragsbearbeitungswarteschlange steckt fest
|
|||
|
Ursachenkategorie
RootCauseCategory
|
Die Klassifizierung der zugrunde liegenden Ursache des Problems. | ||
|
Beschreibung
Kategorisiert den technischen oder Prozessfehler, der das Problem verursacht hat, wie z.B. 'Software Bug', 'Human Error' oder 'Hardware Failure'. Dies ist oft ein Dieses
Warum es wichtig ist
Schlüssel zur Identifizierung systemischer
Woher erhalten
Benutzerdefiniertes
Beispiele
Software-BugKonfigurationsfehlerKapazitätsproblemAnbieterproblem
|
|||
|
Zugewiesene Supportgruppe
SupportGroup
|
Das technische Team oder die Gruppe, die derzeit mit der Untersuchung des Problems beauftragt ist. | ||
|
Beschreibung
Identifiziert das spezifische Team, das für den Problem- Dieses
Warum es wichtig ist
Wichtig für organisatorisches
Woher erhalten
Issue
Beispiele
DatenbankverwaltungNetwork OpsApplication Support Level 2
|
|||
|
Anzahl verknüpfter Incidents
LinkedIncidentCount
|
Die Anzahl der Vorfälle, die mit dieser Problemmeldung verknüpft sind. | ||
|
Beschreibung
Eine Anzahl von Es wird im 'Incident to Problem Linkage Depth'
Warum es wichtig ist
Quantifiziert den geschäftlichen Einfluss basierend auf dem Vorfallsvolumen.
Woher erhalten
Anzahl der
Beispiele
011550
|
|||
|
Behebungscode
ResolutionCode
|
Der Code, der angibt, wie das Problem gelöst wurde. | ||
|
Beschreibung
Gibt das Endergebnis der Problemmeldung an, wie 'Behoben', 'Wird nicht behoben', 'Duplikat' oder 'Nicht reproduzierbar'. Dies wird verwendet, um erfolgreich gelöste Probleme von solchen zu filtern, die aus administrativen Gründen geschlossen wurden, wodurch sichergestellt wird, dass KPI-Berechnungen wie die 'Mittlere Zeit bis zur Ursache' korrekt sind.
Warum es wichtig ist
Unterscheidet zwischen effektiven Lösungen und administrativen Abschlüssen.
Woher erhalten
Issue
Beispiele
ErledigtWird nicht gemachtDuplikatNicht reproduzierbar
|
|||
|
Erkennungsquelle
DetectionSource
|
Wie das Problem identifiziert wurde (z.B. Proaktiv, Reaktiv). | ||
|
Beschreibung
Gibt den Ursprung der Problemidentifikation an. Häufige Dieses
Warum es wichtig ist
Misst die
Woher erhalten
Benutzerdefiniertes
Beispiele
Proaktives MonitoringIncident-EskalationLieferantenbenachrichtigung
|
|||
|
Erstellungsdatum
CreatedDate
|
Das Datum, an dem die Problemmeldung erstellt wurde. | ||
|
Beschreibung
Der Timestamp, wann das Problem erstmals im System erfasst wurde. Während der Event Timestamp das Timing von Aktivitäten handhabt, wird dieses spezifische Attribut oft für die Filterung auf hoher Ebene verwendet (z.B. 'Zeige mir alle im Q1 erstellten Probleme'). Es dient als Ankerpunkt für die Alterungsanalyse.
Warum es wichtig ist
Referenzdatum für Alters- und Erfassungsvolumenanalyse.
Woher erhalten
Issue
Beispiele
2023-01-012023-06-15
|
|||
|
Melder
ReporterName
|
Der Benutzer, der die Problemmeldung ursprünglich erfasst hat. | ||
|
Beschreibung
Identifiziert die Person, die den Problem- Dies fügt der 'Proactive vs Reactive'-Analyse
Warum es wichtig ist
Identifiziert die Quelle der Problemerfassung.
Woher erhalten
Issue
Beispiele
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
PIR durchgeführt
ReviewStatus
|
Gibt an, ob eine Post-Implementierungs-Überprüfung (`PIR`) durchgeführt wurde. | ||
|
Beschreibung
Verfolgt, ob die Aktivität oder das Kennzeichen 'Überprüfung nach der Implementierung' im Fall vorhanden ist. Dies ist entscheidend für das Dashboard 'Compliance der Überprüfung nach der Implementierung'. Es stellt sicher, dass die Organisation die Governance-Anforderungen für kontinuierliche Verbesserung einhält.
Warum es wichtig ist
Compliance-Metrik für organisatorisches Lernen.
Woher erhalten
Benutzerdefiniertes
Beispiele
AbgeschlossenPendingNicht erforderlich
|
|||
|
SLA-Verletzungsstatus
SlaBreachStatus
|
Gibt an, ob der Problem-`record` seine `service level agreement` verletzt hat. | ||
|
Beschreibung
Ein Es hebt
Warum es wichtig ist
Entscheidend für
Woher erhalten
Jira Service Management
Beispiele
ErfülltVerletztPausiert
|
|||
|
Untersuchungsdauer
InvestigationDuration
|
Benötigte Zeit von der Problemerfassung bis zur Ursachenidentifikation. | ||
|
Beschreibung
Berechnet die Dauer zwischen der Erstellung des Problem- Es hilft Managern, komplexe Probleme zu identifizieren, die das Team aufgehalten haben, oder einen
Warum es wichtig ist
Primäre Kennzahl für die Effizienz der Phase der Ursachenanalyse.
Woher erhalten
Berechnet aus
Beispiele
48 Stunden5 Tage30 Minuten
|
|||
|
Verknüpfter `Change Request`
LinkedChangeRequest
|
Der Bezeichner der Änderungsanfrage, die mit diesem Problem verknüpft ist. | ||
|
Beschreibung
Speichert die ID der Änderungsanfrage (RFC), die zur Implementierung der dauerhaften Lösung erstellt wurde. Diese Verknüpfung ist entscheidend für das Dashboard 'Verzögerung bei der Initiierung von Änderungsanfragen'. Sie verbindet den Problem Management Prozess mit dem Change Management und ermöglicht eine prozessübergreifende Analyse.
Warum es wichtig ist
Verbindet Untersuchung mit der Behebung im
Woher erhalten
Issue
Beispiele
CR-404CHG-1099CR-5512
|
|||
|
Wiedereröffnet
IsReopened
|
`Flag`, das anzeigt, ob das Problem nach dem Abschluss wiedereröffnet wurde. | ||
|
Beschreibung
Ein Hohe Wiedereröffnungsraten deuten auf Qualitätsprobleme bei den dauerhaften Lösungen oder unzureichende Verifizierungsverfahren hin.
Warum es wichtig ist
Qualitätsindikator für die Wirksamkeit von Lösungen.
Woher erhalten
Abgeleitet aus
Beispiele
truefalsch
|
|||
|
Workaround verfügbar
WorkaroundDetails
|
Gibt an, ob ein `workaround` für das Problem dokumentiert wurde. | ||
|
Beschreibung
Erfasst, ob ein temporärer Die Analyse dieses Feldes hilft zu bestimmen, wie schnell das Team die
Warum es wichtig ist
Schlüssel zur Messung der Geschwindigkeit der Interimshilfe für das
Woher erhalten
Benutzerdefiniertes
Beispiele
Dienst neu startenBrowser-Cache leerenKeine Angabe
|
|||
Problem Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
`Root Cause` identifiziert
|
Der Punkt, an dem die zugrunde liegende Ursache formell erfasst wird. Dies wird aus einer Statusänderung zu 'Ursache identifiziert' oder der Befüllung des Feldes 'Ursache' abgeleitet. | ||
|
Warum es wichtig ist
Ein wichtiger Meilenstein, der die Untersuchungsphase beendet. Unerlässlich für die Berechnung der 'Mean Time to Root Cause Discovery' (Mittlere Zeit bis zur Entdeckung der Grundursache).
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'Root Cause Identified' ODER
Erfassen
Statusfeld vergleichen oder auf Feldbefüllung prüfen
Ereignistyp
inferred
|
|||
|
Auflösung verifiziert
|
Die Bestätigung, dass die Lösung das Problem effektiv behoben hat. Abgeleitet aus einem Statusübergang zu 'Gelöst' oder einem spezifischen 'Verifiziert'-Status. | ||
|
Warum es wichtig ist
Qualitäts-Gate, das sicherstellt, dass die Lösung funktioniert. Verzögerungen hier deuten auf Engpässe im Test oder bei der Benutzerakzeptanz hin.
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'Resolved' oder 'Verified'
Erfassen
Statusfeld-
Ereignistyp
inferred
|
|||
|
Ermittlung gestartet
|
Der Übergang des Problemstatus in einen aktiven Untersuchungsstatus (z.B. 'In Untersuchung' oder 'In Bearbeitung'). Dies kennzeichnet den Beginn der aktiven Arbeitsphase. | ||
|
Warum es wichtig ist
Startet die Zeiterfassung für die Untersuchungszykluszeit. Hilft, zwischen Backlog-Wartezeit und tatsächlicher aktiver Analyse zu unterscheiden.
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'Under Investigation' oder 'In Progress'
Erfassen
Statusfeld-
Ereignistyp
inferred
|
|||
|
Incident mit Problem verknüpft
|
Die Aktion, ein zugehöriges Incident-Ticket mit der Problemmeldung zu verknüpfen. Dies wird in der Tabelle oder Historie der Ticket-Verknüpfungen erfasst. | ||
|
Warum es wichtig ist
Bestimmt den
Woher erhalten
Jira Issue
Erfassen
Protokolliert, wenn ein
Ereignistyp
explicit
|
|||
|
Problemmeldung erstellt
|
Das initiale Event, bei dem das Problem-Ticket im System erstellt wird. Dies wird in der Ticket-Historie explizit als Erstellungs-Timestamp erfasst. | ||
|
Warum es wichtig ist
Markiert den Beginn des Problem
Woher erhalten
Jira Issue
Erfassen
Protokolliert, wenn die
Ereignistyp
explicit
|
|||
|
Problemmeldung geschlossen
|
Die endgültige Beendigung des Problemlösungslebenszyklus. Explizit erfasst, wenn sich der Status in 'Geschlossen' ändert. | ||
|
Warum es wichtig ist
Das definitive Ende der Prozessinstanz. Notwendig zur Berechnung der gesamten Zykluszeit und Abschlussquoten.
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'Closed'
Erfassen
Protokolliert, wenn der Status auf
Ereignistyp
explicit
|
|||
|
Supportgruppe zugewiesen
|
Die Zuweisung der Problemmeldung an ein spezifisches technisches Team oder eine Support-Gruppe. Dies wird über Änderungen am benutzerdefinierten Feld 'Support Group' oder dem Feld 'Assignee' verfolgt, falls keine Gruppen verwendet werden. | ||
|
Warum es wichtig ist
Entscheidend für die Analyse von Übergaben und
Woher erhalten
Jira Issue Verlauf:
Erfassen
Protokolliert, wenn sich das
Ereignistyp
explicit
|
|||
|
Workaround aktualisiert
|
Die Befüllung oder Aktualisierung des Textfeldes 'Workaround'. Dieses Event zeigt an, dass eine temporäre Lösung dokumentiert wurde. | ||
|
Warum es wichtig ist
Misst die Geschwindigkeit, mit der dem
Woher erhalten
Jira Issue Verlauf:
Erfassen
Protokolliert, wenn das
Ereignistyp
explicit
|
|||
|
Change Request verknüpft
|
Die Verknüpfung einer Änderungsanfrage (RFC) mit der Problemmeldung. Dies kennzeichnet die Initiierung des Prozesses für eine dauerhafte Lösung. | ||
|
Warum es wichtig ist
Misst die Verzögerung zwischen der Identifizierung der Ursache und dem Beginn der Behebung. Unterstützt den 'Change Management Transition Delay'
Woher erhalten
Jira Issue
Erfassen
Protokolliert, wenn ein
Ereignistyp
explicit
|
|||
|
Dauerhafte Lösung angewendet
|
Der Übergang, der anzeigt, dass die Lösung implementiert wurde. Dies wird normalerweise aus einer Statusänderung zu 'Wird implementiert' oder 'Behoben' abgeleitet. | ||
|
Warum es wichtig ist
Markiert das Ende der technischen Behebungsarbeiten. Wird verwendet, um die Implementierungs-
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'Implemented', 'Pending Verification' oder 'Fixed'
Erfassen
Statusfeld-
Ereignistyp
inferred
|
|||
|
Problem wiedereröffnet
|
Der Übergang eines Problems von einem 'Gelöst'- oder 'Geschlossen'-Status zurück zu einem aktiven Status. Deutet auf eine fehlgeschlagene Behebung oder abgelehnte Lösung hin. | ||
|
Warum es wichtig ist
Eine wichtige Qualitätsmetrik. Hohe Wiedereröffnungsraten deuten auf eine ineffektive Grundursachenanalyse oder Tests hin.
Woher erhalten
Jira Issue Verlauf: Status geändert von 'Closed'/'Resolved' zu 'Open'/'In Progress'
Erfassen
Statusfeld-Sequenz vergleichen
Ereignistyp
inferred
|
|||
|
Problem-Priorität geändert
|
Eine Aktualisierung des `Priority field`s des Problem `record`s. Dies wird durch die Überwachung des `history tab`s auf Änderungen am Feld 'Priorität' erfasst. | ||
|
Warum es wichtig ist
Zeigt Eskalation oder Deeskalation des
Woher erhalten
Jira Issue Verlauf:
Erfassen
Protokolliert, wenn das
Ereignistyp
explicit
|
|||
|
SLA verletzt
|
Ein `event`, das anzeigt, dass die Problem-Lösungszeit die definierte `Service Level Agreement` überschritten hat. Dies wird durch den Vergleich des `SLA` `target date`s mit dem Lösungsdatum berechnet. | ||
|
Warum es wichtig ist
Entscheidend für
Woher erhalten
Jira Service Management
Erfassen
Ableiten aus
Ereignistyp
calculated
|
|||
|
Überprüfung nach der Implementierung
|
Die Durchführung einer Überprüfung, nachdem die Lösung angewendet wurde. Erfasst über eine Statusänderung zu 'In Überprüfung' oder Aktualisierungen PIR-spezifischer Felder. | ||
|
Warum es wichtig ist
Eine
Woher erhalten
Jira Issue Verlauf: Status geändert zu 'In Review' ODER
Erfassen
Statusfeld oder PIR-Feld-
Ereignistyp
inferred
|
|||