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 die Nachverfolgung
- Hinweise zur Datenextraktion aus Ivanti Cherwell
Attribute des Änderungsmanagements
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Name des konkreten Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Änderungsmanagementprozess stattgefunden hat. | ||
|
Beschreibung
Der Aktivitätsname bezeichnet einen bestimmten Schritt oder Meilenstein im Lebenszyklus eines Change Requests, zum Beispiel 'Change Submitted For Assessment' oder 'Change Approved by CAB'. Diese Aktivitäten bilden die Knoten in der ermittelten Prozessübersicht. In der Analyse dient dieses Attribut dazu, den Prozessfluss zu visualisieren, die Ereignisabfolge zu erkennen und Abweichungen von der Standardvorgehensweise aufzudecken. Es wird verwendet, um Übergangszeiten zwischen Aktivitäten zu berechnen und Verzögerungen zu lokalisieren.
Warum das wichtig ist
Dieses Attribut ist entscheidend, um den tatsächlichen Prozessfluss zu ermitteln und darzustellen. So lassen sich Engpässe, Nacharbeitsschleifen und nicht konforme Prozesspfade erkennen.
Woher beziehen
Erzeugt aus Statusänderungen, Journaleinträgen oder spezifischen Ereignisprotokollen zum Change-Request-Objekt in Ivanti Cherwell.
Beispiele
Änderung zur Bewertung eingereichtGenehmigung der Änderung ausstehendÄnderung umgesetzt
|
|||
|
Change-Request-ID
ChangeRequestId
|
Eindeutige Kennung eines einzelnen Change-Request-Cases, die alle zugehörigen Aktivitäten von der Einleitung bis zum Abschluss zusammenfasst. | ||
|
Beschreibung
Die Change-Request-ID ist der Primärschlüssel, der jede Änderungsinitiative über ihren gesamten Lebenszyklus eindeutig identifiziert. Beim Process Mining dient sie als Case-Kennung und führt alle Ereignisse, etwa Einreichung, Bewertung, Genehmigung und Umsetzung, zu einer zusammenhängenden Prozessinstanz zusammen. Mit der Change-Request-ID lässt sich der Änderungsmanagementprozess vollständig von Anfang bis Ende analysieren. So können Sie einzelne Änderungen verfolgen, die gesamte Zykluszeit berechnen und Prozessabweichungen oder Engpässe für jeden Antrag erkennen.
Warum das wichtig ist
Diese zentrale Case-Kennung verknüpft alle zugehörigen Ereignisse. So lässt sich der gesamte Verlauf eines Change Requests nachvollziehen und seine Leistung analysieren.
Woher beziehen
In der Regel ist dies die primäre Kennung des Geschäftsobjekts Change Request in Ivanti Cherwell.
Beispiele
CR-105421CR-105422CR-105423
|
|||
|
Ereigniszeitpunkt
EventTime
|
Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis für den Change Request stattgefunden hat. | ||
|
Beschreibung
Der Ereigniszeitpunkt, auch Timestamp genannt, erfasst Datum und Uhrzeit einer Aktivität. Diese Zeitangabe ist erforderlich, um Ereignisse chronologisch zu ordnen, und bildet die Grundlage für alle zeitbezogenen Process-Mining-Analysen. Mit diesem Attribut lassen sich Zeitspannen zwischen Aktivitäten berechnen, die Zykluszeit eines gesamten Cases messen sowie Wartezeiten und Verzögerungen im Prozess erkennen. Es ist außerdem die Grundlage für Dashboards, die die Leistung anhand zeitbezogener Ziele überwachen, etwa der Zykluszeit für die Genehmigung von Änderungen.
Warum das wichtig ist
Dieser Timestamp bildet die Grundlage für alle Leistungs- und Zeitdaueranalysen. Er ermöglicht die Berechnung von Zykluszeiten, das Erkennen von Engpässen und die Überwachung von SLAs.
Woher beziehen
In der Regel in Protokollen zu Statusänderungen, Audit-Trails oder Zeitstempeln von Journaleinträgen zum Change-Request-Objekt in Ivanti Cherwell zu finden.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus Ivanti Cherwell. Es bildet kein Ereignis im Prozess selbst ab, sondern enthält Metadaten zur Aktualität der Daten. So können Benutzer von Dashboards einschätzen, wie aktuell die Analyse ist. Das Attribut unterstützt die Planung von Datenaktualisierungen und stellt sicher, dass Entscheidungen auf Daten mit bekanntem Aktualitätsstand beruhen.
Warum das wichtig ist
Zeigt an, wie aktuell die Daten sind. Das ist wichtig, damit Benutzer der Analyse vertrauen und ihre Relevanz für den aktuellen Betriebszustand einschätzen können.
Woher beziehen
Dieser Timestamp wird während des ETL-Prozesses (Extraktion, Transformation und Laden) für jeden Datensatz erzeugt und eingetragen.
Beispiele
2024-05-21T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das führende System, aus dem die Daten extrahiert wurden. In dieser Ansicht ist dies 'Ivanti Cherwell'. | ||
|
Beschreibung
Dieses Attribut gibt an, aus welchem System die Ereignisdaten stammen. In heterogenen Umgebungen hilft es, Daten aus verschiedenen Quellen zu unterscheiden. In diesem spezifischen Datenmodell hat es einen konstanten Wert, der angibt, dass die Daten aus Ivanti Cherwell stammen. Auch wenn der Wert in einem Modell mit nur einer Quelle unverändert bleibt, ist er für Data Governance, Rückverfolgbarkeit und künftige Integrationen mit anderen Systemen wichtig. Er schafft Klarheit über die Herkunft der Daten und unterstützt die Verwaltung der Datenqualität.
Warum das wichtig ist
Gibt wichtige Informationen zur Herkunft der Daten und unterstützt Data Governance, die Fehlerbehebung und die Rückverfolgbarkeit.
Woher beziehen
In der Regel ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
Ivanti Cherwell
|
|||
|
Änderungsrisikostufe
ChangeRiskLevel
|
Bewertete Risikostufe der Änderung, zum Beispiel 'Low', 'Medium' oder 'High'. | ||
|
Beschreibung
Die Änderungsrisikostufe wird während der Bewertungsphase festgelegt und gibt die möglichen negativen Auswirkungen einer Änderung an. Sie beeinflusst häufig den Genehmigungsprozess und den erforderlichen Prüfungsumfang. Beim Process Mining dient dieses Attribut dazu, die Einheitlichkeit von Risikobewertungen zu untersuchen und Risiken mit dem Prozessverlauf in Beziehung zu setzen. So können Sie beispielsweise prüfen, ob Änderungen mit hohem Risiko einen strengeren Genehmigungsprozess durchlaufen oder länger umgesetzt werden. Das Attribut unterstützt direkt das Dashboard 'Change Risk Assessment Consistency'.
Warum das wichtig ist
Ermöglicht die Analyse, wie sich Risiken auf den Prozessfluss, Genehmigungszyklen und Erfolgsquoten auswirken. So lässt sich sicherstellen, dass Änderungen mit hohem Risiko angemessen geprüft werden.
Woher beziehen
Dieser Wert ist in der Regel im Feld 'Risk Level' oder einem ähnlichen Feld des Change-Request-Objekts gespeichert und wird üblicherweise während der Risikobewertung eingetragen.
Beispiele
NiedrigMittelHochKritisch
|
|||
|
Änderungsstatus
ChangeStatus
|
Aktueller oder abschließender Status des Change Requests, zum Beispiel 'Closed', 'Rejected' oder 'In Progress'. | ||
|
Beschreibung
Der Änderungsstatus gibt an, in welchem Zustand sich ein Change Request zu einem bestimmten Zeitpunkt befindet oder wie er abgeschlossen wurde. Dieses wichtige Attribut hilft, den Abschluss eines Cases zu verstehen und Ausnahmen zu erkennen. In der Prozessanalyse können Sie damit nach bestimmten Ergebnissen filtern, etwa um nur abgelehnte oder abgebrochene Änderungen zu untersuchen. Es fließt in KPIs wie 'Change Request Rejection Rate' ein und ist wichtig, um den Gesamtzustand und die Effizienz des Änderungsmanagementprozesses zu beurteilen.
Warum das wichtig ist
Legt das Ergebnis eines Change Requests fest und ermöglicht wichtige Analysen zu Ablehnungs- und Abschlussquoten sowie zur Verteilung offener und geschlossener Cases.
Woher beziehen
Entspricht dem Feld 'Status' des Geschäftsobjekts Change Request in Ivanti Cherwell.
Beispiele
GenehmigtAbgelehntGeschlossenAbgebrochenGenehmigung ausstehend
|
|||
|
Änderungsteam
ChangeTeam
|
Team oder Gruppe, die aktuell für den Change Request verantwortlich ist. | ||
|
Beschreibung
Das Änderungsteam ist die Gruppe oder Abteilung, der der Change Request zugewiesen ist. Wie beim Änderungsverantwortlichen kann sich auch diese Zuständigkeit im Prozessverlauf ändern. Das zeigt eine Übergabe zwischen Teams an, etwa vom Service Desk an ein Team für Netzwerktechnik. Dieses Attribut ist wichtig, um teamübergreifende Übergaben zu analysieren und systembedingte Verzögerungen durch bestimmte Teams zu erkennen. Es hilft zu klären, welche Teams überlastet sind und wo die Kommunikation stockt. Damit unterstützt es direkt die Analyse 'Change Handoff & Resource Utilization'.
Warum das wichtig ist
Zeigt die Zuständigkeit auf Teamebene an. Das ist wichtig, um Prozessengpässe zu analysieren, die Teamleistung zu messen und Verzögerungen bei Übergaben zwischen Gruppen zu verstehen.
Woher beziehen
Diese Information ist üblicherweise im Feld 'Owned By Team' oder einem ähnlichen Feld für Gruppenzuweisungen des Change-Request-Objekts gespeichert.
Beispiele
NetzwerkbetriebDatenbankadministrationAnwendungssupport
|
|||
|
Änderungstyp
ChangeType
|
Klassifizierung der Änderung, zum Beispiel 'Standard', 'Normal' oder 'Emergency'. | ||
|
Beschreibung
Der Änderungstyp kategorisiert den Change Request nach Art, Dringlichkeit und Auswirkungen. Gängige Typen sind Standard (vorab genehmigt, geringes Risiko), Normal (erfordert eine vollständige Bewertung und Genehmigung) und Emergency (muss sofort umgesetzt werden). Mit diesem Attribut können Sie die Prozessleistung für verschiedene Kategorien getrennt vergleichen. So lässt sich beispielsweise feststellen, ob Emergency-Änderungen einen anderen, schnelleren Prozesspfad durchlaufen oder Standardänderungen tatsächlich mit minimalem Aufwand bearbeitet werden. Das Attribut ist wichtig für das Dashboard 'Problematic Change Type Performance'.
Warum das wichtig ist
Die Segmentierung des Prozesses nach Änderungstyp ist wichtig, um die Leistung zu vergleichen und festzustellen, ob bestimmte Kategorien wie 'Emergency' Engpässe oder Abweichungen verursachen.
Woher beziehen
Entspricht einem Klassifizierungsfeld des Geschäftsobjekts Change Request, das wahrscheinlich 'Change Type' oder 'Category' heißt.
Beispiele
StandardNormalNotfall
|
|||
|
Änderungsverantwortlicher
ChangeOwner
|
Benutzer oder Person, die aktuell für den Change Request verantwortlich ist. | ||
|
Beschreibung
Der Änderungsverantwortliche ist die Person, der ein Change Request in einer bestimmten Phase zugewiesen ist und die dafür verantwortlich ist. Dieses Attribut kann sich im Verlauf des Prozesses ändern und so eine Übergabe zwischen Personen anzeigen. Die Analyse des Änderungsverantwortlichen hilft, die Arbeitsauslastung zu verstehen und Engpässe im Zusammenhang mit bestimmten Personen zu erkennen. Sie ist auch wichtig für die Untersuchung von Übergaben, die erhebliche Verzögerungen verursachen können. Dieses Attribut unterstützt das Dashboard 'Change Handoff & Resource Utilization'.
Warum das wichtig ist
Erfasst die individuelle Verantwortung und ermöglicht Analysen zur Arbeitsverteilung, zur Häufigkeit von Übergaben und zu Engpässen bei bestimmten Ressourcen.
Woher beziehen
In der Regel das Feld 'Owned By' oder 'Assigned To' im Geschäftsobjekt Change Request.
Beispiele
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Geplantes Abschlussdatum
TargetCompletionDate
|
Geplanter oder vereinbarter Termin für den Abschluss der Umsetzung der Änderung. | ||
|
Beschreibung
Das geplante Abschlussdatum ist der Timestamp, bis zu dem die Änderung vollständig umgesetzt und überprüft sein soll. Dieses Datum ist häufig Teil eines Service Level Agreements (SLA) und dient als zentrale Vergleichsgröße für die Leistung. Das Attribut ist wichtig, um die Termintreue und die Einhaltung von Fristen zu überwachen. Der Vergleich mit dem tatsächlichen Abschlussdatum ermöglicht die Berechnung der KPIs 'On-Time Change Completion Rate' und 'Change SLA Adherence Rate'. Außerdem lassen sich damit Änderungen erkennen, bei denen das Erreichen des Ziels gefährdet ist.
Warum das wichtig ist
Dient als Grundlage für die Messung der Termintreue und SLA-Einhaltung, wichtige Kennzahlen für Effizienz und Zuverlässigkeit des Prozesses.
Woher beziehen
In der Regel ein Datumsfeld im Change-Request-Objekt, häufig mit 'Target Date', 'Due Date' oder 'SLA Target' bezeichnet.
Beispiele
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Ablehnungsgrund
ChangeRejectionReason
|
Textbeschreibung oder Kategorie, die erklärt, warum ein Change Request abgelehnt wurde. | ||
|
Beschreibung
Wird ein Change Request abgelehnt, erfasst dieses Attribut den vom Genehmigenden angegebenen Grund. Dabei kann es sich um einen Eintrag aus einer vorgegebenen Liste oder um eine Freitextbegründung handeln. Diese Information ist wichtig für das Dashboard 'Rejected Change Request Analysis'. Durch die Kategorisierung und Analyse von Ablehnungsgründen können Unternehmen häufige Probleme bei Änderungsanträgen erkennen, etwa fehlende Angaben, eine unzureichende Risikobewertung oder geschäftliche Konflikte. Diese Erkenntnisse helfen, die Qualität künftiger Change Requests zu verbessern.
Warum das wichtig ist
Zeigt direkt, warum Änderungen scheitern. So können Sie gezielt die Einreichung und Bewertung verbessern und die Ablehnungsquote insgesamt senken.
Woher beziehen
Diese Daten werden häufig in einem eigenen Feld 'Rejection Reason' oder in einem Notizfeld erfasst, das beim Wechsel des Status zu 'Rejected' ausgefüllt wird.
Beispiele
Umsetzungsplan enthält zu wenige DetailsRisikobewertung unvollständigKonflikt mit anderen terminierten Änderungen
|
|||
|
Änderungspriorität
ChangePriority
|
Prioritätsstufe des Change Requests, die seine Dringlichkeit und geschäftlichen Auswirkungen angibt. | ||
|
Beschreibung
Die Änderungspriorität ergibt sich aus der Dringlichkeit und den Auswirkungen einer Änderung. Sie hilft Teams, ihre Arbeit zu priorisieren und Ressourcen gezielt einzusetzen, damit besonders kritische Änderungen zuerst bearbeitet werden. In der Analyse können Sie prüfen, ob Änderungen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. Abweichungen von dieser Erwartung können auf Ineffizienzen oder Engpässe bei der Priorisierung oder Umsetzung hinweisen.
Warum das wichtig ist
Hilft zu prüfen, ob der Prozess Änderungen mit großen Auswirkungen angemessen priorisiert und ob diese wie vorgesehen schneller bearbeitet werden.
Woher beziehen
In der Regel ein Feld namens 'Priority' im Change-Request-Objekt. Der Wert kann manuell festgelegt oder aus den Feldern für Auswirkungen und Dringlichkeit abgeleitet werden.
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
|
|||
|
Betroffener Service
ServiceAffected
|
Der wichtigste betroffene Geschäftsservice oder das betroffene Konfigurationselement (CI). | ||
|
Beschreibung
Dieses Attribut bezeichnet den IT-Service, die Anwendung oder die Infrastrukturkomponente, auf die sich der Change Request bezieht. Es stellt eine Verbindung zwischen dem Änderungsmanagementprozess und dem übergreifenden IT-Service-Management her. Die Analyse nach betroffenem Service ist wichtig für den KPI 'Top Problematic Change Types'. Sie zeigt, bei welchen Services besonders häufig Änderungen anstehen und welche mit hohen Ablehnungsquoten oder Verzögerungen verbunden sind. Diese Erkenntnisse helfen Serviceverantwortlichen, die Stabilität zu verbessern und technische Schulden abzubauen.
Warum das wichtig ist
Ordnet Änderungen bestimmten Geschäftsservices zu. So lässt sich analysieren, welche Services besonders instabil sind oder die meisten problematischen Änderungen verursachen.
Woher beziehen
Wird üblicherweise aus der Configuration Management Database (CMDB) übernommen und im Feld 'Primary CI' oder 'Service' des Change-Request-Objekts gespeichert.
Beispiele
E-Mail-Service (Exchange)ERP-System (SAP)Zentraler Netzwerk-Switch (CISCO-4500X)
|
|||
|
Einreichende Person
ChangeSubmitter
|
Benutzer, der den Change Request ursprünglich erstellt oder eingereicht hat. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Person, die den Change Request eingeleitet hat. Sie kann sich von der für die Umsetzung zuständigen Person unterscheiden, die später im Prozess die Verantwortung übernimmt. Die Analyse der einreichenden Person kann Muster bei der Qualität von Anträgen aufzeigen. So lässt sich beispielsweise feststellen, ob bestimmte Personen oder Teams häufig unvollständige Anträge einreichen, die zu Ablehnungen oder Nacharbeit führen. Diese Erkenntnisse können gezielte Schulungen unterstützen und die Qualität der Einreichungen insgesamt verbessern.
Warum das wichtig ist
Hilft, den Ursprung von Change Requests nachzuvollziehen, die Qualität der Einreichungen nach Person oder Team zu analysieren und Schulungsbedarf zu erkennen.
Woher beziehen
In der Regel das Feld 'Created By' oder 'Requested By' im Change-Request-Objekt.
Beispiele
Susan MillerDavid ChenMaria Garcia
|
|||
|
Fristgerecht abgeschlossen
IsOnTimeCompletion
|
Ein berechnetes Kennzeichen, das den Wert „wahr“ hat, wenn die Änderung am Zieldatum oder davor abgeschlossen wurde. | ||
|
Beschreibung
Dieses boolesche Attribut wird berechnet, indem „ActualCompletionDate“ mit „TargetCompletionDate“ verglichen wird. Es erleichtert die Analyse, indem es für jede Änderungsanforderung eindeutig angibt, ob sie fristgerecht abgeschlossen wurde. Dieses Kennzeichen bildet die Grundlage für die Berechnung der KPI „On-Time Change Completion Rate“. In Dashboards können Sie damit verspätete Änderungen filtern und gezielt analysieren. So lassen sich häufige Ursachen für Verzögerungen ermitteln.
Warum das wichtig ist
Erleichtert die Leistungsanalyse, indem es eindeutig angibt, ob eine Frist eingehalten wurde. Damit lassen sich KPIs zur fristgerechten Fertigstellung direkt berechnen.
Woher beziehen
Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird während der Datentransformation berechnet, indem „ActualCompletionDate“ <= „TargetCompletionDate“ verglichen wird.
Beispiele
truefalse
|
|||
|
Geschäftseinheit
BusinessUnit
|
Geschäftseinheit oder Abteilung, die die Änderung beantragt hat oder von ihr profitieren wird. | ||
|
Beschreibung
Dieses Attribut ordnet den Change Request einem bestimmten Bereich der Organisation zu, zum Beispiel 'Finanzen', 'Marketing' oder 'Betrieb'. Dadurch erhält ein ansonsten technischer Prozess einen geschäftlichen Kontext. Die Analyse nach Geschäftseinheit zeigt, aus welchen Bereichen der Änderungsbedarf kommt. Sie kann Verrechnungsmodelle unterstützen, die Auswirkungen von IT-Änderungen auf verschiedene Geschäftsbereiche verdeutlichen und aufzeigen, ob Änderungen in bestimmten Einheiten komplexer sind oder länger dauern als in anderen.
Warum das wichtig ist
Liefert den geschäftlichen Kontext und ermöglicht Analysen zu Änderungsbedarf, Auswirkungen und Leistung aus organisatorischer Sicht.
Woher beziehen
Diese Information kann in einem Feld des Change-Request-Objekts gespeichert oder aus dem Benutzerprofil der anfragenden Person übernommen werden.
Beispiele
FinanzenPersonalwesenVertrieb und MarketingBetrieb
|
|||
|
Implementierungszykluszeit
ImplementationCycleTime
|
Die berechnete Dauer vom Beginn bis zum Abschluss der Implementierung einer Änderung. | ||
|
Beschreibung
Diese Kennzahl gibt an, wie lange die Implementierungsphase einer Änderung dauert. Sie wird als Zeitspanne zwischen der Aktivität „Change Implementation Started“ und der Aktivität „Change Implemented“ berechnet. Dieses Attribut dient zur Berechnung der KPI „Average Change Implementation Time“ und unterstützt das Dashboard „Change Implementation Flow & Delays“. Es hilft dabei, Verzögerungen in der Planung von Verzögerungen bei der Ausführung zu unterscheiden. So können Teams Verbesserungen gezielt auf die technische Umsetzung konzentrieren.
Warum das wichtig ist
Zeigt die Leistung während der eigentlichen Implementierungsphase. So lassen sich technische oder ressourcenbedingte Engpässe getrennt von Verzögerungen bei der Freigabe erkennen.
Woher beziehen
Wird im Process-Mining-Tool oder während der Datentransformation berechnet, indem die Zeitdifferenz zwischen den Timestamp-Werten des Implementierungsstarts und des Endereignisses ermittelt wird.
Beispiele
4 Stunden 15 Minuten1 Tag 2 Stunden30 Minuten
|
|||
|
Tatsächliches Abschlussdatum
ActualCompletionDate
|
Timestamp, zu dem die Änderung tatsächlich umgesetzt und als abgeschlossen bestätigt wurde. | ||
|
Beschreibung
Das tatsächliche Abschlussdatum gibt an, wann die Umsetzungsarbeiten für den Change Request beendet wurden. Dieser wichtige Meilenstein wird mit dem geplanten Termin verglichen, um die Leistung zu messen. Zusammen mit dem geplanten Abschlussdatum zeigt dieses Attribut, ob eine Änderung fristgerecht abgeschlossen wurde. Es fließt in KPIs wie 'On-Time Change Completion Rate' ein und hilft, die Ursachen für Verzögerungen in der Umsetzungsphase zu analysieren.
Warum das wichtig ist
Erfasst den tatsächlichen Abschlusszeitpunkt. Dieser ist erforderlich, um die Termintreue zu berechnen und das Ausmaß von Verzögerungen zu analysieren.
Woher beziehen
Dieses Datum wird häufig erfasst, wenn der Status des Change Requests auf 'Implemented' oder 'Completed' gesetzt wird. Es kann in einem eigenen Feld gespeichert oder aus dem Timestamp der Statusänderung abgeleitet werden.
Beispiele
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
Aktivitäten im Änderungsmanagement
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Änderung eingeplant
|
Diese Aktivität markiert den Zeitpunkt, zu dem Datum und Uhrzeit der Umsetzung einer Änderung verbindlich bestätigt und erfasst werden. Sie wird erfasst, wenn der Status auf „Geplant“ gesetzt wird. | ||
|
Warum das wichtig ist
Dieser Meilenstein markiert eine verbindliche Zusage. Er überführt die Änderung vom genehmigten Konzept in eine geplante Maßnahme und ist Voraussetzung für die Umsetzung.
Woher beziehen
Aus dem Verlauf des Change-Request-Objekts abgeleitet, indem der Timestamp erfasst wird, zu dem das Feld 'Status' auf 'Scheduled' gesetzt wird.
Erfassung
Aus der Statusänderung zu 'Scheduled' abgeleitet.
Ereignistyp
inferred
|
|||
|
Änderung geschlossen
|
Diese Aktivität ist der abschließende erfolgreiche Endpunkt des Änderungsmanagementprozesses. Sie wird erfasst, wenn der Status des Change Requests auf 'Closed' gesetzt wird und damit alle Arbeiten abgeschlossen sind. | ||
|
Warum das wichtig ist
Als maßgeblicher Endpunkt für den Erfolg ist diese Aktivität erforderlich, um die durchgängige Zykluszeit erfolgreich abgeschlossener Änderungen zu berechnen. Sie bestätigt, dass alle Prozessschritte beendet sind.
Woher beziehen
Abgeleitet aus dem Timestamp der abschließenden Statusänderung zu 'Closed' im Audit-Verlauf des Change-Request-Objekts.
Erfassung
Aus der abschließenden Statusänderung zu 'Closed' abgeleitet.
Ereignistyp
inferred
|
|||
|
Änderung umgesetzt
|
Dieser Meilenstein zeigt an, dass die technische Arbeit an der Änderung abgeschlossen ist. Er wird erfasst, wenn der Status des Change Requests auf 'Implemented' oder einen ähnlichen Status gesetzt wird, bei dem die Überprüfung noch aussteht. | ||
|
Warum das wichtig ist
Dieser wichtige Erfolgsmeilenstein fließt in die KPIs On-Time Change Completion Rate und Average Change Implementation Time ein. Er markiert das Ende der Umsetzungsphase.
Woher beziehen
Aus dem Audit-Protokoll des Change-Request-Objekts abgeleitet. Maßgeblich ist der Timestamp der Statusänderung zu 'Implemented' oder 'Pending Verification'.
Erfassung
Aus der Statusänderung zu 'Implemented' abgeleitet.
Ereignistyp
inferred
|
|||
|
Änderung vom CAB genehmigt
|
Ein wichtiger Meilenstein: Das Change Advisory Board (CAB) oder eine zuständige Instanz genehmigt die Änderung. Dies wird daran erkannt, dass der Status des Änderungsantrags auf „Genehmigt“ gesetzt wird. | ||
|
Warum das wichtig ist
Diese Aktivität markiert das Ende des Genehmigungszyklus. Sie gibt den Prozess für Planung und Umsetzung frei und ist entscheidend für die Kennzahl zur Genehmigungsdauer von Änderungen.
Woher beziehen
Wird aus dem Auditverlauf des Objekts „Change Request“ abgeleitet. Erfasst wird insbesondere der Timestamp, zu dem das Feld 'Status' auf „Genehmigt“ geändert wird.
Erfassung
Abgeleitet aus der Statusänderung zu „Genehmigt“.
Ereignistyp
inferred
|
|||
|
Änderungsantrag erstellt
|
Diese Aktivität markiert den Beginn eines neuen Änderungsantrags im System. Sie wird in der Regel erfasst, wenn ein neuer Datensatz im Geschäftsobjekt „Change Request“ angelegt wird. Damit beginnt der gesamte Prozess. | ||
|
Warum das wichtig ist
Dies ist das zentrale Start-Event des Prozesses. Die Zeitspanne von dieser Aktivität bis zu anderen Aktivitäten zeigt die Gesamtdauer des Lebenszyklus und hilft, Verzögerungen zu Beginn des Prozesses zu erkennen.
Woher beziehen
Dieses Ereignis wird anhand des Erstellungs-Timestamps des Änderungsantrags erfasst. In Ivanti Cherwell ist dieser üblicherweise im Feld 'CreatedDateTime' des Geschäftsobjekts „Change Request“ gespeichert.
Erfassung
Direkt anhand des Erstellungs-Timestamps des Datensatzes erfasst.
Ereignistyp
explicit
|
|||
|
Auswirkungen und Risiken bewertet
|
Diese Aktivität kennzeichnet den Abschluss der Risiko- und Auswirkungsanalyse für den Änderungsantrag. Sie wird üblicherweise daran erkannt, dass der Status des Änderungsantrags zu einem Status wechselt, der die Genehmigungsreife anzeigt, etwa „Genehmigung ausstehend“. | ||
|
Warum das wichtig ist
Die Erfassung dieser Aktivität hilft, die Dauer der Bewertungsphase zu messen und sicherzustellen, dass Risiken vor der Genehmigung konsequent analysiert werden. Sie unterstützt damit die Kennzahl zur Einhaltung der Risikobewertung.
Woher beziehen
Wird aus dem Verlauf des Objekts „Change Request“ abgeleitet. Erfasst wird der Timestamp, zu dem das Feld 'Status' von „Wird bewertet“ zu einem Status wie „CAB-Genehmigung ausstehend“ geändert wird.
Erfassung
Abgeleitet aus der Statusänderung zu „CAB-Genehmigung ausstehend“.
Ereignistyp
inferred
|
|||
|
Review nach der Umsetzung durchgeführt
|
Diese Aktivität zeigt an, dass die abgeschlossene Änderung formell überprüft wurde, um ihren Erfolg zu bewerten und Erkenntnisse festzuhalten. Sie wird häufig aus einer Statusänderung zu 'Post Implementation Review' abgeleitet. | ||
|
Warum das wichtig ist
Die Erfassung dieser Aktivität stellt sicher, dass die Rückmeldung zu Änderungen in den Prozess einfließt. Sie ist wichtig für die kontinuierliche Verbesserung und fließt direkt in den KPI Post-Implementation Review Rate ein.
Woher beziehen
Aus dem Audit-Verlauf des Change-Request-Objekts abgeleitet. Erfasst wird der Timestamp, zu dem der Status zu einem Wert wie 'Post Implementation Review' wechselt.
Erfassung
Aus der Statusänderung zu 'Post Implementation Review' abgeleitet.
Ereignistyp
inferred
|
|||
|
Änderung abgebrochen
|
Bezeichnet einen Endzustand, in dem ein genehmigter oder bereits laufender Change Request vor dem Abschluss zurückgezogen wird. Das Ereignis wird erfasst, wenn der Status auf 'Cancelled' gesetzt wird. | ||
|
Warum das wichtig ist
Dies ist ein alternativer Endpunkt des Prozesses. Die Analyse, warum und wann Änderungen abgebrochen werden, kann Probleme bei der Planung, Ressourcenzuweisung oder veränderte geschäftliche Prioritäten aufzeigen.
Woher beziehen
Aus dem Audit-Verlauf abgeleitet. Erfasst wird der Timestamp, zu dem das Feld 'Status' des Change-Request-Objekts auf 'Cancelled' gesetzt wird.
Erfassung
Aus der Statusänderung zu 'Cancelled' abgeleitet.
Ereignistyp
inferred
|
|||
|
Änderung abgelehnt
|
Diese Aktivität bezeichnet die endgültige Ablehnung des Änderungsantrags während der Genehmigungsphase. Sie wird erfasst, wenn der Status des Änderungsantrags auf „Abgelehnt“ gesetzt wird. | ||
|
Warum das wichtig ist
Dies ist ein wichtiger Endpunkt für fehlgeschlagene Änderungen. Die Analyse abgelehnter Änderungen und ihrer Gründe hilft, die Qualität der Erstanträge zu verbessern und unterstützt die Kennzahl zur Ablehnungsquote von Änderungsanträgen.
Woher beziehen
Wird aus dem Timestamp abgeleitet, zu dem das Feld 'Status' im Auditverlauf des Objekts „Change Request“ auf „Abgelehnt“ gesetzt wird.
Erfassung
Abgeleitet aus der Statusänderung zu „Abgelehnt“.
Ereignistyp
inferred
|
|||
|
Änderung zur Bewertung eingereicht
|
Bezeichnet die formelle Einreichung eines neu erstellten Änderungsantrags zur ersten Bewertung. In der Regel wird dies daran erkannt, dass sich der Status des Änderungsantrags von „Neu“ oder „Entwurf“ zu einem Status wie „Wird bewertet“ ändert. | ||
|
Warum das wichtig ist
Diese Aktivität markiert nach der ersten Dateneingabe den Beginn des formellen Änderungsprozesses. Die Zeit zwischen Erstellung und Einreichung kann auf Schulungsbedarf oder Hindernisse im Prozess hinweisen.
Woher beziehen
Wird aus dem Audit Log oder dem Änderungsverlauf des Objekts „Change Request“ abgeleitet. Maßgeblich ist der Timestamp, zu dem das Feld 'Status' auf einen Wert wie „Wird bewertet“ oder „Eingereicht“ geändert wird.
Erfassung
Abgeleitet aus der Statusänderung von „Neu“ zu „Wird bewertet“.
Ereignistyp
inferred
|
|||
|
Genehmigung der Änderung ausstehend
|
Diese Aktivität bezeichnet den Zeitraum, in dem ein Änderungsantrag offiziell auf eine Entscheidung des Change Advisory Board (CAB) oder einer anderen Genehmigungsinstanz wartet. Sie wird aus einem Status wie „Genehmigung ausstehend“ oder „CAB ausstehend“ abgeleitet. | ||
|
Warum das wichtig ist
Diese Aktivität bildet eine wichtige Wartezeit ab. Ihre Dauer zeigt Engpässe im Genehmigungsworkflow, einer häufigen Ursache für Verzögerungen im Change Management.
Woher beziehen
Erfasst wird der Timestamp, zu dem das Feld 'Status' im Geschäftsobjekt „Change Request“ auf „Genehmigung ausstehend“ oder einen entsprechenden Wert gesetzt wird.
Erfassung
Erkannt am Wechsel in den Status „Genehmigung ausstehend“.
Ereignistyp
inferred
|
|||
|
Überprüfung der Änderung durchgeführt
|
Bezeichnet die Test- und Validierungsphase, in der geprüft wird, ob die Änderung erfolgreich war und keine unerwünschten Auswirkungen verursacht hat. Sie wird aus einer Statusänderung zu 'Verification' oder 'Testing' abgeleitet. | ||
|
Warum das wichtig ist
Die Analyse von Häufigkeit und Dauer dieser Aktivität zeigt, ob die Qualitätssicherungsschritte eingehalten werden. Sie ist entscheidend, um durch Änderungen verursachte Vorfälle zu vermeiden.
Woher beziehen
Erfasst anhand des Timestamps einer Statusänderung am Change-Request-Objekt, zum Beispiel beim Wechsel zu 'Verification' oder 'User Acceptance Testing'.
Erfassung
Aus der Statusänderung zu 'Verification' abgeleitet.
Ereignistyp
inferred
|
|||
|
Umsetzung der Änderung gestartet
|
Markiert den Beginn der technischen Umsetzung der Änderung. Dieser Zeitpunkt wird in der Regel aus der Änderung des Status des Change Requests zu 'In Progress' oder 'Implementing' abgeleitet. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den Beginn des Umsetzungszeitraums. Die Zeit bis 'Change Implemented' entspricht der tatsächlichen Umsetzungsdauer und ist ein wichtiger Bestandteil der gesamten Zykluszeit.
Woher beziehen
Aus dem Audit-Verlauf des Change-Request-Objekts abgeleitet. Erfasst wird der Timestamp, zu dem das Feld 'Status' auf einen Wert wie 'In Progress' oder 'Implementing' gesetzt wird.
Erfassung
Aus der Statusänderung zu 'In Progress' abgeleitet.
Ereignistyp
inferred
|
|||
|
Umsetzungsplan erstellt
|
Markiert den Abschluss der detaillierten Planung der Änderung. Dazu gehören die Festlegung von Aufgaben und Ressourcen sowie die Erstellung von Rückfallplänen. Häufig wird dies daran erkannt, dass der Status der Änderung von „Genehmigt“ zu „Geplant“ wechselt. | ||
|
Warum das wichtig ist
Die Dauer dieser Aktivität zeigt, wie effizient die Planungsphase der Änderung abläuft. Verzögerungen in dieser Phase können den gesamten Zeitplan beeinträchtigen, auch wenn die Änderung bereits genehmigt wurde.
Woher beziehen
Lässt sich anhand des Timestamps einer Statusänderung von „Genehmigt“ zu „Geplant“ ableiten. Alternativ kann die Aktivität an das Ausfüllen bestimmter Planungsfelder geknüpft werden.
Erfassung
Abgeleitet aus der Statusänderung von „Genehmigt“ zu „Geplant“.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Verwenden Sie dieses Template als Ausgangspunkt für die Analyse Ihres Änderungsmanagementprozesses und gezielte Verbesserungen. Beginnen Sie noch heute damit, Änderungen effizienter umzusetzen.
Erreichen Sie eine Erfolgsquote von 95 % bei Änderungen: Optimieren Sie Ivanti Cherwell jetzt
Beseitigen Sie Engpässe, senken Sie Risiken und erreichen Sie eine Erfolgsquote von 95 % bei Änderungen.
Keine Kreditkarte erforderlich. Sie können sofort loslegen.