Ihr Change Management Daten-Template
Ihr Change Management Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Nachverfolgung für eine präzise Prozesserkennung
- Anleitung zur Datenextraktion aus ServiceNow
Change Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Change Request ID
ChangeRequestNumber
|
Die eindeutige Kennung für eine Änderungsanforderung, die als primäre Fall-ID zur Gruppierung aller zugehörigen Ereignisse dient. | ||
|
Beschreibung
Die Change Request ID ist der Eckpfeiler der Change Management Prozessanalyse. Es ist eine eindeutige Nummer, die jeder Änderungsanforderung zugewiesen wird, wie z. B. 'CHG0030001', und alle Aktivitäten, Genehmigungen und Aufgaben miteinander verbindet. Im Process Mining wird dieses Attribut verwendet, um den End-to-End-Verlauf jeder einzelnen Änderung zu rekonstruieren. Es ermöglicht Analysten, den gesamten Lebenszyklus von der Erstellung bis zum Abschluss zu verfolgen und bietet eine kohärente Sicht darauf, wie jede Änderung im System voranschreitet. Die Analyse von Prozessen, die nach dieser ID gruppiert sind, ist entscheidend für die Berechnung von Durchlaufzeiten, die Identifizierung von Nacharbeitszyklen und das Verständnis von Prozessvarianten.
Bedeutung
Diese ID ist unerlässlich für die Verfolgung des gesamten Lebenszyklus einer Änderung und ermöglicht eine vollständige Analyse von Prozessfluss, Dauer und Compliance für jede Anforderung.
Datenquelle
ServiceNow Tabelle: change_request, Feld: number
Beispiele
CHG0030001CHG0030045CHG0030112
|
|||
|
Ereigniszeit
EventTime
|
Der genaue Zeitstempel, wann eine spezifische Aktivität oder ein Ereignis aufgetreten ist. | ||
|
Beschreibung
Event Time erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität durchgeführt oder eine Statusänderung registriert wurde. Dieser Timestamp ist entscheidend für die chronologische Reihenfolge der Events und für alle dauerbasierten Analysen. Im Process Mining ermöglicht dieses Attribut die Berechnung von Durchlaufzeiten, Bearbeitungszeiten und Wartezeiten zwischen Aktivitäten. Es ist unerlässlich für Dashboards, die die Performance analysieren, wie z. B. den Change Approval Cycle Time und den End-to-End Change Process Flow. Genaue Timestamps sind die Grundlage für die Identifizierung von Verzögerungen und die Messung der Prozesseffizienz im Vergleich zu SLAs.
Bedeutung
Dieser Zeitstempel ist entscheidend für die korrekte Sequenzierung von Ereignissen und die Berechnung aller zeitbasierten Metriken, einschließlich Durchlaufzeiten, Dauern und SLA-Einhaltung.
Datenquelle
ServiceNow Tabelle: sys_audit, Feld: sys_created_on. Dies liefert den Zeitstempel für jede aufgezeichnete Änderung.
Beispiele
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Ereignisses oder einer Aufgabe, das/die innerhalb des Change Management Prozesses aufgetreten ist. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen diskreten Schritt oder eine Statusänderung im Lebenszyklus einer Änderungsanforderung. Beispiele sind 'Change Awaiting Assessment', 'Approval Requested' und 'Change Implemented'. Diese Aktivitäten bilden die Knoten in der entdeckten Prozesskarte. Die Analyse dieser Aktivitäten ermöglicht eine detaillierte Untersuchung des Prozessflusses. Durch die Verfolgung der Abfolge und Häufigkeit von Aktivitäten können Organisationen gängige Pfade, Abweichungen vom Standardprozess und Engpässe identifizieren, an denen Änderungen häufig stagnieren. Dies ist grundlegend für die Visualisierung des Prozesses und die Berechnung von Metriken wie Übergangszeiten zwischen Schritten.
Bedeutung
Es bildet das Rückgrat der Prozesskarte, ermöglicht die Visualisierung des Prozessflusses, die Identifizierung von Engpässen und die Analyse von Abweichungen.
Datenquelle
Abgeleitet von Änderungen im 'state'-Feld oder anderen wichtigen Statusfeldern in der 'change_request'-Tabelle, oft in der 'sys_audit'-Tabelle erfasst.
Beispiele
Change ApprovedImplementierung BegonnenChange ClosedChange Canceled
|
|||
|
Änderungsart
ChangeType
|
Die Klassifizierung der Änderung, wie 'Standard', 'Normal' oder 'Emergency'. | ||
|
Beschreibung
Der Change Type kategorisiert die Change Request basierend auf ihrer Art, ihrem Risiko und ihren Genehmigungsanforderungen. Standard-Changes sind vorab genehmigt, normale Changes durchlaufen den vollständigen Prozess und Notfall-Changes nutzen einen beschleunigten Pfad. Dies ist eine grundlegende Dimension für die Prozessanalyse, da verschiedene Änderungsarten unterschiedliche, legitime Prozessmodelle aufweisen. Der Vergleich der Performance von normalen mit Notfall-Changes kann wichtige Erkenntnisse über die Prozesseinhaltung und Effizienz liefern. Es wird auch in Dashboards wie 'Risk Assessment Standardization' verwendet, um sicherzustellen, dass ähnliche Änderungen konsistent behandelt werden.
Bedeutung
Ermöglicht die Segmentierung der Analyse, da verschiedene Änderungsarten unterschiedlichen autorisierten Prozessflüssen folgen und einzigartige Performance-Erwartungen haben.
Datenquelle
ServiceNow Tabelle: change_request, Feld: type
Beispiele
StandardNormalNotfall
|
|||
|
Bearbeitungsgruppe
AssignmentGroup
|
Das Team oder die Gruppe, die für die Änderungsanforderung verantwortlich ist. | ||
|
Beschreibung
Die Assignment Group gibt an, welches Team derzeit für die Änderungsanforderung verantwortlich ist, wie 'CAB Approval', 'Network Engineering' oder 'Database Administrators'. Dies ist eine kritische Dimension für die Analyse der Prozessleistung in verschiedenen Funktionsbereichen. Dieses Attribut wird verwendet, um die Effizienz auf Teamebene zu messen, Engpässe innerhalb spezifischer Gruppen zu identifizieren und die Effektivität von Übergaben zwischen Teams zu analysieren. Dashboards wie 'Cross-Functional Handoff Efficiency' und 'Change Implementation Throughput' stützen sich stark auf diese Daten, um Verzögerungen durch teamübergreifende Abhängigkeiten zu identifizieren.
Bedeutung
Ermöglicht Performance-Analysen nach Teams, hebt gruppenspezifische Engpässe hervor und misst die Effizienz von Übergaben zwischen verschiedenen Funktionsbereichen.
Datenquelle
ServiceNow Tabelle: change_request, Feld: assignment_group
Beispiele
CAB ApprovalNetwork TeamServer SupportDatenbankadministratoren
|
|||
|
Change State
ChangeState
|
Der aktuelle oder historische Status der Änderungsanforderung, wie 'Assess', 'Authorize', 'Implement' oder 'Closed'. | ||
|
Beschreibung
Das Attribut Change State repräsentiert den Status einer Änderungsanforderung zu einem bestimmten Zeitpunkt. Es bietet eine übergeordnete Zusammenfassung, wo sich die Änderung in ihrem Lebenszyklus befindet. Im Gegensatz zur Aktivität, die ein spezifisches Ereignis darstellt, ist der Status der Zustand, der aus diesem Ereignis resultiert. In der Analyse wird der Change State verwendet, um Fälle zu kategorisieren und deren Ergebnisse zu verstehen. Es ist grundlegend für das Filtern von Änderungen, zum Beispiel, um nur 'Closed'-Änderungen zu analysieren oder zu untersuchen, warum viele Änderungen im 'Authorize'-Status stecken bleiben. Es unterstützt direkt KPIs wie die Change Failure Rate, wenn ein 'Failed'-Status existiert.
Bedeutung
Bietet eine Momentaufnahme des Status der Änderungsanforderung und ermöglicht die Analyse von Ergebnissen, die Filterung von Fällen und die Identifizierung von ins Stocken geratenen Änderungen.
Datenquelle
ServiceNow Tabelle: change_request, Feld: state
Beispiele
AssessAuthorizeGeplantImplementReviewGeschlossenStorniert
|
|||
|
Endzeit
EndTime
|
Der Zeitstempel, wann eine Aktivität abgeschlossen wurde. Er wird oft aus der Startzeit der nachfolgenden Aktivität abgeleitet. | ||
|
Beschreibung
Die Endzeit markiert den Abschluss einer Aktivität. Während Quellsysteme oft den Beginn eines Ereignisses protokollieren, wird die Endzeit häufig abgeleitet. Sie wird typischerweise als der Zeitstempel der nächsten Aktivität in der Sequenz für denselben Fall berechnet. Dieses Attribut ist entscheidend für die Berechnung der Dauer jeder Aktivität, bekannt als Bearbeitungszeit. Zu verstehen, wie lange jeder Schritt dauert, ist grundlegend für die Identifizierung von Engpässen und Ineffizienzen im Prozess. Für die letzte Aktivität in einem Fall ist die Endzeit identisch mit der Startzeit.
Bedeutung
Ermöglicht die Berechnung der Aktivitätsbearbeitungszeit, die entscheidend für die Identifizierung von Engpässen und die Messung der Dauer spezifischer Prozessschritte ist.
Datenquelle
Dieses Attribut wird typischerweise während der Daten transformation berechnet, indem die Startzeit des nächsten Ereignisses für dieselbe CaseId genommen wird.
Beispiele
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Konfigurationselement
ConfigurationItem
|
Die spezifische IT-Komponente, der Dienst oder das System, das/der Gegenstand der Änderung ist. | ||
|
Beschreibung
Das Configuration Item (CI) ist das Asset aus der Configuration Management Database (CMDB), das von der Änderung betroffen sein wird. Dies könnte ein Server, eine Softwareanwendung, ein Netzwerkgerät oder ein Geschäftsservice sein. Dieses Attribut liefert kritischen Kontext für die Änderung. Im Process Mining ermöglicht es die Segmentierung der Analyse nach dem Typ des Assets, das geändert wird. Zum Beispiel verwendet das Dashboard 'Change Testing Duration Analysis' dieses Attribut, um Testzeiten für verschiedene Anwendungen oder Systeme zu vergleichen und hilft zu identifizieren, welche CIs mit längeren Testzyklen verbunden sind.
Bedeutung
Bietet wesentlichen Geschäftskontext, ermöglicht die Filterung der Analyse nach der betroffenen Anwendung, dem Dienst oder dem System, um komponentenspezifische Probleme zu identifizieren.
Datenquelle
ServiceNow Tabelle: change_request, Feld: cmdb_ci
Beispiele
`SAP ERP`Oracle Database 19cE-Mail-DienstWebServer-01
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe der Änderungsanforderung, bestimmt durch deren Auswirkung und Dringlichkeit. | ||
|
Beschreibung
Priorität gibt die Wichtigkeit einer Änderungsanforderung an und bestimmt die Reihenfolge, in der sie bearbeitet werden sollte. Sie wird oft abgeleitet aus Auswirkung und Dringlichkeit der Änderung, mit Werten wie 'Kritisch', 'Hoch', 'Mittel' und 'Niedrig'. Die Analyse nach Priorität ist unerlässlich, um sicherzustellen, dass Änderungen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. Sie unterstützt das 'Critical Change Performance' Dashboard, indem es Analysten ermöglicht, Durchlaufzeiten und Fehlerraten speziell für die wichtigsten Änderungen zu verfolgen. Jede Abweichung, bei der Änderungen mit niedriger Priorität schneller abgeschlossen werden als solche mit hoher Priorität, weist auf ein Problem bei der Ressourcenzuweisung oder Prozessausführung hin.
Bedeutung
Entscheidend für die Bewertung, ob Ressourcen den kritischsten Änderungen korrekt zugewiesen sind und um deren Performance separat zu überwachen.
Datenquelle
ServiceNow Tabelle: change_request, Feld: priority
Beispiele
1 - Kritisch2 - Hoch3 - Moderat4 - Niedrig
|
|||
|
Risikostufe
RiskLevel
|
Das bewertete Risikoniveau der Änderung, wie 'Hoch', 'Mittel' oder 'Niedrig'. | ||
|
Beschreibung
Die Risikostufe ist das Ergebnis des Risikobewertungsprozesses für eine Änderungsanforderung. Sie quantifiziert das Potenzial für nachteilige Folgen, wenn die Änderung implementiert wird, und hilft, das erforderliche Maß an Prüfung und Genehmigung zu bestimmen. Dieses Attribut ist entscheidend für das Dashboard 'Risk Assessment Standardization', wo es verwendet wird, um zu prüfen, ob ähnliche Änderungen konsistente Risikobewertungen erhalten. Die Analyse von Prozessabläufen nach Risikostufe kann auch aufzeigen, ob risikoreiche Änderungen korrekt einem strengeren Genehmigungs- und Testpfad folgen als risikoarme Änderungen, was eine wichtige Compliance-Prüfung darstellt.
Bedeutung
Wesentliche Grundlage für die Compliance-Analyse und um sicherzustellen, dass risikoreiche Änderungen das angemessene Maß an Prüfung erhalten und einem strengeren Prozess folgen.
Datenquelle
ServiceNow Tabelle: change_request, Feld: risk
Beispiele
HochModerateNiedrig
|
|||
|
Assigned To User
AssignedToUser
|
Der einzelne Benutzer, der für die Änderungsanforderung zu einem bestimmten Zeitpunkt verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut identifiziert die spezifische Person, die der Bearbeitung der Änderungsanforderung zugewiesen ist. Dies kann sich im Laufe des Lebenszyklus mehrfach ändern, wenn die Anforderung zwischen verschiedenen Phasen und Teams wechselt. Die Analyse nach Benutzer hilft beim Verständnis der Arbeitslastverteilung, der individuellen Leistung und der Identifizierung von Schulungsbedarfen. Es ist auch entscheidend für die Analyse von Übergaben, insbesondere in Kombination mit der Assignment Group, um zu sehen, wie effizient Arbeit zwischen Einzelpersonen weitergegeben wird.
Bedeutung
Hilft bei der Nachverfolgung individueller Benutzerarbeitslast und Leistung und ist entscheidend für die Analyse von Übergabeverzögerungen zwischen verschiedenen Ressourcen.
Datenquelle
ServiceNow Tabelle: change_request, Feld: assigned_to
Beispiele
Beth AnglinDavid LooAbel Tuter
|
|||
|
Auswirkung
Impact
|
Die potenzielle Auswirkung der Änderung auf den Geschäftsbetrieb, bewertet auf einer Skala wie Hoch, Mittel oder Niedrig. | ||
|
Beschreibung
Auswirkung misst den potenziellen Effekt auf das Geschäft, wenn die Änderungsanforderung nicht korrekt bearbeitet wird. Sie ist eine wichtige Eingabe, zusammen mit der Dringlichkeit, zur Bestimmung der Gesamtpriorität der Änderung. Die Analyse nach Auswirkung hilft sicherzustellen, dass Änderungen, die kritische Dienste betreffen, mit angemessener Sorgfalt verwaltet werden. Sie wird im 'Critical Change Performance' Dashboard verwendet, um Änderungen mit hoher geschäftlicher Auswirkung zu isolieren und zu überwachen. Sie dient auch zur Überprüfung der Konsistenz der Risikobewertung, um sicherzustellen, dass Änderungen mit hoher Auswirkung nicht ohne Begründung einer niedrigen Risikostufe zugewiesen werden.
Bedeutung
Unterstützt die Priorisierung von Änderungen basierend auf ihrer potenziellen geschäftlichen Auswirkung und dient zur Validierung, dass Änderungen mit hoher Auswirkung mit der gebotenen Sorgfalt verwaltet werden.
Datenquelle
ServiceNow Tabelle: change_request, Feld: impact
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Bearbeitungszeit
ProcessingTime
|
Die Dauer einer einzelnen Aktivität, berechnet als Differenz zwischen ihrer Endzeit und Startzeit. | ||
|
Beschreibung
Die Bearbeitungszeit, auch bekannt als Aktivitätsdauer, misst die Zeit, die aktiv an einer bestimmten Aufgabe gearbeitet wird. Sie wird berechnet, indem die Startzeit der Aktivität von ihrer Endzeit subtrahiert wird. Diese berechnete Metrik ist grundlegend für die Leistungsanalyse. Sie ermöglicht die Identifizierung der zeitaufwendigsten Schritte im Prozess, die oft die Hauptziele für Optimierungsbemühungen sind. Dashboards, die die Testdauer oder die Durchlaufzeit der Risikobewertung analysieren, basieren direkt auf dieser Metrik für die relevanten Aktivitäten.
Bedeutung
Misst die Dauer einzelner Aktivitäten und ermöglicht es, die zeitaufwendigsten Schritte zu identifizieren, die Hauptkandidaten für eine Optimierung sind.
Datenquelle
Berechnet während der Datentransformation: EndTime - StartTime.
Beispiele
259200360086400
|
|||
|
Dringlichkeit
Urgency
|
Die Geschwindigkeit, mit der eine Änderung gelöst werden muss, bewertet auf einer Skala wie Hoch, Mittel oder Niedrig. | ||
|
Beschreibung
Dringlichkeit definiert, wie schnell eine Änderung implementiert werden muss. Sie spiegelt die Zeitempfindlichkeit der Anforderung aus geschäftlicher Sicht wider. Zusammen mit der Auswirkung wird sie zur Berechnung der Gesamtpriorität verwendet. Während Priorität das primäre Feld für die Analyse ist, bietet Dringlichkeit zusätzlichen Kontext. Sie kann verwendet werden, um zu untersuchen, warum bestimmte Änderungen als dringend markiert sind und ob der Prozess sie effektiv bewältigt, ohne die Stabilität zu beeinträchtigen. Es hilft, Fragen zu beantworten, ob die Organisation zu oft in einem reaktiven, hochdringlichen Modus agiert.
Bedeutung
Bietet Kontext zur Zeitempfindlichkeit einer Änderung und hilft zu analysieren, ob der Prozess zeitkritische Anfragen effektiv bearbeitet.
Datenquelle
ServiceNow Tabelle: change_request, Feld: urgency
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung bis zum Abschluss einer Änderungsanforderung. | ||
|
Beschreibung
Die Durchlaufzeit ist eine Metrik auf Case-Ebene, die die Gesamtdauer des Lebenszyklus einer Change Request misst. Sie wird als Differenz zwischen dem Timestamp des allerersten Events und dem Timestamp des allerletzten Events für eine gegebene Change Request berechnet. Dies ist ein kritischer KPI zur Messung der gesamten Prozessgeschwindigkeit. Er wird im Dashboard 'End-to-End Change Process Flow' verwendet, um eine übergeordnete Ansicht der Prozessperformance zu bieten. Die Analyse von Durchlaufzeit-Trends und deren Vergleich über verschiedene Dimensionen wie Change Type oder Priority hinweg hilft Organisationen, Möglichkeiten zur strategischen Prozessverbesserung zu identifizieren.
Bedeutung
Misst die End-to-End-Dauer des Änderungsprozesses und liefert einen Schlüsselindikator für die Gesamtprozessgeschwindigkeit und -effizienz.
Datenquelle
Berechnet auf Case-Ebene während der Datenanalyse durch Subtraktion der minimalen StartTime von der maximalen StartTime für jede CaseId.
Beispiele
60480012096002592000
|
|||
|
Ist Nacharbeit
IsRework
|
Ein Boolescher Wert, der wahr ist, wenn eine Aktivität eine Wiederholung eines vorherigen Schritts im selben Case darstellt. | ||
|
Beschreibung
Dieses berechnete Attribut identifiziert Aktivitäten, die Nacharbeit darstellen. Nacharbeit tritt auf, wenn der Prozess zu einem bereits abgeschlossenen Schritt zurückkehren muss, wie eine Änderung, die nach der Genehmigung abgelehnt und zur Neubewertung zurückgesandt wird. Dieses Flag ist entscheidend für die Quantifizierung der Prozesseffizienz. Es unterstützt direkt den 'Change Rework Rate' KPI und das 'Change Failure and Rework Analysis' Dashboard. Durch Filtern nach Aktivitäten, bei denen 'Is Rework' wahr ist, können Analysten die Ursachen der Nacharbeit isolieren und untersuchen, wie unvollständige anfängliche Bewertungen oder sich ändernde Anforderungen, und Maßnahmen zur Abfallreduzierung ergreifen.
Bedeutung
Quantifiziert direkt die Prozessineffizienz, indem es wiederholte Arbeiten kennzeichnet und dabei hilft, die Grundursachen von Prozessschleifen und verschwendetem Aufwand zu identifizieren und zu beheben.
Datenquelle
Berechnet während der Datentransformation durch Erkennung, ob dieselbe Aktivität (oder eine frühere im Standardfluss) für die gegebene CaseId bereits aufgetreten ist.
Beispiele
truefalsch
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut liefert den Zeitstempel der letzten Datenextraktion. Es ist ein Metadatenfeld, das entscheidend ist, um die Aktualität der analysierten Daten zu verstehen. Analysten nutzen diesen Zeitstempel, um zu bestätigen, dass sie mit aktuellen Informationen arbeiten und um die Aktualität der Daten zu verstehen. Es ist besonders wichtig für operative Dashboards, die die laufende Prozessleistung überwachen, und stellt sicher, dass Entscheidungen nicht auf veralteten Daten basieren.
Bedeutung
Zeigt die Aktualität der Daten an und stellt sicher, dass Analysen und Dashboards auf aktuellen und relevanten Informationen basieren.
Datenquelle
Dies ist ein Metadatenfeld, das während des Datenextraktions- und Transformationsprozesses (ETL) generiert wird und den Zeitpunkt des Datenabzugs angibt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden, typischerweise 'ServiceNow'. | ||
|
Beschreibung
Dieses Attribut identifiziert den Ursprung der Prozessdaten. Obwohl in diesem Fall ServiceNow erwartet wird, ist es ein entscheidendes Feld für Data Governance und für Szenarien, in denen Daten aus mehreren Systemen zusammengeführt werden könnten. In der Analyse gewährleistet es eine klare Datenherkunft und hilft bei der Validierung der Datenquelle. Für Organisationen mit mehreren ITSM-Tools oder integrierten Systemen ermöglicht dieses Attribut das Filtern und Vergleichen von Prozessen über verschiedene Plattformen hinweg.
Bedeutung
Bietet eine klare Datenherkunft und stellt sicher, dass der Ursprung der Prozessdaten dokumentiert ist, was für Data Governance und Multi-System-Analyse von entscheidender Bedeutung ist.
Datenquelle
Dies ist typischerweise ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses (ETL) hinzugefügt wird.
Beispiele
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Schließcode
CloseCode
|
Ein Code, der das Ergebnis angibt, wenn die Change Request geschlossen wurde, z. B. 'Successful' oder 'Unsuccessful'. | ||
|
Beschreibung
Der Close Code bietet eine endgültige Klassifizierung für eine abgeschlossene Änderungsanforderung. Er dokumentiert formell, ob die Änderung erfolgreich, mit Problemen oder zurückgerollt wurde. Dieses Attribut ist eine direkte Eingabe für den KPI 'Change Failure Rate'. Durch die Analyse der Verteilung der Close Codes können Organisationen den Erfolg ihrer Änderungsinitiativen quantifizieren. Das Filtern der Prozesskarte nach Änderungen mit einem 'Unsuccessful' Close Code ist eine leistungsstarke Technik für die Ursachenanalyse und deckt gängige Prozessmuster auf, die zu Fehlern führen.
Bedeutung
Misst direkt das Ergebnis einer Änderung und liefert die primären Daten, die zur Berechnung der Ausfallrate von Änderungen und zur Analyse der Grundursachen fehlgeschlagener Änderungen erforderlich sind.
Datenquelle
ServiceNow Tabelle: change_request, Feld: close_code
Beispiele
SuccessfulErfolgreich mit ProblemenNicht erfolgreich / Zurückgerollt
|
|||
|
SLA-Status
SlaState
|
Der Status der Änderungsanforderung in Bezug auf ihr Service Level Agreement (SLA), wie 'On Track', 'At Risk' oder 'Breached'. | ||
|
Beschreibung
Der SLA-Status gibt an, ob die Änderungsanforderung innerhalb der durch ihre SLA definierten Zeitrahmen voranschreitet. Dieser Status kann in jeder Phase des Prozesses verfolgt werden. Dieses Attribut ist entscheidend für die Überwachung der Einhaltung von Service-Level-Verpflichtungen. Es ist die primäre Datenquelle für das 'Change SLA Performance Overview' Dashboard und den KPI 'Change SLA Adherence Rate'. Die Analyse, wo und warum SLAs verletzt werden, ermöglicht es der Organisation, systemische Verzögerungen zu beheben und die Vorhersehbarkeit der Servicebereitstellung zu verbessern.
Bedeutung
Bietet ein direktes Maß für die Leistung im Vergleich zu Fristen, ermöglicht proaktives Monitoring und Analyse von SLA-Verstößen, um die Servicebereitstellung zu verbessern.
Datenquelle
Dies kann aus der Tabelle 'task_sla' in ServiceNow bezogen werden, die SLAs für Aufgaben wie Änderungsanforderungen verfolgt, oder basierend auf Fälligkeitsdatumsfeldern berechnet werden.
Beispiele
On TrackRisikobehaftetVerletzt
|
|||
Change Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Change Approved
|
Die Änderungsanforderung hat alle notwendigen Genehmigungen erhalten, um zu den Planungs- und Implementierungsphasen überzugehen. Dies ist ein kritischer Meilenstein, der erfasst wird, wenn die endgültige Genehmigung erteilt und das Feld 'approval' auf 'approved' gesetzt wird. | ||
|
Bedeutung
Dieser Meilenstein schließt die Genehmigungsphase ab. Er ist entscheidend für die Messung der Genehmigungsdurchlaufzeiten und die Identifizierung von Engpässen im Entscheidungsprozess.
Datenquelle
Abgeleitet aus der Änderung des Feldes 'approval' in der change_request-Tabelle zu 'approved'. Der Zeitstempel stammt aus der Audit-Historie für diese Änderung.
Erfassen
Erfassen Sie den Timestamp, wenn das 'approval'-Feld zu 'approved' wird.
Ereignistyp
inferred
|
|||
|
Change Canceled
|
Die Änderungsanforderung wurde irgendwann vor Abschluss der Implementierung zurückgezogen oder abgebrochen. Dies ist ein alternativer Endzustand, der erfasst wird, wenn der Status auf 'Canceled' gesetzt wird. | ||
|
Bedeutung
Die Analyse abgebrochener Änderungen kann Prozesseffizienzen aufdecken, z. B. dass Anfragen unnötig erstellt werden oder zu lange in der Genehmigung stecken bleiben und obsolet werden.
Datenquelle
Abgeleitet aus der Einstellung des Feldes 'state' in der change_request-Tabelle auf 'Canceled'. Der Zeitstempel wird aus dem Audit-Log für diese Statusänderung erfasst.
Erfassen
Erfassen Sie den Timestamp, wenn das 'state'-Feld auf 'Canceled' aktualisiert wird.
Ereignistyp
inferred
|
|||
|
Change Closed
|
Die Änderungsanforderung wurde erfolgreich abgeschlossen, überprüft und gilt nun als beendet. Dies ist der primäre Erfolgsendpunkt für den Prozess und wird erfasst, wenn der Änderungsstatus zu 'Closed' wechselt. | ||
|
Bedeutung
Diese Aktivität markiert den erfolgreichen Abschluss des Änderungslebenszyklus. Es ist das Endereignis zur Messung der End-to-End-Prozessdauer und der SLA-Einhaltung.
Datenquelle
Abgeleitet aus der Einstellung des Feldes 'state' in der change_request-Tabelle auf 'Closed'. Der Zeitstempel wird aus der Audit-Historie für diese finale Statusänderung entnommen.
Erfassen
Erfassen Sie den Timestamp, wenn das 'state'-Feld auf 'Closed' aktualisiert wird.
Ereignistyp
inferred
|
|||
|
Change Implemented
|
Die Implementierungsarbeit wurde abgeschlossen, und die Änderung ist bereit zur Überprüfung, Verifizierung oder zum Testen. Diese Aktivität wird abgeleitet, wenn der Status der Änderungsanforderung von 'Implement' zu 'Review' wechselt. | ||
|
Bedeutung
Dies ist ein kritischer Meilenstein, der die Implementierungsphase abschließt. Es ist ein Schlüsselereignis für die Berechnung der KPIs 'Change Failure Rate' und 'Change Rework Rate'.
Datenquelle
Abgeleitet aus einem Statusübergang von 'Implement' zu einem nachfolgenden Status wie 'Review'. Der Zeitstempel wird aus der Audit-Historie des Feldes 'state' in der change_request-Tabelle erfasst.
Erfassen
Identifizieren Sie, wann sich das Feld 'state' von 'Implement' zu 'Review' ändert.
Ereignistyp
inferred
|
|||
|
Change Request Created
|
Diese Aktivität markiert die Erstellung eines neuen Änderungsanforderungsdatensatzes im System. Sie ist der offizielle Beginn des Change Management Prozesses und wird erfasst, wenn ein neuer Eintrag in die Tabelle change_request eingefügt wird. | ||
|
Bedeutung
Dies ist das primäre Startereignis für den Prozess. Die Analyse der Zeit von dieser Aktivität zu anderen zeigt die gesamte Durchlaufzeit auf und hilft, Verzögerungen ganz am Anfang des Prozesses zu identifizieren.
Datenquelle
Dieses Ereignis entspricht dem Zeitstempel der Datensatz-Erstellung (sys_created_on) in der ServiceNow change_request-Tabelle.
Erfassen
Verwenden Sie den sys_created_on Zeitstempel aus der change_request-Tabelle.
Ereignistyp
explicit
|
|||
|
Change Scheduled
|
Der genehmigten Änderung wurde ein geplantes Start- und Enddatum zugewiesen und ist nun offiziell im Implementierungskalender eingetragen. Dies wird abgeleitet, wenn der Status der Änderungsanforderung zu 'Scheduled' wechselt. | ||
|
Bedeutung
Diese Aktivität trennt die Planungs- und Genehmigungsphasen von der aktiven Implementierungsphase. Die in diesem Status verbrachte Zeit kann auf Verzögerungen zwischen Genehmigung und Arbeitsbeginn hinweisen.
Datenquelle
Abgeleitet aus einer Änderung des 'state'-Feldes in der change_request-Tabelle zu 'Scheduled'. Der Zeitstempel wird aus dem entsprechenden Audit-Log-Eintrag erfasst.
Erfassen
Verfolgen Sie Statusfeldänderungen zu 'Scheduled' in der Audit-Historie der change_request-Tabelle.
Ereignistyp
inferred
|
|||
|
Risiko und Auswirkung bewertet
|
Repräsentiert den Abschluss der Risiko- und Auswirkungsanalyse für die Änderungsanforderung. Dies ist ein entscheidender Meilenstein, bevor die Genehmigung eingeholt wird, und wird oft abgeleitet, wenn die Änderung aus einem 'Assess'-Status in einen 'Authorize'- oder 'Awaiting Approval'-Status übergeht. | ||
|
Bedeutung
Die Verfolgung der Dauer der Bewertungsphase ist entscheidend für den KPI 'Durchschnittliche Risikobewertungs-Durchlaufzeit'. Es hilft, den Bewertungsprozess zu standardisieren und zu identifizieren, wo Analysen zu lange dauern.
Datenquelle
Abgeleitet aus dem Übergang des Feldes 'state' in der change_request-Tabelle von 'Assess' zu 'Authorize'. Der Ereignis-Zeitstempel wird aus dem Audit-Log dieser Statusänderung erfasst.
Erfassen
Identifizieren Sie, wann sich das Feld 'state' von 'Assess' zu einem nachfolgenden Status wie 'Authorize' ändert.
Ereignistyp
inferred
|
|||
|
Change Awaiting Assessment
|
Die Änderungsanforderung wurde eingereicht und wartet nun auf die technische und geschäftliche Bewertung. Dies wird typischerweise abgeleitet, wenn der Status der Änderungsanforderung zu 'Assess' oder einem ähnlichen Status wechselt, was darauf hinweist, dass sie die Entwurfsphase verlassen hat. | ||
|
Bedeutung
Diese Aktivität hilft, die anfängliche Übergabezeit vom Anforderer an das Bewertungsteam zu messen. Verzögerungen hier können auf Probleme mit der anfänglichen Datenqualität oder der Ressourcenverfügbarkeit für die Bewertung hinweisen.
Datenquelle
Abgeleitet aus einer Änderung des Feldes 'state' in der change_request-Tabelle, typischerweise zu einem Wert wie 'Assess'. Der Zeitstempel wird aus der Audit-Historie (sys_audit) für diese Feldänderung entnommen.
Erfassen
Verfolgen Sie Statusfeldänderungen zu 'Assess' in der Audit-Historie der change_request-Tabelle.
Ereignistyp
inferred
|
|||
|
Change Rejected
|
Die Änderungsanforderung wurde von einem Genehmiger oder dem CAB abgelehnt. Diese Aktivität stellt einen Endzustand für die Anforderung dar, es sei denn, sie wird überarbeitet und erneut eingereicht. Sie wird erfasst, wenn das Feld 'approval' auf 'rejected' gesetzt wird. | ||
|
Bedeutung
Die Verfolgung von Ablehnungen hilft, häufige Gründe für die Ablehnung zu identifizieren, wie unvollständige Informationen oder hohes Risiko. Diese Analyse kann die Qualität zukünftiger Änderungsanträge verbessern.
Datenquelle
Abgeleitet aus der Änderung des Feldes 'approval' in der change_request-Tabelle zu 'rejected'. Der Zeitstempel wird aus der Audit-Historie erfasst.
Erfassen
Erfassen Sie den Timestamp, wenn das 'approval'-Feld zu 'rejected' wird.
Ereignistyp
inferred
|
|||
|
Change Reopened
|
Die Änderungsanforderung wurde in einen früheren Status zurückgesetzt, nachdem sie eine spätere Phase erreicht hatte, z. B. 'Implement' oder 'Assess'. Dieses Ereignis wird aus einem nicht-linearen Statusübergang abgeleitet und bedeutet Nacharbeit. | ||
|
Bedeutung
Diese Aktivität ist entscheidend für die Identifizierung von Nacharbeitszyklen und die Berechnung der 'Change Rework Rate'. Häufige Wiedereröffnungsereignisse deuten auf Probleme mit der Implementierungsqualität, dem Testen oder der Planung hin.
Datenquelle
Abgeleitet durch Analyse der Abfolge von Statusänderungen in der Audit-Historie der change_request. Ein Übergang von einem späteren Status (z. B. 'Review') zu einem früheren Status (z. B. 'Implement') deutet auf ein Wiedereröffnungsereignis hin.
Erfassen
Erkennung eines nicht-sequenziellen, rückwärts gerichteten Übergangs in der Historie des 'state'-Feldes.
Ereignistyp
inferred
|
|||
|
Freigabe angefordert
|
Diese Aktivität bedeutet, dass die Änderungsanforderung formell zur Genehmigung eingereicht wurde, typischerweise an einen Manager oder ein Change Advisory Board (CAB). Dieses Ereignis wird erfasst, wenn der Genehmigungsstatus der Änderungsanforderung auf 'requested' gesetzt wird. | ||
|
Bedeutung
Dies markiert den Beginn des Genehmigungszyklus. Das Messen der Zeit von diesem Ereignis bis zu 'Change Approved' berechnet direkt den KPI 'Durchschnittliche Änderungsfreigabezeit'.
Datenquelle
Abgeleitet aus der Änderung des Feldes 'approval' in der change_request-Tabelle zu 'requested'. Der Zeitstempel wird aus der sys_audit-Tabelle für dieses Feld aufgezeichnet.
Erfassen
Zeitstempel, wann das Feld 'approval' in der change_request-Tabelle auf 'requested' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Implementierung Begonnen
|
Die aktive Implementierung der Änderung hat begonnen. Dies wird erfasst, wenn der Status der Änderungsanfrage auf 'Implementieren' aktualisiert wird, was den Übergang von der Planung zur Ausführung kennzeichnet. | ||
|
Bedeutung
Dies markiert den Beginn der praktischen Implementierungsarbeit. Es ist der Ausgangspunkt für die Messung des KPIs 'Durchschnittliche Implementierungsdauer' und die Analyse der Teameffizienz.
Datenquelle
Abgeleitet aus der Änderung des Feldes 'state' in der change_request-Tabelle zu 'Implement'. Der Zeitstempel wird aus dem Audit-Log für diesen Statusübergang entnommen.
Erfassen
Erfassen Sie den Timestamp der Statusänderung zu 'Implement' aus der
Ereignistyp
inferred
|
|||
|
Überprüfung in Bearbeitung
|
Eine Post-Implementation Review (PIR) wird durchgeführt, um festzustellen, ob die Änderung erfolgreich war und ihre Ziele erreicht hat. Dies wird erfasst, wenn der Status der Change Request auf 'Review' gesetzt wird. | ||
|
Bedeutung
Die Analyse der Dauer der Review-Phase hilft, Verzögerungen bei der Validierung des Änderungserfolgs zu identifizieren. Sie hebt auch nicht-konforme Änderungen hervor, bei denen dieser Schritt übersprungen wird.
Datenquelle
Abgeleitet aus der Änderung des Feldes 'state' in der change_request-Tabelle zu 'Review'. Der Zeitstempel stammt aus dem Audit-Log für diese Statusänderung.
Erfassen
Erfassen Sie den Timestamp der Statusänderung zu 'Review' aus der
Ereignistyp
inferred
|
|||