Ihr Daten-Template für das Problemmanagement

ServiceNow-Problemmanagement
Ihr Daten-Template für das Problemmanagement

Ihr Daten-Template für das Problemmanagement

Dieses Template bietet eine umfassende Vorlage für die Analyse des ITIL-Problemmanagement-Lebenszyklus in ServiceNow. Es enthält die erforderlichen Attribute, die zu erfassenden wichtigen Aktivitäten und eine Schritt-für-Schritt-Anleitung zur Extraktion Ihrer Daten. So erhalten Sie die nötige Transparenz, um die durchschnittliche Lösungszeit zu verkürzen und wiederkehrende Incidents zu vermeiden.
  • Empfohlene Attribute für die Ursachenanalyse
  • Wichtige Prozessmeilensteine und Aktivitäten
  • Schritt-für-Schritt-Anleitung zur Datenextraktion aus ServiceNow
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Problemmanagements

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren ITIL-Problemmanagementprozess umfassend zu analysieren.
5 Erforderlich 7 Empfohlen 9 Optional
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
Erforderlich Empfohlen Optional

Aktivitäten im Problemmanagement

Diese wichtigen Prozessschritte und Meilensteine des Lebenszyklus sollten Sie in Ihrem Event Log erfassen, damit Ihre Problemmanagement-Workflows präzise erkannt werden können.
8 Empfohlen 6 Optional
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
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus dem ServiceNow-Problemmanagement

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 %

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.