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

Ihr Daten-Template für das Incident Management

BMC Helix ITSM

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 bietet eine umfassende Anleitung zur Erfassung der wesentlichen Daten, die Sie für die Optimierung Ihres Incident-Management-Prozesses benötigen. Es beschreibt die wichtigsten Attribute und Aktivitäten, die Sie erfassen sollten, und zeigt, wie Sie diese Daten auslesen. Verwenden Sie diese Ressource, um Ihre Datenvorbereitung zu vereinfachen und Ihre Prozessanalyse schneller zu starten.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für Ihren Prozess
Anleitung zur Datenextraktion aus Ihrem Datensystem

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

Template herunterladen

Attribute des Incident Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine gründliche Analyse Ihres Incident-Management-Prozesses in Ihr Event Log aufnehmen sollten.

3 Erforderlich 8 Empfohlen 10 Optional

	Name	Beschreibung
	Incident-ID IncidentId	Die eindeutige Kennung für jeden Incident-Datensatz.
Beschreibung Die Incident ID dient als Primärschlüssel für jeden Incident und identifiziert ihn von der Erstellung bis zum Abschluss eindeutig. Sie verknüpft alle zugehörigen Aktivitäten, Logs und Änderungen und ermöglicht so eine vollständige End-to-End-Sicht auf den Lebenszyklus des Incidents. Im Process Mining ist dieses Attribut grundlegend, da es den Case definiert. Jedes Event mit derselben Incident ID gilt als Teil derselben Prozessinstanz. Dadurch lässt sich rekonstruieren und analysieren, wie einzelne Incidents bearbeitet werden. Warum das wichtig ist Dies ist die zentrale Case-Kennung, die alle Events im Lebenszyklus eines Incidents verbindet und eine End-to-End-Prozessanalyse ermöglicht. Bezugsquelle Dies ist das Feld „Incident Number“ (Field ID: 1000000161) im Formular „HPD:Help Desk“. Beispiele INC000001234567INC000002345678INC000003456789
	Aktivitätsname ActivityName	Der Name des konkreten Events oder der Aufgabe, die im Lebenszyklus des Incidents stattgefunden hat.
Beschreibung Dieses Attribut beschreibt die Aktivität, die zu einem bestimmten Zeitpunkt für einen Incident ausgeführt wurde, etwa „Incident Reported“, „Group Assigned“ oder „Incident Resolved“. Diese Aktivitäten bilden die Grundlage der Prozesskarte. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten zeigt den tatsächlichen Prozessfluss, macht häufige Pfade sichtbar und weist auf Abweichungen vom Standardverfahren hin. Sie ist entscheidend, um zu verstehen, welche Maßnahmen zur Lösung eines Incidents ergriffen werden. Warum das wichtig ist Aktivitäten definieren die Schritte in der Prozesskarte und ermöglichen die Visualisierung und Analyse des Incident-Management-Workflows. Bezugsquelle In der Regel abgeleitet aus Änderungen an „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 geschlossen
	Event-Timestamp EventTimestamp	Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat.
Beschreibung Dieser Timestamp erfasst, wann ein bestimmtes Event im Lebenszyklus des Incidents stattgefunden hat. Er liefert die chronologische Reihenfolge, die erforderlich ist, um den Prozessfluss aus Rohdaten zu rekonstruieren. Der Event-Timestamp ist für alle zeitbezogenen Analysen entscheidend. Dazu gehören die Berechnung von Durchlaufzeiten zwischen Aktivitäten, die Identifizierung von Engpässen mit langen Wartezeiten sowie die Messung der gesamten Lösungszeit. Er bildet das zeitliche Rückgrat der Prozessanalyse. Warum das wichtig ist Dieser Timestamp liefert die chronologische Reihenfolge der Events. Das ist entscheidend für die Berechnung von Zeitdauern, die Identifizierung von Engpässen und das Verständnis des zeitlichen Prozessverlaufs. Bezugsquelle Das Feld „Last Modified Date“ (Field ID: 6) oder spezifische 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
	Bearbeiter Assignee	Der einzelne Benutzer, der mit der Bearbeitung des Incidents beauftragt ist.
Beschreibung Der Bearbeiter ist der konkrete Supportmitarbeiter oder Techniker, der zu einem bestimmten Zeitpunkt für den Incident verantwortlich ist. Das liefert eine detailliertere Sicht als die zugewiesene Gruppe. Die Analyse der Leistung nach Bearbeiter kann dabei helfen, besonders leistungsstarke Mitarbeiter, zusätzlichen Schulungsbedarf und eine unausgewogene Arbeitsverteilung zu erkennen. Außerdem lässt sich damit die genaue Abfolge der Aktionen nachvollziehen, die einzelne Personen bei der Bearbeitung eines komplexen Incidents ausgeführt haben. Warum das wichtig ist Ermöglicht eine detaillierte Sicht auf die Arbeitsverteilung und die individuelle Leistung. So lassen sich besonders leistungsstarke Mitarbeiter oder Agents mit Unterstützungsbedarf erkennen. Bezugsquelle Dies ist das Feld „Assignee“ (Field ID: 1000000218) im Formular „HPD:Help Desk“. Beispiele Bob SmithAlice JohnsonCharlie Brown
	Erneut geöffnet IsReopened	Ein Kennzeichen dafür, ob ein Incident nach dem Status „Resolved“ erneut geöffnet wurde.
Beschreibung Dieses boolesche Attribut ist wahr, wenn der Status eines Incidents nach der Markierung als „Resolved“ wieder in einen aktiven Zustand, etwa „In Progress“, gewechselt hat. Das weist darauf hin, dass die ursprüngliche Lösung nicht wirksam oder nicht vollständig war. Dies ist ein direktes Maß für Nacharbeit und wird zur Berechnung der KPI „Incident-Nacharbeitsrate“ verwendet. Die Analyse erneut geöffneter Incidents hilft dabei, Lösungen mit geringer Qualität, unzureichende Tests oder nicht vollständig 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 Rate erneut geöffneter Incidents weist auf unwirksame Lösungen und Schwächen im Prozess hin. Bezugsquelle Wird durch die Analyse der Aktivitätssequenz eines Incidents berechnet. Wenn nach einer Aktivität „Resolution Implemented“ eine Aktivität „Incident Reopened“ oder eine vergleichbare Aktivität erscheint, 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 Zustand des Incidents an, etwa „New“, „In Progress“, „Pending“, „Resolved“ oder „Closed“. Es zeigt, an welcher Stelle des Lebenszyklus sich der Incident befindet. Die Analyse von Statusänderungen ist grundlegend für das Verständnis des Incident-Management-Prozesses. Sie dient dazu, Aktivitäten zu definieren, die in verschiedenen Zuständen verbrachte Zeit zu messen, etwa wie lange Incidents „Pending“ sind, und möglicherweise feststeckende oder inaktive Incidents zu erkennen. Warum das wichtig ist Die Nachverfolgung von Statusänderungen ist entscheidend, um den Fortschritt eines Incidents zu verstehen und zu messen, wie lange er sich in bestimmten Zuständen wie „Pending“ oder „In Progress“ befindet. Bezugsquelle Dies ist das Feld „Status“ (Field ID: 7) im Formular „HPD:Help Desk“. Beispiele NeuZugewiesenIn BearbeitungPendingResolvedGeschlossen
	Incidentkategorie IncidentCategory	Die Klassifizierung des Incidents, häufig in einer hierarchischen Struktur.
Beschreibung Die Incident-Kategorisierung bietet eine strukturierte Möglichkeit, Incidents zu klassifizieren, typischerweise anhand einer mehrstufigen Hierarchie, zum Beispiel Ebene 1: Hardware, Ebene 2: Laptop, Ebene 3: Akku. Diese Daten sind für Routing, Reporting und Trendanalysen unerlässlich. Im Process Mining wird die Kategorisierung verwendet, um verschiedene Incident-Typen getrennt zu analysieren. Sie unterstützt das Dashboard zur Genauigkeit der Incident-Kategorisierung, indem anfängliche und abschließende Kategorien verglichen werden, und hilft dabei, Trends für das Dashboard zu Root-Cause-Trends zu erkennen. Warum das wichtig ist Die Kategorisierung ermöglicht präzises Routing, Trendanalysen und Leistungsvergleiche zwischen verschiedenen Incident-Typen. Bezugsquelle Dabei handelt es sich um die Felder „Operational Categorization Tier 1/2/3“ im Formular „HPD:Help Desk“. Beispiele Hardware > Laptop > AkkuSoftware > Unternehmensanwendung > AnmeldefehlerNetzwerk > Konnektivität > WLAN
	Priorität Priority	Die dem Incident zugewiesene Prioritätsstufe, die die Dringlichkeit seiner Bearbeitung bestimmt.
Beschreibung Die Priorität wird in der Regel aus der Kombination von Auswirkung und Dringlichkeit abgeleitet und bestimmt Reihenfolge und Geschwindigkeit der Incident-Lösung. Übliche Werte reichen von „Critical“ bis „Low“. 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 „Erleben Incidents mit niedriger Priorität längere Verzögerungen?“ Eine Filterung nach Priorität ermöglicht eine gezielte Analyse der kritischsten Geschäftsprobleme. Warum das wichtig ist Dieses Attribut ist entscheidend, um Analysen zu segmentieren und sicherzustellen, dass Incidents mit hoher Priorität schneller bearbeitet und ihre spezifischen Serviceziele eingehalten werden. Bezugsquelle 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 Incident betroffen ist.
Beschreibung Dieses Attribut verknüpft einen Incident mit einem bestimmten Service in der Configuration Management Database (CMDB), etwa „Email Service“, „VPN Access“ oder „SAP Financials“. Diese Verknüpfung ist entscheidend, um die geschäftlichen Auswirkungen von Incidents zu verstehen. Die Analyse nach Service hilft, problematische Services mit einem hohen Incident-Aufkommen zu erkennen, wiederkehrende Probleme bestimmter Technologien sichtbar zu machen und die Trendanalyse im Problem Management zu unterstützen. Warum das wichtig ist Die Verknüpfung von Incidents mit Geschäftsservices ist entscheidend für die Auswirkungsanalyse und die Identifizierung der Services, bei denen besonders häufig Probleme auftreten. Bezugsquelle Dies ist das Feld „ServiceCI“ oder ein vergleichbares Feld, das das betroffene Configuration Item (CI) im Formular „HPD:Help Desk“ repräsentiert. Beispiele Unternehmens-E-MailSAP ERPVPN für RemotezugriffPersonalportal
	SLA verletzt IsSlaBreached	Ein Kennzeichen dafür, ob der Incident nach seinem SLA-Zieldatum gelöst wurde.
Beschreibung Dieses boolesche Attribut ist wahr, wenn die Lösungszeit des Incidents das festgelegte SLA überschritten hat. Es liefert für jeden Incident ein eindeutiges binäres Ergebnis zur SLA-Leistung. Das Kennzeichen ist entscheidend für das Dashboard zur Übersicht der Incident-SLA-Leistung und für die Berechnung der KPI „SLA-Einhaltungsrate bei Incidents“. Es vereinfacht die Analyse, da alle Incidents, die ihre Serviceziele nicht erreicht haben, direkt gefiltert und aggregiert werden können. So lassen sich die Gründe für SLA-Verletzungen gezielt untersuchen. Warum das wichtig ist Dieses Kennzeichen vereinfacht die Analyse der SLA-Einhaltung. Alle Incidents mit SLA-Verletzung lassen sich leicht filtern und auf ihre Root Causes untersuchen. Bezugsquelle Wird durch den Vergleich des Event-Timestamps von „Incident Resolved“ mit „SlaTargetDate“ berechnet. Liegt der Lösungs-Timestamp nach dem Zieldatum, ist dieses Kennzeichen wahr. Beispiele truefalse
	Zugewiesene Gruppe AssignedGroup	Die Supportgruppe, die für die Bearbeitung des Incidents verantwortlich ist.
Beschreibung Dieses Attribut identifiziert das Team oder die Abteilung, die dem Incident zugewiesen ist, etwa „Service Desk“, „Network Team“ oder „Database Administrators“. Die Nachverfolgung von Zuweisungen ist entscheidend, um den Arbeitsfluss zwischen Teams zu verstehen. Mit diesem Attribut lassen sich Übergaben zwischen Teams analysieren, durch bestimmte Gruppen verursachte Engpässe erkennen und die Incident Reassignment Rate messen. Es visualisiert den Weg eines Incidents durch die Organisation und zeigt Bereiche mit ineffizienter Weiterleitung oder Wissenslücken auf. Warum das wichtig ist Die Nachverfolgung der zugewiesenen Gruppe hilft, Übergaben zu analysieren, Schleifen bei Neuzuweisungen zu erkennen und Engpässe in bestimmten Teams zu lokalisieren. Bezugsquelle Dies ist das Feld „Assigned Group“ (Field ID: 1000000217) im Formular „HPD:Help Desk“. Beispiele Service DeskNetzwerkbetriebAnwendungssupport, Stufe 2Infrastrukturdienste
	Abschlusscode CloseCode	Der beim Schließen eines Incidents ausgewählte Code, der das Ergebnis der Lösung angibt.
Beschreibung Der Abschlusscode fasst strukturiert zusammen, wie ein Incident gelöst wurde. Beispiele sind „Vom Benutzer gelöst“, „Kein Fehler gefunden“, „Doppelter Incident“ oder „Dauerhafte Lösung umgesetzt“. Dieses Attribut ist wertvoll für die Analyse der Wirksamkeit und Ergebnisse von Lösungen. Es kann dabei helfen, Incidents zu identifizieren, die ohne tatsächliche Behebung geschlossen wurden, oder Kategorien hervorzuheben, in denen Benutzer ihre Probleme häufig selbst lösen. Das kann auf Möglichkeiten für bessere Wissensdatenbankartikel oder Self-Service-Tools hinweisen. Warum das wichtig ist Liefert strukturierte Daten zu den Ergebnissen von Lösungen. Dadurch lässt sich die Wirksamkeit von Behebungen analysieren und erkennen, wie Incidents geschlossen werden. Bezugsquelle Dieses Feld gehört typischerweise zu den Informationen zur Lösung oder zum Abschluss im Formular „HPD:Help Desk“. Beispiele Remote gelöstDoppeltes ProblemBenutzerfehlerKeine Aktion erforderlich
	Anzahl der Neuzuweisungen ReassignmentCount	Die Gesamtzahl der Fälle, in denen ein Incident einer anderen Gruppe zugewiesen wurde.
Beschreibung Diese Kennzahl zählt, wie oft sich das Feld „AssignedGroup“ während des Lebenszyklus eines Incidents geändert hat. Ein hoher Wert deutet auf Probleme beim initialen Routing, eine geringe Lösungsquote beim Erstkontakt oder komplexe Probleme hin, die den Beitrag mehrerer Teams erfordern. Dieses Attribut unterstützt direkt die KPI „Incident-Neuzuweisungsrate“ und das Dashboard „Zyklus-Analyse der Incident-Neuzuweisungen“. Es hilft, den Pingpong-Effekt zu quantifizieren, bei dem Tickets zwischen Teams hin- und hergereicht werden. Das führt zu erheblichen Verzögerungen und ineffizienten Prozessen. Warum das wichtig ist Quantifiziert ineffizientes Routing und Übergaben. So lassen sich Incidents identifizieren, die in Neuzuweisungsschleifen zwischen Teams feststecken. Bezugsquelle Wird berechnet, indem die Anzahl der Änderungen des Werts „AssignedGroup“ für eine bestimmte Incident-ID im Event Log gezählt wird. Beispiele 0135
	Auswirkung Impact	Das Maß für die Auswirkung eines Incidents auf Geschäftsprozesse.
Beschreibung Die Auswirkung bewertet das Ausmaß, in dem ein Incident das Unternehmen beeinträchtigt. Sie wird häufig anhand einer Skala definiert, etwa „Umfassend/Weitreichend“, „Erheblich/Groß“, „Moderat/Begrenzt“ oder „Gering/Lokal“. Zusammen mit der Dringlichkeit bestimmt die Auswirkung die Priorität des Incidents. Eine Analyse nach Auswirkung zeigt, welche Incidents die größten Beeinträchtigungen für das Unternehmen verursachen, unabhängig von ihrer technischen Komplexität. Das ist entscheidend, um Maßnahmen zur Prozessverbesserung zu priorisieren. Warum das wichtig ist Hilft dabei, den geschäftlichen Schweregrad eines Incidents zu quantifizieren. Dieser ist ein wesentlicher Faktor für die Prioritätsbestimmung und lenkt die Analyse auf Probleme mit großer Auswirkung. Bezugsquelle Dies ist das Feld „Impact“ (Field ID: 1000000163) im Formular „HPD:Help Desk“. Beispiele 1-Umfassend/Weitreichend2-Erheblich/Groß3-Mittel/Begrenzt4-Gering/Lokal begrenzt
	Kanal Channel	Die Methode, mit der der Incident gemeldet wird.
Beschreibung Dieses Attribut gibt an, wie der Incident eingereicht wurde, zum Beispiel per Telefon, E-Mail, Self-Service-Portal oder direkt vor Ort. Es zeigt den Eingangspunkt des Incidents in den Supportprozess. Die Analyse von Incidents nach Kanal kann zeigen, welche Kanäle besonders wirksam sind und über welche Kanäle Incidents eingehen, die sich leichter oder schwieriger lösen lassen. Sie kann außerdem Entscheidungen darüber unterstützen, in welche Automatisierung oder Benutzerschulungen investiert werden sollte, etwa indem die Nutzung eines Self-Service-Portals gefördert wird, das bessere Anfangsdaten erfasst. Warum das wichtig ist Das Verständnis des Eingangskanals hilft bei der Analyse der Effizienz verschiedener Erfassungsmethoden und kann Investitionen in Self-Service oder Automatisierung unterstützen. Bezugsquelle Dies ist das Feld „Reported Source“ (Field ID: 1000000215) im Formular „HPD:Help Desk“. Beispiele E-MailTelefonSelf-ServiceDirekteingabe
	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 liefert Kontext zur Aktualität der analysierten Daten und ist wichtig, um einzuordnen, wie aktuell die gewonnenen Prozesserkenntnisse sind. Die Kenntnis des letzten Aktualisierungszeitpunkts ist für Reporting und Dashboards entscheidend. Sie informiert über die Aktualität der Daten und hilft dabei, Erwartungen an die Berücksichtigung der neuesten Incident-Aktivitäten zu steuern. Warum das wichtig ist Zeigt die Aktualität der Daten an und stellt sicher, dass Benutzer den aktuellen Stand der Prozessanalyse und der daraus gewonnenen Erkenntnisse verstehen. Bezugsquelle Dieser Wert wird in der Regel während der Datenextraktion (ETL) im Datensatz erzeugt und mit einem Timestamp versehen. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
	Lösungsbeschreibung Resolution	Eine Freitextbeschreibung der Schritte, die zur Lösung des Incidents durchgeführt wurden.
Beschreibung Dieses Feld enthält die ausführliche, von einer Person verfasste Zusammenfassung der abschließenden Lösung. Es beschreibt, was getan wurde, um das Problem zu beheben und den Service für den Benutzer wiederherzustellen. Obwohl es sich um unstrukturierte Daten handelt, lässt sich dieser Text mit Text-Mining-Verfahren analysieren. So können häufige Lösungsmuster erkannt, Schlüsselwörter zu bestimmten Problemen extrahiert oder Root-Cause-Analysen ergänzt werden. Das Feld liefert qualitativen Kontext, der in strukturierten Datenfeldern häufig fehlt. Warum das wichtig ist Liefert qualitative Details zur Lösung. Diese können im Text Mining verwendet werden, um Muster zu erkennen, die in strukturierten Daten nicht sichtbar sind. Bezugsquelle 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-Raum 3B wurde neu gestartet.
	Meldende Person Submitter	Die Person, die den Incident ursprünglich gemeldet hat.
Beschreibung Die meldende Person ist der Endbenutzer oder Kunde, bei dem das Problem aufgetreten ist und der es gemeldet hat. Sie unterscheidet sich von der zugewiesenen Person, die am Incident arbeitet. Die Analyse nach meldender Person oder Abteilung kann bestimmte Benutzergruppen identifizieren, die zusätzliche Schulungen benötigen, oder Gruppen, die von einer bestimmten Problemart betroffen sind. Dadurch entsteht eine kundenorientierte Sicht auf den Incident-Management-Prozess. Warum das wichtig ist Identifiziert den Benutzer, der das Problem gemeldet hat. Dadurch sind Analysen nach Abteilung, Standort oder Rolle möglich, um benutzerspezifische Trends zu erkennen. Bezugsquelle 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 identifiziert die Herkunft der Daten. 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 zwischen Produktiv-, Entwicklungs- oder Altsystemen variieren können. So bleibt die Datenherkunft nachvollziehbar und verlässlich. Warum das wichtig ist Identifiziert die Herkunft der Daten. Das ist entscheidend für die Datenvalidierung und die Verwaltung von Analysen über mehrere integrierte Systeme hinweg. Bezugsquelle In der Regel ein statischer Wert, der während des Prozesses zur Extraktion, Transformation und zum Laden der Daten (ETL) hinzugefügt wird. Beispiele BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
	SLA-Zieldatum SlaTargetDate	Das Datum und die Uhrzeit, bis zu denen der Incident gemäß seinem SLA voraussichtlich gelöst sein soll.
Beschreibung Dieses Attribut speichert die Frist für die Lösung des Incidents gemäß dem geltenden Service Level Agreement (SLA). Die Frist wird anhand der Priorität des Incidents und der festgelegten Servicezeiten berechnet. Dieser Timestamp dient als Referenz für die Messung der tatsächlichen Lösungszeit. Er ist für die Berechnung der KPI „SLA-Einhaltungsrate bei Incidents“ und für Dashboards zur Visualisierung der SLA-Leistung unerlässlich. So können Incidents, deren Frist näher rückt, proaktiv überwacht werden. Warum das wichtig ist Dies ist die Referenz für die Messung der SLA-Einhaltung. Damit lässt sich berechnen, ob ein Incident fristgerecht gelöst wurde oder sein SLA verletzt hat. Bezugsquelle Diese Daten werden typischerweise im Formular „SLM:Measurement“ gespeichert und mit dem Incident verknüpft. Sie befinden sich nicht direkt im Feld „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 letztendliche Ursache des Incidents.
Beschreibung Die Root Cause ist das grundlegende Problem, dessen Behebung ein erneutes Auftreten des Incidents verhindern würde. Sie wird häufig im Rahmen der Untersuchung eines damit verbundenen Problems ermittelt. Nicht für jeden Incident wird eine Root Cause dokumentiert. Die Analyse dieses Attributs ist jedoch für ein proaktives Problemmanagement entscheidend. Sie unterstützt die KPI „Rate der Root-Cause-Ermittlung“ und hilft beim Erstellen von Dashboards, die Trends bei wiederkehrenden Problemen verfolgen. Dadurch lassen sich Maßnahmen zur Umsetzung dauerhafter Lösungen gezielt steuern. Warum das wichtig ist Die Ermittlung der Root Cause ist für das Problemmanagement und Analysen zur Reduzierung wiederkehrender Incidents unerlässlich. Bezugsquelle Diese Information kann in einem eigenen Feld „Root Cause“ im Incident oder häufiger in einem verknüpften Formular „PBI:Problem Investigation“ enthalten sein. Beispiele Nicht genügend Speicherplatz auf dem ServerFehler in der NetzwerkkonfigurationSoftwarefehler in Version 2.1Abgelaufenes Sicherheitszertifikat

Erforderlich Empfohlen Optional

Aktivitäten des Incident Managements

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie für eine präzise Prozesserkennung und Visualisierung des Prozessablaufs in Ihrem Event Log erfassen sollten.

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 aus dem ersten Befüllen des Feldes „Assigned Group“ nach der Erstellung des Incidents abgeleitet.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der den Beginn der aktiven Bearbeitung markiert. Die Zeit bis zur ersten Zuweisung ist entscheidend für die Bewertung der Reaktionszeit und der Effizienz der ersten Weiterleitung. Bezugsquelle Abgeleitet aus dem Audit Log („HPD:HelpDesk_AuditLogSystem“) für das Formular „HPD:Help Desk“, das das erstmalige Befüllen des Feldes „Assigned Group“ erfasst. Erfassen Aus dem Timestamp, zu dem das Feld „Assigned Group“ erstmals befüllt wird. Ereignistyp inferred
	Incident gelöst	Diese Aktivität kennzeichnet die offizielle Lösung des Incidents aus Sicht des Service Desks, bevor der endgültige Abschluss erfolgt. Sie wird erfasst, wenn der Status des Incidents auf „Resolved“ gesetzt wird.
Warum das wichtig ist Dies ist der wichtigste Meilenstein zur Messung der SLA-Konformität und der Lösungszeit. Er zeigt an, dass der Service für den Benutzer wiederhergestellt wurde. Bezugsquelle Dieses Event entspricht dem Setzen des Feldes „Status“ im Formular „HPD:Help Desk“ auf „Resolved“. Der Timestamp wird im Feld „Last Resolved Date“ und im Audit Log erfasst. Erfassen 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 und die Eingangsraten von Incidents zu berechnen. Bezugsquelle Dieses Event entspricht der Erstellung des Datensatzes im Formular „HPD:Help Desk“. Der Timestamp stammt in der Regel aus dem Feld „Submit Date“ oder „Reported Date“. Erfassen Aus dem Timestamp von „Submit Date“ im Formular „HPD:Help Desk“. Ereignistyp explicit
	Incident geschlossen	Dies ist die letzte Aktivität. Sie 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 definitive End-Event im Lebenszyklus eines Incidents. Die Zeit zwischen „Resolved“ und „Closed“ stellt den Zeitraum für die Bestätigung durch den Benutzer und die administrative Nachbearbeitung dar. Bezugsquelle Dieses Event entspricht dem Setzen des Feldes „Status“ im Formular „HPD:Help Desk“ auf „Closed“. Der Timestamp wird im Feld „Closed Date“ und im Audit Log erfasst. Erfassen Aus dem Timestamp von „Closed Date“ oder dem Statuswechsel zu „Closed“. Ereignistyp inferred
	Untersuchung gestartet	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 vom Warten 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 „Diagnosis & Investigation Bottlenecks“. Bezugsquelle Abgeleitet aus einer Statusänderung im Formular „HPD:Help Desk“. Das Event wird ausgelöst, wenn sich das Feld „Status“ in „In Progress“ ändert. Der Timestamp stammt aus dem Audit Log. Erfassen Abgeleitet aus dem Statuswechsel zu „In Progress“ im HPD:HelpDesk_AuditLogSystem. Ereignistyp inferred
	An eine andere Gruppe übertragen	Diese Aktivität tritt auf, wenn ein Incident von einer Supportgruppe an eine andere neu zugewiesen wird. Sie wird durch eine Änderung des Feldes „Assigned Group“ nach der ersten Zuweisung erkannt.
Warum das wichtig ist Häufige Übertragungen weisen auf eine fehlerhafte Erstzuweisung oder Wissenslücken hin. Die Nachverfolgung dieser Aktivität ist entscheidend für das Dashboard „Incident Reassignment Cycle Analysis“ und den KPI „Incident Reassignment Rate“. Bezugsquelle Abgeleitet aus dem Audit Log („HPD:HelpDesk_AuditLogSystem“), indem nach dem erstmaligen Befüllen weitere Änderungen am Feld „Assigned Group“ im Formular „HPD:Help Desk“ identifiziert werden. Erfassen Identifiziert Änderungen am Feld „Assigned Group“ nach der ersten Zuweisung. Ereignistyp inferred
	Bestätigung des Benutzers erhalten	Kennzeichnet die aktive Bestätigung des Benutzers, dass die bereitgestellte Lösung sein Problem behoben hat. Dies kann ein explizites Event sein oder aus Notizen beziehungsweise einer zugehörigen Systemaktion vor dem Abschluss abgeleitet werden.
Warum das wichtig ist Die Nachverfolgung liefert ein genaueres Bild des Benutzerbestätigungsprozesses als das bloße Warten auf die automatische Schließung. Sie hilft, den KPI „Average User Confirmation Time“ zu messen und Lücken in der Kommunikation zu erkennen. Bezugsquelle Dies lässt sich nur schwer zuverlässig erfassen. Das Event kann aus einem Work-Log-Eintrag oder einer bestimmten Änderung des Statusgrunds kurz vor dem Wechsel des Incidents zu „Closed“ abgeleitet werden. Möglicherweise ist dafür eine Analyse des Formulars „HPD:WorkLog“ erforderlich. Erfassen Abgeleitet aus bestimmten Work-Log-Einträgen oder Änderungen des Statusgrunds vor dem Abschluss. Ereignistyp inferred
	Incident erneut geöffnet	Kennzeichnet einen Incident, der zuvor als gelöst markiert, aber erneut aktiviert wurde, weil das Problem weiterhin besteht. Dies wird aus einem Statuswechsel von „Resolved“ zurück in einen aktiven Zustand wie „In Progress“ oder „Assigned“ abgeleitet.
Warum das wichtig ist Diese Aktivität misst direkt die Nacharbeit und die Wirksamkeit der ursprünglichen Lösungen. Eine hohe Zahl erneut geöffneter Incidents ist ein wichtiger Hinweis auf eine unzureichende Qualität der Fehlerbehebung und unterstützt den KPI „Incident Rework Rate“. Bezugsquelle Abgeleitet aus dem Audit Log („HPD:HelpDesk_AuditLogSystem“), indem für eine bestimmte Incident ID ein Statuswechsel von „Resolved“ zu „In Progress“ oder „Assigned“ erkannt wird. Erfassen Abgeleitet aus dem Statuswechsel von „Resolved“ in einen aktiven Zustand. Ereignistyp inferred
	Incident kategorisiert	Kennzeichnet den Zeitpunkt, an dem der Incident mit operativen und produktbezogenen Kategorien klassifiziert und eine Priorität festgelegt wurde. Dies wird in der Regel aus dem Befüllen oder der letzten Änderung der Kategorisierungsfelder abgeleitet.
Warum das wichtig ist Eine korrekte und zeitnahe Kategorisierung ist entscheidend für eine effiziente Weiterleitung und aussagekräftiges Reporting. Die Analyse dieser Aktivität hilft, Verzögerungen oder Ungenauigkeiten bei der ersten Triage zu erkennen, und unterstützt das Dashboard „Incident Categorization Accuracy“. Bezugsquelle 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. Erfassen Aus dem Timestamp der letzten Änderung an Kategorisierungs- oder Prioritätsfeldern nach der Erstellung. Ereignistyp inferred
	Incident storniert	Diese Aktivität kennzeichnet die Beendigung eines Incidents, der versehentlich erstellt wurde oder nicht mehr relevant ist. Sie wird erfasst, wenn der Status des Incidents auf „Cancelled“ gesetzt wird.
Warum das wichtig ist Dies ist ein endgültiger Endzustand eines Incidents und unterscheidet sich von einer erfolgreichen Lösung. Die Analyse stornierter Incidents kann Probleme bei Kanälen zur Incident-Erstellung oder bei doppelten Meldungen aufzeigen. Bezugsquelle Abgeleitet aus dem Formular „HPD:Help Desk“, wenn das Feld „Status“ auf „Cancelled“ aktualisiert wird. Der Timestamp wird im Audit Log erfasst. Erfassen Abgeleitet aus dem Statuswechsel zu „Cancelled“ im Audit Log. 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 Status des Incidents auf „Resolved“ wechselt.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der anzeigt, dass eine Lösung bereitgestellt wurde. Er dient als zentraler Datenpunkt, um die Zeit bis zur Anwendung einer Fehlerbehebung nach Abschluss der Untersuchung zu messen. Bezugsquelle In der Regel abgeleitet daraus, dass der „Status“ im Formular „HPD:Help Desk“ auf „Resolved“ geändert wird. Der Timestamp wird im Feld „Last Resolved Date“ und im Audit Log erfasst. Erfassen Aus dem Timestamp von „Last Resolved Date“ oder dem Statuswechsel zu „Resolved“. Ereignistyp inferred
	SLA-Verstoß	Dies ist ein berechnetes Event, das eintritt, wenn die Lösungszeit eines Incidents das festgelegte Ziel des Service Level Agreement überschreitet. Es wird durch den Vergleich des Lösungs-Timestamps mit dem Fälligkeitsdatum des SLA ermittelt.
Warum das wichtig ist Diese Aktivität ist grundlegend für das Dashboard „Incident SLA Performance Overview“ und den KPI „Incident SLA Compliance Rate“. Sie kennzeichnet direkt Incidents, bei denen die vereinbarten Serviceziele nicht eingehalten wurden. Bezugsquelle Berechnet durch den Vergleich von „Last Resolved Date“ mit „Target Date“ (SLA Due Date) im Formular „HPD:Help Desk“. Ist der Incident noch nicht gelöst, kann die Berechnung anhand der aktuellen Zeit erfolgen. Erfassen Berechnetes Event: tritt ein, wenn „Last Resolved Date“ > „Target Date“ ist. Ereignistyp calculated
	Warten auf Bestätigung des Benutzers	Tritt auf, nachdem eine Lösung umgesetzt wurde und das Supportteam auf die Bestätigung des Benutzers wartet, dass die Fehlerbehebung erfolgreich war. Dies wird häufig durch den Status „Resolved“ dargestellt, mit dem die Frist bis zur automatischen Schließung beginnt.
Warum das wichtig ist Diese Aktivität ist entscheidend für das Dashboard „User Confirmation & Verification Delays“. Sie hilft, Verzögerungen zwischen der Bereitstellung einer Lösung und ihrer Bestätigung durch den Benutzer zu quantifizieren, die den Lebenszyklus des Incidents künstlich verlängern können. Bezugsquelle Dieser Zustand beginnt, wenn sich der „Status“ im Formular „HPD:Help Desk“ in „Resolved“ ändert. Die Dauer wird vom „Last Resolved Date“ bis zu dem Zeitpunkt gemessen, an dem der Incident entweder auf „Closed“ oder „Reopened“ gesetzt wird. Erfassen Beginnt mit dem Statuswechsel zu „Resolved“ und endet mit dem Statuswechsel zu „Closed“ oder „In Progress“. Ereignistyp inferred
	Warten auf Eingaben des Kunden	Kennzeichnet einen Punkt, an dem der Incident pausiert, weil Informationen oder eine Aktion des Benutzers ausstehen. Dies wird aus einem Statuswechsel in den Zustand „Pending“ abgeleitet.
Warum das wichtig ist Diese Aktivität trennt die Arbeitszeit des Agents von der Wartezeit auf den Kunden. Die Analyse der in diesem Zustand verbrachten Zeit ist entscheidend, um zu verstehen, wie sich Verzögerungen bei der Benutzerantwort auf die gesamte Lösungszeit auswirken. Bezugsquelle 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“. Erfassen Abgeleitet aus dem Statuswechsel zu „Pending“ im HPD:HelpDesk_AuditLogSystem. Ereignistyp inferred

Anleitungen zur Datenextraktion

So rufen Sie Ihre Daten aus BMC Helix ITSM ab

Schritte

Smart Reporting öffnen: Melden Sie sich bei Ihrer BMC-Helix-ITSM-Umgebung an. Öffnen Sie im Hauptmenü die Berichte, um Smart Reporting zu starten.
Neuen Bericht erstellen: Klicken Sie in Smart Reporting auf die Schaltfläche Erstellen und wählen Sie Bericht. Wählen Sie die Option Advanced Report, 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, die als semantische Ebene auf den zentralen Incident-Formularen aufbaut.
Freehand SQL verwenden: Öffnen Sie im Berichtseditor die Datenquellenoptionen und wählen Sie statt des Ziehens von Feldern per Drag-and-drop Freehand SQL. Daraufhin wird ein Editor geöffnet, in dem Sie eine benutzerdefinierte 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 Platzhalterwerte [START_DATE], [END_DATE] und [YOUR_COMPANY_NAME] durch Ihre konkreten Angaben.
Daten validieren und in der Vorschau prüfen: Verwenden Sie die Validierungs- oder Vorschaufunktion im SQL-Editor, um Syntaxfehler zu prüfen und einen Ausschnitt der Ausgabe anzuzeigen. 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 der Validierung der Abfrage mit dem Berichtsentwurf fort. Die in der SQL-Abfrage definierten Spalten stehen als Felder zur Verfügung. Stellen Sie sicher, dass alle Spalten, etwa IncidentId, ActivityName und EventTimestamp, in der Berichtstabelle enthalten sind.
Berichtsfilter anwenden (optional): Der Hauptdatumsfilter befindet sich zwar in der SQL-Abfrage, bei Bedarf können Sie auf Berichtsebene weitere interaktive Filter hinzufügen, etwa für Priority oder AssignedGroup.
Bericht ausführen und speichern: Führen Sie den Bericht aus, um den vollständigen Datensatz zu erzeugen. Wenn Sie mit den Ergebnissen zufrieden sind, speichern Sie den Bericht unter einem aussagekräftigen Namen wie „Incident Management Event Log“.
In CSV exportieren: Verwenden Sie bei angezeigten Berichtsergebnissen die Funktion Export. Wählen Sie CSV als Exportformat. 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 so planen, dass er automatisch ausgeführt wird. Konfigurieren Sie in den Verteilungseinstellungen des Berichts einen Zeitplan, zum Beispiel täglich oder wöchentlich, und legen Sie als Ziel eine Dateifreigabe oder E-Mail fest. Stellen Sie sicher, dass das Format CSV ist.

Konfiguration

Voraussetzungen: Sie benötigen ein BMC-Helix-Konto mit Berechtigungen für den Zugriff auf Smart Reporting, die Erstellung von Reports, die Verwendung von Freehand SQL und die Abfrage der Datenquelle Incident Management.
Report-Typ: Für den Aufbau der Event-Log-Struktur mit UNION-ALL-Anweisungen ist ein Advanced Report mit der Funktion Freehand SQL erforderlich.
Ansicht der Datenquelle: Verwenden Sie die Standardansicht Incident Management, die auf dem Formular HPD:Help Desk und den zugehörigen Verknüpfungen basiert.
Filterung nach Zeitraum: Legen Sie unbedingt einen Zeitraum fest, um die Systemleistung zu steuern. Die bereitgestellte Abfrage enthält die Platzhalter [START_DATE] und [END_DATE]. Für eine aussagekräftige Analyse ohne übermäßige Systemlast empfehlen wir, Daten für drei bis sechs Monate zu extrahieren.
Unternehmensfilter: Die Abfrage enthält den Platzhalter [YOUR_COMPANY_NAME], um die Daten auf ein bestimmtes betreibendes Unternehmen einzugrenzen. In einer mandantenfähigen Umgebung ist dieser Filter für eine präzise Auswertung erforderlich.
Überlegungen zur Leistung: Die Abfrage für das Event Log ist komplex und verknüpft mehrere Tabellen. Bei großen Datenmengen kann ihre Ausführung erhebliche Systemressourcen beanspruchen. Planen Sie umfangreiche Exporte stets außerhalb der Spitzenzeiten.

a 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

Datenbankzugang und Schema ermitteln: Beschaffen Sie schreibgeschützte Zugangsdaten für die zugrunde liegende BMC-Helix-ITSM-AR-System-Datenbank, etwa SQL Server oder Oracle. Ermitteln Sie außerdem das konkrete Schema sowie die Tabellen für das Incident-Management-Formular HPD:Help Desk und dessen Audit Log. Die Haupttabelle trägt häufig einen Namen wie T<form_id>, etwa T1234. Das Audit Log heißt typischerweise H<form_id> oder [form_name]_AuditLogSystem.
Mit der Datenbank verbinden: Verwenden Sie einen gängigen SQL-Client wie DBeaver, SQL Server Management Studio (SSMS) oder Oracle SQL Developer, um sich mit den Zugangsdaten aus dem vorherigen Schritt mit der Datenbank zu verbinden.
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 korrekten Werte für Ihre Umgebung:
- [Your_HPD_Help_Desk_Table]: Ersetzen Sie diesen Platzhalter durch den tatsächlichen Tabellennamen des Formulars HPD:Help Desk.
- [Your_HPD_Help_Desk_Audit_Table]: Ersetzen Sie diesen 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 Unix-Epoch-Timestamps. Wenn Sie Oracle oder eine andere Datenbank verwenden, müssen Sie die Funktion entsprechend anpassen. Das Äquivalent für Oracle lautet TO_DATE('1970-01-01', 'YYYY-MM-DD') + ( [TimestampColumn] / 86400 ).
Abfrage ausführen: Führen Sie die angepasste Abfrage in der Datenbank aus. Je nach Zeitraum und Umfang Ihrer Incident-Daten kann dies mehrere Minuten dauern.
Ergebnisse prüfen: Prüfen Sie die Ausgabe nach Abschluss der Abfrage kurz. Stellen Sie sicher, dass die Spalten IncidentId, ActivityName und EventTimestamp erwartungsgemäß befüllt sind. Achten Sie auf verschiedene Aktivitäten, damit Sie erkennen, ob die UNION-ALL-Anweisungen korrekt funktionieren.
Daten in CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie die UTF-8-Kodierung und fügen Sie eine Kopfzeile mit den Spaltennamen ein.
Upload vorbereiten: Stellen Sie vor dem Upload in ein Process-Mining-Tool sicher, dass die Spalte EventTimestamp ein einheitliches Format verwendet, etwa 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 BMC-Helix-ITSM-Anwendungsdatenbank. Außerdem müssen Sie die konkreten Tabellennamen des Formulars HPD:Help Desk und seines Audit Logs kennen. Diese können sich je nach Systeminstallation unterscheiden.
Filterung nach Zeitraum: Die Abfrage enthält in der CTE BaseIncidents eine WHERE-Klausel zur Filterung nach Submit_Date. Beginnen Sie möglichst mit einem begrenzten Zeitraum von drei bis sechs Monaten, um Abfrageleistung und Datenvolumen zu steuern. Beispiel: WHERE hpd.Submit_Date >= '2023-01-01' AND hpd.Submit_Date < '2023-07-01'.
Filterung nach Unternehmen: Ist Ihre ITSM-Instanz mandantenfähig, fügen Sie in der WHERE-Klausel der CTE BaseIncidents einen Filter für das zu analysierende Unternehmen hinzu, etwa AND hpd.Company = '[Your Company Name]'.
Überlegungen zur Leistung: Direkte Datenbankabfragen können erhebliche Ressourcen beanspruchen, insbesondere bei Verknüpfungen mit großen Audit-Log-Tabellen und mehreren UNION-ALL-Operationen. Führen Sie umfangreiche Extraktionen möglichst außerhalb der Spitzenzeiten aus, damit die Systemleistung nicht beeinträchtigt wird.
Timestamp-Konvertierung: Die Abfrage geht davon aus, 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 zutrifft und ob die in der Abfrage verwendete Konvertierungsfunktion zu Ihrer konkreten Datenbanktechnologie passt, etwa SQL Server oder Oracle.

a 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 requests-Bibliothek, indem Sie in der Befehlszeile oder im Terminal pip install requests ausführen. Beschaffen Sie 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, darunter 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 zu authentifizieren. Es erhält ein JSON Web Token (JWT), das anschließend für alle weiteren Datenabfragen als Autorisierungs-Header verwendet wird.
Skript ausführen: Starten Sie das Skript in Ihrem Terminal mit dem Befehl python extract_incidents.py. Das Skript wird ausgeführt und zeigt im Terminal den Fortschritt an.
Erste Incident-Daten abrufen: Das Skript fragt den REST-API-Endpunkt 'HPD:Help Desk' ab, um eine Liste aller Incidents abzurufen, die im angegebenen Zeitraum erstellt wurden. Mithilfe von Pagination, also den Parametern limit und offset, verarbeitet es auch große Incident-Mengen, ohne die API zu überlasten.
Audit Log abrufen: Für jeden im vorherigen Schritt abgerufenen Incident führt das Skript einen separaten API-Aufruf für das Formular 'HPD:Help Desk Audit Log' aus. Dadurch wird die detaillierte Änderungshistorie jedes Incidents abgerufen. Diese ist entscheidend, um Aktivitäten wie Statusänderungen und Neuzuweisungen zu erkennen.
Events und Logik ableiten: Das Skript verarbeitet die Daten im Arbeitsspeicher. Es führt den Hauptdatensatz des Incidents mit dem zugehörigen Audit Log zusammen und durchläuft anschließend die sortierten Audit-Log-Einträge, um die angegebenen Aktivitäten logisch abzuleiten. Beim ersten Auftreten des Feldes 'Assigned Group' im Log erstellt es beispielsweise ein Event 'Group Assigned'. Eine Statusänderung von 'Resolved' zu 'In Progress' erzeugt das Event 'Incident Reopened'.
Berechnete Events verarbeiten: Das Skript berechnet Events, die nicht direkt protokolliert werden. 'Incident Reported' wird aus 'Submit Date' erstellt. 'SLA Breach' wird durch den Vergleich von 'Last Resolved Date' mit 'Target Date' abgeleitet.
Daten strukturieren: Sobald eine Aktivität erkannt wird, erstellt das Skript ein Dictionary mit IncidentId, ActivityName, EventTimestamp sowie allen weiteren erforderlichen und empfohlenen Attributen. Diese Dictionaries werden in einer gemeinsamen Liste gesammelt.
CSV-Datei erzeugen: Nachdem alle Incidents und die zugehörigen Aktivitäten verarbeitet wurden, schreibt die integrierte csv-Bibliothek von Python das abschließende Event Log in eine Datei namens bmc_helix_incident_log.csv. Diese Datei wird im selben Verzeichnis erstellt, in dem das Skript ausgeführt wurde.
Abschließende Prüfung und Upload: Öffnen Sie die erzeugte CSV-Datei in einem Tabellenkalkulationsprogramm und prüfen Sie ihren Inhalt. Stellen Sie sicher, dass Spalten und Daten korrekt erscheinen. 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, das für die Authentifizierung verwendet wird.
HELIX_PASSWORD: Das Passwort des API-Kontos. Für Zugangsdaten in einer Produktionsumgebung empfiehlt sich die Verwendung von Umgebungsvariablen oder eines sicheren Tools zur Verwaltung von Secrets.
START_DATE / END_DATE: Der Zeitraum für die Extraktion im Format "YYYY-MM-DDTHH:MM:SS.sssZ". Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten, um einen repräsentativen Datensatz ohne übermäßiges Volumen zu erhalten.
COMPANY_NAME: Der Name des Unternehmens, nach dem die Incidents gefiltert werden sollen. In mandantenfähigen Umgebungen ist dieser Parameter entscheidend, um die Daten korrekt einzugrenzen. Falls keine Filterung erforderlich ist, können Sie ihn auf None setzen.
PAGE_SIZE: Die Anzahl der Incidents, die pro API-Anfrage abgerufen werden. Ein Wert zwischen 500 und 1.000 ist in der Regel effizient, muss jedoch möglicherweise an die Leistung Ihrer Instanz und die Rate Limits der API angepasst werden.
Voraussetzungen: Das Skript benötigt ein BMC-Helix-Benutzerkonto mit mindestens Leseberechtigungen für die Formulare HPD:Help Desk und HPD:Help Desk Audit Log. Ohne Zugriff auf beide Formulare bleibt die Extraktion unvollständig.

a 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()

Bereit für den Start?

Verwenden Sie dieses Template, um Ihre Process-Mining-Initiativen zu starten und wertvolle Erkenntnisse in Ihren Incident-Management-Daten zu gewinnen. Beginnen Sie noch heute mit der Optimierung Ihrer Abläufe.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Beheben Sie wiederkehrende Incidents in BMC Helix ITSM noch heute!

Senken Sie die MTTR um 35 %, vermeiden Sie SLA-Verstöße und steigern Sie die Zufriedenheit der Anwender.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Kostenlose Testphase über 14 Tage.

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 in CSV

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage in den Incident-Tabellen der ITSM-Datenbank

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion per Python-Skript über die BMC-Helix-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Beheben Sie wiederkehrende Incidents in BMC Helix ITSM noch heute!

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 in CSV

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage in den Incident-Tabellen der ITSM-Datenbank

Schritte

Konfiguration

a Beispielabfrage sql

Datenextraktion per Python-Skript über die BMC-Helix-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Beheben Sie wiederkehrende Incidents in BMC Helix ITSM noch heute!

Ihre Privatsphäre ist uns wichtig