Ihr Daten-Template für das Problemmanagement
Ihr Daten-Template für das Problemmanagement
- Empfohlene Attribute für die Ursachenanalyse
- Wichtige Prozessmeilensteine und Aktivitäten
- Schritt-für-Schritt-Anleitung zur Datenextraktion aus ServiceNow
Attribute des Problemmanagements
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Das konkrete Ereignis oder die Aktion, die am Problem-Datensatz ausgeführt wurde. | ||
|
Beschreibung
Dieses Attribut bildet die einzelnen Schritte und Statusänderungen im Lebenszyklus eines Problem-Datensatzes ab. Beispiele sind „Problem-Datensatz erstellt“, „Ursache ermittelt“ oder „Supportgruppe zugewiesen“. Es ist entscheidend, um die Prozesslandkarte zu erstellen und die Abfolge der Ereignisse darzustellen.
Warum das wichtig ist
Das Attribut definiert die Knoten in der Prozesslandkarte und ermöglicht die Darstellung des Workflows und seiner Varianten.
Woher beziehen
Abgeleitet aus den Tabellen „sys_audit“ und „sys_history_line“ oder aus Statusänderungen in der Tabelle „problem“
Beispiele
Problem-Datensatz erstelltAnalyse abgeschlossenStatus auf „Geschlossen“ geändert
|
|||
|
Ereignis-Timestamp
EventTime
|
Das genaue Datum und die Uhrzeit, zu denen eine Aktivität stattgefunden hat. | ||
|
Beschreibung
Erfasst den genauen Timestamp, zu dem eine Änderung oder Aktion im System protokolliert wurde. Dieser Wert ist entscheidend, um Aktivitäten chronologisch zu ordnen und Zeitkennzahlen wie Zykluszeiten sowie Durchlaufzeiten zwischen Prozessschritten zu berechnen.
Warum das wichtig ist
Unverzichtbar, um Ereignisse zu ordnen und alle zeitbasierten KPIs zu berechnen.
Woher beziehen
ServiceNow-Feld „sys_created_on“ in Audit- und Verlaufstabellen
Beispiele
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
Problem-Datensatz
ProblemNumber
|
Die eindeutige Kennung des Problem-Datensatzes. | ||
|
Beschreibung
Der eindeutige alphanumerische Schlüssel für einen bestimmten Problem-Datensatz in ServiceNow, zum Beispiel PRB000123. Diese Kennung bildet den roten Faden, der alle Prozessaktivitäten miteinander verknüpft: von der ersten Erfassung über die Ursachenanalyse bis zum endgültigen Abschluss. In der Process-Mining-Analyse dient dieses Attribut als Case-ID. So lässt sich der gesamte Weg der Problemlösung rekonstruieren.
Warum das wichtig ist
Der Primärschlüssel dient dazu, einzelne Cases voneinander zu unterscheiden und zusammengehörige Ereignisse im Prozessgraph zu gruppieren.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „number“
Beispiele
PRB004512PRB009823PRB001122
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der Datenextraktion oder der letzten Aktualisierung. | ||
|
Beschreibung
Zeigt, wie aktuell der für die Analyse verwendete Datensatz ist. So können Analysten erkennen, ob sie Echtzeitdaten oder einen historischen Datenstand betrachten. Das ist wichtig, um den Status offener Cases richtig einzuordnen.
Warum das wichtig ist
Zeigt Benutzern, wie aktuell die Daten sind, damit sie operative Berichte korrekt interpretieren können.
Woher beziehen
Systemzeit zum Zeitpunkt der ETL-Ausführung
Beispiele
2023-11-01T12:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Der Name des Systems, aus dem die Daten stammen. | ||
|
Beschreibung
Gibt an, aus welcher ServiceNow-Instanz oder -Umgebung die Daten zum Problemmanagement extrahiert wurden. Das ist besonders in Umgebungen mit mehreren Systemen hilfreich, um die Datenherkunft nachzuverfolgen und systemspezifische Besonderheiten in der Analyse zu berücksichtigen.
Warum das wichtig ist
Liefert Informationen zur Datenherkunft, insbesondere wenn Daten aus mehreren ITSM-Tools zusammengeführt werden.
Woher beziehen
Bei der Extraktion fest hinterlegt, zum Beispiel „ServiceNow Production“
Beispiele
ServiceNow ProdServiceNow EMEA
|
|||
|
Anzahl der Neuzuweisungen
ReassignmentCount
|
Wie oft das Problem zwischen Gruppen neu zugewiesen wurde. | ||
|
Beschreibung
Zählt, wie häufig sich die zugewiesene Gruppe geändert hat. Dieser Wert fließt direkt in die KPI „Anzahl der Neuzuweisungen von Problem-Datensätzen“ ein und hilft, ein Hin und Her zwischen Teams zu erkennen.
Warum das wichtig ist
Ein direkter Hinweis auf Reibungsverluste im Prozess und unklare Zuständigkeiten.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „reassignment_count“
Beispiele
0312
|
|||
|
Anzahl verknüpfter Incidents
RelatedIncidentCount
|
Die Anzahl der Incidents, die mit diesem Problem-Datensatz verknüpft sind. | ||
|
Beschreibung
Beziffert die Auswirkungen des Problems anhand der damit verknüpften Incidents. Hohe Werte, insbesondere bei bekannten Fehlern, fließen in das Dashboard „Bekannte Fehler und wiederkehrende Incidents“ ein.
Warum das wichtig ist
Misst das Ausmaß der Auswirkungen des Problems auf Benutzer.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „related_incidents“ (Feldname kann abweichen) oder Anzahl verknüpfter Datensätze
Beispiele
1501200
|
|||
|
Priorität
Priority
|
Die dem Problem-Datensatz zugewiesene Prioritätsstufe. | ||
|
Beschreibung
Gibt die Bedeutung und Dringlichkeit des Problems an. Die Priorität wird üblicherweise anhand von Auswirkung und Dringlichkeit berechnet. Mit diesem Attribut lässt sich die Analyse nach Kritikalität aufschlüsseln, etwa im Dashboard „Überwachung von SLA-Verstößen und Prioritäten“.
Warum das wichtig ist
Ermöglicht es, die Prozessleistung nach geschäftlicher Kritikalität aufzuschlüsseln.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „priority“
Beispiele
1 - Kritisch2 - Hoch3 - Mittel
|
|||
|
Problemstatus
ProblemState
|
Der Status im Lebenszyklus des Problem-Datensatzes. | ||
|
Beschreibung
Zeigt die aktuelle Phase des Problem-Datensatzes an, zum Beispiel „Offen“, „Ursachenanalyse“, „Fehlerbehebung läuft“ oder „Geschlossen“. Das Attribut ist maßgeblich, um den Backlog im Dashboard „Altersstrukturanalyse älterer Problem-Datensätze“ zu filtern und seine Zusammensetzung zu verstehen.
Warum das wichtig ist
Die zentrale Statusangabe zum Filtern offener und geschlossener Cases.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „state“
Beispiele
NeuBewertenUrsachenanalyseGelöst
|
|||
|
Supportgruppe
AssignmentGroup
|
Das technische Team, das für die Problemlösung zuständig ist. | ||
|
Beschreibung
Gibt an, welcher Supportgruppe oder welchem Team das Problem aktuell zugewiesen ist. Dieses Attribut ist für das Dashboard „Analyse der Neuzuweisungen zwischen Supportgruppen“ wichtig: Es macht Übergaben zwischen Teams sichtbar und hilft, organisatorische Silos zu erkennen.
Warum das wichtig ist
Entscheidend, um Engpässe zwischen Abteilungen zu erkennen und die Effizienz von Übergaben zu analysieren.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „assignment_group“
Beispiele
NetzwerkbetriebDatenbankadministratorenService Desk
|
|||
|
Ursachenkategorie
RootCauseCategory
|
Die Klassifizierung der ermittelten Ursache. | ||
|
Beschreibung
Ordnet die zugrunde liegende Ursache des Problems ein, zum Beispiel Softwarefehler, menschliches Versagen oder Hardwareausfall. Dieses Attribut bildet die Grundlage für das Dashboard „Genauigkeit der Ursachenklassifizierung“ und hilft, systematische Fehlermuster zu erkennen.
Warum das wichtig ist
Ermöglicht die Analyse von Fehlermustern als Grundlage für gezielte Verbesserungen.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „rca_category“ oder „u_root_cause_category“
Beispiele
SoftwarefehlerKonfigurationsfehlerProblem mit einem Anbieter
|
|||
|
Zugewiesener Benutzer
AssignedTo
|
Die Person, die mit der Bearbeitung des Problems betraut ist. | ||
|
Beschreibung
Gibt an, welcher Benutzer aktuell für den Problem-Datensatz verantwortlich ist. Die Analyse dieses Attributs zeigt, wie sich die Arbeitslast verteilt, wie die individuelle Leistung ausfällt und wo Engpässe auf Ressourcenebene entstehen können.
Warum das wichtig ist
Wichtig für die Analyse der Ressourceneffizienz und der individuellen Arbeitslast.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „assigned_to“
Beispiele
Alice SmithBob JonesSystemadministrator
|
|||
|
Als bekannter Fehler eingestuft
IsKnownError
|
Kennzeichen dafür, ob das Problem als bekannter Fehler eingestuft ist. | ||
|
Beschreibung
Gibt an, ob der Problem-Datensatz in einen bekannten Fehler umgewandelt oder als solcher gekennzeichnet wurde. Das ist wichtig für die Analyse „Bekannte Fehler und wiederkehrende Incidents“, mit der sich die Wirksamkeit des Wissensmanagements prüfen lässt.
Warum das wichtig ist
Unterscheidet zwischen laufenden Untersuchungen und anerkannten Fehlern, für die Behelfslösungen vorliegen.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „known_error“
Beispiele
truefalse
|
|||
|
Dauer der Lösungserarbeitung
SolutionDraftingTime
|
Zeit zwischen der Ermittlung der Ursache und dem Vorschlag einer Lösung. | ||
|
Beschreibung
Erfasst die Dauer der Entwurfsphase, in der nach Ermittlung der Ursache eine Fehlerbehebung entwickelt wird. Die Kennzahl unterstützt das Dashboard „Lösungserarbeitung und Umsetzung der Fehlerbehebung“.
Warum das wichtig ist
Macht die Leistung in der Phase der Fehlerbehebungsplanung separat sichtbar.
Woher beziehen
Berechnet als Timestamp von „Lösungsvorschlag erstellt“ minus „Ursache ermittelt“
Beispiele
2 Tage4 Stunden
|
|||
|
Dauer des Ausstehens
PendingDuration
|
Gesamtdauer, die sich das Problem in einem ausgesetzten oder ausstehenden Status befand. | ||
|
Beschreibung
Addiert die Zeit in Status wie „Warten auf Anbieter“ oder „Zurückgestellt“. Die Kennzahl wird in der „Wartezeitanalyse für ausstehende Status“ verwendet, um interne Bearbeitungszeit von externen Verzögerungen zu unterscheiden.
Warum das wichtig ist
Unterscheidet zwischen Ineffizienzen im Team und externen Abhängigkeiten.
Woher beziehen
Berechnet als Summe der Zeitintervalle mit Status „Ausstehend“ oder „Zurückgestellt“
Beispiele
5 Tage0 Minuten
|
|||
|
Ergebnis der PIR
PostImplementationReviewResult
|
Das Ergebnis oder der Abschlussstatus des Reviews nach der Implementierung. | ||
|
Beschreibung
Speichert das Ergebnis oder den Status der PIR, zum Beispiel „Abgeschlossen“, „Nicht erforderlich“ oder „Ausstehend“. Dieses Attribut wird für das Dashboard „Einhaltung der Reviews nach der Implementierung“ benötigt, damit größere Probleme überprüft werden.
Warum das wichtig ist
Kennzahl zur Qualitätskontrolle, die sicherstellt, dass aus schwerwiegenden Incidents gelernt wird.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „pir_state“ oder ein ähnliches benutzerdefiniertes Feld
Beispiele
AbgeschlossenAusgenommenAusstehend
|
|||
|
Geschäftsservice
BusinessService
|
Der übergeordnete Geschäftsservice, der vom Problem betroffen ist. | ||
|
Beschreibung
Bezeichnet den für das Geschäft relevanten Service, zum Beispiel „Gehaltsabrechnung“ oder „Kundenportal“, und nicht die technische Komponente. So erhalten Stakeholder eine geschäftsorientierte Sicht auf die Daten.
Warum das wichtig ist
Stellt den Bezug zwischen technischen Problemen und geschäftlichen Wertströmen her.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „business_service“
Beispiele
OnlinebankingInterne E-Mail
|
|||
|
Konfigurationselement
ConfigurationItem
|
Das konkrete Asset oder der Service, das beziehungsweise der vom Problem betroffen ist. | ||
|
Beschreibung
Gibt das Konfigurationselement (CI) an, das mit dem Problem-Datensatz verknüpft ist. Die Analyse zeigt, welche Hardware, Software oder Services mit Problemen zusammenhängen. Sie unterstützt damit das Dashboard „Genauigkeit der Ursachenklassifizierung“.
Warum das wichtig ist
Verknüpft Prozessprobleme mit bestimmten physischen oder logischen Assets.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „cmdb_ci“
Beispiele
SAP-ERP-Server 01Exchange-E-Mail-ServiceOracle-Produktionsdatenbank
|
|||
|
Nummer des Änderungsantrags
ChangeRequestNumber
|
Die Kennung des Änderungsantrags, der zur Behebung des Problems erstellt wurde. | ||
|
Beschreibung
Verknüpft den Problem-Datensatz mit einem Datensatz aus dem Änderungsmanagement (RFC). Diese Verbindung ist für das Dashboard „Effizienz des Übergangs zum Änderungsantrag“ wichtig: Damit lässt sich messen, wie schnell die Übergabe von der Problemdiagnose zur Umsetzung der Infrastrukturänderung erfolgt.
Warum das wichtig ist
Verfolgt den Übergang vom Problemmanagement zum Änderungsmanagement.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „rfc“
Beispiele
CHG003001CHG004552
|
|||
|
SLA-Fälligkeit
SlaDueDate
|
Der im SLA festgelegte Zielzeitpunkt für die Problemlösung. | ||
|
Beschreibung
Der Timestamp, bis zu dem das Problem gemäß den Service Level Agreements gelöst sein muss. Er dient als Grundlage für das Dashboard „Überwachung von SLA-Verstößen und Prioritäten“ sowie für die Berechnung der Konformitätsraten.
Warum das wichtig ist
Grundlage für die Berechnung, ob ein SLA-Verstoß vorliegt.
Woher beziehen
Mit dem Problem verknüpfte ServiceNow-Tabelle „task_sla“
Beispiele
2023-12-31T17:00:00Z
|
|||
|
Übergangslösung veröffentlicht
WorkaroundPublished
|
Zeigt an, ob eine Behelfslösung dokumentiert und weitergegeben wurde. | ||
|
Beschreibung
Ein boolesches Feld oder Statuskennzeichen, das angibt, ob eine vorläufige Lösung gefunden und in der Knowledge Base oder der Datenbank bekannter Fehler veröffentlicht wurde. Das Attribut unterstützt das Dashboard „Leistung bei der Veröffentlichung von Behelfslösungen“.
Warum das wichtig ist
Entscheidend, um zu messen, wie schnell die Auswirkungen auf das Geschäft vor einer endgültigen Fehlerbehebung eingedämmt werden.
Woher beziehen
ServiceNow-Tabelle „problem“, Feld „work_around“ (wenn Text vorhanden ist) oder ein bestimmter Status
Beispiele
truefalse
|
|||
Aktivitäten im Problemmanagement
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Änderungsantrag eingeleitet
|
Ein Änderungsantrag (RFC) wird mit dem Problem-Datensatz verknüpft. Damit wird die Zuständigkeit für die Umsetzung von Problem Management an Change Management übergeben. | ||
|
Warum das wichtig ist
Wichtig für das Dashboard zur Effizienz des Übergangs zum Änderungsantrag. Zeigt Verzögerungen zwischen der Ermittlung einer Lösung und dem Start des Änderungsprozesses.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', in der das Befüllen des Referenzfelds 'rfc' in der Tabelle 'problem' erfasst wird.
Erfassung
Erfasst, wenn die Transaktion Create Normal Change ausgeführt wird
Ereignistyp
explicit
|
|||
|
Dauerhafte Lösung umgesetzt
|
Der Zeitpunkt, an dem das Problem als gelöst markiert wird, häufig nach Abschluss des zugehörigen Änderungsantrags. Damit ist die technische Arbeit abgeschlossen. | ||
|
Warum das wichtig ist
Legt das Ende des aktiven Behebungszyklus fest. Dient zur Berechnung der gesamten Lösungszeit im Verhältnis zum SLA.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', Feld 'state': Wechsel zu 'Resolved' (typischer Wert: 106).
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Problem-Datensatz erstellt
|
Ein Problem-Datensatz wird erstmals im ServiceNow-System erstellt. Damit beginnt der Lebenszyklus des Problem Managements und der Timestamp für die Berechnung des Datensatzalters wird festgelegt. | ||
|
Warum das wichtig ist
Legt den Startzeitpunkt für alle Berechnungen der Zykluszeit und SLA-Messungen fest. Dient als zentrale Grundlage, um das Volumen eingehender Problem-Untersuchungen zu ermitteln.
Woher beziehen
ServiceNow-Tabelle 'problem', Feld 'sys_created_on'.
Erfassung
Erfasst, wenn die Transaktion New Record ausgeführt wird
Ereignistyp
explicit
|
|||
|
Problem-Datensatz geschlossen
|
Das abschließende Ereignis im Lebenszyklus: Der Datensatz wird inaktiv und es sind keine weiteren Arbeiten vorgesehen. | ||
|
Warum das wichtig ist
Der endgültige Endpunkt der Prozessinstanz. Wird zur Berechnung der gesamten Zykluszeit benötigt.
Woher beziehen
ServiceNow-Tabelle 'problem', Feld 'closed_at' oder Statuswechsel zu 'Closed'.
Erfassung
Erfasst, wenn die Transaktion Close Problem ausgeführt wird
Ereignistyp
explicit
|
|||
|
Supportgruppe zugewiesen
|
Der Problem-Datensatz wird zur Untersuchung an ein bestimmtes technisches Team weitergeleitet. Diese Aktivität bildet den Zuständigkeitsverlauf ab und ist wichtig für die Analyse von Übergaben. | ||
|
Warum das wichtig ist
Wichtig für das Dashboard zur Analyse von Neuzuweisungen zwischen Supportgruppen. Damit lassen sich Hin-und-her-Weiterleitungen und Engpässe zwischen Teams erkennen.
Woher beziehen
ServiceNow-Tabelle 'sys_audit' oder 'sys_history_line', in der Änderungen am Feld 'assignment_group' erfasst werden.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Übergangslösung ermittelt
|
Text wird in das Feld 'Workaround' des Problem-Datensatzes eingetragen. Damit wird erfasst, wann der Analyst eine vorübergehende Lösung dokumentiert. | ||
|
Warum das wichtig ist
Unterstützt das Dashboard zur Leistung bei der Veröffentlichung von Übergangslösungen, indem erfasst wird, wann die technische Lösung erstmals bekannt war.
Woher beziehen
ServiceNow-Tabelle 'sys_audit' mit dem Feld 'fieldname' auf 'workaround'.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Untersuchung begonnen
|
Der Status des Problem-Datensatzes wechselt von 'New' zu 'Assess' oder 'Root Cause Analysis'. Damit beginnt ein Analyst aktiv mit der Bearbeitung des Problems. | ||
|
Warum das wichtig ist
Markiert das Ende der anfänglichen Wartezeit in der Warteschlange und den Beginn der aktiven Untersuchungsphase. Unterstützt die Analyse ausstehender Status.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', in der Änderungen am Feld 'state' erfasst werden, zum Beispiel der Wechsel zu 102 oder 103, je nach Konfiguration.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Ursache ermittelt
|
Die Codes für 'Root Cause' werden ausgefüllt oder der Status wechselt zu 'Fix in Progress'. Damit ist das Problem erfolgreich diagnostiziert. | ||
|
Warum das wichtig ist
Berechnet die durchschnittliche Zeit bis zur Ermittlung der Ursache und unterstützt das Dashboard zur Zykluszeit der Ursachenanalyse. Ein wichtiger Meilenstein im Prozess.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', in der Änderungen am Feld für die Kategorie 'root_cause' oder der Wechsel zum Status 'Fix in Progress' erfasst werden.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Bewertung abgelehnt
|
Der Problem-Datensatz wird während der Bewertungsphase in einen vorherigen Status zurückgesetzt oder abgebrochen, weil kein gültiges Problem vorliegt. | ||
|
Warum das wichtig ist
Zeigt unnötigen Aufwand, wenn Störungen fälschlicherweise als Probleme eingestuft werden.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', Feld 'state': Wechsel von 'Assess' zu 'Closed/Cancelled' oder 'New'.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Lösung überprüft
|
Bei diesem Prüfschritt wird bestätigt, dass die Lösung wirksam ist. Je nach Reife des Prozesses wird dafür ein eigener Status oder ein Kontrollkästchen verwendet. | ||
|
Warum das wichtig ist
Stellt die Qualitätskontrolle vor dem Abschluss sicher. Wird dieser Schritt übersprungen, lässt sich die Prozessabweichung analysieren.
Woher beziehen
ServiceNow-Tabelle 'sys_audit'. Kann ein Statuswechsel von Resolved zu Closed oder bei entsprechender Konfiguration eine Änderung am Feld 'u_resolution_verified' sein.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Lösungsvorschlag entworfen
|
Daten werden in die Felder 'Fix Notes' oder 'Resolution Code' eingetragen. Das zeigt, dass der Analyst von der Ursachenanalyse zum Entwurf einer dauerhaften Lösung übergegangen ist. | ||
|
Warum das wichtig ist
Unterstützt das Dashboard zum Entwurf und zur Umsetzung von Lösungen, indem die Dauer der Entwurfsphase separat erfasst wird.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', in der Aktualisierungen des Felds 'fix_notes' erfasst werden.
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Review nach der Implementierung abgeschlossen
|
Die PIR-Aufgabe wird abgeschlossen oder eine PIR-Kennzeichnung gesetzt. Damit wird bestätigt, dass bei größeren Problemen eine rückblickende Analyse durchgeführt wurde. | ||
|
Warum das wichtig ist
Unterstützt direkt das Dashboard zur Einhaltung der Vorgaben für Reviews nach der Implementierung. Fehlt diese Aktivität bei Problemen mit hoher Priorität, deutet das auf einen Compliance-Verstoß hin.
Woher beziehen
Abschluss eines Datensatzes vom Typ PIR in der ServiceNow-Tabelle 'problem_task' oder Änderung des Felds 'pir_state' in der Tabelle 'problem'.
Erfassung
Durch Vergleich von Feld X mit Feld Y ableiten
Ereignistyp
inferred
|
|||
|
Status auf Fix in Progress geändert
|
Der Datensatz wechselt in einen Status, der anzeigt, dass eine Behebung entwickelt oder bereitgestellt wird. Häufig wartet der Vorgang dabei auf Change Management. | ||
|
Warum das wichtig ist
Unterscheidet die aktive Untersuchungszeit von der Wartezeit auf eine Änderung und präzisiert so die Engpassanalyse.
Woher beziehen
ServiceNow-Tabelle 'sys_audit', Feld 'state': Wechsel zu 'Fix in Progress' (typischer Wert: 104).
Erfassung
Statusfeld vorher und nachher vergleichen
Ereignistyp
inferred
|
|||
|
Übergangslösung veröffentlicht
|
Die Aktion 'Communicate Workaround' wird ausgeführt. Dadurch wird die Übergangslösung an verknüpfte Störungen weitergegeben oder ein Artikel zu einem bekannten Fehler erstellt. Das ist nicht dasselbe wie das bloße Eintragen der Übergangslösung. | ||
|
Warum das wichtig ist
Entscheidend für die Messung, wie schnell Wissen geteilt wird. Verzögerungen wirken sich unmittelbar auf das Volumen wiederkehrender Störungen aus.
Woher beziehen
ServiceNow-Tabelle 'sys_journal_field' oder spezifische UI-Action-Logs. Alternativ lässt sich das Ereignis ableiten, wenn ein Datensatz vom Typ 'Known Error' in 'kb_knowledge' erstellt wird.
Erfassung
Erfasst, wenn die Transaktion Communicate Workaround ausgeführt wird
Ereignistyp
explicit
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Laden Sie das vollständige Template herunter und verwandeln Sie Ihre Problemmanagement-Daten noch heute in konkrete Erkenntnisse. Unser Team unterstützt Sie bei jedem Schritt Ihrer Process-Mining-Reise.
Optimieren Sie jetzt das Problemmanagement und lösen Sie Probleme schneller
Verkürzen Sie mit Process Mining den Untersuchungszyklus um 30 %
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.