Ihr Daten-Template für das Änderungsmanagement
Ihr Daten-Template für das Änderungsmanagement
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für eine präzise Prozesserkennung
- Hinweise zur Datenextraktion aus ServiceNow
Attribute des Change Managements
| Name | Beschreibung | ||
|---|---|---|---|
|
Change-Request-ID
ChangeRequestNumber
|
Die eindeutige Kennung eines Change Requests. Sie dient als primäre Case-ID, um alle zugehörigen Events zu gruppieren. | ||
|
Beschreibung
Die Change-Request-ID bildet die Grundlage für die Analyse des Change-Management-Prozesses. Sie ist eine eindeutige Nummer, die jedem Change Request zugewiesen wird, beispielsweise „CHG0030001“, und alle zugehörigen Aktivitäten, Genehmigungen und Tasks miteinander verknüpft. Im Process Mining wird dieses Attribut verwendet, um den durchgängigen Ablauf jedes einzelnen Changes zu rekonstruieren. Es ermöglicht Analysten, den vollständigen Lebenszyklus von der Erstellung bis zum Abschluss nachzuverfolgen und zu erkennen, wie sich jeder Change durch das System bewegt. Die Gruppierung der Prozesse nach dieser ID ist entscheidend für die Berechnung von Zykluszeiten, die Erkennung von Nacharbeitsschleifen und das Verständnis von Prozessvarianten.
Warum das wichtig ist
Diese ID ist entscheidend, um den gesamten Lebenszyklus eines Changes nachzuverfolgen und Prozessfluss, Dauer und Compliance für jeden Request vollständig zu analysieren.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: number
Beispiele
CHG0030001CHG0030045CHG0030112
|
|||
|
Event-Zeit
EventTime
|
Der genaue Timestamp, zu dem eine bestimmte Aktivität oder ein bestimmtes Event stattgefunden hat. | ||
|
Beschreibung
Die Event-Zeit erfasst das genaue Datum und die genaue Uhrzeit, zu denen eine Aktivität ausgeführt oder eine Statusänderung registriert wurde. Dieser Timestamp ist entscheidend für die chronologische Sortierung von Events und für alle zeitbasierten Analysen. Im Process Mining ermöglicht dieses Attribut die Berechnung von Zykluszeiten, Bearbeitungszeiten und Wartezeiten zwischen Aktivitäten. Es ist eine wichtige Grundlage für Dashboards zur Leistungsanalyse, etwa „Change Approval Cycle Time“ und „End-to-End Change Process Flow“. Genaue Timestamps sind die Basis, um Verzögerungen zu erkennen und die Prozesseffizienz anhand von SLAs zu messen.
Warum das wichtig ist
Dieser Timestamp ist entscheidend für die korrekte Reihenfolge der Events und die Berechnung aller zeitbasierten Kennzahlen, einschließlich Zykluszeiten, Dauern und SLA-Einhaltung.
Bezugsquelle
ServiceNow-Tabelle: sys_audit, Feld: sys_created_on. Dieses Feld liefert den Timestamp für jede erfasste Änderung.
Beispiele
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Aktivitätsname
ActivityName
|
Der Name eines bestimmten Events oder Tasks, der innerhalb des Change-Management-Prozesses stattgefunden hat. | ||
|
Beschreibung
Der Aktivitätsname beschreibt einen einzelnen Schritt oder eine Statusänderung im Lebenszyklus eines Change Requests. Beispiele sind „Change Awaiting Assessment“, „Approval Requested“ und „Change Implemented“. Diese Aktivitäten bilden die Knoten in der ermittelten Prozesslandkarte. Die Analyse dieser Aktivitäten ermöglicht eine detaillierte Untersuchung des Prozessflusses. Durch die Nachverfolgung von Reihenfolge und Häufigkeit der Aktivitäten können Unternehmen typische Abläufe, Abweichungen vom Standardprozess und Engpässe erkennen, an denen Changes häufig ins Stocken geraten. Dies ist eine wichtige Grundlage für die Visualisierung des Prozesses und die Berechnung von Kennzahlen wie den Übergangszeiten zwischen einzelnen Schritten.
Warum das wichtig ist
Dieses Attribut bildet das Rückgrat der Prozesslandkarte. Es ermöglicht die Visualisierung des Prozessflusses, die Erkennung von Engpässen und die Analyse von Abweichungen.
Bezugsquelle
Abgeleitet aus Änderungen des Feldes „state“ oder anderer wichtiger Statusfelder in der Tabelle „change_request“, die häufig in der Tabelle „sys_audit“ erfasst werden.
Beispiele
Change genehmigtImplementierung gestartetChange geschlossenChange abgebrochen
|
|||
|
Change-Status
ChangeState
|
Der aktuelle oder historische Status des Change Requests, beispielsweise „Assess“, „Authorize“, „Implement“ oder „Closed“. | ||
|
Beschreibung
Das Attribut Change-Status beschreibt den Status eines Change Requests zu einem bestimmten Zeitpunkt. Es liefert eine übergeordnete Zusammenfassung der Position des Changes in seinem Lebenszyklus. Im Gegensatz zur Aktivität, die ein bestimmtes Event darstellt, beschreibt der Status den Zustand, der aus diesem Event resultiert. In der Analyse wird der Change-Status verwendet, um Cases zu kategorisieren und ihre Ergebnisse zu verstehen. Er ist eine wichtige Grundlage für Filter, etwa um nur „Closed“-Changes zu analysieren oder zu untersuchen, warum viele Changes im Status „Authorize“ feststecken. Wenn ein Status „Failed“ vorhanden ist, unterstützt das Attribut direkt KPIs wie die Change Failure Rate.
Warum das wichtig ist
Liefert eine Momentaufnahme des Status eines Change Requests und ermöglicht die Analyse von Ergebnissen, die Filterung von Cases sowie die Erkennung festgefahrener Changes.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: state
Beispiele
BewertenAutorisierenGeplantImplementierenPrüfenGeschlossenAbgebrochen
|
|||
|
Change-Typ
ChangeType
|
Die Klassifizierung des Changes, beispielsweise „Standard“, „Normal“ oder „Emergency“. | ||
|
Beschreibung
Der Change-Typ kategorisiert den Change Request anhand seiner Art, seines Risikos und der erforderlichen Genehmigungen. Standard Changes sind vorab genehmigt, Normal Changes durchlaufen den vollständigen Prozess und Emergency Changes folgen einem beschleunigten Ablauf. Dies ist eine zentrale Dimension der Prozessanalyse, da verschiedene Change-Typen unterschiedlichen, zulässigen Prozessmodellen folgen. Der Vergleich der Leistung von Normal und Emergency Changes kann wichtige Erkenntnisse zur Prozesseinhaltung und Effizienz liefern. Das Attribut wird außerdem in Dashboards wie „Risk Assessment Standardization“ verwendet, um eine konsistente Behandlung vergleichbarer Changes sicherzustellen.
Warum das wichtig ist
Ermöglicht eine differenzierte Analyse, da verschiedene Change-Typen unterschiedlichen autorisierten Prozessabläufen folgen und jeweils eigene Leistungserwartungen haben.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: type
Beispiele
StandardNormalNotfall
|
|||
|
Configuration Item
ConfigurationItem
|
Die konkrete IT-Komponente, der Service oder das System, auf den beziehungsweise das sich der Change bezieht. | ||
|
Beschreibung
Das Configuration Item (CI) ist das Asset aus der Configuration Management Database (CMDB), das durch den Change betroffen ist. Dabei kann es sich um einen Server, eine Softwareanwendung, ein Netzwerkgerät oder einen Business-Service handeln. Dieses Attribut liefert wichtigen Kontext zum Change. Im Process Mining ermöglicht es, die Analyse nach der Art des betroffenen Assets zu segmentieren. Das Dashboard „Change Testing Duration Analysis“ verwendet dieses Attribut beispielsweise, um Testzeiten verschiedener Anwendungen oder Systeme zu vergleichen und CIs zu identifizieren, die mit längeren Testzyklen verbunden sind.
Warum das wichtig ist
Liefert wichtigen fachlichen Kontext und ermöglicht, die Analyse nach betroffener Anwendung, betroffenem Service oder betroffenem System zu filtern, um komponentenspezifische Probleme zu erkennen.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: cmdb_ci
Beispiele
SAP ERPOracle Database 19cE-Mail-ServiceWebServer-01
|
|||
|
Endzeit
EndTime
|
Der Timestamp, zu dem eine Aktivität abgeschlossen wurde. Häufig wird er aus der Startzeit der nachfolgenden Aktivität abgeleitet. | ||
|
Beschreibung
Die Endzeit kennzeichnet den Abschluss einer Aktivität. Während Quellsysteme häufig den Beginn eines Events protokollieren, wird die Endzeit oft abgeleitet. Typischerweise entspricht sie dem Timestamp der nächsten Aktivität im selben Case. Dieses Attribut ist entscheidend für die Berechnung der Dauer jeder Aktivität, auch Bearbeitungszeit genannt. Die Dauer der einzelnen Schritte zu verstehen, ist eine wichtige Grundlage für die Erkennung von Engpässen und Ineffizienzen. Bei der letzten Aktivität eines Cases entspricht die Endzeit der Startzeit.
Warum das wichtig ist
Ermöglicht die Berechnung der Bearbeitungszeit einer Aktivität. Diese ist entscheidend, um Engpässe zu erkennen und die Dauer bestimmter Prozessschritte zu messen.
Bezugsquelle
Dieses Attribut wird typischerweise während der Datentransformation berechnet, indem die StartTime des nächsten Events für dieselbe CaseId übernommen wird.
Beispiele
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe des Change Requests, die anhand seiner Auswirkungen und Dringlichkeit bestimmt wird. | ||
|
Beschreibung
Die Priorität gibt die Bedeutung eines Change Requests an und bestimmt die Reihenfolge seiner Bearbeitung. Sie wird häufig aus den Auswirkungen und der Dringlichkeit des Changes abgeleitet und umfasst Werte wie „Critical“, „High“, „Moderate“ und „Low“. Die Analyse nach Priorität ist entscheidend, um sicherzustellen, dass Changes mit hoher Priorität schneller bearbeitet werden als Changes mit niedriger Priorität. Sie unterstützt das Dashboard „Critical Change Performance“, indem Analysten Zykluszeiten und Fehlerraten speziell für die wichtigsten Changes verfolgen können. Wenn Changes mit niedriger Priorität schneller abgeschlossen werden als Changes mit hoher Priorität, weist dies auf Probleme bei der Ressourcenverteilung oder Prozessausführung hin.
Warum das wichtig ist
Entscheidend, um zu bewerten, ob Ressourcen korrekt auf die kritischsten Changes verteilt werden, und deren Leistung separat zu überwachen.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: priority
Beispiele
1 - Kritisch2 - Hoch3 - Mäßig4 - Niedrig
|
|||
|
Risikostufe
RiskLevel
|
Die bewertete Risikostufe des Changes, beispielsweise „High“, „Moderate“ oder „Low“. | ||
|
Beschreibung
Die Risikostufe ist das Ergebnis der Risikobewertung eines Change Requests. Sie quantifiziert die möglichen negativen Folgen einer Implementierung und hilft, den erforderlichen Prüfungs- und Genehmigungsumfang zu bestimmen. Dieses Attribut ist eine wichtige Grundlage für das Dashboard „Risk Assessment Standardization“. Dort wird geprüft, ob vergleichbare Changes konsistente Risikobewertungen erhalten. Die Analyse von Prozessabläufen nach Risikostufe kann außerdem zeigen, ob Changes mit hohem Risiko im Vergleich zu Changes mit niedrigem Risiko tatsächlich einen strengeren Genehmigungs- und Testprozess durchlaufen. Dies ist eine wichtige Compliance-Prüfung.
Warum das wichtig ist
Unverzichtbar für Compliance-Analysen und um sicherzustellen, dass Changes mit hohem Risiko angemessen geprüft werden und einen strengeren Prozess durchlaufen.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: risk
Beispiele
HochMäßigNiedrig
|
|||
|
Zuweisungsgruppe
AssignmentGroup
|
Das Team oder die Gruppe, die für den Change Request verantwortlich ist. | ||
|
Beschreibung
Die Assignment Group gibt an, welches Team aktuell für den Change Request verantwortlich ist, beispielsweise „CAB Approval“, „Network Engineering“ oder „Database Administrators“. Sie ist eine wichtige Dimension für die Analyse der Prozessleistung in verschiedenen Funktionsbereichen. Dieses Attribut wird verwendet, um die Effizienz auf Teamebene zu messen, Engpässe in bestimmten Gruppen zu erkennen und die Wirksamkeit von Übergaben zwischen Teams zu analysieren. Dashboards wie „Cross-Functional Handoff Efficiency“ und „Change Implementation Throughput“ greifen stark auf diese Daten zurück, um Verzögerungen durch Abhängigkeiten zwischen Teams zu lokalisieren.
Warum das wichtig ist
Ermöglicht die Leistungsanalyse nach Team, macht gruppenspezifische Engpässe sichtbar und misst die Effizienz von Übergaben zwischen verschiedenen Funktionsbereichen.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: assignment_group
Beispiele
CAB-GenehmigungNetzwerkteamServer-SupportDatenbankadministration
|
|||
|
Abschlusscode
CloseCode
|
Ein Code, der das Ergebnis beim Abschluss des Change Requests angibt, beispielsweise „Successful“ oder „Unsuccessful“. | ||
|
Beschreibung
Der Close Code dokumentiert das abschließende Ergebnis eines fertiggestellten Change Requests. Er hält formal fest, ob der Change erfolgreich, mit Problemen oder durch ein Rollback implementiert wurde. Dieses Attribut fließt direkt in den KPI „Change Failure Rate“ ein. Durch die Analyse der Verteilung der Abschlusscodes können Unternehmen den Erfolg ihrer Change-Initiativen quantifizieren. Eine Filterung der Prozesslandkarte nach Changes mit dem Abschlusscode „Unsuccessful“ ist eine wirkungsvolle Methode für die Ursachenanalyse. Sie macht typische Prozessmuster sichtbar, die zu Fehlern führen.
Warum das wichtig ist
Misst direkt das Ergebnis eines Changes und liefert die wichtigsten Daten zur Berechnung der Change Failure Rate sowie zur Analyse der Ursachen fehlgeschlagener Changes.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: close_code
Beispiele
ErfolgreichErfolgreich mit ProblemenNicht erfolgreich / zurückgesetzt
|
|||
|
Auswirkungen
Impact
|
Die möglichen Auswirkungen des Changes auf den Geschäftsbetrieb, bewertet auf einer Skala wie „High“, „Medium“ oder „Low“. | ||
|
Beschreibung
Die Auswirkungen messen den möglichen Effekt auf das Unternehmen, wenn der Change Request nicht korrekt bearbeitet wird. Zusammen mit der Dringlichkeit sind sie eine wichtige Grundlage für die Bestimmung der Gesamtpriorität des Changes. Die Analyse nach Auswirkungen hilft sicherzustellen, dass Changes mit Auswirkungen auf kritische Services angemessen behandelt werden. Im Dashboard „Critical Change Performance“ wird dieses Attribut verwendet, um Changes mit hoher geschäftlicher Auswirkung gezielt zu isolieren und zu überwachen. Außerdem lässt sich damit die Konsistenz der Risikobewertung prüfen, damit Changes mit hoher Auswirkung nicht ohne Begründung einer niedrigen Risikostufe zugeordnet werden.
Warum das wichtig ist
Hilft, Changes anhand ihrer möglichen geschäftlichen Auswirkungen zu priorisieren, und dient zur Prüfung, ob Changes mit hoher Auswirkung mit der erforderlichen Sorgfalt behandelt werden.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: impact
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Dringlichkeit
Urgency
|
Die Geschwindigkeit, mit der ein Change bearbeitet werden muss, bewertet auf einer Skala wie „High“, „Medium“ oder „Low“. | ||
|
Beschreibung
Die Dringlichkeit legt fest, wie schnell ein Change implementiert werden muss. Sie beschreibt die zeitliche Sensibilität des Requests aus Sicht des Unternehmens. Zusammen mit den Auswirkungen wird sie zur Berechnung der Gesamtpriorität verwendet. Während die Priorität das wichtigste Analysefeld ist, liefert die Dringlichkeit zusätzlichen Kontext. Sie kann zeigen, warum bestimmte Changes als dringend eingestuft werden und ob der Prozess solche Requests wirksam verarbeitet, ohne die Stabilität zu beeinträchtigen. Außerdem hilft sie bei der Frage, ob das Unternehmen zu häufig in einen reaktiven Modus mit hoher Dringlichkeit gerät.
Warum das wichtig ist
Liefert Kontext zur zeitlichen Sensibilität eines Changes und hilft zu analysieren, ob der Prozess zeitkritische Requests wirksam verarbeitet.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: urgency
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Durchlaufzeit
CycleTime
|
Die gesamte verstrichene Zeit von der Erstellung bis zum Abschluss eines Änderungsantrags. | ||
|
Beschreibung
Die Durchlaufzeit ist eine Kennzahl auf Case-Ebene, die die Gesamtdauer des Lebenszyklus eines Änderungsantrags misst. Sie wird als Differenz zwischen dem Timestamp des ersten und dem Timestamp des letzten Ereignisses eines bestimmten Änderungsantrags berechnet. Dieser KPI ist entscheidend für die Messung der gesamten Prozessgeschwindigkeit. Im Dashboard „End-to-End Change Process Flow“ bietet er einen übergeordneten Überblick über die Prozessleistung. Die Analyse von Trends bei der Durchlaufzeit und der Vergleich verschiedener Dimensionen wie Änderungstyp oder Priorität helfen Organisationen, Ansatzpunkte für eine strategische Prozessverbesserung zu erkennen.
Warum das wichtig ist
Misst die End-to-End-Dauer des Änderungsprozesses und liefert damit einen wichtigen Indikator für die gesamte Prozessgeschwindigkeit und Effizienz.
Bezugsquelle
Wird während der Datenanalyse auf Case-Ebene berechnet, indem für jede CaseId die minimale StartTime von der maximalen StartTime abgezogen wird.
Beispiele
60480012096002592000
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Kennzeichen, das den Wert true erhält, wenn eine Aktivität eine Wiederholung eines früheren Schritts im selben Case darstellt. | ||
|
Beschreibung
Dieses berechnete Attribut identifiziert Aktivitäten, die Nacharbeit darstellen. Nacharbeit entsteht, wenn der Prozess zu einem bereits abgeschlossenen Schritt zurückkehren muss, etwa wenn ein Change nach der Genehmigung abgelehnt und zur erneuten Bewertung zurückgesendet wird. Dieses Kennzeichen ist entscheidend, um die Ineffizienz eines Prozesses zu quantifizieren. Es unterstützt direkt den KPI „Change Rework Rate“ und das Dashboard „Change Failure and Rework Analysis“. Durch die Filterung nach Aktivitäten, bei denen „Is Rework“ den Wert true hat, können Analysten die Ursachen der Nacharbeit isolieren und untersuchen, beispielsweise unvollständige Erstbewertungen oder veränderte Anforderungen. Auf dieser Grundlage lassen sich Verschwendung und unnötige Arbeit reduzieren.
Warum das wichtig ist
Quantifiziert die Prozessineffizienz direkt, indem wiederholte Arbeit gekennzeichnet wird. Dadurch lassen sich die Ursachen von Prozessschleifen und unnötigem Aufwand erkennen und beheben.
Bezugsquelle
Wird während der Datentransformation berechnet, indem geprüft wird, ob dieselbe Aktivität oder eine frühere Aktivität im Standardablauf für die betreffende CaseId bereits stattgefunden hat.
Beispiele
truefalse
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut enthält den Timestamp der letzten Datenextraktion. Es handelt sich um ein Metadatenfeld, das entscheidend ist, um die Aktualität der analysierten Daten zu beurteilen. Analysten verwenden diesen Timestamp, um zu bestätigen, dass sie mit aktuellen Informationen arbeiten, und um die Aktualität der Daten einzuordnen. Für operative Dashboards zur Überwachung der laufenden Prozessleistung ist dies besonders wichtig, damit Entscheidungen nicht auf veralteten Daten beruhen.
Warum das wichtig ist
Zeigt die Aktualität der Daten an und stellt sicher, dass Analysen und Dashboards auf aktuellen, relevanten Informationen basieren.
Bezugsquelle
Dieses Metadatenfeld wird während des Datenextraktions- und Transformationsprozesses (ETL) erzeugt und gibt den Zeitpunkt des Datenabrufs an.
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 die Herkunft der Prozessdaten. In diesem Fall wird ServiceNow erwartet. Das Feld ist jedoch auch für Data Governance und Szenarien wichtig, in denen Daten aus mehreren Systemen zusammengeführt werden. In der Analyse sorgt es für eine klare Datenherkunft und unterstützt die Validierung der Datenquelle. Für Unternehmen mit mehreren ITSM-Tools oder integrierten Systemen ermöglicht dieses Attribut, Prozesse über verschiedene Plattformen hinweg zu filtern und zu vergleichen.
Warum das wichtig ist
Stellt eine klare Datenherkunft bereit und dokumentiert, aus welchem System die Prozessdaten stammen. Das ist für Data Governance und Analysen über mehrere Systeme hinweg von großer Bedeutung.
Bezugsquelle
Dies ist typischerweise ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses (ETL) hinzugefügt wird.
Beispiele
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
SLA-Status
SlaState
|
Der Status des Änderungsantrags im Verhältnis zu seinem Service Level Agreement (SLA), zum Beispiel „On Track“, „At Risk“ oder „Breached“. | ||
|
Beschreibung
SLA State zeigt an, ob der Änderungsantrag innerhalb der im SLA festgelegten Zeitvorgaben voranschreitet. Dieser Status lässt sich in jeder Prozessphase verfolgen. Dieses Attribut ist entscheidend für die Überwachung der Einhaltung von Service-Level-Verpflichtungen. Es ist die primäre Datenquelle für das Dashboard „Change SLA Performance Overview“ und den KPI „Change SLA Adherence Rate“. Die Analyse, wo und warum SLAs verletzt werden, hilft der Organisation, systematische Verzögerungen zu beheben und die Planbarkeit der Servicebereitstellung zu verbessern.
Warum das wichtig ist
Liefert eine direkte Messgröße für die Leistung im Verhältnis zu Fristen und ermöglicht die proaktive Überwachung und Analyse von SLA-Verletzungen, um die Servicebereitstellung zu verbessern.
Bezugsquelle
Diese Information kann aus der Tabelle „task_sla“ in ServiceNow stammen, die aufgabenbezogene SLAs, etwa für Änderungsanträge, erfasst, oder anhand von Fälligkeitsfeldern berechnet werden.
Beispiele
Im PlanGefährdetFrist überschritten
|
|||
|
Zugewiesener Benutzer
AssignedToUser
|
Die einzelne Person, die zu einem bestimmten Zeitpunkt für den Change Request verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, die mit der Bearbeitung des Change Requests beauftragt ist. Die Zuordnung kann sich im Lebenszyklus mehrfach ändern, wenn der Request zwischen verschiedenen Phasen und Teams weitergegeben wird. Die Analyse nach Benutzer hilft, die Verteilung der Arbeitslast und die individuelle Leistung zu verstehen sowie Schulungsbedarf zu erkennen. Sie ist außerdem wichtig für die Analyse von Übergaben, insbesondere in Kombination mit der Assignment Group, um die Effizienz der Weitergabe zwischen einzelnen Personen zu beurteilen.
Warum das wichtig ist
Hilft, Arbeitslast und Leistung einzelner Benutzer nachzuverfolgen, und ist entscheidend für die Analyse von Übergabeverzögerungen zwischen verschiedenen Ressourcen.
Bezugsquelle
ServiceNow-Tabelle: change_request, Feld: assigned_to
Beispiele
Beth AnglinDavid LooAbel Tuter
|
|||
Aktivitäten des Change Managements
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Change abgebrochen
|
Der Change Request wurde zu einem Zeitpunkt vor Abschluss der Implementierung zurückgezogen oder abgebrochen. Dies ist ein alternativer Endstatus, der erfasst wird, sobald der Status auf „Canceled“ gesetzt wird. | ||
|
Warum das wichtig ist
Die Analyse abgebrochener Changes kann Ineffizienzen im Prozess aufdecken, etwa unnötig erstellte Requests oder Requests, die zu lange auf eine Genehmigung warten und dadurch veralten.
Bezugsquelle
Abgeleitet daraus, dass das Feld „state“ in der Tabelle change_request auf „Canceled“ gesetzt wird. Der Timestamp stammt aus dem Audit Log dieses Statuswechsels.
Erfassen
Erfassen Sie den Timestamp, sobald das Feld „state“ auf „Canceled“ aktualisiert wird.
Ereignistyp
inferred
|
|||
|
Change eingeplant
|
Dem genehmigten Change wurden ein geplanter Start- und Endtermin zugewiesen. Er steht nun offiziell im Implementierungskalender. Dies wird daraus abgeleitet, dass der Status des Change Requests auf „Scheduled“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität trennt die Planungs- und Genehmigungsphasen von der aktiven Implementierungsphase. Die Verweildauer in diesem Status kann auf Verzögerungen zwischen der Genehmigung und dem Arbeitsbeginn hinweisen.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „state“ in der Tabelle change_request auf „Scheduled“. Der Timestamp stammt aus dem zugehörigen Audit-Log-Eintrag.
Erfassen
Verfolgen Sie Änderungen des Feldes „state“ auf „Scheduled“ in der Audit-Historie der Tabelle change_request.
Ereignistyp
inferred
|
|||
|
Change genehmigt
|
Der Change Request hat alle erforderlichen Genehmigungen erhalten und kann in die Planungs- und Implementierungsphasen übergehen. Dies ist ein entscheidender Meilenstein. Er wird erfasst, sobald die letzte Genehmigung erteilt und das Feld „approval“ auf „approved“ gesetzt wurde. | ||
|
Warum das wichtig ist
Dieser Meilenstein beendet die Genehmigungsphase. Er ist wichtig, um Genehmigungszykluszeiten zu messen und Engpässe im Entscheidungsprozess zu erkennen.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „approval“ in der Tabelle change_request auf „approved“. Der Timestamp stammt aus der Audit-Historie dieser Änderung.
Erfassen
Erfassen Sie den Timestamp, sobald das Feld „approval“ den Wert „approved“ erhält.
Ereignistyp
inferred
|
|||
|
Change geschlossen
|
Der Change Request wurde erfolgreich abgeschlossen und geprüft und gilt nun als beendet. Dies ist der primäre erfolgreiche Endpunkt des Prozesses und wird erfasst, sobald der Status des Changes auf „Closed“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Change-Lebenszyklus. Sie ist das End-Event für die Messung der durchgängigen Prozessdauer und der SLA-Einhaltung.
Bezugsquelle
Abgeleitet daraus, dass das Feld „state“ in der Tabelle change_request auf „Closed“ gesetzt wird. Der Timestamp stammt aus der Audit-Historie dieses abschließenden Statuswechsels.
Erfassen
Erfassen Sie den Timestamp, sobald das Feld „state“ auf „Closed“ aktualisiert wird.
Ereignistyp
inferred
|
|||
|
Change implementiert
|
Die Implementierungsarbeiten sind abgeschlossen. Der Change ist nun bereit für Prüfung, Verifizierung oder Tests. Diese Aktivität wird daraus abgeleitet, dass der Status des Change Requests von „Implement“ auf „Review“ wechselt. | ||
|
Warum das wichtig ist
Dies ist ein entscheidender Meilenstein, der die Implementierungsphase beendet. Das Event ist wichtig für die Berechnung der KPIs „Change Failure Rate“ und „Change Rework Rate“.
Bezugsquelle
Abgeleitet aus einem Statuswechsel von „Implement“ in einen nachfolgenden Status wie „Review“. Der Timestamp stammt aus der Audit-Historie des Feldes „state“ in der Tabelle change_request.
Erfassen
Ermitteln Sie, wann sich das Feld „state“ von „Implement“ auf „Review“ ändert.
Ereignistyp
inferred
|
|||
|
Change Request erstellt
|
Diese Aktivität kennzeichnet die Erstellung eines neuen Change-Request-Datensatzes im System. Sie bildet den offiziellen Start des Change-Management-Prozesses und wird erfasst, sobald ein neuer Eintrag in die Tabelle change_request eingefügt wird. | ||
|
Warum das wichtig ist
Dies ist das primäre Start-Event des Prozesses. Die Analyse der Zeitspanne von dieser Aktivität bis zu anderen Aktivitäten zeigt die gesamte Durchlaufzeit und hilft, Verzögerungen bereits am Prozessanfang zu erkennen.
Bezugsquelle
Dieses Event entspricht dem Timestamp der Datensatzerstellung (sys_created_on) in der ServiceNow-Tabelle change_request.
Erfassen
Verwenden Sie den Timestamp sys_created_on aus der Tabelle change_request.
Ereignistyp
explicit
|
|||
|
Risiko und Auswirkungen bewertet
|
Kennzeichnet den Abschluss der Risiko- und Auswirkungsanalyse für den Change Request. Dies ist ein wichtiger Meilenstein vor der Genehmigung und wird häufig daraus abgeleitet, dass der Change den Status „Assess“ verlässt und in „Authorize“ oder „Awaiting Approval“ wechselt. | ||
|
Warum das wichtig ist
Die Messung der Dauer der Bewertungsphase ist entscheidend für den KPI „Avg. Risk Assessment Cycle Time“. Sie hilft, den Bewertungsprozess zu standardisieren und Bereiche zu erkennen, in denen Analysen zu viel Zeit in Anspruch nehmen.
Bezugsquelle
Abgeleitet aus dem Wechsel des Feldes „state“ in der Tabelle change_request von „Assess“ zu „Authorize“. Der Event-Timestamp wird aus dem Audit Log dieser Statusänderung übernommen.
Erfassen
Ermitteln Sie, wann sich das Feld „state“ von „Assess“ in einen nachfolgenden Status wie „Authorize“ ändert.
Ereignistyp
inferred
|
|||
|
Change abgelehnt
|
Der Change Request wurde von einem Genehmiger oder dem CAB abgelehnt. Diese Aktivität stellt einen Endstatus des Requests dar, sofern er nicht überarbeitet und erneut eingereicht wird. Sie wird erfasst, sobald das Feld „approval“ auf „rejected“ gesetzt wird. | ||
|
Warum das wichtig ist
Die Analyse von Ablehnungen hilft, häufige Ablehnungsgründe wie unvollständige Informationen oder ein hohes Risiko zu erkennen. Dadurch lässt sich die Qualität künftiger Change-Einreichungen verbessern.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „approval“ in der Tabelle change_request auf „rejected“. Der Timestamp wird aus der Audit-Historie übernommen.
Erfassen
Erfassen Sie den Timestamp, sobald das Feld „approval“ den Wert „rejected“ erhält.
Ereignistyp
inferred
|
|||
|
Change erneut geöffnet
|
Der Change Request wurde nach Erreichen einer späteren Phase in einen früheren Status wie „Implement“ oder „Assess“ zurückgesetzt. Dieses Event wird aus einem nicht linearen Statuswechsel abgeleitet und kennzeichnet Nacharbeit. | ||
|
Warum das wichtig ist
Diese Aktivität ist entscheidend, um Nacharbeitsschleifen zu erkennen und die „Change Rework Rate“ zu berechnen. Häufige erneute Öffnungen weisen auf Probleme bei Implementierung, Tests oder Planung hin.
Bezugsquelle
Abgeleitet aus der Analyse der Statuswechsel in der Audit-Historie des Change Requests. Ein Wechsel von einem späteren Status, beispielsweise „Review“, zu einem früheren Status, beispielsweise „Implement“, kennzeichnet ein erneutes Öffnen.
Erfassen
Erkennen Sie einen nicht sequenziellen Rücksprung in der Historie des Feldes „state“.
Ereignistyp
inferred
|
|||
|
Change wartet auf Bewertung
|
Der Change Request wurde eingereicht und wartet nun auf die technische und fachliche Bewertung. Dies wird typischerweise daraus abgeleitet, dass der Status des Change Requests auf „Assess“ oder einen ähnlichen Wert wechselt. Damit hat der Request die Entwurfsphase verlassen. | ||
|
Warum das wichtig ist
Diese Aktivität hilft, die anfängliche Übergabezeit vom Antragsteller an das Bewertungsteam zu messen. Verzögerungen an dieser Stelle können auf Probleme mit der Qualität der Eingangsdaten oder auf fehlende Ressourcen für die Bewertung hinweisen.
Bezugsquelle
Abgeleitet aus einer Änderung des Feldes „state“ in der Tabelle change_request, typischerweise auf den Wert „Assess“. Der Timestamp stammt aus der Audit-Historie (sys_audit) dieser Feldänderung.
Erfassen
Verfolgen Sie Änderungen des Feldes „state“ auf „Assess“ in der Audit-Historie der Tabelle change_request.
Ereignistyp
inferred
|
|||
|
Genehmigung angefordert
|
Diese Aktivität zeigt an, dass der Change Request formell zur Genehmigung eingereicht wurde, typischerweise bei einer Führungskraft oder einem Change Advisory Board (CAB). Das Event wird erfasst, sobald der Genehmigungsstatus des Change Requests auf „requested“ gesetzt wird. | ||
|
Warum das wichtig ist
Damit beginnt der Genehmigungszyklus. Die Messung der Zeit von diesem Event bis zu „Change Approved“ berechnet direkt den KPI „Average Change Approval Time“.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „approval“ in der Tabelle change_request auf „requested“. Der Timestamp wird aus der Tabelle sys_audit für dieses Feld übernommen.
Erfassen
Timestamp, zu dem das Feld „approval“ in der Tabelle change_request auf „requested“ gesetzt wird.
Ereignistyp
inferred
|
|||
|
Implementierung gestartet
|
Die Arbeiten zur Implementierung des Changes haben begonnen. Dies wird erfasst, sobald der Status des Change Requests auf „Implement“ aktualisiert wird. Damit wechselt der Prozess von der Planung in die Ausführung. | ||
|
Warum das wichtig ist
Damit beginnt die praktische Implementierungsarbeit. Dieses Event bildet den Ausgangspunkt für die Messung des KPIs „Average Implementation Duration“ und die Analyse der Teameffizienz.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „state“ in der Tabelle change_request auf „Implement“. Der Timestamp stammt aus dem Audit Log dieses Statuswechsels.
Erfassen
Erfassen Sie den Timestamp des Statuswechsels auf „Implement“ aus der Audit-Historie des Change Requests.
Ereignistyp
inferred
|
|||
|
Prüfung läuft
|
Eine Prüfung nach der Implementierung (PIR) wird durchgeführt, um festzustellen, ob der Change erfolgreich war und seine Ziele erreicht hat. Dies wird erfasst, sobald der Status des Change Requests auf „Review“ gesetzt wird. | ||
|
Warum das wichtig ist
Die Analyse der Dauer der Prüfungsphase hilft, Verzögerungen bei der Validierung des Change-Erfolgs zu erkennen. Sie macht außerdem nicht konforme Changes sichtbar, bei denen dieser Schritt übersprungen wird.
Bezugsquelle
Abgeleitet aus der Änderung des Feldes „state“ in der Tabelle change_request auf „Review“. Der Timestamp stammt aus dem Audit Log dieses Statuswechsels.
Erfassen
Erfassen Sie den Timestamp des Statuswechsels auf „Review“ aus der Audit-Historie des Change Requests.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Bereit für den Start?
Verwenden Sie dieses Template, um Ihre Daten vorzubereiten und Erkenntnisse über Ihren Änderungsmanagementprozess in ServiceNow zu gewinnen. Beginnen Sie noch heute mit der Optimierung für maximale Effizienz.
Stoppen Sie fehlgeschlagene Änderungen und steigern Sie jetzt Ihren ServiceNow-Erfolg!
Lokalisieren Sie Engpässe und erreichen Sie mühelos eine Erfolgsquote von 95 % bei Änderungen.
Keine Kreditkarte erforderlich, Einrichtung in wenigen Minuten.