> Kontinuierliche Prozessoptimierung > Serviceanfragen Management > BMC Helix ITSM > Datenvorlage

Ihre Service Request Management Daten-Template

BMC Helix ITSM

Attribute im Service Request Management (21) Aktivitäten im Service Request Management (14) Extraktionsleitfäden (3)

Ihre Service Request Management Daten-Template

Diese Template bietet einen klaren Überblick über die wesentlichen Datenattribute, die gesammelt werden müssen, und die Schlüsselaktivitäten, die für Ihren Service Request Management Prozess nachverfolgt werden sollen. Sie enthält auch praktische Anleitungen, wie diese Daten effizient aus BMC Helix ITSM extrahiert werden können. Nutzen Sie diese Ressource, um Ihre Datenvorbereitung zu optimieren und Ihre Process Mining Initiativen mit Vertrauen zu starten.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung für BMC Helix ITSM

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

Vorlage herunterladen

Attribute im Service Request Management

Diese Datenfelder sind unerlässlich, um einen umfassenden Event Log zu erstellen, der eine tiefgehende Analyse Ihres Service Request Management Prozesses ermöglicht.

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des spezifischen Events oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Lebenszyklus der Serviceanfrage stattfand.
Beschreibung Dieses Attribut beschreibt einen spezifischen Schritt oder eine Statusänderung im Service-Anfrage-Prozess, wie zum Beispiel „Anfrage in Prüfung“, „Bearbeitung im Gange“ oder „Service-Anfrage gelöst“. Jede Aktivität repräsentiert ein einzelnes Event in der End-to-End-Reise einer Service-Anfrage. Die Analyse der Sequenz und Häufigkeit von Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Entdeckung von Prozesskarten, die Identifizierung von Bottlenecks und die Analyse von Prozessvarianten. Zu verstehen, welche Aktivitäten in welcher Reihenfolge und wie oft auftreten, ist entscheidend für die Prozessoptimierung. Bedeutung Aktivitäten bilden die Bausteine der Prozesslandkarte. Ihre Verfolgung ermöglicht die Visualisierung und Analyse des Prozessflusses und offenbart, wie die Arbeit tatsächlich ausgeführt wird. Datenquelle Dies wird typischerweise aus Änderungen in den Feldern „Status“ und „Status Reason“ im SRM:Request-Formular oder verwandten Bearbeitungsanwendungs-Logs (z.B. Incident, Work Order) abgeleitet. Beispiele Anfrage wartet auf GenehmigungErfüllung in BearbeitungServiceanfrage gelöstServiceanfrage geschlossen
	Serviceanfrage-ID ServiceRequestId	Der eindeutige Identifikator für jede Service-Anfrage, der als Primärschlüssel zur Nachverfolgung des gesamten Lebenszyklus dient.
Beschreibung Die Service Request ID identifiziert eindeutig jede einzelne Service-Anfrage, die von einem Benutzer oder System eingereicht wurde. Sie dient als zentraler Faden, der alle nachfolgenden Events, von der initialen Protokollierung bis zum finalen Abschluss, miteinander verbindet und eine vollständige End-to-End-Analyse der Reise jeder Service-Anfrage ermöglicht. Im Process Mining ist diese ID unerlässlich, um die Abfolge der Aktivitäten für jeden Case zu rekonstruieren. Sie ermöglicht es dem Tool, alle zusammengehörigen Events, wie „Anfrage eingereicht“, „Anfrage zugewiesen“ und „Service-Anfrage geschlossen“, zu einer einzigen Prozessinstanz zusammenzufassen, die die Grundlage für alle Prozessanalysen bildet. Bedeutung Dies ist der fundamentale Case Identifier. Ohne ihn ist es unmöglich, die End-to-End-Reise einer Service-Anfrage nachzuvollziehen, was die Prozesserkennung und -analyse unmöglich macht. Datenquelle Dies ist typischerweise das Feld „InstanceId“ oder „Request Number“ im SRM:Request-Formular in BMC Helix ITSM. Beispiele SR000010572931SR000010572932SR000010572933
	Startzeit EventStartTime	Der Timestamp, der den Beginn einer bestimmten Aktivität oder eines Events anzeigt.
Beschreibung Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität begonnen hat. Jedes Event im Log, von der initialen Einreichung bis zum finalen Abschluss, muss eine Start Time haben, um die chronologische Reihenfolge des Prozesses festzulegen. Dieser Timestamp ist entscheidend für alle zeitbasierten Process Mining Analysen. Er wird verwendet, um Cycle Times, Dauer von Aktivitäten, Wartezeiten zwischen den Schritten zu berechnen und die SLA-Compliance zu überprüfen. Er ermöglicht die Entdeckung von Bottlenecks und die Analyse der Prozess-Performance über die Zeit. Bedeutung Die Start Time liefert die chronologische Reihenfolge der Events, die für die Berechnung von Prozessdauern, die Identifizierung von Verzögerungen und das Verständnis des Prozesszeitplans unerlässlich ist. Datenquelle Dies entspricht den Timestamp-Feldern in den Audit Logs oder Statusverlaufstabellen, die mit dem SRM:Request-Formular verknüpft sind, wie z.B. „Submit Date“ für das initiale Event. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, wann 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 bietet Benutzern Kontext zur Aktualität der analysierten Daten und stellt sicher, dass sie den durch die Analyse abgedeckten Zeitraum kennen. Dies ist ein kritisches Metadaten-Attribut für jedes Process Mining Dashboard oder jede Analyse. Es ermöglicht Benutzern zu verstehen, ob die Erkenntnisse auf nahezu Echtzeitdaten oder einem historischen Snapshot basieren, was die Gültigkeit und Relevanz der gezogenen Schlussfolgerungen beeinflusst. Bedeutung Es informiert Benutzer über die Aktualität der Daten, was entscheidend ist, um Entscheidungen auf der Grundlage der aktuellsten verfügbaren Prozessleistungsinformationen zu treffen. Datenquelle Dieser Timestamp wird während des Datenextraktions- und Ladevorgangs generiert und hinzugefügt. Beispiele 2024-05-21T08:00:00Z
	Quellsystem SourceSystem	Identifiziert das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt den Ursprung der Prozessdaten an. Für diese Ansicht wäre es statisch auf „BMC Helix ITSM“ gesetzt, um anzuzeigen, dass alle Events im Zusammenhang mit den Service-Anfragen aus diesem System stammen. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld entscheidend für das Verständnis der Datenherkunft und die Partitionierung von Daten basierend auf ihrer Quelle. Es gewährleistet Klarheit und Nachvollziehbarkeit, insbesondere beim Zusammenführen von Daten aus verschiedenen Plattformen. Bedeutung Es liefert Kontext zur Datenherkunft, was wichtig für Data Governance, Nachvollziehbarkeit und Fehlerbehebung in Multi-System-Umgebungen ist. Datenquelle Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird und kein Feld innerhalb von BMC Helix ITSM selbst ist. Beispiele BMC Helix ITSM
	Anfragestatus RequestStatus	Der Status der Service-Anfrage zum Zeitpunkt des Events, wie zum Beispiel „In Bearbeitung“, „Ausstehend“ oder „Geschlossen“.
Beschreibung Dieses Attribut erfasst den Status der Service-Anfrage zu verschiedenen Zeitpunkten in ihrem Lebenszyklus. Der Status bietet Kontext für jede Aktivität und ist oft die Quelle, aus der das Attribut „Aktivität“ selbst abgeleitet wird. Eine Analyse nach Status hilft zu verstehen, wie viel Zeit Anfragen in bestimmten Zuständen verbringen, wie z.B. „Wartet auf Kunden“ oder „Wartet auf Genehmigung“. Dies ist entscheidend für die Identifizierung von Bottlenecks und Verzögerungen, die durch externe Abhängigkeiten oder interne Warteschlangen verursacht werden. Es unterstützt direkt das Bottleneck Identification Dashboard. Bedeutung Es bietet einen Überblick über den Status der Anfrage und ermöglicht die Analyse der Zeit, die in Wartezuständen im Vergleich zu aktiven Zuständen verbracht wird, was entscheidend für die Identifizierung von Engpässen ist. Datenquelle Dies ist das Feld „Status“ im SRM:Request-Formular. Historische Werte finden Sie im Audit Log. Beispiele PlanungIn BearbeitungPendingGelöstGeschlossen
	Endzeit EventEndTime	Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die End Time markiert den Abschluss einer Aktivität. Während viele Aktivitäten in ITSM-Systemen sofortige Statusänderungen sind, haben einige eine messbare Dauer. Eine End Time ermöglicht die präzise Berechnung der Dauer solcher Aktivitäten. In der Analyse wird die End Time in Verbindung mit der Start Time verwendet, um die Bearbeitungszeit für einzelne Aktivitäten zu berechnen. Dies hilft, genau zu bestimmen, welche spezifischen Aufgaben, und nicht nur die Wartezeit dazwischen, die meiste Zeit im Prozess in Anspruch nehmen. Bedeutung Es ermöglicht die Berechnung von Aktivitätsbearbeitungszeiten, was entscheidend ist, um ineffiziente Schritte zu identifizieren und zu verstehen, wo Ressourcen ihre Zeit verbringen. Datenquelle Dies kann abgeleitet werden. Die End Time einer Aktivität ist oft die Start Time der nächsten sequentiellen Aktivität für denselben Case. Für die finale Aktivität wäre es der Lösungs- oder Abschluss-Timestamp. Beispiele 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Priorität Priority	Die der Service-Anfrage zugewiesene Prioritätsstufe, die deren geschäftliche Auswirkungen und Dringlichkeit anzeigt.
Beschreibung Die Priorität bestimmt die Reihenfolge und Geschwindigkeit, mit der Anfragen bearbeitet werden sollen. Gängige Werte sind 'Kritisch', 'Hoch', 'Mittel' und 'Niedrig'. Diese Zuweisung basiert oft auf einer Kombination aus der Auswirkung der Anfrage auf das Geschäft und ihrer Dringlichkeit. Die Analyse nach Priorität ist entscheidend, um zu bewerten, ob Anfragen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. Sie ist eine Schlüsseldimension in Dashboards für Lösungszeit und SLA-Einhaltung und hilft sicherzustellen, dass Ressourcen angemessen den kritischsten Geschäftsanforderungen zugewiesen werden. Bedeutung Es hilft bei der Beurteilung, ob der Prozess die Arbeit korrekt priorisiert und die erwarteten Service-Levels für Anfragen mit unterschiedlichem Geschäftseinfluss erfüllt. Datenquelle Dies ist das Feld „Priority“ im SRM:Request-Formular. Beispiele KritischHochMittelNiedrig
	Serviceart ServiceType	Die Kategorie oder Art des vom Benutzer angefragten Services.
Beschreibung Der Service Type klassifiziert die Art der Anfrage, zum Beispiel „Neue Software anfordern“, „Passwort zurücksetzen“ oder „Neuen Mitarbeiter einbinden“. Er ist eine grundlegende Dimension zur Filterung und Segmentierung der Prozessdaten. In der Prozessanalyse wird dieses Attribut verwendet, um die Performance verschiedener Anfragetypen zu vergleichen. Es hilft, Fragen zu beantworten wie: „Welche Service Types benötigen am längsten zur Lösung?“ oder „Welche Service Types erfordern die meiste Nacharbeit?“. Dies ist entscheidend für die Dashboards zu Resolution Time und SLA Compliance. Bedeutung Es ermöglicht die Segmentierung von Serviceanfragen, um Prozessabläufe zu vergleichen, typspezifische Probleme zu identifizieren und Optimierungsbemühungen effektiv anzupassen. Datenquelle Diese Daten finden sich oft im Feld „Title“ oder einem Kategorisierungsfeld im SRM:Request-Formular, abgeleitet vom ausgewählten Service im Katalog. Beispiele Neue HardwareanfrageSoftware-ZugriffsanfrageVPN-Zugang einrichten
	Zugewiesener Agent AssignedAgent	Der einzelne Benutzer, der derzeit mit der Bearbeitung der Service-Anfrage beauftragt ist.
Beschreibung Dieses Attribut identifiziert den spezifischen IT-Agenten oder Support-Mitarbeiter, der zu einem bestimmten Zeitpunkt für die Anfrage zuständig ist. Änderungen in diesem Feld über den Lebenszyklus einer einzelnen Anfrage deuten auf eine Übergabe oder Neuzuweisung hin. Dieses Attribut ist entscheidend für die Agenten-Performance- und Arbeitslastanalyse. Es ermöglicht die Nachverfolgung, wie viele Anfragen jeder Agent bearbeitet, deren durchschnittliche Lösungszeit und die Häufigkeit von Neuzuweisungen. Diese Daten unterstützen das Ressourcenmanagement und die Identifizierung von Schulungsmöglichkeiten. Bedeutung Die Nachverfolgung des zugewiesenen Agenten ist unerlässlich für die Analyse von Übergaben, die Messung der individuellen Performance und das Verständnis der Arbeitslastverteilung im Support-Team. Datenquelle Dies entspricht dem Feld „Assignee“ oder „Assigned To“ im Bearbeitungsdatensatz (z.B. Work Order, Incident), der mit der Service-Anfrage verknüpft ist. Beispiele Bob SmithAlice JohnsonCharlie Brown
	Zugewiesenes Team AssignedTeam	Die Support-Gruppe oder das Team, das derzeit der Service-Anfrage zugewiesen ist.
Beschreibung Dieses Attribut identifiziert die funktionale Gruppe, die für die Bearbeitung der Anfrage zuständig ist, wie z.B. „Help Desk“, „Netzwerk-Team“ oder „Datenbankadministration“. Eine Änderung in diesem Feld bedeutet eine Übergabe der Verantwortung zwischen Teams. Die Analyse basierend auf dem zugewiesenen Team hilft, Bottlenecks auf Teamebene zu identifizieren, Übergaben zwischen Teams zu analysieren und die Effizienz verschiedener Support-Gruppen zu bewerten. Sie ist entscheidend für die Dashboards zu Request Rework und Reassignment sowie Triage Efficiency, da sie Muster aufzeigt, wie die Arbeit durch die Organisation geleitet wird. Bedeutung Es ermöglicht die Analyse des Prozessflusses zwischen verschiedenen Funktionsgruppen und hilft dabei, Routing-Ineffizienzen zu identifizieren und die Leistung auf Teamebene zu messen. Datenquelle Dies entspricht dem Feld „Assigned Group“ im Bearbeitungsdatensatz (z.B. Work Order, Incident), der mit der Service-Anfrage verknüpft ist. Beispiele `Service Desk`Infrastruktur-SupportAnwendungssupport Tier 2
	`Handoff`-Anzahl HandoffCount	Die Gesamtzahl der Male, die eine Service-Anfrage zwischen verschiedenen Agenten oder Teams neu zugewiesen wurde.
Beschreibung Diese berechnete Metrik zählt, wie oft sich der „AssignedAgent“ oder das „AssignedTeam“ für eine einzelne Service-Anfrage ändert. Eine hohe Anzahl von Übergaben kann auf Prozessfragmentierung, mangelnde Erstlösungsquote oder ineffizientes Routing hindeuten. Dieses Attribut ist die Grundlage für den KPI „Durchschnittliche Agentenübergaben pro Anfrage“ und wird im Dashboard „Request Rework und Reassignment“ verwendet. Die Analyse von Cases mit vielen Übergaben kann Möglichkeiten aufzeigen, die Triage zu verbessern, bessere Schulungen anzubieten oder den Lösungsprozess zu straffen, um Verzögerungen zu reduzieren und die Kundenzufriedenheit zu erhöhen. Bedeutung Es misst Prozessfragmentierung und Kommunikationsaufwand. Hohe Übergabezahlen korrelieren oft mit längeren Lösungszeiten und geringerer Prozesseffizienz. Datenquelle Dies ist eine berechnete Metrik, die durch Zählen der Anzahl der unterschiedlichen Werte im Attribut „AssignedAgent“ oder „AssignedTeam“ für jede eindeutige Service Request ID abgeleitet wird. Beispiele 0135
	`SLA` verletzt IsSlaBreached	Ein boolesches Flag, das anzeigt, ob die Serviceanfrage nach ihrem SLA-Zieldatum gelöst wurde.
Beschreibung Dieses berechnete Flag ist auf „true“ gesetzt, wenn der finale Lösungs-Timestamp der Service-Anfrage später als ihr „SLA Target Date“ liegt. Es liefert ein einfaches, binäres Ergebnis für die SLA-Performance pro Anfrage. Dieses Attribut ist unerlässlich für das SLA Compliance Overview Dashboard und den KPI „SLA Adherence Rate“. Es ermöglicht eine einfache Aggregation zur Berechnung der Gesamt-Compliance-Raten und das Filtern, um die Prozesseigenschaften von verletzten Anfragen im Vergleich zu konformen Anfragen zu analysieren, was hilft, die Hauptursachen für SLA-Fehler zu identifizieren. Bedeutung Es vereinfacht die SLA-Leistungsanalyse, indem es einen Zeitstempelvergleich in ein einfaches boolesches Flag umwandelt, wodurch es leicht wird, die Compliance-Raten zu messen und zu visualisieren. Datenquelle Dies ist ein berechnetes Feld. Die Logik lautet: WENN „Resolution Timestamp“ > „SlaTargetDate“ DANN wahr SONST falsch. Beispiele truefalsch
	Abteilung des Antragstellers RequestorDepartment	Die Geschäftsabteilung oder Einheit des Benutzers, der die Anfrage eingereicht hat.
Beschreibung Dieses Attribut identifiziert die Organisationsabteilung der Person, die den Service anfordert, wie z.B. „Finanzen“, „Personalwesen“ oder „IT“. Diese Informationen stammen typischerweise aus dem Benutzerprofil im System. Die Segmentierung der Prozessanalyse nach Abteilung ermöglicht die Identifizierung abteilungsspezifischer Bedürfnisse, Anfragemuster und potenzieller Bereiche für gezielte Schulungen oder Serviceverbesserungen. Sie kann helfen, Fragen zu beantworten wie: „Hat die Finanzabteilung längere Wartezeiten bei ihren Anfragen?“ Bedeutung Es ermöglicht die Analyse des Serviceverbrauchs und der Prozessleistung pro Geschäftseinheit, was abteilungsspezifische Probleme oder Trends hervorheben kann. Datenquelle Diese Informationen werden üblicherweise aus dem Benutzerprofil abgerufen, das mit dem „Requested For“-Benutzer im SRM:Request-Formular verknüpft ist. Beispiele FinanzenVertriebPersonalwesenInformationstechnologie
	Durchlaufzeit CycleTime	Die Gesamtzeit, die von der Erstellung der Service-Anfrage bis zu ihrer endgültigen Lösung vergangen ist.
Beschreibung Die Zykluszeit, auch als End-to-End-Dauer bekannt, misst die gesamte Lebensdauer einer Serviceanfrage. Sie wird als Differenz zwischen dem Zeitstempel des ersten Ereignisses (z.B. „Service Request Submitted“) und dem letzten Lösungsereignis (z.B. „Service Request Resolved“) berechnet. Dies ist eine der grundlegendsten KPIs im Process Mining und unterstützt direkt das Dashboard zur Lösungszeit von Serviceanfragen. Die Analyse der durchschnittlichen Zykluszeit und deren Aufschlüsselung nach Dimensionen wie Servicetyp oder Priorität offenbart die Gesamteffizienz des Prozesses und hebt Bereiche hervor, die zu lange dauern. Bedeutung Dies ist ein primäres Maß für die Prozesseffizienz. Das Verständnis und die Reduzierung der Cycle Time ist oft ein Schlüsselziel von Prozessverbesserungsinitiativen. Datenquelle Dies ist eine berechnete Metrik. Sie wird abgeleitet, indem das „Submit Date“ vom „Closed Date“ oder „Resolved Date“ für jede eindeutige Service Request ID subtrahiert wird. Beispiele 2 Tage 4 Stunden8 Stunden 30 Minuten15 Tage
	Einreichungskanal SubmissionChannel	Die Methode oder der Kanal, über den die Service-Anfrage eingereicht wurde.
Beschreibung Dieses Attribut erfasst, wie die Service-Anfrage initiiert wurde, zum Beispiel über ein Self-Service Portal, E-Mail, Telefonanruf beim Service Desk oder eine automatisierte Systemwarnung. Verschiedene Kanäle können zu unterschiedlichen Prozessvarianten und Bearbeitungszeiten führen. Die Analyse des Prozesses nach Einreichungskanal kann Ineffizienzen oder Best Practices aufzeigen, die mit spezifischen Aufnahmemethoden verbunden sind. Beispielsweise können Anfragen, die über das Self-Service Portal eingereicht werden, aufgrund besserer initialer Datenqualität schneller gelöst werden, während E-Mail-Anfragen möglicherweise mehr manuelle Triage erfordern. Bedeutung Es hilft zu verstehen, wie die Erfassungsmethode die Prozesseffizienz, Datenqualität und die gesamte Zykluszeit beeinflusst, und ermöglicht gezielte Verbesserungen in spezifischen Kanälen. Datenquelle Dies kann oft aus Feldern wie „Client Type“ oder „Reported Source“ im SRM:Request-Formular oder zugehörigen Bearbeitungstickets abgeleitet werden. Beispiele Self-Service-PortalE-MailTelefonSystemgeneriert
	Ist eskaliert IsEscalated	Ein boolesches Flag, das angibt, ob die Serviceanfrage eskaliert wurde.
Beschreibung Dieses Flag ist auf „true“ gesetzt, wenn eine Service-Anfrage eine funktionale oder hierarchische Eskalation durchlaufen hat. Eine Eskalation tritt typischerweise auf, wenn eine Anfrage nicht wie erwartet voranschreitet, kurz vor einem SLA-Verstoß steht oder eine höhere Autorität zur Genehmigung oder Aktion erfordert. Dieses Attribut ist entscheidend für das Request Escalation Efficiency Analysis Dashboard. Es ermöglicht das Filtern und Analysieren der Prozesspfade eskalierter Anfragen, um zu verstehen, was sie auslöst, wie lange ihre Lösung nach der Eskalation dauert und wie effektiv der Eskalationsprozess ist. Bedeutung Es ermöglicht die Isolierung und Analyse der Untermenge von Anfragen, die eine Eskalation erforderten, und hilft dabei, Schwachstellen im Standardprozess oder Auslöser für komplexe Probleme zu identifizieren. Datenquelle Dies ist typischerweise kein einziges Feld. Es wird abgeleitet, indem im Audit Log nach spezifischen eskalationsbezogenen Aktivitäten oder nach Änderungen in der Priorität oder Zuweisung gesucht wird, die einem Eskalationsprotokoll folgen. Beispiele truefalsch
	Ist Nacharbeit IsRework	Ein boolesches Flag, das anzeigt, ob eine Serviceanfrage nachbearbeitet wurde, z.B. durch Rückkehr zu einem vorherigen Stadium.
Beschreibung Dieses Flag identifiziert Service-Anfragen, die einen Loop oder eine Nacharbeit in ihrem Prozessfluss erfahren haben. Zum Beispiel würde eine Anfrage, die von „Bearbeitung im Gange“ zurück zu „Anfrage in Prüfung“ wechselt, als Nacharbeit betrachtet werden. Die genaue Definition hängt von der Geschäftsprozesslogik ab. Dieses Attribut unterstützt direkt das Request Rework und Reassignment Analysis Dashboard und den KPI „Request Rework Rate“. Es ermöglicht die Quantifizierung der Häufigkeit von Nacharbeiten und die Analyse der häufigsten Ursachen, wie z.B. eine falsche initiale Bewertung oder unvollständige Informationen, die zu Prozessineffizienzen führen. Bedeutung Es quantifiziert die Prozesseffizienz, indem es Fälle kennzeichnet, die vom 'Optimalpfad' abweichen, und hilft so, die Ursachen für Schleifen und wiederholte Arbeit zu identifizieren. Datenquelle Dies ist ein berechnetes Attribut, das aus der Abfolge der Aktivitäten im Event Log abgeleitet wird. Es ist Logik erforderlich, um Rückwärtsbewegungen im Prozessfluss zu erkennen. Beispiele truefalsch
	Lösungskategorie ResolutionCategory	Die Klassifizierung der zur Lösung der Anfrage bereitgestellten Lösung.
Beschreibung Dieses Attribut bietet eine strukturierte Kategorisierung, wie eine Anfrage gelöst wurde, z.B. „Software-Fix“, „Benutzerschulung“ oder „Datenkorrektur“. Es geht über einen einfachen Close Code hinaus, um die Art der Lösung zu beschreiben. Dies ist unerlässlich für das Resolution Category Accuracy Dashboard, wo es mit dem initialen Service Type verglichen werden kann, um die Konsistenz zu überprüfen. Die Analyse von Lösungskategorien hilft, Trends bei Problemen zu identifizieren und ein proaktives Problemmanagement zu informieren, z.B. wenn viele Anfragen durch Benutzerschulungen gelöst werden. Bedeutung Es bietet Einblicke in die Art der Lösungen und hilft dabei, Trends bei wiederkehrenden Problemen sowie Möglichkeiten für proaktives Problemmanagement oder Benutzerschulungen zu identifizieren. Datenquelle Diese Informationen sind Teil der operationalen und Produktkategorisierungsfelder auf dem Bearbeitungsticket, oft als „Resolution Category“ bezeichnet. Beispiele Kontoverwaltung`Hardware`-AusfallSoftware-UpgradeInformationen bereitgestellt
	Schließcode CloseCode	Ein Code, der das Endergebnis oder den Grund für das Schließen der Serviceanfrage angibt.
Beschreibung Der Close Code bietet eine standardisierte Methode zur Klassifizierung der Lösung einer Service-Anfrage. Beispiele sind „Vom Service Desk gelöst“, „Vom Benutzer storniert“ oder „Duplizierte Anfrage“. Die Analyse von Close Codes hilft, die häufigsten Ergebnisse von Anfragen zu verstehen. Sie kann Probleme aufzeigen, wie eine hohe Anzahl von Anfragen, die von Benutzern storniert werden, was auf einen langwierigen Prozess hindeuten könnte, oder viele Duplikate, die auf ein System- oder Kommunikationsproblem hinweisen könnten. Dieses Attribut unterstützt das Resolution Category Accuracy Dashboard. Bedeutung Es liefert strukturierte Daten zu Anfrageergebnissen und ermöglicht die Analyse der Lösungseffektivität sowie der Gründe für Nicht-Abschluss oder Stornierung. Datenquelle Diese Informationen finden sich typischerweise in einem Feld „Resolution“ oder „Closure Code“ auf dem Bearbeitungsticket, das mit der Service-Anfrage verknüpft ist. Beispiele SuccessfulVom Benutzer storniertNicht länger erforderlichAutomatisierte Lösung
	SLA-Zieldatum SlaTargetDate	Das Datum und die Uhrzeit, bis zu denen die Service-Anfrage gemäß ihrem Service Level Agreement (SLA) voraussichtlich gelöst sein wird.
Beschreibung Das SLA Target Date ist ein berechneter Timestamp, der die Frist für den Abschluss der Service-Anfrage darstellt. Es wird durch die Service-Vereinbarungsregeln bestimmt, die oft Faktoren wie die Priorität und den Typ der Anfrage berücksichtigen. Dieses Attribut ist fundamental für das SLA Compliance Overview Dashboard. Es dient als Benchmark, an dem die tatsächliche Lösungszeit gemessen wird. Durch den Vergleich der „EventEndTime“ der finalen Lösungsaktivität mit diesem Zieldatum können wir feststellen, ob die Service-Zusage eingehalten wurde. Bedeutung Dies ist der primäre Benchmark zur Messung der Service-Performance im Vergleich zu Zusagen, wodurch er für das SLA Compliance Monitoring und Reporting unerlässlich ist. Datenquelle Dieses Datum wird vom Service Level Management (SLM) Modul berechnet und gespeichert und kann in verwandten SLM-Formularen gefunden werden, die mit der Service-Anfrage 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

Diese wichtigen Prozessschritte und Meilensteine sollten in Ihrem Event Log erfasst werden, um eine genaue Prozesserkennung und Visualisierung zu ermöglichen.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Anfrage zugewiesen	Die Service-Anfrage wurde einem spezifischen Bearbeitungsagenten oder Team zugewiesen, das für die Erledigung der Arbeit verantwortlich ist. Dies markiert das Ende der Triage-Phase.
Bedeutung Dieser Meilenstein ist entscheidend für die Messung der Triage-Zeit und die Analyse der Agenten-Arbeitslast. Häufige Neuzuweisungen können auf Routing-Probleme oder Qualifikationslücken hinweisen. Datenquelle Dieses Event kann explizit aus dem Audit Log der Felder „Assigned Group“ oder „Assignee“ im SRM:Request-Formular oder verwandten Bearbeitungsanwendungsformularen (z.B. WOI:WorkOrder) erfasst werden. Erfassen Timestamp aus dem Audit Log, der anzeigt, dass im Feld „Assignee“ zum ersten Mal ein nicht-null Wert gesetzt wurde. Ereignistyp explicit
	Erfüllung in Bearbeitung	Der zugewiesene Agent oder das Team hat aktiv mit der Bearbeitung der Service-Anfrage begonnen. Dies zeigt an, dass die Anfrage von einer Warteschlange in einen aktiven Arbeitszustand übergegangen ist.
Bedeutung Markiert den Beginn der wertschöpfenden Erfüllungsarbeit. Die Analyse der in dieser Phase verbrachten Zeit hilft, die Ressourcenproduktivität und die Komplexität der Erfüllung zu verstehen. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu 'In Progress'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „In Bearbeitung“ wechselt. Ereignistyp inferred
	Service-Anfrage eingereicht	Diese Aktivität markiert die Erstellung und Einreichung einer neuen Service-Anfrage durch einen Benutzer. Sie wird erfasst, wenn ein neuer Eintrag im SRM:Request Formular mit einem initialen Status, typischerweise „Eingereicht“, erstellt wird.
Bedeutung Dies ist der Startpunkt für jeden Service-Anfrage-Case, wesentlich für die Messung der gesamten Lebenszyklusdauer und die Analyse des Anfrageeingangsvolumens. Datenquelle Dieses Event wird aus dem Erstellungs-Timestamp und dem initialen Status (z.B. „Eingereicht“) eines Datensatzes im SRM:Request-Formular abgeleitet. Erfassen Identifizieren Sie den Erstellungs-Zeitstempel für eine neue Service Request ID im Formular `SRM:Request`, wenn der Status 'Submitted' ist. Ereignistyp inferred
	Service-Anfrage storniert	Die Service-Anfrage wurde entweder vom Antragsteller oder vom Service Desk zurückgezogen, bevor die Bearbeitung abgeschlossen war. Dies ist ein Endstatus für die Anfrage.
Bedeutung Die Nachverfolgung von Stornierungen hilft, Muster zu identifizieren, wie z.B. Benutzer, die falsche Anfragen einreichen oder Services, die nicht mehr benötigt werden, was wiederum zur Verbesserung des Servicekatalogs beitragen kann. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu 'Canceled'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „Storniert“ wechselt. Ereignistyp inferred
	Serviceanfrage gelöst	Die Bearbeitung der Service-Anfrage ist abgeschlossen, und die Lösung wurde dem Antragsteller mitgeteilt. Die Anfrage wartet auf die endgültige Bestätigung oder wird nach einer festgelegten Frist automatisch geschlossen.
Bedeutung Ein kritischer Meilenstein, der das Ende des Service-Bereitstellungszyklus markiert. Er ist der primäre Endpunkt zur Messung der Lösungszeit und der SLA-Einhaltung. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu 'Resolved' oder 'Completed'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „Gelöst“ oder „Abgeschlossen“ wechselt. Ereignistyp inferred
	Serviceanfrage geschlossen	Die Service-Anfrage wird formell geschlossen und in einen schreibgeschützten, archivierten Status überführt. Dies geschieht nach der Lösung und Ablauf einer etwaigen Bestätigungsfrist.
Bedeutung Diese Aktivität stellt das definitive Ende des Prozesses dar. Die Zeit zwischen „Gelöst“ und „Geschlossen“ kann Ineffizienzen im Abschlussverfahren aufzeigen. Datenquelle Abgeleitet aus der letzten Statusänderung im Formular `SRM:Request` zu 'Closed'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „Geschlossen“ wechselt. Ereignistyp inferred
	Anfrage abgelehnt	Die Service-Anfrage wurde während einer Genehmigungsphase abgelehnt. Dies ist ein Endstatus, der den Prozess stoppt, bevor die Bearbeitung beginnt.
Bedeutung Die Analyse abgelehnter Anfragen kann Probleme bei der Begründung von Anfragen, den Zulassungskriterien oder den Genehmigungsrichtlinien aufzeigen. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu 'Rejected'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „Abgelehnt“ wechselt. Ereignistyp inferred
	Anfrage genehmigt	Die Service-Anfrage wurde von der erforderlichen Partei formell genehmigt, wodurch der Bearbeitungsprozess fortgesetzt werden kann. Dieses Event folgt typischerweise auf den Status „Wartet auf Genehmigung“.
Bedeutung Markiert das Ende des Genehmigungs-Subprozesses und ist ein wichtiger Meilenstein, um zu verfolgen, wie lange Genehmigungen dauern und welche Auswirkungen sie auf die gesamte Lösungszeit haben. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` von 'Waiting Approval' zu einem nachfolgenden Status wie 'Planning' oder 'In Progress'. Die Genehmigungsentscheidung selbst wird in den zugehörigen Genehmigungsformularen protokolliert. Erfassen Timestamp der Statusänderung von „Wartet auf Genehmigung“ nach einer positiven Genehmigungsentscheidung. Ereignistyp inferred
	Anfrage in Prüfung	Die Service-Anfrage wird einer initialen Überprüfung und Triage durch den Service Desk unterzogen, um ihre Art, Priorität und das geeignete Bearbeitungsteam zu bestimmen. Dies wird typischerweise durch eine Statusänderung im Anfragedatensatz dargestellt.
Bedeutung Die Nachverfolgung dieser Aktivität hilft, die Triage-Effizienz zu messen und Verzögerungen zwischen Einreichung und Zuweisung zu identifizieren, was für den KPI „Durchschnittliche Triage-Zeit“ entscheidend ist. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu einem Wert wie 'In Review' oder 'Planning'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „In Prüfung“ wechselt. Ereignistyp inferred
	Anfrage wartet auf Genehmigung	Die Service-Anfrage wurde an einen bestimmten Genehmiger oder eine Genehmigungsgruppe übermittelt und wartet auf eine Entscheidung, bevor die Bearbeitung beginnen kann. Dies ist ein häufiger Schritt bei Anfragen, die Kosten oder Zugriffsrechte betreffen.
Bedeutung Diese Aktivität isoliert genehmigungsbedingte Verzögerungen und ermöglicht die Analyse der Genehmigungsdurchlaufzeiten sowie die Identifizierung von Bottlenecks in der Genehmigungskette. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu einem Wert wie 'Waiting Approval'. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request zu „Wartet auf Genehmigung“ wechselt. Ereignistyp inferred
	Anfrage wieder aufgenommen	Die Service-Anfrage wurde aus einem Status „Ausstehend“ oder „Wartend“ genommen, typischerweise nachdem die erforderlichen Informationen vom Benutzer bereitgestellt wurden. Die Arbeit an der Anfrage wird vom Bearbeitungsagenten wieder aufgenommen.
Bedeutung Markiert das Ende einer Wartezeit und ermöglicht eine präzise Messung externer Wartezeiten und deren Auswirkungen auf die SLA-Einhaltung. Datenquelle Abgeleitet, wenn der Status der `SRM:Request` von 'Pending' zurück zu 'In Progress' wechselt. Erfassen Timestamp des Update-Events, bei dem das Feld „Status“ des SRM:Request von „Ausstehend“ zu „In Bearbeitung“ wechselt. Ereignistyp inferred
	Informationen vom Benutzer angefordert	Der ausführende Agent benötigt zusätzliche Informationen vom Antragsteller, um die Arbeit fortzusetzen. Die Anfrage wird typischerweise in einen Status „Ausstehend“ versetzt.
Bedeutung Diese Aktivität ist entscheidend für die Berechnung der „Wartezeit auf externe Informationen“, identifiziert, wie oft Anfragen aufgrund unvollständiger Informationen stagnieren. Datenquelle Abgeleitet aus einer Statusänderung im Formular `SRM:Request` zu 'Pending' mit einem Statusgrund wie 'Customer Hold' oder 'Awaiting Information'. Erfassen Timestamp der Statusänderung zu „Ausstehend“ in Kombination mit einem spezifischen Statusgrund. Ereignistyp inferred
	Lösung implementiert	Die zur Bearbeitung der Service-Anfrage erforderliche technische Arbeit wurde vom Agenten abgeschlossen. Die Anfrage ist nun bereit für die Bestätigung durch den Benutzer, bevor sie formell gelöst wird.
Bedeutung Diese Aktivität trennt den technischen Abschluss von der formalen Lösung und hilft, Verzögerungen zwischen Arbeitsabschluss und Benutzerbestätigung zu identifizieren. Datenquelle Dies kann aus einer Statusänderung auf einem Backend-Bearbeitungsticket (z.B. Work Order Status zu „Abgeschlossen“) abgeleitet werden, bevor die übergeordnete SRM:Request als „Gelöst“ markiert wird. Erfassen Timestamp, wenn ein Backend-Ticket (Work Order, Incident usw.), das mit dem SRM:Request verknüpft ist, als abgeschlossen markiert wird. Ereignistyp inferred
	Lösung vom Benutzer bestätigt	Der Antragsteller hat aktiv bestätigt, dass der Service zufriedenstellend erbracht und die Anfrage gelöst wurde. Dies löst oft den endgültigen Abschluss der Anfrage aus.
Bedeutung Bietet einen klaren Indikator für die Kundenzufriedenheit und schließt die Service-Interaktion formal ab. Es trennt die Prozesslösung von der Kundenakzeptanz. Datenquelle Dieses Event könnte in den SRM:Request Arbeits-Logs oder Aktivitätsnotizen erfasst werden, wenn ein Benutzer über das Portal oder per E-Mail bestätigt. Es ist nicht immer ein diskreter Status. Erfassen Arbeits-Logs (SRM:WorkInfo) nach spezifischen Einträgen durchsuchen, die eine Benutzerbestätigung oder den Abschluss einer Umfrage anzeigen. Ereignistyp explicit

Extraktionsleitfäden

So erhalten Sie Ihre `Daten` aus BMC Helix ITSM

Schritte

Smart Reporting aufrufen: Melden Sie sich in Ihrer BMC Helix ITSM-Umgebung an. Navigieren Sie zum Berichtsabschnitt und starten Sie Smart Reporting. Je nach Version kann dies als „Reports“ oder „Smart Reporting“ bezeichnet sein.
Neuen Bericht erstellen: Wählen Sie in der Smart Reporting-Benutzeroberfläche die Option zum Erstellen eines neuen Berichts. Wählen Sie als Typ „Report“.
Datenquelle und Ansicht auswählen: Sie werden aufgefordert, eine Datenquelle auszuwählen. Wählen Sie Ihre primäre AR System-Datenquelle. Suchen und wählen Sie für die Ansicht die Service Request-Ansicht aus, die typischerweise auf dem SRM:Request-Formular basiert.
Zusätzliche Formulare hinzufügen (Joins): Um den gesamten Lebenszyklus zu erfassen, müssen Sie das Hauptformular SRM:Request mit verwandten Formularen verknüpfen. Verwenden Sie die Registerkarte „Data“ und verknüpfen Sie Folgendes:
- SRM:WorkInfo (über SR ID+ = Request Number), um Details zu Erfüllungsaktivitäten und Arbeitsprotokollen zu erhalten.
- AP:Signature (über Request = SRInstanceID), um genehmigungsbezogene Ereignisse wie Genehmigungen und Ablehnungen zu erhalten. Hierfür ist möglicherweise ein benutzerdefinierter Join erforderlich.
Berichtsspalten definieren: Ziehen Sie die erforderlichen Felder aus den verknüpften Formularen in den Bereich „Columns“. Dies umfasst Felder wie Request Number, Submit Date, Status, Description, Priority, Assigned To und Assigned Group aus SRM:Request sowie verwandte Felder aus den verknüpften Formularen.
Berechnete Felder für Aktivitäten erstellen: Der Kern dieser Methode besteht darin, eine Reihe von berechneten Feldern zu erstellen, um den Zeitstempel jeder Aktivität darzustellen. Gehen Sie zur Registerkarte „Data“ und erstellen Sie für jede Aktivität ein neues berechnetes Feld. Zum Beispiel:
- Einreichungs-Zeitstempel: Verwenden Sie direkt das Feld Submit Date.
- Genehmigungs-Zeitstempel: Verwenden Sie das Signature Date aus dem AP:Signature-Formular.
- In Bearbeitung-Zeitstempel: Verwenden Sie das MIN(Submit Date) aus SRM:WorkInfo, gruppiert nach Request Number.
Bericht für Union strukturieren: Smart Reporting verfügt nicht über eine einfache „UNION ALL“-Schaltfläche wie SQL. Um dies zu erreichen, erstellen Sie einen einzelnen Bericht und verwenden erweiterte Funktionen oder Unterabfragen, um die Daten zu pivotieren. Eine gängige Technik besteht darin, mehrere berechnete Spalten zu erstellen, eine für den Zeitstempel jeder Aktivität. Sie müssen dann den endgültigen Export formatieren, um diese Spalten in separate Zeilen für jede Aktivität umzuwandeln.
Filter anwenden: Um den Datenumfang zu begrenzen und die Leistung zu verbessern, fügen Sie Filter zu Ihrem Bericht hinzu. Filtern Sie mindestens nach Submit Date aus dem SRM:Request-Formular, um einen spezifischen Datumsbereich auszuwählen. Fügen Sie außerdem Filter für „Company“ hinzu, wenn Sie in einer Multi-Mandanten-Umgebung arbeiten.
Daten ausführen und in der Vorschau anzeigen: Führen Sie den Bericht aus, um sicherzustellen, dass die Daten korrekt abgerufen werden. Überprüfen Sie korrekte Joins, ausgefüllte Spalten und dass Ihre berechneten Felder die erwarteten Zeitstempel zurückgeben.
Bericht exportieren: Sobald der Bericht validiert ist, exportieren Sie die Daten. Wählen Sie CSV oder Microsoft Excel als Exportformat, da diese für den Import in Process Mining-Tools leicht verarbeitet werden können.
Endgültige Datentransformation: Nach dem Export müssen Sie die Daten von einem breiten Format (eine Zeile pro Serviceanfrage mit vielen Zeitstempelspalten) in ein langes Format (eine Zeile pro Aktivität) transformieren. Verwenden Sie ein Skript (z.B. Python, PowerShell) oder ein Tool wie Excel Power Query, um die Zeitstempelspalten in zwei Spalten zu entpivotieren: ActivityName und EventStartTime. Dieser Schritt ist entscheidend, um die erforderliche Ereignisprotokollstruktur zu erstellen.

Konfiguration

Voraussetzungen: Sie müssen über ein Benutzerkonto mit Berichtsrechten in BMC Helix ITSM verfügen, insbesondere über Zugriff zum Erstellen und Ausführen von Berichten in Smart Reporting. Sie benötigen außerdem Berechtigungen zum Lesen von Daten aus den Formularen SRM:Request, SRM:WorkInfo und AP:Signature.
Schlüsselformulare: Der Bericht wird durch das Verknüpfen dieser Kernformulare erstellt:
- SRM:Request: Das primäre Formular, das die Hauptdetails der Serviceanfrage enthält.
- SRM:WorkInfo: Enthält Worklog-Einträge, die zur Ableitung von Erfüllungsaktivitäten verwendet werden.
- AP:Signature: Enthält Genehmigungsdatensätze, die für die Nachverfolgung genehmigungsbezogener Aktivitäten unerlässlich sind.
Datumsbereichsfilterung: Wenden Sie immer einen Datumsbereichsfilter auf das Feld SRM:Request.Submit Date an. Ein Datenbereich von 3 bis 6 Monaten wird empfohlen, um ein repräsentatives Sample und die Berichtsleistung auszugleichen.
Wichtige Filter: Filtern Sie zusätzlich zu einem Datumsbereich nach Company, um Daten für eine spezifische Geschäftseinheit zu isolieren. Möglicherweise möchten Sie auch spezifische Anfragetypen oder Status wie 'Entwurf' herausfiltern, die für die Prozessanalyse nicht relevant sind.
Leistungsaspekte: Berichte, die mehrere Formulare über einen großen Datumsbereich verknüpfen, können langsam generiert werden. Es wird dringend empfohlen, den Bericht für große Datenmengen außerhalb der Spitzenzeiten auszuführen. Erwägen Sie, die Extraktion bei Zeitüberschreitungen in kleinere, monatliche Teile aufzuteilen.

a Beispielabfrage config

/*
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 einen Datenbank-Client (wie DBeaver, SQL Server Management Studio oder Oracle SQL Developer) und schreibgeschützte Zugangsdaten für die BMC Helix AR System-Datenbank haben.
Mit der Datenbank verbinden: Verwenden Sie Ihren Datenbank-Client, um eine Verbindung zum AR System-Datenbankserver herzustellen.
Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „Query“ dieses Dokuments in den Abfrage-Editor Ihres Datenbank-Clients.
Parameter festlegen: Suchen Sie die Platzhalterwerte innerhalb der Abfrage. Ersetzen Sie :start_date und :end_date durch den gewünschten Datumsbereich für die Extraktion, z.B. '2023-01-01' und '2023-12-31'. Ersetzen Sie :company_name durch den spezifischen Unternehmensnamen, nach dem Sie filtern möchten, falls zutreffend.
Abfrage ausführen: Führen Sie die geänderte SQL-Abfrage aus. Je nach Datumsbereich und Systemgröße kann dies mehrere Minuten dauern.
Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, wird ein Ergebnisset mit dem Ereignisprotokoll angezeigt. Überprüfen Sie die Daten kurz, um sicherzustellen, dass sie korrekt gefüllt wurden und die erwarteten Spalten und Aktivitäten enthalten.
Zeitstempel handhaben: Überprüfen Sie, ob alle Zeitstempelspalten, insbesondere EventStartTime, EventEndTime und LastDataUpdate, in einem konsistenten Format, z.B. 'JJJJ-MM-TT HH:MI:SS', formatiert sind. Wenn Ihre Datenbank sie in einem anderen Format zurückgibt, passen Sie die Funktionen TO_CHAR oder CONVERT in der Abfrage entsprechend an.
Daten exportieren: Verwenden Sie die Exportfunktion Ihres Datenbank-Clients, um das vollständige Ergebnisset als CSV-Datei zu speichern. Wählen Sie die UTF-8-Codierung, um die Kompatibilität zu gewährleisten.
Für den Upload vorbereiten: Benennen Sie die Datei entsprechend, z.B. servicerequest_eventlog.csv. Diese Datei ist nun bereit, auf die ProcessMind-Plattform hochgeladen zu werden.

Konfiguration

Datenbank-Zugangsdaten: Ein schreibgeschütztes Benutzerkonto für die AR System-Datenbank ist erforderlich. Dies verhindert unbeabsichtigte Datenänderungen und entspricht bewährten Sicherheitspraktiken.
Datumsbereichsfilterung: Die Abfrage enthält die Platzhalter :start_date und :end_date. Es ist entscheidend, einen spezifischen und angemessenen Datumsbereich festzulegen, typischerweise 3 bis 12 Monate Daten, um die Abfrageleistung und das Datenvolumen zu steuern. Die Filterung wird auf das Submit_Date der Serviceanfrage angewendet.
Unternehmensfilter: Ein Platzhalter :company_name ist enthalten, um Anfragen für ein spezifisches Betriebsunternehmen zu filtern. Wenn Sie Daten für alle Unternehmen extrahieren müssen, können Sie die Zeile AND req.Company = :company_name entfernen oder einen Wildcard verwenden, falls unterstützt.
Statuswerte: Die Abfrage verwendet Standard-Integerwerte für den BMC Helix ITSM-Status (z.B. Eingereicht = 0, In Prüfung = 1, etc.). Ihr System kann benutzerdefinierte Status oder unterschiedliche Integer-Zuordnungen haben. Überprüfen Sie diese Werte mit dem SYS:Status-Formular oder dem Developer Studio Ihres Systems und passen Sie die WHERE-Klauseln in der Abfrage bei Bedarf an.
Leistung: Direkte Datenbankabfragen auf großen Tabellen wie SRM_Request und ihren Audit-Logs können ressourcenintensiv sein. Planen Sie die Extraktion außerhalb der Spitzenzeiten, um die Auswirkungen auf die Systemleistung zu minimieren.

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 requests-Bibliothek, die für HTTP-API-Aufrufe erforderlich ist, indem Sie pip install requests in Ihrem Terminal oder Ihrer Eingabeaufforderung ausführen.
API-Zugangsdaten erhalten: Erstellen oder beschaffen Sie Zugangsdaten für ein dediziertes Dienstkonto in BMC Helix ITSM. Dieses Konto benötigt mindestens Lesezugriffsrechte für das Formular SRM:Request und das entsprechende Audit-Log-Formular, das oft SRM:Request_AuditLog oder ähnlich benannt ist. Notieren Sie sich Ihren Benutzernamen, Ihr Passwort und die Basis-URL für Ihre BMC Helix-Instanz (z.B. https://[ihr-unternehmen].bmc.com).
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, z.B. extract_servicerequests.py. Bearbeiten Sie das Skript und füllen Sie die Platzhaltervariablen oben aus: BASE_URL, USERNAME, PASSWORD und AUDIT_FORM_NAME. Passen Sie das STATUS_ACTIVITY_MAP-Wörterbuch an die spezifischen Statuswerte an, die in Ihrem Service-Anfrage-Workflow verwendet werden.
Extraktionszeitraum festlegen: Ändern Sie die Variablen START_DATE und END_DATE im Skript. Dies definiert das Zeitfenster für die Extraktion basierend auf dem Einreichungsdatum der Serviceanfrage. Verwenden Sie für erste Tests einen kleinen Datumsbereich, z.B. einen einzelnen Tag.
Skript ausführen: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl python extract_servicerequests.py aus. Das Skript wird sich zuerst mit der API authentifizieren, um einen Token zu erhalten.
Erster Datenabruf: Das Skript fragt das SRM:Request-Formular ab, um eine Liste aller Serviceanfragen abzurufen, die innerhalb des angegebenen Datumsbereichs erstellt wurden. Dieser Schritt sammelt die Fall-ID und zugehörige statische Attribute wie Priorität und Servicetyp.
Ereignishistorie abrufen: Das Skript durchläuft jede in den vorherigen Schritten erhaltene Service-Anfrage-ID. Für jede ID führt es einen zweiten API-Aufruf an das konfigurierte Audit-Log-Formular durch, um die detaillierte Historie der Statusänderungen für diese spezifische Anfrage abzurufen.
Daten in Ereignisprotokoll transformieren: Für jeden Datensatz aus dem Audit-Log ordnet das Skript die Statusänderung einem Standard-Aktivitätsnamen mithilfe der STATUS_ACTIVITY_MAP zu. Es erstellt eine Zeile für jede zugeordnete Aktivität, einschließlich der Service-Anfrage-ID, des Aktivitätsnamens und des Zeitstempels der Änderung.
Ereignis 'Eingereicht' generieren: Das Skript erstellt auch die anfängliche Aktivität 'Service Request Submitted' für jede Anfrage, indem es das Submit Date aus dem Hauptformular SRM:Request verwendet.
In CSV exportieren: Nach der Verarbeitung aller Serviceanfragen und ihrer Historien konsolidiert das Skript die generierten Zeilen in einer einzigen Liste und schreibt die Daten in eine CSV-Datei namens servicerequest_event_log.csv. Diese Datei ist formatiert und bereit für den Upload in ein Process Mining-Tool.

Konfiguration

API-Endpunkte: Das Skript verwendet hauptsächlich zwei API-Endpunkte. Die Authentifizierung erfolgt über api/jwt/login. Daten werden von arsys/v1/entry/SRM:Request für die Liste der Fälle und von arsys/v1/entry/[AUDIT_FORM_NAME] für die Ereignishistorie abgefragt.
Dienstkontoberechtigungen: Ein dediziertes Dienstkonto mit Lesezugriff auf das SRM:Request-Formular und das Audit-Log-Formular des Systems ist erforderlich. Die Verwendung eines Dienstkontos ist entscheidend für Sicherheit und Nachvollziehbarkeit.
Datumsbereichsfilterung: Das Skript ist so konfiguriert, dass es Serviceanfragen basierend auf ihrem Submit Date filtert. Es wird empfohlen, Daten in überschaubaren Batches, z.B. 3-6 Monate auf einmal, zu extrahieren, um eine zuverlässige Leistung zu gewährleisten.
Status-zu-Aktivitäts-Zuordnung: Das STATUS_ACTIVITY_MAP-Wörterbuch im Skript ist der Kern der Transformationslogik. Es muss sorgfältig konfiguriert werden, um die benutzerdefinierten Status Ihrer Organisation widerzuspiegeln und sie den gewünschten Aktivitätsnamen zuzuordnen. Jeder Status in Ihrem Workflow, der nicht in der Zuordnung vorhanden ist, wird ignoriert.
Audit-Log-Formular: Die Fähigkeit des Skripts, detaillierte Aktivitäten zu erfassen, hängt vollständig von einem abfragbaren Audit-Log ab. Sie müssen den korrekten Formularnamen in Ihrer Umgebung identifizieren, der die Statusänderungshistorie für Serviceanfragen speichert, und die Variable AUDIT_FORM_NAME entsprechend aktualisieren.
Paginierung: Das Skript handhabt die API-Paginierung automatisch, um alle Datensätze abzurufen. Der limit-Parameter im API-Aufruf ist so eingestellt, dass 1000 Datensätze pro Anfrage abgerufen werden, um Leistung und Speichernutzung auszugleichen.

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

Ihre Service Request Management Daten-Template

Ihre Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsleitfäden

BMC Helix ITSM Smart Reporting für Serviceanfragen

Schritte

Konfiguration

a Beispielabfrage config

Direkte SQL-Abfrage auf AR System-Datenbanktabellen

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript-Extraktion über die BMC Helix REST API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Effizienz entfesseln: Service Request Management noch heute optimieren

Ihre Service Request Management Daten-Template

Ihre Service Request Management Daten-Template

Attribute im Service Request Management

Aktivitäten im Service Request Management

Extraktionsleitfäden

BMC Helix ITSM Smart Reporting für Serviceanfragen

Schritte

Konfiguration

a Beispielabfrage config

Direkte SQL-Abfrage auf AR System-Datenbanktabellen

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript-Extraktion über die BMC Helix REST API

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Effizienz entfesseln: Service Request Management noch heute optimieren