Ihr Daten-Template für das Änderungsmanagement

Ivanti Cherwell
Ihr Daten-Template für das Änderungsmanagement

Ihr Daten-Template für das Änderungsmanagement

Dieses Template zeigt Ihnen, welche wesentlichen Daten Sie für die Analyse Ihres Änderungsmanagementprozesses erfassen sollten. Es beschreibt die erforderlichen Attribute und wichtigen Aktivitäten und enthält konkrete Hinweise dazu, wie Sie diese Informationen aus Ihrem Quellsystem extrahieren. Verwenden Sie diese Ressource, um ein aussagekräftiges Event Log für Ihre Process-Mining-Analysen zu erstellen.
  • Empfohlene Attribute für die Erfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Hinweise zur Datenextraktion aus Ivanti Cherwell
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Änderungsmanagements

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um das Änderungsmanagement umfassend zu analysieren und den Prozess gezielt zu entdecken.
5 Erforderlich 6 Empfohlen 8 Optional
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
Erforderlich Empfohlen Optional

Aktivitäten im Änderungsmanagement

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, um den Prozess präzise zu entdecken und seine Leistung zu messen.
7 Empfohlen 7 Optional
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
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Ivanti Cherwell

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.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Sie können sofort loslegen.