Ihr Daten-Template für Problem Management
Ihr Daten-Template für Problem Management
- Wichtige Datenfelder für die Ursachenanalyse
- Einheitliche Prozessmeilensteine für die Nachverfolgung
- Konkrete Hinweise zur Datenextraktion aus BMC Helix ITSM
Attribute für Problem Management
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Die konkrete Task oder Statusänderung, die stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut bezeichnet den konkreten Schritt im Ablauf des Problem Managements, etwa „Problem Record erfasst“, „Ursache identifiziert“ oder „Lösungsdatenbank aktualisiert“. In BMC Helix werden diese Angaben häufig aus dem Statusverlauf, den Audit-Protokollen oder den Zeitstempeln einzelner Transaktionen im Modul Problem Investigation abgeleitet. Dieses Attribut bildet die Grundlage für die Prozesserkennung. Anhand der Abfolge dieser Aktivitäten erstellt das Process-Mining-Tool eine Prozessübersicht, die den tatsächlichen Arbeitsablauf mit dem geplanten Prozess vergleicht. Dabei werden Schleifen, Nacharbeit und Abweichungen von der Standardvorgehensweise sichtbar. Präzise Aktivitätsnamen sind entscheidend, um nachvollziehen zu können, was im Prozess tatsächlich geschehen ist. Mit diesen Daten lassen sich die Übergangszeiten zwischen einzelnen Schritten messen, zum Beispiel die Zeit zwischen der Identifizierung einer Ursache und dem Start eines Änderungsantrags.
Warum das wichtig ist
Das Attribut legt die Knoten in der Prozessübersicht fest und ermöglicht die Visualisierung des Workflows.
Woher beziehen
Abgeleitet aus dem Statusverlauf von PBM:Problem Investigation oder PBM:AuditLogSystem
Beispiele
Problem Record erfasstSupportgruppe zugewiesenUntersuchung begonnenUrsache identifiziert
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, zu dem die jeweilige Aktivität stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut erfasst das genaue Datum und die Uhrzeit einer Aktivität. In BMC Helix ITSM entspricht es Feldern wie „Submit Date“ und „Last Modified Date“ oder den Zeitstempeln in Verlaufstabellen, die Statusänderungen dokumentieren. Bei der Analyse dient das Attribut dazu, Ereignisse chronologisch zu ordnen und Zeitspannen zu berechnen. Damit lassen sich Zykluszeiten zwischen beliebigen Prozessschritten messen, etwa die „Investigation Cycle Time“ oder die „Workaround Publication Lead Time“. Präzise Zeitstempel sind wichtig, um Engpässe zu erkennen. Durch die Berechnung der Zeit zwischen aufeinanderfolgenden Ereignissen können Analysten genau feststellen, wo Verzögerungen auftreten, sei es bei der anfänglichen Zuweisung oder in der abschließenden Prüfphase.
Warum das wichtig ist
Ermöglicht die Berechnung aller zeitbasierten KPIs und die chronologische Anordnung der Ereignisse.
Woher beziehen
Verlaufstabellen oder Audit-Protokolle zu PBM:Problem Investigation
Beispiele
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
Problem Record
ProblemRecord
|
Die eindeutige Kennung des Problem Investigation Case. | ||
|
Beschreibung
Dieses Attribut dient als zentrale Case-Kennung für den Problem-Management-Prozess. In BMC Helix ITSM ist dies üblicherweise das Feld „Problem ID“ im Formular PBM:Problem Investigation, zum Beispiel PBI00000012345. Es verknüpft alle zugehörigen Aktivitäten, von der ersten Erfassung des Problems bis zum endgültigen Abschluss und der Überprüfung nach der Umsetzung. Bei der Process-Mining-Analyse werden einzelne Ereignisse anhand dieses Attributs zu einer Prozessinstanz zusammengefasst. So können Analysten den gesamten Ablauf einer bestimmten Problem Investigation visualisieren. Ohne diese Kennung ließen sich die aufeinanderfolgenden Aktionen verschiedener Supportgruppen und Koordinatoren nicht miteinander verknüpfen. Dieses Feld ist der Primärschlüssel des Event Log und für alle Aggregationen auf Case-Ebene erforderlich, etwa zur Berechnung der gesamten Zykluszeit pro Problem oder zur Zählung der Probleme je Prioritätsstufe.
Warum das wichtig ist
Diese grundlegende Kennung ist erforderlich, um die Prozessansicht zu erstellen und den Ablauf einzelner Probleme nachzuverfolgen.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Problem ID“
Beispiele
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der Datenextraktion oder der letzten Aktualisierung. | ||
|
Beschreibung
Dieses Attribut gibt an, wann die Daten zuletzt in die Process-Mining-Anwendung geladen wurden. So wissen Analysten, wie aktuell die angezeigten Daten sind. Der Wert wird üblicherweise vom Extraktionsskript oder der Datenpipeline erzeugt. Bei der Analyse hilft dies, Entscheidungen auf Grundlage veralteter Daten zu vermeiden. Betrachtet eine Führungskraft beispielsweise offene Problem Records, macht es für die Einschätzung der aktuellen Arbeitslast einen erheblichen Unterschied, ob die Daten vor einer Stunde oder vor einer Woche aktualisiert wurden. Das Attribut wird auch für inkrementelle Datenladungen verwendet. Anhand des Zeitpunkts der letzten Aktualisierung kann der ETL-Prozess nur Records abrufen, die sich seit der vorherigen Extraktion geändert haben. Das verbessert die Leistung und verringert die Systemlast.
Warum das wichtig ist
Sichert die Aktualität der Daten und unterstützt Strategien für inkrementelle Datenladungen.
Woher beziehen
Systemzeit zum Zeitpunkt der Extraktion
Beispiele
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten stammen. | ||
|
Beschreibung
Dieses Attribut bezeichnet das Softwaresystem, aus dem die Prozessdaten extrahiert wurden, in diesem Fall „BMC Helix ITSM“. Es ist besonders wichtig in Umgebungen mit mehreren Systemen, in denen Process Mining Daten aus verschiedenen ITSM-, Entwicklungs- oder externen Anbietersystemen zusammenführt. Bei der Analyse dient dieses Feld als Metadatenkennzeichnung zur Überprüfung der Herkunft eines Records. Führt die Process-Mining-Ansicht Daten aus BMC Helix für das Problem Management und aus einem separaten System für die Softwareentwicklung zusammen, zum Beispiel Jira, können Sie die Analyse nach dem Ursprungssystem aufschlüsseln. Das Attribut unterstützt auch die technische Fehlerbehebung. Treten Probleme mit der Datenqualität auf, können Datentechniker anhand des Quellsystems die Ursache bis zur jeweiligen Extraktionsroutine oder Quelldatenbank zurückverfolgen.
Warum das wichtig ist
Sorgt für Rückverfolgbarkeit und Kontext, besonders bei Prozessansichten über mehrere Systeme hinweg.
Woher beziehen
Während der Extraktion fest vorgegeben
Beispiele
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Anzahl verknüpfter Incidents
RelatedIncidentCount
|
Anzahl der Incidents, die mit diesem Problem-Datensatz verknüpft sind. | ||
|
Beschreibung
Dieses Attribut beziffert die Auswirkungen des Problems anhand der Anzahl der damit verknüpften Incidents. In BMC Helix entspricht dies üblicherweise der Anzahl der Datensätze im Formular HPD:Help Desk, die mit dem PBM-Datensatz verknüpft sind. Dieses Attribut fließt in die KPI „Dichte der Incident-Verknüpfungen“ ein. Ein hoher Wert weist auf ein Problem mit großen Auswirkungen hin, das den Service Desk stark belastet. Im Abgleich mit der „Priorität“ lässt sich prüfen, ob Probleme mit vielen Incidents tatsächlich als kritisch behandelt werden. Auch bei der Priorisierung des Rückstands hilft diese Kennzahl. Ein Problem-Datensatz mit 500 verknüpften Incidents sollte wahrscheinlich Vorrang vor einem „kritischen“ Problem mit nur einem verknüpften Incident haben, denn seine Lösung schafft mehr Kapazität im Service Desk.
Warum das wichtig ist
Beziffert die betrieblichen Auswirkungen des Problems und die Belastung der Benutzer.
Woher beziehen
Berechnet durch Zählen der zugehörigen Zeilen in HPD:Associations oder HPD:Help Desk
Beispiele
15120
|
|||
|
Auslöser der Untersuchung
InvestigationDriver
|
Der Grund für den Start der Problem Investigation. | ||
|
Beschreibung
Dieses Attribut klassifiziert den Auslöser des Problem Records, zum Beispiel „Incident Volume“, „Major Incident“, „Vendor Notification“ oder „Proactive Trend Analysis“. In BMC Helix entspricht es dem Feld „Investigation Driver“. Das Attribut unterstützt das Dashboard „Proactive Identification Trends“. Unternehmen können damit nachvollziehen, ob sie von einer reaktiven Störungsbehebung, also der Reaktion auf Vorfälle, zu einem vorausschauenden Problem Management übergehen, bei dem Risiken erkannt werden, bevor sie sich auswirken. Die Analyse von Prozessabläufen nach „Investigation Driver“ kann unterschiedliche Muster sichtbar machen. Proaktiv erkannte Probleme bleiben möglicherweise länger in der Warteschlange, weil sie keine unmittelbaren Ausfälle verursachen. Probleme, die durch einen „Major Incident“ ausgelöst wurden, werden dagegen oft schneller bearbeitet.
Warum das wichtig ist
Unterscheidet zwischen reaktiver und proaktiver Arbeit, einem wichtigen Indikator für den Reifegrad.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Investigation Driver“
Beispiele
ReaktivProaktivWiederkehrende Incidents
|
|||
|
Priorität
Priority
|
Die anhand von Auswirkungen und Dringlichkeit berechnete Priorität des Problems. | ||
|
Beschreibung
Dieses Attribut gibt die Prioritätsstufe des Problem Records an, zum Beispiel „Kritisch“, „Hoch“, „Mittel“ oder „Niedrig“. In BMC Helix wird sie üblicherweise anhand der Angaben zu Auswirkungen und Dringlichkeit berechnet. Bei der Analyse wird das Attribut im Dashboard „Throughput and Priority Volume“ verwendet. Unternehmen können damit prüfen, ob die Ressourcen entsprechend den geschäftlichen Anforderungen eingesetzt werden. Bei Problemen mit kritischer Priorität sollten die erste Zuweisung und die gesamte Zykluszeit beispielsweise kürzer ausfallen als bei Problemen mit niedriger Priorität. Wenn Sie nach Priorität filtern, können Sie Verbesserungsmaßnahmen gezielt ausrichten. Ein Engpass in einem Prozess mit niedriger Priorität ist möglicherweise vertretbar. Dieselbe Verzögerung bei einem kritischen Prozess stellt hingegen ein erhebliches Risiko für die Geschäftskontinuität und die Einhaltung von SLAs dar.
Warum das wichtig ist
Gliedert die Analyse nach geschäftlicher Kritikalität und unterstützt die SLA-Analyse.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Priority“
Beispiele
KritischHochMittelNiedrig
|
|||
|
Problemkoordinator
ProblemCoordinator
|
Die Person, die mit der Koordination der Untersuchung betraut ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Person, die für den Problem Record zuständig ist. In BMC Helix ITSM entspricht es dem Feld „Problem Coordinator“. Diese Person verantwortet den Ablauf des Problems, auch wenn einzelne Tasks an andere delegiert werden. Das Attribut unterstützt das Dashboard „Support Group Workload Distribution“. Führungskräfte können damit erkennen, ob einzelne Personen mit Untersuchungen überlastet sind, während andere noch Kapazitäten haben. Außerdem ermöglicht es Leistungsanalysen auf individueller Ebene, um Schulungsbedarf oder besonders leistungsstarke Mitarbeitende zu erkennen. Beim Process Mining dient dieses Feld als Ressourcenattribut. Es macht sichtbar, wie die Arbeit zwischen einzelnen Personen weitergegeben wird, und kann kritische Abhängigkeiten aufzeigen, wenn ein Prozess zu stark auf eine bestimmte Fachkraft angewiesen ist.
Warum das wichtig ist
Ermöglicht die Ressourcenanalyse und den Ausgleich der Arbeitslast auf individueller Ebene.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Problem Coordinator“
Beispiele
Max MustermannErika MustermannSystemadministration
|
|||
|
Service-CI
ServiceCI
|
Der betroffene geschäftliche Service oder das betroffene Konfigurationselement. | ||
|
Beschreibung
Dieses Attribut bezeichnet das Service Configuration Item (CI), das mit dem Problem verknüpft ist, zum Beispiel „E-Mail-Service“, „SAP ERP“ oder „WLAN“. In BMC Helix entspricht es häufig dem Feld „Service+“ oder der primären CI-Beziehung. Bei der Analyse lassen sich Problem Records nach Produkt oder Service aufschlüsseln. So kann die IT-Leitung erkennen, welche Services besonders störanfällig sind und die meisten Problem Investigations verursachen. Als zusätzliche Produktdimension fließt das Attribut in das Dashboard „Throughput and Priority Volume“ ein. Wird dieses Attribut mit der „Investigation Cycle Time“ verglichen, zeigt sich, ob komplexe Services wie ein Kernbankensystem grundsätzlich längere Untersuchungen erfordern als Standardservices wie Drucken.
Warum das wichtig ist
Verknüpft die Prozessleistung mit bestimmten Produkten oder Services des Unternehmens.
Woher beziehen
Formular PBM:Problem Investigation, Feld „ServiceCI“ oder „CI Name“
Beispiele
E-Mail-ServiceGehaltsabrechnungssystemUnternehmens-VPN
|
|||
|
SLA überschritten?
IsSLABreached
|
Kennzeichen dafür, ob die Problemlösung die zulässige Zeit überschritten hat. | ||
|
Beschreibung
Dieses boolesche Attribut gibt an, ob der Problem-Datensatz gegen die Service Level Agreement verstoßen hat. Es wird berechnet, indem der Timestamp der Aktivität „Lösung bestätigt“ mit dem „SLA-Fälligkeitsdatum“ verglichen wird. Alternativ kann der Wert direkt aus dem SLM-Status übernommen werden. Dieses Attribut ist entscheidend für das Dashboard „SLA-Einhaltung und Überschreitungen im Zeitverlauf“. Es ermöglicht eine einfache Einteilung des Prozesses in SLA-konforme und nicht SLA-konforme Fälle. So lassen sich die Merkmale fehlgeschlagener Prozesse leicht untersuchen, etwa mit der Frage: „Sind bei SLA-Überschreitungen immer Fälle der Supportgruppe X betroffen?“ Das Attribut dient als wichtiger Filter für die Ursachenanalyse von Prozessfehlern. Analysten können nach „IsSLABreached = True“ filtern und anschließend in der Prozesslandkarte prüfen, an welcher Stelle Zeit verloren ging, zum Beispiel durch lange Wartezeiten auf die Freigabe eines Anbieters.
Warum das wichtig ist
Vereinfacht die Compliance-Berichterstattung und die Analyse von Fehlern.
Woher beziehen
SLM: Formular „Measurement“ oder berechneter Wert
Beispiele
truefalse
|
|||
|
SLA-Fälligkeitsdatum
SLADueDate
|
Datum und Uhrzeit, bis zu denen das Problem gelöst sein muss. | ||
|
Beschreibung
Dieses Attribut enthält die Frist für die Problemlösung gemäß der Service Level Agreement. In BMC Helix ist dies häufig das „Zieldatum für die Lösung“ oder der Timestamp eines berechneten SLA-Meilensteins. Dieses Attribut bildet die Grundlage für das Dashboard „SLA-Einhaltung und Überschreitungen im Zeitverlauf“. Durch den Vergleich dieses Timestamps mit dem Timestamp der Aktivität „Lösung bestätigt“ berechnet das System, ob die SLA eingehalten oder überschritten wurde. Anhand der Visualisierung dieses Datums erkennen Analysten, wie knapp das Team die Frist einhält. Werden Probleme Tage im Voraus gelöst oder regelmäßig erst wenige Minuten vor einer SLA-Überschreitung? Diese Erkenntnisse unterstützen die Kapazitätsplanung.
Warum das wichtig ist
Dient als Referenz für die Berechnung aller Kennzahlen zur Compliance und Termintreue.
Woher beziehen
PBM: Formular „Problem Investigation“, Feld „Target Resolution Date“
Beispiele
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Supportgruppe
SupportGroup
|
Das technische Team, dem die Problem Investigation derzeit zugewiesen ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Supportgruppe, zum Beispiel „Serveradministration“ oder „Datenbanksupport“, die zum Zeitpunkt des Ereignisses für den Problem Record zuständig ist. In BMC Helix entspricht es dem Feld „Assigned Group“. Das Attribut ist wichtig für die Dashboards „Support Group Workload Distribution“ und „Support Group Reassignment Analysis“. Analysten können die Prozessübersicht nach Team aufschlüsseln und sehen, welche Gruppen die meisten Fälle bearbeiten und wo im Untersuchungsprozess Engpässe entstehen. Die Analyse von Übergaben zwischen Supportgruppen hilft, wiederholte Weiterleitungen zu erkennen, bei denen ein Ticket ohne Lösung zwischen Teams hin- und hergeschoben wird. Das deutet häufig auf unklare Zuständigkeiten oder unzureichendes Wissensmanagement im Unternehmen hin.
Warum das wichtig ist
Ermöglicht die Analyse der Organisation und das Erkennen von Engpässen auf Teamebene.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Assigned Group“
Beispiele
Service Desk Ebene 1Backoffice-SupportNetzwerkadministration
|
|||
|
Ursachenkategorie
RootCauseCategory
|
Die Klassifizierung der zugrunde liegenden Ursache des Problems. | ||
|
Beschreibung
Dieses Attribut enthält die ausgewählte Kategorie, sobald die Ursache identifiziert wurde, zum Beispiel „Softwarefehler“, „Hardwareausfall“ oder „Prozesslücke“. In BMC Helix wird sie üblicherweise in den Menüs „Root Cause“ oder „Generic Categorization“ ausgewählt. Das Attribut ist wichtig für die Ansicht „Fix Effectiveness and Quality“. Unternehmen können damit bestimmte Ursachenarten mit Nacharbeitsquoten oder langen Untersuchungszeiten in Verbindung bringen. So lässt sich beispielsweise feststellen, ob Probleme aufgrund von Softwarefehlern durchgehend doppelt so lange bis zur Lösung benötigen wie Probleme aufgrund von Hardwareausfällen. Das Attribut dient auch zur Berechnung der „Root Cause Categorization Rate“. Ein hoher Anteil der Werte „Unknown“ oder „Other“ weist auf möglichen Bedarf an besserer technischer Schulung oder differenzierteren Kategorisierungsoptionen hin.
Warum das wichtig ist
Ermöglicht die Trendanalyse systemischer Probleme und unterstützt ein vorausschauendes Problem Management.
Woher beziehen
Formular PBM:Problem Investigation, Felder „Root Cause“ oder der Kategorisierungsregisterkarte
Beispiele
SoftwaremodulNetzwerkinfrastrukturMenschlicher Fehler
|
|||
|
Anzahl der Neuzuweisungen
ReassignmentCount
|
Gesamtzahl der Änderungen der Supportgruppe. | ||
|
Beschreibung
Dieses Attribut zählt, wie oft die Aktivität „Supportgruppe zugewiesen“ für einen einzelnen Case auftritt. Es misst direkt Reibungsverluste im Prozess und die Effizienz der Weiterleitung. Dieses Attribut fließt in das Chart „Analyse der Neuzuweisungen von Supportgruppen“ ein. Hohe Werte, also häufiges Hin- und Herschieben, deuten darauf hin, dass die erste Triage nicht funktioniert oder bei komplexen Problemen klare Zuständigkeiten fehlen. Das ist ein Frühindikator für längere Zykluszeiten. Führungskräfte nutzen diese Kennzahl, um Schulungsbedarf zu erkennen. Weist der Service Desk Probleme mit „Database“ regelmäßig zuerst der Gruppe „Network“ zu und leitet „Network“ sie anschließend an „Database“ weiter, steigt die Anzahl der Neuzuweisungen deutlich. Das macht den Bedarf an besseren Skripten für die Erstdiagnose sichtbar.
Warum das wichtig ist
Macht Verschwendung, Reibungsverluste und fehlende Zuständigkeiten im Prozess sichtbar.
Woher beziehen
Aus dem Aktivitätsverlauf berechnet
Beispiele
015
|
|||
|
ID des verknüpften Änderungsantrags
RelatedChangeRequestId
|
Kennung des Änderungsantrags, der zur Behebung des Problems eingeleitet wurde. | ||
|
Beschreibung
Dieses Attribut enthält die ID des mit dem Problem-Datensatz verknüpften Änderungsantrags, zum Beispiel CRQ0000.... Es kennzeichnet den Übergang von der Untersuchung zur Umsetzung einer dauerhaften Lösung. Dieses Attribut wird für die KPI „Durchlaufzeit von der Ursachenanalyse bis zur Änderung“ benötigt. Damit kann das Process-Mining-Tool die Verzögerung zwischen dem Ermitteln der Ursache und dem Start des Änderungsprozesses messen. An dieser häufigen Übergabestelle geht oft Zeit verloren. Außerdem lässt sich damit die „Vollständigkeit des Prozesses“ prüfen. Wird ein Problem-Datensatz mit dem Status „Abgeschlossen“ geschlossen, ohne dass ein Änderungsantrag oder eine Behelfslösung verknüpft ist, kann dies auf einen Prozessverstoß hindeuten: Die Ursache wurde zwar gefunden, aber nie tatsächlich behoben.
Warum das wichtig ist
Verknüpft den Problemmanagementprozess mit dem Änderungsmanagementprozess.
Woher beziehen
PBM: Registerkarte „Investigation Associations“ oder „Relationship“
Beispiele
CRQ00000021345CRQ00000021346
|
|||
|
Region
Region
|
Die geografische Region, die dem Problem zugeordnet ist. | ||
|
Beschreibung
Dieses Attribut gibt den geografischen Ort an, an dem das Problem aufgetreten ist oder bearbeitet wird, zum Beispiel „Nordamerika“ oder „EMEA“. In BMC Helix finden Sie diese Angabe häufig in den Feldern „Region“ oder „Standort“, die dem Anfordernden oder dem betroffenen Asset zugeordnet sind. Bei der Analyse ermöglicht dieses Attribut eine geografische Segmentierung. So lässt sich feststellen, ob in bestimmten Regionen mehr Probleme auftreten oder die Lösungszeiten länger sind. Dadurch werden mögliche Unterschiede bei der Support-Besetzung oder der Infrastrukturqualität an verschiedenen Standorten sichtbar. Für global tätige Unternehmen ist das wichtig, um eine einheitliche Servicebereitstellung sicherzustellen. Ist die „Untersuchungszykluszeit“ in „APAC“ doppelt so lang wie in „NAM“, sollte geprüft werden, ob Ressourcen in dieser Region angemessen verteilt werden und die Prozesse eingehalten werden.
Warum das wichtig ist
Ermöglicht den geografischen Vergleich der Prozessleistung.
Woher beziehen
PBM: Formular „Problem Investigation“, Feld „Region“
Beispiele
AmerikaEMEAAPAC
|
|||
|
Status der Behelfslösung
WorkaroundStatus
|
Gibt an, ob eine gültige Behelfslösung gefunden und veröffentlicht wurde. | ||
|
Beschreibung
Dieses Attribut erfasst den Status der vorübergehenden Lösung (Behelfslösung). Es kann als einfacher Wahrheitswert (Behelfslösung vorhanden) oder als Statusangabe gespeichert sein. In BMC Helix wird der Status häufig aus einem Eintrag im Feld „Workaround“ oder einem bestimmten Statuskennzeichen abgeleitet. Dieses Attribut ist entscheidend für das Dashboard „Leistung bei der Veröffentlichung von Behelfslösungen“. Es zeigt, wie wirksam das Team die Auswirkungen begrenzt, während es nach der Ursache sucht. Eine Prozessansicht mit dem Filter „Keine Behelfslösung“ macht Fälle sichtbar, in denen das Unternehmen während der Untersuchung den vollen Auswirkungen ausgesetzt ist. Das Attribut unterstützt auch Qualitätsprüfungen. Wird ein Problem-Datensatz ohne dauerhafte Lösung (Änderungsantrag) UND ohne Behelfslösung geschlossen, deutet dies in der Regel auf einen Prozessfehler hin, der überprüft werden sollte.
Warum das wichtig ist
Misst, wie wirksam die Auswirkungen während der Untersuchung begrenzt werden.
Woher beziehen
PBM: Formular „Problem Investigation“, Prüfung des Feldinhalts „Workaround“
Beispiele
AktivKeineAusgemustert
|
|||
|
Untersuchungszykluszeit
InvestigationCycleTime
|
Dauer vom Beginn der Untersuchung bis zur Ermittlung der Ursache. | ||
|
Beschreibung
Dieses berechnete Dauerattribut misst die Zeit zwischen den Aktivitäten „Untersuchung begonnen“ und „Ursache ermittelt“. Es bildet die zentrale wertschöpfende Zeit im Problemmanagementprozess ab. Diese Kennzahl fließt in das Dashboard „Zykluszeit der Ursachenuntersuchung“ ein. Sie hilft Führungskräften, die technische Komplexität von Problemen und die Effizienz der Untersuchungsteams einzuschätzen. Auffälligkeiten, etwa extrem kurze Zeiten, können auf bloße Vermutungen hindeuten. Sehr lange Zeiten weisen dagegen auf ins Stocken geratene Untersuchungen hin. Durch den Vergleich dieser Kennzahl nach „Supportgruppen“ und „Prioritäten“ kann das Unternehmen feststellen, welche Teams bessere Werkzeuge, Schulungen oder Unterstützung durch Anbieter benötigen, um Probleme schneller zu diagnostizieren.
Warum das wichtig ist
Die zentrale Effizienzkennzahl für die technische Untersuchungsphase.
Woher beziehen
Aus den Aktivitäts-Timestamps berechnet
Beispiele
4500000120000
|
|||
Aktivitäten im Problem Management
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Änderungsantrag gestartet
|
Ein Infrastructure Change Request wird mit der Problem Investigation verknüpft. Damit beginnt die Umsetzungsphase. | ||
|
Warum das wichtig ist
Wichtig für die KPI „Root Cause to Change Lead Time“ und zum Erkennen von Silos zwischen Problem- und Change-Prozessen.
Woher beziehen
Tabelle PBM:Investigation_Associations oder Befüllung des Felds „Infrastructure Change ID“.
Erfassung
Erfasst, wenn eine Verknüpfung in PBM:Investigation_Associations erstellt wird
Ereignistyp
explicit
|
|||
|
Lösung überprüft
|
Die dauerhafte Lösung wird als erfolgreich bestätigt. Dies wird abgeleitet, wenn sich der Status zu „Solution Implemented“ oder „Completed“ ändert. | ||
|
Warum das wichtig ist
Wird für die „Problem SLA Adherence Rate“ verwendet und bestätigt den Abschluss der technischen Arbeit.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Solution Implemented“ oder „Completed“.
Erfassung
Statusfeld auf den Wechsel zu „Solution Implemented“ prüfen
Ereignistyp
inferred
|
|||
|
Problem Record abgebrochen
|
Ein Problem Record wird vor der Lösung beendet. Erfasst, wenn der Status zu „Cancelled“ oder „Rejected“ wechselt. | ||
|
Warum das wichtig ist
Hilft, unnötigen Aufwand oder berechtigte Duplikate zu erkennen. Stellt einen alternativen Endpunkt dar.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Cancelled“ oder „Rejected“.
Erfassung
Statusfeld auf den Wechsel zu „Cancelled“ prüfen
Ereignistyp
inferred
|
|||
|
Problem Record erfasst
|
Ein Problem Investigation Record wird erstmals im System angelegt. Dieses Ereignis wird ausdrücklich erfasst, wenn ein neuer Eintrag im Formular PBM:Problem Investigation gespeichert wird. | ||
|
Warum das wichtig ist
Kennzeichnet den Beginn der Prozessinstanz. Wichtig für die Berechnung der gesamten Zykluszeit und der Kennzahlen zur ersten Reaktion.
Woher beziehen
Formular PBM:Problem Investigation, Timestamp „Submit Date“ oder Erstellungsprotokoll mit „Status“ = „Draft“.
Erfassung
Erfasst, wenn ein PBM:Problem Investigation Record erstellt wird
Ereignistyp
explicit
|
|||
|
Problem Record geschlossen
|
Der Problem Record wird abschließend administrativ geschlossen. Dieses Ereignis beendet die Prozessinstanz. | ||
|
Warum das wichtig ist
Das reguläre Endereignis. Erforderlich für die vollständige Analyse der Zykluszeit und die Berechnung der „Incident Linkage Density“.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Closed“.
Erfassung
Statusfeld auf den Wechsel zu „Closed“ prüfen
Ereignistyp
inferred
|
|||
|
Supportgruppe zugewiesen
|
Der Problem Record wird einem bestimmten technischen Team zugewiesen. Erfasst durch die Überwachung von Änderungen am Feld „Assigned Group“. | ||
|
Warum das wichtig ist
Wichtig für die Messung von Übergaben, wiederholten Weiterleitungen und der KPI „Mean Time to Initial Assignment“.
Woher beziehen
Formular PBM:Problem Investigation, Änderungsverlauf oder Audit-Protokoll des Felds „Assigned Group“.
Erfassung
Feld „Assigned Group“ vor und nach der Aktualisierung vergleichen
Ereignistyp
inferred
|
|||
|
Untersuchung begonnen
|
Der Problem Record wechselt in eine aktive Analysephase. Dies wird abgeleitet, wenn sich das Feld „Status“ zu „Under Investigation“ ändert. | ||
|
Warum das wichtig ist
Kennzeichnet den Beginn der eigentlichen Arbeit und unterstützt die KPI „Investigation Cycle Time“.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Under Investigation“.
Erfassung
Statusfeld auf den Wechsel zu „Under Investigation“ prüfen
Ereignistyp
inferred
|
|||
|
Ursache identifiziert
|
Der Problem Record wechselt in einen Status, der anzeigt, dass die Ursache bekannt ist. Dies wird abgeleitet, wenn sich der Status zu „Root Cause Identified“ ändert. | ||
|
Warum das wichtig ist
Ein wichtiger Meilenstein für das Dashboard „Root Cause Investigation Cycle Time“. Er kennzeichnet den Übergang von der Analyse zur Lösungsfindung.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Root Cause Identified“.
Erfassung
Statusfeld auf den Wechsel zu „Root Cause Identified“ prüfen
Ereignistyp
inferred
|
|||
|
Workaround definiert
|
Im Feld „Workaround“ des Problem Records wird Text eingetragen oder aktualisiert. Dieses Ereignis zeigt an, dass eine vorläufige Lösung dokumentiert wurde. | ||
|
Warum das wichtig ist
Unterstützt die KPI „Workaround Publication Lead Time“ und zeigt, dass Maßnahmen zur Begrenzung der Auswirkungen eines Vorfalls ergriffen wurden.
Woher beziehen
Formular PBM:Problem Investigation, Änderungen am Textfeld „Workaround“.
Erfassung
Inhalt des Felds „Workaround“ auf Aktualisierungen mit einem Wert prüfen
Ereignistyp
inferred
|
|||
|
Known Error angelegt
|
Ein mit der Problem Investigation verknüpfter Known Error Record wird erstellt. Dieses Ereignis erfasst die Erstellung eines zugehörigen Records. | ||
|
Warum das wichtig ist
Zeigt, dass das Problem für die weitere Kommunikation und langfristige Nachverfolgung formal dokumentiert wurde.
Woher beziehen
Erstellung eines Records in PBM:Known Error, verknüpft mit der PBM:Problem Investigation ID.
Erfassung
Erfasst, wenn ein PBM:Known Error Record erstellt wird
Ereignistyp
explicit
|
|||
|
Koordination neu zugewiesen
|
Die für ein Problem zuständige Person innerhalb einer Supportgruppe ändert sich. Erfasst durch die Überwachung des Felds „Problem Coordinator“. | ||
|
Warum das wichtig ist
Unterstützt die Analyse der Arbeitsverteilung und individueller Engpässe bei den verfügbaren Ressourcen.
Woher beziehen
Formular PBM:Problem Investigation, Änderungsverlauf des Felds „Problem Coordinator“.
Erfassung
Feld „Problem Coordinator“ vor und nach der Aktualisierung vergleichen
Ereignistyp
inferred
|
|||
|
Lösungsdatenbank aktualisiert
|
Der Record wechselt in den Status „Solution Database“. Das zeigt an, dass eine dauerhafte Lösung vorgeschlagen oder identifiziert wurde. | ||
|
Warum das wichtig ist
Verfolgt den Fortschritt bei der Ausarbeitung einer Lösung vor ihrer Umsetzung.
Woher beziehen
Formular PBM:Problem Investigation, Feld „Status“ = „Solution Database“.
Erfassung
Statusfeld auf den Wechsel zu „Solution Database“ prüfen
Ereignistyp
inferred
|
|||
|
Überprüfung nach der Umsetzung durchgeführt
|
Die PIR-Phase ist abgeschlossen. Erfasst durch einen Statuswechsel aus einem PIR-Status oder den Abschluss einer verknüpften PIR Task. | ||
|
Warum das wichtig ist
Unterstützt direkt die „Post Implementation Review Compliance“ und Qualitätsprüfungen des Prozesses.
Woher beziehen
Formular PBM:Problem Investigation, Kennzeichen „PIR Required“ oder Abschluss einer verknüpften Task vom Typ „PIR“.
Erfassung
Abgeleitet aus dem Abschluss des PIR-Status oder der PIR Task
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Verbessern Sie die Stabilität Ihres Service, indem Sie dieses Template noch heute auf Ihre BMC Helix ITSM-Daten anwenden. Bei Fragen zur Einrichtung hilft Ihnen unser Team gerne weiter.
Beseitigen Sie noch heute Engpässe im Problem Management
Verkürzen Sie die Zykluszeiten um 30 % und verbessern Sie die Stabilität Ihres Service.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.