> Kontinuierliche Prozessverbesserung > Problemmanagement > Jira Service Management > Daten Template

Ihr Daten-Template für Problem Management

Jira Service Management

Attribute des Problemmanagements (20) Aktivitäten des Problemmanagements (14) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für Problem Management

Dieses Template dient als umfassender Leitfaden für die Analyse Ihrer IT-Service-Management-Workflows. Es zeigt die wesentlichen Datenpunkte und Prozessmeilensteine in Jira Service Management. Die strukturierte Übersicht umfasst die Attribute und Aktivitäten, die Sie benötigen, um den Umgang Ihres Teams mit zugrunde liegenden Problemen und der Ursachenanalyse vollständig nachzuvollziehen. Verwenden Sie diese Leitlinien, um Ihre Datenerfassung zu vereinfachen und sicherzustellen, dass Ihre Process-Mining-Initiativen zu konkreten Erkenntnissen führen.

Empfohlene Attribute für eine detaillierte Analyse
Prozessmeilensteine, die Sie in Ihrem Event Log erfassen sollten
Technische Hinweise zur Datenextraktion

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des Problemmanagements

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um den Lebenszyklus Ihres Problemmanagements umfassend zu analysieren.

5 Erforderlich 5 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die konkrete Aktion oder Statusänderung, die für den Problem Record eingetreten ist.
Beschreibung Dieses Attribut erfasst den Namen des Events oder Statusübergangs innerhalb des Lebenszyklus im Problem Management. Beispiele sind „Problem Logged“, „Status Changed to Investigating“ oder „Root Cause Identified“. Es ist entscheidend für die Zuordnung des Prozessablaufs und die Ermittlung der Reihenfolge der Schritte zur Lösung eines Problems. Im Process Mining bilden diese Aktivitäten die Knoten der Prozessdarstellung. Warum das wichtig ist Definiert die Schritte in der Prozessdarstellung und ermöglicht die Analyse von Prozessvarianten. Bezugsquelle Jira Changelog (History) oder Statusübergänge des Issues Beispiele Problem Record erstelltUntersuchung gestartetUrsache identifiziertWorkaround aktualisiertProblem Record geschlossen
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten extrahiert oder zuletzt aktualisiert wurden.
Beschreibung Zeigt an, wann der Datensatz zuletzt mit der aktiven Jira-Service-Management-Umgebung synchronisiert wurde. So können Analysten die Aktualität der Daten einschätzen. Das Attribut dient dazu zu prüfen, ob die Analyse den aktuellen Prozesszustand abbildet, und mögliche Verzögerungen bei der Datenübertragung zu erkennen. Warum das wichtig ist Stellt die Aktualität der Daten sicher und stärkt das Vertrauen in die Analyseergebnisse. Bezugsquelle ETL-Timestamp Beispiele 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Problemdatensatz ProblemKey	Die eindeutige Kennung, die dem Problem Record in Jira Service Management zugewiesen wird.
Beschreibung Dieses Attribut dient als zentrale Case-Kennung für die Process-Mining-Analyse. Es stellt den eindeutigen Schlüssel dar, etwa PM-1001, den Jira Service Management beim Erstellen eines neuen Problem Records generiert. Damit werden alle zugehörigen Aktivitäten, Statusänderungen und Aktualisierungen zu einer einzigen End-to-End-Prozessinstanz zusammengefasst. Die Analyse dieses Attributs ermöglicht die Visualisierung des vollständigen Lebenszyklus eines Problems, von der ersten Erkennung über die Untersuchung bis zum endgültigen Abschluss. Warum das wichtig ist Es ist der grundlegende Schlüssel, der für die Rekonstruktion des Prozessablaufs und die Nachverfolgung einzelner Problem Records erforderlich ist. Bezugsquelle Issue-Tabelle, Feld „Key“ oder „Issue Key“ Beispiele PM-1023PM-4099PRB-3321PM-5001
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Identifiziert das Softwaresystem, aus dem die Prozessdaten extrahiert wurden. In diesem Kontext lautet der Wert durchgehend „Jira Service Management“. Dieses Attribut ist besonders in Umgebungen mit mehreren Systemen hilfreich, um Datenquellen zu unterscheiden. In dieser spezifischen Ansicht dient es jedoch hauptsächlich als statische Kennung für die Datenherkunft. Warum das wichtig ist Liefert Kontext zur Datenherkunft, insbesondere bei der Zusammenführung mit weiteren IT-Service-Management-Daten. Bezugsquelle Fest codiert oder Systemkonfiguration Beispiele Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den exakten Zeitpunkt einer Aktivität. Es dient dazu, Events chronologisch zu ordnen und die Dauer zwischen einzelnen Schritten zu berechnen. Genaue Timestamps sind entscheidend für die Berechnung von Durchlaufzeiten, etwa von „Problem Logged“ bis „Root Cause Identified“, sowie für die Analyse des Durchsatzes im Zeitverlauf. Warum das wichtig ist Ermöglicht die Berechnung aller zeitbasierten KPIs und die korrekte Reihenfolge der Events. Bezugsquelle Erstellungsdatum des Jira Changelog oder Erstellungsdatum des Issues Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Benutzer UserKey	Die eindeutige Kennung oder der Name des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Erfasst die Identität der Person oder des Systemkontos, die beziehungsweise das für die Ausführung der jeweiligen Aktivität verantwortlich ist. Dabei kann es sich um den „Assignee“ handeln, der den Record aktualisiert, oder um den „Author“ einer Statusänderung. Diese Daten dienen dazu, die Ressourcennutzung zu analysieren, Übergabeengpässe zwischen Benutzern zu erkennen und die Verantwortlichkeit im Problem-Management-Prozess sicherzustellen. Warum das wichtig ist Entscheidend für die Analyse von Übergaben, Funktionstrennung und Ressourcenauslastung. Bezugsquelle Jira-Feld „author“ im Changelog oder Feld „assignee“ beim Vorgang Beispiele j.smithsystem_automationm.doe
	Kategorie der Grundursache RootCauseCategory	Die Klassifizierung der zugrunde liegenden Ursache des Problems.
Beschreibung Kategorisiert den technischen oder prozessualen Fehler, der das Problem verursacht hat, etwa „Software Bug“, „Human Error“ oder „Hardware Failure“. In Jira Service Management handelt es sich dabei häufig um ein benutzerdefiniertes Feld. Dieses Attribut unterstützt das Dashboard „Verteilung der Grundursachenkategorien“. Dadurch können Sie strategische Entscheidungen darüber treffen, in welche Infrastruktur oder Schulungen investiert werden sollte, um ein erneutes Auftreten zu verhindern. Warum das wichtig ist Wichtig, um systemische Probleme zu erkennen und vorbeugende Maßnahmen abzuleiten. Bezugsquelle Benutzerdefiniertes Feld „Root Cause“ oder „Root Cause Category“ Beispiele SoftwarefehlerKonfigurationsfehlerKapazitätsproblemLieferantenproblem
	Priorität Priority	Die dem Problemdatensatz zugewiesene Kritikalitätsstufe.
Beschreibung Gibt die Dringlichkeit und Auswirkung des Problems an, typischerweise von „Low“ bis „Critical“. Dieses Feld dient dazu, die Analyse zu segmentieren und sicherzustellen, dass Probleme mit hoher Priorität innerhalb der SLA-Ziele gelöst werden. Die Analyse dieses Attributs unterstützt das Dashboard „SLA-Konformität und Zieltrends“ dabei zu prüfen, ob kritische Geschäftsrisiken angemessen priorisiert werden. Warum das wichtig ist Ermöglicht die Segmentierung der Prozessleistung nach geschäftlicher Kritikalität. Bezugsquelle Vorgangsfeld „Priority“ Beispiele HöchsteHochMittelNiedrig
	Problemzusammenfassung ProblemSummary	Die kurze Beschreibung oder der Titel des Problemdatensatzes.
Beschreibung Enthält die zusammenfassende Überschrift des Problemdatensatzes. Obwohl es sich hauptsächlich um Text handelt, liefert dieses Attribut Analysten Kontext bei der Prüfung einzelner Cases im Process-Mining-Tool. Es ermöglicht die Stichwortsuche und eine qualitative Analyse der erfassten Problemarten. Warum das wichtig ist Liefert einen verständlichen Kontext zur Case-ID. Bezugsquelle Vorgangsfeld „Summary“ Beispiele Zeitüberschreitung der Datenbankverbindung in der Region EUSpitze bei der Latenz des E-Mail-DienstesWarteschlange der Auftragsverarbeitung blockiert
	Zugewiesene Supportgruppe SupportGroup	Das technische Team oder die Gruppe, die derzeit mit der Untersuchung des Problems betraut ist.
Beschreibung Identifiziert das Team, das zum Zeitpunkt des Ereignisses für den Problemdatensatz verantwortlich ist. In Jira Service Management wird dieses Attribut häufig dem Feld „Component“ oder einem benutzerdefinierten Feld wie „Support Group“ zugeordnet. Dieses Attribut ist für das Dashboard „Engpässe bei Übergaben zwischen Supportgruppen“ entscheidend. Es ermöglicht Analysten, nachzuvollziehen, wie Probleme zwischen Teams weitergegeben werden und wo sie am längsten liegen bleiben. Warum das wichtig ist Unverzichtbar für die Analyse der Organisationsstruktur und die Identifizierung teamübergreifender Reibungsverluste. Bezugsquelle Vorgangsfeld „Component“ oder benutzerdefiniertes Feld „Support Group“ Beispiele DatenbankadministrationNetzwerkbetriebAnwendungs-Support, Ebene 2
	Anzahl verknüpfter Incidents LinkedIncidentCount	Die Anzahl der mit diesem Problemdatensatz verknüpften Incidents.
Beschreibung Zählt die Incident-Tickets, die dem Problemdatensatz zugeordnet sind. Dieses Attribut quantifiziert die Auswirkungen des Problems auf die Benutzerbasis. Es wird im KPI „Tiefe der Verknüpfung von Incident und Problem“ verwendet, um Probleme zu priorisieren, die das höchste Volumen an Support-Tickets verursachen. Warum das wichtig ist Quantifiziert die geschäftlichen Auswirkungen anhand des Incident-Volumens. Bezugsquelle Anzahl der Verknüpfungen in der Tabelle „issuelinks“, deren Typ „Problem/Incident“ lautet Beispiele 011550
	Erkennungsquelle DetectionSource	Wie das Problem identifiziert wurde, zum Beispiel proaktiv oder reaktiv.
Beschreibung Gibt an, woher die Identifizierung des Problems stammt. Häufige Werte sind „Proactive Monitoring“, „Service Desk Incident“ oder „Vendor Notification“. Dieses Attribut wird im Dashboard „Proaktive und reaktive Identifizierung“ verwendet, um den Reifegrad des Problem-Management-Prozesses zu messen. Warum das wichtig ist Misst den Prozessreifegrad und die Wirksamkeit der Überwachungssysteme. Bezugsquelle Benutzerdefiniertes Feld „Source“ oder „Detection Source“ Beispiele Proaktive ÜberwachungIncident-EskalationLieferantenbenachrichtigung
	Erneut geöffnet IsReopened	Kennzeichen dafür, ob das Problem nach dem Schließen erneut geöffnet wurde.
Beschreibung Ein boolesches Kennzeichen, das auf „true“ gesetzt wird, wenn der Problemdatensatz von einem geschlossenen in einen offenen Status zurückgewechselt ist. Dieses Attribut unterstützt die „Analyse der Wiedereröffnungsrate von Problemen“. Hohe Wiedereröffnungsraten weisen auf Qualitätsprobleme bei dauerhaften Lösungen oder unzureichende Prüfverfahren hin. Warum das wichtig ist Qualitätsindikator für die Wirksamkeit von Fehlerbehebungen. Bezugsquelle Abgeleitet aus Statusübergängen Beispiele truefalse
	Erstellungsdatum CreatedDate	Das Datum, an dem der Problemdatensatz erstellt wurde.
Beschreibung Der Timestamp, zu dem das Problem erstmals im System erfasst wurde. Während der Ereignis-Timestamp den Zeitpunkt einer Aktivität abbildet, wird dieses spezifische Attribut häufig für übergeordnete Filter verwendet, etwa „Alle im ersten Quartal erstellten Probleme anzeigen“. Es dient als Ausgangspunkt für die Altersanalyse. Warum das wichtig ist Ausgangsdatum für die Analyse des Alters und des Eingangsvolumens. Bezugsquelle Vorgangsfeld „Created“ Beispiele 2023-01-012023-06-15
	Lösungscode ResolutionCode	Der Code, der angibt, wie das Problem gelöst wurde.
Beschreibung Gibt das endgültige Ergebnis des Problemdatensatzes an, etwa „Fixed“, „Won't Fix“, „Duplicate“ oder „Cannot Reproduce“. Dieses Attribut dient dazu, erfolgreich gelöste Probleme von Fällen zu unterscheiden, die aus administrativen Gründen geschlossen wurden. So bleiben KPI-Berechnungen wie „Durchschnittliche Zeit bis zur Grundursache“ aussagekräftig. Warum das wichtig ist Unterscheidet zwischen wirksamen Fehlerbehebungen und administrativen Schließungen. Bezugsquelle Vorgangsfeld „Resolution“ Beispiele ErledigtWird nicht umgesetztDuplikatNicht reproduzierbar
	Meldende Person ReporterName	Der Benutzer, der den Problemdatensatz ursprünglich erfasst hat.
Beschreibung Identifiziert die Person, die den Problemdatensatz erstellt hat. Sie unterscheidet sich von der zugewiesenen Person. Die Analyse der meldenden Personen zeigt, wo Probleme erkannt werden, etwa durch Service-Desk-Mitarbeiter oder Systemadministratoren. Dies liefert zusätzlichen Kontext für die Analyse „Proaktiv und reaktiv“. Warum das wichtig ist Identifiziert die Quelle des Problemzugangs. Bezugsquelle Vorgangsfeld „Reporter“ Beispiele monitoring_servicehelpdesk_leadnetwork_admin
	PIR durchgeführt ReviewStatus	Gibt an, ob ein Post Implementation Review (PIR) durchgeführt wurde.
Beschreibung Verfolgt, ob die Aktivität oder das Kennzeichen „Post Implementation Review“ beim Case vorhanden ist. Dieses Attribut ist für das Dashboard „Compliance bei Post Implementation Reviews“ unverzichtbar. Es stellt sicher, dass die Organisation die Governance-Anforderungen für kontinuierliche Verbesserung einhält. Warum das wichtig ist Compliance-Kennzahl für organisatorisches Lernen. Bezugsquelle Benutzerdefiniertes Feld „PIR Status“ oder Vorhandensein der Aktivität „PIR“ Beispiele AbgeschlossenAusstehendNicht erforderlich
	SLA-Verletzungsstatus SlaBreachStatus	Gibt an, ob der Problemdatensatz seine Service-Level-Vereinbarung verletzt hat.
Beschreibung Ein boolesches Feld oder Statusfeld, das angibt, ob die Lösungszeit das vereinbarte Ziel überschritten hat. Dieses Attribut unterstützt das Dashboard „SLA-Konformität und Zieltrends“. Es macht Cases sichtbar, die Compliance-Risiken oder Strafzahlungen für die Organisation verursachen können. Warum das wichtig ist Entscheidend für Compliance und Leistungsüberwachung. Bezugsquelle Logik des Jira-Service-Management-SLA-Felds Beispiele EingehaltenVerletztPausiert
	Verknüpfte Change-Anforderung LinkedChangeRequest	Die Kennung der mit diesem Problem verknüpften Change-Anforderung.
Beschreibung Speichert die ID der Change-Anforderung (RFC), die zur Umsetzung der dauerhaften Lösung erstellt wurde. Diese Verknüpfung ist für das Dashboard „Verzögerung bis zur Initiierung der Change-Anforderung“ entscheidend. Sie verbindet den Problem-Management-Prozess mit dem Change Management und ermöglicht eine prozessübergreifende Analyse. Warum das wichtig ist Verbindet die Untersuchung mit der Behebung im Change-Management-Prozess. Bezugsquelle Vorgangsverknüpfungen mit dem Typ „is fixed by“ oder einem ähnlichen Typ Beispiele CR-404CHG-1099CR-5512
	Workaround verfügbar WorkaroundDetails	Gibt an, ob ein Workaround für das Problem dokumentiert wurde.
Beschreibung Erfasst, ob ein Text zu einem temporären Workaround vorhanden oder veröffentlicht ist. Dadurch kann die Organisation die „Geschwindigkeit der Workaround-Veröffentlichung“ verfolgen. Die Analyse dieses Feldes zeigt, wie schnell das Team die Servicestabilität wiederherstellen kann, bevor eine dauerhafte Lösung gefunden wurde. Warum das wichtig ist Wichtig, um die Geschwindigkeit der vorläufigen Entlastung für das Unternehmen zu messen. Bezugsquelle Benutzerdefiniertes Feld „Workaround“ Beispiele Dienst neu startenBrowser-Cache leerenKeine Angabe

Erforderlich Empfohlen Optional

Aktivitäten des Problemmanagements

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um Ihre Lösungs-Workflows präzise zu ermitteln.

8 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Incident mit Problem verknüpft	Die Verknüpfung eines zugehörigen Incident-Tickets mit dem Problem Record. Sie wird in der Tabelle oder im Verlauf der Issue Links erfasst.
Warum das wichtig ist Bestimmt die Auswirkung und den Umfang des Problems. Unverzichtbar für die KPI „Incident to Problem Linkage Depth“ und für eine Priorisierung nach Geschäftseinfluss. Bezugsquelle Jira Issue Links: Link mit dem Typ „causes“ oder „relates to“ erstellt Erfassen Wird protokolliert, sobald ein Issue Link erstellt wird. Ereignistyp explicit
	Lösung verifiziert	Die Bestätigung, dass die Korrektur das Problem wirksam gelöst hat. Sie wird aus einem Statusübergang in „Resolved“ oder einen bestimmten Status „Verified“ abgeleitet.
Warum das wichtig ist Qualitätssicherung, die bestätigt, dass die Korrektur funktioniert. Verzögerungen weisen auf Engpässe bei Tests oder der Benutzerabnahme hin. Bezugsquelle Jira-Issue-History: Status in „Resolved“ oder „Verified“ geändert Erfassen Aktualisierungen des Statusfeldes vergleichen Ereignistyp inferred
	Problem Record erstellt	Das erste Event, bei dem das Problem-Ticket im System erstellt wird. Dieses Event wird im Vorgangsverlauf ausdrücklich über den Erstellungs-Timestamp erfasst.
Warum das wichtig ist Kennzeichnet den Beginn des Lebenszyklus im Problem Management und ermöglicht eine Volumenanalyse. Unverzichtbar für die Berechnung von Durchsatz und Eingangsraten. Bezugsquelle Jira-Issue-Tabelle: Timestamp des Erstellungsdatums oder History Tab: Event „Issue Created“ Erfassen Wird protokolliert, sobald die Transaktion zur Vorgangserstellung abgeschlossen ist. Ereignistyp explicit
	Problem Record geschlossen	Die endgültige Beendigung des Problem-Lebenszyklus. Wird ausdrücklich erfasst, sobald sich der Status in „Closed“ ändert.
Warum das wichtig ist Das definitive Ende der Prozessinstanz. Erforderlich für die Berechnung der gesamten Durchlaufzeit und der Abschlussquoten. Bezugsquelle Jira-Issue-History: Status in „Closed“ geändert Erfassen Wird protokolliert, sobald der Status in „Closed“ übergeht. Ereignistyp explicit
	Supportgruppe zugewiesen	Die Zuweisung des Problem Records an ein bestimmtes technisches Team oder eine Supportgruppe. Sie wird über Änderungen am benutzerdefinierten Feld „Support Group“ oder am Feld „Assignee“ erfasst, falls keine Gruppen verwendet werden.
Warum das wichtig ist Entscheidend für die Analyse von Übergaben und Engpässen zwischen Teams. Eine hohe Zahl an Übergaben kann auf ineffiziente Weiterleitungsregeln hinweisen. Bezugsquelle Jira-Issue-History: Feld „Support Group“ oder „Assignee“ geändert Erfassen Wird protokolliert, sobald sich das Zuweisungsfeld ändert. Ereignistyp explicit
	Untersuchung gestartet	Der Übergang des Problemstatus in einen aktiven Untersuchungsstatus, etwa „Under Investigation“ oder „In Progress“. Damit beginnt die Phase der aktiven Bearbeitung.
Warum das wichtig ist Startet die Zeitmessung für die Untersuchungsdauer. So lassen sich Wartezeiten im Backlog von der tatsächlichen aktiven Analyse unterscheiden. Bezugsquelle Jira-Issue-History: Status in „Under Investigation“ oder „In Progress“ geändert Erfassen Aktualisierungen des Statusfeldes vergleichen Ereignistyp inferred
	Ursache identifiziert	Der Zeitpunkt, an dem die zugrunde liegende Ursache formal erfasst wird. Er wird aus einer Statusänderung in „Root Cause Identified“ oder dem Ausfüllen des Feldes „Root Cause“ abgeleitet.
Warum das wichtig ist Ein wichtiger Meilenstein, der die Untersuchungsphase beendet. Unverzichtbar für die Berechnung von „Mean Time to Root Cause Discovery“. Bezugsquelle Jira-Issue-History: Status in „Root Cause Identified“ geändert ODER Feld „Root Cause“ ausgefüllt Erfassen Statusfeld vergleichen oder prüfen, ob das Feld ausgefüllt wurde Ereignistyp inferred
	Workaround aktualisiert	Das Ausfüllen oder Aktualisieren des Textfeldes „Workaround“. Dieses Event zeigt an, dass eine temporäre Korrektur dokumentiert wurde.
Warum das wichtig ist Misst, wie schnell eine Entlastung für das Geschäft bereitgestellt wird. Entscheidend für die KPI „Workaround Availability Lead Time“. Bezugsquelle Jira-Issue-History: Feld „Workaround“ geändert, nicht null Erfassen Wird protokolliert, sobald das Feld „Workaround“ geändert wird. Ereignistyp explicit
	Change Request verknüpft	Die Verknüpfung eines Request for Change (RFC) mit dem Problem Record. Dies zeigt den Beginn des Prozesses für die dauerhafte Korrektur an.
Warum das wichtig ist Misst die Verzögerung zwischen der Identifikation der Ursache und dem Beginn der Behebung. Unterstützt die KPI „Change Management Transition Delay“. Bezugsquelle Jira Issue Links: Link mit dem Typ „is fixed by“ erstellt oder mit dem Issue-Typ „Change“ verknüpft Erfassen Wird protokolliert, sobald ein Link zu einem Issue-Typ „Change“ erstellt wird. Ereignistyp explicit
	Dauerhafte Korrektur angewendet	Der Übergang, der anzeigt, dass die Lösung implementiert wurde. Er wird meist aus einer Statusänderung in „Implementing“ oder „Fixed“ abgeleitet.
Warum das wichtig ist Kennzeichnet das Ende der technischen Behebung. Wird zur Messung der Implementierungsdauer verwendet. Bezugsquelle Jira-Issue-History: Status in „Implemented“, „Pending Verification“ oder „Fixed“ geändert Erfassen Aktualisierungen des Statusfeldes vergleichen Ereignistyp inferred
	Priorität des Problems geändert	Eine Aktualisierung des Feldes „Priority“ im Problem Record. Sie wird erfasst, indem der History Tab auf Änderungen am Feld „Priority“ überwacht wird.
Warum das wichtig ist Zeigt eine Eskalation oder Deeskalation des Problems an. Die Analyse hilft, die Genauigkeit der ersten Triage und die Überalterung des Backlogs mit hoher Priorität zu bewerten. Bezugsquelle Jira-Issue-History: Feld „Priority“ von altem Wert zu neuem Wert geändert Erfassen Wird protokolliert, sobald das Feld „Priority“ aktualisiert wird. Ereignistyp explicit
	Problem erneut geöffnet	Der Übergang eines Problems aus dem Status „Resolved“ oder „Closed“ zurück in einen aktiven Status. Dies weist auf eine fehlgeschlagene Korrektur oder eine abgelehnte Lösung hin.
Warum das wichtig ist Eine zentrale Qualitätskennzahl. Hohe Wiedereröffnungsquoten weisen auf eine unzureichende Ursachenanalyse oder Prüfung hin. Bezugsquelle Jira-Issue-History: Status von „Closed“/„Resolved“ in „Open“/„In Progress“ geändert Erfassen Abfolge der Statusfelder vergleichen Ereignistyp inferred
	Review nach der Implementierung	Die Durchführung eines Reviews nach der Anwendung der Korrektur. Erfasst über eine Statusänderung in „In Review“ oder Aktualisierungen spezifischer PIR-Felder.
Warum das wichtig ist Eine Compliance-Aktivität, die sicherstellt, dass Erkenntnisse dokumentiert werden. Unterstützt die Analyse der „Post Implementation Review Compliance“. Bezugsquelle Jira-Issue-History: Status in „In Review“ geändert ODER Feld „PIR Notes“ aktualisiert Erfassen Statusfeld oder Aktualisierungen der PIR-Felder vergleichen Ereignistyp inferred
	SLA verletzt	Ein Event, das anzeigt, dass die Lösungszeit des Problems die festgelegte Service Level Agreement-Vorgabe überschritten hat. Dies wird durch den Vergleich des SLA-Zieldatums mit dem Lösungsdatum berechnet.
Warum das wichtig ist Entscheidend für Compliance-Berichte. Hilft zu erkennen, welche Prioritäten oder Kategorien die Zielvorgaben am häufigsten verfehlen. Bezugsquelle Jira-Service-Management-SLA-Logs: „Time to Resolution“ > Zielwert oder berechnet Erfassen Aus SLA-Felddaten ableiten oder Fälligkeitsdatum mit Lösungsdatum vergleichen Ereignistyp calculated

Anleitungen zur Datenextraktion

So erhalten Sie Ihre Daten aus Jira Service Management

Schritte

Melden Sie sich über einen Webbrowser bei Ihrer Jira-Service-Management-Instanz an. Verwenden Sie ein Konto mit der Berechtigung „Browse Projects“ für das Projekt Problem Management.
Öffnen Sie in der oberen Menüleiste Filters und wählen Sie anschließend Advanced Issue Search, um den Issue Navigator zu öffnen.
Wechseln Sie in den Suchmodus JQL (Jira Query Language), falls nicht bereits ausgewählt, statt Basic zu verwenden.
Geben Sie die im Abschnitt Query angegebene JQL-Abfrage ein, um Problem-Datensätze zu isolieren, zum Beispiel project = 'Problem Management'. Achten Sie darauf, dass der Zeitraum innerhalb der Exportgrenzen des Systems liegt.
Klicken Sie auf Search und prüfen Sie, ob die erwarteten Problem-Datensätze angezeigt werden.
Suchen Sie oben rechts in der Oberfläche des Issue Navigators nach der Schaltfläche Export.
Wählen Sie im Dropdown-Menü Export XML. Wählen Sie nicht CSV, da der Standard-CSV-Export nur den aktuellen Status enthält und die für Process Mining erforderlichen historischen Änderungsprotokolle fehlen.
Speichern Sie die erzeugte XML-Datei, zum Beispiel jira_export.xml, in einem lokalen Verzeichnis, auf das Ihre Verarbeitungsumgebung zugreifen kann.
Bereiten Sie die Python-Umgebung vor, indem Sie die erforderliche Bibliothek pandas installieren, sofern sie noch nicht vorhanden ist.
Führen Sie das im Abschnitt Query bereitgestellte Python-Skript aus. Stellen Sie sicher, dass die Variable für den Dateipfad auf den Speicherort Ihrer XML-Datei verweist.
Das Skript analysiert die RSS/XML-Struktur und extrahiert den Timestamp „Created“, die „History“-Einträge für Änderungen an Status, Priorität und Zuordnung sowie „Issue Links“ für verknüpfte Incidents.
Das Skript ermittelt SLA-Verletzungen, indem es Lösungsdaten mit Fälligkeitsdaten vergleicht, und gibt ein formatiertes CSV-Event-Log aus, das für ProcessMind bereit ist.

Konfiguration

Exportformat: Verwenden Sie den XML-Export (RSS), nicht CSV. Das XML-Format enthält die Tags <history> und <issuelinks>, die für die Rekonstruktion des Prozessablaufs erforderlich sind.
Zeilenlimit: Die Standardexporte von Jira sind häufig auf 1.000 Vorgänge pro Export begrenzt. Bei größeren Datenmengen müssen Sie die Extraktion paginieren, indem Sie den JQL-Zeitraum anpassen, zum Beispiel created >= '2023-01-01' AND created < '2023-02-01', und mehrere Exporte durchführen.
JQL-Filter: Stellen Sie sicher, dass der Schlüssel project der Kennung Ihres konkreten Problem-Management-Projekts entspricht, zum Beispiel PROB oder PM.
Systemzeitzone: Prüfen Sie, ob das Benutzerprofil, das den Export durchführt, dieselbe Zeitzone wie das System verwendet, damit die Timestamps konsistent bleiben.
Feldberechtigungen: Der Benutzer benötigt die Berechtigung, die Änderungshistorie und verknüpfte Vorgänge anzuzeigen, damit Übergänge und Incident-Verknüpfungen erfasst werden können.
Benutzerdefinierte Felder: Wenn „Root Cause“ oder „Workaround“ benutzerdefinierte Felder sind, muss die Logik zur Zuordnung der Feldnamen im Skript mit den konkreten Feldnamen Ihrer Jira-Instanz übereinstimmen.

a Beispielabfrage sql

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.x sowie die Bibliotheken requests und pandas installiert sind. Sie benötigen ein Jira-Service-Management-Konto mit Leseberechtigung für das relevante Projekt. Für Jira Cloud erstellen Sie über Ihre Atlassian-Kontoeinstellungen ein API Token. Für Data Center erstellen Sie ein Personal Access Token (PAT).
IDs benutzerdefinierter Felder ermitteln: Jira Service Management verwendet dynamische IDs für benutzerdefinierte Felder, zum Beispiel customfield_10012 für Support Group oder SLA. Fragen Sie vor der eigentlichen Extraktion über einen Browser oder Postman einen einzelnen Problem-Vorgang ab (/rest/api/2/issue/[ISSUE-KEY]), um die konkreten Feld-IDs für „Support Group“, „Workaround“, „Root Cause“ und Ihre SLA-Felder zu ermitteln.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript und aktualisieren Sie das CONFIG-Dictionary. Ersetzen Sie URL, Benutzer-E-Mail-Adresse und API Token. Aktualisieren Sie das FIELD_MAPPING-Dictionary mit den tatsächlichen benutzerdefinierten Feldnamen oder IDs aus Schritt 2. Passen Sie JQL_QUERY an Ihr konkretes Projekt an, zum Beispiel project = PM AND issuetype = Problem.
Statuszuordnungen definieren: Ordnen Sie im STATUS_MAPPING-Dictionary des Skripts Ihre Jira-Workflow-Status, zum Beispiel „Under Investigation“, „Implementing“ und „Resolved“, den standardmäßigen ProcessMind-Aktivitätsnamen zu, etwa „Investigation Started“ und „Permanent Fix Applied“.
Extraktion ausführen: Führen Sie das Skript über ein Terminal oder eine IDE aus. Das Skript verwendet die Jira Search API mit expand=changelog, um den aktuellen Status und die vollständige Historie aller Feldänderungen abzurufen.
Verarbeitungslogik: Das Skript durchläuft jeden Vorgang. Zunächst erstellt es aus dem Erstellungs-Timestamp ein Ereignis „Problem Record Created“. Anschließend analysiert es die Changelog-Historie. Für jeden History-Eintrag prüft es, ob das geänderte Feld in der relevanten Liste enthalten ist, etwa Status, Priority oder Link, und erzeugt eine entsprechende Ereigniszeile.
SLA-Verarbeitung: Das Skript versucht, SLA-Verletzungen anhand von Änderungen in SLA-bezogenen benutzerdefinierten Feldern oder von Statusübergängen mit der Bezeichnung „Breached“ zu erkennen. Passen Sie die Logik in der Funktion _parse_sla_breach an, wenn Ihr System eine spezielle Automatisierung zur Kennzeichnung von Verletzungen verwendet.
Datentransformation: Das Skript überführt die verschachtelte JSON-Struktur in einen tabellarischen Pandas DataFrame. Timestamps werden in das ISO-8601-Format konvertiert.
Export: Der fertige Datensatz wird als CSV-Datei mit dem Namen jira_problem_event_log.csv exportiert. Öffnen Sie die Datei und prüfen Sie, ob die Spaltenüberschriften den ProcessMind-Anforderungen entsprechen.
Upload in ProcessMind: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie ProblemKey der Case ID, ActivityName der Activity und EventTimestamp dem Timestamp zu.

Konfiguration

API-Endpunkt: Verwendet /rest/api/2/search, kompatibel mit Jira Cloud und den meisten Data-Center-Versionen. API v3 wird ebenfalls unterstützt, v2 bietet jedoch in der Regel eine breitere Kompatibilität.
Paginierung: Das Skript verwendet startAt und maxResults, um große Datenmengen effizient zu verarbeiten. Die Standardgröße eines Datenpakets beträgt 50.
Changelog-Erweiterung: Der Parameter expand=changelog ist entscheidend. Ohne ihn wird nur der aktuelle Status zurückgegeben, während Historie und Prozessablauf fehlen.
JQL-Filterung: Die Abfrage filtert nach issuetype = Problem. Es empfiehlt sich dringend, für erste Tests einen Datumsfilter zu ergänzen, zum Beispiel created >= -180d, um das Datenvolumen zu begrenzen.
Authentifizierung: Für Cloud wird Basic Auth mit E-Mail-Adresse und Token unterstützt. Für Data Center müssen Sie die Header für Bearer Tokens anpassen.
Feldzuordnung: Eine sorgfältige Konfiguration ist erforderlich. Die internen Jira-Feldnamen für „Status“ und „Priority“ sind standardisiert. „Support Group“, „Root Cause“ und „SLA“ sind dagegen fast immer benutzerdefinierte Felder mit individuellen IDs, zum Beispiel customfield_12345.

a Beispielabfrage python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        params = {
            class="hl-string">"jql": jql,
            class="hl-string">"startAt": start_at,
            class="hl-string">"maxResults": max_results,
            class="hl-string">"expand": class="hl-string">"changelog"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Bereit für den Start?

Verwandeln Sie Ihre Daten aus dem Problem Management noch heute in konkrete Erkenntnisse. Laden Sie die Anleitung herunter oder wenden Sie sich an unser Support-Team, um mit Process Mining zu beginnen.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Ihren Problem-Management-Flow noch heute

Verkürzen Sie Durchlaufzeiten um 30 % und stabilisieren Sie Ihre IT-Umgebung.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für Problem Management

Ihr Daten-Template für Problem Management

Attribute des Problemmanagements

Aktivitäten des Problemmanagements

Anleitungen zur Datenextraktion

Export aus dem Jira Service Management Issue Navigator

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion über die Jira REST API mit Changelog

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie Ihren Problem-Management-Flow noch heute

Ihr Daten-Template für Problem Management

Ihr Daten-Template für Problem Management

Attribute des Problemmanagements

Aktivitäten des Problemmanagements

Anleitungen zur Datenextraktion

Export aus dem Jira Service Management Issue Navigator

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion über die Jira REST API mit Changelog

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie Ihren Problem-Management-Flow noch heute

Ihre Privatsphäre ist uns wichtig