Ihr Daten-Template für Change Management

Ivanti Cherwell
Ihr Daten-Template für Change Management

Ihr Daten-Template für Change Management

Dieses Template bietet einen klaren Leitfaden für die Erfassung der wesentlichen Daten zur Analyse Ihres Change-Management-Prozesses. Es beschreibt die wichtigen Attribute, die Sie erfassen sollten, die zentralen Aktivitäten, die Sie verfolgen sollten, und enthält konkrete Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um ein aussagekräftiges Event Log für Ihre Process-Mining-Initiativen zu erstellen.
  • Empfohlene Attribute für die Erfassung
  • Zentrale Aktivitäten zur Nachverfolgung
  • Hinweise zur Extraktion aus Ivanti Cherwell
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Attribute des Change Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse des Change Managements und eine aussagekräftige Prozesserkennung in Ihr Event Log aufnehmen sollten.
5 Erforderlich 6 Empfohlen 8 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name des spezifischen Ereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Change-Management-Prozess stattgefunden hat.
Beschreibung

Der Aktivitätsname beschreibt einen bestimmten Schritt oder Meilenstein im Lebenszyklus eines Änderungsantrags, beispielsweise „Change Submitted For Assessment“ oder „Change Approved by CAB“. Diese Aktivitäten bilden die Knoten in der ermittelten Prozesslandkarte.

In der Analyse ist dieses Attribut grundlegend für die Visualisierung des Prozessflusses, die Ermittlung der Ereignisabfolge und das Erkennen von Abweichungen vom Standardverfahren. Es dient zur Berechnung der Übergangszeiten zwischen Aktivitäten und zeigt, an welchen Stellen Verzögerungen auftreten.

Warum das wichtig ist

Dieses Attribut ist entscheidend für die Ermittlung und Visualisierung des tatsächlichen Prozessflusses. Dadurch lassen sich Engpässe, Nacharbeitsschleifen und nicht konforme Pfade erkennen.

Bezugsquelle

Erzeugt aus Statusänderungen, Journaleinträgen oder spezifischen Event Logs zum Objekt „Change Request“ in Ivanti Cherwell.

Beispiele
Change zur Bewertung eingereichtChange wartet auf GenehmigungÄnderung umgesetzt
Ereigniszeit
EventTime
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis für den Änderungsantrag stattgefunden hat.
Beschreibung

Die Ereigniszeit, auch als Timestamp bezeichnet, erfasst das genaue Datum und die genaue Uhrzeit einer Aktivität. Diese Zeitdaten sind entscheidend für die chronologische Sortierung von Ereignissen und bilden die Grundlage für alle zeitbezogenen Process-Mining-Analysen.

Dieses Attribut dient zur Berechnung der Dauer zwischen Aktivitäten, zur Messung der gesamten Zykluszeit eines Cases sowie zur Ermittlung von Wartezeiten oder Verzögerungen im Prozess. Es ist grundlegend für Dashboards, die die Leistung anhand zeitbezogener Zielwerte überwachen, beispielsweise der „Change Approval Cycle Time“.

Warum das wichtig ist

Dieser Timestamp bildet die Grundlage für alle Leistungs- und Daueranalysen. Er ermöglicht die Berechnung von Zykluszeiten, die Ermittlung von Engpässen und die Überwachung von SLAs.

Bezugsquelle

Typischerweise in Protokollen zu Statusänderungen, Audit-Trails oder Timestamps von Journaleinträgen zum Objekt „Change Request“ in Ivanti Cherwell zu finden.

Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ID des Änderungsantrags
ChangeRequestId
Die eindeutige Kennung eines einzelnen Änderungsantrags, die alle zugehörigen Aktivitäten von der Initiierung bis zum Abschluss zusammenfasst.
Beschreibung

Die ID des Änderungsantrags ist der Primärschlüssel, der jede Änderungsinitiative während ihres gesamten Lebenszyklus eindeutig identifiziert. Sie dient im Process Mining als Case-Kennung und verknüpft alle Ereignisse wie Einreichung, Bewertung, Genehmigung und Umsetzung zu einer einzigen, zusammenhängenden Prozessinstanz.

Die Analyse von Daten anhand der ID des Änderungsantrags ermöglicht eine vollständige End-to-End-Sicht auf den Change-Management-Prozess. Dadurch lassen sich einzelne Änderungen nachverfolgen, die gesamte Zykluszeit berechnen und Prozessabweichungen oder Engpässe für jeden Antrag erkennen.

Warum das wichtig ist

Dies ist die zentrale Case-Kennung, die alle zugehörigen Ereignisse verbindet. So lässt sich der gesamte Verlauf eines Änderungsantrags nachvollziehen und seine Leistung analysieren.

Bezugsquelle

Dies ist typischerweise die primäre Kennung des Geschäftsobjekts „Change Request“ in Ivanti Cherwell.

Beispiele
CR-105421CR-105422CR-105423
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten für dieses Ereignis zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden.
Beschreibung

Dieses Attribut erfasst das Datum und die Uhrzeit, zu denen die Daten zuletzt aus Ivanti Cherwell abgerufen wurden. Es stellt kein Ereignis im Prozess selbst dar, sondern Metadaten zur Aktualität der Daten.

Diese Information ist für Dashboard-Nutzer wichtig, um die Aktualität der Analyse einzuschätzen. Sie unterstützt die Planung von Datenaktualisierungen und stellt sicher, dass Entscheidungen auf Daten mit bekanntem Aktualitätsstand beruhen.

Warum das wichtig ist

Zeigt die Aktualität der Daten an. Das ist entscheidend, damit Nutzer der Analyse vertrauen und ihre Relevanz für den aktuellen Betriebszustand einschätzen können.

Bezugsquelle

Dieser Timestamp wird während des ETL-Prozesses zur Extraktion, Transformation und zum Laden der Daten 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. Für diese Ansicht ist dies „Ivanti Cherwell“.
Beschreibung

Dieses Attribut identifiziert das Ursprungssystem der Ereignisdaten. In heterogenen Umgebungen hilft es, Daten aus unterschiedlichen Quellen zu unterscheiden. Für dieses spezifische Datenmodell enthält es einen konstanten Wert, der angibt, dass die Daten aus Ivanti Cherwell stammen.

Auch wenn der Wert in einem Modell mit nur einer Quelle statisch erscheint, ist er für Data Governance, Nachvollziehbarkeit und künftige Integrationen mit anderen Systemen entscheidend. Er schafft Klarheit über die Datenherkunft und unterstützt das Management der Datenqualität.

Warum das wichtig ist

Liefert wichtigen Kontext zur Herkunft der Daten. Dieser ist für Data Governance, die Fehlerbehebung und die Sicherstellung der Nachvollziehbarkeit entscheidend.

Bezugsquelle

Dies ist typischerweise ein statischer Wert, der während der Datenextraktion und -transformation ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Beispiele
Ivanti Cherwell
Änderungsstatus
ChangeStatus
Der aktuelle oder abschließende Status des Änderungsantrags, beispielsweise „Closed“, „Rejected“ oder „In Progress“.
Beschreibung

Der Änderungsstatus gibt den Zustand eines Änderungsantrags zu einem bestimmten Zeitpunkt oder sein abschließendes Ergebnis an. Er ist ein wichtiges Attribut, um die Lösung eines Cases zu verstehen und Ausnahmen zu erkennen.

In der Prozessanalyse dient dieses Attribut dazu, nach bestimmten Ergebnissen zu filtern, beispielsweise um nur abgelehnte oder abgebrochene Änderungen zu analysieren. Es bildet die Grundlage für KPIs wie „Change Request Rejection Rate“ und ist entscheidend, um den allgemeinen Zustand und die Effizienz des Change-Management-Prozesses zu verstehen.

Warum das wichtig ist

Definiert das Ergebnis eines Änderungsantrags und ermöglicht wichtige Analysen zu Ablehnungs- und Abschlussraten sowie zur Verteilung offener und geschlossener Cases.

Bezugsquelle

Dies entspricht dem Feld „Status“ des Geschäftsobjekts „Change Request“ in Ivanti Cherwell.

Beispiele
GenehmigtAbgelehntGeschlossenAbgebrochenWartet auf Genehmigung
Änderungsteam
ChangeTeam
Das Team oder die Gruppe, die derzeit für den Änderungsantrag verantwortlich ist.
Beschreibung

Das Änderungsteam ist die Gruppe oder Abteilung, der der Änderungsantrag zugewiesen wurde. Wie der Verantwortliche für die Änderung kann sich auch dieses Attribut im Prozess ändern und eine Übergabe der Verantwortung zwischen Teams anzeigen, beispielsweise vom Service Desk an ein Netzwerk-Engineering-Team.

Dieses Attribut ist für die Analyse von Übergaben zwischen Teams und die Ermittlung systemischer Verzögerungen durch bestimmte Teams unerlässlich. Es hilft bei der Beantwortung der Fragen, welche Teams überlastet sind oder wo Kommunikationsprobleme auftreten, und unterstützt direkt die Analyse „Change Handoff & Resource Utilization“.

Warum das wichtig ist

Identifiziert die Verantwortung auf Teamebene. Das ist entscheidend für die Analyse von Prozessengpässen, die Messung der Teamleistung und das Verständnis von Verzögerungen bei Übergaben zwischen Gruppen.

Bezugsquelle

Diese Information ist üblicherweise im Feld „Owned By Team“ oder einem vergleichbaren Feld zur Gruppenzuweisung im Objekt „Change Request“ gespeichert.

Beispiele
NetzwerkbetriebDatenbankadministrationAnwendungsbetreuung
Änderungstyp
ChangeType
Die Klassifizierung der Änderung, beispielsweise „Standard“, „Normal“ oder „Emergency“.
Beschreibung

Der Änderungstyp kategorisiert den Änderungsantrag nach Art, Dringlichkeit und Auswirkungen. Zu den gängigen Typen gehören Standardänderungen, die vorab genehmigt und risikoarm sind, normale Änderungen, die eine vollständige Bewertung und Genehmigung erfordern, sowie Notfalländerungen, die sofort umgesetzt werden müssen.

Dieses Attribut ermöglicht eine segmentierte Analyse und den Vergleich der Prozessleistung verschiedener Kategorien. So lässt sich beispielsweise prüfen, ob Notfalländerungen einem anderen, schnelleren Pfad folgen oder Standardänderungen tatsächlich mit minimalem Aufwand bearbeitet werden. Es ist zentral für das Dashboard „Problematic Change Type Performance“.

Warum das wichtig ist

Die Segmentierung des Prozesses nach Änderungstyp ist entscheidend, um die Leistung zu vergleichen und festzustellen, ob bestimmte Kategorien wie „Emergency“ Engpässe oder Abweichungen verursachen.

Bezugsquelle

Entspricht einem Klassifizierungsfeld, das im Geschäftsobjekt „Change Request“ wahrscheinlich „Change Type“ oder „Category“ heißt.

Beispiele
StandardNormalNotfall
Geplantes Abschlussdatum
TargetCompletionDate
Die geplante oder vereinbarte Frist für den Abschluss der Umsetzung der Änderung.
Beschreibung

Das geplante Abschlussdatum ist der Zeitpunkt, bis zu dem die Änderung voraussichtlich vollständig umgesetzt und verifiziert ist. Dieses Datum ist häufig Bestandteil eines Service Level Agreements (SLA) und dient als zentraler Leistungsmaßstab.

Dieses Attribut ist entscheidend für die Überwachung der Termintreue. Es wird mit dem tatsächlichen Abschlussdatum verglichen, um die KPIs „On-Time Change Completion Rate“ und „Change SLA Adherence Rate“ zu berechnen. Außerdem hilft es, Änderungen, bei denen das Ziel gefährdet ist, frühzeitig zu erkennen.

Warum das wichtig ist

Liefert die Grundlage für die Messung der Termintreue und SLA-Einhaltung. Beide Werte sind wichtige Indikatoren für Prozesseffizienz und Zuverlässigkeit.

Bezugsquelle

Dies ist typischerweise ein Datumsfeld im Objekt „Change Request“, das häufig „Target Date“, „Due Date“ oder „SLA Target“ heißt.

Beispiele
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Risikostufe der Änderung
ChangeRiskLevel
Die bewertete Risikostufe der Änderung, beispielsweise „Low“, „Medium“ oder „High“.
Beschreibung

Die Risikostufe der Änderung wird während der Bewertungsphase zugewiesen, um die potenziellen negativen Auswirkungen einer Änderung zu quantifizieren. Diese Bewertung beeinflusst häufig den Genehmigungsprozess und den erforderlichen Prüfungsumfang.

Im Process Mining dient dieses Attribut dazu, die Konsistenz von Risikobewertungen zu analysieren und Risiken mit dem Prozessverhalten in Beziehung zu setzen. So lässt sich beispielsweise prüfen, ob Änderungen mit hohem Risiko einen strengeren Genehmigungspfad durchlaufen oder längere Umsetzungszeiten aufweisen. Es unterstützt direkt das Dashboard „Change Risk Assessment Consistency“.

Warum das wichtig ist

Ermöglicht die Analyse, wie sich Risiken auf Prozessfluss, Genehmigungszyklen und Erfolgsquoten auswirken. So lässt sich sicherstellen, dass Änderungen mit hohem Risiko angemessen geprüft werden.

Bezugsquelle

Dieser Wert ist in einem Feld „Risk Level“ oder einem vergleichbaren Feld des Objekts „Change Request“ gespeichert und wird typischerweise während der Risikobewertung eingetragen.

Beispiele
NiedrigMittelHochKritisch
Verantwortlicher für die Änderung
ChangeOwner
Der Nutzer oder die Person, die derzeit für den Änderungsantrag verantwortlich ist.
Beschreibung

Der Verantwortliche für die Änderung ist die Person, die einem Änderungsantrag in einer bestimmten Phase zugewiesen wurde und dafür Rechenschaft trägt. Dieses Attribut ändert sich häufig, wenn der Antrag seinen Lebenszyklus durchläuft, und zeigt eine Übergabe zwischen Personen an.

Die Analyse des Verantwortlichen für die Änderung hilft, die Auslastung von Ressourcen zu verstehen und Engpässe bei bestimmten Personen zu erkennen. Sie ist auch grundlegend für die Analyse von Übergaben, die eine wesentliche Verzögerungsquelle sein können. Dieses Attribut unterstützt das Dashboard „Change Handoff & Resource Utilization“.

Warum das wichtig ist

Erfasst die individuelle Verantwortung und ermöglicht die Analyse der Arbeitsverteilung, der Häufigkeit von Übergaben sowie ressourcenbezogener Engpässe.

Bezugsquelle

Typischerweise das Feld „Owned By“ oder „Assigned To“ im Geschäftsobjekt „Change Request“.

Beispiele
Alice JohnsonBob WilliamsCharlie Brown
Ablehnungsgrund
ChangeRejectionReason
Eine textuelle Beschreibung oder Kategorie, die erklärt, warum ein Änderungsantrag abgelehnt wurde.
Beschreibung

Wenn ein Änderungsantrag abgelehnt wird, erfasst dieses Attribut den vom Genehmiger angegebenen Grund. Dabei kann es sich um eine Auswahl aus einer vordefinierten Liste oder um eine Freitexterklärung handeln.

Diese Information ist für das Dashboard „Rejected Change Request Analysis“ von großer Bedeutung. Durch die Kategorisierung und Analyse von Ablehnungsgründen können Unternehmen wiederkehrende Probleme bei Änderungsanträgen erkennen, etwa unvollständige Angaben, eine unzureichende Risikobewertung oder geschäftliche Konflikte. Diese Erkenntnisse lassen sich nutzen, um die Qualität künftiger Änderungsanträge zu verbessern.

Warum das wichtig ist

Liefert direkte Erkenntnisse darüber, warum Änderungen scheitern, und ermöglicht gezielte Verbesserungen des Einreichungs- und Bewertungsprozesses, um die allgemeine Ablehnungsquote zu senken.

Bezugsquelle

Diese Daten werden häufig in einem eigenen Feld „Rejection Reason“ oder in einem Notizfeld erfasst, das beim Wechsel des Status auf „Rejected“ befüllt wird.

Beispiele
Unzureichende Details im ImplementierungsplanRisikobewertung unvollständigKonflikte mit anderen eingeplanten Änderungen
Betroffener Service
ServiceAffected
Der primäre Geschäftsservice oder das Configuration Item (CI), das von der Änderung betroffen ist.
Beschreibung

Dieses Attribut identifiziert den zentralen IT-Service, die Anwendung oder die Infrastrukturkomponente, auf die der Änderungsantrag abzielt. Es verknüpft den Change-Management-Prozess mit der übergeordneten IT-Service-Management-Landschaft.

Die Analyse nach betroffenem Service ist für das KPI „Top Problematic Change Types“ entscheidend. Sie zeigt, bei welchen Services besonders häufig Änderungen vorgenommen werden und welche Services mit hohen Ablehnungsquoten oder Verzögerungen verbunden sind. Dadurch erhalten Service Owner wichtige Erkenntnisse, um die Stabilität zu verbessern und technische Schulden zu steuern.

Warum das wichtig ist

Verknüpft Änderungen mit bestimmten Geschäftsservices und ermöglicht die Analyse, welche Services besonders instabil sind oder die meisten problematischen Änderungen verursachen.

Bezugsquelle

Dies ist typischerweise mit der Configuration Management Database (CMDB) verknüpft und im Feld „Primary CI“ oder „Service“ des Objekts „Change Request“ gespeichert.

Beispiele
E-Mail-Service (Exchange)ERP-System (SAP)Core-Netzwerk-Switch (CISCO-4500X)
Einreicher der Änderung
ChangeSubmitter
Der Nutzer, der den Änderungsantrag ursprünglich erstellt oder eingereicht hat.
Beschreibung

Dieses Attribut identifiziert die Person, die den Änderungsantrag initiiert hat. Sie kann sich vom Verantwortlichen für die Änderung unterscheiden, der später im Prozess die Verantwortung für die Umsetzung übernimmt.

Die Analyse des Einreichers der Änderung kann Muster bei der Qualität von Anträgen sichtbar machen. So lässt sich beispielsweise erkennen, ob bestimmte Personen oder Teams häufig unvollständige Anträge einreichen, die zu Ablehnungen oder Nacharbeit führen. Diese Erkenntnis kann für gezielte Schulungen genutzt werden, um die Qualität der Einreichungen insgesamt zu verbessern.

Warum das wichtig ist

Hilft, die Herkunft von Änderungsanträgen nachzuverfolgen, die Qualität der Einreichungen nach Person oder Team zu analysieren und Schulungsbedarf zu erkennen.

Bezugsquelle

Dies ist üblicherweise das Feld „Created By“ oder „Requested By“ im Objekt „Change Request“.

Beispiele
Susan MillerDavid ChenMaria Garcia
Geschäftseinheit
BusinessUnit
Die Geschäftseinheit oder Abteilung, die die Änderung angefordert hat oder von ihr profitieren wird.
Beschreibung

Dieses Attribut ordnet den Änderungsantrag einem bestimmten Teil der Organisation zu, beispielsweise „Finance“, „Marketing“ oder „Operations“. Dadurch erhält ein ansonsten technischer Prozess einen geschäftlichen Kontext.

Die Analyse nach Geschäftseinheit zeigt, aus welchen Bereichen der Änderungsbedarf stammt. Sie kann bei Chargeback-Modellen helfen, die Auswirkungen von IT-Änderungen auf verschiedene Geschäftsfunktionen sichtbar machen und aufzeigen, ob bestimmte Einheiten komplexere oder stärker verzögerte Änderungen aufweisen.

Warum das wichtig ist

Liefert geschäftlichen Kontext und ermöglicht die Analyse von Änderungsbedarf, Auswirkungen und Leistung aus organisatorischer Sicht.

Bezugsquelle

Dies kann ein Feld im Objekt „Change Request“ sein oder aus dem Benutzerprofil des Antragstellers übernommen werden.

Beispiele
FinanzenPersonalwesenVertrieb und MarketingBetrieb
Priorität der Änderung
ChangePriority
Die Prioritätsstufe des Änderungsantrags, die seine Dringlichkeit und geschäftlichen Auswirkungen angibt.
Beschreibung

Die Priorität der Änderung wird anhand der Dringlichkeit und der Auswirkungen einer Änderung bestimmt. Sie hilft Teams, ihre Arbeit zu priorisieren und Ressourcen gezielt zuzuweisen, damit besonders kritische Änderungen zuerst bearbeitet werden.

In der Analyse lässt sich anhand der Priorität prüfen, ob Änderungen mit hoher Priorität schneller bearbeitet werden als Änderungen mit niedriger Priorität. Abweichungen von dieser Erwartung können auf Ineffizienzen oder Engpässe bei Priorisierung und Umsetzung hinweisen.

Warum das wichtig ist

Hilft zu analysieren, ob der Prozess Änderungen mit großen Auswirkungen richtig priorisiert und ob diese wie vorgesehen beschleunigt bearbeitet werden.

Bezugsquelle

Typischerweise ein Feld namens „Priority“ im Objekt „Change Request“. Der Wert kann manuell gesetzt oder aus den Feldern für Auswirkungen und Dringlichkeit abgeleitet werden.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
Tatsächliches Abschlussdatum
ActualCompletionDate
Der Timestamp, an dem die Änderung tatsächlich umgesetzt und als abgeschlossen verifiziert wurde.
Beschreibung

Das tatsächliche Abschlussdatum markiert den Zeitpunkt, an dem die Umsetzungsarbeiten für den Änderungsantrag beendet wurden. Dieser wichtige Meilenstein wird mit der geplanten Frist verglichen, um die Leistung zu messen.

Dieses Attribut wird zusammen mit dem geplanten Abschlussdatum verwendet, um festzustellen, ob eine Änderung termingerecht abgeschlossen wurde. Es ist ein grundlegender Eingangswert für die Berechnung der KPI „On-Time Change Completion Rate“ und für die Analyse der Ursachen von Verzögerungen in der Umsetzungsphase.

Warum das wichtig ist

Erfasst den tatsächlichen Abschlusszeitpunkt. Dieser ist erforderlich, um Termintreuequoten zu berechnen und das Ausmaß von Verzögerungen zu analysieren.

Bezugsquelle

Dieses Datum wird häufig erfasst, wenn der Status des Änderungsantrags auf „Implemented“ oder „Completed“ gesetzt wird. Es kann in einem eigenen Feld gespeichert oder aus dem Timestamp dieser Statusänderung abgeleitet werden.

Beispiele
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Termingerechter Abschluss
IsOnTimeCompletion
Ein berechnetes Kennzeichen, das den Wert „true“ hat, wenn die Änderung am oder vor dem Zieldatum abgeschlossen wurde.
Beschreibung

Dies ist ein boolesches Attribut, das durch den Vergleich von „ActualCompletionDate“ mit „TargetCompletionDate“ abgeleitet wird. Es vereinfacht die Analyse, indem es für jeden Änderungsantrag eine eindeutige binäre Kennzeichnung der Termintreue liefert.

Dieses Kennzeichen bildet die Grundlage für die Berechnung des KPI „On-Time Change Completion Rate“. Es kann in Dashboards als Filter verwendet werden, um verspätete Änderungen gezielt zu isolieren und zu analysieren sowie häufige Ursachen für Verzögerungen zu erkennen.

Warum das wichtig ist

Vereinfacht die Leistungsanalyse durch ein eindeutiges Ergebnis für die Einhaltung von Fristen und bildet direkt die Grundlage für KPIs zum termingerechten Abschluss.

Bezugsquelle

Dieses Attribut ist im Quellsystem nicht vorhanden. Es wird während der Datentransformation durch den Vergleich „ActualCompletionDate“ <= „TargetCompletionDate“ berechnet.

Beispiele
truefalse
Umsetzungszykluszeit
ImplementationCycleTime
Die berechnete Dauer vom Beginn der Umsetzung einer Änderung bis zu ihrem Abschluss.
Beschreibung

Diese Kennzahl quantifiziert die Dauer der Umsetzungsphase einer Änderung. Sie wird als Zeitspanne zwischen den Aktivitäten „Change Implementation Started“ und „Change Implemented“ berechnet.

Dieses Attribut dient zur Berechnung des KPI „Average Change Implementation Time“ und unterstützt das Dashboard „Change Implementation Flow & Delays“. Es hilft, Verzögerungen in der Planung von Verzögerungen bei der Ausführung zu unterscheiden, sodass Teams Verbesserungsmaßnahmen gezielt auf die technische Umsetzung konzentrieren können.

Warum das wichtig ist

Isoliert die Leistung der tatsächlichen Umsetzungsphase und hilft, technische oder ressourcenbezogene Engpässe unabhängig von Genehmigungsverzögerungen zu erkennen.

Bezugsquelle

Wird im Process-Mining-Tool oder während der Datentransformation berechnet, indem die Zeitdifferenz zwischen den Timestamps des Start- und Endereignisses der Umsetzung ermittelt wird.

Beispiele
4 Stunden 15 Minuten1 Tag 2 Stunden30 Minuten
Erforderlich Empfohlen Optional

Aktivitäten des Change Managements

Dies sind die wesentlichen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Prozess präzise zu erkennen und seine Leistung zu messen.
7 Empfohlen 7 Optional
Aktivität Beschreibung
Änderung geschlossen
Diese Aktivität ist der abschließende erfolgreiche Endpunkt des Change-Management-Prozesses. Sie wird erfasst, wenn der Status des Änderungsantrags auf „Closed“ gesetzt wird und alle Arbeiten abgeschlossen sind.
Warum das wichtig ist

Als zentraler Erfolgsendpunkt ist diese Aktivität für die Berechnung der End-to-End-Zykluszeit erfolgreich abgeschlossener Änderungen unerlässlich. Sie bestätigt, dass alle Prozessschritte beendet sind.

Bezugsquelle

Abgeleitet aus dem Timestamp der letzten Statusänderung auf „Closed“ in der Audit-Historie des Objekts „Change Request“.

Erfassen

Abgeleitet aus der letzten Statusänderung auf „Closed“.

Ereignistyp inferred
Änderung terminiert
Diese Aktivität markiert den Zeitpunkt, an dem Datum und Uhrzeit der Umsetzung der Änderung formell bestätigt und erfasst werden. Sie wird erfasst, wenn der Status auf „Scheduled“ aktualisiert wird.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein für die Verbindlichkeit. Die Änderung wechselt damit von einem genehmigten Konzept zu einer geplanten Maßnahme und erfüllt eine Voraussetzung für die Umsetzung.

Bezugsquelle

Abgeleitet aus der Historie des Objekts „Change Request“, indem der Timestamp erfasst wird, an dem das Feld „Status“ auf „Scheduled“ aktualisiert wird.

Erfassen

Abgeleitet aus der Statusänderung auf „Scheduled“.

Ereignistyp inferred
Änderung umgesetzt
Dieser Meilenstein zeigt an, dass die technische Arbeit an der Änderung abgeschlossen wurde. Er wird erfasst, wenn der Status des Änderungsantrags auf „Implemented“ oder einen vergleichbaren Status zur ausstehenden Verifizierung aktualisiert wird.
Warum das wichtig ist

Dies ist ein kritischer Erfolgsmeilenstein und ein wichtiger Eingangswert für die KPIs „On-Time Change Completion Rate“ und „Average Change Implementation Time“. Er markiert das Ende der Umsetzungsphase.

Bezugsquelle

Abgeleitet aus dem Audit Log des Objekts „Change Request“ anhand des Timestamps der Statusänderung auf „Implemented“ oder „Pending Verification“.

Erfassen

Abgeleitet aus der Statusänderung auf „Implemented“.

Ereignistyp inferred
Änderung vom CAB genehmigt
Ein wichtiger Meilenstein, an dem das Change Advisory Board (CAB) oder eine benannte zuständige Stelle die Genehmigung zur Umsetzung der Änderung erteilt. Dies wird abgeleitet, wenn der Status des Änderungsantrags auf „Approved“ aktualisiert wird.
Warum das wichtig ist

Diese Aktivität bildet den Endpunkt für die Messung der Genehmigungszykluszeit. Sie gibt den Prozess frei, sodass Planung und Umsetzung beginnen können, und ist entscheidend für das KPI „Change Approval Cycle Time“.

Bezugsquelle

Abgeleitet aus der Audit-Historie des Objekts „Change Request“, insbesondere anhand des Timestamps, an dem sich das Feld „Status“ auf „Approved“ ändert.

Erfassen

Abgeleitet aus der Statusänderung auf „Approved“.

Ereignistyp inferred
Auswirkungen und Risiken bewertet
Diese Aktivität bezeichnet den Abschluss der Risiko- und Auswirkungsanalyse für die Change-Anfrage. Sie wird typischerweise abgeleitet, wenn der Status der Change-Anfrage in einen Zustand wechselt, der die Genehmigungsreife anzeigt, etwa „Awaiting Approval“.
Warum das wichtig ist

Die Erfassung dieser Aktivität hilft, die Dauer der Bewertungsphase zu messen und sicherzustellen, dass vor der Genehmigung konsequent eine Risikoanalyse durchgeführt wird. Das unterstützt den KPI zur Einhaltungsquote der Risikobewertung.

Bezugsquelle

Aus der Historie des Business Objects „Change Request“ abgeleitet. Erfasst wird der Timestamp, zu dem das Feld „Status“ von „Assessing“ in einen Status wie „Awaiting CAB Approval“ geändert wird.

Erfassen

Aus dem Statuswechsel zu „Awaiting CAB Approval“ abgeleitet.

Ereignistyp inferred
Change Request erstellt
Diese Aktivität markiert den Beginn einer neuen Change-Anfrage im System. Sie wird typischerweise erfasst, wenn ein neuer Datensatz im Business Object „Change Request“ angelegt wird. Damit beginnt der gesamte Prozess.
Warum das wichtig ist

Dies ist das primäre Start-Event des Prozesses. Die Analyse der Zeit von dieser Aktivität bis zu anderen Aktivitäten zeigt die Gesamtdauer des Lebenszyklus und hilft, Verzögerungen in frühen Prozessphasen zu erkennen.

Bezugsquelle

Dieses Event wird anhand des Erstellungs-Timestamps des Change-Request-Datensatzes erfasst. In Ivanti Cherwell wird dieser üblicherweise im Feld „CreatedDateTime“ des Business Objects „Change Request“ gespeichert.

Erfassen

Direkt aus dem Timestamp der Datensatzerstellung erfasst.

Ereignistyp explicit
Review nach der Umsetzung durchgeführt
Diese Aktivität zeigt an, dass eine formelle Prüfung der abgeschlossenen Änderung stattgefunden hat, um ihren Erfolg zu bewerten und gewonnene Erkenntnisse festzuhalten. Sie wird häufig aus einer Statusänderung auf „Post Implementation Review“ abgeleitet.
Warum das wichtig ist

Die Nachverfolgung stellt sicher, dass die Feedbackschleife für Änderungen geschlossen wird. Sie ist für die kontinuierliche Verbesserung unerlässlich und unterstützt direkt das KPI „Post-Implementation Review Rate“.

Bezugsquelle

Abgeleitet aus der Audit-Historie des Objekts „Change Request“, wobei der Timestamp erfasst wird, an dem das Feld „Status“ in einen Status wie „Post Implementation Review“ wechselt.

Erfassen

Abgeleitet aus der Statusänderung auf „Post Implementation Review“.

Ereignistyp inferred
Änderung abgebrochen
Stellt einen Endstatus dar, in dem ein genehmigter oder bereits laufender Änderungsantrag vor dem Abschluss zurückgezogen wird. Dieses Ereignis wird erfasst, wenn der Status auf „Cancelled“ aktualisiert wird.
Warum das wichtig ist

Dies ist ein alternativer Prozessendpunkt. Die Analyse, warum und wann Änderungen abgebrochen werden, kann Probleme bei der Planung, Ressourcenzuweisung oder veränderte geschäftliche Prioritäten sichtbar machen.

Bezugsquelle

Abgeleitet aus der Audit-Historie, indem der Timestamp erfasst wird, an dem das Feld „Status“ des Objekts „Change Request“ auf „Cancelled“ aktualisiert wird.

Erfassen

Abgeleitet aus der Statusänderung auf „Cancelled“.

Ereignistyp inferred
Änderung abgelehnt
Diese Aktivität stellt die abschließende Entscheidung dar, den Änderungsantrag während der Genehmigungsphase abzulehnen. Sie wird erfasst, wenn der Status des Änderungsantrags auf „Rejected“ gesetzt wird.
Warum das wichtig ist

Dies ist ein kritischer Endpunkt für fehlgeschlagene Vorgänge. Die Analyse abgelehnter Änderungen und ihrer Gründe hilft, die Qualität der ursprünglichen Anträge zu verbessern, und unterstützt das KPI „Change Request Rejection Rate“.

Bezugsquelle

Abgeleitet aus dem Timestamp, an dem das Feld „Status“ des Objekts „Change Request“ in der Audit-Historie auf „Rejected“ aktualisiert wird.

Erfassen

Abgeleitet aus der Statusänderung auf „Rejected“.

Ereignistyp inferred
Change wartet auf Genehmigung
Diese Aktivität bezeichnet den Zeitraum, in dem eine Change-Anfrage offiziell auf eine Entscheidung des Change Advisory Board, CAB, oder einer anderen genehmigenden Stelle wartet. Sie wird aus einem Status wie „Pending Approval“ oder „Awaiting CAB“ abgeleitet.
Warum das wichtig ist

Dies ist eine wichtige Aktivität zur Messung der Wartezeit. Die Analyse ihrer Dauer hilft, Engpässe im Genehmigungs-Workflow zu erkennen, der im Change Management häufig eine Verzögerungsquelle darstellt.

Bezugsquelle

Erfasst anhand des Timestamps, zu dem das Feld „Status“ im Business Object „Change Request“ auf „Pending Approval“ oder einen entsprechenden Wert aktualisiert wird.

Erfassen

Durch den Eintritt in den Status „Pending Approval“ identifiziert.

Ereignistyp inferred
Change zur Bewertung eingereicht
Diese Aktivität bezeichnet die formale Einreichung einer neu erstellten Change-Anfrage zur ersten Bewertung. Sie wird in der Regel abgeleitet, wenn der Status der Change-Anfrage von „New“ oder „Draft“ in einen Status wie „Assessing“ wechselt.
Warum das wichtig ist

Diese Aktivität markiert den Beginn des formalen Change-Prozesses nach der ersten Dateneingabe. Die Zeit zwischen Erstellung und Einreichung kann auf Schulungsbedarf oder Reibung im Prozess hinweisen.

Bezugsquelle

Aus dem Audit Log oder der Historie des Business Objects „Change Request“ abgeleitet, indem der Timestamp ermittelt wird, zu dem sich das Feld „Status“ in einen Wert wie „Assessing“ oder „Submitted“ ändert.

Erfassen

Aus dem Statuswechsel von „New“ zu „Assessing“ abgeleitet.

Ereignistyp inferred
Umsetzung der Änderung gestartet
Stellt den Beginn der technischen Umsetzung der Änderung dar. Dies wird typischerweise abgeleitet, wenn der Status des Änderungsantrags auf „In Progress“ oder „Implementing“ gesetzt wird.
Warum das wichtig ist

Diese Aktivität markiert den Beginn des Umsetzungszeitraums. Die Zeit zwischen dieser Aktivität und „Change Implemented“ entspricht der tatsächlichen Umsetzungsdauer und ist ein wichtiger Bestandteil der gesamten Zykluszeit.

Bezugsquelle

Abgeleitet aus der Audit-Historie des Objekts „Change Request“. Erfasst wird der Timestamp, an dem das Feld „Status“ auf einen Wert wie „In Progress“ oder „Implementing“ aktualisiert wird.

Erfassen

Abgeleitet aus der Statusänderung auf „In Progress“.

Ereignistyp inferred
Umsetzungsplan erstellt
Kennzeichnet den Abschluss der detaillierten Planung der Änderung, einschließlich der Definition von Aufgaben, Ressourcen und Backout-Plänen. Dies wird häufig abgeleitet, wenn die Änderung von „Approved“ zu „Scheduled“ wechselt.
Warum das wichtig ist

Die Dauer dieser Aktivität zeigt, wie effizient die Änderungsplanung abläuft. Verzögerungen in dieser Phase können den gesamten Zeitplan der Änderung beeinträchtigen, selbst wenn die Genehmigung bereits erteilt wurde.

Bezugsquelle

Dies kann aus dem Timestamp der Statusänderung von „Approved“ zu „Scheduled“ abgeleitet werden. Alternativ kann die Aktivität an das Befüllen bestimmter Planungsfelder geknüpft sein.

Erfassen

Abgeleitet aus der Statusänderung von „Approved“ zu „Scheduled“.

Ereignistyp inferred
Verifizierung der Änderung durchgeführt
Stellt die Test- und Validierungsphase dar, in der bestätigt wird, dass die Änderung erfolgreich war und keine negativen Auswirkungen verursacht hat. Dies wird aus einer Statusänderung auf „Verification“ oder „Testing“ abgeleitet.
Warum das wichtig ist

Die Analyse der Häufigkeit und Dauer dieser Aktivität stellt sicher, dass Qualitätssicherungsschritte nicht übersprungen werden. Sie ist entscheidend, um durch Änderungen verursachte Incidents zu vermeiden.

Bezugsquelle

Erfasst anhand des Timestamps einer Statusänderung am Objekt „Change Request“, beispielsweise beim Wechsel in den Status „Verification“ oder „User Acceptance Testing“.

Erfassen

Abgeleitet aus der Statusänderung auf „Verification“.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Extraktion

So extrahieren Sie Ihre Daten aus Ivanti Cherwell

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Analyse des Change-Management-Prozesses schnell zu beginnen und deutliche Verbesserungen zu erzielen. Starten Sie heute den Weg zu optimierten und effizienteren Änderungen.

95 % erfolgreiche Changes sicherstellen: Optimieren Sie Ivanti Cherwell jetzt

Beseitigen Sie Engpässe, reduzieren Sie Risiken und erreichen Sie eine Erfolgsquote von 95 % bei Changes.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Starten Sie sofort.