Ihr Daten-Template für das Änderungsmanagement
Ihr Daten-Template für das Änderungsmanagement
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für eine präzise Prozesserkennung
- Anleitung zur Datenextraktion aus ServiceNow
Attribute des Änderungsmanagements
| Name | Beschreibung | ||
|---|---|---|---|
|
Change-Request-ID
ChangeRequestNumber
|
Die eindeutige Kennung eines Change Requests. Sie dient als primäre Case-ID, um alle zugehörigen Events zusammenzufassen. | ||
|
Beschreibung
Die Change-Request-ID ist die Grundlage für die Analyse des Change-Management-Prozesses. Sie ist eine eindeutige Nummer, die jedem Change Request zugewiesen wird, zum Beispiel „CHG0030001“, und alle zugehörigen Aktivitäten, Freigaben und Tasks miteinander verknüpft. Beim Process Mining dient dieses Attribut dazu, den gesamten Ablauf jedes einzelnen Changes zu rekonstruieren. Analysten können damit den vollständigen Lebenszyklus von der Erstellung bis zum Abschluss verfolgen und nachvollziehen, wie jeder Change das System durchläuft. Die Gruppierung nach dieser ID ist entscheidend, um Zykluszeiten zu berechnen, Nacharbeitsschleifen zu erkennen und Prozessvarianten zu verstehen.
Warum das wichtig ist
Diese ID ist unverzichtbar, um den gesamten Lebenszyklus eines Changes zu verfolgen und Prozessablauf, Dauer und Compliance für jeden Antrag vollständig zu analysieren.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: number
Beispiele
CHG0030001CHG0030045CHG0030112
|
|||
|
Event-Zeitpunkt
EventTime
|
Der genaue Timestamp, zu dem eine bestimmte Aktivität oder ein Event stattgefunden hat. | ||
|
Beschreibung
Der Event-Zeitpunkt erfasst Datum und Uhrzeit, zu denen eine Aktivität ausgeführt oder eine Statusänderung registriert wurde. Dieser Timestamp ist entscheidend, um Events chronologisch zu ordnen und Zeitspannen zu analysieren. Beim Process Mining ermöglicht dieses Attribut die Berechnung von Zyklus-, Verarbeitungs- und Wartezeiten zwischen Aktivitäten. Es ist eine wichtige Grundlage für Dashboards zur Leistungsanalyse, etwa zur Zykluszeit für Change-Freigaben und zum durchgängigen Ablauf des Change-Prozesses. Genaue Timestamps helfen, Verzögerungen zu erkennen und die Prozesseffizienz anhand von SLAs zu messen.
Warum das wichtig ist
Dieser Timestamp ist entscheidend, um Events korrekt zu ordnen und alle zeitbasierten Kennzahlen zu berechnen, darunter Zykluszeiten, Zeitspannen und die Einhaltung von SLAs.
Woher beziehen
ServiceNow-Tabelle: sys_audit, Feld: sys_created_on. Dieses Feld enthält 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 im Change-Management-Prozess. | ||
|
Beschreibung
Der Aktivitätsname bezeichnet einen einzelnen Schritt oder eine Statusänderung im Lebenszyklus eines Change Requests. Beispiele sind „Change wartet auf Bewertung“, „Freigabe angefordert“ und „Change implementiert“. Diese Aktivitäten bilden die Knoten in der ermittelten Prozesslandkarte. Die Analyse dieser Aktivitäten ermöglicht eine detaillierte Untersuchung des Prozessablaufs. Wenn Unternehmen die Abfolge und Häufigkeit der Aktivitäten verfolgen, können sie häufige Abläufe, Abweichungen vom Standardprozess und Engpässe erkennen, an denen Changes oft ins Stocken geraten. Das ist eine wichtige Grundlage, um den Prozess zu visualisieren und Kennzahlen wie die Übergangszeiten zwischen einzelnen Schritten zu berechnen.
Warum das wichtig ist
Der Aktivitätsname bildet die Grundlage der Prozesslandkarte. Er ermöglicht die Visualisierung des Prozessablaufs, das Erkennen von Engpässen und die Analyse von Abweichungen.
Woher beziehen
Abgeleitet aus Änderungen des Felds „state“ oder anderer wichtiger Statusfelder in der Tabelle „change_request“, die häufig in der Tabelle „sys_audit“ erfasst werden.
Beispiele
Change freigegebenImplementierung gestartetChange abgeschlossenChange abgebrochen
|
|||
|
Change-Status
ChangeState
|
Der aktuelle oder historische Status des Change Requests, zum Beispiel „Assess“, „Authorize“, „Implement“ oder „Closed“. | ||
|
Beschreibung
Das Attribut Change-Status gibt an, welchen Status ein Change Request zu einem bestimmten Zeitpunkt hat. Es fasst auf hoher Ebene zusammen, an welcher Stelle seines Lebenszyklus sich der Change befindet. Anders als die Aktivität, die ein bestimmtes Event bezeichnet, beschreibt der Status den Zustand, der sich aus diesem Event ergibt. Bei der Analyse dient der Change-Status dazu, Cases zu kategorisieren und ihre Ergebnisse zu verstehen. Er ist eine wichtige Grundlage, um Changes zu filtern, beispielsweise um nur abgeschlossene Changes zu analysieren oder zu untersuchen, warum viele Changes im Status „Authorize“ feststecken. Wenn ein Status „Failed“ vorhanden ist, unterstützt er direkt die KPI „Change Failure Rate“.
Warum das wichtig ist
Zeigt den Status des Change Requests zu einem bestimmten Zeitpunkt. So lassen sich Ergebnisse analysieren, Cases filtern und festgefahrene Changes erkennen.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: state
Beispiele
BewertungAutorisierungEingeplantImplementierungPrüfungAbgeschlossenAbgebrochen
|
|||
|
Change-Typ
ChangeType
|
Die Klassifizierung des Changes, zum Beispiel „Standard“, „Normal“ oder „Emergency“. | ||
|
Beschreibung
Der Change-Typ kategorisiert den Change Request nach Art, Risiko und erforderlichen Freigaben. Standard-Changes sind vorab freigegeben, normale Changes durchlaufen den vollständigen Prozess und Emergency Changes folgen einem beschleunigten Ablauf. Der Change-Typ ist eine grundlegende Dimension der Prozessanalyse, da für die verschiedenen Typen unterschiedliche, zulässige Prozessmodelle gelten. Ein Vergleich normaler und dringender Changes kann wichtige Erkenntnisse zur Prozesseinhaltung und Effizienz liefern. Das Attribut wird auch in Dashboards wie „Standardisierung der Risikobewertung“ verwendet, um sicherzustellen, dass ähnliche Changes einheitlich behandelt werden.
Warum das wichtig ist
Ermöglicht eine differenzierte Analyse, da für verschiedene Change-Typen unterschiedliche freigegebene Prozessabläufe und Leistungserwartungen gelten.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: type
Beispiele
StandardNormalNotfall
|
|||
|
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. Quellsysteme erfassen häufig den Beginn eines Events, während die Endzeit oft abgeleitet wird. Üblicherweise entspricht sie dem Timestamp der nächsten Aktivität desselben Cases. Dieses Attribut ist wichtig, um die Dauer jeder Aktivität, also ihre Verarbeitungszeit, zu berechnen. Die Dauer einzelner Schritte zu kennen, ist eine wichtige Grundlage, um Engpässe und Ineffizienzen im Prozess zu erkennen. Bei der letzten Aktivität eines Cases entspricht die Endzeit der Startzeit.
Warum das wichtig ist
Ermöglicht die Berechnung der Verarbeitungszeit von Aktivitäten. Das ist wichtig, um Engpässe zu erkennen und die Dauer einzelner Prozessschritte zu messen.
Woher beziehen
Dieses Attribut wird üblicherweise bei der Datentransformation berechnet. Dazu wird die StartTime des nächsten Events desselben CaseId herangezogen.
Beispiele
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Konfigurationselement
ConfigurationItem
|
Die konkrete IT-Komponente, der Service oder das System, auf das sich der Change bezieht. | ||
|
Beschreibung
Das Konfigurationselement (CI) ist das Asset aus der Configuration Management Database (CMDB), das vom 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. Beim Process Mining ermöglicht es, die Analyse nach Art des betroffenen Assets aufzuschlüsseln. Das Dashboard „Analyse der Testdauer von Changes“ nutzt das Attribut beispielsweise, um Testzeiten verschiedener Anwendungen oder Systeme zu vergleichen und CIs zu erkennen, die mit längeren Testzyklen verbunden sind.
Warum das wichtig ist
Liefert wichtigen fachlichen Kontext. Die Analyse lässt sich nach betroffener Anwendung, betroffenem Service oder System filtern, um komponentenspezifische Probleme zu erkennen.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: cmdb_ci
Beispiele
SAP ERPOracle Database 19cE-Mail-ServiceWebserver-01
|
|||
|
Priorität
Priority
|
Die Prioritätsstufe des Change Requests, die sich aus seinen Auswirkungen und seiner Dringlichkeit ergibt. | ||
|
Beschreibung
Die Priorität gibt an, wie wichtig ein Change Request ist, und bestimmt, in welcher Reihenfolge er bearbeitet werden sollte. Sie wird häufig aus den Auswirkungen und der Dringlichkeit des Changes abgeleitet. Mögliche Werte sind „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“. Die Analyse nach Priorität ist wichtig, damit Changes mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. Das Dashboard „Leistung kritischer Changes“ ermöglicht es Analysten, Zykluszeiten und Ausfallraten für besonders wichtige Changes gezielt zu verfolgen. Werden Changes mit niedriger Priorität schneller abgeschlossen als solche mit hoher Priorität, kann das auf Probleme bei der Ressourcenzuweisung oder der Prozessausführung hinweisen.
Warum das wichtig ist
Wichtig, um zu prüfen, ob Ressourcen den kritischsten Changes angemessen zugewiesen sind, und deren Leistung gesondert zu überwachen.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: priority
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
|
|||
|
Risikostufe
RiskLevel
|
Die bewertete Risikostufe des Changes, zum Beispiel „Hoch“, „Mittel“ oder „Niedrig“. | ||
|
Beschreibung
Die Risikostufe ist das Ergebnis der Risikobewertung eines Change Requests. Sie beziffert mögliche negative Folgen der Implementierung und hilft, den erforderlichen Prüf- und Freigabeumfang festzulegen. Dieses Attribut ist wichtig für das Dashboard „Standardisierung der Risikobewertung“. Damit lässt sich prüfen, ob ähnliche Changes einheitlich eingestuft werden. Die Analyse von Prozessabläufen nach Risikostufe kann außerdem zeigen, ob Changes mit hohem Risiko den strengeren Freigabe- und Testprozess durchlaufen, der für sie vorgesehen ist. Das ist eine wichtige Compliance-Prüfung.
Warum das wichtig ist
Wichtig für die Compliance-Analyse und um sicherzustellen, dass Changes mit hohem Risiko angemessen geprüft werden und einen strengeren Prozess durchlaufen.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: risk
Beispiele
HochMittelNiedrig
|
|||
|
Zuweisungsgruppe
AssignmentGroup
|
Das Team oder die Gruppe, das beziehungsweise die für den Change Request verantwortlich ist. | ||
|
Beschreibung
Die Zuweisungsgruppe gibt an, welches Team aktuell für den Change Request verantwortlich ist, zum Beispiel „CAB Approval“, „Network Engineering“ oder „Database Administrators“. Sie ist eine wichtige Dimension für die Analyse der Prozessleistung in verschiedenen Fachbereichen. Mit diesem Attribut lässt sich die Effizienz auf Teamebene messen, lassen sich gruppenspezifische Engpässe erkennen und Übergaben zwischen Teams analysieren. Dashboards wie „Effizienz fachbereichsübergreifender Übergaben“ und „Durchsatz der Change-Implementierung“ stützen sich maßgeblich auf diese Daten, um Verzögerungen durch Abhängigkeiten zwischen Teams aufzudecken.
Warum das wichtig ist
Ermöglicht die Leistungsanalyse nach Teams. So werden gruppenspezifische Engpässe sichtbar und die Effizienz von Übergaben zwischen Fachbereichen lässt sich messen.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: assignment_group
Beispiele
CAB-FreigabeNetzwerkteamServer-SupportDatenbankadministration
|
|||
|
Abschlusscode
CloseCode
|
Ein Code, der das Ergebnis beim Schließen einer Änderungsanforderung angibt, zum Beispiel „Erfolgreich“ oder „Nicht erfolgreich“. | ||
|
Beschreibung
Der Abschlusscode dokumentiert das endgültige Ergebnis einer abgeschlossenen Änderungsanforderung. Er hält formell fest, ob die Änderung erfolgreich umgesetzt wurde, Probleme auftraten oder sie zurückgesetzt wurde. Dieses Attribut fließt direkt in die KPI „Fehlerquote bei Änderungen“ ein. Anhand der Verteilung der Abschlusscodes können Organisationen den Erfolg ihrer Änderungsinitiativen quantifizieren. Wenn Sie die Prozessübersicht nach Änderungen mit dem Abschlusscode „Nicht erfolgreich“ filtern, können Sie die Ursachen gezielt untersuchen. Dabei werden wiederkehrende Prozessmuster sichtbar, die zum Scheitern führen.
Warum das wichtig ist
Misst direkt das Ergebnis einer Änderung und liefert die wichtigsten Daten zur Berechnung der Fehlerquote sowie zur Analyse der Ursachen fehlgeschlagener Änderungen.
Woher beziehen
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 beispielsweise als hoch, mittel oder niedrig. | ||
|
Beschreibung
Die Auswirkungen geben an, welche Folgen es für das Unternehmen haben könnte, wenn der Change Request nicht korrekt bearbeitet wird. Zusammen mit der Dringlichkeit sind sie eine wichtige Grundlage für die Gesamtpriorität des Changes. Die Analyse nach Auswirkungen hilft sicherzustellen, dass Changes mit Folgen für kritische Services angemessen behandelt werden. Im Dashboard „Leistung kritischer Changes“ lassen sich Changes mit erheblichen geschäftlichen Auswirkungen gezielt herausfiltern und überwachen. Außerdem kann geprüft werden, ob die Risikobewertung einheitlich erfolgt und Changes mit großen Auswirkungen nicht ohne Begründung als geringes Risiko eingestuft werden.
Warum das wichtig ist
Hilft, Changes nach ihren möglichen geschäftlichen Auswirkungen zu priorisieren und zu prüfen, ob Changes mit großen Auswirkungen mit der gebotenen Sorgfalt behandelt werden.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: impact
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Dringlichkeit
Urgency
|
Die Geschwindigkeit, mit der eine Änderung umgesetzt werden muss, bewertet beispielsweise als Hoch, Mittel oder Niedrig. | ||
|
Beschreibung
Die Dringlichkeit gibt an, wie schnell eine Änderung umgesetzt werden muss. Sie spiegelt die zeitliche Sensibilität der Anfrage aus geschäftlicher Sicht wider. Zusammen mit den Auswirkungen wird daraus die Gesamtpriorität berechnet. Für die Analyse ist die Priorität das wichtigste Feld. Die Dringlichkeit liefert zusätzlichen Kontext. Anhand dieses Attributs lässt sich untersuchen, warum bestimmte Änderungen als dringend eingestuft werden und ob der Prozess sie wirksam bewältigt, ohne die Stabilität zu gefährden. So können Sie feststellen, ob die Organisation zu häufig unter hohem Zeitdruck reagieren muss.
Warum das wichtig ist
Liefert Kontext zur zeitlichen Sensibilität einer Änderung und hilft zu analysieren, ob der Prozess zeitkritische Anfragen wirksam bearbeitet.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: urgency
Beispiele
1 - Hoch2 - Mittel3 - Niedrig
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Kennzeichen, das den Wert „wahr“ hat, wenn eine Aktivität einen bereits ausgeführten Schritt desselben Cases wiederholt. | ||
|
Beschreibung
Dieses berechnete Attribut kennzeichnet Aktivitäten, bei denen Nacharbeit anfällt. Nacharbeit entsteht, wenn der Prozess zu einem bereits abgeschlossenen Schritt zurückkehren muss, etwa wenn eine Änderung nach der Freigabe abgelehnt und zur erneuten Bewertung zurückgesendet wird. Das Kennzeichen ist entscheidend, um Ineffizienzen im Prozess zu quantifizieren. Es fließt direkt in die KPI „Nacharbeitsquote bei Änderungen“ und das Dashboard „Analyse von Fehlern und Nacharbeit bei Änderungen“ ein. Filtern Analysten nach Aktivitäten, bei denen „Ist Nacharbeit“ den Wert „wahr“ hat, können sie die Ursachen gezielt untersuchen. Dazu zählen etwa unvollständige Erstbewertungen oder geänderte Anforderungen. Auf dieser Grundlage lassen sich unnötige Aufwände reduzieren.
Warum das wichtig ist
Quantifiziert Prozessineffizienzen direkt, indem wiederholte Arbeit gekennzeichnet wird. So lassen sich die Ursachen von Prozessschleifen und unnötigem Aufwand erkennen und beheben.
Woher beziehen
Wird bei der Datentransformation berechnet. Dabei wird geprüft, ob dieselbe Aktivität oder eine frühere Aktivität im Standardablauf für die jeweilige 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. Als Metadatenfeld ist es wichtig, um die Aktualität der analysierten Daten einzuschätzen. Analysten prüfen damit, ob sie mit aktuellen Informationen arbeiten, und können nachvollziehen, wie neu die Daten sind. Für operative Dashboards zur laufenden Prozessleistung ist dieser Timestamp besonders wichtig. So beruhen Entscheidungen nicht auf veralteten Daten.
Warum das wichtig ist
Zeigt an, wie aktuell die Daten sind, und stellt sicher, dass Analysen und Dashboards auf relevanten Informationen beruhen.
Woher beziehen
Dieses Metadatenfeld wird während der Datenextraktion und -transformation (ETL) erstellt 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, in der Regel „ServiceNow“. | ||
|
Beschreibung
Dieses Attribut gibt an, aus welchem System die Prozessdaten stammen. In diesem Fall wird ServiceNow erwartet. Das Feld ist wichtig für die Data Governance und für Szenarien, in denen Daten aus mehreren Systemen zusammengeführt werden. Bei der Analyse sorgt es für eine nachvollziehbare Datenherkunft und erleichtert die Prüfung der Datenquelle. Unternehmen mit mehreren ITSM-Tools oder integrierten Systemen können damit Prozesse verschiedener Plattformen filtern und vergleichen.
Warum das wichtig ist
Dokumentiert die Herkunft der Prozessdaten nachvollziehbar. Das ist wichtig für die Data Governance und die Analyse von Daten aus mehreren Systemen.
Woher beziehen
In der Regel handelt es sich um einen statischen Wert, der während der Datenextraktion und -transformation (ETL) hinzugefügt wird.
Beispiele
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
SLA-Status
SlaState
|
Der Status der Änderungsanforderung im Verhältnis zu ihrem Service Level Agreement (SLA), zum Beispiel „Im Plan“, „Gefährdet“ oder „Frist überschritten“. | ||
|
Beschreibung
Der SLA-Status zeigt an, ob die Änderungsanforderung innerhalb der im SLA festgelegten Fristen vorankommt. Dieser Status lässt sich in jeder Prozessphase verfolgen. Das Attribut ist wichtig, um die Einhaltung von Service-Level-Zusagen zu überwachen. Es ist die zentrale Datenquelle für das Dashboard „Übersicht der SLA-Leistung bei Änderungen“ und die KPI „Einhaltungsquote der SLAs bei Änderungen“. Wenn Sie analysieren, wo und warum SLAs nicht eingehalten werden, kann die Organisation systembedingte Verzögerungen beheben und die Vorhersagbarkeit der Servicebereitstellung verbessern.
Warum das wichtig ist
Misst direkt die Leistung im Verhältnis zu Fristen. So lassen sich SLA-Verstöße proaktiv überwachen und analysieren, um die Servicebereitstellung zu verbessern.
Woher beziehen
Die Daten können aus der ServiceNow-Tabelle „task_sla“ stammen, in der SLAs zu Aufgaben wie Änderungsanforderungen erfasst werden. Alternativ lässt sich der Status anhand von Fälligkeitsfeldern berechnen.
Beispiele
Im PlanGefährdetFrist überschritten
|
|||
|
Zugewiesener Benutzer
AssignedToUser
|
Der Benutzer, der zu einem bestimmten Zeitpunkt für den Change Request verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Benutzer mit der Bearbeitung des Change Requests betraut ist. Die Zuweisung kann sich im Laufe des Lebenszyklus mehrfach ändern, wenn der Antrag verschiedene Phasen und Teams durchläuft. Die Analyse nach Benutzern hilft, die Arbeitslastverteilung und die individuelle Leistung zu verstehen sowie Schulungsbedarf zu erkennen. In Verbindung mit der Zuweisungsgruppe ist das Attribut auch wichtig, um Übergaben zu analysieren und zu prüfen, wie effizient Aufgaben zwischen Benutzern weitergegeben werden.
Warum das wichtig ist
Hilft, Arbeitslast und Leistung einzelner Benutzer nachzuverfolgen und Verzögerungen bei Übergaben zwischen verschiedenen Mitarbeitenden zu analysieren.
Woher beziehen
ServiceNow-Tabelle: change_request, Feld: assigned_to
Beispiele
Beth AnglinDavid LooAbel Tuter
|
|||
|
Zykluszeit
CycleTime
|
Die gesamte Zeitspanne von der Erstellung bis zum Abschluss einer Änderungsanforderung. | ||
|
Beschreibung
Die Zykluszeit ist eine Kennzahl auf Case-Ebene. Sie misst die Gesamtdauer des Lebenszyklus einer Änderungsanforderung und ergibt sich aus der Differenz zwischen dem Timestamp des ersten und dem des letzten Ereignisses für die jeweilige Änderungsanforderung. Diese wichtige KPI misst die Geschwindigkeit des Gesamtprozesses. Im Dashboard „End-to-End-Ablauf des Änderungsprozesses“ bietet sie einen Überblick über die Prozessleistung. Wenn Sie Trends bei der Zykluszeit analysieren und nach Dimensionen wie Änderungstyp oder Priorität vergleichen, erkennen Sie Möglichkeiten für gezielte Prozessverbesserungen.
Warum das wichtig ist
Misst die Gesamtdauer des Änderungsprozesses und dient als wichtige Kennzahl für die Geschwindigkeit und Effizienz des Gesamtprozesses.
Woher beziehen
Wird bei der Datenanalyse auf Case-Ebene berechnet, indem für jede CaseId der minimale StartTime-Wert vom maximalen StartTime-Wert abgezogen wird.
Beispiele
60480012096002592000
|
|||
Aktivitäten des Änderungsmanagements
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Change abgebrochen
|
Der Change Request wurde zurückgezogen oder abgebrochen, bevor die Implementierung abgeschlossen war. Dieser alternative Endstatus wird erfasst, wenn das Feld „state“ auf „Canceled“ gesetzt wird. | ||
|
Warum das wichtig ist
Die Analyse abgebrochener Changes kann Ineffizienzen im Prozess aufdecken. Dazu zählen unnötig erstellte Anträge oder Vorgänge, die so lange auf eine Freigabe warten, dass sie hinfällig werden.
Woher beziehen
Wird erkannt, wenn das Feld „state“ in der Tabelle change_request auf „Canceled“ gesetzt wird. Der Timestamp stammt aus dem Audit-Log dieser Statusänderung.
Erfassung
Erfassen Sie den Timestamp, zu dem das Feld „state“ auf „Canceled“ gesetzt wird.
Ereignistyp
inferred
|
|||
|
Change abgeschlossen
|
Der Change Request wurde erfolgreich umgesetzt und geprüft und gilt nun als abgeschlossen. Dies ist der reguläre Endpunkt des Prozesses. Er wird erfasst, wenn der Status des Changes zu „Closed“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Change-Lebenszyklus. Sie ist das End-Event zur Messung der gesamten Prozessdauer und der Einhaltung von SLAs.
Woher beziehen
Wird erkannt, wenn das Feld „state“ in der Tabelle change_request auf „Closed“ gesetzt wird. Der Timestamp stammt aus der Änderungshistorie dieses abschließenden Statuswechsels.
Erfassung
Erfassen Sie den Timestamp, zu dem das Feld „state“ auf „Closed“ gesetzt wird.
Ereignistyp
inferred
|
|||
|
Change eingeplant
|
Für den freigegebenen Change wurden ein geplanter Start- und Endtermin festgelegt. Er steht nun offiziell im Implementierungskalender. Dieser Status wird daran erkannt, dass der Status des Change Requests zu „Scheduled“ wechselt. | ||
|
Warum das wichtig ist
Diese Aktivität trennt die Planungs- und Freigabephasen von der aktiven Implementierung. Die Verweildauer in diesem Status kann auf Verzögerungen zwischen der Freigabe und dem Arbeitsbeginn hinweisen.
Woher beziehen
Wird erkannt, wenn sich das Feld „state“ in der Tabelle change_request auf „Scheduled“ ändert. Der Timestamp stammt aus dem entsprechenden Eintrag im Audit-Log.
Erfassung
Erfassen Sie Änderungen des Felds „state“ auf „Scheduled“ in der Änderungshistorie der Tabelle change_request.
Ereignistyp
inferred
|
|||
|
Change freigegeben
|
Der Change Request hat alle erforderlichen Freigaben erhalten und kann in die Planungs- und Implementierungsphase übergehen. Dieser wichtige Meilenstein wird erfasst, sobald die letzte Freigabe erteilt und das Feld „approval“ auf „approved“ gesetzt wird. | ||
|
Warum das wichtig ist
Mit diesem Meilenstein endet die Freigabephase. Er ist wichtig, um Freigabezyklen zu messen und Engpässe im Entscheidungsprozess zu erkennen.
Woher beziehen
Wird erkannt, wenn sich das Feld „approval“ in der Tabelle change_request auf „approved“ ändert. Der Timestamp stammt aus der Änderungshistorie dieses Felds.
Erfassung
Erfassen Sie den Timestamp, zu dem das Feld „approval“ den Wert „approved“ erhält.
Ereignistyp
inferred
|
|||
|
Change implementiert
|
Die Implementierung ist abgeschlossen. Der Change kann nun geprüft, verifiziert oder getestet werden. Diese Aktivität wird daran erkannt, dass der Status des Change Requests von „Implement“ zu „Review“ wechselt. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein schließt die Implementierungsphase ab. Er ist eine zentrale Grundlage für die KPIs „Change Failure Rate“ und „Change Rework Rate“.
Woher beziehen
Wird erkannt, wenn der Status von „Implement“ zu einem nachfolgenden Status wie „Review“ wechselt. Der Timestamp stammt aus der Änderungshistorie des Felds „state“ in der Tabelle change_request.
Erfassung
Ermitteln Sie, wann sich das Feld „state“ von „Implement“ zu „Review“ ändert.
Ereignistyp
inferred
|
|||
|
Change Request erstellt
|
Diese Aktivität kennzeichnet die Erstellung eines neuen Change-Request-Datensatzes im System. Sie ist der offizielle 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 Zeitspanne von dieser Aktivität bis zu anderen Aktivitäten zeigt die gesamte Durchlaufzeit und hilft, Verzögerungen gleich zu Prozessbeginn zu erkennen.
Woher beziehen
Dieses Event entspricht dem Erstellungszeitpunkt des Datensatzes (sys_created_on) in der ServiceNow-Tabelle change_request.
Erfassung
Verwenden Sie den Timestamp sys_created_on aus der Tabelle change_request.
Ereignistyp
explicit
|
|||
|
Risiko und Auswirkungen bewertet
|
Diese Aktivität kennzeichnet den Abschluss der Risiko- und Auswirkungsanalyse für den Change Request. Sie ist ein wichtiger Meilenstein vor der Freigabe. Häufig wird sie daran erkannt, dass der Change den Status „Assess“ verlässt und zu „Authorize“ oder „Awaiting Approval“ wechselt. | ||
|
Warum das wichtig ist
Die Dauer der Bewertungsphase ist eine wichtige Grundlage für die KPI „Durchschnittliche Zykluszeit der Risikobewertung“. Sie hilft, den Bewertungsprozess zu standardisieren und zu erkennen, an welchen Stellen Analysen zu lange dauern.
Woher beziehen
Wird erkannt, wenn das Feld „state“ in der Tabelle change_request von „Assess“ zu „Authorize“ wechselt. Der Timestamp des Events stammt aus dem Audit-Log dieser Statusänderung.
Erfassung
Ermitteln Sie, wann sich das Feld „state“ von „Assess“ zu einem nachfolgenden Status wie „Authorize“ ändert.
Ereignistyp
inferred
|
|||
|
Change abgelehnt
|
Eine freigabeberechtigte Person oder das CAB hat den Change Request abgelehnt. Damit ist der Vorgang abgeschlossen, sofern der Antrag nicht überarbeitet und erneut eingereicht wird. Das Event wird erfasst, wenn das Feld „approval“ auf „rejected“ gesetzt wird. | ||
|
Warum das wichtig ist
Die Erfassung von Ablehnungen hilft, häufige Gründe dafür zu erkennen, etwa unvollständige Angaben oder ein hohes Risiko. Diese Erkenntnisse können die Qualität künftiger Change-Anträge verbessern.
Woher beziehen
Wird erkannt, wenn sich das Feld „approval“ in der Tabelle change_request auf „rejected“ ändert. Der Timestamp stammt aus der Änderungshistorie.
Erfassung
Erfassen Sie den Timestamp, zu dem das Feld „approval“ den Wert „rejected“ erhält.
Ereignistyp
inferred
|
|||
|
Change erneut geöffnet
|
Der Change Request wurde nach Erreichen einer späteren Phase auf einen früheren Status zurückgesetzt, etwa auf „Implement“ oder „Assess“. Dieses Event wird anhand eines nicht linearen Statuswechsels erkannt und weist auf Nacharbeit hin. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um Nacharbeitsschleifen zu erkennen und die „Change Rework Rate“ zu berechnen. Häufiges erneutes Öffnen weist auf Probleme bei der Implementierungsqualität, beim Testen oder bei der Planung hin.
Woher beziehen
Wird durch die Analyse der Statusänderungen in der Änderungshistorie des Change Requests erkannt. Ein Wechsel von einem späteren Status (z. B. „Review“) zu einem früheren Status (z. B. „Implement“) kennzeichnet ein erneutes Öffnen.
Erfassung
Erkennen Sie in der Historie des Felds „state“ einen nicht sequenziellen Wechsel zu einem früheren Status.
Ereignistyp
inferred
|
|||
|
Change wartet auf Bewertung
|
Der Change Request wurde eingereicht und wartet nun auf eine technische und fachliche Bewertung. Dieser Status wird in der Regel daran erkannt, dass der Status des Change Requests zu „Assess“ oder einem ähnlichen Wert wechselt. Damit ist der Entwurf abgeschlossen. | ||
|
Warum das wichtig ist
Mit dieser Aktivität lässt sich die erste Übergabezeit vom Antragsteller an das Bewertungsteam messen. Verzögerungen können auf eine unzureichende Datenqualität zu Beginn oder fehlende Kapazitäten für die Bewertung hinweisen.
Woher beziehen
Wird anhand einer Änderung des Felds „state“ in der Tabelle change_request erkannt, üblicherweise auf einen Wert wie „Assess“. Der Timestamp stammt aus der Änderungshistorie (sys_audit) dieses Felds.
Erfassung
Erfassen Sie Änderungen des Felds „state“ auf „Assess“ in der Änderungshistorie der Tabelle change_request.
Ereignistyp
inferred
|
|||
|
Freigabe angefordert
|
Diese Aktivität zeigt an, dass der Change Request formell zur Freigabe eingereicht wurde, üblicherweise bei einer Führungskraft oder einem Change Advisory Board (CAB). Das Event wird erfasst, wenn der Freigabestatus des Change Requests auf „requested“ gesetzt wird. | ||
|
Warum das wichtig ist
Damit beginnt der Freigabezyklus. Die Zeitspanne von diesem Event bis zu „Change freigegeben“ ergibt direkt die KPI „Durchschnittliche Freigabezeit für Changes“.
Woher beziehen
Wird erkannt, wenn sich das Feld „approval“ in der Tabelle change_request auf „requested“ ändert. Der Timestamp wird für dieses Feld aus der Tabelle sys_audit ermittelt.
Erfassung
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. Das Event wird erfasst, wenn der Status des Change Requests auf „Implement“ gesetzt wird. Damit geht der Vorgang von der Planung in die Umsetzung über. | ||
|
Warum das wichtig ist
Damit beginnt die praktische Umsetzung. Dieses Event ist der Ausgangspunkt für die KPI „Durchschnittliche Implementierungsdauer“ und für die Analyse der Teameffizienz.
Woher beziehen
Wird erkannt, wenn sich das Feld „state“ in der Tabelle change_request auf „Implement“ ändert. Der Timestamp stammt aus dem Audit-Log dieses Statuswechsels.
Erfassung
Erfassen Sie den Timestamp der Statusänderung auf „Implement“ aus der Änderungshistorie des Change Requests.
Ereignistyp
inferred
|
|||
|
Prüfung läuft
|
Nach der Implementierung findet eine Prüfung (PIR) statt, um festzustellen, ob der Change erfolgreich war und seine Ziele erreicht hat. Das Event wird erfasst, wenn 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 Bewertung des Change-Erfolgs zu erkennen. Sie zeigt auch nicht konforme Changes auf, bei denen dieser Schritt ausgelassen wird.
Woher beziehen
Wird erkannt, wenn sich das Feld „state“ in der Tabelle change_request auf „Review“ ändert. Der Timestamp stammt aus dem Audit-Log dieser Statusänderung.
Erfassung
Erfassen Sie den Timestamp der Statusänderung auf „Review“ aus der Änderungshistorie des Change Requests.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie jetzt starten?
Bereiten Sie Ihre Daten mit diesem Template vor und gewinnen Sie Erkenntnisse zu Ihrem Änderungsmanagementprozess in ServiceNow. Beginnen Sie noch heute mit der Optimierung Ihrer Prozesseffizienz.
Verhindern Sie fehlgeschlagene Änderungen und verbessern Sie jetzt Ihre Ergebnisse mit ServiceNow!
Ermitteln Sie Engpässe und erreichen Sie mühelos eine Erfolgsquote von 95 % bei Änderungen.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.