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

Ihr Daten-Template für das Serviceanfragemanagement

Jira Service Management

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Serviceanfragemanagements(17) Aktivitäten im Serviceanfragemanagement(13) Anleitungen zur Datenextraktion(3)

Ihr Daten-Template für das Serviceanfragemanagement

Dieses Template bietet eine strukturierte Anleitung, um die wesentlichen Daten für die Analyse Ihrer Serviceanfrageprozesse zusammenzustellen. Es beschreibt, welche wichtigen Attribute Sie erfassen und welche zentralen Aktivitäten Sie verfolgen sollten. Außerdem erfahren Sie, wie Sie diese Informationen aus Ihrem System extrahieren. Mit dieser Ressource bereiten Sie Ihre Daten effizienter vor und gewinnen tiefere Erkenntnisse über Ihre Abläufe.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Aktivitäten für die Prozesserkennung
Anleitung zur Datenextraktion aus Jira Service Management

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

Template herunterladen

Attribute des Serviceanfragemanagements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um das Serviceanfragemanagement umfassend zu analysieren.

5 Erforderlich 5 Empfohlen 7 Optional

	Name	Beschreibung
	Aktivität ActivityName	Name des konkreten Ereignisses oder der Aufgabe im Lebenszyklus der Serviceanfrage.
Beschreibung Dieses Attribut beschreibt die konkrete Aktion oder Statusänderung, die zu einem bestimmten Zeitpunkt bei einer Serviceanfrage stattgefunden hat. Beispiele sind „Anfrage erstellt“, „Anfrage zugewiesen“, „Lösung umgesetzt“ und „Anfrage geschlossen“. Die Abfolge und Häufigkeit dieser Aktivitäten zu analysieren, ist der Kern des Process Mining. So lassen sich Prozessabläufe visualisieren, Engpässe erkennen und Abweichungen vom Standard-Workflow aufdecken. Das ist entscheidend, um Prozesseffizienz und Compliance zu beurteilen. Warum das wichtig ist Es legt die Prozessschritte fest und ermöglicht die Visualisierung des Prozessablaufs sowie die Analyse von Workflow-Mustern und Abweichungen. Woher beziehen Wird üblicherweise aus dem Verlauf der „status“-Änderungen eines Jira-Vorgangs abgeleitet. Jeder Eintrag im Änderungsprotokoll des Vorgangs für das Statusfeld entspricht einer Aktivität. Beispiele Anfrage triagiertInformationen angefordertLösung umgesetztServiceanfrage geschlossen
	Serviceanfrage-ID ServiceRequestId	Eindeutige Kennung jeder Serviceanfrage, die als Primärschlüssel für alle zugehörigen Ereignisse dient.
Beschreibung Die Serviceanfrage-ID, in Jira häufig als Issue Key bezeichnet, identifiziert jede einzelne Anfrage, die ein Benutzer oder System eingereicht hat. Sie bildet den zentralen Bezugspunkt für alle nachfolgenden Ereignisse, von der ersten Erfassung bis zum endgültigen Abschluss. So lässt sich der gesamte Verlauf jeder Serviceanfrage analysieren. Beim Process Mining ist diese ID für die Zuordnung von Cases unverzichtbar. Sie stellt sicher, dass jede Aktivität, Statusänderung und jeder Timestamp der richtigen Anfrage zugeordnet wird. Dadurch entsteht eine zusammenhängende Prozessinstanz, die sich analysieren lässt. Warum das wichtig ist Diese ID ist die grundlegende Case-ID. Sie führt alle zugehörigen Aktivitäten in einem durchgängigen Prozessablauf zusammen und ermöglicht so die Prozessanalyse. Woher beziehen Dies ist das Feld „key“ eines Vorgangs in Jira Service Management. Beispiele SR-2023-001IT-45892HELP-105
	Startzeit EventTime	Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Startzeit, auch Ereignis-Timestamp genannt, hält den genauen Zeitpunkt einer Aktivität fest. Sie ist eine zentrale Grundlage jeder Process-Mining-Analyse, da sie den zeitlichen Kontext des gesamten Prozesses liefert. Anhand dieses Timestamps lassen sich Ereignisse chronologisch ordnen, Zeitspannen zwischen Aktivitäten und die Zykluszeit eines gesamten Cases berechnen sowie die Prozessleistung anhand zeitgebundener Ziele wie SLAs bewerten. Ohne genaue Timestamps lassen sich weder Prozessabläufe nachvollziehen noch Verzögerungen erkennen oder Effizienz messen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, Zeitspannen und Zykluszeiten zu berechnen und Prozessengpässe zu erkennen. Woher beziehen Dies ist der Timestamp der jeweiligen Statusänderung im Änderungsprotokoll des Jira-Vorgangs. Der Erstellungszeitpunkt des Vorgangs steht im Feld „created“. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion aus Jira Service Management. Es liefert wichtigen Kontext zur Aktualität der Analyse und der in Dashboards und Kennzahlen enthaltenen Daten. Für fundierte Entscheidungen ist es wichtig zu wissen, wie aktuell die Daten sind. Anhand dieses Timestamps erkennen Benutzer, ob sie Echtzeitinformationen oder einen Datenstand von einem früheren Zeitpunkt betrachten. Das beeinflusst, wie relevant die Erkenntnisse sind. Warum das wichtig ist Zeigt an, wie aktuell die Daten sind, und stellt sicher, dass Analysen auf dem neuesten Informationsstand beruhen. Woher beziehen Dieses Metadatenfeld wird vom Datenextraktionstool oder Skript am Ende der Ausführung erstellt und gespeichert. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten der Serviceanfrage extrahiert wurden.
Beschreibung Dieses Attribut gibt an, woher die Daten stammen, in diesem Fall aus Jira Service Management. Bei Daten aus nur einer Quelle mag das nebensächlich erscheinen. Sobald Prozessdaten aus mehreren Systemen zusammengeführt werden, ist die Angabe jedoch entscheidend. Sie hilft dabei, die Datenherkunft nachzuvollziehen und die Datenqualität sicherzustellen. Außerdem können Sie damit Prozesse filtern und vergleichen, die sich über verschiedene Softwareplattformen erstrecken oder mit ihnen interagieren. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance und beim Zusammenführen von Prozessdaten aus mehreren Unternehmenssystemen. Woher beziehen Dies ist in der Regel ein statischer Wert, der bei der Datenextraktion und -transformation ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Jira Service ManagementJiraSM
	Anfragetyp RequestType	Die Klassifizierung der Serviceanfrage, zum Beispiel „Zugriffsanfrage“ oder „Hardwareproblem“.
Beschreibung Der Anfragetyp ordnet eine Serviceanfrage nach ihrer Art ein. Diese Dimension ist eine wichtige Grundlage der Analyse, da für verschiedene Anfragetypen oft unterschiedliche Lösungsprozesse, SLAs und Ressourcen erforderlich sind. Wenn Unternehmen die Prozessanalyse nach Anfragetyp aufschlüsseln, können sie Verbesserungen gezielt auf bestimmte Workflows abstimmen. Der Engpass bei einer Anfrage zum Zurücksetzen eines Passworts unterscheidet sich beispielsweise deutlich von dem bei der Bereitstellung eines neuen Servers. Dieses Attribut ist wichtig für aussagekräftige Dashboards wie „Lösungsqualität nach Kategorie“. Warum das wichtig ist Dieses Attribut ist entscheidend, um Prozesse, Arbeitsaufkommen und Leistung für verschiedene Kategorien von Serviceanfragen zu vergleichen. Woher beziehen Entspricht häufig dem Feld „issuetype“ in Jira oder einem benutzerdefinierten Feld „Request Type“ in Jira Service Management. Beispiele Neues Konto anfordernIT-Support anfordernNeuen Mitarbeiter einarbeiten
	Priorität der Anfrage RequestPriority	Die Prioritätsstufe der Serviceanfrage, zum Beispiel niedrig, mittel, hoch oder kritisch.
Beschreibung Die Priorität der Anfrage gibt an, wie dringend sie ist und welche geschäftlichen Auswirkungen sie hat. Diese Einstufung bestimmt die Reihenfolge der Bearbeitung und legt häufig die angestrebten Lösungszeiten und SLAs fest. Bei der Prozessanalyse ist die Priorität eine wichtige Dimension für die Segmentierung. So lassen sich Zykluszeiten und SLA-Einhaltung für verschiedene Prioritätsstufen vergleichen. Dadurch können Sie prüfen, ob Anfragen mit hoher Priorität tatsächlich schneller bearbeitet werden und ihre Zielvorgaben erfüllen. Das zeigt, wie wirksam die Priorisierung ist. Warum das wichtig ist Ermöglicht eine segmentierte Analyse, mit der Sie prüfen können, ob Anfragen mit hoher Priorität schneller bearbeitet werden und strengere Serviceziele erfüllen. Woher beziehen Entspricht dem Feld „priority“ eines Jira-Vorgangs. Beispiele HöchsteHochMittelNiedrig
	SLA-Fälligkeitsdatum SlaDueDate	Das Zieldatum und die Zieluhrzeit, bis zu denen die Serviceanfrage gemäß SLA gelöst sein soll.
Beschreibung Das SLA-Fälligkeitsdatum ist ein berechneter Timestamp, der die Frist für die Lösung einer Anfrage angibt. Es richtet sich nach Priorität und Typ der Anfrage sowie den in Jira Service Management festgelegten Service-Level-Agreement-Richtlinien (SLA). Dieses Attribut ist eine wichtige Grundlage für das Dashboard „SLA-Leistung bei Serviceanfragen“ und die Kennzahl „SLA-Einhaltungsquote“. Durch den Vergleich der tatsächlichen Lösungszeit mit dem Fälligkeitsdatum lässt sich feststellen, ob eine Anfrage fristgerecht oder verspätet abgeschlossen wurde oder ob ein SLA-Verstoß droht. Warum das wichtig ist Dient als Maßstab für die Leistung. Das Attribut unterstützt direkt die Berechnung der SLA-Einhaltung und hilft bei der Priorisierung der Arbeit. Woher beziehen Jira Service Management verwaltet die SLA-Informationen. Sie sind über die API zugänglich und werden häufig in benutzerdefinierten Feldern gespeichert, die dynamisch aktualisiert werden. Beispiele 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Status der Anfrage RequestStatus	Der aktuelle Status der Serviceanfrage in ihrem Lebenszyklus.
Beschreibung Dieses Attribut gibt den aktuellen Status einer Serviceanfrage an, zum Beispiel „Open“, „In Progress“, „Waiting for Customer“ oder „Resolved“. Es zeigt, an welchem Punkt sich die Anfrage gerade befindet. Das Aktivitätsprotokoll bildet den bisherigen Verlauf ab. Der aktuelle Status eignet sich dagegen, um offene Arbeitsbestände zu analysieren und festgefahrene Anfragen zu erkennen. So können Sie beispielsweise Anfragen untersuchen, die ungewöhnlich lange den Status „Waiting for Vendor“ haben. Dadurch werden externe Abhängigkeiten und Verzögerungen sichtbar. Warum das wichtig ist Zeigt den aktuellen Stand jedes Cases und ermöglicht die Analyse laufender Arbeit sowie das Erkennen festgefahrener oder überfälliger Anfragen. Woher beziehen Dies ist das Feld „status“ eines Jira-Vorgangs. Beispiele OffenIn BearbeitungWarten auf KundenGelöst
	Zuständiger Benutzer Assignee	Der Benutzer oder Mitarbeiter, der aktuell für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Der zuständige Benutzer ist für den nächsten Schritt oder die Lösung der Serviceanfrage verantwortlich. Dieser Attributwert kann sich im Verlauf der Anfrage mehrfach ändern, wenn sie zwischen verschiedenen Mitarbeitern oder Teams weitergegeben wird. Das Attribut ist wichtig für die Analyse der Arbeitsauslastung, die Leistungsmessung und das Ressourcenmanagement. Sie können den Prozess nach Mitarbeitern filtern, Lösungszeiten vergleichen und möglichen Schulungsbedarf oder eine unausgewogene Arbeitsverteilung erkennen, die zu Engpässen führt. Warum das wichtig ist Dieses Attribut ist wichtig, um die Arbeitsauslastung der Mitarbeiter zu analysieren, ihre individuelle Leistung zu messen und die Ressourcenzuteilung nachzuvollziehen. Woher beziehen Entspricht dem Feld „assignee“ eines Jira-Vorgangs. Beispiele Alice JohnsonBob WilliamsNicht zugewiesen
	Erneut geöffnet IsReopened	Ein boolesches Kennzeichen, das angibt, ob eine Serviceanfrage nach ihrer Lösung erneut geöffnet wurde.
Beschreibung Dieses berechnete Attribut ist ein Wahr/Falsch-Kennzeichen. Es wird auf „wahr“ gesetzt, wenn der Workflow einer Anfrage die Aktivität „Anfrage erneut geöffnet“ enthält. Der Wert wird aus der Abfolge der Aktivitäten für jeden Case abgeleitet. Das Kennzeichen ist wichtig für die Berechnung der Kennzahl „Quote erneut geöffneter Serviceanfragen“ und für das Dashboard „Volumen erneut geöffneter Serviceanfragen“. Eine hohe Quote deutet darauf hin, dass Anfragen häufig nicht beim ersten Versuch zufriedenstellend gelöst werden. Das führt zu Nacharbeit und geringerer Kundenzufriedenheit. Wenn Sie untersuchen, welche Anfragetypen oder Lösungen mit diesem Kennzeichen verbunden sind, können Sie Verbesserungsbedarf gezielt erkennen. Warum das wichtig ist Misst direkt die Nacharbeit und die Qualität der Lösung beim ersten Versuch. Beides sind wichtige Indikatoren für die Prozesseffektivität und Kundenzufriedenheit. Woher beziehen Wird bei der Datentransformation berechnet. Dazu wird geprüft, ob die Aktivitätsabfolge eines Cases nach einem Übergang zu „Resolved“ einen Übergang zu „Reopened“ enthält. Beispiele truefalse
	Kanal Channel	Der Einreichungsweg, über den die Serviceanfrage erstellt wurde, zum Beispiel per E-Mail, Portal oder API.
Beschreibung Das Attribut „Kanal“ gibt an, über welchen Weg eine Serviceanfrage ins System gelangt ist. Zu den üblichen Kanälen in Jira Service Management gehören das Kundenportal, E-Mail oder die direkte Erstellung durch einen Mitarbeiter. Die Analyse nach Kanal hilft dabei, das Verhalten der Benutzer zu verstehen und die Servicebereitstellung zu verbessern. Sie zeigt beispielsweise, ob Anfragen über bestimmte Kanäle länger dauern oder häufiger Rückfragen erfordern. Das kann auf Verbesserungsbedarf bei den Portalformularen oder den Regeln zur E-Mail-Verarbeitung hinweisen. Diese Analyse unterstützt das Dashboard „Trends beim Durchsatz von Serviceanfragen“. Warum das wichtig ist Hilft zu analysieren, ob der Einreichungskanal die Lösungszeiten, die Verständlichkeit der Anfrage oder die Prozesseffizienz insgesamt beeinflusst. Woher beziehen Diese Information ist in Jira Service Management über das Feld „Request channel type“ verfügbar. Dafür kann ein spezieller API-Zugriff erforderlich sein; alternativ ist sie möglicherweise in einem benutzerdefinierten Feld gespeichert. Beispiele PortalE-MailAPI
	Lösung Resolution	Das endgültige Ergebnis oder der Abschluss einer gelösten Serviceanfrage.
Beschreibung Das Feld „Resolution“ gibt an, warum eine Serviceanfrage geschlossen wurde. Häufige Werte sind „Done“, „Won't Do“, „Duplicate“ oder „Cannot Reproduce“. Es enthält zusätzliche Angaben zum Abschluss, die über den Status „Resolved“ oder „Closed“ hinausgehen. Die Analyse der Lösungsangaben zeigt, welche Ergebnisse erzielt wurden und wie sie zustande kamen. Eine hohe Zahl von Anfragen mit der Lösung „Duplicate“ kann beispielsweise auf Probleme bei der Einreichung hindeuten. Wenn Sie außerdem erfassen, welche Lösungen zu erneut geöffneten Anfragen führen, können Sie unwirksame Lösungen erkennen. Warum das wichtig ist Liefert Kontext zum Ergebnis einer Anfrage. So können Sie die Lösungsqualität analysieren und Muster bei den Gründen für den Abschluss erkennen. Woher beziehen Entspricht dem Feld „resolution“ eines Jira-Vorgangs. Dieses wird üblicherweise gesetzt, wenn der Vorgang in einen Status der Kategorie „done“ wechselt. Beispiele ErledigtWird nicht umgesetztDuplikatBehoben
	Meldender Benutzer Reporter	Der Benutzer, der die Serviceanfrage ursprünglich erstellt oder gemeldet hat.
Beschreibung Der meldende Benutzer ist die Person, häufig ein Endbenutzer oder Kunde, die die Serviceanfrage eingereicht hat. Dieses Attribut gibt an, wer den Prozess angestoßen hat. In der Analyse lässt sich damit nachvollziehen, welche Anfragen von bestimmten Benutzern, Abteilungen oder Kundengruppen kommen. So können Sie Fragen beantworten wie: „Welche Abteilungen stellen die meisten Anfragen?“ oder „Treten bei bestimmten Benutzern wiederholt dieselben Probleme auf?“ Diese Informationen helfen beim proaktiven Problemmanagement und bei der Verbesserung von Benutzerschulungen. Warum das wichtig ist Gibt an, wer die Anfrage gestellt hat. So lassen sich Anzahl und Art der Anfragen nach Benutzer, Abteilung oder Kunde analysieren. Woher beziehen Entspricht dem Feld „reporter“ eines Jira-Vorgangs. Beispiele Charles DarwinMarie CurieIsaac Newton
	Organisation Organization	Die Kundenorganisation oder interne Abteilung, der der meldende Benutzer angehört.
Beschreibung Dieses Attribut ordnet meldende Benutzer Organisationen oder Abteilungen zu. Jira Service Management bietet eine integrierte Funktion „Organizations“, mit der Mitarbeiter Anfragen mehrerer Kunden oder interner Teams verwalten können. Die Analyse nach Organisation liefert wichtigen geschäftlichen Kontext. Sie zeigt, welche Kunden oder Abteilungen die meisten Supportressourcen beanspruchen, ob bestimmte Gruppen wiederholt Probleme haben und ob SLAs in verschiedenen Geschäftseinheiten durchgängig eingehalten werden. Warum das wichtig ist Ermöglicht die Analyse von Servicebedarf und Leistung nach Kunden oder internen Abteilungen und liefert wichtige geschäftliche Erkenntnisse. Woher beziehen Diese Daten stammen aus dem Feld „Organizations“, das in Jira Service Management mit der Serviceanfrage verknüpft ist. Beispiele Acme CorporationFinanzabteilungGlobal Tech Inc.
	SLA-Status SlaState	Gibt an, ob die Serviceanfrage ihr SLA erfüllt, überschritten hat oder noch innerhalb der festgelegten Frist liegt.
Beschreibung Der SLA-Status ist ein berechnetes Attribut, das jede Serviceanfrage anhand ihrer Leistung im Verhältnis zur SLA-Frist einordnet. Mögliche Werte sind „Eingehalten“, „Überschritten“ oder „In Bearbeitung“. Der Status wird durch den Vergleich des Lösungs-Timestamps mit „SlaDueDate“ ermittelt. Dieses zentrale Attribut bildet die Grundlage für das Dashboard „SLA-Leistung bei Serviceanfragen“ und die Berechnung der Kennzahl „SLA-Einhaltungsquote“. Es zeigt auf einen Blick, ob die Serviceziele eingehalten werden. Das ist wichtig für die Berichterstattung, das Vertragsmanagement und die Sicherung der Servicequalität. Warum das wichtig ist Zeigt die SLA-Leistung unmittelbar und verständlich an. Sie ist ein wichtiger Maßstab für Servicequalität und Vertragseinhaltung. Woher beziehen Wird bei der Datentransformation berechnet. Liegt die Lösungszeit vor „SlaDueDate“, lautet der Status „Eingehalten“, andernfalls „Überschritten“. Beispiele EingehaltenÜberschrittenIn Bearbeitung
	Zugewiesenes Team AssignedTeam	Das Team oder die Gruppe, die für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut gibt das Team an, dem eine Anfrage zugewiesen ist. Es bildet häufig eine übergeordnete Einheit im Vergleich zum einzelnen zuständigen Benutzer. Damit lässt sich die Leistung auf Teamebene analysieren, etwa durch einen Vergleich des First-Level-Supports mit dem Netzwerkbetrieb. Diese Dimension ist wichtig für Dashboards wie „Arbeitsauslastung der Mitarbeiter und Lösungskennzahlen“. Sie ermöglicht es, Leistungskennzahlen auf Teamebene zusammenzufassen, Teams fair zu vergleichen und ihren Beitrag zur gesamten Servicebereitstellung zu verstehen. Warum das wichtig ist Ermöglicht die Analyse der Leistung und den Ausgleich der Arbeitslast auf Team- oder Abteilungsebene, statt nur einzelne Mitarbeiter zu betrachten. Woher beziehen Dies kann ein benutzerdefiniertes Jira-Feld wie „Team“ sein oder aus den Benutzerprofilattributen des zuständigen Benutzers abgeleitet werden. Beispiele IT-Support - Stufe 1InfrastrukturteamAnwendungssupport

Erforderlich Empfohlen Optional

Aktivitäten im Serviceanfragemanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Prozesse präzise zu erkennen und zu optimieren.

5 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage zugewiesen	Diese Aktivität tritt ein, wenn eine Serviceanfrage einem bestimmten Agent oder Team zur Bearbeitung zugewiesen wird. Jira erfasst Änderungen am Feld „Assignee“ ausdrücklich und speichert den Timestamp der Zuweisung.
Warum das wichtig ist Dieser wichtige Meilenstein dient dazu, die Zeit von der Triage bis zur Zuweisung und die Verteilung der Arbeitslast auf Agents zu messen. Er markiert den Übergang von der Warteschlange zur aktiven Bearbeitung. Woher beziehen Wird aus der Vorgangshistorie ermittelt, indem nach dem ersten Eintrag gesucht wird, bei dem das Feld „Assignee“ gesetzt oder von „nicht zugewiesen“ geändert wurde. Erfassung Verwenden Sie den Timestamp der ersten Änderung am Feld „Assignee“ in der Vorgangshistorie. Ereignistyp explicit
	Lösung vorgeschlagen	In vielen Service-Desk-Workflows wird der anfragenden Person in einem eigenen Schritt eine Lösung zur Freigabe vorgeschlagen. Dies wird aus einem Status wie „Pending Customer Acceptance“ oder „Awaiting Confirmation“ abgeleitet.
Warum das wichtig ist Diese Aktivität grenzt die Wartezeit auf eine Rückmeldung der anfragenden Person nach Bereitstellung einer Lösung ab. So lässt sie sich von der internen Bearbeitungszeit unterscheiden. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp wird erfasst, wenn sich der Status zu einem Wert ändert, der anzeigt, dass die Lösung auf die Prüfung durch die anfragende Person wartet. Erfassung Ermitteln Sie den Timestamp der Statusänderung zu „Pending Customer Acceptance“ oder einem gleichwertigen Status. Ereignistyp inferred
	Serviceanfrage erstellt	Diese Aktivität markiert den Beginn des Lebenszyklus einer Serviceanfrage. Eine Person reicht die Anfrage über ein Portal, per E-Mail oder über einen anderen Kanal ein. Jira erfasst dieses Ereignis ausdrücklich, wenn ein neuer Vorgang des Typs „Service Request“ erstellt wird, und speichert den Erstellungs-Timestamp.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Es ist entscheidend, um die gesamte Zykluszeit zu berechnen und Umfang sowie Eingangsmuster der Anfragen zu verstehen. Woher beziehen Dieses Ereignis wird ausdrücklich in der Vorgangshistorie erfasst. Als Timestamp der Aktivität dient das Feld „created“ des Jira-Vorgangs. Erfassung Verwenden Sie den Erstellungs-Timestamp des Vorgangs aus der Tabelle „issues“ oder der Historie. Ereignistyp explicit
	Serviceanfrage gelöst	Markiert den offiziellen Zeitpunkt, zu dem die Anfrage als erfüllt gilt und die Lösung dokumentiert wird. Jira füllt das Feld „Resolution Date“, sobald ein Vorgang erstmals in einen Status der Kategorie „Done“ wechselt.
Warum das wichtig ist Dies ist ein zentraler Endmeilenstein des Prozesses und entscheidend für die Berechnung der Lösungszeit und die Einhaltung von SLAs. Er markiert das Ende der aktiven Bearbeitung. Woher beziehen Dies ist ein explizites Ereignis. Der Timestamp entspricht dem Wert im Feld „Resolution Date“ des Jira-Vorgangs. Jira setzt ihn beim ersten Wechsel in einen Status der Kategorie „Done“. Erfassung Verwenden Sie das Feld „resolutiondate“ des Jira-Vorgangs. Jira füllt dieses Feld automatisch aus. Ereignistyp explicit
	Serviceanfrage geschlossen	Bezeichnet den endgültigen administrativen Abschluss der Serviceanfrage. Dieser erfolgt häufig automatisch, nachdem die Anfrage eine festgelegte Zeit im Status „Resolved“ war. Damit endet der Lebenszyklus des Vorgangs in Jira.
Warum das wichtig ist Dies ist das endgültige Endereignis des Prozesses. Die Zeit zwischen „Resolved“ und „Closed“ lässt sich analysieren, um den administrativen Aufwand oder automatische Abschlussregeln zu bewerten. Woher beziehen Aus dem Vorgangsverlauf abgeleitet. Der Timestamp entspricht der letzten Statusänderung zu „Closed“ oder einem vergleichbaren Endstatus. Erfassung Ermitteln Sie den Timestamp der letzten Statusänderung zu „Closed“. Ereignistyp inferred
	Anfrage erneut geöffnet	Diese Aktivität erfasst Fälle, in denen eine zuvor gelöste Serviceanfrage wieder in einen aktiven Status versetzt wird. Sie wird aus einer Statusänderung von „Resolved“ oder „Closed“ zurück zu „Open“ oder „In Progress“ abgeleitet.
Warum das wichtig ist Die Erfassung erneut geöffneter Anfragen ist entscheidend, um die Lösungsqualität und die Lösungsquote beim ersten Kontakt zu messen. Eine hohe Wiedereröffnungsquote deutet auf unwirksame Lösungen oder wiederkehrende Probleme hin. Woher beziehen Wird aus der Vorgangshistorie abgeleitet, indem ein Statuswechsel von einer Statuskategorie wie „Resolved“ oder „Closed“ zu einer Kategorie wie „Open“ oder „In Progress“ ermittelt wird. Erfassung Suchen Sie nach einer Statusänderung von der Kategorie „Done“ zu „To Do“ oder „In Progress“. Ereignistyp inferred
	Anfrage triagiert	Bezeichnet die erste Bewertung einer Serviceanfrage, bei der Priorität, Kategorie und Auswirkungen festgelegt werden. Diese Aktivität wird üblicherweise aus einer Statusänderung abgeleitet, etwa von „New“ zu „In Progress“ oder zu einem eigenen Status „Triaged“.
Warum das wichtig ist Die Analyse der Zeit bis zur Triage zeigt, wie effizient Anfragen zu Beginn bearbeitet werden. Verzögerungen in dieser Phase können die gesamte Bearbeitungszeit und die Einhaltung von SLAs erheblich beeinträchtigen. Woher beziehen Wird aus der Vorgangshistorie abgeleitet, indem der erste Timestamp einer Statusänderung von einem anfänglichen Status wie „New“ oder „Open“ zu einem aktiven Status wie „In Progress“ ermittelt wird. Erfassung Ermitteln Sie anhand des Workflows des Projekts die erste Statusänderung von „New“ oder einem entsprechenden Anfangsstatus. Ereignistyp inferred
	Einbindung des Anbieters beendet	Bezeichnet den Zeitpunkt, an dem der externe Anbieter seine Arbeit abgeschlossen hat und die Serviceanfrage an das interne Team zurückgeht. Dies wird daraus abgeleitet, dass der Vorgang den Status „Waiting for vendor“ verlässt.
Warum das wichtig ist Die Dauer der Einbindung externer Anbieter zu messen, hilft dabei, deren Leistung zu steuern und den Einfluss externer Parteien auf die gesamte Bearbeitungszeit zu verstehen. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Vorgangs von einem Anbieterstatus zurück zu „In Progress“ ändert. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld „status“ von einem Anbieterstatus zurück zu einem aktiven Status ändert. Ereignistyp inferred
	Einbindung des Anbieters begonnen	Diese Aktivität zeigt an, dass die Serviceanfrage an einen externen Anbieter oder Dritten eskaliert wurde oder dessen Mitwirkung erfordert. Sie wird aus einem Status wie „Waiting for vendor“ oder „With Third Party“ abgeleitet.
Warum das wichtig ist Die Erfassung der Einbindung externer Anbieter ist wichtig, um externe Abhängigkeiten und Verzögerungen zu erkennen, die außerhalb des direkten Einflussbereichs des internen Service Desks liegen. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Vorgangs zu einem festgelegten Anbieterstatus ändert. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld „status“ zu einem Wert wie „Waiting for Vendor“ ändert. Ereignistyp inferred
	Informationen angefordert	Markiert den Zeitpunkt, an dem ein Agent weitere Informationen von der anfragenden Person benötigt, um die Anfrage zu bearbeiten. Dies wird üblicherweise aus einem Status wie „Waiting for customer“ oder „Pending Input“ abgeleitet.
Warum das wichtig ist Häufige oder lang andauernde Zyklen mit dem Status „Information Requested“ können auf unklare ursprüngliche Anfragen oder ineffiziente Kommunikation hindeuten und erhebliche Verzögerungen verursachen. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Vorgangs zu „Waiting for customer“ oder einem gleichwertigen Status ändert. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld „status“ in einen Wert ändert, der anzeigt, dass der Prozess auf eine Rückmeldung der anfragenden Person wartet. Ereignistyp inferred
	Informationen bereitgestellt	Diese Aktivität tritt ein, wenn die anfragende Person die benötigten Informationen bereitstellt und der Agent die Arbeit fortsetzen kann. Sie wird daraus abgeleitet, dass der Vorgang den Status „Waiting for customer“ verlässt. Häufig löst ein Kommentar der anfragenden Person diesen Wechsel aus.
Warum das wichtig ist Diese Aktivität schließt den Anfrage-Antwort-Zyklus mit der anfragenden Person ab. Die Zeit zwischen der Informationsanfrage und dem Eingang der Antwort ist ein wichtiger Bestandteil der Wartezeit im Prozess. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Vorgangs von „Waiting for customer“ zurück zu „In Progress“ ändert. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld „status“ von einem Warte- zu einem aktiven Status ändert. Ereignistyp inferred
	Lösung bestätigt	Diese Aktivität tritt ein, wenn die anfragende Person die vorgeschlagene Lösung offiziell akzeptiert. Häufig wird dadurch automatisch der Status „Resolved“ gesetzt. Das Ereignis wird in der Regel aus dieser Statusänderung abgeleitet.
Warum das wichtig ist Dieser Meilenstein bestätigt die Wirksamkeit der Lösung und löst das Anhalten der SLA-Uhr aus. Er hilft dabei, die Zeit bis zur Bestätigung einer Lösung durch Kunden zu messen. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht der Statusänderung von „Pending Customer Acceptance“ zu „Resolved“ oder „Closed“. Erfassung Ermitteln Sie den Timestamp der Statusänderung von „Pending Customer Acceptance“ zu „Resolved“ oder „Closed“. Ereignistyp inferred
	Lösung umgesetzt	Zeigt an, dass der Agent die erforderlichen Maßnahmen ergriffen oder eine Lösung für die Serviceanfrage entwickelt hat. Dies wird häufig aus einer Statusänderung zu „Pending Review“ oder direkt zu „Resolved“ abgeleitet.
Warum das wichtig ist Dieser Meilenstein markiert den Abschluss der zentralen Lösungsarbeit. Die Zeit bis zu dieser Aktivität umfasst häufig den wichtigsten wertschöpfenden Teil des Prozesses. Woher beziehen Wird aus der Vorgangshistorie abgeleitet. Der Timestamp entspricht der Statusänderung zu „Resolved“, „Pending Acceptance“ oder einem ähnlichen Status vor dem Abschluss. Erfassung Ermitteln Sie den Timestamp, an dem sich das Feld „status“ zu einem Wert ändert, der den Abschluss der Arbeit anzeigt. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Jira Service Management

Schritte

Melden Sie sich bei Ihrer Jira Service Management-Instanz an und öffnen Sie das Hauptmenü.
Wählen Sie Filter und anschließend Erweiterte Vorgangssuche. Dadurch wird der Vorgangsnavigator geöffnet, in dem Sie Abfragen erstellen können.
Geben Sie in der Suchleiste die im Abschnitt „Abfrage“ angegebene JQL-Abfrage (Jira Query Language) ein, um die gewünschten Serviceanfragen zu filtern. Passen Sie den Projektschlüssel und den Datumsbereich bei Bedarf an.
Klicken Sie auf Suchen, um die Abfrage auszuführen. Prüfen Sie die angezeigten Vorgänge, um sicherzustellen, dass der richtige Datensatz zurückgegeben wurde.
Klicken Sie oben rechts auf der Suchergebnisseite auf das Symbol Exportieren. Es sieht meist wie ein Kästchen mit einem nach außen zeigenden Pfeil aus.
Wählen Sie im Dropdown-Menü XML aus. Das XML-Format ist erforderlich, da der standardmäßige CSV-Export nicht den detaillierten Änderungsverlauf enthält, der für ein vollständiges Event Log benötigt wird.
Speichern Sie die heruntergeladene XML-Datei auf Ihrem lokalen System. Sie enthält alle Vorgänge aus Ihrer Abfrage einschließlich des vollständigen Änderungsverlaufs in den jeweiligen Vorgangsdaten.
Da die exportierte XML-Datei kein Event-Log-Format hat, müssen Sie die Daten nachbearbeiten. Verwenden Sie dazu ein Skript, beispielsweise in Python, PowerShell oder einer anderen Programmiersprache, um die XML-Datei auszulesen.
Das Skript muss jeden Vorgang in der Datei durchlaufen und anhand des Erstellungszeitstempels ein Ereignis „Serviceanfrage erstellt“ anlegen. Anschließend muss es den Änderungsverlauf jedes Vorgangs auswerten und Änderungen an den Feldern „status“ und „assignee“ den erforderlichen Aktivitäten zuordnen. Für jede erkannte Änderung muss eine neue Zeile erstellt werden.
Das Skript sollte die Daten in eine flache CSV-Datei umwandeln und Spalten für ServiceRequestId, ActivityName, EventTime sowie alle weiteren erforderlichen und empfohlenen Attribute erstellen.
Die Ausgabe des Skripts ist das Event Log. Speichern Sie die CSV-Datei und bereiten Sie sie für den Upload in das Process-Mining-Tool vor.

Konfiguration

JQL-Projektfilter: Verwenden Sie project = "[Your JSM Project Key]", um das gewünschte Service-Management-Projekt auszuwählen. Ersetzen Sie den Platzhalter durch den Projektschlüssel, zum Beispiel „JSM“ oder „HELPDESK“.
JQL-Vorgangstypfilter: Verwenden Sie issuetype = "Service Request" oder den Namen des Vorgangstyps, der in Ihrer Konfiguration für Serviceanfragen verwendet wird.
Datumsbereich: Es empfiehlt sich dringend, einen bestimmten Zeitraum festzulegen, damit der Export überschaubar bleibt. Verwenden Sie beispielsweise eine Klausel wie created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Ein Zeitraum von 3 bis 6 Monaten ist oft ein guter Ausgangspunkt.
Exportformat: Wählen Sie für den Export unbedingt XML aus. Das CSV-Format enthält nicht die Änderungsverlaufsdaten, die zum Erstellen des Event Logs erforderlich sind.
Jira-Berechtigungen: Der Benutzer, der den Export durchführt, benötigt für das angegebene Jira-Projekt die Berechtigung „Projekte durchsuchen“, um Vorgänge anzeigen und exportieren zu können.
Datenvolumen: Der Jira-UI-Export ist standardmäßig häufig auf 1.000 Vorgänge pro Export begrenzt. Liefert Ihre Abfrage mehr Ergebnisse, exportieren Sie die Daten in kleineren Paketen und schränken Sie dafür den Datumsbereich jedes Exports ein.

Beispielabfrage config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Schritte

Datenbankzugriff einrichten: Besorgen Sie sich schreibgeschützte Zugangsdaten und Verbindungsinformationen (Hostname, Port, Datenbankname) für die SQL-Datenbank Ihrer Jira-Instanz. Dazu benötigen Sie in der Regel Unterstützung durch die Datenbankadministration oder Ihre IT-Abteilung.
Jira-Schema ermitteln: Stellen Sie mit einem SQL-Client wie DBeaver, SQuirreL SQL oder SQL Server Management Studio eine Verbindung zur Datenbank her. Machen Sie sich mit den wichtigsten Tabellen vertraut: jiraissue (Kerndaten der Vorgänge), changegroup (Änderungsverlauf), changeitem (Details zu einzelnen Änderungen), project (Projektdetails), issuetype und priority.
IDs benutzerdefinierter Felder ermitteln: Attribute wie RequestType und SlaDueDate sind häufig benutzerdefinierte Felder. Ermitteln Sie ihre IDs, indem Sie die Tabelle customfield abfragen: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Notieren Sie die IDs für die Hauptabfrage.
SQL-Abfrage anpassen: Kopieren Sie das bereitgestellte SQL-Skript in Ihren SQL-Client. Ersetzen Sie sorgfältig alle Platzhalter in eckigen Klammern durch die tatsächlichen Werte Ihrer Jira-Konfiguration. Dazu gehören Projektschlüssel, Vorgangstypen, Statusnamen und IDs benutzerdefinierter Felder.
Datumsbereich festlegen: Suchen Sie im anfänglichen Abschnitt issue_base der Abfrage nach der Klausel WHERE i.created >= '[YYYY-MM-DD]'. Ändern Sie das Datum, um den Zeitraum für die Datenextraktion festzulegen.
Abfrage ausführen: Führen Sie das angepasste SQL-Skript aus. Die Abfrage ist für gängige SQL-Datenbanken wie PostgreSQL, SQL Server und MySQL ausgelegt. Bei großen Jira-Instanzen kann die Ausführung mehrere Minuten dauern.
Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage kurz, ob Zeilen zurückgegeben wurden und ob Spalten wie ServiceRequestId, ActivityName und EventTime wie erwartet gefüllt sind.
Daten exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie einen aussagekräftigen Dateinamen, zum Beispiel jira_servicerequest_eventlog.csv.
Upload vorbereiten: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Spaltenüberschriften exakt den erforderlichen Attributnamen entsprechen, zum Beispiel ServiceRequestId, ActivityName und EventTime. Speichern Sie die Datei für die Kompatibilität mit ProcessMind in UTF-8.

Konfiguration

Voraussetzungen: Sie benötigen direkten, schreibgeschützten Zugriff auf die Produktions- oder Replikadatenbank von Jira. Der normale Anwendungszugriff reicht nicht aus. Außerdem müssen Sie den Workflow Ihres Service-Desk-Projekts genau kennen, einschließlich der exakten Namen von Status, Vorgangstypen und benutzerdefinierten Feldern.
Wichtige Abfragefilter: Konfigurieren Sie die Abfrage so, dass sie den richtigen Datensatz erfasst. Achten Sie besonders auf folgende WHERE-Klauseln:
- p.pkey IN ('[Your Project Key]'): Dies ist der wichtigste Filter. Er beschränkt die Daten auf ein oder mehrere bestimmte Jira Service Management-Projekte.
- it.pname = '[Your Service Request Issue Type]': Damit werden ausschließlich Serviceanfragen und keine Incidents, Probleme oder anderen Vorgangstypen extrahiert.
- i.created >= '[YYYY-MM-DD]': Dieser Filter legt das Startdatum der Extraktion fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Zuordnung der Workflow-Status: Die Genauigkeit des Event Logs hängt vollständig davon ab, dass die Jira-Statusnamen in der Abfrage korrekt zugeordnet sind. Ersetzen Sie Platzhalter wie [Status for Triage], [Waiting for Customer Status] und [Resolved Status] durch die Namen, die in Ihrem Workflow verwendet werden.
Leistungshinweise: Die direkte Ausführung dieser Abfrage auf einer großen, aktiv genutzten Jira-Datenbank kann erhebliche Ressourcen beanspruchen und die Anwendungsleistung für Benutzer beeinträchtigen. Führen Sie die Extraktion möglichst auf einer schreibgeschützten Replik oder außerhalb der Hauptnutzungszeiten aus.

Beispielabfrage sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Schritte

Voraussetzungen und Einrichtung: Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist. Installieren Sie die erforderlichen Python-Bibliotheken, indem Sie im Terminal folgenden Befehl ausführen: pip install requests pandas.
Jira-API-Token erstellen: Melden Sie sich bei Ihrem Jira Cloud-Konto an. Öffnen Sie Ihre Profileinstellungen, wählen Sie „Kontoeinstellungen“ und wechseln Sie zum Tab „Sicherheit“, um ein API-Token zu erstellen. Kopieren Sie das Token sicher, da es zur Authentifizierung verwendet wird.
IDs benutzerdefinierter Felder ermitteln: Viele Jira-Attribute wie „Anfragetyp“ oder „SLA-Fälligkeitsdatum“ sind benutzerdefinierte Felder. Um ihre IDs zu finden, öffnen Sie „Einstellungen“ > „Vorgänge“ > „Benutzerdefinierte Felder“. Suchen Sie das gewünschte Feld und klicken Sie auf die drei Punkte „...“ > „Feldinformationen anzeigen“. Die ID steht in der URL, zum Beispiel customFieldId=10021. Notieren Sie die IDs für die Skriptkonfiguration.
Python-Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript in einem Texteditor. Tragen Sie oben in der Datei die Konfigurationswerte ein, darunter JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, die jql_query zur Auswahl Ihrer Serviceanfragen und die im vorherigen Schritt ermittelten CUSTOM_FIELD_IDS.
Jira-Status Aktivitäten zuordnen: Prüfen Sie das Wörterbuch STATUS_ACTIVITY_MAP im Skript sorgfältig. Passen Sie die Zuordnung an Ihren Jira Service Management-Workflow an. Als Schlüssel müssen die exakten Namen Ihrer Jira-Status verwendet werden, zum Beispiel „Warten auf Kundenrückmeldung“. Die Werte sind die entsprechenden Aktivitätsnamen für das Event Log, zum Beispiel „Information angefordert“.
Extraktionsskript ausführen: Öffnen Sie ein Terminal oder eine Eingabeaufforderung, wechseln Sie in das Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit folgendem Befehl aus: python jira_extraction_script.py. Das Skript stellt eine Verbindung zur Jira API her, ruft die Vorgangsdaten ab, verarbeitet sie und zeigt den Fortschritt in der Konsole an.
Ausgabedatei prüfen: Nach Abschluss erstellt das Skript im selben Verzeichnis eine CSV-Datei namens jira_event_log.csv. Öffnen Sie die Datei in einer Tabellenkalkulation und prüfen Sie den Inhalt. Kontrollieren Sie, ob alle Spalten vorhanden und wie erwartet ausgefüllt sind.
Upload zu ProcessMind vorbereiten: Stellen Sie sicher, dass die Spaltenüberschriften der CSV-Datei exakt den Anforderungen entsprechen: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType und SlaDueDate. Die Datei kann nun in ProcessMind hochgeladen werden.

Konfiguration

Jira-Authentifizierung: Das Skript benötigt die URL Ihrer Jira-Domain, die mit Ihrem Jira-Konto verknüpfte E-Mail-Adresse und ein persönliches API-Token für den sicheren Zugriff.
JQL-Abfrage (jql_query): Sie bildet den zentralen Filter für die Extraktion. Definieren Sie eine präzise JQL-Abfrage, um die richtigen Vorgänge auszuwählen. Wir empfehlen, nach project, issuetype und einem bestimmten Zeitraum über createdDate zu filtern, damit das Datenvolumen überschaubar bleibt, zum Beispiel project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Zuordnung von Status zu Aktivitäten (STATUS_ACTIVITY_MAP): Dieses Wörterbuch ist entscheidend, um Jira-Statusänderungen den passenden Prozessaktivitäten zuzuordnen. Passen Sie die Zuordnung an den Jira-Workflow Ihrer Organisation an. Status, die nicht in dieser Zuordnung enthalten sind, werden ignoriert.
IDs benutzerdefinierter Felder (CUSTOM_FIELD_IDS): Um Daten aus benutzerdefinierten Feldern wie „Anfragetyp“ oder „SLA-Fälligkeitsdatum“ zu extrahieren, müssen Sie deren eindeutige System-IDs angeben, zum Beispiel customfield_10021. Nur mit der richtigen Konfiguration werden die Attribute ausgefüllt.
Datumsbereich und Leistung: Für erste Extraktionen empfiehlt sich ein JQL-Zeitraum von 3 bis 6 Monaten, damit die Verarbeitung überschaubar bleibt. Die Extraktion mehrerer Jahre kann aufgrund der API-Paginierung und Ratenbegrenzung lange dauern.

Beispielabfrage python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        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'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

Möchten Sie loslegen?

Nutzen Sie dieses Template als Einstieg in Process Mining und verbessern Sie gezielt Ihr Serviceanfragemanagement. Beginnen Sie noch heute mit der Optimierung Ihrer Abläufe.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie jetzt das Serviceanfragemanagement in Jira

Erreichen Sie einen Automatisierungsgrad von 70 % und beenden Sie langsame Bearbeitungsprozesse. Steigern Sie jetzt Ihre Effizienz!

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.

Ihr Daten-Template für das Serviceanfragemanagement

Ihr Daten-Template für das Serviceanfragemanagement

Attribute des Serviceanfragemanagements

Aktivitäten im Serviceanfragemanagement

Anleitungen zur Datenextraktion

Integrierter CSV-/XML-Export von Jira Service Management

Schritte

Konfiguration

Beispielabfrage config

Direkte Datenbankabfrage in Jira Server/Data Center

Schritte

Konfiguration

Beispielabfrage sql

Datenextraktion mit einem Python-Skript über die Jira Cloud REST API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie jetzt das Serviceanfragemanagement in Jira