> Kontinuierliche Prozessoptimierung > Problem Management > `Jira Service Management` > Datenvorlage

Ihre Problem Management Datenvorlage

Jira Service Management

Problem Management Attribute (21) Problem Management Aktivitäten (14) Extraktionsleitfäden (2)

Ihre Problem Management Datenvorlage

Diese Vorlage dient als umfassende Roadmap zur Analyse Ihrer IT-Service-Management-Workflows, indem sie die wesentlichen Datenpunkte und Prozessmeilensteine innerhalb von Jira Service Management identifiziert. Sie bietet einen strukturierten Überblick über die Attribute und Aktivitäten, die notwendig sind, um volle Transparenz darüber zu erhalten, wie Ihr Team zugrunde liegende Probleme und die Ursachenanalyse handhabt. Nutzen Sie diese Richtlinien, um Ihre Datenerfassung zu optimieren und sicherzustellen, dass Ihre Process Mining Initiativen umsetzbare Erkenntnisse liefern.

Empfohlene Attribute für eine tiefgehende Analyse
Prozessmeilensteine, die in Ihrem Event Log erfasst werden müssen
Technische Anleitung zur Datenextraktion

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

Vorlage herunterladen

Problem Management Attribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihren Event Log aufnehmen sollten, für eine umfassende Analyse Ihres Problem Management Lebenszyklus.

5 Erforderlich 5 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die spezifische Aktion oder Statusänderung, die für die Problemmeldung aufgetreten ist.
Beschreibung Dieses Attribut erfasst den Namen des Ereignisses oder Statusübergangs, der innerhalb des Problem Management Lebenszyklus auftritt. Beispiele sind 'Problem erfasst', 'Status auf Untersuchung geändert' oder 'Ursache identifiziert'. Es ist essenziell für die Abbildung des Prozessflusses und die Identifizierung der Schrittfolge zur Lösung eines Problems. Im Process Mining bilden diese Aktivitäten die Knoten der Prozesskarte. Bedeutung Definiert die Schritte in der `process map` und ermöglicht die Analyse von Prozessvarianten. Datenquelle Jira `Changelog` (Verlauf) oder Issue Status `transitions` Beispiele Problemmeldung erstelltErmittlung gestartet`Root Cause` identifiziertWorkaround aktualisiertProblemmeldung geschlossen
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, wann die Daten extrahiert oder zuletzt aktualisiert wurden.
Beschreibung Gibt an, wann der `dataset` zuletzt mit der Live-Jira Service Management-Umgebung synchronisiert wurde. Dies stellt sicher, dass `analysts` die `freshness` der `data` verstehen. Es wird verwendet, um zu validieren, dass die Analyse den aktuellsten Status des Prozesses widerspiegelt und potenzielle `data latency issues` zu identifizieren. Bedeutung Stellt die `data freshness` sicher und hilft, den Analyseergebnissen zu vertrauen. Datenquelle ETL-Zeitstempel Beispiele 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Problemmeldung ProblemKey	Der eindeutige Bezeichner, der der Problemmeldung in Jira Service Management zugewiesen ist.
Beschreibung Dieses Attribut dient als zentraler Case-Bezeichner für die Process Mining Analyse. Es repräsentiert den eindeutigen Schlüssel (z.B. PM-1001), der von Jira Service Management generiert wird, wenn eine neue Problemmeldung erstellt wird. Es wird verwendet, um alle zugehörigen Aktivitäten, Statusänderungen und Aktualisierungen zu einer einzigen End-to-End-Prozessinstanz zusammenzufassen. Die Analyse dieses Attributs ermöglicht die Visualisierung des gesamten Lebenszyklus eines Problems von der ersten Erkennung über die Untersuchung bis zum endgültigen Abschluss. Bedeutung Es ist der fundamentale `key`, der erforderlich ist, um den `process flow` zu rekonstruieren und spezifische Problem `records` zu verfolgen. Datenquelle Issue `table`, `field` 'Key' oder 'Issue Key' Beispiele PM-1023PM-4099PRB-3321PM-5001
	Quellsystem SourceSystem	Der Name des Systems, aus dem die `data` stammen.
Beschreibung Identifiziert das Softwaresystem, aus dem die `process data` extrahiert wurde. In diesem `context` ist der `value` konsistent 'Jira Service Management'. Dieses `attribute` ist besonders nützlich in `multi-system environments`, um `data sources` zu unterscheiden, obwohl es für diese spezifische Ansicht primär als statischer Identifikator für die `data lineage` dient. Bedeutung Bietet Kontext für die Datenherkunft, insbesondere beim Zusammenführen mit anderen IT Service Management Daten. Datenquelle Hardcodiert oder Systemkonfiguration Beispiele `Jira Service Management``Jira Cloud`JSM-Prod
	Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut zeichnet den genauen Zeitpunkt einer Aktivität auf. Es wird verwendet, um Events chronologisch zu sequenzieren und Dauern zwischen Schritten zu berechnen. Genaue Timestamps sind entscheidend für die Berechnung von Zykluszeiten, wie der Zeit von 'Problem erfasst' bis 'Ursache identifiziert', und für die Analyse des Durchsatzes über die Zeit. Bedeutung Ermöglicht die Berechnung aller zeitbasierten `KPIs` und die korrekte Reihenfolge der `events`. Datenquelle Jira `Changelog` `created date` oder Issue `created date` Beispiele 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Benutzer UserKey	Der eindeutige Bezeichner oder Name des Benutzers, der die Aktivität durchgeführt hat.
Beschreibung Erfasst die Identität der Person oder des Systemkontos, die für die Ausführung der spezifischen `activity` verantwortlich ist. Dies könnte der 'Assignee' sein, der den `record` aktualisiert, oder der 'Author' einer Statusänderung. Diese `data` wird verwendet, um die `resource utilization` zu analysieren, Übergabe-`bottlenecks` zwischen Benutzern zu identifizieren und die Verantwortlichkeit innerhalb des `problem management` Prozesses sicherzustellen. Bedeutung Entscheidend für die Analyse von Übergaben, Aufgabentrennung und `resource workload`. Datenquelle Jira 'author'-`field` im `changelog` oder 'assignee'-`field` im `issue` Beispiele j.smithsystem_automationm.doe
	Priorität Priority	Das der Problemmeldung zugewiesene Kritikalitätsniveau.
Beschreibung Gibt die Dringlichkeit und den `impact` des Problems an, typischerweise von 'Niedrig' bis 'Kritisch' reichend. Dieses `field` wird verwendet, um die Analyse zu segmentieren und sicherzustellen, dass hochprioritäre Probleme innerhalb der `SLA` `targets` gelöst werden. Die Analyse dieses `attribute`s hilft im `Dashboard` 'SLA Compliance and Target Trends' zu überprüfen, ob kritische `business risks` korrekt priorisiert werden. Bedeutung Ermöglicht die Segmentierung der `process performance` nach geschäftlicher Kritikalität. Datenquelle Issue `field` 'Priorität' Beispiele HöchsteHochMittelNiedrig
	Problemzusammenfassung ProblemSummary	Die Kurzbeschreibung oder der Titel der Problemmeldung.
Beschreibung Enthält die Titelzusammenfassung des Problem-`record`s. Obwohl hauptsächlich `text-based`, bietet es `context` für `analysts`, die individuelle `cases` innerhalb des `Process Mining` `tool`s überprüfen. Es ermöglicht die `keyword search` und qualitative Analyse der Arten von Problemen, die protokolliert werden. Bedeutung Bietet einen menschenlesbaren Kontext für den Case-Bezeichner. Datenquelle Issue `field` 'Zusammenfassung' Beispiele Datenbankverbindungs-`timeout` in der Region EUE-Mail-`service latency spike`Auftragsbearbeitungswarteschlange steckt fest
	Ursachenkategorie RootCauseCategory	Die Klassifizierung der zugrunde liegenden Ursache des Problems.
Beschreibung Kategorisiert den technischen oder Prozessfehler, der das Problem verursacht hat, wie z.B. 'Software Bug', 'Human Error' oder 'Hardware Failure'. Dies ist oft ein `custom field` in Jira Service Management. Dieses `attribute` unterstützt das `Dashboard` zur 'Root Cause Category Distribution' (Verteilung der Grundursachenkategorien), wodurch strategische Entscheidungen darüber ermöglicht werden, wo in Infrastruktur oder Schulungen investiert werden sollte, um ein Wiederauftreten zu verhindern. Bedeutung Schlüssel zur Identifizierung systemischer `issues` und zur Lenkung präventiver Maßnahmen. Datenquelle Benutzerdefiniertes `field` 'Root Cause' oder 'Root Cause Category' Beispiele Software-BugKonfigurationsfehlerKapazitätsproblemAnbieterproblem
	Zugewiesene Supportgruppe SupportGroup	Das technische Team oder die Gruppe, die derzeit mit der Untersuchung des Problems beauftragt ist.
Beschreibung Identifiziert das spezifische Team, das für den Problem-`record` zum Zeitpunkt des `event`s verantwortlich ist. In Jira Service Management wird dies oft 'Komponente' oder einem `custom field` wie 'Support Group' zugeordnet. Dieses `attribute` ist entscheidend für das `Dashboard` 'Support Group Handover Bottlenecks', das `analysts` ermöglicht zu visualisieren, wie Probleme zwischen Teams wechseln und wo sie am längsten verweilen. Bedeutung Wichtig für organisatorisches `mining` und die Identifizierung von Reibungspunkten zwischen Teams. Datenquelle Issue `field` 'Komponente' oder `custom field` 'Support Group' Beispiele DatenbankverwaltungNetwork OpsApplication Support Level 2
	Anzahl verknüpfter Incidents LinkedIncidentCount	Die Anzahl der Vorfälle, die mit dieser Problemmeldung verknüpft sind.
Beschreibung Eine Anzahl von `incident tickets`, die dem Problem `record` zugeordnet sind. Dieses `attribute` quantifiziert die Auswirkungen des Problems auf die Nutzerbasis. Es wird im 'Incident to Problem Linkage Depth' `KPI` verwendet, um Probleme zu priorisieren, die das höchste Volumen an Support-`tickets` generieren. Bedeutung Quantifiziert den geschäftlichen Einfluss basierend auf dem Vorfallsvolumen. Datenquelle Anzahl der `links` in der Tabelle 'issuelinks', wobei der `type` 'Problem/Incident' ist Beispiele 011550
	Behebungscode ResolutionCode	Der Code, der angibt, wie das Problem gelöst wurde.
Beschreibung Gibt das Endergebnis der Problemmeldung an, wie 'Behoben', 'Wird nicht behoben', 'Duplikat' oder 'Nicht reproduzierbar'. Dies wird verwendet, um erfolgreich gelöste Probleme von solchen zu filtern, die aus administrativen Gründen geschlossen wurden, wodurch sichergestellt wird, dass KPI-Berechnungen wie die 'Mittlere Zeit bis zur Ursache' korrekt sind. Bedeutung Unterscheidet zwischen effektiven Lösungen und administrativen Abschlüssen. Datenquelle Issue `field` 'Lösung' Beispiele ErledigtWird nicht gemachtDuplikatNicht reproduzierbar
	Erkennungsquelle DetectionSource	Wie das Problem identifiziert wurde (z.B. Proaktiv, Reaktiv).
Beschreibung Gibt den Ursprung der Problemidentifikation an. Häufige `values` sind 'Proactive Monitoring', 'Service Desk Incident' oder 'Vendor Notification'. Dieses `attribute` wird im `Dashboard` 'Proactive vs Reactive Identification' verwendet, um die Reife des `problem management` Prozesses zu messen. Bedeutung Misst die `process maturity` und die Wirksamkeit von `monitoring systems`. Datenquelle Benutzerdefiniertes `field` 'Source' oder 'Detection Source' Beispiele Proaktives MonitoringIncident-EskalationLieferantenbenachrichtigung
	Erstellungsdatum CreatedDate	Das Datum, an dem die Problemmeldung erstellt wurde.
Beschreibung Der Timestamp, wann das Problem erstmals im System erfasst wurde. Während der Event Timestamp das Timing von Aktivitäten handhabt, wird dieses spezifische Attribut oft für die Filterung auf hoher Ebene verwendet (z.B. 'Zeige mir alle im Q1 erstellten Probleme'). Es dient als Ankerpunkt für die Alterungsanalyse. Bedeutung Referenzdatum für Alters- und Erfassungsvolumenanalyse. Datenquelle Issue `field` 'Erstellt' Beispiele 2023-01-012023-06-15
	Melder ReporterName	Der Benutzer, der die Problemmeldung ursprünglich erfasst hat.
Beschreibung Identifiziert die Person, die den Problem-`record` erstellt hat. Dies unterscheidet sich vom Bearbeiter. Die Analyse der `reporters` hilft zu verstehen, wo Probleme erkannt werden (z.B. `Service Desk Agents` vs. `System Admins`). Dies fügt der 'Proactive vs Reactive'-Analyse `context` hinzu. Bedeutung Identifiziert die Quelle der Problemerfassung. Datenquelle Issue `field` 'Reporter' Beispiele monitoring_servicehelpdesk_leadnetwork_admin
	PIR durchgeführt ReviewStatus	Gibt an, ob eine Post-Implementierungs-Überprüfung (`PIR`) durchgeführt wurde.
Beschreibung Verfolgt, ob die Aktivität oder das Kennzeichen 'Überprüfung nach der Implementierung' im Fall vorhanden ist. Dies ist entscheidend für das Dashboard 'Compliance der Überprüfung nach der Implementierung'. Es stellt sicher, dass die Organisation die Governance-Anforderungen für kontinuierliche Verbesserung einhält. Bedeutung Compliance-Metrik für organisatorisches Lernen. Datenquelle Benutzerdefiniertes `field` 'PIR Status' oder Existenz der 'PIR'-`activity` Beispiele AbgeschlossenPendingNicht erforderlich
	SLA-Verletzungsstatus SlaBreachStatus	Gibt an, ob der Problem-`record` seine `service level agreement` verletzt hat.
Beschreibung Ein `boolean` oder `status field`, das angibt, ob die Lösungszeit das vereinbarte Ziel überschritten hat. Dies hilft im `Dashboard` für 'SLA Compliance und Target Trends'. Es hebt `cases` hervor, die das Unternehmen `compliance`-Risiken oder Strafen aussetzen. Bedeutung Entscheidend für `compliance` und `performance monitoring`. Datenquelle Jira Service Management `SLA` `field logic` Beispiele ErfülltVerletztPausiert
	Untersuchungsdauer InvestigationDuration	Benötigte Zeit von der Problemerfassung bis zur Ursachenidentifikation.
Beschreibung Berechnet die Dauer zwischen der Erstellung des Problem-`record`s und dem `timestamp` der `activity` 'Root Cause Identified' (Grundursache identifiziert). Dies ist die primäre Metrik für das `Dashboard` zur 'Investigation Cycle Time Analysis' (Analyse der Untersuchungszykluszeit). Es hilft Managern, komplexe Probleme zu identifizieren, die das Team aufgehalten haben, oder einen `resource`nmangel in der Diagnosephase aufzudecken. Bedeutung Primäre Kennzahl für die Effizienz der Phase der Ursachenanalyse. Datenquelle Berechnet aus `event` `timestamps` Beispiele 48 Stunden5 Tage30 Minuten
	Verknüpfter `Change Request` LinkedChangeRequest	Der Bezeichner der Änderungsanfrage, die mit diesem Problem verknüpft ist.
Beschreibung Speichert die ID der Änderungsanfrage (RFC), die zur Implementierung der dauerhaften Lösung erstellt wurde. Diese Verknüpfung ist entscheidend für das Dashboard 'Verzögerung bei der Initiierung von Änderungsanfragen'. Sie verbindet den Problem Management Prozess mit dem Change Management und ermöglicht eine prozessübergreifende Analyse. Bedeutung Verbindet Untersuchung mit der Behebung im `Change Management` Prozess. Datenquelle Issue `links`, wobei der `type` 'behoben durch' oder ähnlich ist Beispiele CR-404CHG-1099CR-5512
	Wiedereröffnet IsReopened	`Flag`, das anzeigt, ob das Problem nach dem Abschluss wiedereröffnet wurde.
Beschreibung Ein `boolean flag`, das auf `true` gesetzt wird, wenn der Problem `record` von einem geschlossenen Zustand zurück in einen offenen Zustand übergeht. Dies unterstützt die 'Problem Reopened Rate Analysis' (Analyse der Wiedereröffnungsrate von Problemen). Hohe Wiedereröffnungsraten deuten auf Qualitätsprobleme bei den dauerhaften Lösungen oder unzureichende Verifizierungsverfahren hin. Bedeutung Qualitätsindikator für die Wirksamkeit von Lösungen. Datenquelle Abgeleitet aus `status transitions` Beispiele truefalsch
	Workaround verfügbar WorkaroundDetails	Gibt an, ob ein `workaround` für das Problem dokumentiert wurde.
Beschreibung Erfasst, ob ein temporärer `workaround` `text` existiert oder veröffentlicht wurde. Dies ermöglicht der Organisation, die 'Workaround Publication Speed' (Veröffentlichungsgeschwindigkeit von `workarounds`) zu verfolgen. Die Analyse dieses Feldes hilft zu bestimmen, wie schnell das Team die `service stability` wiederherstellen kann, noch bevor eine dauerhafte Lösung gefunden wird. Bedeutung Schlüssel zur Messung der Geschwindigkeit der Interimshilfe für das `business`. Datenquelle Benutzerdefiniertes `field` 'Workaround' Beispiele Dienst neu startenBrowser-Cache leerenKeine Angabe

Erforderlich Empfohlen Optional

Problem Management Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die in Ihrem Event Log erfasst werden müssen, für eine genaue Erkennung Ihrer Lösungs-Workflows.

8 Empfohlen 6 Optional

	Aktivität	Beschreibung
	`Root Cause` identifiziert	Der Punkt, an dem die zugrunde liegende Ursache formell erfasst wird. Dies wird aus einer Statusänderung zu 'Ursache identifiziert' oder der Befüllung des Feldes 'Ursache' abgeleitet.
Bedeutung Ein wichtiger Meilenstein, der die Untersuchungsphase beendet. Unerlässlich für die Berechnung der 'Mean Time to Root Cause Discovery' (Mittlere Zeit bis zur Entdeckung der Grundursache). Datenquelle Jira Issue Verlauf: Status geändert zu 'Root Cause Identified' ODER `Field` 'Root Cause' befüllt Erfassen Statusfeld vergleichen oder auf Feldbefüllung prüfen Ereignistyp inferred
	Auflösung verifiziert	Die Bestätigung, dass die Lösung das Problem effektiv behoben hat. Abgeleitet aus einem Statusübergang zu 'Gelöst' oder einem spezifischen 'Verifiziert'-Status.
Bedeutung Qualitäts-Gate, das sicherstellt, dass die Lösung funktioniert. Verzögerungen hier deuten auf Engpässe im Test oder bei der Benutzerakzeptanz hin. Datenquelle Jira Issue Verlauf: Status geändert zu 'Resolved' oder 'Verified' Erfassen Statusfeld-`updates` vergleichen Ereignistyp inferred
	Ermittlung gestartet	Der Übergang des Problemstatus in einen aktiven Untersuchungsstatus (z.B. 'In Untersuchung' oder 'In Bearbeitung'). Dies kennzeichnet den Beginn der aktiven Arbeitsphase.
Bedeutung Startet die Zeiterfassung für die Untersuchungszykluszeit. Hilft, zwischen Backlog-Wartezeit und tatsächlicher aktiver Analyse zu unterscheiden. Datenquelle Jira Issue Verlauf: Status geändert zu 'Under Investigation' oder 'In Progress' Erfassen Statusfeld-`updates` vergleichen Ereignistyp inferred
	Incident mit Problem verknüpft	Die Aktion, ein zugehöriges Incident-Ticket mit der Problemmeldung zu verknüpfen. Dies wird in der Tabelle oder Historie der Ticket-Verknüpfungen erfasst.
Bedeutung Bestimmt den `impact` und Umfang des Problems. Unerlässlich für den 'Incident to Problem Linkage Depth' `KPI` und die Priorisierung basierend auf dem Geschäftseinfluss. Datenquelle Jira Issue `Links`: `Link` erstellt mit `type` 'causes' oder 'relates to' Erfassen Protokolliert, wenn ein `issue link` erstellt wird Ereignistyp explicit
	Problemmeldung erstellt	Das initiale Event, bei dem das Problem-Ticket im System erstellt wird. Dies wird in der Ticket-Historie explizit als Erstellungs-Timestamp erfasst.
Bedeutung Markiert den Beginn des Problem `Management lifecycle`s und ermöglicht eine `volume analysis`. Unerlässlich für die Berechnung von `throughput` und Erfassungsraten. Datenquelle Jira Issue `Table`: `Created Date` `timestamp` oder History `Tab`: Issue Created `event` Erfassen Protokolliert, wenn die `issue creation transaction` durchgeführt wird Ereignistyp explicit
	Problemmeldung geschlossen	Die endgültige Beendigung des Problemlösungslebenszyklus. Explizit erfasst, wenn sich der Status in 'Geschlossen' ändert.
Bedeutung Das definitive Ende der Prozessinstanz. Notwendig zur Berechnung der gesamten Zykluszeit und Abschlussquoten. Datenquelle Jira Issue Verlauf: Status geändert zu 'Closed' Erfassen Protokolliert, wenn der Status auf `Closed` wechselt Ereignistyp explicit
	Supportgruppe zugewiesen	Die Zuweisung der Problemmeldung an ein spezifisches technisches Team oder eine Support-Gruppe. Dies wird über Änderungen am benutzerdefinierten Feld 'Support Group' oder dem Feld 'Assignee' verfolgt, falls keine Gruppen verwendet werden.
Bedeutung Entscheidend für die Analyse von Übergaben und `bottlenecks` zwischen Teams. Hohe Übergaberaten können auf `routing inefficiencies` hindeuten. Datenquelle Jira Issue Verlauf: `Field` 'Support Group' oder 'Assignee' geändert Erfassen Protokolliert, wenn sich das `assignment field` ändert Ereignistyp explicit
	Workaround aktualisiert	Die Befüllung oder Aktualisierung des Textfeldes 'Workaround'. Dieses Event zeigt an, dass eine temporäre Lösung dokumentiert wurde.
Bedeutung Misst die Geschwindigkeit, mit der dem `business` Abhilfe geschaffen wird. Kritisch für den 'Workaround Availability Lead Time' `KPI`. Datenquelle Jira Issue Verlauf: `Field` 'Workaround' geändert (nicht `null`) Erfassen Protokolliert, wenn das `Workaround field` modifiziert wird Ereignistyp explicit
	Change Request verknüpft	Die Verknüpfung einer Änderungsanfrage (RFC) mit der Problemmeldung. Dies kennzeichnet die Initiierung des Prozesses für eine dauerhafte Lösung.
Bedeutung Misst die Verzögerung zwischen der Identifizierung der Ursache und dem Beginn der Behebung. Unterstützt den 'Change Management Transition Delay' `KPI`. Datenquelle Jira Issue `Links`: `Link` erstellt mit `type` 'is fixed by' oder Verknüpfung zu 'Change' `issue type` Erfassen Protokolliert, wenn ein `link` zu einem `Change issue type` erstellt wird Ereignistyp explicit
	Dauerhafte Lösung angewendet	Der Übergang, der anzeigt, dass die Lösung implementiert wurde. Dies wird normalerweise aus einer Statusänderung zu 'Wird implementiert' oder 'Behoben' abgeleitet.
Bedeutung Markiert das Ende der technischen Behebungsarbeiten. Wird verwendet, um die Implementierungs-`cycle time` zu messen. Datenquelle Jira Issue Verlauf: Status geändert zu 'Implemented', 'Pending Verification' oder 'Fixed' Erfassen Statusfeld-`updates` vergleichen Ereignistyp inferred
	Problem wiedereröffnet	Der Übergang eines Problems von einem 'Gelöst'- oder 'Geschlossen'-Status zurück zu einem aktiven Status. Deutet auf eine fehlgeschlagene Behebung oder abgelehnte Lösung hin.
Bedeutung Eine wichtige Qualitätsmetrik. Hohe Wiedereröffnungsraten deuten auf eine ineffektive Grundursachenanalyse oder Tests hin. Datenquelle Jira Issue Verlauf: Status geändert von 'Closed'/'Resolved' zu 'Open'/'In Progress' Erfassen Statusfeld-Sequenz vergleichen Ereignistyp inferred
	Problem-Priorität geändert	Eine Aktualisierung des `Priority field`s des Problem `record`s. Dies wird durch die Überwachung des `history tab`s auf Änderungen am Feld 'Priorität' erfasst.
Bedeutung Zeigt Eskalation oder Deeskalation des `issue`s an. Die Analyse dessen hilft, die anfängliche `triage accuracy` und das Altern hochprioritärer `backlogs` zu identifizieren. Datenquelle Jira Issue Verlauf: `Field` 'Priorität' geändert von `Old Value` zu `New Value` Erfassen Protokolliert, wenn das `Priority field` `updated` wird Ereignistyp explicit
	SLA verletzt	Ein `event`, das anzeigt, dass die Problem-Lösungszeit die definierte `Service Level Agreement` überschritten hat. Dies wird durch den Vergleich des `SLA` `target date`s mit dem Lösungsdatum berechnet.
Bedeutung Entscheidend für `compliance reporting`. Hilft zu identifizieren, welche Prioritäten oder `categories` am häufigsten Ziele verfehlen. Datenquelle Jira Service Management `SLA Logs`: 'Time to Resolution' > `Target`, oder berechnet Erfassen Ableiten aus `SLA` `field data` oder `Due Date` mit `Resolution Date` vergleichen Ereignistyp calculated
	Überprüfung nach der Implementierung	Die Durchführung einer Überprüfung, nachdem die Lösung angewendet wurde. Erfasst über eine Statusänderung zu 'In Überprüfung' oder Aktualisierungen PIR-spezifischer Felder.
Bedeutung Eine `compliance activity`, die sicherstellt, dass gewonnene Erkenntnisse erfasst werden. Unterstützt die 'Post Implementation Review Compliance'-Analyse. Datenquelle Jira Issue Verlauf: Status geändert zu 'In Review' ODER `Field` 'PIR Notes' `updated` Erfassen Statusfeld oder PIR-Feld-`updates` vergleichen Ereignistyp inferred

Extraktionsleitfäden

So erhalten Sie Ihre Daten aus `Jira Service Management`

Schritte

Melden Sie sich in Ihrer Jira Service Management-Instanz über einen web browser mit einem Konto an, das über 'Browse Projects'-Berechtigungen für das Problem Management Projekt verfügt.
Navigieren Sie zur oberen Menüleiste und wählen Sie Filters, klicken Sie dann auf Advanced Issue Search, um den Issue Navigator zu öffnen.
Wechseln Sie den Suchmodus auf JQL (Jira Query Language) anstatt Basic, falls noch nicht ausgewählt.
Geben Sie die spezifische JQL query string ein, die im Abschnitt Query unten bereitgestellt wird, um Problem records zu isolieren (z.B. project = 'Problem Management'). Stellen Sie sicher, dass der time range für die Exportgrenzen des Systems geeignet ist.
Klicken Sie auf den Search button, um zu überprüfen, ob die Liste der issues die erwarteten Problem records zurückgibt.
Suchen Sie den Export button in der oberen rechten Ecke der issue navigator interface.
Wählen Sie Export XML aus dem dropdown menu. Wählen Sie nicht CSV, da der Standard-CSV export nur aktuelle state data bereitstellt und die für Process Mining erforderlichen historischen change logs fehlen.
Speichern Sie die generierte XML file (z.B. jira_export.xml) in einem lokalen Verzeichnis, das von Ihrer processing environment zugänglich ist.
Bereiten Sie die Python-Umgebung vor, indem Sie die erforderliche Bibliothek pandas installieren, falls nicht bereits vorhanden.
Führen Sie das im Abschnitt Query bereitgestellte Python-Skript aus und stellen Sie sicher, dass die file path variable mit dem Speicherort Ihrer gespeicherten XML file übereinstimmt.
Das Skript parses die RSS/XML structure, extrahiert den 'Created' timestamp, 'History'-Einträge für Status-/Prioritäts-/Zuweisungsänderungen und Issue Links für verwandte Incidents.
Das Skript berechnet SLA breaches, indem es Lösungsdaten mit Fälligkeitsdaten vergleicht, und gibt ein formatiertes CSV event log aus, das für ProcessMind bereit ist.

Konfiguration

Export Format: Es muss der XML-(RSS)-Export verwendet werden, nicht CSV. Das XML-Format enthält die <history>- und <issuelinks>-Tags, die für die Rekonstruktion des Prozessflusses unerlässlich sind.
Row Limit: Jira-Standardexporte sind oft auf 1.000 issues pro Export begrenzt. Für größere datasets müssen Sie die Extraktion durch Anpassung des JQL date range (z.B. created >= '2023-01-01' AND created < '2023-02-01') und Durchführung mehrerer Exporte paginaten.
JQL Filter: Stellen Sie sicher, dass der project-Schlüssel mit Ihrem spezifischen Problem Management Projektidentifikator (z.B. PROB, PM) übereinstimmt.
System Timezone: Verifizieren Sie, dass das Benutzerprofil, das den Export durchführt, der System-timezone entspricht, um die timestamp-Konsistenz zu gewährleisten.
Field Permissions: Der Benutzer muss die Berechtigung haben, die Change History und Linked Issues anzuzeigen, um transitions und Incident links zu erfassen.
Custom Fields: Wenn 'Root Cause' oder 'Workaround' custom fields sind, stellen Sie sicher, dass die Feldnamen-Abgleichlogik des Skripts mit den spezifischen Feldnamen in Ihrer Jira-Instanz übereinstimmt.

a Beispielabfrage config

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 einrichten: Stellen Sie sicher, dass Python 3.x zusammen mit den Bibliotheken requests und pandas installiert ist. Sie benötigen ein Jira Service Management-Konto mit Leseberechtigungen für das entsprechende Projekt. Für Jira Cloud generieren Sie einen API Token über Ihre Atlassian Account-Einstellungen. Für Data Center generieren Sie einen Personal Access Token (PAT).
Benutzerdefinierte Feld-IDs identifizieren: Jira Service Management verwendet dynamische IDs für custom fields (z.B. customfield_10012 für Supportgruppe oder SLA). Bevor Sie die Haupt-Extraktion ausführen, verwenden Sie einen browser oder Postman, um ein spezifisches Problem issue (/rest/api/2/issue/[ISSUE-KEY]) abzufragen und die spezifischen Feld-IDs für 'Support Group', 'Workaround', 'Root Cause' und Ihre SLA-Felder zu identifizieren.
Das Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript und aktualisieren Sie das CONFIG dictionary. Ersetzen Sie die URL, die Benutzer-E-Mail und den API Token. Aktualisieren Sie das FIELD_MAPPING dictionary mit den tatsächlichen custom field Namen oder IDs, die Sie in Schritt 2 identifiziert haben. Aktualisieren Sie die JQL_QUERY, um Ihr spezifisches Projekt anzusprechen (z.B. project = PM AND issuetype = Problem).
Statuszuordnungen definieren: Ordnen Sie im STATUS_MAPPING dictionary innerhalb des Skripts Ihre spezifischen Jira-workflow-Stati (z.B. 'Under Investigation', 'Implementing', 'Resolved') den Standard-ProcessMind activity names (z.B. 'Investigation Started', 'Permanent Fix Applied') zu.
Die 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 Zustand und die vollständige Historie jeder Feldänderung abzurufen.
Verarbeitungslogik: Das Skript iteriert durch jedes issue. Es erstellt zuerst ein 'Problem Record Created' event aus dem Erstellungs-timestamp. Anschließend parses es die changelog history. Für jedes Historien-item prüft es, ob das geänderte Feld mit unserer Interessensliste (Status, Priorität, Link, etc.) übereinstimmt und generiert eine entsprechende event row.
SLA-Behandlung: Das Skript versucht, SLA breaches zu identifizieren, indem es nach Änderungen in SLA-bezogenen custom fields oder status transitions sucht, die explizit 'Breached' genannt werden. Passen Sie die Logik in der Funktion _parse_sla_breach an, wenn Ihr System eine spezifische automation zur Kennzeichnung von breaches verwendet.
Datenumwandlung: Das Skript flattens die verschachtelte JSON structure in ein tabellarisches Pandas DataFrame. Timestamps werden in das ISO 8601 format konvertiert.
Exportieren: Der endgültige Datensatz wird in eine CSV file mit dem Namen jira_problem_event_log.csv exportiert. Öffnen Sie diese file, um zu überprüfen, ob die Spaltenüberschriften den ProcessMind-Anforderungen entsprechen.
In ProcessMind hochladen: Importieren Sie die CSV file in ProcessMind. Ordnen Sie ProblemKey als Case ID, ActivityName als Activity und EventTimestamp als Timestamp zu.

Konfiguration

API Endpoint: Verwendet /rest/api/2/search (kompatibel mit Cloud und den meisten Data Center-Versionen). API v3 wird ebenfalls unterstützt, aber v2 ist generell sicherer für eine breite Kompatibilität.
Pagination: Das Skript implementiert Pagination mittels startAt und maxResults, um große datamengen effizient zu verarbeiten. Die Standard-Batch-Größe ist auf 50 eingestellt.
Changelog Expansion: Der Parameter expand=changelog ist kritisch. Ohne diesen wird nur der aktuelle Zustand zurückgegeben, und die Historie/der process flow gehen verloren.
JQL Filtering: Die Abfrage filtert nach issuetype = Problem. Es wird dringend empfohlen, einen Datumsbereichsfilter (z.B. created >= -180d) hinzuzufügen, um das datavolumen während der ersten Tests zu begrenzen.
Authentication: Unterstützt Basic Auth (Email + Token) für Cloud. Für Data Center müssen die Header zur Verwendung von Bearer tokens angepasst werden.
Field Mapping: Kritische Konfiguration erforderlich. Die internen Jira-Feldnamen für 'Status' und 'Priorität' sind Standard, aber 'Support Group', 'Root Cause' und SLA sind fast immer benutzerdefinierte Felder mit eindeutigen IDs (z.B. 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}")

Ihre Problem Management Datenvorlage

Ihre Problem Management Datenvorlage

Problem Management Attribute

Problem Management Aktivitäten

Extraktionsleitfäden

Jira Service Management `Issue Navigator Export`

Schritte

Konfiguration

a Beispielabfrage config

Python-Extraktion über die Jira REST API mit Changelog

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Optimieren Sie Ihren Problem Management Ablauf noch heute

Ihre Problem Management Datenvorlage

Ihre Problem Management Datenvorlage

Problem Management Attribute

Problem Management Aktivitäten

Extraktionsleitfäden

Jira Service Management `Issue Navigator Export`

Schritte

Konfiguration

a Beispielabfrage config

Python-Extraktion über die Jira REST API mit Changelog

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Optimieren Sie Ihren Problem Management Ablauf noch heute