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

Ihr Daten-Template für das Problemmanagement

Jira Service Management

← Zurück zum Leitfaden zur Prozessverbesserung

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

Ihr Daten-Template für das Problemmanagement

Dieses Template bietet einen umfassenden Leitfaden zur Analyse Ihrer IT-Service-Management-Workflows. Es benennt die wesentlichen Datenpunkte und Prozessmeilensteine in Jira Service Management. Außerdem gibt es einen strukturierten Überblick über die Attribute und Aktivitäten, die erforderlich sind, um nachzuvollziehen, wie Ihr Team zugrunde liegende Probleme untersucht und deren Ursachen ermittelt. Nutzen Sie diese Empfehlungen, um die Datenerfassung zu vereinfachen und sicherzustellen, dass Ihre Process-Mining-Initiativen verwertbare Erkenntnisse liefern.

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

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute des Problemmanagements

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie den Lebenszyklus des Problemmanagements umfassend analysieren können.

5 Erforderlich 5 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die konkrete Aktion oder Statusänderung, die beim Problem Record stattgefunden hat.
Beschreibung Dieses Attribut erfasst den Namen des Ereignisses oder Statusübergangs im Lebenszyklus des Problemmanagements. Beispiele sind „Problem protokolliert“, „Status auf Untersuchung geändert“ oder „Ursache ermittelt“. Das Attribut ist wichtig, um den Prozessablauf abzubilden und die Reihenfolge der Schritte zur Problemlösung zu erkennen. Beim Process Mining bilden diese Aktivitäten die Knoten der Prozessübersicht. Warum das wichtig ist Definiert die Schritte in der Prozessübersicht und ermöglicht die Analyse von Prozessvarianten. Woher beziehen Jira-Änderungsprotokoll (Verlauf) oder Statusübergänge des Vorgangs Beispiele Problem Record erstelltUntersuchung begonnenUrsache ermitteltWorkaround aktualisiertProblem Record geschlossen
	Letzte Datenaktualisierung LastDataUpdate	Zeitstempel der Datenextraktion oder der letzten Aktualisierung.
Beschreibung Gibt an, wann der Datensatz zuletzt mit der Live-Umgebung von Jira Service Management synchronisiert wurde. So können Analysten die Aktualität der Daten beurteilen. Damit lässt sich prüfen, ob die Analyse den aktuellen Stand des Prozesses abbildet. Außerdem können mögliche Verzögerungen bei der Datenübertragung erkannt werden. Warum das wichtig ist Sichert die Aktualität der Daten und stärkt das Vertrauen in die Analyseergebnisse. Woher beziehen ETL-Zeitstempel Beispiele 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Problem Record ProblemKey	Die eindeutige Kennung, die dem Problem Record in Jira Service Management zugewiesen wird.
Beschreibung Dieses Attribut dient als zentrale Case-ID für die Process-Mining-Analyse. Es enthält den eindeutigen Schlüssel, zum Beispiel PM-1001, den Jira Service Management beim Erstellen eines neuen Problem Records vergibt. Damit werden alle zugehörigen Aktivitäten, Statusänderungen und Aktualisierungen zu einer einzigen End-to-End-Prozessinstanz zusammengeführt. Anhand dieses Attributs lässt sich der gesamte Lebenszyklus eines Problems visualisieren, von der ersten Erkennung über die Untersuchung bis zum endgültigen Abschluss. Warum das wichtig ist Dieser grundlegende Schlüssel ist erforderlich, um den Prozessablauf zu rekonstruieren und einzelne Problem Records nachzuverfolgen. Woher beziehen Vorgangstabelle, Feld „Key“ oder „Issue Key“ Beispiele PM-1023PM-4099PRB-3321PM-5001
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Daten stammen.
Beschreibung Gibt an, aus welchem Softwaresystem die Prozessdaten exportiert wurden. In diesem Fall lautet der Wert immer „Jira Service Management“. In Umgebungen mit mehreren Systemen hilft dieses Attribut, Datenquellen voneinander zu unterscheiden. In dieser Ansicht dient es vor allem als statische Kennung für die Datenherkunft. Warum das wichtig ist Gibt Aufschluss über die Datenherkunft, insbesondere wenn die Daten mit anderen IT-Service-Management-Daten zusammengeführt werden. Woher beziehen Fest codiert oder Systemkonfiguration Beispiele Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt einer Aktivität. Es dient dazu, Ereignisse chronologisch zu ordnen und die Dauer zwischen Prozessschritten zu berechnen. Genaue Timestamps sind entscheidend für die Berechnung von Durchlaufzeiten, etwa vom Zeitpunkt „Problem protokolliert“ bis „Ursache ermittelt“, 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 Ereignisse. Woher beziehen Erstellungsdatum im Jira-Änderungsprotokoll oder Erstellungsdatum des Vorgangs Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Benutzer UserKey	Eindeutige Kennung oder Name des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Erfasst die Person oder das Systemkonto, das für die jeweilige Aktivität verantwortlich ist. Das kann der „Assignee“ sein, der den Datensatz aktualisiert, oder der „Author“ einer Statusänderung. Diese Daten dienen dazu, die Ressourcenauslastung zu analysieren, Engpässe bei Übergaben zwischen Benutzern zu erkennen und die Verantwortlichkeit im Problemmanagement sicherzustellen. Warum das wichtig ist Wichtig für die Analyse von Übergaben, Funktionstrennung und Arbeitsauslastung. Woher beziehen Jira-Feld „author“ im Änderungsprotokoll oder Feld „assignee“ beim Vorgang Beispiele j.smithsystem_automationm.doe
	Kategorie der Grundursache RootCauseCategory	Klassifizierung der zugrunde liegenden Ursache des Problems.
Beschreibung Ordnet die technischen oder prozessbedingten Fehler ein, die das Problem verursacht haben, etwa „Softwarefehler“, „menschlicher Fehler“ oder „Hardwarefehler“. In Jira Service Management wird dafür häufig ein benutzerdefiniertes Feld verwendet. Dieses Attribut unterstützt das Dashboard „Verteilung der Grundursachenkategorien“. So können strategische Entscheidungen darüber getroffen werden, wo Investitionen in Infrastruktur oder Schulungen Wiederholungen verhindern. Warum das wichtig ist Wichtig, um systemische Probleme zu erkennen und vorbeugende Maßnahmen abzuleiten. Woher beziehen Benutzerdefiniertes Feld „Root Cause“ oder „Root Cause Category“ Beispiele SoftwarefehlerKonfigurationsfehlerKapazitätsproblemLieferantenproblem
	Priorität Priority	Kritikalität des Problemdatensatzes.
Beschreibung Gibt die Dringlichkeit und die Auswirkungen des Problems an. Die Werte reichen üblicherweise von „Niedrig“ bis „Kritisch“. Mit diesem Feld lässt sich die Analyse segmentieren und prüfen, ob 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. Woher beziehen Vorgangsfeld „Priority“ Beispiele HöchsteHochMittelNiedrig
	Problembeschreibung ProblemSummary	Kurztext oder Titel des Problemdatensatzes.
Beschreibung Enthält eine kurze Zusammenfassung des Problemdatensatzes. Der Text liefert Analysten Kontext, wenn sie einzelne Cases im Process-Mining-Tool prüfen. Er ermöglicht die Suche nach Stichwörtern und eine qualitative Analyse der erfassten Problemarten. Warum das wichtig ist Ergänzt die Case-ID um einen verständlichen Kontext. Woher beziehen Vorgangsfeld „Summary“ Beispiele Zeitüberschreitung bei der Datenbankverbindung in der EU-RegionLatenzspitze beim E-Mail-DienstWarteschlange für die Auftragsverarbeitung blockiert
	Zugewiesene Supportgruppe SupportGroup	Das technische Team oder die Gruppe, die derzeit mit der Untersuchung des Problems betraut ist.
Beschreibung Gibt an, welches Team zum Zeitpunkt des Ereignisses für den Problemdatensatz verantwortlich war. In Jira Service Management wird dies 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“ wichtig. Es zeigt, wie Probleme zwischen Teams weitergegeben werden und wo sie am längsten liegen bleiben. Warum das wichtig ist Wichtig für die Analyse von Organisationseinheiten und das Erkennen von Reibungsverlusten zwischen Teams. Woher beziehen Vorgangsfeld „Component“ oder benutzerdefiniertes Feld „Support Group“ Beispiele DatenbankadministrationNetzwerkbetriebAnwendungssupport, Ebene 2
	Anzahl verknüpfter Incidents LinkedIncidentCount	Anzahl der mit diesem Problemdatensatz verknüpften Incidents.
Beschreibung Anzahl der Incident-Tickets, die mit dem Problemdatensatz verknüpft sind. Dieses Attribut beziffert die Auswirkungen des Problems auf die Benutzer. Es fließt in die KPI „Tiefe der Verknüpfung zwischen Incidents und Problemen“ ein und hilft dabei, Probleme mit besonders vielen Support-Tickets zu priorisieren. Warum das wichtig ist Beziffert die geschäftlichen Auswirkungen anhand der Anzahl der Incidents. Woher beziehen Anzahl der Verknüpfungen in der Tabelle „issuelinks“ mit dem Typ „Problem/Incident“ Beispiele 011550
	Erkennungsquelle DetectionSource	Gibt an, wie das Problem erkannt wurde, zum Beispiel proaktiv oder reaktiv.
Beschreibung Gibt an, wodurch das Problem erkannt wurde. Häufige Werte sind „Proaktive Überwachung“, „Service-Desk-Incident“ oder „Lieferantenbenachrichtigung“. Dieses Attribut wird im Dashboard „Proaktive und reaktive Erkennung“ verwendet, um den Reifegrad des Problemmanagements zu messen. Warum das wichtig ist Misst den Reifegrad des Prozesses und die Wirksamkeit der Überwachungssysteme. Woher beziehen Benutzerdefiniertes Feld „Source“ oder „Detection Source“ Beispiele Proaktive ÜberwachungEskalation eines IncidentsLieferantenbenachrichtigung
	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 vom geschlossenen in den offenen Status wechselt. Es unterstützt die „Analyse der Wiedereröffnungsrate von Problemen“. Eine hohe Wiedereröffnungsrate weist auf Qualitätsmängel bei dauerhaften Lösungen oder unzureichende Prüfverfahren hin. Warum das wichtig ist Qualitätsindikator für die Wirksamkeit von Fehlerbehebungen. Woher beziehen Aus Statusübergängen abgeleitet Beispiele truefalse
	Erstellungsdatum CreatedDate	Datum, an dem der Problemdatensatz erstellt wurde.
Beschreibung Zeitstempel, zu dem das Problem erstmals im System erfasst wurde. Während der Ereigniszeitstempel den Zeitpunkt der Aktivität angibt, dient dieses Attribut häufig der übergeordneten Filterung, etwa für die Frage: „Alle im ersten Quartal erstellten Probleme anzeigen“. Es bildet den Ausgangspunkt für die Altersstrukturanalyse. Warum das wichtig ist Ausgangsdatum für die Analyse des Alters und des Eingangsvolumens. Woher beziehen Vorgangsfeld „Created“ Beispiele 2023-01-012023-06-15
	Lösungscode ResolutionCode	Code, der angibt, wie das Problem gelöst wurde.
Beschreibung Gibt das Endergebnis des Problemdatensatzes an, zum Beispiel „Behoben“, „Wird nicht behoben“, „Duplikat“ oder „Nicht reproduzierbar“. Damit lassen sich erfolgreich gelöste Probleme von Datensätzen unterscheiden, die aus administrativen Gründen geschlossen wurden. So bleiben KPI-Berechnungen wie „Durchschnittliche Zeit bis zur Ermittlung der Grundursache“ aussagekräftig. Warum das wichtig ist Unterscheidet wirksame Fehlerbehebungen von administrativen Schließungen. Woher beziehen Vorgangsfeld „Resolution“ Beispiele ErledigtWird nicht umgesetztDuplikatNicht reproduzierbar
	Meldende Person ReporterName	Benutzer, der den Problemdatensatz ursprünglich erfasst hat.
Beschreibung Gibt an, wer den Problemdatensatz erstellt hat. Diese Person ist nicht unbedingt dem Problem zugewiesen. Die Analyse der meldenden Personen zeigt, wo Probleme erkannt werden, zum Beispiel durch Service-Desk-Mitarbeitende oder Systemadministratoren. Das ergänzt die Analyse „Proaktive und reaktive Erkennung“ um zusätzlichen Kontext. Warum das wichtig ist Gibt an, woher die Problemmeldung stammt. Woher beziehen Vorgangsfeld „Reporter“ Beispiele monitoring_servicehelpdesk_leadnetwork_admin
	PIR durchgeführt ReviewStatus	Gibt an, ob eine Überprüfung nach der Implementierung (Post Implementation Review, PIR) durchgeführt wurde.
Beschreibung Erfasst, ob die Aktivität „Post Implementation Review“ oder das entsprechende Kennzeichen im Case vorhanden ist. Dies ist wichtig für das Dashboard „Compliance bei Überprüfungen nach der Implementierung“. So lässt sich prüfen, ob die Organisation ihre Governance-Vorgaben zur kontinuierlichen Verbesserung einhält. Warum das wichtig ist Compliance-Kennzahl für organisationales Lernen. Woher beziehen Benutzerdefiniertes Feld „PIR Status“ oder Vorhandensein der Aktivität „PIR“ Beispiele AbgeschlossenAusstehendNicht erforderlich
	SLA-Verletzungsstatus SlaBreachStatus	Gibt an, ob der Problemdatensatz die vereinbarte Service Level Agreement (SLA) verletzt hat.
Beschreibung Ein boolesches Feld oder Statusfeld, das angibt, ob die Lösungszeit das vereinbarte Ziel überschritten hat. Es unterstützt das Dashboard „SLA-Konformität und Zieltrends“. Es hebt Cases hervor, die für die Organisation ein Compliance-Risiko oder mögliche Strafzahlungen bedeuten. Warum das wichtig ist Wichtig für die Compliance- und Leistungsüberwachung. Woher beziehen Logik des SLA-Felds in Jira Service Management Beispiele EingehaltenVerletztPausiert
	Verknüpfte Änderungsanforderung LinkedChangeRequest	Kennung der mit diesem Problem verknüpften Änderungsanforderung.
Beschreibung Speichert die ID der Änderungsanforderung (RFC), die zur Umsetzung der dauerhaften Lösung erstellt wurde. Diese Verknüpfung ist wichtig für das Dashboard „Verzögerung bis zur Einleitung einer Änderungsanforderung“. Sie verbindet das Problemmanagement mit dem Änderungsmanagement und ermöglicht Analysen über beide Prozesse hinweg. Warum das wichtig ist Verknüpft die Untersuchung mit der Behebung im Änderungsmanagement. Woher beziehen Vorgangsverknüpfungen mit dem Typ „wird behoben durch“ oder ähnlich Beispiele CR-404CHG-1099CR-5512
	Workaround verfügbar WorkaroundDetails	Gibt an, ob für das Problem ein Workaround dokumentiert wurde.
Beschreibung Erfasst, ob ein Text mit einem vorübergehenden Workaround vorhanden oder veröffentlicht ist. So lässt sich die „Veröffentlichungsgeschwindigkeit von Workarounds“ verfolgen. Die Analyse dieses Felds zeigt, wie schnell das Team die Stabilität des Service wiederherstellen kann, bevor eine dauerhafte Lösung gefunden ist. Warum das wichtig ist Wichtig, um zu messen, wie schnell das Unternehmen vorläufig entlastet wird. Woher beziehen Benutzerdefiniertes Feld „Workaround“ Beispiele Service neu startenBrowser-Cache leerenKeine Angabe

Erforderlich Empfohlen Optional

Aktivitäten im Problemmanagement

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie für eine präzise Ermittlung Ihrer Lösungsabläufe im Event Log erfassen sollten.

8 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Lösung verifiziert	Die Bestätigung, dass die Korrektur das Problem wirksam behoben hat. Sie lässt sich an einem Statuswechsel zu „Gelöst“ oder einem speziellen Status „Verifiziert“ erkennen.
Warum das wichtig ist Qualitätssicherung, die bestätigt, dass die Korrektur funktioniert. Verzögerungen an dieser Stelle weisen auf Engpässe bei Tests oder der Benutzerabnahme hin. Woher beziehen Jira-Vorgangsverlauf: Status auf „Gelöst“ oder „Verifiziert“ geändert Erfassung Aktualisierungen des Statusfelds vergleichen Ereignistyp inferred
	Problem Record erstellt	Das erste Ereignis: Ein Problem-Ticket wird im System erstellt. Der Erstellungs-Timestamp ist ausdrücklich im Vorgangsverlauf erfasst.
Warum das wichtig ist Kennzeichnet den Beginn des Problemmanagement-Lebenszyklus und ermöglicht eine Volumenanalyse. Wichtig für die Berechnung von Durchsatz und Eingangsraten. Woher beziehen Jira-Vorgangstabelle: Timestamp des Erstellungsdatums oder Verlaufsregisterkarte: Ereignis „Vorgang erstellt“ Erfassung Wird protokolliert, sobald der Vorgangserstellungsvorgang abgeschlossen ist Ereignistyp explicit
	Problem Record geschlossen	Der endgültige Abschluss des Problemmanagement-Lebenszyklus. Wird ausdrücklich erfasst, wenn sich der Status zu „Geschlossen“ ändert.
Warum das wichtig ist Das endgültige Ende der Prozessinstanz. Erforderlich für die Berechnung der Gesamtdurchlaufzeit und der Abschlussquote. Woher beziehen Jira-Vorgangsverlauf: Status auf „Geschlossen“ geändert Erfassung Wird protokolliert, wenn der Status auf „Geschlossen“ wechselt Ereignistyp explicit
	Supportgruppe zugewiesen	Der Problem Record wird einem bestimmten technischen Team oder einer Supportgruppe zugewiesen. Erfasst wird dies über Änderungen am benutzerdefinierten Feld „Supportgruppe“ oder, wenn keine Gruppen verwendet werden, am Feld „Zuständig“.
Warum das wichtig ist Wichtig für die Analyse von Übergaben und Engpässen zwischen Teams. Häufige Weitergaben können auf ineffiziente Weiterleitungsregeln hindeuten. Woher beziehen Jira-Vorgangsverlauf: Feld „Supportgruppe“ oder „Zuständig“ geändert Erfassung Wird protokolliert, wenn sich das Zuweisungsfeld ändert Ereignistyp explicit
	Untersuchung begonnen	Der Problemstatus wechselt in einen aktiven Untersuchungsstatus, zum Beispiel „Wird untersucht“ oder „In Bearbeitung“. Damit beginnt die aktive Arbeitsphase.
Warum das wichtig ist Startet die Messung der Untersuchungsdauer. So lässt sich die Wartezeit im Rückstand von der aktiven Analysezeit unterscheiden. Woher beziehen Jira-Vorgangsverlauf: Status auf „Wird untersucht“ oder „In Bearbeitung“ geändert Erfassung Aktualisierungen des Statusfelds vergleichen Ereignistyp inferred
	Ursache ermittelt	Der Zeitpunkt, an dem die zugrunde liegende Ursache offiziell erfasst wird. Er lässt sich an einer Statusänderung zu „Ursache ermittelt“ oder am Ausfüllen des Felds „Ursache“ erkennen.
Warum das wichtig ist Ein wichtiger Meilenstein, der die Untersuchungsphase beendet. Erforderlich für die Berechnung der „Durchschnittlichen Zeit bis zur Ermittlung der Ursache“. Woher beziehen Jira-Vorgangsverlauf: Status auf „Ursache ermittelt“ geändert ODER Feld „Ursache“ ausgefüllt Erfassung Statusfeld vergleichen oder prüfen, ob das Feld ausgefüllt wurde Ereignistyp inferred
	Vorfall mit Problem verknüpft	Ein zugehöriges Vorfall-Ticket wird mit dem Problem Record verknüpft. Erfasst wird dies in der Tabelle der Vorgangsverknüpfungen oder im Verlauf.
Warum das wichtig ist Zeigt Ausmaß und Umfang des Problems. Wichtig für die KPI „Tiefe der Verknüpfung von Vorfällen mit Problemen“ und für die Priorisierung nach Geschäftsauswirkung. Woher beziehen Jira-Vorgangsverknüpfungen: Verknüpfung mit dem Typ „verursacht“ oder „steht in Beziehung zu“ erstellt Erfassung Wird protokolliert, wenn eine Vorgangsverknüpfung erstellt wird Ereignistyp explicit
	Workaround aktualisiert	Das Textfeld „Workaround“ wird ausgefüllt oder aktualisiert. Dieses Ereignis zeigt an, dass eine vorübergehende Lösung dokumentiert wurde.
Warum das wichtig ist Misst, wie schnell eine Entlastung für das Geschäft bereitgestellt wird. Wichtig für die KPI „Vorlaufzeit bis zur Verfügbarkeit eines Workarounds“. Woher beziehen Jira-Vorgangsverlauf: Feld „Workaround“ geändert (nicht leer) Erfassung Wird protokolliert, wenn das Feld „Workaround“ geändert wird Ereignistyp explicit
	Änderungsantrag verknüpft	Ein Änderungsantrag (RFC) wird mit dem Problem Record verknüpft. Dies zeigt den Beginn des Prozesses für eine dauerhafte Korrektur an.
Warum das wichtig ist Misst die Verzögerung zwischen der Ermittlung der Ursache und dem Beginn der Behebung. Grundlage für die KPI „Verzögerung beim Übergang ins Change Management“. Woher beziehen Jira-Vorgangsverknüpfungen: Verknüpfung mit dem Typ „wird behoben durch“ erstellt oder mit einem Vorgang des Typs „Change“ verknüpft Erfassung Wird protokolliert, wenn eine Verknüpfung mit einem Vorgang des Typs „Change“ erstellt wird Ereignistyp explicit
	Dauerhafte Korrektur umgesetzt	Der Übergang zeigt an, dass die Lösung umgesetzt wurde. Er lässt sich in der Regel an einer Statusänderung zu „Wird implementiert“ oder „Behoben“ erkennen.
Warum das wichtig ist Kennzeichnet das Ende der technischen Behebung. Dient zur Messung der Implementierungsdauer. Woher beziehen Jira-Vorgangsverlauf: Status auf „Implementiert“, „Verifizierung ausstehend“ oder „Behoben“ geändert Erfassung Aktualisierungen des Statusfelds vergleichen Ereignistyp inferred
	Priorität des Problem Records geändert	Eine Änderung am Feld „Priorität“ des Problem Records. Sie wird erfasst, indem der Verlauf auf Änderungen am Feld „Priorität“ geprüft wird.
Warum das wichtig ist Zeigt an, dass die Priorität des Problems erhöht oder gesenkt wurde. Die Analyse hilft, die Genauigkeit der ersten Einstufung und die Dauer offener Probleme mit hoher Priorität zu bewerten. Woher beziehen Jira-Vorgangsverlauf: Feld „Priorität“ von altem zu neuem Wert geändert Erfassung Wird protokolliert, wenn das Feld „Priorität“ aktualisiert wird Ereignistyp explicit
	Problem wiedereröffnet	Ein Problem wechselt vom Status „Gelöst“ oder „Geschlossen“ 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. Eine hohe Wiedereröffnungsquote weist auf eine unzureichende Ursachenanalyse oder Prüfung hin. Woher beziehen Jira-Vorgangsverlauf: Status von „Geschlossen“/„Gelöst“ zu „Offen“/„In Bearbeitung“ geändert Erfassung Statusabfolge vergleichen Ereignistyp inferred
	Review nach der Implementierung	Ein Review wird nach der Umsetzung der Korrektur durchgeführt. Erfasst wird es über eine Statusänderung zu „Wird überprüft“ oder über Aktualisierungen an PIR-spezifischen Feldern.
Warum das wichtig ist Eine Compliance-Aktivität, mit der sichergestellt wird, dass Erkenntnisse festgehalten werden. Grundlage für die Analyse der „Compliance bei Reviews nach der Implementierung“. Woher beziehen Jira-Vorgangsverlauf: Status auf „Wird überprüft“ geändert ODER Feld „PIR-Notizen“ aktualisiert Erfassung Statusfeld oder PIR-Feldaktualisierungen vergleichen Ereignistyp inferred
	SLA-Ziel verfehlt	Dieses Ereignis zeigt an, dass die Zeit bis zur Lösung des Problems die festgelegte Service-Level-Vereinbarung überschritten hat. Es wird berechnet, indem das SLA-Zieldatum mit dem Lösungsdatum verglichen wird.
Warum das wichtig ist Wichtig für Compliance-Berichte. Hilft zu erkennen, bei welchen Prioritäten oder Kategorien die Ziele am häufigsten verfehlt werden. Woher beziehen SLA-Protokolle in Jira Service Management: „Zeit bis zur Lösung“ > Zielwert oder berechneter Wert Erfassung Aus SLA-Felddaten ableiten oder Fälligkeitsdatum mit Lösungsdatum vergleichen Ereignistyp calculated

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Jira Service Management

Schritte

Melden Sie sich in einem Webbrowser bei Ihrer Jira-Service-Management-Instanz an. Verwenden Sie ein Konto, das über die Berechtigung „Browse Projects“ für das Projekt Problem Management verfügt.
Öffnen Sie in der oberen Menüleiste „Filters“ und wählen Sie „Advanced Issue Search“, um den Issue Navigator aufzurufen.
Wechseln Sie den Suchmodus zu JQL (Jira Query Language), falls nicht bereits ausgewählt, statt „Basic“ zu verwenden.
Geben Sie die unten im Abschnitt „Query“ angegebene JQL-Abfrage ein, um Problem-Datensätze herauszufiltern (z. B. 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 im Issue Navigator die Schaltfläche „Export“.
Wählen Sie im Dropdown-Menü „Export XML“. Wählen Sie nicht CSV aus, da der standardmäßige CSV-Export nur den aktuellen Status enthält und nicht die für Process Mining erforderlichen historischen Änderungsprotokolle.
Speichern Sie die erzeugte XML-Datei (z. B. jira_export.xml) in einem Verzeichnis, auf das Ihre Verarbeitungsumgebung zugreifen kann.
Richten Sie die Python-Umgebung ein und installieren Sie bei Bedarf die Bibliothek pandas.
Führen Sie das im Abschnitt „Query“ bereitgestellte Python-Skript aus. Achten Sie darauf, dass der Dateipfad auf den Speicherort Ihrer XML-Datei verweist.
Das Skript verarbeitet die RSS/XML-Struktur und extrahiert den Timestamp „Created“, die „History“-Einträge zu Status-, Prioritäts- und Zuweisungsänderungen sowie „Issue Links“ zu zugehörigen Incidents.
Das Skript ermittelt SLA-Verletzungen, indem es Lösungsdaten mit Fälligkeitsdaten vergleicht, und erstellt ein formatiertes CSV-Event-Log für ProcessMind.

Konfiguration

Exportformat: Verwenden Sie den Export im Format XML (RSS), nicht CSV. Die XML-Datei enthält die Tags <history> und <issuelinks>, die für die Rekonstruktion des Prozessablaufs erforderlich sind.
Zeilenbegrenzung: Der Jira-Standardexport ist häufig auf 1.000 Vorgänge pro Export begrenzt. Bei größeren Datenmengen müssen Sie den Export aufteilen, indem Sie den JQL-Zeitraum anpassen (z. B. created >= '2023-01-01' AND created < '2023-02-01') und mehrere Exporte durchführen.
JQL-Filter: Stellen Sie sicher, dass der Schlüssel project mit der Kennung Ihres Problemmanagementprojekts übereinstimmt (z. B. PROB, PM).
Systemzeitzone: Prüfen Sie, ob das Benutzerprofil für den Export dieselbe Zeitzone wie das System verwendet, damit die Timestamps konsistent sind.
Feldberechtigungen: Der Benutzer benötigt die Berechtigung, den Änderungsverlauf und verknüpfte Vorgänge einzusehen, damit Übergänge und Incident-Verknüpfungen erfasst werden.
Benutzerdefinierte Felder: Wenn „Root Cause“ oder „Workaround“ benutzerdefinierte Felder sind, muss die Feldnamenzuordnung im Skript den konkreten Feldnamen Ihrer Jira-Instanz entsprechen.

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: Installieren Sie Python 3.x sowie die Bibliotheken requests und pandas. Sie benötigen ein Jira-Service-Management-Konto mit Leseberechtigung für das betreffende Projekt. Erstellen Sie für Jira Cloud in den Einstellungen Ihres Atlassian-Kontos ein API-Token. Erstellen Sie für Data Center ein Personal Access Token (PAT).
IDs benutzerdefinierter Felder ermitteln: Jira Service Management verwendet dynamische IDs für benutzerdefinierte Felder (z. B. customfield_10012 für Support Group oder SLA). Rufen Sie vor der eigentlichen Extraktion eine einzelne Problem-Meldung im Browser oder mit Postman ab (/rest/api/2/issue/[ISSUE-KEY]), um die IDs der Felder 'Support Group', 'Workaround', 'Root Cause' und Ihrer SLA-Felder zu ermitteln.
Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript und bearbeiten Sie das Wörterbuch CONFIG. Ersetzen Sie URL, Benutzer-E-Mail-Adresse und API-Token. Tragen Sie im Wörterbuch FIELD_MAPPING die tatsächlichen Namen oder IDs der in Schritt 2 ermittelten benutzerdefinierten Felder ein. Passen Sie JQL_QUERY an Ihr Projekt an (z. B. project = PM AND issuetype = Problem).
Statuszuordnungen festlegen: Ordnen Sie im Wörterbuch STATUS_MAPPING des Skripts Ihre Jira-Workflow-Status (z. B. 'Under Investigation', 'Implementing', 'Resolved') den standardisierten ProcessMind-Aktivitätsnamen zu (z. B. 'Investigation Started', 'Permanent Fix Applied').
Extraktion ausführen: Führen Sie das Skript in einem Terminal oder einer IDE aus. Es verwendet die Jira Search API mit expand=changelog, um den aktuellen Status und den vollständigen Änderungsverlauf aller Felder abzurufen.
Verarbeitungslogik: Das Skript durchläuft alle Vorgänge. Zunächst erstellt es anhand des Erstellungs-Timestamps ein Ereignis 'Problem Record Created'. Anschließend verarbeitet es den Änderungsverlauf. Für jeden Eintrag prüft es, ob das geänderte Feld zu den relevanten Feldern gehört (Status, Priorität, Verknüpfung usw.), und erzeugt eine entsprechende Ereigniszeile.
SLA-Verarbeitung: Das Skript versucht, SLA-Verletzungen anhand von Änderungen an SLA-bezogenen benutzerdefinierten Feldern oder Statusübergängen mit der Bezeichnung 'Breached' zu erkennen. Passen Sie die Logik in der Funktion _parse_sla_breach an, wenn Ihr System Verletzungen mit einer bestimmten Automatisierung kennzeichnet.
Datentransformation: Das Skript überführt die verschachtelte JSON-Struktur in einen tabellarischen Pandas DataFrame. Timestamps werden in das ISO-8601-Format umgewandelt.
Export: Der fertige Datensatz wird in eine CSV-Datei namens jira_problem_event_log.csv exportiert. Prüfen Sie, ob die Spaltenüberschriften den Anforderungen von ProcessMind entsprechen.
Upload zu ProcessMind: Importieren Sie die CSV-Datei in ProcessMind. Ordnen Sie ProblemKey der Case-ID, ActivityName der Aktivität und EventTimestamp dem Timestamp zu.

Konfiguration

API-Endpunkt: Verwendet /rest/api/2/search (kompatibel mit Cloud und den meisten Data-Center-Versionen). API v3 wird ebenfalls unterstützt, doch v2 bietet in der Regel eine breitere Kompatibilität.
Seitennummerierung: Das Skript verwendet startAt und maxResults, um auch große Datenmengen effizient abzurufen. Die Standardgröße eines Datenpakets beträgt 50.
Erweiterung des Änderungsverlaufs: Der Parameter expand=changelog ist entscheidend. Ohne ihn wird nur der aktuelle Status zurückgegeben, der Änderungsverlauf und der Prozessablauf gehen verloren.
JQL-Filterung: Die Abfrage filtert nach issuetype = Problem. Für erste Tests empfiehlt es sich dringend, einen Datumsbereich hinzuzufügen (z. B. created >= -180d), um die Datenmenge zu begrenzen.
Authentifizierung: Unterstützt Basic Auth (E-Mail-Adresse und Token) für Cloud. Für Data Center müssen Sie die Header so anpassen, dass Bearer-Token verwendet werden.
Feldzuordnung: Eine wichtige 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 eindeutigen IDs (z. B. customfield_12345).

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}")

Möchten Sie loslegen?

Wandeln Sie Ihre Problemmanagementdaten noch heute in konkrete Erkenntnisse um. Laden Sie den Leitfaden herunter oder wenden Sie sich an unser Supportteam, um mit Process Mining zu beginnen.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie noch heute Ihren Problemmanagementprozess

Verkürzen Sie die Zykluszeiten 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 das Problemmanagement

Ihr Daten-Template für das Problemmanagement

Attribute des Problemmanagements

Aktivitäten im Problemmanagement

Anleitungen zur Datenextraktion

Export aus dem Issue Navigator von Jira Service Management

Schritte

Konfiguration

Beispielabfrage sql

Python-Extraktion über die Jira-REST-API mit Änderungsverlauf

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie noch heute Ihren Problemmanagementprozess