> Kontinuierliche Prozessverbesserung > Verwaltung von Serviceanfragen > BMC Helix ITSM > Daten Template

Ihr Daten-Template für das Serviceanfragemanagement

BMC Helix ITSM

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Serviceanfragemanagements (20) Aktivitäten im Service-Request-Management (14) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für das Serviceanfragemanagement

Dieses Template bietet einen klaren Überblick über die wichtigsten Datenattribute, die Sie für Ihren Serviceanfrageprozess erfassen sollten, und über die zentralen Aktivitäten, die Sie verfolgen sollten. Außerdem enthält es praktische Hinweise, wie Sie diese Daten effizient aus BMC Helix ITSM extrahieren. Damit können Sie Ihre Datenaufbereitung vereinfachen und Ihre Process-Mining-Initiativen mit Zuversicht starten.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten zur Nachverfolgung
Hinweise zur Datenextraktion aus BMC Helix ITSM

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

Template herunterladen

Attribute des Serviceanfragemanagements

Diese Datenfelder sind entscheidend für ein vollständiges Event Log. Damit lässt sich Ihr Service-Request-Management-Prozess detailliert analysieren.

5 Erforderlich 6 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des konkreten Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Ablauf der Serviceanfrage stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen bestimmten Schritt oder eine Statusänderung im Serviceanfrageprozess, etwa „Anfrage in Prüfung“, „Bearbeitung läuft“ oder „Serviceanfrage gelöst“. Jede Aktivität steht für ein einzelnes Ereignis im gesamten Ablauf einer Serviceanfrage. Die Analyse der Abfolge und Häufigkeit von Aktivitäten bildet den Kern des Process Mining. Sie ermöglicht es, Prozessmodelle zu entdecken, Engpässe zu erkennen und Prozessvarianten zu analysieren. Für die Prozessoptimierung ist entscheidend zu wissen, welche Aktivitäten in welcher Reihenfolge und wie oft auftreten. Warum das wichtig ist Aktivitäten bilden die Bausteine des Prozessmodells. Ihre Erfassung ermöglicht es, den Prozessablauf darzustellen und zu analysieren. So wird sichtbar, wie die Arbeit tatsächlich ausgeführt wird. Woher beziehen Dieses Attribut wird üblicherweise aus Änderungen der Felder „Status“ und „Status Reason“ im Formular „SRM:Request“ oder aus zugehörigen Fulfillment-Anwendungsprotokollen abgeleitet, zum Beispiel aus Incident- oder Work-Order-Daten. Beispiele Anfrage wartet auf FreigabeBearbeitung läuftServiceanfrage gelöstServiceanfrage geschlossen
	Service-Request-ID ServiceRequestId	Die eindeutige Kennung jeder Serviceanfrage. Sie dient als Primärschlüssel, um den gesamten Ablauf nachzuverfolgen.
Beschreibung Die Service-Request-ID identifiziert jede einzelne Serviceanfrage, die ein Benutzer oder ein System eingereicht hat. Sie dient als zentrale Verknüpfung aller nachfolgenden Ereignisse, von der ersten Erfassung bis zum endgültigen Abschluss. So lässt sich der gesamte Ablauf jeder Serviceanfrage analysieren. Beim Process Mining ist diese ID unverzichtbar, um die Abfolge der Aktivitäten für jeden Case zu rekonstruieren. Das Tool kann damit alle zugehörigen Ereignisse, etwa „Anfrage eingereicht“, „Anfrage zugewiesen“ und „Serviceanfrage geschlossen“, zu einer Prozessinstanz zusammenfassen. Darauf bauen alle Prozessanalysen auf. Warum das wichtig ist Dies ist die grundlegende Case-ID. Ohne sie lässt sich der Ablauf einer Serviceanfrage nicht von Anfang bis Ende nachverfolgen. Prozessentdeckung und -analyse sind dann nicht möglich. Woher beziehen Dies ist üblicherweise das Feld „InstanceId“ oder „Request Number“ im Formular „SRM:Request“ von BMC Helix ITSM. Beispiele SR000010572931SR000010572932SR000010572933
	Startzeit EventStartTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis begonnen hat.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine Aktivität begonnen hat. Jedes Ereignis im Protokoll, von der ersten Einreichung bis zum endgültigen Abschluss, benötigt eine Startzeit, damit sich die zeitliche Abfolge des Prozesses bestimmen lässt. Dieser Timestamp ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Er dient zur Berechnung von Zykluszeiten, Aktivitätsdauern und Wartezeiten zwischen Schritten sowie zur Prüfung der SLA-Einhaltung. So lassen sich Engpässe erkennen und die Prozessleistung im Zeitverlauf analysieren. Warum das wichtig ist Die Startzeit legt die zeitliche Reihenfolge der Ereignisse fest. Das ist wichtig, um Prozessdauern zu berechnen, Verzögerungen zu erkennen und den zeitlichen Ablauf des Prozesses zu verstehen. Woher beziehen Dies entspricht den Timestamp-Feldern in den Audit-Logs oder Statushistorientabellen des Formulars „SRM:Request“, etwa dem Feld „Submit Date“ für das erste Ereignis. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem die Daten für diesen Prozess zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut gibt Datum und Uhrzeit der letzten Datenextraktion aus BMC Helix ITSM an. Es zeigt Benutzern, wie aktuell die analysierten Daten sind und welchen Zeitraum die Analyse abdeckt. Diese Metadaten sind für jedes Process-Mining-Dashboard und jede Analyse wichtig. Sie zeigen, ob die Erkenntnisse auf nahezu Echtzeitdaten oder einem historischen Datenstand beruhen. Das beeinflusst, wie aussagekräftig und relevant die daraus gezogenen Schlussfolgerungen sind. Warum das wichtig ist Das Attribut informiert Benutzer darüber, wie aktuell die Daten sind. Das ist wichtig, um Entscheidungen auf Grundlage der neuesten verfügbaren Informationen zur Prozessleistung zu treffen. Woher beziehen Dieser Timestamp wird bei der Datenextraktion und beim Laden der Daten erzeugt und hinzugefügt. Beispiele 2024-05-21T08:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt an, woher die Prozessdaten stammen. In dieser Ansicht wird es statisch auf „BMC Helix ITSM“ gesetzt, um zu kennzeichnen, dass alle Ereignisse zu den Serviceanfragen aus diesem System stammen. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld wichtig, um die Herkunft der Daten nachzuvollziehen und sie nach Quelle aufzuteilen. Das sorgt für Klarheit und Rückverfolgbarkeit, insbesondere wenn Daten aus verschiedenen Plattformen zusammengeführt werden. Warum das wichtig ist Das Attribut gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für Data Governance, Rückverfolgbarkeit und Fehlerbehebung in Umgebungen mit mehreren Systemen. Woher beziehen Dies ist ein statischer Wert, der bei der Datenextraktion und -transformation hinzugefügt wird. Er ist kein Feld in BMC Helix ITSM. Beispiele BMC Helix ITSM
	Anfragestatus RequestStatus	Der Status der Serviceanfrage zum Zeitpunkt des Ereignisses, etwa „In Progress“, „Pending“ oder „Closed“.
Beschreibung Dieses Attribut erfasst den Status der Serviceanfrage zu verschiedenen Zeitpunkten ihres Ablaufs. Der Status liefert Kontext zu jeder Aktivität und dient häufig als Grundlage für das Attribut „Aktivität“. Eine Auswertung nach Status zeigt, wie viel Zeit Anfragen in bestimmten Zuständen verbringen, etwa in „Pending Customer“ oder „Waiting for Approval“. Das ist wichtig, um Engpässe und Verzögerungen durch externe Abhängigkeiten oder interne Warteschlangen zu erkennen. Das Attribut unterstützt direkt das Dashboard zur Erkennung von Engpässen. Warum das wichtig ist Das Attribut zeigt den Status der Anfrage zu einem bestimmten Zeitpunkt. So lässt sich die Zeit in Wartezuständen mit der Zeit in aktiven Zuständen vergleichen, was für die Erkennung von Engpässen entscheidend ist. Woher beziehen Dies ist das Feld „Status“ im Formular „SRM:Request“. Frühere Werte finden Sie im Audit-Log. Beispiele PlanungIn BearbeitungAusstehendGelöstGeschlossen
	Endzeit EventEndTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Viele Aktivitäten in ITSM-Systemen sind unmittelbare Statusänderungen, andere dauern messbar lange. Mit einer Endzeit lässt sich die Dauer solcher Aktivitäten genau berechnen. Bei der Analyse wird die Endzeit zusammen mit der Startzeit verwendet, um die Verarbeitungszeit einzelner Aktivitäten zu berechnen. So lässt sich erkennen, welche konkreten Aufgaben im Prozess am meisten Zeit beanspruchen, nicht nur die Wartezeiten zwischen ihnen. Warum das wichtig ist Damit lassen sich die Verarbeitungszeiten von Aktivitäten berechnen. Das ist wichtig, um ineffiziente Schritte zu erkennen und zu verstehen, wofür Ressourcen ihre Zeit aufwenden. Woher beziehen Die Endzeit lässt sich ableiten. Bei zwei aufeinanderfolgenden Aktivitäten desselben Cases entspricht die Endzeit der ersten Aktivität häufig der Startzeit der nächsten. Für die letzte Aktivität wird der Timestamp der Lösung oder des Abschlusses verwendet. Beispiele 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Priorität Priority	Die der Serviceanfrage zugewiesene Priorität. Sie gibt ihre geschäftlichen Auswirkungen und Dringlichkeit an.
Beschreibung Die Priorität bestimmt, in welcher Reihenfolge und wie schnell Anfragen bearbeitet werden sollen. Übliche Werte sind „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“. Die Einstufung richtet sich häufig danach, wie stark sich die Anfrage auf das Unternehmen auswirkt und wie dringend sie ist. Eine Auswertung nach Priorität zeigt, ob Anfragen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. Sie ist eine wichtige Dimension in Dashboards zu Lösungszeiten und SLA-Einhaltung und hilft sicherzustellen, dass Ressourcen den wichtigsten geschäftlichen Anforderungen entsprechend eingesetzt werden. Warum das wichtig ist Damit lässt sich beurteilen, ob der Prozess die Arbeit angemessen priorisiert und die erwarteten Service-Level für Anfragen mit unterschiedlichen geschäftlichen Auswirkungen erfüllt. Woher beziehen Dies ist das Feld „Priority“ im Formular „SRM:Request“. Beispiele KritischHochMittelNiedrig
	Serviceart ServiceType	Die Kategorie oder Art des Services, den der Benutzer anfordert.
Beschreibung Die Serviceart beschreibt die Art der Anfrage, zum Beispiel „Neue Software anfordern“, „Passwort zurücksetzen“ oder „Neuen Mitarbeiter einrichten“. Sie ist eine wichtige Dimension, um Prozessdaten zu filtern und aufzuschlüsseln. Bei der Prozessanalyse dient dieses Attribut dazu, die Leistung verschiedener Anfragetypen zu vergleichen. Es hilft bei Fragen wie: „Welche Servicearten dauern am längsten?“ oder „Bei welchen Servicearten fällt die meiste Nacharbeit an?“ Das ist wichtig für Dashboards zu Lösungszeiten und SLA-Einhaltung. Warum das wichtig ist Damit lassen sich Serviceanfragen nach Typ aufschlüsseln, Prozessabläufe vergleichen, spezifische Probleme erkennen und Verbesserungsmaßnahmen gezielt ausrichten. Woher beziehen Diese Daten finden sich häufig im Feld „Title“ oder in einem Kategorisierungsfeld des Formulars „SRM:Request“. Sie werden aus dem im Katalog ausgewählten Service abgeleitet. Beispiele Anfrage für neue HardwareAnfrage für SoftwarezugriffVPN-Zugang einrichten
	Zugewiesener Agent AssignedAgent	Der Benutzer, der aktuell für die Bearbeitung der Serviceanfrage zuständig ist.
Beschreibung Dieses Attribut bezeichnet den IT-Agenten oder Support-Mitarbeitenden, der zu einem bestimmten Zeitpunkt für die Anfrage zuständig ist. Ändert sich der Wert im Verlauf einer Anfrage, deutet das auf eine Übergabe oder Neuzuweisung hin. Das Attribut ist wichtig, um die Leistung und Auslastung der Agenten zu analysieren. Sie können damit erfassen, wie viele Anfragen jeder Agent bearbeitet, wie lange die durchschnittliche Bearbeitung dauert und wie oft Anfragen neu zugewiesen werden. Diese Daten unterstützen die Ressourcenplanung und helfen, Schulungsbedarf zu erkennen. Warum das wichtig ist Die Zuordnung zum zuständigen Agenten ist entscheidend, um Übergaben zu analysieren, die individuelle Leistung zu messen und die Arbeitslast im Support-Team zu verstehen. Woher beziehen Dies entspricht dem Feld „Assignee“ oder „Assigned To“ im zugehörigen Fulfillment-Datensatz, zum Beispiel im Work Order oder Incident. Beispiele Bob SmithAlice JohnsonCharlie Brown
	Zugewiesenes Team AssignedTeam	Die Support-Gruppe oder das Team, dem die Serviceanfrage derzeit zugewiesen ist.
Beschreibung Dieses Attribut bezeichnet die zuständige Fachgruppe, etwa „Help Desk“, „Network Team“ oder „Database Administration“. Eine Änderung des Werts zeigt, dass die Verantwortung an ein anderes Team übergeben wurde. Die Analyse nach zugewiesenem Team macht Engpässe auf Teamebene sichtbar, zeigt Übergaben zwischen Teams und ermöglicht den Vergleich verschiedener Support-Gruppen. Sie ist eine wichtige Grundlage für die Dashboards „Anfragen-Nachbearbeitung und Neuzuweisung“ sowie „Effizienz der Triage“ und zeigt, wie die Arbeit innerhalb der Organisation weitergeleitet wird. Warum das wichtig ist Damit lässt sich der Prozessfluss zwischen verschiedenen Fachgruppen analysieren. So können Sie ineffiziente Weiterleitungen erkennen und die Leistung der einzelnen Teams messen. Woher beziehen Dies entspricht dem Feld „Assigned Group“ im Fulfillment-Datensatz, zum Beispiel im Work Order oder Incident, der mit der Serviceanfrage verknüpft ist. Beispiele Service DeskInfrastruktur-SupportAnwendungs-Support, Stufe 2
	Abschlusscode CloseCode	Ein Code, der das endgültige Ergebnis oder den Grund für den Abschluss der Serviceanfrage angibt.
Beschreibung Der Abschlusscode ermöglicht eine einheitliche Klassifizierung des Ergebnisses einer Serviceanfrage. Beispiele sind „Vom Service Desk gelöst“, „Von der anfragenden Person storniert“ oder „Doppelte Anfrage“. Die Analyse der Abschlusscodes zeigt, welche Ergebnisse bei Anfragen häufig auftreten. Eine hohe Zahl von Stornierungen durch Benutzer kann beispielsweise auf einen langwierigen Prozess hindeuten. Viele doppelte Anfragen können auf Probleme mit dem System oder der Kommunikation hinweisen. Dieses Attribut unterstützt das Dashboard „Genauigkeit der Lösungskategorie“. Warum das wichtig ist Das Attribut liefert strukturierte Daten zu den Ergebnissen von Anfragen. Damit können Sie die Wirksamkeit der Lösungen sowie Gründe für einen nicht erfolgten Abschluss oder eine Stornierung analysieren. Woher beziehen Diese Information steht üblicherweise im Feld „Resolution“ oder „Closure Code“ des Fulfillment-Tickets, das mit der Serviceanfrage verknüpft ist. Beispiele ErfolgreichVon der anfragenden Person storniertNicht mehr erforderlichAutomatisch gelöst
	Abteilung der anfragenden Person RequestorDepartment	Die Fachabteilung oder Geschäftseinheit der Person, die die Anfrage eingereicht hat.
Beschreibung Dieses Attribut bezeichnet die Abteilung der Person, die den Service anfordert, zum Beispiel „Finanzen“, „Personal“ oder „IT“. Die Information stammt in der Regel aus dem Benutzerprofil im System. Wenn Sie die Prozessanalyse nach Abteilung aufschlüsseln, erkennen Sie abteilungsspezifische Anforderungen und Anfragemuster sowie mögliche Ansatzpunkte für gezielte Schulungen oder Serviceverbesserungen. So lässt sich etwa prüfen, ob Anfragen aus der Finanzabteilung länger auf ihre Bearbeitung warten. Warum das wichtig ist Damit können Sie die Servicenutzung und Prozessleistung nach Geschäftseinheit analysieren und abteilungsspezifische Probleme oder Trends erkennen. Woher beziehen Diese Information stammt üblicherweise aus dem Benutzerprofil der im Formular „SRM:Request“ unter „Requested For“ angegebenen Person. Beispiele FinanzenVertriebPersonalInformationstechnologie
	Anzahl der Übergaben HandoffCount	Die Gesamtzahl der Neuzuweisungen einer Serviceanfrage zwischen verschiedenen Agenten oder Teams.
Beschreibung Diese berechnete Kennzahl zählt, wie oft sich der Wert von „AssignedAgent“ oder „AssignedTeam“ bei einer einzelnen Serviceanfrage ändert. Eine hohe Zahl an Übergaben kann auf eine Zersplitterung des Prozesses, eine geringe Lösungsquote beim Erstkontakt oder ineffiziente Weiterleitungen hindeuten. Das Attribut bildet die Grundlage für die KPI „Durchschnittliche Agentenübergaben pro Anfrage“ und wird im Dashboard „Anfragen-Nachbearbeitung und Neuzuweisung“ verwendet. Die Analyse von Fällen mit vielen Übergaben zeigt, wo eine bessere Triage, gezielte Schulungen oder ein effizienterer Lösungsprozess Verzögerungen verringern und die Kundenzufriedenheit verbessern können. Warum das wichtig ist Die Kennzahl misst, wie stark der Prozess zersplittert ist und wie viel Aufwand für die Kommunikation zwischen Beteiligten entsteht. Viele Übergaben gehen häufig mit längeren Lösungszeiten und geringerer Prozesseffizienz einher. Woher beziehen Diese berechnete Kennzahl ergibt sich aus der Anzahl unterschiedlicher Werte im Attribut „AssignedAgent“ oder „AssignedTeam“ für jede eindeutige Service Request ID. Beispiele 0135
	Einreichungskanal SubmissionChannel	Die Methode oder der Kanal, über den die Serviceanfrage eingereicht wurde.
Beschreibung Dieses Attribut erfasst, wie eine Serviceanfrage eingegangen ist, zum Beispiel über ein Self-Service-Portal, per E-Mail, telefonisch beim Service Desk oder durch eine automatische Systemmeldung. Je nach Kanal können sich Prozessvarianten und Bearbeitungszeiten unterscheiden. Eine Analyse nach Einreichungskanal kann Ineffizienzen oder bewährte Vorgehensweisen bei bestimmten Eingangsmethoden aufzeigen. Anfragen über das Self-Service-Portal lassen sich beispielsweise möglicherweise schneller bearbeiten, weil die Daten von Anfang an vollständiger sind. Bei E-Mail-Anfragen ist dagegen unter Umständen mehr manuelle Triage erforderlich. Warum das wichtig ist So können Sie nachvollziehen, wie sich die Eingangsmethode auf Prozesseffizienz, Datenqualität und Zykluszeit auswirkt und gezielte Verbesserungen für einzelne Kanäle ableiten. Woher beziehen Der Wert lässt sich häufig aus Feldern wie „Client Type“ oder „Reported Source“ im Formular „SRM:Request“ oder in zugehörigen Fulfillment-Tickets ableiten. Beispiele Self-Service-PortalE-MailTelefonAutomatisch vom System erstellt
	Eskaliert IsEscalated	Ein boolesches Kennzeichen, das angibt, ob die Serviceanfrage eskaliert wurde.
Beschreibung Dieses Kennzeichen wird auf „true“ gesetzt, wenn eine Serviceanfrage fachlich oder hierarchisch eskaliert wurde. Eine Eskalation erfolgt in der Regel, wenn eine Anfrage nicht wie erwartet vorankommt, eine SLA-Verletzung droht oder eine höhere Instanz eine Freigabe erteilen oder Maßnahmen ergreifen muss. Das Attribut ist eine wichtige Grundlage für das Dashboard „Effizienzanalyse der Anfrageeskalation“. Sie können damit die Prozesspfade eskalierter Anfragen filtern und analysieren: Was löst Eskalationen aus? Wie lange dauert die Bearbeitung danach? Und wie wirksam ist der Eskalationsprozess? Warum das wichtig ist Damit können Sie gezielt die Anfragen untersuchen, die eskaliert werden mussten. So lassen sich Schwächen im Standardprozess und Auslöser komplexer Probleme erkennen. Woher beziehen Dafür gibt es üblicherweise kein einzelnes Feld. Das Kennzeichen wird abgeleitet, indem Sie im Audit-Log nach bestimmten eskalationsbezogenen Aktivitäten oder nach Änderungen an Priorität und Zuweisung suchen, die einem Eskalationsprotokoll folgen. Beispiele truefalse
	Lösungskategorie ResolutionCategory	Die Klassifizierung der Lösung, mit der die Anfrage bearbeitet wurde.
Beschreibung Dieses Attribut kategorisiert, wie eine Anfrage gelöst wurde, zum Beispiel durch eine „Softwarekorrektur“, eine „Benutzerschulung“ oder eine „Datenkorrektur“. Es beschreibt die Art der Lösung genauer als ein einfacher Abschlusscode. Das Attribut ist wichtig für das Dashboard „Genauigkeit der Lösungskategorie“. Dort lässt sich die Lösungskategorie mit der ursprünglichen Serviceart vergleichen, um die Konsistenz zu prüfen. Die Analyse zeigt Trends bei wiederkehrenden Problemen und unterstützt ein proaktives Problemmanagement. Werden beispielsweise viele Anfragen durch Benutzerschulungen gelöst, kann dies auf entsprechenden Schulungsbedarf hinweisen. Warum das wichtig ist Das Attribut zeigt, welche Arten von Lösungen zum Einsatz kommen. So lassen sich wiederkehrende Probleme und Möglichkeiten für ein proaktives Problemmanagement oder Benutzerschulungen erkennen. Woher beziehen Diese Information ist Teil der operativen und produktbezogenen Kategorisierungsfelder im Fulfillment-Ticket. Das Feld heißt häufig „Resolution Category“. Beispiele KontoverwaltungHardwaredefektSoftware-UpgradeInformationen bereitgestellt
	Nacharbeit IsRework	Ein boolesches Kennzeichen, das angibt, ob eine Serviceanfrage nachbearbeitet wurde, zum Beispiel durch die Rückkehr zu einer früheren Prozessphase.
Beschreibung Dieses Kennzeichen markiert Serviceanfragen, bei denen der Prozess eine Schleife oder Nacharbeit aufweist. Wird eine Anfrage beispielsweise von „Bearbeitung läuft“ zurück zu „Anfrage wird geprüft“ gesetzt, gilt dies als Nacharbeit. Die genaue Definition hängt von der Geschäftslogik des Prozesses ab. Das Attribut unterstützt direkt das Dashboard „Anfragen-Nachbearbeitung und Neuzuweisung“ sowie die KPI „Nacharbeitsquote bei Anfragen“. Damit können Sie die Häufigkeit von Nacharbeit messen und häufige Ursachen untersuchen, etwa eine fehlerhafte Ersteinschätzung oder unvollständige Angaben. So werden Ineffizienzen im Prozess sichtbar. Warum das wichtig ist Das Attribut macht Ineffizienzen sichtbar, indem es Fälle kennzeichnet, die vom Happy Path abweichen. So können Sie die Ursachen von Schleifen und wiederholter Arbeit untersuchen. Woher beziehen Dieses berechnete Attribut wird aus der Abfolge der Aktivitäten im Event Log abgeleitet. Dazu muss die Logik Rückschritte im Prozessfluss erkennen. Beispiele truefalse
	SLA verletzt IsSlaBreached	Ein boolesches Kennzeichen, das angibt, ob die Serviceanfrage nach dem SLA-Zieldatum gelöst wurde.
Beschreibung Dieses berechnete Kennzeichen wird auf „true“ gesetzt, wenn der Timestamp der abschließenden Lösung nach dem „SLA-Zieldatum“ liegt. Es zeigt für jede Anfrage eindeutig an, ob die SLA-Vorgabe eingehalten wurde. Das Attribut ist wichtig für das Dashboard „SLA-Compliance-Übersicht“ und die KPI „SLA-Einhaltungsquote“. Sie können damit die Gesamterfüllungsquote berechnen und Anfragen mit SLA-Verletzung filtern. Der Vergleich mit SLA-konformen Anfragen zeigt, welche Prozessmerkmale zu den Verstößen beitragen. Warum das wichtig ist Das Attribut vereinfacht die SLA-Leistungsanalyse: Statt Timestamps miteinander zu vergleichen, können Sie ein einfaches boolesches Kennzeichen auswerten und die Einhaltungsquote leicht messen und visualisieren. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Beispiele truefalse
	SLA-Zieldatum SlaTargetDate	Datum und Uhrzeit, bis zu denen die Serviceanfrage gemäß Service Level Agreement (SLA) gelöst sein soll.
Beschreibung Das SLA-Zieldatum ist ein berechneter Timestamp, der die Frist für den Abschluss der Serviceanfrage angibt. Es wird anhand der Regeln des Servicevertrags ermittelt, die häufig Faktoren wie Priorität und Art der Anfrage berücksichtigen. Dieses Attribut ist eine zentrale Grundlage für das Dashboard „SLA-Compliance-Übersicht“. Es dient als Vergleichswert für die tatsächliche Lösungszeit. Vergleichen Sie den „EventEndTime“ der abschließenden Lösungsaktivität mit dem Zieldatum, um festzustellen, ob die vereinbarte Serviceleistung erbracht wurde. Warum das wichtig ist Das Zieldatum ist der maßgebliche Vergleichswert, um die Serviceleistung an den vereinbarten Zusagen zu messen. Es ist daher für die Überwachung und Berichterstattung zur SLA-Einhaltung unverzichtbar. Woher beziehen Dieses Datum wird vom Modul Service Level Management (SLM) berechnet und gespeichert. Sie finden es in zugehörigen SLM-Formularen, die mit der Serviceanfrage verknüpft sind. Beispiele 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z

Erforderlich Empfohlen Optional

Aktivitäten im Service-Request-Management

Damit Process Mining den Prozess zuverlässig ermitteln und visualisieren kann, sollten Sie diese wichtigen Prozessschritte und Meilensteine im Event Log erfassen.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage zugewiesen	Die Serviceanfrage wurde einem bestimmten Agent oder Team zugewiesen, das für die Bearbeitung zuständig ist. Damit endet die Priorisierungsphase.
Warum das wichtig ist Dieser Meilenstein ist wichtig, um die Priorisierungszeit zu messen und die Arbeitslast der Agents zu analysieren. Häufige Neuzuweisungen können auf Probleme bei der Weiterleitung oder fehlende Kompetenzen hinweisen. Woher beziehen Dieses Ereignis lässt sich direkt im Audit-Log der Felder „Assigned Group“ oder „Assignee“ im Formular SRM:Request oder in zugehörigen Fulfillment-Anwendungen erfassen, zum Beispiel in WOI:WorkOrder. Erfassung Timestamp aus dem Audit-Log, an dem erstmals ein Wert ungleich null im Feld „Assignee“ eingetragen wird. Ereignistyp explicit
	Bearbeitung läuft	Der zuständige Agent oder das Team hat mit der aktiven Bearbeitung der Serviceanfrage begonnen. Die Anfrage befindet sich damit nicht mehr in einer Warteschlange, sondern wird bearbeitet.
Warum das wichtig ist Damit beginnt die wertschöpfende Fulfillment-Arbeit. Die Dauer dieser Phase gibt Aufschluss über die Produktivität der Ressourcen und die Komplexität der Bearbeitung. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf „In Progress“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „In Progress“ ändert. Ereignistyp inferred
	Serviceanfrage eingereicht	Diese Aktivität kennzeichnet die Erstellung und Einreichung einer neuen Serviceanfrage durch einen Benutzer. Sie wird erfasst, wenn im Formular SRM:Request ein neuer Eintrag mit einem Anfangsstatus angelegt wird, üblicherweise mit dem Status „Submitted“.
Warum das wichtig ist Dies ist der Startpunkt jedes Serviceanfrage-Cases. Er ist entscheidend, um die gesamte Durchlaufzeit zu messen und das Anfragevolumen zu analysieren. Woher beziehen Dieses Ereignis wird anhand des Erstellungs-Timestamps und des Anfangsstatus, zum Beispiel „Submitted“, eines Eintrags im Formular SRM:Request abgeleitet. Erfassung Ermitteln Sie den Erstellungs-Timestamp einer neuen Service-Request-ID im Formular SRM:Request, wenn der Status „Submitted“ lautet. Ereignistyp inferred
	Serviceanfrage gelöst	Die Serviceanfrage wurde bearbeitet und die Lösung dem Anfragenden mitgeteilt. Die Anfrage wartet nun auf die abschließende Bestätigung oder wird nach einer festgelegten Frist automatisch geschlossen.
Warum das wichtig ist Ein wichtiger Meilenstein, der das Ende des Servicebereitstellungszyklus markiert. Er ist der zentrale Endpunkt für die Messung der Lösungszeit und SLA-Einhaltung. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf „Resolved“ oder „Completed“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „Resolved“ oder „Completed“ ändert. Ereignistyp inferred
	Serviceanfrage geschlossen	Die Serviceanfrage wird formell geschlossen und in einen schreibgeschützten, archivierten Status versetzt. Dies geschieht nach der Lösung und nach Ablauf einer etwaigen Bestätigungsfrist.
Warum das wichtig ist Diese Aktivität markiert das endgültige Ende des Prozesses. Die Zeit zwischen „Resolved“ und „Closed“ kann auf Ineffizienzen beim Abschluss hinweisen. Woher beziehen Abgeleitet aus der abschließenden Statusänderung im Formular SRM:Request auf „Closed“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „Closed“ ändert. Ereignistyp inferred
	Serviceanfrage storniert	Der Anfragende oder der Service Desk hat die Serviceanfrage zurückgezogen, bevor die Bearbeitung abgeschlossen war. Damit ist der Vorgang beendet.
Warum das wichtig ist Die Analyse von Stornierungen hilft, Muster zu erkennen, etwa falsch eingereichte Anfragen oder nicht mehr benötigte Services. Diese Erkenntnisse können in die Verbesserung des Servicekatalogs einfließen. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf „Canceled“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „Canceled“ ändert. Ereignistyp inferred
	Anfrage abgelehnt	Die Serviceanfrage wurde während einer Freigabephase abgelehnt. Damit endet der Vorgang, bevor die Bearbeitung beginnt.
Warum das wichtig ist Die Analyse abgelehnter Anfragen kann Probleme mit der Begründung, den Anspruchsvoraussetzungen oder den Freigaberichtlinien aufzeigen. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf „Rejected“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „Rejected“ ändert. Ereignistyp inferred
	Anfrage freigegeben	Die zuständige Stelle hat die Serviceanfrage formell freigegeben. Damit kann die Bearbeitung fortgesetzt werden. Dieses Ereignis folgt üblicherweise auf den Status „Waiting for Approval“.
Warum das wichtig ist Dieses Ereignis markiert das Ende des Freigabe-Teilprozesses. Es ist ein wichtiger Meilenstein, um die Dauer von Freigaben und ihre Auswirkungen auf die gesamte Lösungszeit zu messen. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request von „Waiting Approval“ zu einem nachfolgenden Status wie „Planning“ oder „In Progress“. Die Freigabeentscheidung selbst wird in zugehörigen Freigabeformularen protokolliert. Erfassung Timestamp der Statusänderung nach „Waiting Approval“ nach einer positiven Freigabeentscheidung. Ereignistyp inferred
	Anfrage in Prüfung	Der Service Desk prüft und priorisiert die Serviceanfrage zunächst, um ihre Art und Priorität sowie das zuständige Fulfillment-Team zu bestimmen. Dies zeigt sich üblicherweise an einer Statusänderung im Anfragedatensatz.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft, die Effizienz der Priorisierung zu messen und Verzögerungen zwischen Einreichung und Zuweisung zu erkennen. Das ist wichtig für die KPI „Durchschnittliche Priorisierungszeit“. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf einen Wert wie „In Review“ oder „Planning“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „In Review“ ändert. Ereignistyp inferred
	Anfrage wartet auf Freigabe	Die Serviceanfrage wurde einer zuständigen freigabeberechtigten Person oder einer Freigabegruppe vorgelegt. Vor Beginn der Bearbeitung steht noch eine Entscheidung aus. Dieser Schritt ist bei Anfragen zu Kosten oder Zugriffsrechten üblich.
Warum das wichtig ist Mit dieser Aktivität lassen sich Verzögerungen bei Freigaben gesondert betrachten. So können Sie Freigabezeiten analysieren und Engpässe im Freigabeprozess erkennen. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf einen Wert wie „Waiting Approval“. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request in „Waiting Approval“ ändert. Ereignistyp inferred
	Anfrage wieder aufgenommen	Die Serviceanfrage wurde aus einem ausstehenden oder wartenden Status genommen, üblicherweise nachdem der Benutzer die benötigten Informationen bereitgestellt hat. Der zuständige Agent setzt die Bearbeitung fort.
Warum das wichtig ist Dieses Ereignis markiert das Ende einer Wartezeit. So lassen sich externe Wartezeiten und ihre Auswirkungen auf die SLA-Einhaltung genau messen. Woher beziehen Abgeleitet, wenn sich der Status von SRM:Request von „Pending“ zurück zu „In Progress“ ändert. Erfassung Timestamp des Aktualisierungsereignisses, bei dem sich das Feld „Status“ in SRM:Request von „Pending“ in „In Progress“ ändert. Ereignistyp inferred
	Informationen beim Benutzer angefordert	Der zuständige Agent benötigt weitere Informationen vom Anfragenden, um die Arbeit fortzusetzen. Die Anfrage erhält dabei üblicherweise den Status „Pending“.
Warum das wichtig ist Diese Aktivität ist wichtig, um die „Wartezeit auf externe Informationen“ zu berechnen und zu ermitteln, wie oft Anfragen wegen fehlender Angaben ins Stocken geraten. Woher beziehen Abgeleitet aus einer Statusänderung im Formular SRM:Request auf „Pending“ mit einem Statusgrund wie „Customer Hold“ oder „Awaiting Information“. Erfassung Timestamp der Statusänderung auf „Pending“ in Verbindung mit einem bestimmten Statusgrund. Ereignistyp inferred
	Lösung umgesetzt	Der Agent hat die für die Serviceanfrage erforderlichen technischen Arbeiten abgeschlossen. Nun kann der Benutzer die Lösung bestätigen, bevor die Anfrage formell gelöst wird.
Warum das wichtig ist Diese Aktivität trennt den technischen Abschluss von der formellen Lösung. So lassen sich Verzögerungen zwischen dem Abschluss der Arbeiten und der Bestätigung durch den Benutzer erkennen. Woher beziehen Dieses Ereignis lässt sich möglicherweise aus einer Statusänderung in einem nachgelagerten Fulfillment-Ticket ableiten, zum Beispiel aus dem Status „Completed“ eines Work Order, bevor die übergeordnete SRM:Request als „Resolved“ markiert wird. Erfassung Timestamp, zu dem ein mit SRM:Request verknüpftes nachgelagertes Ticket, etwa ein Work Order oder Incident, als abgeschlossen markiert wird. Ereignistyp inferred
	Lösung vom Benutzer bestätigt	Der Anfragende hat bestätigt, dass der Service zufriedenstellend erbracht und die Anfrage gelöst wurde. Dies löst häufig den endgültigen Abschluss der Anfrage aus.
Warum das wichtig ist Dieses Ereignis gibt einen klaren Hinweis auf die Kundenzufriedenheit und schließt die Serviceinteraktion formell ab. Es unterscheidet die Lösung des Vorgangs von der Annahme durch den Kunden. Woher beziehen Dieses Ereignis wird möglicherweise in den Arbeitsprotokollen oder Aktivitätsnotizen von SRM:Request erfasst, wenn ein Benutzer die Lösung über das Portal oder per E-Mail bestätigt. Es gibt nicht immer einen eigenen Status dafür. Erfassung Durchsuchen Sie die Arbeitsprotokolle (SRM:WorkInfo) nach Einträgen, die eine Bestätigung durch den Benutzer oder den Abschluss einer Umfrage anzeigen. Ereignistyp explicit

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 den Berichtsbereich und starten Sie Smart Reporting. Je nach Version heißt der Bereich möglicherweise „Berichte“ oder „Smart Reporting“.
Neuen Bericht erstellen: Wählen Sie in Smart Reporting die Option zum Erstellen eines neuen Berichts. Wählen Sie als Typ „Bericht“.
Datenquelle und Ansicht auswählen: Wählen Sie die gewünschte Datenquelle aus. Verwenden Sie Ihre primäre AR-System-Datenquelle. Suchen Sie bei der Ansicht nach der Service-Request-Ansicht und wählen Sie sie aus. Sie basiert in der Regel auf dem Formular SRM:Request.
Weitere Formulare verknüpfen (Joins): Um den gesamten Prozessverlauf abzubilden, müssen Sie das Hauptformular SRM:Request mit den zugehörigen Formularen verknüpfen. Öffnen Sie die Registerkarte „Daten“ und fügen Sie folgende Verknüpfungen hinzu:
- SRM:WorkInfo (über SR ID+ = Request Number), um Details zu Bearbeitungsaktivitäten und Arbeitsprotokollen abzurufen.
- AP:Signature (über Request = SRInstanceID), um Ereignisse zu Genehmigungen und Ablehnungen zu erfassen. Dafür benötigen Sie möglicherweise eine benutzerdefinierte Verknüpfung.
Berichtsspalten festlegen: Ziehen Sie die benötigten Felder aus den verknüpften Formularen per Drag-and-drop in den Bereich „Spalten“. Dazu gehören beispielsweise die Felder Request Number, Submit Date, Status, Beschreibung, Priority, Assigned To und Assigned Group aus SRM:Request sowie zugehörige Felder aus den verknüpften Formularen.
Berechnete Felder für Aktivitäten erstellen: Für diese Methode erstellen Sie mehrere berechnete Felder, die jeweils den Timestamp einer Aktivität abbilden. Öffnen Sie die Registerkarte „Daten“ und erstellen Sie für jede Aktivität ein berechnetes Feld. Beispiele:
- Timestamp der Einreichung: Verwenden Sie direkt das Feld Submit Date.
- Timestamp der Genehmigung: Verwenden Sie Signature Date aus dem Formular AP:Signature.
- Timestamp für „In Bearbeitung“: Verwenden Sie MIN(Submit Date) aus SRM:WorkInfo, gruppiert nach Request Number.
Bericht für die Zusammenführung strukturieren: Smart Reporting bietet keine einfache Schaltfläche für „UNION ALL“ wie SQL. Erstellen Sie stattdessen einen einzelnen Bericht und verwenden Sie erweiterte Funktionen oder Unterabfragen, um die Daten umzustrukturieren. Eine gängige Methode ist, für den Timestamp jeder Aktivität eine eigene berechnete Spalte anzulegen. Anschließend müssen Sie den Export so aufbereiten, dass für jede Aktivität eine eigene Zeile entsteht.
Filter anwenden: Begrenzen Sie den Datenumfang und verbessern Sie die Leistung, indem Sie Filter für den Bericht festlegen. Filtern Sie mindestens nach Submit Date aus dem Formular SRM:Request, um einen bestimmten Zeitraum auszuwählen. Wenn Sie in einer Umgebung mit mehreren Mandanten arbeiten, können Sie zusätzlich nach „Company“ filtern.
Bericht ausführen und Daten prüfen: Führen Sie den Bericht aus und kontrollieren Sie, ob die Daten korrekt abgerufen werden. Prüfen Sie die Verknüpfungen und gefüllten Spalten sowie die berechneten Felder und deren Timestamps.
Bericht exportieren: Exportieren Sie die Daten, sobald Sie den Bericht geprüft haben. Wählen Sie als Format CSV oder Microsoft Excel. Diese Formate lassen sich problemlos für den Import in Process-Mining-Tools aufbereiten.
Daten abschließend umwandeln: Wandeln Sie die Daten nach dem Export vom breiten Format (eine Zeile pro Serviceanfrage mit mehreren Timestamp-Spalten) in ein langes Format um (eine Zeile pro Aktivität). Verwenden Sie dazu ein Skript, etwa in Python oder PowerShell, oder ein Tool wie Excel Power Query. Überführen Sie die Timestamp-Spalten in zwei Spalten: ActivityName und EventStartTime. Dieser Schritt ist entscheidend, damit das Event Log die erforderliche Struktur erhält.

Konfiguration

Voraussetzungen: Sie benötigen ein Benutzerkonto mit Berichtsberechtigungen in BMC Helix ITSM. Dazu gehört insbesondere der Zugriff zum Erstellen und Ausführen von Berichten in Smart Reporting. Außerdem benötigen Sie Leseberechtigungen für die Formulare SRM:Request, SRM:WorkInfo und AP:Signature.
Wichtige Formulare: Der Bericht wird durch Verknüpfung dieser zentralen Formulare erstellt:
- SRM:Request: Das Hauptformular mit den grundlegenden Angaben zur Serviceanfrage.
- SRM:WorkInfo: Enthält Arbeitsprotokolle, aus denen sich Bearbeitungsaktivitäten ableiten lassen.
- AP:Signature: Enthält Genehmigungsdatensätze, die für die Erfassung von Genehmigungsaktivitäten erforderlich sind.
Zeitraumfilter: Wenden Sie immer einen Zeitraumfilter auf das Feld SRM:Request.Submit Date an. Empfohlen wird ein Zeitraum von 3 bis 6 Monaten. So erhalten Sie eine aussagekräftige Stichprobe, ohne die Berichtsleistung unnötig zu beeinträchtigen.
Wichtige Filter: Filtern Sie zusätzlich zum Zeitraum nach „Company“, um die Daten einer bestimmten Geschäftseinheit auszuwählen. Sie können auch bestimmte Anfragetypen oder Statuswerte ausschließen, etwa „Entwurf“, wenn sie für die Prozessanalyse nicht relevant sind.
Leistungsaspekte: Berichte, die mehrere Formulare über einen langen Zeitraum verknüpfen, können langsam erstellt werden. Bei großen Datenmengen empfiehlt es sich, den Bericht außerhalb der Hauptnutzungszeiten auszuführen. Bei Zeitüberschreitungen können Sie die Extraktion in kleinere monatliche Abschnitte aufteilen.

a Beispielabfrage sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Schritte

Voraussetzungen: Stellen Sie sicher, dass Sie über einen Datenbank-Client wie DBeaver, SQL Server Management Studio oder Oracle SQL Developer sowie über schreibgeschützte Zugangsdaten für die BMC-Helix-AR-System-Datenbank verfügen.
Mit der Datenbank verbinden: Stellen Sie mit Ihrem Datenbank-Client eine Verbindung zum AR-System-Datenbankserver her.
Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „Abfrage“ dieses Dokuments in den Abfrage-Editor Ihres Datenbank-Clients.
Parameter festlegen: Suchen Sie die Platzhalter in der Abfrage. Ersetzen Sie :start_date und :end_date durch den gewünschten Zeitraum für die Extraktion, zum Beispiel 2023-01-01 und 2023-12-31. Ersetzen Sie :company_name gegebenenfalls durch den Namen des Unternehmens, nach dem Sie filtern möchten.
Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage aus. Je nach Zeitraum und Größe des Systems kann dies mehrere Minuten dauern.
Ergebnisse prüfen: Nach Abschluss der Abfrage wird eine Ergebnismenge mit dem Event Log angezeigt. Prüfen Sie kurz, ob die Daten korrekt vorliegen und die erwarteten Spalten und Aktivitäten enthalten sind.
Timestamps prüfen: Kontrollieren Sie, ob alle Timestamp-Spalten, insbesondere EventStartTime, EventEndTime und LastDataUpdate, einheitlich formatiert sind, zum Beispiel als YYYY-MM-DD HH:MI:SS. Gibt Ihre Datenbank ein anderes Format zurück, passen Sie die Funktionen TO_CHAR oder CONVERT in der Abfrage entsprechend an.
Daten exportieren: Speichern Sie die vollständige Ergebnismenge über die Exportfunktion Ihres Datenbank-Clients als CSV-Datei. Wählen Sie die UTF-8-Kodierung, um die Kompatibilität sicherzustellen.
Upload vorbereiten: Geben Sie der Datei einen aussagekräftigen Namen, zum Beispiel servicerequest_eventlog.csv. Anschließend können Sie sie in ProcessMind hochladen.

Konfiguration

Datenbankzugangsdaten: Sie benötigen ein schreibgeschütztes Benutzerkonto für die AR-System-Datenbank. So vermeiden Sie versehentliche Änderungen an den Daten und halten bewährte Sicherheitspraktiken ein.
Zeitraumfilter: Die Abfrage enthält die Platzhalter :start_date und :end_date. Legen Sie unbedingt einen konkreten, angemessenen Zeitraum fest, üblicherweise 3 bis 12 Monate. So lassen sich Abfrageleistung und Datenvolumen kontrollieren. Der Filter wird auf Submit_Date der Serviceanfrage angewendet.
Unternehmensfilter: Der Platzhalter :company_name dient dazu, Anfragen eines bestimmten Unternehmens herauszufiltern. Wenn Sie Daten für alle Unternehmen extrahieren möchten, entfernen Sie die Zeile AND req.Company = :company_name oder setzen Sie einen Platzhalterwert ein, sofern dieser unterstützt wird.
Statuswerte: Die Abfrage verwendet die standardmäßigen ganzzahligen Statuswerte von BMC Helix ITSM, zum Beispiel Submitted = 0 und In Review = 1. In Ihrem System können benutzerdefinierte Statuswerte oder andere Zuordnungen gelten. Prüfen Sie die Werte im Formular SYS:Status oder im Developer Studio und passen Sie bei Bedarf die WHERE-Klauseln der Abfrage an.
Leistung: Direkte Datenbankabfragen auf großen Tabellen wie SRM_Request und den zugehörigen Audit-Protokollen können viele Ressourcen beanspruchen. Führen Sie die Extraktion außerhalb der Hauptnutzungszeiten aus, um die Systemleistung möglichst wenig zu beeinträchtigen.

a Beispielabfrage sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist. Installieren Sie die für HTTP-API-Aufrufe benötigte Bibliothek requests, indem Sie im Terminal oder in der Eingabeaufforderung pip install requests ausführen.
API-Zugangsdaten beschaffen: Erstellen Sie in BMC Helix ITSM ein eigenes Dienstkonto oder lassen Sie sich Zugangsdaten dafür geben. Das Konto benötigt mindestens Leseberechtigungen für das Formular SRM:Request und das zugehörige Audit-Protokollformular, das häufig SRM:Request_AuditLog oder ähnlich heißt. Notieren Sie sich den Benutzernamen, das Passwort und die Basis-URL Ihrer BMC-Helix-Instanz, zum Beispiel https://[your-company].bmc.com.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_servicerequests.py. Bearbeiten Sie das Skript und tragen Sie oben die Werte für die Platzhalter BASE_URL, USERNAME, PASSWORD und AUDIT_FORM_NAME ein. Passen Sie das Dictionary STATUS_ACTIVITY_MAP an die Statuswerte an, die in Ihrem Service-Request-Workflow verwendet werden.
Extraktionszeitraum festlegen: Ändern Sie die Variablen START_DATE und END_DATE im Skript. Damit legen Sie den Zeitraum für die Extraktion anhand des Einreichungsdatums der Serviceanfrage fest. Testen Sie das Skript zunächst mit einem kurzen Zeitraum, etwa einem einzelnen Tag.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_servicerequests.py. Zunächst authentifiziert sich das Skript über die API, um ein Token abzurufen.
Erste Datenabfrage: Das Skript fragt das Formular SRM:Request ab und ruft eine Liste aller Serviceanfragen ab, die im festgelegten Zeitraum erstellt wurden. Dabei werden die Case-ID und zugehörige statische Attribute wie Priorität und Servicetyp erfasst.
Ereignisverlauf abrufen: Das Skript verarbeitet nacheinander die IDs aller Serviceanfragen aus dem vorherigen Schritt. Für jede ID fragt es das konfigurierte Audit-Protokollformular erneut über die API ab, um den detaillierten Verlauf der Statusänderungen für diese Anfrage abzurufen.
Daten in ein Event Log umwandeln: Für jeden Datensatz aus dem Audit-Protokoll ordnet das Skript die Statusänderung mithilfe von STATUS_ACTIVITY_MAP einem standardisierten Aktivitätsnamen zu. Für jede zugeordnete Aktivität erstellt es eine Zeile mit der Service-Request-ID, dem Aktivitätsnamen und dem Timestamp der Änderung.
Ereignis „Eingereicht“ erstellen: Für jede Anfrage erstellt das Skript außerdem die anfängliche Aktivität „Serviceanfrage eingereicht“. Dafür verwendet es Submit Date aus dem Hauptformular SRM:Request.
Als CSV exportieren: Nachdem das Skript alle Serviceanfragen und deren Verläufe verarbeitet hat, führt es die erstellten Zeilen in einer Liste zusammen und schreibt die Daten in die CSV-Datei servicerequest_event_log.csv. Die Datei ist für den Upload in ein Process-Mining-Tool vorbereitet.

Konfiguration

API-Endpunkte: Das Skript verwendet hauptsächlich zwei API-Endpunkte. Die Authentifizierung erfolgt über api/jwt/login. Die Daten werden über arsys/v1/entry/SRM:Request für die Liste der Cases und über arsys/v1/entry/[AUDIT_FORM_NAME] für den Ereignisverlauf abgefragt.
Berechtigungen des Dienstkontos: Sie benötigen ein eigenes Dienstkonto mit Lesezugriff auf das Formular SRM:Request und das Audit-Protokollformular des Systems. Ein Dienstkonto ist wichtig für Sicherheit und Nachvollziehbarkeit.
Zeitraumfilter: Das Skript filtert Serviceanfragen anhand von Submit Date. Für eine zuverlässige Ausführung empfiehlt es sich, die Daten in überschaubaren Abschnitten zu extrahieren, beispielsweise jeweils über 3 bis 6 Monate.
Zuordnung von Status zu Aktivitäten: Das Dictionary STATUS_ACTIVITY_MAP im Skript bildet den Kern der Umwandlungslogik. Konfigurieren Sie es sorgfältig, damit es die benutzerdefinierten Statuswerte Ihrer Organisation abbildet und den gewünschten Aktivitätsnamen zuordnet. Statuswerte, die nicht im Dictionary enthalten sind, werden ignoriert.
Audit-Protokollformular: Ob das Skript detaillierte Aktivitäten erfassen kann, hängt vollständig davon ab, ob ein abfragbares Audit-Protokoll vorhanden ist. Ermitteln Sie den Namen des Formulars in Ihrer Umgebung, in dem der Verlauf der Statusänderungen von Serviceanfragen gespeichert wird, und tragen Sie ihn in der Variablen AUDIT_FORM_NAME ein.
Seitennummerierung: Das Skript verarbeitet die API-Seitennummerierung automatisch, um alle Datensätze abzurufen. Der Parameter limit ist auf 1.000 Datensätze pro Anfrage gesetzt, um Leistung und Speicherbedarf auszubalancieren.

a Beispielabfrage python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

Möchten Sie loslegen?

Mit diesem Template vereinfachen Sie die Datenerfassung und starten Ihre Process-Mining-Analyse auf einer verlässlichen Grundlage. Beginnen Sie noch heute damit, Ihr Service-Request-Management zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Mehr Effizienz im Service-Request-Management: Verbessern Sie Ihre Abläufe

Erreichen Sie eine Automatisierungsquote von 70 %, vermeiden Sie Verzögerungen bei der Bearbeitung und steigern Sie die Zufriedenheit der Benutzer.

Kostenlose Testphase starten

Keine Kreditkarte erforderlich. Sie können in wenigen Minuten loslegen.

Ihr Daten-Template für das Serviceanfragemanagement

Ihr Daten-Template für das Serviceanfragemanagement

Attribute des Serviceanfragemanagements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

BMC Helix ITSM Smart Reporting für Serviceanfragen

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage der AR-System-Datenbanktabellen

Schritte

Konfiguration

a Beispielabfrage sql

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

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Mehr Effizienz im Service-Request-Management: Verbessern Sie Ihre Abläufe

Ihr Daten-Template für das Serviceanfragemanagement

Ihr Daten-Template für das Serviceanfragemanagement

Attribute des Serviceanfragemanagements

Aktivitäten im Service-Request-Management

Anleitungen zur Datenextraktion

BMC Helix ITSM Smart Reporting für Serviceanfragen

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage der AR-System-Datenbanktabellen

Schritte

Konfiguration

a Beispielabfrage sql

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

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Mehr Effizienz im Service-Request-Management: Verbessern Sie Ihre Abläufe

Der Schutz Ihrer Daten ist uns wichtig