> Kontinuierliche Prozessverbesserung > Incident Management > BMC Helix ITSM > Daten Template

Ihr Daten-Template für das Incident Management

BMC Helix ITSM

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Incident Managements(21) Aktivitäten des Incident Managements(14) Anleitungen zur Datenextraktion(3)

Ihr Daten-Template für das Incident Management

Dieses Template zeigt Ihnen, welche wichtigen Daten Sie für die Optimierung Ihres Incident-Management-Prozesses erfassen sollten. Es beschreibt die relevanten Attribute und Aktivitäten, die Sie verfolgen sollten, und erklärt, wie Sie diese Daten extrahieren. So bereiten Sie Ihre Daten effizienter vor und können schneller mit der Prozessanalyse beginnen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten, die Sie im Prozess verfolgen sollten
Anleitung zum Extrahieren der Daten aus Ihrem System

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

Template herunterladen

Attribute des Incident Managements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Incident-Management-Prozess umfassend zu analysieren.

3 Erforderlich 8 Empfohlen 10 Optional

	Name	Beschreibung
	Incident-ID IncidentId	Die eindeutige Kennung jedes Incident-Datensatzes.
Beschreibung Die Incident-ID ist der Primärschlüssel jedes Incidents und identifiziert ihn eindeutig von der Erstellung bis zum Abschluss. Sie verknüpft alle zugehörigen Aktivitäten, Protokolle und Änderungen und ermöglicht so einen vollständigen End-to-End-Überblick über den Lebenszyklus des Incidents. Im Process Mining ist dieses Attribut grundlegend, da es den Case definiert. Jedes Event mit derselben Incident-ID gehört zur selben Prozessinstanz. So lässt sich rekonstruieren und analysieren, wie einzelne Incidents bearbeitet werden. Warum das wichtig ist Diese wichtige Case-ID verknüpft alle Events im Lebenszyklus eines Incidents und ermöglicht so die End-to-End-Prozessanalyse. Woher beziehen Dies ist das Feld „Incident Number“ (Field ID: 1000000161) im Formular „HPD:Help Desk“. Beispiele INC000001234567INC000002345678INC000003456789
	Aktivitätsname ActivityName	Die Bezeichnung des konkreten Events oder der Aufgabe im Lebenszyklus eines Incidents.
Beschreibung Dieses Attribut beschreibt die Aktivität, die zu einem bestimmten Zeitpunkt für einen Incident ausgeführt wurde, zum Beispiel „Incident gemeldet“, „Gruppe zugewiesen“ oder „Incident gelöst“. Diese Aktivitäten bilden die Bausteine der Prozessdarstellung. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten zeigt den tatsächlichen Prozessablauf, macht häufige Pfade sichtbar und weist auf Abweichungen von der Standardvorgehensweise hin. Sie ist entscheidend, um zu verstehen, welche Maßnahmen zur Lösung eines Incidents ergriffen werden. Warum das wichtig ist Aktivitäten bilden die Schritte in der Prozessdarstellung ab und ermöglichen die Visualisierung und Analyse des Incident-Management-Workflows. Woher beziehen In der Regel abgeleitet aus Änderungen der Felder „Status“ (Field ID: 7) und „Status_Reason“ im Formular „HPD:Help Desk“ oder aus dem Formular „HPD:Help Desk Audit Log“. Beispiele Incident gemeldetGruppe zugewiesenLösung umgesetztIncident abgeschlossen
	Event-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieser Timestamp erfasst, wann ein bestimmtes Event im Lebenszyklus eines Incidents stattgefunden hat. Er liefert die chronologische Reihenfolge, die erforderlich ist, um den Prozessablauf aus den Rohdaten zu rekonstruieren. Der Event-Timestamp ist für alle zeitbasierten Analysen unverzichtbar. Dazu gehören die Berechnung von Zykluszeiten zwischen Aktivitäten, das Erkennen von Engpässen mit langen Wartezeiten und die Messung der gesamten Lösungszeit. Er bildet die zeitliche Grundlage der Prozessanalyse. Warum das wichtig ist Dieser Timestamp gibt die chronologische Reihenfolge der Events an. Das ist entscheidend, um Zeitspannen zu berechnen, Engpässe zu erkennen und den zeitlichen Prozessablauf zu verstehen. Woher beziehen Das Feld „Last Modified Date“ (Field ID: 6) oder bestimmte Datumsfelder aus dem Formular „HPD:Help Desk“. Bei historischen Events stammt der Wert aus dem Timestamp-Feld des Audit-Logs. Beispiele 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
	Erneut geöffnet IsReopened	Kennzeichnet, ob ein Vorfall nach dem Status „Resolved“ erneut geöffnet wurde.
Beschreibung Dieses boolesche Attribut ist wahr, wenn der Status eines Vorfalls nach der Kennzeichnung als „Resolved“ wieder in einen aktiven Status wie „In Progress“ wechselt. Das weist darauf hin, dass die ursprüngliche Lösung nicht wirksam oder nicht vollständig war. Das Attribut misst Nacharbeit direkt und dient zur Berechnung der Kennzahl „Nacharbeitsrate bei Vorfällen“. Die Analyse erneut geöffneter Vorfälle hilft dabei, mangelhafte Lösungen, unzureichende Tests oder nicht angemessen behobene wiederkehrende Probleme zu erkennen. Sie unterstützt das Dashboard zu Nacharbeits- und Eskalationspfaden. Warum das wichtig ist Misst Nacharbeit und die Qualität von Lösungen direkt. Eine hohe Wiedereröffnungsrate weist auf unwirksame Lösungen und Schwächen im Prozess hin. Woher beziehen Wird anhand der Aktivitätsabfolge eines Vorfalls berechnet. Erscheint nach der Aktivität „Resolution Implemented“ eine Aktivität wie „Incident Reopened“, wird dieses Kennzeichen auf wahr gesetzt. Beispiele truefalse
	Incident-Status IncidentStatus	Der aktuelle oder historische Status des Incidents zum Zeitpunkt des Events.
Beschreibung Dieses Attribut gibt den Status des Incidents an, zum Beispiel „Neu“, „In Bearbeitung“, „Ausstehend“, „Gelöst“ oder „Abgeschlossen“. Es zeigt den jeweiligen Stand im Lebenszyklus des Incidents. Die Analyse von Statusänderungen ist grundlegend, um den Incident-Management-Prozess zu verstehen. Sie dient dazu, Aktivitäten zu definieren, die Dauer in verschiedenen Status zu messen, etwa wie lange Incidents „Ausstehend“ sind, und festzustellen, ob Incidents feststecken oder nicht mehr bearbeitet werden. Warum das wichtig ist Die Erfassung von Statusänderungen ist entscheidend, um den Fortschritt eines Incidents nachzuvollziehen und die Dauer in bestimmten Status wie „Ausstehend“ oder „In Bearbeitung“ zu messen. Woher beziehen Dies ist das Feld „Status“ (Field ID: 7) im Formular „HPD:Help Desk“. Beispiele NeuZugewiesenIn BearbeitungAusstehendGelöstAbgeschlossen
	Priorität Priority	Die dem Incident zugewiesene Priorität, die bestimmt, wie dringend er bearbeitet wird.
Beschreibung Die Priorität ergibt sich in der Regel aus der Kombination von Auswirkungen und Dringlichkeit. Sie bestimmt die Reihenfolge und Geschwindigkeit der Incident-Bearbeitung. Übliche Werte reichen von „Kritisch“ bis „Niedrig“. Im Process Mining ist die Analyse von Incidents nach Priorität entscheidend für die Leistungsbewertung. Sie hilft bei Fragen wie: „Halten wir die SLAs für Incidents mit hoher Priorität ein?“ und „Kommt es bei Incidents mit niedriger Priorität zu längeren Verzögerungen?“ Durch die Filterung nach Priorität können Sie besonders kritische Geschäftsprobleme gezielt untersuchen. Warum das wichtig ist Dieses Attribut ist entscheidend, um Analysen zu segmentieren. So lässt sich sicherstellen, dass Vorfälle mit hoher Priorität schneller bearbeitet werden und die dafür geltenden Service-Level-Ziele erreichen. Woher beziehen Dies ist das Feld „Priority“ (Field ID: 1000000164) im Formular „HPD:Help Desk“. Beispiele KritischHochMittelNiedrig
	Service Service	Der geschäftliche oder technische Service, der vom Vorfall betroffen ist.
Beschreibung Dieses Attribut verknüpft einen Vorfall mit einem bestimmten Service aus der Configuration Management Database (CMDB), zum Beispiel „E-Mail-Service“, „VPN-Zugang“ oder „SAP-Finanzwesen“. Diese Verknüpfung ist entscheidend, um die geschäftlichen Auswirkungen von Vorfällen zu verstehen. Die Analyse nach Service zeigt, welche Services besonders viele Vorfälle verursachen, macht wiederkehrende Probleme mit bestimmten Technologien sichtbar und unterstützt die Trendanalyse im Problemmanagement. Warum das wichtig ist Die Zuordnung von Vorfällen zu Geschäftsservices ist entscheidend für die Analyse ihrer Auswirkungen und dafür, Services mit besonders häufigen Problemen zu erkennen. Woher beziehen Dies ist das Feld „ServiceCI“ oder ein ähnliches Feld für das betroffene Configuration Item (CI) im Formular „HPD:Help Desk“. Beispiele Unternehmens-E-MailSAP ERPVPN für den FernzugriffPersonalportal
	SLA-Frist überschritten IsSlaBreached	Kennzeichnet, ob der Vorfall nach dem SLA-Zieldatum gelöst wurde.
Beschreibung Dieses boolesche Attribut ist wahr, wenn die Lösungszeit des Vorfalls die festgelegte SLA-Frist überschritten hat. Es zeigt für jeden Vorfall eindeutig an, ob die SLA-Leistung eingehalten wurde. Das Kennzeichen ist entscheidend für das Dashboard „Übersicht der SLA-Leistung bei Vorfällen“ und die Berechnung der Kennzahl „SLA-Konformitätsrate bei Vorfällen“. Es vereinfacht die Analyse, da Sie alle Vorfälle, bei denen die Service-Level-Ziele verfehlt wurden, direkt filtern und zusammenfassen können. So lassen sich die Gründe für Fristüberschreitungen gezielt untersuchen. Warum das wichtig ist Dieses Kennzeichen vereinfacht die Analyse der SLA-Konformität. Sie können alle Vorfälle mit überschrittener Frist filtern und deren Ursachen untersuchen. Woher beziehen Wird berechnet, indem der Timestamp des Ereignisses „Incident Resolved“ mit „SlaTargetDate“ verglichen wird. Liegt der Timestamp der Lösung nach dem Zieldatum, ist dieses Kennzeichen wahr. Beispiele truefalse
	Vorfallkategorie IncidentCategory	Die Klassifizierung des Vorfalls, häufig in einer mehrstufigen Struktur.
Beschreibung Die Kategorisierung von Vorfällen bietet eine strukturierte Möglichkeit, diese einzuordnen, meist anhand einer mehrstufigen Hierarchie (z. B. Stufe 1: Hardware, Stufe 2: Laptop, Stufe 3: Akku). Diese Daten sind für die Weiterleitung, Berichterstattung und Trendanalyse wichtig. Beim Process Mining lassen sich damit verschiedene Vorfalltypen getrennt analysieren. Das Dashboard zur Genauigkeit der Vorfallkategorisierung vergleicht die ursprünglichen mit den endgültigen Kategorien. Außerdem unterstützt die Kategorisierung die Erkennung von Trends im Dashboard zu Ursachenentwicklungen. Warum das wichtig ist Eine präzise Kategorisierung ermöglicht die korrekte Weiterleitung, die Trendanalyse und den Leistungsvergleich verschiedener Vorfalltypen. Woher beziehen Dies sind die Felder „Operational Categorization Tier 1/2/3“ im Formular „HPD:Help Desk“. Beispiele Hardware > Laptop > AkkuSoftware > Unternehmensanwendung > AnmeldefehlerNetzwerk > Verbindung > WLAN
	Zugewiesene Gruppe AssignedGroup	Die Supportgruppe, die für die Bearbeitung des Vorfalls zuständig ist.
Beschreibung Dieses Attribut gibt das Team oder die Abteilung an, dem bzw. der der Vorfall zugewiesen wurde, zum Beispiel „Service Desk“, „Netzwerkteam“ oder „Datenbankadministration“. Anhand der Zuweisungen lässt sich nachvollziehen, wie die Arbeit zwischen Teams weitergegeben wird. Mit diesem Attribut können Sie Übergaben zwischen Teams analysieren, durch bestimmte Gruppen verursachte Engpässe erkennen und die Rate der Neuzuweisungen von Vorfällen messen. Es veranschaulicht den Weg eines Vorfalls durch die Organisation und zeigt ineffiziente Weiterleitungen oder Wissenslücken auf. Warum das wichtig ist Die zugewiesene Gruppe zu erfassen, erleichtert die Analyse von Übergaben und Neuzuweisungsschleifen sowie das Erkennen von Engpässen in bestimmten Teams. Woher beziehen Dies ist das Feld „Assigned Group“ (Field ID: 1000000217) im Formular „HPD:Help Desk“. Beispiele Service DeskNetzwerkbetriebAnwendungssupport, Stufe 2Infrastrukturdienste
	Zuständige Person Assignee	Der Benutzer, der mit der Bearbeitung des Vorfalls beauftragt ist.
Beschreibung Die zuständige Person ist der konkrete Supportmitarbeiter oder Techniker, der zu einem bestimmten Zeitpunkt für den Vorfall verantwortlich ist. Dieses Attribut bietet eine detailliertere Sicht als die zugewiesene Gruppe. Die Analyse der Leistung nach zuständiger Person kann zeigen, wer besonders gute Ergebnisse erzielt, wer zusätzliche Schulungen benötigt und wie die Arbeitslast verteilt ist. Außerdem lässt sich damit die genaue Abfolge der Maßnahmen nachvollziehen, die einzelne Personen bei einem komplexen Vorfall ergriffen haben. Warum das wichtig ist Ermöglicht eine detaillierte Analyse der Arbeitslastverteilung und der individuellen Leistung. So lassen sich besonders leistungsstarke Mitarbeitende und Personen mit Unterstützungsbedarf erkennen. Woher beziehen Dies ist das Feld „Assignee“ (Field ID: 1000000218) im Formular „HPD:Help Desk“. Beispiele Bob SmithAlice JohnsonCharlie Brown
	Abschlusscode CloseCode	Der beim Schließen eines Vorfalls ausgewählte Code, der das Ergebnis der Lösung angibt.
Beschreibung Der Abschlusscode fasst strukturiert zusammen, wie ein Vorfall gelöst wurde. Beispiele sind „Vom Benutzer gelöst“, „Kein Fehler festgestellt“, „Doppelter Vorfall“ oder „Dauerhafte Lösung umgesetzt“. Dieses Attribut ist hilfreich, um die Wirksamkeit und Ergebnisse von Lösungen zu analysieren. Es kann Vorfälle aufzeigen, die ohne tatsächliche Behebung geschlossen wurden, oder Kategorien, in denen Benutzer ihre Probleme häufig selbst lösen. Das kann auf Möglichkeiten für bessere Wissensdatenbankartikel oder Self-Service-Angebote hinweisen. Warum das wichtig ist Liefert strukturierte Daten zu den Lösungsergebnissen. Damit können Sie die Wirksamkeit von Fehlerbehebungen analysieren und Trends bei den Abschlussgründen erkennen. Woher beziehen Dieses Attribut ist üblicherweise Teil der Lösungs- oder Abschlussinformationen im Formular „HPD:Help Desk“. Beispiele Per Fernzugriff gelöstDoppeltes ProblemBenutzerfehlerKeine Maßnahme erforderlich
	Anzahl der Neuzuweisungen ReassignmentCount	Wie oft ein Vorfall insgesamt einer anderen Gruppe zugewiesen wurde.
Beschreibung Diese Kennzahl zählt, wie oft sich das Feld „AssignedGroup“ im Verlauf eines Vorfalls geändert hat. Ein hoher Wert deutet auf Probleme bei der anfänglichen Weiterleitung, eine geringe Lösungsquote beim Erstkontakt oder komplexe Probleme hin, an denen mehrere Teams beteiligt sind. Dieses Attribut unterstützt direkt die Kennzahl „Rate der Neuzuweisungen von Vorfällen“ und das Dashboard zur Zyklusanalyse von Neuzuweisungen. Es macht den Pingpong-Effekt messbar, bei dem Tickets zwischen Teams hin- und hergeschoben werden. Das führt zu erheblichen Verzögerungen und ineffizienten Prozessen. Warum das wichtig ist Macht ineffiziente Weiterleitungen und Übergaben messbar. So lassen sich Vorfälle erkennen, die in Neuzuweisungsschleifen zwischen Teams feststecken. Woher beziehen Wird berechnet, indem im Event Log gezählt wird, wie oft sich der Wert „AssignedGroup“ für eine bestimmte Incident ID ändert. Beispiele 0135
	Auswirkung Impact	Das Ausmaß, in dem der Vorfall Geschäftsprozesse beeinträchtigt.
Beschreibung Die Auswirkung beschreibt, wie stark ein Vorfall das Geschäft beeinträchtigt. Sie wird häufig anhand einer Skala bewertet, zum Beispiel „Umfassend/Weitreichend“, „Erheblich/Groß“, „Mäßig/Begrenzt“ oder „Gering/Lokal“. Zusammen mit der Dringlichkeit bestimmt die Auswirkung die Priorität des Vorfalls. Eine Analyse nach Auswirkung zeigt, welche Vorfälle den Geschäftsbetrieb am stärksten stören, unabhängig von ihrer technischen Komplexität. Das ist wichtig, um Verbesserungsmaßnahmen für Prozesse gezielt zu priorisieren. Warum das wichtig ist Hilft dabei, die geschäftlichen Auswirkungen eines Vorfalls zu bewerten. Das ist entscheidend für die Priorisierung und dafür, Analysen auf Vorfälle mit großen Auswirkungen zu konzentrieren. Woher beziehen Dies ist das Feld „Impact“ (Field ID: 1000000163) im Formular „HPD:Help Desk“. Beispiele 1-Umfassend/Weitreichend2-Erheblich/Groß3-Mäßig/Begrenzt4-Gering/Lokal
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion. Es gibt Aufschluss darüber, wie aktuell die analysierten Daten sind und wie zeitnah die daraus gewonnenen Erkenntnisse den Prozess abbilden. Der Zeitpunkt der letzten Aktualisierung ist für Berichte und Dashboards wichtig. Er informiert Benutzer über die Aktualität der Daten und macht deutlich, ob die neuesten Incident-Aktivitäten bereits enthalten sind. Warum das wichtig ist Gibt an, wie aktuell die Daten sind, damit Benutzer die Aktualität der Prozessanalyse und der daraus gewonnenen Erkenntnisse einschätzen können. Woher beziehen Dieser Wert wird in der Regel während der Datenextraktion im ETL-Prozess erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
	Lösungsbeschreibung Resolution	Eine Freitextbeschreibung der Schritte zur Behebung des Vorfalls.
Beschreibung Dieses Feld enthält eine ausführliche, von einer Person verfasste Zusammenfassung der endgültigen Lösung. Darin steht, was unternommen wurde, um das Problem zu beheben und den Service für den Benutzer wiederherzustellen. Der Text ist zwar unstrukturiert, lässt sich aber mit Text-Mining-Verfahren analysieren. So können Sie häufige Lösungsmuster erkennen, Schlüsselwörter zu bestimmten Problemen extrahieren oder die Ursachenanalyse ergänzen. Der Text liefert qualitative Informationen, die in strukturierten Datenfeldern oft fehlen. Warum das wichtig ist Liefert qualitative Details zur Lösung. Mit Text Mining lassen sich damit Muster erkennen, die in strukturierten Daten nicht sichtbar sind. Woher beziehen Dies ist das Feld „Resolution“ (Field ID: 1000000156) im Formular „HPD:Help Desk“. Beispiele Das Passwort des Benutzers wurde über Active Directory zurückgesetzt.Cache und Cookies im Browser wurden gelöscht. Dadurch wurde das Anmeldeproblem behoben.Der Netzwerk-Switch im IDF-Schrank 3B wurde neu gestartet.
	Meldekanal Channel	Der Weg, über den der Vorfall gemeldet wurde.
Beschreibung Dieses Attribut gibt an, wie ein Vorfall gemeldet wurde, zum Beispiel telefonisch, per E-Mail, über ein Self-Service-Portal oder persönlich vor Ort. Es zeigt, über welchen Eingang der Vorfall in den Supportprozess gelangt ist. Die Analyse nach Meldekanal kann zeigen, welche Kanäle am effektivsten sind und über welche Kanäle gemeldete Vorfälle leichter oder schwieriger zu lösen sind. Sie kann auch Entscheidungen darüber unterstützen, wo sich Investitionen in Automatisierung oder Benutzerschulungen lohnen. Beispielsweise kann ein Self-Service-Portal gefördert werden, über das bereits bei der Meldung bessere Ausgangsdaten erfasst werden. Warum das wichtig ist Die Kenntnis des Meldekanals erleichtert den Vergleich verschiedener Erfassungswege und kann Investitionen in Self-Service oder Automatisierung unterstützen. Woher beziehen Dies ist das Feld „Reported Source“ (Field ID: 1000000215) im Formular „HPD:Help Desk“. Beispiele E-MailTelefonSelf-ServiceDirekte Eingabe
	Meldende Person Submitter	Die Person, die den Vorfall ursprünglich gemeldet hat.
Beschreibung Die meldende Person ist der Endbenutzer oder Kunde, der das Problem erlebt und gemeldet hat. Sie ist nicht mit der zuständigen Person zu verwechseln, die den Vorfall bearbeitet. Die Analyse nach meldender Person oder Abteilung kann Benutzergruppen aufzeigen, die zusätzliche Schulungen benötigen, oder Gruppen, die von einer bestimmten Art von Problem betroffen sind. So erhalten Sie eine kundenorientierte Sicht auf den Vorfallmanagementprozess. Warum das wichtig ist Gibt an, wer das Problem gemeldet hat. So können Sie die Daten nach Abteilung, Standort oder Rolle auswerten und benutzerspezifische Trends erkennen. Woher beziehen Diese Information wird im Feld „Submitter“ oder in Feldern zu den Kundeninformationen im Formular „HPD:Help Desk“ erfasst. Beispiele John DoeJane SmithPeter Jones
	Quellsystem SourceSystem	Das System, aus dem die Incident-Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Daten an. Das ist besonders in Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilfreich. Es bestätigt, dass die Daten aus der erwarteten Quelle stammen, etwa aus einer bestimmten BMC-Helix-ITSM-Instanz. In der Analyse hilft es, Prozesse oder Datenmerkmale zu unterscheiden, die sich zwischen Produktions-, Entwicklungs- oder Altsystemen unterscheiden können. So bleibt die Datenherkunft nachvollziehbar und vertrauenswürdig. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist entscheidend für die Datenvalidierung und die Analyse mehrerer integrierter Systeme. Woher beziehen In der Regel handelt es sich um einen statischen Wert, der während des ETL-Prozesses (Extraktion, Transformation und Laden) hinzugefügt wird. Beispiele BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
	SLA-Zieldatum SlaTargetDate	Datum und Uhrzeit, bis zu denen der Vorfall gemäß SLA voraussichtlich gelöst sein soll.
Beschreibung Dieses Attribut speichert die Frist für die Lösung eines Vorfalls gemäß der geltenden Service Level Agreement (SLA). Sie wird anhand der Priorität des Vorfalls und der festgelegten Servicezeiten berechnet. Dieser Timestamp dient als Vergleichswert für die tatsächliche Lösungszeit. Er ist entscheidend für die Berechnung der Kennzahl „SLA-Konformitätsrate bei Vorfällen“ und für Dashboards zur SLA-Leistung. Außerdem können Sie damit Vorfälle überwachen, deren Frist näher rückt. Warum das wichtig ist Dieser Vergleichswert dient zur Messung der SLA-Konformität. Anhand dessen lässt sich feststellen, ob ein Vorfall fristgerecht gelöst oder die vereinbarte Frist überschritten wurde. Woher beziehen Diese Daten werden üblicherweise im Formular „SLM:Measurement“ gespeichert und mit dem Vorfall verknüpft. Sie sind kein direktes Feld im Formular „HPD:Help Desk“. Beispiele 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
	Ursache RootCause	Der zugrunde liegende Grund oder die eigentliche Ursache des Vorfalls.
Beschreibung Die Ursache ist das grundlegende Problem, dessen Behebung ein erneutes Auftreten des Vorfalls verhindern würde. Sie wird häufig im Rahmen einer Untersuchung des zugehörigen Problems ermittelt. Auch wenn nicht für alle Vorfälle eine Ursache dokumentiert ist, ist die Analyse dieses Attributs für ein vorausschauendes Problemmanagement entscheidend. Es unterstützt die Kennzahl „Rate der Ursachenermittlung“ und hilft beim Erstellen von Dashboards, die Trends bei wiederkehrenden Problemen verfolgen. So lassen sich Maßnahmen zur Umsetzung dauerhafter Lösungen gezielt ausrichten. Warum das wichtig ist Die Ermittlung der Ursache ist für das Problemmanagement und für Analysen zur Verringerung wiederkehrender Vorfälle entscheidend. Woher beziehen Diese Information kann in einem eigenen Feld „Root Cause“ des Vorfalls stehen oder, häufiger, im verknüpften Formular „PBI:Problem Investigation“. Beispiele Zu wenig Speicherplatz auf dem ServerFehler in der NetzwerkkonfigurationSoftwarefehler in Version 2.1Abgelaufenes Sicherheitszertifikat

Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und seinen Ablauf zu visualisieren.

5 Empfohlen 9 Optional

	Aktivität	Beschreibung
	Gruppe zugewiesen	Diese Aktivität kennzeichnet die erstmalige Zuweisung des Incidents an eine bestimmte Supportgruppe zur Untersuchung. Sie wird anhand des ersten Ausfüllens des Felds „Assigned Group“ nach der Erstellung des Incidents abgeleitet.
Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der aktiven Bearbeitung. Die Zeit bis zur ersten Zuweisung ist entscheidend für die Bewertung der Reaktionszeit und der Effizienz der ersten Weiterleitung. Woher beziehen Abgeleitet aus dem Audit-Log („HPD:HelpDesk_AuditLogSystem“) des Formulars „HPD:Help Desk“, das das erstmalige Ausfüllen des Felds „Assigned Group“ erfasst. Erfassung Aus dem Timestamp, zu dem das Feld „Assigned Group“ erstmals ausgefüllt wird. Ereignistyp inferred
	Incident abgeschlossen	Diese letzte Aktivität kennzeichnet den formalen Abschluss des Incident-Datensatzes, nachdem die Lösung bestätigt wurde oder eine Bestätigungsfrist abgelaufen ist. Sie wird erfasst, wenn der Status auf „Closed“ gesetzt wird.
Warum das wichtig ist Dies ist das endgültige End-Event im Lebenszyklus eines Incidents. Die Zeit zwischen „Resolved“ und „Closed“ umfasst die Bestätigung durch den Benutzer und den administrativen Abschluss. Woher beziehen Dieses Event entspricht dem Status „Closed“ im Feld „Status“ des Formulars „HPD:Help Desk“. Der Timestamp wird im Feld „Closed Date“ und im Audit-Log erfasst. Erfassung Aus dem Timestamp „Closed Date“ oder dem Statuswechsel zu „Closed“. Ereignistyp inferred
	Incident gelöst	Diese Aktivität kennzeichnet die offizielle Lösung des Incidents aus Sicht des Service Desk, bevor der endgültige Abschluss erfolgt. Sie wird erfasst, wenn der Incident-Status auf „Resolved“ gesetzt wird.
Warum das wichtig ist Dies ist der wichtigste Meilenstein zur Messung der SLA-Einhaltung und der Lösungszeit. Er zeigt an, dass der Service für den Benutzer wiederhergestellt wurde. Woher beziehen Dieses Event entspricht dem Status „Resolved“ im Feld „Status“ des Formulars „HPD:Help Desk“. Der Timestamp wird im Feld „Last Resolved Date“ und im Audit-Log erfasst. Erfassung Aus dem Timestamp des Statuswechsels zu „Resolved“ im Audit-Log. Ereignistyp inferred
	Incident gemeldet	Diese Aktivität kennzeichnet die erstmalige Erstellung des Incident-Datensatzes im System. Sie wird anhand des Erstellungs-Timestamps des Incidents im zentralen Incident-Management-Formular erfasst.
Warum das wichtig ist Dies ist das primäre Start-Event im Lebenszyklus eines Incidents. Es ist entscheidend, um die gesamte Lösungszeit zu berechnen und die Häufigkeit neu eingehender Incidents zu verstehen. Woher beziehen Dieses Event entspricht der Erstellung des Datensatzes im Formular „HPD:Help Desk“. Als Timestamp dient in der Regel das Feld „Submit Date“ oder „Reported Date“. Erfassung Aus dem Timestamp „Submit Date“ im Formular HPD:Help Desk. Ereignistyp explicit
	Untersuchung begonnen	Zeigt an, dass ein Supportmitarbeiter mit der aktiven Bearbeitung des Incidents begonnen hat. Dies wird in der Regel aus einem Statuswechsel von „Assigned“ zu „In Progress“ abgeleitet.
Warum das wichtig ist Dieser Meilenstein markiert den Übergang von der Wartezeit in einer Warteschlange zur aktiven Diagnose. Die Analyse der Wartezeit bis zum Beginn der Untersuchung hilft, Ressourcenengpässe zu erkennen, und unterstützt das Dashboard „Engpässe bei Diagnose und Untersuchung“. Woher beziehen Abgeleitet aus einer Statusänderung im Formular „HPD:Help Desk“. Das Event wird ausgelöst, wenn das Feld „Status“ zu „In Progress“ wechselt. Der Timestamp stammt aus dem Audit-Log. Erfassung Abgeleitet aus dem Statuswechsel zu „In Progress“ im HPD:HelpDesk_AuditLogSystem. Ereignistyp inferred
	An andere Gruppe übertragen	Diese Aktivität tritt auf, wenn ein Incident von einer Supportgruppe an eine andere neu zugewiesen wird. Sie wird anhand einer Änderung des Felds „Assigned Group“ nach der ersten Zuweisung ermittelt.
Warum das wichtig ist Häufige Übertragungen deuten auf eine falsche Erstzuweisung oder fehlendes Wissen hin. Die Erfassung dieser Aktivität ist wichtig für das Dashboard „Analyse der Incident-Neuzuweisungen“ und die KPI „Incident-Neuzuweisungsrate“. Woher beziehen Abgeleitet aus dem Audit-Log („HPD:HelpDesk_AuditLogSystem“), indem nach dem erstmaligen Ausfüllen des Felds „Assigned Group“ weitere Änderungen dieses Felds im Formular „HPD:Help Desk“ ermittelt werden. Erfassung Ermitteln Sie Änderungen am Feld „Assigned Group“ nach der ersten Zuweisung. Ereignistyp inferred
	Bestätigung durch den Benutzer erhalten	Kennzeichnet die ausdrückliche Bestätigung des Benutzers, dass die bereitgestellte Lösung das Problem behoben hat. Dies kann als eigenes Event erfasst oder vor dem Abschluss aus Notizen beziehungsweise einer zugehörigen Systemaktion abgeleitet werden.
Warum das wichtig ist Die Erfassung dieses Events bildet den Bestätigungsprozess durch den Benutzer genauer ab, als lediglich auf den automatischen Abschluss zu warten. Sie hilft, die KPI „Durchschnittliche Zeit bis zur Bestätigung durch den Benutzer“ zu messen und Kommunikationslücken zu erkennen. Woher beziehen Dieses Event lässt sich möglicherweise nur schwer zuverlässig erfassen. Es kann aus einem Eintrag im Arbeitsprotokoll oder einer Änderung des Statusgrunds kurz vor dem Wechsel des Incidents zu „Closed“ abgeleitet werden. Dafür kann eine Analyse des Formulars „HPD:WorkLog“ erforderlich sein. Erfassung Abgeleitet aus bestimmten Einträgen im Arbeitsprotokoll oder Änderungen des Statusgrunds vor dem Abschluss. Ereignistyp inferred
	Incident abgebrochen	Diese Aktivität kennzeichnet die Beendigung eines Incidents, der versehentlich erstellt wurde oder nicht mehr relevant ist. Sie wird erfasst, wenn der Incident-Status auf „Cancelled“ gesetzt wird.
Warum das wichtig ist Dies ist ein endgültiger Endstatus für einen Incident und unterscheidet sich von einer erfolgreichen Lösung. Die Analyse abgebrochener Incidents kann Probleme bei den Erfassungskanälen oder doppelte Meldungen aufdecken. Woher beziehen Abgeleitet aus dem Formular „HPD:Help Desk“, wenn das Feld „Status“ auf „Cancelled“ gesetzt wird. Der Timestamp wird im Audit-Log erfasst. Erfassung Abgeleitet aus dem Statuswechsel zu „Cancelled“ im Audit-Log. Ereignistyp inferred
	Incident erneut geöffnet	Kennzeichnet einen Incident, der zuvor als gelöst markiert, aber wieder aktiviert wurde, weil das Problem weiterhin besteht. Dies wird aus einem Statuswechsel von „Resolved“ zurück zu einem aktiven Status wie „In Progress“ oder „Assigned“ abgeleitet.
Warum das wichtig ist Diese Aktivität misst direkt den Nacharbeitsaufwand und die Wirksamkeit der ersten Lösungen. Eine hohe Zahl erneut geöffneter Incidents weist auf eine geringe Qualität der Fehlerbehebung hin und unterstützt die KPI „Nacharbeitsrate bei Incidents“. Woher beziehen Abgeleitet aus dem Audit-Log („HPD:HelpDesk_AuditLogSystem“), indem für eine Incident-ID ein Statuswechsel von „Resolved“ zu „In Progress“ oder „Assigned“ ermittelt wird. Erfassung Abgeleitet aus dem Statuswechsel von „Resolved“ zurück zu einem aktiven Status. Ereignistyp inferred
	Incident kategorisiert	Kennzeichnet den Zeitpunkt, an dem der Incident nach betrieblichen und produktbezogenen Kriterien klassifiziert und eine Priorität festgelegt wurde. Dies wird in der Regel daraus abgeleitet, dass Kategorisierungsfelder ausgefüllt oder zuletzt geändert wurden.
Warum das wichtig ist Eine korrekte und zeitnahe Kategorisierung ist entscheidend für eine effiziente Weiterleitung und aussagekräftige Berichte. Die Analyse dieser Aktivität hilft, Verzögerungen oder Fehler bei der ersten Triage zu erkennen und unterstützt das Dashboard „Genauigkeit der Incident-Kategorisierung“. Woher beziehen Abgeleitet aus dem Audit-Log („HPD:HelpDesk_AuditLogSystem“), das Änderungen an Feldern wie „Operational Categorization Tier 1-3“, „Product Categorization Tier 1-3“ und „Priority“ im Formular „HPD:Help Desk“ erfasst. Erfassung Aus dem Timestamp der letzten Änderung an Kategorisierungs- oder Prioritätsfeldern nach der Erstellung. Ereignistyp inferred
	Lösung umgesetzt	Diese Aktivität zeigt an, dass das Supportteam eine Fehlerbehebung oder einen Workaround angewendet hat. Sie wird häufig daraus abgeleitet, dass der Incident-Status zu „Resolved“ wechselt.
Warum das wichtig ist Dieser wichtige Meilenstein zeigt an, dass eine Lösung bereitgestellt wurde. Er ist ein zentraler Datenpunkt, um die Zeit bis zur Fehlerbehebung nach Abschluss der Untersuchung zu messen. Woher beziehen Dies wird in der Regel daraus abgeleitet, dass das Feld „Status“ im Formular „HPD:Help Desk“ auf „Resolved“ gesetzt wird. Der Timestamp wird im Feld „Last Resolved Date“ und im Audit-Log erfasst. Erfassung Aus dem Timestamp „Last Resolved Date“ oder dem Statuswechsel zu „Resolved“. Ereignistyp inferred
	SLA-Verletzung	Dieses berechnete Event tritt ein, wenn die Lösungszeit eines Incidents das festgelegte Ziel des Service Level Agreement überschreitet. Es wird ermittelt, indem der Timestamp der Lösung mit dem Fälligkeitsdatum des SLA verglichen wird.
Warum das wichtig ist Diese Aktivität ist grundlegend für das Dashboard „Übersicht der SLA-Leistung bei Incidents“ und die KPI „SLA-Einhaltungsrate bei Incidents“. Sie kennzeichnet direkt Incidents, bei denen die vereinbarten Serviceziele nicht erreicht wurden. Woher beziehen Berechnet durch den Vergleich von „Last Resolved Date“ mit „Target Date“ (SLA-Fälligkeitsdatum) im Formular „HPD:Help Desk“. Ist der Incident noch nicht gelöst, kann stattdessen der aktuelle Zeitpunkt herangezogen werden. Erfassung Berechnetes Event: tritt ein, wenn „Last Resolved Date“ > „Target Date“. Ereignistyp calculated
	Warten auf Bestätigung durch den Benutzer	Diese Phase beginnt nach der Umsetzung einer Lösung, wenn das Supportteam auf die Bestätigung des Benutzers wartet, dass die Fehlerbehebung erfolgreich war. Sie wird häufig durch den Status „Resolved“ dargestellt. In diesem Status beginnt die Frist bis zum automatischen Abschluss.
Warum das wichtig ist Diese Aktivität ist wichtig für das Dashboard „Verzögerungen bei Benutzerbestätigung und Überprüfung“. Sie hilft, die Zeit zwischen der Bereitstellung einer Fehlerbehebung und ihrer Bestätigung durch den Benutzer zu messen. Diese Wartezeit kann den Incident-Lebenszyklus unnötig verlängern. Woher beziehen Dieser Status beginnt, wenn das Feld „Status“ im Formular „HPD:Help Desk“ auf „Resolved“ wechselt. Die Dauer wird ab „Last Resolved Date“ gemessen, bis der Incident entweder auf „Closed“ oder erneut auf „Reopened“ gesetzt wird. Erfassung Beginnt mit dem Statuswechsel zu „Resolved“ und endet mit dem Statuswechsel zu „Closed“ oder „In Progress“. Ereignistyp inferred
	Warten auf Kundenangaben	Kennzeichnet eine Unterbrechung der Incident-Bearbeitung, während Informationen oder eine Aktion des Benutzers ausstehen. Dies wird aus einem Statuswechsel zu „Pending“ abgeleitet.
Warum das wichtig ist Diese Aktivität trennt die Arbeitszeit des Supportmitarbeiters von der Wartezeit auf den Kunden. Die Analyse der Dauer in diesem Status ist entscheidend, um zu verstehen, wie sich verzögerte Rückmeldungen auf die gesamte Lösungszeit auswirken. Woher beziehen Abgeleitet aus dem Formular „HPD:Help Desk“, wenn das Feld „Status“ auf „Pending“ gesetzt wird. Der konkrete Grund steht häufig im Feld „Status_Reason“. Erfassung Abgeleitet aus dem Statuswechsel zu „Pending“ im HPD:HelpDesk_AuditLogSystem. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus BMC Helix ITSM

Schritte

Smart Reporting öffnen: Melden Sie sich bei Ihrer BMC Helix ITSM-Umgebung an. Öffnen Sie im Hauptmenü der Anwendung den Bereich Berichte, um Smart Reporting zu starten.
Neuen Bericht erstellen: Klicken Sie in Smart Reporting auf Erstellen und wählen Sie Bericht. Wählen Sie Erweiterter Bericht, um auf komplexere Funktionen wie Freehand SQL zuzugreifen.
Datenquelle auswählen: Wählen Sie bei der entsprechenden Aufforderung Ihre primäre ITSM-Datenquelle aus. Wählen Sie die Ansicht Incident Management. Diese semantische Ebene basiert auf den zentralen Vorfallsformularen.
Freehand SQL verwenden: Öffnen Sie im Berichtseditor die Optionen der Datenquelle und wählen Sie statt Felder per Drag-and-drop hinzuzufügen die Option Freehand SQL. Daraufhin öffnet sich ein Editor, in dem Sie eine eigene SQL-Abfrage schreiben können.
SQL-Abfrage eingeben: Kopieren Sie die vollständige SQL-Abfrage aus dem Abfrageabschnitt dieses Dokuments und fügen Sie sie in den Freehand-SQL-Editor ein. Ersetzen Sie die Platzhalter [START_DATE], [END_DATE] und [YOUR_COMPANY_NAME] durch die für Sie passenden Werte.
Daten prüfen und Vorschau anzeigen: Prüfen Sie mit der Validierungs- oder Vorschaufunktion des SQL-Editors, ob Syntaxfehler vorliegen, und sehen Sie sich Beispieldaten an. So stellen Sie sicher, dass die Abfrage in Ihrer Umgebung korrekt ausgeführt wird, bevor Sie den vollständigen Bericht erstellen.
Bericht formatieren: Fahren Sie nach erfolgreicher Validierung mit dem Berichtsentwurf fort. Die in der SQL-Abfrage definierten Spalten stehen als Felder zur Verfügung. Nehmen Sie alle Spalten (IncidentId, ActivityName, EventTimestamp usw.) in die Berichtstabelle auf.
Berichtsfilter anwenden (optional): Der Hauptfilter für den Zeitraum ist bereits in der SQL-Abfrage enthalten. Bei Bedarf können Sie auf Berichtsebene weitere interaktive Filter hinzufügen, etwa nach Priority oder AssignedGroup.
Bericht ausführen und speichern: Führen Sie den Bericht aus, um den vollständigen Datensatz zu erstellen. Wenn Sie mit den Ergebnissen zufrieden sind, speichern Sie den Bericht unter einem aussagekräftigen Namen, zum Beispiel „Incident Management Event Log“.
Als CSV exportieren: Öffnen Sie die Berichtsergebnisse und wählen Sie die Funktion Export. Wählen Sie als Exportformat CSV. Dadurch wird die vollständige Event-Log-Datei auf Ihren lokalen Rechner heruntergeladen.
Export planen (optional): Für laufende Analysen können Sie den Bericht automatisch ausführen lassen. Richten Sie in den Verteilungseinstellungen des Berichts einen Zeitplan ein, zum Beispiel täglich oder wöchentlich, und legen Sie als Ziel einen Dateifreigabeordner oder eine E-Mail-Adresse fest. Achten Sie darauf, CSV als Format auszuwählen.

Konfiguration

Voraussetzungen: Sie benötigen ein BMC Helix-Konto mit Berechtigungen für Smart Reporting, das Erstellen von Berichten, die Verwendung von Freehand SQL und Abfragen der Datenquelle Incident Management.
Berichtstyp: Zum Erstellen der Event-Log-Struktur mit UNION ALL-Anweisungen benötigen Sie einen Erweiterten Bericht mit der Funktion Freehand SQL.
Ansicht der Datenquelle: Verwenden Sie die Standardansicht Incident Management, die auf dem Formular HPD:Help Desk und den zugehörigen Verknüpfungen basiert.
Zeitraumfilter: Legen Sie unbedingt einen Zeitraum fest, um die Leistung zu sichern. Die bereitgestellte Abfrage enthält die Platzhalter [START_DATE] und [END_DATE]. Für aussagekräftige Analysen empfehlen wir, Daten aus einem Zeitraum von 3 bis 6 Monaten zu extrahieren, ohne das System übermäßig zu belasten.
Unternehmensfilter: Die Abfrage enthält den Platzhalter [YOUR_COMPANY_NAME], mit dem Sie die Daten auf ein bestimmtes operatives Unternehmen beschränken. In einer Umgebung mit mehreren Mandanten ist dieser Filter für korrekte Berichte unerlässlich.
Leistungsaspekte: Die Abfrage für das Event Log ist komplex und verknüpft mehrere Tabellen. Bei großen Datensätzen kann ihre Ausführung erhebliche Systemressourcen beanspruchen. Planen Sie umfangreiche Exporte daher außerhalb der Spitzenzeiten.

Beispielabfrage sql

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Reported' AS "ActivityName",
  hpd."Submit Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Categorized' AS "ActivityName",
  hpd."Last Modified Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."First Assigned Date" IS NOT NULL AND hpd."Operational Categ Tier 1" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT 
  hpd."Incident Number" AS "IncidentId",
  'Group Assigned' AS "ActivityName",
  hpd."First Assigned Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."First Assigned Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  aud."New_Value" AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  aud."New_Value" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Status%' AND aud.New_Value IN ('In Progress', 'Pending')
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'
  AND aud.New_Value = 'In Progress' AND aud."Audit_Date" = (SELECT MIN(a2."Audit_Date") FROM HPD_HelpDesk_AuditLogSystem a2 WHERE a2."Original_Request_ID" = hpd."Incident Number" AND a2."New_Value" = 'In Progress' AND a2."Fields_Changed" LIKE '%Status%')

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Transferred To Another Group' AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  aud."New_Value" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Assigned Group%' AND aud."Audit_Date" > hpd."First Assigned Date"
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Pending Customer Input' AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  'Pending' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Status%' AND aud."New_Value" = 'Pending'
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Resolution Implemented' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Awaiting User Confirmation' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Resolved' AND hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Reopened' AS "ActivityName",
  hpd."Re-Opened Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  'Yes' AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Re-Opened Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Resolved' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" >= 'Resolved' AND hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'User Confirmation Received' AS "ActivityName",
  hpd."Closed Date" AS "EventTimestamp",
  'Closed' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Closed' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'SLA Breach' AS "ActivityName",
  hpd."Estimated Resolution Date" AS "EventTimestamp", -- Represents the SLA due date
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  'Yes' AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."SLM Status" = 'Service Target Breached' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Cancelled' AS "ActivityName",
  hpd."Last Modified Date" AS "EventTimestamp",
  'Cancelled' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Cancelled' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Closed' AS "ActivityName",
  hpd."Closed Date" AS "EventTimestamp",
  'Closed' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Closed' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

Schritte

Datenbankzugangsdaten und Schema ermitteln: Besorgen Sie sich schreibgeschützte Zugangsdaten für die zugrunde liegende BMC Helix ITSM AR System-Datenbank, zum Beispiel SQL Server oder Oracle. Ermitteln Sie außerdem die konkreten Schema- und Tabellennamen für das Formular zur Vorfallverwaltung (HPD:Help Desk) und dessen Audit-Log. Die Haupttabelle heißt häufig T<form_id> (zum Beispiel T1234), das Audit-Log meist H<form_id> oder [form_name]_AuditLogSystem.
Mit der Datenbank verbinden: Stellen Sie mit einem gängigen SQL-Client wie DBeaver, SQL Server Management Studio (SSMS) oder Oracle SQL Developer und den Zugangsdaten aus dem vorherigen Schritt eine Verbindung zur Datenbank her.
SQL-Abfrage prüfen und anpassen: Kopieren Sie die bereitgestellte SQL-Abfrage in Ihren Client. Prüfen Sie die Platzhalter sorgfältig und ersetzen Sie sie durch die passenden Werte für Ihre Umgebung:
- [Your_HPD_Help_Desk_Table]: Ersetzen Sie den Platzhalter durch den tatsächlichen Tabellennamen des Formulars HPD:Help Desk.
- [Your_HPD_Help_Desk_Audit_Table]: Ersetzen Sie den Platzhalter durch den tatsächlichen Tabellennamen des Audit-Logs für das Formular HPD:Help Desk.
- 'YYYY-MM-DD' und 'YYYY-MM-DD': Legen Sie das Start- und Enddatum des Extraktionszeitraums fest.
Timestamp-Konvertierung berücksichtigen: Die bereitgestellte Abfrage verwendet DATEADD(s, [TimestampColumn], '1970-01-01'). Diese Funktion ist spezifisch für SQL Server und konvertiert Epoch-Timestamps. Wenn Sie Oracle oder eine andere Datenbank verwenden, müssen Sie die Funktion entsprechend anpassen. In Oracle lautet das Äquivalent TO_DATE('1970-01-01', 'YYYY-MM-DD') + ( [TimestampColumn] / 86400 ).
Abfrage ausführen: Führen Sie die angepasste Abfrage für die Datenbank aus. Je nach Zeitraum und Umfang Ihrer Vorfalldaten kann dies mehrere Minuten dauern.
Ergebnisse prüfen: Überprüfen Sie die Ausgabe nach Abschluss der Abfrage kurz. Kontrollieren Sie, ob die Spalten IncidentId, ActivityName und EventTimestamp wie erwartet befüllt sind. Achten Sie darauf, dass verschiedene Aktivitäten enthalten sind, damit Sie sehen, ob die UNION ALL-Anweisungen korrekt funktionieren.
Daten als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8 als Zeichenkodierung und nehmen Sie eine Kopfzeile mit den Spaltennamen auf.
Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die Spalte EventTimestamp ein einheitliches Format verwendet, zum Beispiel YYYY-MM-DD HH:MI:SS. Wenn die SQL-Abfrage korrekt ausgeführt wurde, sind keine weiteren Datentransformationen erforderlich.

Konfiguration

Voraussetzungen: Sie benötigen schreibgeschützten Benutzerzugriff auf die Anwendungsdatenbank von BMC Helix ITSM. Außerdem müssen Sie die konkreten Tabellennamen des Formulars HPD:Help Desk und seines Audit-Logs kennen. Diese können je nach Systeminstallation variieren.
Zeitraumfilter: Die Abfrage enthält in der CTE BaseIncidents eine WHERE-Klausel, die nach Submit_Date filtert. Beginnen Sie am besten mit einem begrenzten Zeitraum von beispielsweise 3 bis 6 Monaten, um Abfrageleistung und Datenvolumen zu kontrollieren. Beispiel: WHERE hpd.Submit_Date >= '2023-01-01' AND hpd.Submit_Date < '2023-07-01'.
Unternehmensfilter: Wenn Ihre ITSM-Instanz mehrere Mandanten umfasst, ergänzen Sie in der WHERE-Klausel der CTE BaseIncidents einen Filter für das zu analysierende Unternehmen, zum Beispiel AND hpd.Company = '[Your Company Name]'.
Leistungsaspekte: Direkte Datenbankabfragen können viele Ressourcen beanspruchen, insbesondere wenn sie Verknüpfungen mit großen Audit-Log-Tabellen und mehrere UNION ALL-Operationen enthalten. Führen Sie umfangreiche Extraktionen am besten außerhalb der Spitzenzeiten aus, damit die Systemleistung nicht beeinträchtigt wird.
Timestamp-Konvertierung: Die Abfrage setzt voraus, dass Timestamps im Unix-Epoch-Format gespeichert sind, also als Sekunden seit dem 01.01.1970. Prüfen Sie, ob dies für Ihr System gilt und ob die verwendete Konvertierungsfunktion zu Ihrer Datenbank passt, zum Beispiel zu SQL Server oder Oracle.

Beispielabfrage sql

WITH BaseIncidents AS (
    -- Select the base set of incidents within the desired date range
    SELECT
        hpd.Incident_Number AS IncidentId,
        hpd.Status AS FinalStatus,
        hpd.Priority,
        hpd.Assigned_Group AS FinalAssignedGroup,
        hpd.Assignee AS FinalAssignee,
        hpd.Service_CI AS Service,
        hpd.Categorization_Tier_1 + ' | ' + hpd.Categorization_Tier_2 + ' | ' + hpd.Categorization_Tier_3 AS IncidentCategory,
        DATEDIFF(SECOND, hpd.Submit_Date, hpd.Last_Resolved_Date) AS IncidentResolutionTime,
        CASE WHEN hpd.Last_Resolved_Date > hpd.Target_Date THEN 'true' ELSE 'false' END AS IsSlaBreached,
        hpd.Submit_Date,
        hpd.Last_Resolved_Date,
        hpd.Closed_Date,
        hpd.Target_Date,
        hpd.Entry_ID -- Required for joining with the audit log
    FROM [Your_HPD_Help_Desk_Table] hpd
    WHERE hpd.Submit_Date BETWEEN '[START_DATE_YYYY-MM-DD]' AND '[END_DATE_YYYY-MM-DD]'
),
AuditChanges AS (
    -- Process the audit log to identify key changes in Status and Assigned Group
    SELECT 
        audit.Entry_ID,
        audit.Log_Key_Value,
        audit.Fields_Changed,
        DATEADD(s, audit.Log_Key_Value, '1970-01-01') AS EventTimestamp,
        LAG(audit.Fields_Changed, 1, '') OVER (PARTITION BY audit.Entry_ID, SUBSTRING(audit.Fields_Changed, 1, 8) ORDER BY audit.Log_Key_Value) AS Previous_Value
    FROM [Your_HPD_Help_Desk_Audit_Table] audit
    WHERE 
        -- Field ID 7 is for Status, Field ID 1000000217 is for Assigned Group
        (SUBSTRING(audit.Fields_Changed, 1, 8) = '7       ' OR SUBSTRING(audit.Fields_Changed, 1, 8) = '1000000217')
        AND audit.Entry_ID IN (SELECT Entry_ID FROM BaseIncidents)
),
ReopenedFlag AS (
    -- Identify incidents that have been reopened
    SELECT DISTINCT Entry_ID, 'true' AS IsReopened
    FROM AuditChanges
    WHERE 
        SUBSTRING(Fields_Changed, 1, 8) = '7       ' -- Status field
        AND CHARINDEX('Resolved', Previous_Value) > 0
        AND CHARINDEX('Resolved', Fields_Changed) = 0
)
-- Combine all activities into a single event log
SELECT
    b.IncidentId,
    'Incident Reported' AS ActivityName,
    b.Submit_Date AS EventTimestamp,
    'New' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Categorized' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus, -- Inferred status at time of categorization/assignment
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN (
    -- Find the first assignment event, used as a proxy for categorization
    SELECT Entry_ID, MIN(EventTimestamp) AS FirstAssignmentTime
    FROM AuditChanges
    WHERE SUBSTRING(Fields_Changed, 1, 8) = '1000000217'
    GROUP BY Entry_ID
) first_assign ON b.Entry_ID = first_assign.Entry_ID
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID AND a.EventTimestamp = first_assign.FirstAssignmentTime AND SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217'
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Group Assigned' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus,
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217' AND a.Previous_Value = ''
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Investigation Initiated' AS ActivityName,
    a.EventTimestamp,
    'In Progress' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE 
    SUBSTRING(a.Fields_Changed, 1, 8) = '7       '
    AND CHARINDEX('Assigned', a.Previous_Value) > 0
    AND CHARINDEX('In Progress', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Transferred To Another Group' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus,
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217' AND a.Previous_Value <> ''
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Pending Customer Input' AS ActivityName,
    a.EventTimestamp,
    'Pending' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Pending', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Capturing this as 'Resolution Implemented' based on status change
SELECT
    b.IncidentId,
    'Resolution Implemented' AS ActivityName,
    a.EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Resolved', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Capturing 'Awaiting User Confirmation' from the same status change event
SELECT
    b.IncidentId,
    'Awaiting User Confirmation' AS ActivityName,
    a.EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Resolved', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Reopened' AS ActivityName,
    a.EventTimestamp,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    'true' AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE 
    SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' 
    AND CHARINDEX('Resolved', a.Previous_Value) > 0 
    AND CHARINDEX('Resolved', a.Fields_Changed) = 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Using Last_Resolved_Date for the official 'Incident Resolved' activity
SELECT
    b.IncidentId,
    'Incident Resolved' AS ActivityName,
    b.Last_Resolved_Date AS EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Last_Resolved_Date IS NOT NULL

UNION ALL

-- Inferring 'User Confirmation Received' from the closure event
SELECT
    b.IncidentId,
    'User Confirmation Received' AS ActivityName,
    b.Closed_Date AS EventTimestamp,
    'Closed' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Closed_Date IS NOT NULL

UNION ALL

SELECT
    b.IncidentId,
    'SLA Breach' AS ActivityName,
    b.Target_Date AS EventTimestamp,
    b.FinalStatus AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    'true' AS IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.IsSlaBreached = 'true' AND b.Target_Date IS NOT NULL

UNION ALL

SELECT
    b.IncidentId,
    'Incident Cancelled' AS ActivityName,
    a.EventTimestamp,
    'Cancelled' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Cancelled', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Closed' AS ActivityName,
    b.Closed_Date AS EventTimestamp,
    'Closed' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Closed_Date IS NOT NULL;

Schritte

Voraussetzungen und Einrichtung der Umgebung: Stellen Sie sicher, dass Python 3.6 oder neuer installiert ist. Installieren Sie die erforderliche Bibliothek requests, indem Sie in der Befehlszeile oder im Terminal pip install requests ausführen. Besorgen Sie sich API-Zugangsdaten, also Benutzername und Passwort, für ein BMC Helix-Benutzerkonto mit mindestens schreibgeschützten Berechtigungen für die Formulare 'HPD:Help Desk' und 'HPD:Help Desk Audit Log'.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_incidents.py. Öffnen Sie die Datei und passen Sie die Konfigurationsvariablen am Anfang an Ihre Umgebung und den gewünschten Datenumfang an: HELIX_HOSTNAME, HELIX_USERNAME, HELIX_PASSWORD, START_DATE, END_DATE und COMPANY_NAME.
Authentifizierung verstehen: Das Skript ruft zunächst den Endpunkt /api/jwt/login auf, um sich bei Ihrer BMC Helix-Instanz anzumelden. Es erhält ein JSON Web Token (JWT), das anschließend als Autorisierungsheader für alle weiteren Datenabfragen dient.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_incidents.py. Während der Ausführung zeigt das Skript den Fortschritt in der Konsole an.
Erste Vorfalldaten abrufen: Das Skript fragt den REST-API-Endpunkt 'HPD:Help Desk' ab, um alle Vorfälle im angegebenen Zeitraum abzurufen. Mithilfe der Paginierungsparameter limit und offset verarbeitet es auch große Vorfallzahlen effizient, ohne die API zu überlasten.
Audit-Log abrufen: Für jeden im vorherigen Schritt abgerufenen Vorfall stellt das Skript eine separate API-Anfrage an das Formular 'HPD:Help Desk Audit Log'. So ruft es den detaillierten Änderungsverlauf jedes Vorfalls ab, der für die Ermittlung von Aktivitäten wie Statusänderungen und Neuzuweisungen wichtig ist.
Ereignisse ableiten und Logik anwenden: Das Skript verarbeitet die Daten im Arbeitsspeicher und führt den Hauptdatensatz jedes Vorfalls mit dem zugehörigen Audit-Log zusammen. Anschließend durchläuft es die sortierten Audit-Log-Einträge und leitet daraus die angegebenen Aktivitäten ab. Beim ersten Auftreten des Felds 'Assigned Group' im Log wird beispielsweise ein Ereignis 'Group Assigned' erstellt. Eine Statusänderung von 'Resolved' zu 'In Progress' erzeugt das Ereignis 'Incident Reopened'.
Berechnete Ereignisse verarbeiten: Das Skript berechnet Ereignisse, die nicht direkt protokolliert werden. 'Incident Reported' wird aus dem 'Submit Date' abgeleitet. 'SLA Breach' ergibt sich aus dem Vergleich von 'Last Resolved Date' mit dem 'Target Date'.
Daten strukturieren: Für jede erkannte Aktivität erstellt das Skript ein Wörterbuch mit IncidentId, ActivityName, EventTimestamp sowie allen weiteren erforderlichen und empfohlenen Attributen. Diese Wörterbücher werden in einer gemeinsamen Liste gesammelt.
CSV-Datei erstellen: Nachdem alle Vorfälle und die zugehörigen Aktivitäten verarbeitet wurden, schreibt die integrierte Python-Bibliothek csv das fertige Event Log in eine Datei namens bmc_helix_incident_log.csv. Die Datei wird im selben Verzeichnis erstellt, aus dem Sie das Skript ausgeführt haben.
Abschließende Prüfung und Upload: Öffnen Sie die erstellte CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie den Inhalt. Kontrollieren Sie, ob Spalten und Daten korrekt aussehen. Anschließend können Sie die Datei zur Analyse in ProcessMind hochladen.

Konfiguration

HELIX_HOSTNAME: Die Basis-URL Ihrer BMC Helix ITSM-Umgebung, zum Beispiel „https://your-company.bmc.com“.
HELIX_USERNAME: Der Benutzername des API-Kontos für die Authentifizierung.
HELIX_PASSWORD: Das Passwort des API-Kontos. In Produktionsumgebungen empfiehlt es sich, Zugangsdaten in Umgebungsvariablen oder einem sicheren Tool zur Geheimnisverwaltung abzulegen.
START_DATE / END_DATE: Der Extraktionszeitraum im Format „YYYY-MM-DDTHH:MM:SS.sssZ“. Für eine erste Analyse empfehlen wir einen Zeitraum von 3 bis 6 Monaten. So erhalten Sie einen repräsentativen Datensatz, ohne ein übermäßiges Datenvolumen zu erzeugen.
COMPANY_NAME: Der Name des Unternehmens, nach dem die Vorfälle gefiltert werden sollen. In Umgebungen mit mehreren Mandanten ist dieser Wert entscheidend, um den Datenumfang korrekt einzugrenzen. Wenn kein Filter erforderlich ist, können Sie den Wert auf None setzen.
PAGE_SIZE: Die Anzahl der Vorfälle, die pro API-Anfrage abgerufen werden. Ein Wert zwischen 500 und 1000 ist in der Regel effizient. Je nach Leistung Ihrer Instanz und den Ratenbegrenzungen der API kann eine Anpassung erforderlich sein.
Voraussetzungen: Das Skript benötigt ein BMC Helix-Benutzerkonto mit mindestens Leseberechtigung für die Formulare HPD:Help Desk und HPD:Help Desk Audit Log. Ohne Zugriff auf beide Formulare ist die Extraktion unvollständig.

Beispielabfrage python

import requests
import json
import csv
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
HELIX_HOSTNAME = class="hl-string">"https://[your-helix-instance].bmc.com"
HELIX_USERNAME = class="hl-string">"[your_api_username]"
HELIX_PASSWORD = class="hl-string">"[your_api_password]"

class=class="hl-string">"hl-comment"># Date range for the query (ISO 8601 format)
START_DATE = class="hl-string">"2023-01-01T00:00:00.000Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59.000Z"

class=class="hl-string">"hl-comment"># Optional: Filter by company for multi-tenant environments
COMPANY_NAME = class="hl-string">"[Your Company Name]"  class=class="hl-string">"hl-comment"># Set to None if not needed

PAGE_SIZE = 1000
OUTPUT_CSV_FILE = class="hl-string">'bmc_helix_incident_log.csv'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

def get_jwt_token(session):
    class="hl-string">"""Authenticates with the BMC Helix API and returns a JWT token."""
    login_url = fclass="hl-string">"{HELIX_HOSTNAME}/api/jwt/login"
    auth_data = {class="hl-string">'username': HELIX_USERNAME, class="hl-string">'password': HELIX_PASSWORD}
    try:
        response = session.post(login_url, data=auth_data, headers={class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'})
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error during authentication: {e}")
        return None

def get_all_incidents(session, token):
    class="hl-string">"""Retrieves all incident records within the specified date range."""
    all_incidents = []
    offset = 0
    url = fclass="hl-string">"{HELIX_HOSTNAME}/api/arsys/v1/entry/HPD:Help Desk"
    headers = {class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}', class="hl-string">'Content-Type': class="hl-string">'application/json'}
    
    qualification = fclass="hl-string">"'Submit Date' >= \"{START_DATE}\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}\class="hl-string">""
    if COMPANY_NAME:
        qualification += fclass="hl-string">" AND 'Company' = \"{COMPANY_NAME}\class="hl-string">""

    fields = (
        class="hl-string">"Incident Number,Submit Date,Last Resolved Date,Closed Date,Status,Priority,Assigned Group,"
        class="hl-string">"Assignee,ServiceCI,Operational Categorization Tier 1,Operational Categorization Tier 2,"
        class="hl-string">"Product Categorization Tier 1,Product Categorization Tier 2,Target Date"
    )

    while True:
        params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({fields})', class="hl-string">'limit': PAGE_SIZE, class="hl-string">'offset': offset}
        print(fclass="hl-string">"Fetching incidents, offset: {offset}...")
        try:
            response = session.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            entries = data.get(class="hl-string">'entries', [])
            if not entries:
                break
            all_incidents.extend(entries)
            offset += len(entries)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching incidents: {e}")
            break
    return all_incidents

def get_audit_log(session, token, incident_id):
    class="hl-string">"""Retrieves the audit log for a single incident."""
    url = fclass="hl-string">"{HELIX_HOSTNAME}/api/arsys/v1/entry/HPD:Help Desk Audit Log"
    headers = {class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}', class="hl-string">'Content-Type': class="hl-string">'application/json'}
    qualification = fclass="hl-string">"'Incident Number' = \"{incident_id}\class="hl-string">""
    fields = class="hl-string">"Log,Fields Changed,Log Key,Audit Date"
    params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({fields})'}
    try:
        response = session.get(url, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()
        return sorted(data.get(class="hl-string">'entries', []), key=lambda x: x[class="hl-string">'values'][class="hl-string">'Audit Date'])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audit log for {incident_id}: {e}")
        return []

def parse_timestamp(ts):
    if not ts: return None
    try:
        return datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z').strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    except ValueError:
        try:
            return datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%S%z').strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
        except ValueError:
            return ts

def main():
    event_log = []
    with requests.Session() as session:
        token = get_jwt_token(session)
        if not token:
            return

        incidents = get_all_incidents(session, token)
        total = len(incidents)
        print(fclass="hl-string">"Found {total} incidents to process.")

        for index, incident_entry in enumerate(incidents):
            incident = incident_entry[class="hl-string">'values']
            incident_id = incident.get(class="hl-string">'Incident Number')
            print(fclass="hl-string">"Processing incident {index + 1}/{total}: {incident_id}")

            base_attributes = {
                class="hl-string">'IncidentId': incident_id,
                class="hl-string">'Priority': incident.get(class="hl-string">'Priority'),
                class="hl-string">'Service': incident.get(class="hl-string">'ServiceCI'),
                class="hl-string">'IncidentCategory': fclass="hl-string">"{incident.get('Product Categorization Tier 1', '')} / {incident.get('Product Categorization Tier 2', '')}",
            }
            
            class=class="hl-string">"hl-comment"># 1. Incident Reported
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Incident Reported',
                class="hl-string">'EventTimestamp': parse_timestamp(incident.get(class="hl-string">'Submit Date')),
                class="hl-string">'IncidentStatus': class="hl-string">'New', class=class="hl-string">"hl-comment"># Typically starts as New
                class="hl-string">'AssignedGroup': incident.get(class="hl-string">'Assigned Group'),
                class="hl-string">'Assignee': incident.get(class="hl-string">'Assignee'),
            })

            audit_entries = get_audit_log(session, token, incident_id)

            current_group = None
            last_status = class="hl-string">'New'
            is_reopened = False
            group_assigned = False

            for audit in audit_entries:
                audit_values = audit[class="hl-string">'values']
                event_ts = parse_timestamp(audit_values.get(class="hl-string">'Audit Date'))
                log_key = audit_values.get(class="hl-string">'Log Key')
                fields_changed = audit_values.get(class="hl-string">'Fields Changed', class="hl-string">'')

                class=class="hl-string">"hl-comment"># 2. Group Assigned & 3. Transferred To Another Group
                if class="hl-string">'Assigned Group' in fields_changed:
                    new_group = audit_values.get(class="hl-string">'Log').split(class="hl-string">'\n')[0]
                    if new_group and not group_assigned:
                        activity = class="hl-string">'Group Assigned'
                        group_assigned = True
                    elif new_group and new_group != current_group:
                        activity = class="hl-string">'Transferred To Another Group'
                    else:
                        continue
                    current_group = new_group
                    event_log.append({**base_attributes, class="hl-string">'ActivityName': activity, class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': last_status, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

                class=class="hl-string">"hl-comment"># Status-based activities
                if class="hl-string">'Status' in fields_changed:
                    new_status_str = audit_values.get(class="hl-string">'Log').split(class="hl-string">'\n')[0]
                    new_status_map = {
                        class="hl-string">'In Progress': class="hl-string">'Investigation Initiated',
                        class="hl-string">'Pending': class="hl-string">'Pending Customer Input',
                        class="hl-string">'Resolved': class="hl-string">'Resolution Implemented', class=class="hl-string">"hl-comment"># First event is implementation
                        class="hl-string">'Cancelled': class="hl-string">'Incident Cancelled',
                        class="hl-string">'Closed': class="hl-string">'Incident Closed' class=class="hl-string">"hl-comment"># Final closure
                    }
                    
                    if last_status == class="hl-string">'Resolved' and new_status_str in [class="hl-string">'In Progress', class="hl-string">'Assigned']:
                        is_reopened = True
                        event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Reopened', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

                    if new_status_str in new_status_map:
                        activity = new_status_map[new_status_str]
                        event_log.append({**base_attributes, class="hl-string">'ActivityName': activity, class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                        class=class="hl-string">"hl-comment"># Add specific Resolution/Confirmation events
                        if new_status_str == class="hl-string">'Resolved':
                             event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                             event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Awaiting User Confirmation', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                    
                    last_status = new_status_str

            class=class="hl-string">"hl-comment"># 4. Incident Categorized (approximated as last categorization change before resolution)
            cat_events = [a for a in audit_entries if class="hl-string">'Operational Categorization Tier 1' in a[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'') or class="hl-string">'Product Categorization Tier 1' in a[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'')]
            if cat_events:
                last_cat_event = cat_events[-1]
                event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Categorized', class="hl-string">'EventTimestamp': parse_timestamp(last_cat_event[class="hl-string">'values'][class="hl-string">'Audit Date']), class="hl-string">'IncidentStatus': last_status, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

            class=class="hl-string">"hl-comment"># Add placeholder for User Confirmation Received - often not explicit
            if incident.get(class="hl-string">'Status') == class="hl-string">'Closed' and incident.get(class="hl-string">'Last Resolved Date'):
                class=class="hl-string">"hl-comment"># This is an approximation, real confirmation might be earlier
                event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'User Confirmation Received', class="hl-string">'EventTimestamp': parse_timestamp(incident.get(class="hl-string">'Closed Date')), class="hl-string">'IncidentStatus': class="hl-string">'Closed', class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

            class=class="hl-string">"hl-comment"># 5. SLA Breach (calculated)
            is_sla_breached = False
            target_date_str = incident.get(class="hl-string">'Target Date')
            resolved_date_str = incident.get(class="hl-string">'Last Resolved Date')
            if target_date_str and resolved_date_str:
                target_dt = datetime.strptime(target_date_str, class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolved_dt = datetime.strptime(resolved_date_str, class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                if resolved_dt > target_dt:
                    is_sla_breached = True
                    event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'SLA Breach', class="hl-string">'EventTimestamp': parse_timestamp(target_date_str), class="hl-string">'IncidentStatus': incident.get(class="hl-string">'Status'), class="hl-string">'AssignedGroup': incident.get(class="hl-string">'Assigned Group'), class="hl-string">'Assignee': incident.get(class="hl-string">'Assignee')})

            class=class="hl-string">"hl-comment"># Final attributes update
            resolution_time = None
            if incident.get(class="hl-string">'Submit Date') and incident.get(class="hl-string">'Last Resolved Date'):
                submit_dt = datetime.strptime(incident.get(class="hl-string">'Submit Date'), class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolved_dt = datetime.strptime(incident.get(class="hl-string">'Last Resolved Date'), class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolution_time = (resolved_dt - submit_dt).total_seconds()
            
            for event in event_log:
                if event[class="hl-string">'IncidentId'] == incident_id:
                    event[class="hl-string">'IsSlaBreached'] = is_sla_breached
                    event[class="hl-string">'IsReopened'] = is_reopened
                    event[class="hl-string">'IncidentResolutionTime'] = resolution_time
            
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to be kind to the API

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        fieldnames = [class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'IncidentStatus', class="hl-string">'Priority', class="hl-string">'AssignedGroup', class="hl-string">'Assignee', class="hl-string">'Service', class="hl-string">'IncidentCategory', class="hl-string">'IncidentResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'IsReopened']
        with open(OUTPUT_CSV_FILE, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=fieldnames, extrasaction=class="hl-string">'ignore')
            writer.writeheader()
            writer.writerows(sorted(event_log, key=lambda x: (x[class="hl-string">'IncidentId'], x[class="hl-string">'EventTimestamp'])))
        print(fclass="hl-string">"Successfully wrote {len(event_log)} events to {OUTPUT_CSV_FILE}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Möchten Sie loslegen?

Verwenden Sie dieses Template als Ausgangspunkt für Ihr Process Mining und gewinnen Sie wertvolle Erkenntnisse aus Ihren Incident-Management-Daten. Beginnen Sie noch heute mit der Optimierung Ihrer Abläufe.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Beheben Sie wiederkehrende Vorfälle in BMC Helix ITSM noch heute!

Senken Sie die MTTR um 35 % und vermeiden Sie SLA-Überschreitungen. So steigern Sie die Zufriedenheit der Benutzer.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Kostenlose 14-tägige Testphase.

Ihr Daten-Template für das Incident Management

Ihr Daten-Template für das Incident Management

Attribute des Incident Managements

Aktivitäten des Incident Managements

Anleitungen zur Datenextraktion

BMC Helix Smart Reporting: Export als CSV

Schritte

Konfiguration

Beispielabfrage sql

Direkte SQL-Abfrage in den Vorfalltabellen der ITSM-Datenbank

Schritte

Konfiguration

Beispielabfrage sql

Datenextraktion mit einem Python-Skript über die BMC Helix REST API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Beheben Sie wiederkehrende Vorfälle in BMC Helix ITSM noch heute!