Ihr Daten-Template für Change Management
Ihr Daten-Template für Change Management
- Empfohlene Attribute für die Erfassung
- Zentrale Aktivitäten zur Nachverfolgung
- Hinweise zur Extraktion aus Ivanti Cherwell
Attribute des Change Managements
| 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
|
|||
Aktivitäten des Change Managements
| 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
|
|||
Anleitungen zur Extraktion
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.
Keine Kreditkarte erforderlich. Starten Sie sofort.