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

Ihr Daten-Template für das Service Request Management

Jira Service Management

Attribute des Service-Request-Managements (17) Aktivitäten des Service-Request-Managements (13) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Service Request Management

Dieses Template bietet einen strukturierten Ansatz zur Erfassung der wesentlichen Daten für die Analyse Ihrer Service-Request-Prozesse. Es beschreibt die wichtigsten zu erfassenden Attribute und zu verfolgenden Aktivitäten und zeigt, wie Sie diese Informationen aus Ihrem System extrahieren. Verwenden Sie diese Ressource, um Ihre Datenvorbereitung zu vereinfachen und tiefere Erkenntnisse über Ihre Abläufe zu gewinnen.

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? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des Service-Request-Managements

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um das Service-Request-Management umfassend zu analysieren.

5 Erforderlich 5 Empfohlen 7 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des konkreten Ereignisses oder Tasks, der innerhalb des Lebenszyklus eines Service Requests stattgefunden hat.
Beschreibung Dieses Attribut beschreibt die konkrete Aktion oder Statusänderung, die zu einem bestimmten Zeitpunkt für einen Service Request stattgefunden hat. Beispiele sind „Request Created“, „Request Assigned“, „Solution Implemented“ und „Request Closed“. Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten bildet den Kern des Process Mining. Sie ermöglicht die Visualisierung von Prozessmodellen, die Identifikation von Engpässen sowie die Erkennung von Abweichungen vom Standard-Workflow. Das ist entscheidend, um Prozesseffizienz und Compliance zu verstehen. Warum das wichtig ist Es definiert die Prozessschritte und ermöglicht dadurch die Visualisierung des Prozessmodells sowie die Analyse von Workflow-Mustern und Abweichungen. Bezugsquelle Wird in der Regel aus der Historie der „status“-Übergänge eines Jira-Issues abgeleitet. Jeder Eintrag im Changelog des Issues für das Statusfeld stellt eine Aktivität dar. Beispiele Anfrage triagiertInformationen angefordertLösung umgesetztServiceanfrage geschlossen
	Service-Request-ID ServiceRequestId	Die eindeutige Kennung für jeden Service Request, die als Primärschlüssel für alle zugehörigen Ereignisse dient.
Beschreibung Die Service-Request-ID, in Jira häufig als Issue Key bezeichnet, identifiziert jeden einzelnen Service Request, der von einem Benutzer oder System eingereicht wurde. Sie dient als zentraler Bezugspunkt für alle nachfolgenden Ereignisse, von der ersten Erfassung bis zum endgültigen Abschluss, und ermöglicht eine vollständige End-to-End-Analyse des Verlaufs jedes Service Requests. Im Process Mining ist diese ID für die Zuordnung von Cases unverzichtbar. Sie stellt sicher, dass jede Aktivität, Statusänderung und jeder Timestamp korrekt dem jeweiligen Request zugeordnet wird. So entsteht eine konsistente Prozessinstanz für die Analyse. Warum das wichtig ist Diese ID ist die zentrale Case-Kennung. Sie verbindet alle zugehörigen Aktivitäten zu einem durchgängigen End-to-End-Prozess und macht die Prozessanalyse möglich. Bezugsquelle Dies ist das Feld „key“ für ein Issue in Jira Service Management. Beispiele SR-2023-001IT-45892HELP-105
	Startzeit EventTime	Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Startzeit oder der Ereignis-Timestamp erfasst den genauen Zeitpunkt, an dem eine Aktivität stattgefunden hat. Sie ist eine zentrale Komponente jeder Process-Mining-Analyse, da sie den zeitlichen Kontext für den gesamten Prozess liefert. Dieser Timestamp dient dazu, Ereignisse chronologisch zu ordnen, die Dauer zwischen Aktivitäten zu berechnen, die gesamte Zykluszeit eines Cases zu messen und die Prozessleistung anhand zeitbasierter Ziele wie SLAs zu analysieren. Ohne genaue Timestamps lassen sich Prozessabläufe, Verzögerungen und Effizienz nicht zuverlässig bewerten. Warum das wichtig ist Dieser Timestamp ist entscheidend für die Reihenfolge von Ereignissen, die Berechnung von Dauern und Zykluszeiten sowie die Identifikation von Prozessengpässen. Bezugsquelle Dies ist der Timestamp, der mit jeder Statusänderung im Changelog des Jira-Issues verknüpft ist. Der Erstellungszeitpunkt des Issues 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 KPIs enthaltenen Daten. Für jede Analyse ist es wichtig zu wissen, wie aktuell die Daten sind, um fundierte Entscheidungen zu treffen. Dieser Timestamp zeigt, ob Sie Echtzeitinformationen oder eine Momentaufnahme aus einem früheren Zeitpunkt betrachten. Das beeinflusst die Aussagekraft der Erkenntnisse. Warum das wichtig ist Zeigt die Aktualität der Daten an und stellt sicher, dass Analysen auf aktuellen Informationen basieren. Bezugsquelle Dies ist ein Metadatenfeld, das vom Datenextraktionstool oder -skript am Ende der Ausführung erzeugt und gespeichert wird. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten des Service Requests extrahiert wurden.
Beschreibung Dieses Attribut identifiziert die Herkunft der Daten, in diesem Fall Jira Service Management. Bei der Analyse einer einzelnen Quelle mag das nebensächlich erscheinen. Beim Zusammenführen von Prozessdaten aus mehreren Systemen wird es jedoch entscheidend. Für die Analyse unterstützt es die Nachverfolgung der Datenherkunft und die Sicherstellung der Datenqualität. Außerdem können Sie damit Prozesse filtern und vergleichen, die sich über verschiedene Softwareplattformen erstrecken oder miteinander interagieren. Warum das wichtig ist Identifiziert die Herkunft der Daten. Das ist für Data Governance und beim Zusammenführen von Prozessdaten aus mehreren Unternehmenssystemen entscheidend. Bezugsquelle In der Regel handelt es sich um einen statischen Wert, der während der Datenextraktion und -transformation ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Jira Service ManagementJiraSM
	Priorität des Requests RequestPriority	Die dem Service Request zugewiesene Prioritätsstufe, beispielsweise Niedrig, Mittel, Hoch oder Kritisch.
Beschreibung Die Priorität des Requests zeigt die Dringlichkeit und die geschäftlichen Auswirkungen eines Service Requests an. Diese Einstufung bestimmt die Reihenfolge der Bearbeitung und legt häufig die angestrebten Lösungszeiten und SLAs fest. In der Prozessanalyse ist die Priorität eine wichtige Dimension für die Segmentierung. Sie ermöglicht den Vergleich von Zykluszeiten und SLA-Einhaltung über verschiedene Prioritätsstufen hinweg. So lässt sich prüfen, ob Requests mit hoher Priorität tatsächlich schneller bearbeitet werden und ihre Ziele erreichen. Das unterstützt die Bewertung der Wirksamkeit des Priorisierungssystems. Warum das wichtig ist Ermöglicht eine segmentierte Analyse, damit Requests mit hoher Priorität schneller bearbeitet werden und strengere Service Levels einhalten. Bezugsquelle Dies entspricht dem Feld „priority“ eines Jira-Issues. Beispiele HöchsteHochMittelNiedrig
	Request-Typ RequestType	Die Klassifizierung des Service Requests, beispielsweise „Access Request“ oder „Hardware Issue“.
Beschreibung Der Request-Typ kategorisiert den Service Request anhand seiner Art. Das ist eine grundlegende Analysedimension, da verschiedene Request-Typen häufig unterschiedliche Lösungsprozesse, SLAs und Ressourcenanforderungen haben. Durch die Segmentierung der Prozessanalyse nach Request-Typ können Unternehmen Verbesserungen auf bestimmte Workflows zuschneiden. Der Engpass bei einem „Password Reset“ unterscheidet sich beispielsweise deutlich von dem bei der „New Server Provisioning“. Dieses Attribut ist entscheidend für relevante Dashboards wie „Resolution Quality by Category“. Warum das wichtig ist Dieses Attribut ist unverzichtbar, um Prozesse, Arbeitslasten und Leistung über verschiedene Kategorien von Service Requests hinweg zu vergleichen. Bezugsquelle Dies entspricht häufig dem Feld „issuetype“ in Jira oder einem benutzerdefinierten Feld „Request Type“ in Jira Service Management. Beispiele Neues Konto anfordernIT-Hilfe anfordernNeuen Mitarbeiter onboarden
	SLA-Fälligkeitsdatum SlaDueDate	Das Zieldatum und die Zielzeit, bis zu denen der Service Request gemäß seinem SLA gelöst sein sollte.
Beschreibung Das SLA-Fälligkeitsdatum ist ein berechneter Timestamp, der die Frist für die Lösung eines Requests angibt. Er wird anhand der Priorität und des Typs des Requests sowie der in Jira Service Management konfigurierten Richtlinien für Service Level Agreements (SLAs) bestimmt. Dieses Attribut ist grundlegend für das Dashboard „Service Request SLA Performance“ und den KPI „SLA Adherence Rate“. Durch den Vergleich der tatsächlichen Lösungszeit mit diesem Fälligkeitsdatum kann das System feststellen, ob ein Request fristgerecht abgeschlossen wurde, verspätet ist oder das SLA zu verletzen droht. Warum das wichtig ist Dies ist der Maßstab für die Leistungsmessung. Er unterstützt direkt die Berechnung der SLA-Konformität und hilft bei der Priorisierung der Arbeit. Bezugsquelle SLA-Informationen werden von Jira Service Management verwaltet und sind über die API verfügbar. Häufig werden sie in benutzerdefinierten Feldern gespeichert, die dynamisch aktualisiert werden. Beispiele 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Status des Requests RequestStatus	Der aktuelle Status des Service Requests in seinem Lebenszyklus.
Beschreibung Dieses Attribut beschreibt den aktuellen Zustand eines Service Requests, beispielsweise „Open“, „In Progress“, „Waiting for Customer“ oder „Resolved“. Es zeigt, an welcher Stelle sich der Request zu einem bestimmten Zeitpunkt befindet. Während das Aktivitätsprotokoll den historischen Verlauf darstellt, eignet sich der aktuelle Status zur Analyse offener Arbeitsbestände und zur Identifikation feststeckender Vorgänge. So kann die Analyse beispielsweise Requests untersuchen, die ungewöhnlich lange den Status „Waiting for Vendor“ haben. Dadurch werden externe Abhängigkeiten und Verzögerungen sichtbar. Warum das wichtig ist Liefert eine aktuelle Momentaufnahme jedes Cases. Dadurch lassen sich laufende Arbeiten analysieren sowie feststeckende oder überfällige Requests identifizieren. Bezugsquelle Dies ist das Feld „status“ eines Jira-Issues. Beispiele OffenIn BearbeitungWarten auf KundenGelöst
	Zuständige Person Assignee	Der Benutzer oder Agent, der aktuell für die Bearbeitung des Service Requests zuständig ist.
Beschreibung Die zuständige Person ist für die nächste Aktion oder die Lösung des Service Requests verantwortlich. Der Wert dieses Attributs kann sich im Verlauf des Requests mehrfach ändern, wenn die Bearbeitung zwischen verschiedenen Agents oder Teams übergeben wird. Dieses Attribut ist für die Analyse der Arbeitslast, die Leistungsmessung und das Ressourcenmanagement entscheidend. Sie können den Prozess nach Agent filtern, Lösungszeiten vergleichen und möglichen Schulungsbedarf oder unausgewogene Arbeitslasten erkennen, die Engpässe verursachen. Warum das wichtig ist Dieses Attribut ist für die Analyse der Arbeitslast von Agents, die Messung individueller Leistung und das Verständnis der Ressourcenverteilung von großer Bedeutung. Bezugsquelle Dies entspricht dem Feld „assignee“ eines Jira-Issues. Beispiele Alice JohnsonBob WilliamsNicht zugewiesen
	Erneut geöffnet IsReopened	Ein boolesches Kennzeichen, das angibt, ob ein Service Request nach seiner Lösung erneut geöffnet wurde.
Beschreibung Dieses berechnete Attribut ist ein Wahr/Falsch-Kennzeichen. Es wird auf „true“ gesetzt, wenn der Workflow eines Requests die Aktivität „Request Reopened“ enthält. Der Wert wird aus der Analyse der Aktivitätsabfolge jedes Cases abgeleitet. Dieses Kennzeichen ist entscheidend für die Berechnung des KPIs „Service Request Reopen Rate“ und für das Dashboard „Reopened Service Request Volume“. Eine hohe Rate erneut geöffneter Requests weist deutlich auf eine geringe Lösungsqualität beim ersten Kontakt hin. Das führt zu Nacharbeit und sinkender Kundenzufriedenheit. Die Analyse der mit diesem Kennzeichen verbundenen Request-Typen oder Lösungen kann Verbesserungsbereiche aufzeigen. Warum das wichtig ist Misst direkt die Nacharbeit und die Lösungsqualität beim ersten Kontakt. Beide Werte sind wichtige Indikatoren für Prozesseffektivität und Kundenzufriedenheit. Bezugsquelle Wird während der Datentransformation berechnet, indem geprüft wird, ob die Aktivitätsabfolge eines Cases nach einem „Resolved“-Übergang einen „Reopened“-Übergang enthält. Beispiele truefalse
	Kanal Channel	Die Einreichungsmethode, über die der Service Request erstellt wurde, beispielsweise E-Mail, Portal oder API.
Beschreibung Das Attribut „Kanal“ identifiziert, wie ein Service Request in das System gelangt ist. Zu den gängigen Kanälen in Jira Service Management gehören das Kundenportal, E-Mail oder die direkte Erstellung durch einen Agent. Die Analyse des Prozesses nach Kanal ist wichtig, um das Benutzerverhalten zu verstehen und die Servicebereitstellung zu optimieren. Sie kann zeigen, ob Requests aus bestimmten Kanälen länger bis zur Lösung benötigen oder häufiger Rückfragen erfordern. Das kann auf bessere Formulare im Portal oder optimierte Regeln für die E-Mail-Verarbeitung hinweisen. Diese Analyse unterstützt das Dashboard „Service Request Throughput Trends“. Warum das wichtig ist Hilft zu analysieren, ob der Einreichungskanal Lösungszeiten, Verständlichkeit des Requests oder die allgemeine Prozesseffizienz beeinflusst. Bezugsquelle Diese Information ist in Jira Service Management über das Feld „Request channel type“ verfügbar. Dafür kann ein spezifischer API-Zugriff erforderlich sein, oder die Information ist in einem benutzerdefinierten Feld gespeichert. Beispiele PortalE-MailAPI
	Lösung Resolution	Das endgültige Ergebnis oder der Abschluss eines gelösten Service Requests.
Beschreibung Das Feld „Resolution“ gibt an, warum ein Service Request geschlossen wurde. Häufige Werte sind „Done“, „Won't Do“, „Duplicate“ oder „Cannot Reproduce“. Es liefert Abschlussdetails, die über den Status „Resolved“ oder „Closed“ hinausgehen. Die Analyse von Lösungen hilft, Qualität und Art der Ergebnisse zu verstehen. Eine hohe Anzahl von Lösungen mit dem Wert „Duplicate“ kann beispielsweise auf ein Problem bei der Einreichung von Requests hinweisen. Die Auswertung, welche Lösungen zu erneut geöffneten Requests führen, kann außerdem unwirksame Lösungen sichtbar machen. Warum das wichtig ist Liefert Kontext zum Ergebnis eines Requests. Dadurch lassen sich die Lösungsqualität analysieren und Trends bei den Gründen für das Schließen von Requests erkennen. Bezugsquelle Dies entspricht dem Feld „resolution“ eines Jira-Issues. Es wird in der Regel gesetzt, wenn das Issue in eine Statuskategorie „done“ wechselt. Beispiele ErledigtWird nicht erledigtDuplikatBehoben
	Meldende Person Reporter	Der Benutzer, der den Service Request ursprünglich erstellt oder gemeldet hat.
Beschreibung Die meldende Person ist der Benutzer, häufig ein Endbenutzer oder Kunde, der den Service Request eingereicht hat. Dieses Attribut identifiziert den Stakeholder, der den Prozess gestartet hat. In der Analyse können Sie damit Request-Muster verschiedener Benutzer, Abteilungen oder Kundensegmente untersuchen. Es hilft bei Fragen wie: „Welche Abteilungen reichen die meisten Requests ein?“ oder „Treten bei bestimmten Benutzern wiederholt dieselben Probleme auf?“ Diese Informationen sind für proaktives Problemmanagement und eine bessere Benutzerschulung wertvoll. Warum das wichtig ist Identifiziert den Ursprung eines Requests und ermöglicht die Analyse von Volumen und Typen nach Benutzer, Abteilung oder Kunde. Bezugsquelle Dies entspricht dem Feld „reporter“ eines Jira-Issues. Beispiele Charles DarwinMarie CurieIsaac Newton
	Organisation Organization	Die Kundenorganisation oder interne Abteilung, der die meldende Person angehört.
Beschreibung Dieses Attribut gruppiert meldende Personen nach Organisationen oder Abteilungen. Jira Service Management verfügt über eine integrierte Funktion „Organizations“, mit der Agents Requests mehrerer Kunden oder interner Teams verwalten können. Die Analyse nach Organisation liefert wertvollen geschäftlichen Kontext. Sie kann zeigen, welche Kunden oder Abteilungen die meisten Supportressourcen beanspruchen, ob bestimmte Gruppen wiederkehrende Probleme haben und ob SLAs in verschiedenen Geschäftsbereichen einheitlich eingehalten werden. Warum das wichtig ist Ermöglicht die Analyse von Servicenachfrage und Leistung nach Kunde oder interner Abteilung und liefert wichtige geschäftliche Erkenntnisse. Bezugsquelle Diese Daten stammen aus dem Feld „Organizations“, das in Jira Service Management mit dem Service Request verknüpft ist. Beispiele Acme CorporationFinanzabteilungGlobal Tech Inc.
	SLA-Status SlaState	Gibt an, ob der Service Request sein SLA eingehalten oder verletzt hat oder sich noch innerhalb des definierten SLA befindet.
Beschreibung Der SLA-Status ist ein berechnetes Attribut, das jeden Service Request anhand seiner Leistung im Verhältnis zur SLA-Frist kategorisiert. Mögliche Werte sind „Met“, „Breached“ oder „In Progress“. Der Wert wird durch den Vergleich des Lösungs-Timestamps mit „SlaDueDate“ bestimmt. Dieses Attribut bildet die Grundlage für das Dashboard „Service Request SLA Performance“ und wird zur Berechnung des KPIs „SLA Adherence Rate“ verwendet. Es liefert einen klaren Überblick über die Einhaltung von Service Levels, die für Reporting, Vertragsmanagement und die Sicherung der Servicequalität entscheidend ist. Warum das wichtig ist Liefert einen klaren und unmittelbaren Indikator für die SLA-Leistung. Diese ist ein entscheidendes Maß für Servicequalität und vertragliche Compliance. Bezugsquelle Wird während der Datentransformation berechnet. Liegt die Lösungszeit vor „SlaDueDate“, lautet der Status „Met“, andernfalls „Breached“. Beispiele EingehaltenVerletztIn Bearbeitung
	Zuständiges Team AssignedTeam	Das Team oder die Gruppe, die für die Bearbeitung des Service Requests zuständig ist.
Beschreibung Dieses Attribut gibt das einem Request zugewiesene Team an. Dabei handelt es sich häufig um eine übergeordnete Gruppierung gegenüber der einzelnen zuständigen Person. Das ist für die Analyse auf Teamebene hilfreich, etwa beim Vergleich des First-Level-Support-Teams mit dem Network-Operations-Team. Diese Dimension ist für Dashboards wie „Agent Workload and Resolution Metrics“ entscheidend. Sie ermöglicht die Aggregation von Leistungskennzahlen auf Teamebene, faire Vergleiche und ein besseres Verständnis des Beitrags verschiedener Teams zur gesamten Servicebereitstellung. Warum das wichtig ist Ermöglicht die Analyse der Leistung und den Ausgleich der Arbeitslast auf Team- oder Abteilungsebene, statt nur einzelne Agents zu betrachten. Bezugsquelle Dies kann ein benutzerdefiniertes Feld in Jira sein, beispielsweise „Team“, oder aus den Benutzerprofilattributen der zuständigen Person abgeleitet werden. Beispiele IT-Support, Stufe 1InfrastrukturteamAnwendungs-Support

Erforderlich Empfohlen Optional

Aktivitäten des Service-Request-Managements

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Prozess präzise zu entdecken und zu optimieren.

5 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage zugewiesen	Diese Aktivität tritt ein, wenn eine Serviceanfrage einer bestimmten Person oder einem Team zur Lösung zugewiesen wird. Jira erfasst Änderungen am Feld „Assignee“ ausdrücklich und stellt damit einen eindeutigen Timestamp für die Zuweisung bereit.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein zur Messung der Zeit von der Triage bis zur Zuweisung sowie der Verteilung der Arbeitslast. Er markiert den Übergang von der Warteschlange zur aktiven Bearbeitung. Bezugsquelle Aus der Issue-Historie ermittelt, indem das erste Setzen oder Ändern des Feldes „Assignee“ von „nicht zugewiesen“ gesucht wird. Erfassen Verwenden Sie den Timestamp der ersten Änderung am Feld „Assignee“ in der Issue-Historie. Ereignistyp explicit
	Lösung vorgeschlagen	In vielen Workflows von Service Desks gibt es einen eigenen Schritt, in dem der anfragenden Person eine Lösung zur Bestätigung vorgelegt wird. Diese Aktivität wird daraus abgeleitet, dass sich der Status des Issues in einen Wert wie „Pending Customer Acceptance“ oder „Awaiting Confirmation“ ändert.
Warum das wichtig ist Diese Aktivität isoliert die Wartezeit auf eine Rückmeldung des Kunden, nachdem eine Lösung bereitgestellt wurde. So lässt sie sich von der internen Bearbeitungszeit unterscheiden. Bezugsquelle Aus der Issue-Historie abgeleitet und mit dem Timestamp der Statusänderung in einen Zustand erfasst, der anzeigt, dass die Lösung auf die Bestätigung des Kunden wartet. Erfassen 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, wenn ein Benutzer eine Anfrage über ein Portal, per E-Mail oder über einen anderen Kanal formal übermittelt. In Jira wird dieses Ereignis ausdrücklich erfasst, sobald ein neues Issue vom Typ „Service Request“ erstellt wird. Dabei wird der Erstellungs-Timestamp gespeichert.
Warum das wichtig ist Dies ist das primäre Start-Ereignis des Prozesses. Es ist entscheidend für die Berechnung der gesamten Durchlaufzeit sowie für das Verständnis von Anfragevolumen und Eingangsmustern. Bezugsquelle Dies ist ein ausdrücklich in der Issue-Historientabelle erfasstes Ereignis. Der Aktivitäts-Timestamp entspricht dem Feld „created“ des Jira-Issues. Erfassen Verwenden Sie den Erstellungs-Timestamp des Issues aus der Tabelle „issues“ oder der Historie. Ereignistyp explicit
	Serviceanfrage gelöst	Diese Aktivität markiert den offiziellen Zeitpunkt, an dem die Anfrage als erfüllt gilt und die Lösung dokumentiert wird. Jira füllt das Feld „Resolution Date“, sobald ein Issue 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 SLA-Einhaltung. Er markiert das Ende der aktiven Bearbeitung. Bezugsquelle Dies ist ein ausdrücklich erfasstes Ereignis. Der Timestamp entspricht dem Wert im Feld „Resolution Date“ des Jira-Issues. Dieses Feld wird beim ersten Übergang in einen Status der Kategorie „Done“ gesetzt. Erfassen Verwenden Sie das Feld „resolutiondate“ des Jira-Issues. Dieses Feld wird automatisch ausgefüllt. Ereignistyp explicit
	Serviceanfrage geschlossen	Diese Aktivität bezeichnet den endgültigen administrativen Abschluss der Serviceanfrage. Er erfolgt häufig automatisch, nachdem die Anfrage eine festgelegte Zeit im Status „Resolved“ verblieben ist. Damit endet der Lebenszyklus des Issues in Jira.
Warum das wichtig ist Dies ist das definitive Endereignis des Prozesses. Die Zeit zwischen „Resolved“ und „Closed“ kann analysiert werden, um den administrativen Aufwand oder Richtlinien zur automatischen Schließung zu verstehen. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht der letzten Statusänderung zu „Closed“ oder einem gleichwertigen Endstatus. Erfassen Ermitteln Sie den Timestamp der letzten Statusänderung zu einem Status wie „Closed“. Ereignistyp inferred
	Anfrage triagiert	Diese Aktivität steht für die erste Bewertung einer Serviceanfrage. Dabei werden Priorität, Kategorie und Auswirkung bestimmt. In der Regel wird sie aus einer Statusänderung abgeleitet, etwa vom Status „New“ zu „In Progress“ oder zu einem eigenen Status „Triaged“.
Warum das wichtig ist Die Analyse der Zeit bis zur Triage hilft bei der Bewertung der Effizienz der ersten Bearbeitung einer Anfrage. Verzögerungen an dieser Stelle können die gesamte Lösungszeit und die SLA-Einhaltung erheblich beeinträchtigen. Bezugsquelle Aus der Issue-Historie 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. Erfassen Ermitteln Sie die erste Statusänderung von „New“ oder einem gleichwertigen Anfangsstatus auf Grundlage des Workflows des Projekts. Ereignistyp inferred
	Anfrage wiedereröffnet	Diese Aktivität erfasst Fälle, in denen eine zuvor gelöste Serviceanfrage in einen aktiven Zustand zurückkehrt. Sie wird aus einer Statusänderung von einem gelösten oder geschlossenen Status zurück zu einem offenen Status oder zu „In Progress“ abgeleitet.
Warum das wichtig ist Die Verfolgung wiedereröffneter Anfragen ist entscheidend für die Messung der Lösungsqualität und der First-Time Resolution Rate. Eine hohe Wiedereröffnungsrate weist auf unwirksame Lösungen oder wiederkehrende Probleme hin. Bezugsquelle Aus der Issue-Historie abgeleitet, indem ein Statusübergang von einem Status der Kategorie „Resolved“ oder „Closed“ zu einem Status der Kategorie „Open“ oder „In Progress“ ermittelt wird. Erfassen Suchen Sie nach einer Statusänderung von einem Status der Kategorie „Done“ zu einem Status der Kategorie „To Do“ oder „In Progress“. Ereignistyp inferred
	Einbindung des Anbieters beendet	Diese Aktivität bezeichnet den Zeitpunkt, an dem der externe Anbieter seine Aufgabe abgeschlossen hat und die Serviceanfrage an das interne Team zurückgegeben wird. Sie wird daraus abgeleitet, dass das Issue den Status „Waiting for vendor“ verlässt.
Warum das wichtig ist Die Messung der Dauer der Anbieterbeteiligung unterstützt das Anbietermanagement und zeigt, wie sich externe Parteien auf die gesamte Lösungszeit auswirken. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Issues von einem Anbieterstatus zurück in einen Status wie „In Progress“ ändert. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „status“ von einem Anbieterstatus zurück in einen aktiven Status ändert. Ereignistyp inferred
	Einbindung des Anbieters gestartet	Diese Aktivität zeigt an, dass die Serviceanfrage an einen externen Anbieter oder Dritten eskaliert wurde oder dessen Unterstützung erfordert. Sie wird daraus abgeleitet, dass das Issue in einen Status wie „Waiting for vendor“ oder „With Third Party“ wechselt.
Warum das wichtig ist Die Verfolgung der Einbindung externer Anbieter ist entscheidend, um externe Abhängigkeiten und Verzögerungen zu erkennen, die außerhalb der direkten Kontrolle des internen Service Desks liegen. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Issues in einen festgelegten Anbieterstatus ändert. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „status“ in einen Wert wie „Waiting for Vendor“ ändert. Ereignistyp inferred
	Informationen angefordert	Diese Aktivität markiert den Zeitpunkt, an dem eine mit der Bearbeitung betraute Person weitere Informationen von der anfragenden Person benötigt. In der Regel wird sie daraus abgeleitet, dass das Issue in einen Status wie „Waiting for customer“ oder „Pending Input“ wechselt.
Warum das wichtig ist Häufige oder lange Zyklen mit dem Status „Information Requested“ können auf unklare ursprüngliche Angaben oder ineffiziente Kommunikation hinweisen und eine wesentliche Verzögerungsquelle darstellen. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Issues in „Waiting for customer“ oder einen gleichwertigen Status ändert. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „status“ in einen Wert ändert, der darauf hinweist, dass der Prozess auf die anfragende Person wartet. Ereignistyp inferred
	Informationen bereitgestellt	Diese Aktivität tritt ein, wenn die anfragende Person die erforderlichen Informationen übermittelt und die Bearbeitung fortgesetzt werden kann. Sie wird daraus abgeleitet, dass das Issue den Status „Waiting for customer“ verlässt, häufig nachdem die anfragende Person einen Kommentar hinzugefügt hat.
Warum das wichtig ist Diese Aktivität schließt die Anfrage-Antwort-Schleife mit dem Kunden ab. Die Zeit zwischen der Anforderung und dem Eingang der Informationen ist ein wichtiger Bestandteil der Wartezeit im Prozess. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status des Issues von „Waiting for customer“ zurück in einen Status wie „In Progress“ ändert. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „status“ von einem Wartezustand zurück in einen aktiven Zustand ändert. Ereignistyp inferred
	Lösung bestätigt	Diese Aktivität tritt ein, wenn die anfragende Person die vorgeschlagene Lösung formal akzeptiert. Häufig löst dies einen automatisierten Übergang zum Status „Resolved“ aus. In der Regel wird das Ereignis 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 zu messen, die Kunden für die Bestätigung einer Lösung benötigen. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt, an dem sich der Status von „Pending Customer Acceptance“ zu „Resolved“ oder „Closed“ ändert. Erfassen Ermitteln Sie den Timestamp der Statusänderung von „Pending Customer Acceptance“ zu einem Status wie „Resolved“ oder „Closed“. Ereignistyp inferred
	Lösung umgesetzt	Diese Aktivität zeigt an, dass die mit der Bearbeitung betraute Person die erforderlichen Maßnahmen durchgeführt oder eine Lösung für die Serviceanfrage entwickelt hat. Häufig wird sie aus einer Statusänderung zu „Pending Review“ oder direkt zu „Resolved“ abgeleitet.
Warum das wichtig ist Dieser Meilenstein markiert den Abschluss der eigentlichen Lösungsarbeit. Die Zeit bis zu dieser Aktivität stellt häufig den zentralen wertschöpfenden Teil des Prozesses dar. Bezugsquelle Aus der Issue-Historie abgeleitet. Der Timestamp entspricht dem Zeitpunkt der Statusänderung zu „Resolved“, „Pending Acceptance“ oder einem vergleichbaren Status vor dem Abschluss. Erfassen Ermitteln Sie den Timestamp, an dem sich das Feld „status“ in einen Wert ändert, der den Abschluss der Arbeit anzeigt. Ereignistyp inferred

Anleitungen zur Datenextraktion

So erhalten 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 Advanced issue search. Dadurch wird der Issue Navigator geöffnet, in dem Sie Abfragen erstellen können.
Geben Sie in der Suchleiste die im Abschnitt Query bereitgestellte JQL-Abfrage (Jira Query Language) ein, um die gewünschten Service Requests 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 zurückgegebene Liste der Vorgänge, um sicherzustellen, dass sie den richtigen Datenbestand enthält.
Klicken Sie oben rechts auf der Seite mit den Suchergebnissen auf das Export-Symbol, das häufig wie ein Kasten mit einem nach außen zeigenden Pfeil aussieht.
Wählen Sie im Dropdown-Menü XML aus. XML ist erforderlich, da der standardmäßige CSV-Export nicht die detaillierte Änderungshistorie enthält, die 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 Ihrer Abfrage einschließlich der vollständigen Änderungshistorie in den jeweiligen Vorgangsdaten.
Da das exportierte XML nicht im Format eines Event Logs vorliegt, ist eine Nachbearbeitung erforderlich. Verwenden Sie ein Skript, beispielsweise in Python, Powershell oder einer anderen Sprache, um die XML-Datei zu analysieren.
Das Skript muss jeden Vorgang in der Datei durchlaufen und anhand des Erstellungs-Timestamps ein Ereignis 'Service Request Created' erzeugen. Anschließend muss es die Änderungshistorie jedes Vorgangs analysieren und Feldänderungen für 'status' und 'assignee' identifizieren, die den erforderlichen Aktivitäten zugeordnet werden. Für jede erkannte Änderung muss eine neue Zeile erzeugt 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 diese 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 Ihres Projekts, beispielsweise „JSM“ oder „HELPDESK“.
JQL-Filter für Vorgangstypen: Verwenden Sie issuetype = "Service Request" oder die in Ihrer Konfiguration verwendete Bezeichnung des Vorgangstyps für Serviceanfragen.
Datumsbereich: Es empfiehlt sich dringend, einen bestimmten Zeitraum zu filtern, um die Exportgröße zu begrenzen. Verwenden Sie beispielsweise created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Ein Zeitraum von drei bis sechs Monaten ist häufig ein guter Ausgangspunkt.
Exportformat: Für den Export müssen Sie XML auswählen. Das CSV-Format enthält nicht die Änderungshistorie, die für die Erstellung des Event Logs erforderlich ist.
Jira-Berechtigungen: Die Person, die den Export durchführt, benötigt für das angegebene Jira-Projekt die Berechtigung „Browse Projects“, um Vorgänge anzuzeigen und zu exportieren.
Datenvolumen: Der Standardexport der Jira-Benutzeroberfläche ist häufig auf 1.000 Vorgänge pro Export begrenzt. Liefert Ihre Abfrage mehr Ergebnisse, müssen Sie die Daten in kleineren Paketen exportieren, indem Sie den Datumsbereich für jeden Export einschränken.

a 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: Beschaffen Sie schreibgeschützte Zugangsdaten und Verbindungsinformationen, darunter Hostname, Port und Datenbankname, für die SQL-Datenbank im Backend Ihrer Jira-Instanz. Dafür benötigen Sie in der Regel Unterstützung durch die Datenbankadministration oder Ihre IT-Abteilung.
Jira-Schema identifizieren: 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 (zentrale Vorgangsdaten), changegroup (Änderungshistorie), changeitem (Details der 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 diese IDs für die Verwendung in der Hauptabfrage.
SQL-Abfrage anpassen: Kopieren Sie das bereitgestellte SQL-Skript in Ihren SQL-Client. Ersetzen Sie alle Platzhalter in eckigen Klammern sorgfältig durch die tatsächlichen Werte Ihrer Jira-Konfiguration. Dazu gehören Projektschlüssel, Vorgangstypen, Statusbezeichnungen und IDs benutzerdefinierter Felder.
Datumsbereich festlegen: Suchen Sie im initialen 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 die Ausgabe. Stellen Sie sicher, dass Zeilen zurückgegeben werden und Spalten wie ServiceRequestId, ActivityName und EventTime erwartungsgemäß befüllt sind.
Daten exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie einen aussagekräftigen Dateinamen, beispielsweise jira_servicerequest_eventlog.csv.
Upload vorbereiten: Öffnen Sie die CSV-Datei und prüfen Sie, ob die Spaltenüberschriften exakt den erforderlichen Attributnamen entsprechen, beispielsweise 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 Replikatdatenbank von Jira. Der normale Anwendungszugriff reicht nicht aus. Außerdem benötigen Sie ein umfassendes Verständnis des Workflows Ihres Service-Desk-Projekts, einschließlich der exakten Bezeichnungen von Status, Vorgangstypen und benutzerdefinierten Feldern.
Wichtige Abfragefilter: Die Abfrage muss auf den richtigen Datensatz ausgerichtet sein. Achten Sie besonders auf diese 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]': Dadurch 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 der letzten drei bis sechs Monate.
Zuordnung der Workflow-Status: Die Genauigkeit des Event Logs hängt vollständig von der korrekten Zuordnung Ihrer Jira-Statusbezeichnungen in der Abfrage ab. Ersetzen Sie Platzhalter wie [Status for Triage], [Waiting for Customer Status] und [Resolved Status] durch die in Ihrem Workflow verwendeten Bezeichnungen.
Überlegungen zur Leistung: Die direkte Ausführung dieser Abfrage auf einer großen, aktiven Jira-Datenbank kann erhebliche Ressourcen beanspruchen und die Anwendungsleistung für andere Benutzer beeinträchtigen. Es wird dringend empfohlen, die Extraktion auf einer Lesereplikat-Datenbank oder außerhalb der Hauptbetriebszeiten auszuführen.

a 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 mit folgendem Befehl in Ihrem Terminal: pip install requests pandas.
Jira-API-Token erstellen: Melden Sie sich bei Ihrem Jira-Cloud-Konto an. Öffnen Sie Ihre Profileinstellungen, wählen Sie „Account settings“ und anschließend die Registerkarte „Security“. Erstellen Sie dort ein API-Token. Kopieren Sie das Token sicher, da es zur Authentifizierung verwendet wird.
IDs benutzerdefinierter Felder ermitteln: Viele Jira-Attribute wie „Request Type“ oder „SLA Due Date“ sind benutzerdefinierte Felder. Öffnen Sie „Settings“ > „Issues“ > „Custom fields“. Suchen Sie das gewünschte Feld und klicken Sie auf die drei Punkte „...“ > „View field information“. Die ID steht in der URL, beispielsweise customFieldId=10021. Notieren Sie diese IDs für die Skriptkonfiguration.
Python-Skript konfigurieren: Öffnen Sie das bereitgestellte Python-Skript in einem Texteditor. Füllen Sie die Konfigurationsvariablen am Anfang der Datei aus, 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 Dictionary STATUS_ACTIVITY_MAP im Skript sorgfältig. Passen Sie die Zuordnung an Ihren Jira-Service-Management-Workflow an. Die Schlüssel müssen den exakten Namen Ihrer Jira-Status entsprechen, beispielsweise „Waiting for customer“. Die Werte müssen den für das Event Log erforderlichen Aktivitätsnamen entsprechen, beispielsweise „Information Requested“.
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 verbindet sich mit der Jira-API, 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 mit dem Namen jira_event_log.csv. Öffnen Sie diese Datei in einer Tabellenkalkulation und prüfen Sie den Inhalt. Stellen Sie sicher, dass alle Spalten vorhanden und erwartungsgemäß befüllt sind.
Upload in ProcessMind vorbereiten: Stellen Sie sicher, dass die Spaltenüberschriften 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 Datumsbereich über createdDate zu filtern, um das Datenvolumen zu begrenzen, beispielsweise project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Zuordnung von Status zu Aktivitäten (STATUS_ACTIVITY_MAP): Dieses Dictionary ist entscheidend, um Jira-Statusänderungen korrekt in aussagekräftige Prozessaktivitäten zu überführen. Passen Sie die Zuordnung an den spezifischen Jira-Workflow Ihrer Organisation an. Status, die nicht in dieser Zuordnung enthalten sind, werden ignoriert.
IDs benutzerdefinierter Felder (CUSTOM_FIELD_IDS): Für die Extraktion von Daten aus benutzerdefinierten Feldern wie „Request Type“ oder „SLA Due Date“ müssen Sie deren eindeutige System-IDs angeben, beispielsweise customfield_10021. Nur bei korrekter Konfiguration werden die Attribute befüllt.
Datumsbereich und Leistung: Für erste Extraktionen empfiehlt sich ein JQL-Zeitraum von drei bis sechs Monaten, damit die Verarbeitung überschaubar bleibt. Die Extraktion mehrerer Jahre kann aufgrund der API-Seitennavigation und der Ratenbegrenzung langsam sein.

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

Bereit für den Start?

Verwenden Sie dieses Template als Ausgangspunkt für Ihr Process-Mining-Projekt und erzielen Sie deutliche Verbesserungen im Service Request Management. Beginnen Sie noch heute mit der Optimierung Ihrer Abläufe.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie das Service Request Management in Jira jetzt

Erreichen Sie 70 % Automatisierung 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 Service Request Management

Ihr Daten-Template für das Service Request Management

Attribute des Service-Request-Managements

Aktivitäten des Service-Request-Managements

Anleitungen zur Datenextraktion

Integrierter CSV/XML-Export von Jira Service Management

Schritte

Konfiguration

a Beispielabfrage config

Direkte Datenbankabfrage auf Jira Server/Data Center

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion per Python-Skript über die Jira Cloud REST API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie das Service Request Management in Jira jetzt

Ihr Daten-Template für das Service Request Management

Ihr Daten-Template für das Service Request Management

Attribute des Service-Request-Managements

Aktivitäten des Service-Request-Managements

Anleitungen zur Datenextraktion

Integrierter CSV/XML-Export von Jira Service Management

Schritte

Konfiguration

a Beispielabfrage config

Direkte Datenbankabfrage auf Jira Server/Data Center

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion per Python-Skript über die Jira Cloud REST API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Optimieren Sie das Service Request Management in Jira jetzt

Ihre Privatsphäre ist uns wichtig