Ihr Change Management Daten-Template
Ihr Change Management Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung von Ivanti Cherwell
Change Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name des spezifischen Events oder der Aufgabe, die zu einem bestimmten Zeitpunkt innerhalb des Change Management Prozesses aufgetreten ist. | ||
|
Beschreibung
Der Activity Name beschreibt einen spezifischen Schritt oder Meilenstein innerhalb des Lebenszyklus einer Änderungsanfrage, wie z.B. 'Change Submitted For Assessment' oder 'Change Approved by CAB'. Diese Activities bilden die Knotenpunkte in der entdeckten Prozesskarte.\n\nIn der Analyse ist dieses Attribut grundlegend, um den Prozessfluss zu visualisieren, die Ereignissequenz zu identifizieren und Abweichungen vom Standardverfahren zu erkennen. Es wird verwendet, um Übergangszeiten zwischen Activities zu berechnen und zu verstehen, wo Verzögerungen auftreten.
Bedeutung
Dieses Attribut ist entscheidend für die Entdeckung und Visualisierung des tatsächlichen Prozessflusses, um Engpässe (Bottlenecks), Nacharbeitszyklen und nicht-konforme Pfade zu identifizieren.
Datenquelle
Generiert aus Statusänderungen, Journal-Einträgen oder spezifischen Event Logs, die sich auf das Change Request-Objekt in Ivanti Cherwell beziehen.
Beispiele
Änderung zur Bewertung eingereichtÄnderung wartet auf GenehmigungÄnderung implementiert
|
|||
|
Change Request ID
ChangeRequestId
|
Die eindeutige Kennung für einen einzelnen Änderungsanfrage-Case, der alle zugehörigen Activities von der Initiierung bis zum Abschluss gruppiert. | ||
|
Beschreibung
Die Change Request ID ist der Primärschlüssel, der jede Änderungsinitiative über ihren gesamten Lebenszyklus eindeutig identifiziert. Sie dient als Case Identifier im Process Mining und verknüpft alle Events, wie Einreichung, Bewertung, Genehmigung und Implementierung, zu einer einzigen, kohärenten Prozessinstanz.\n\nDie Analyse von Daten mittels der Change Request ID ermöglicht eine vollständige End-to-End-Ansicht des Change Management Prozesses. Dies ermöglicht die Verfolgung individueller Änderungen, die Berechnung der gesamten Zykluszeiten und die Identifizierung von Prozessabweichungen oder Engpässen (Bottlenecks), die spezifisch für jede Anfrage sind.
Bedeutung
Dies ist der essentielle Case Identifier, der alle zusammenhängenden Events verbindet und es ermöglicht, den gesamten Verlauf einer Änderungsanfrage nachzuvollziehen und deren Leistung zu analysieren.
Datenquelle
Dies ist typischerweise der primäre Identifier des Change Request Business Object in Ivanti Cherwell.
Beispiele
CR-105421CR-105422CR-105423
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, der angibt, wann eine spezifische Activity oder ein Event für die Änderungsanfrage aufgetreten ist. | ||
|
Beschreibung
Event Time, auch bekannt als Timestamp, zeichnet das genaue Datum und die Uhrzeit auf, zu der eine Aktivität stattfand. Diese temporären Daten sind essenziell für die chronologische Anordnung von Events und bilden die Grundlage für alle zeitbasierten Process Mining-Analysen. Dieses Attribut wird verwendet, um Dauern zwischen Aktivitäten zu berechnen, die gesamten Case Cycle Times zu messen und Wartezeiten oder Verzögerungen im Prozess zu identifizieren. Es ist grundlegend für die Erstellung von Dashboards, die die Performance anhand zeitbasierter Ziele überwachen, wie z.B. die Change Approval Cycle Time.
Bedeutung
Dieser Timestamp ist die Grundlage für alle Performance- und Daueranalysen und ermöglicht die Berechnung von Zykluszeiten, die Identifizierung von Engpässen (Bottlenecks) und die Überwachung von SLAs.
Datenquelle
Typischerweise in Statusänderungsprotokollen, Audit Trails oder Journal-Eintrag-Timestamps zu finden, die mit dem Change Request Objekt in Ivanti Cherwell verbunden sind.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit, wann die Daten zuletzt aus Ivanti Cherwell abgerufen wurden. Es stellt kein Event im Prozess selbst dar, sondern ist Metadaten über die Aktualität der Daten.\n\nDies ist wichtig für Dashboard-Nutzer, um zu verstehen, wie aktuell die Analyse ist. Es hilft bei der Verwaltung von Datenaktualisierungszeitplänen und stellt sicher, dass Entscheidungen auf Daten eines bekannten Alters basieren.
Bedeutung
Gibt die Aktualität der Daten an, was entscheidend ist, damit Benutzer der Analyse vertrauen und deren Relevanz für den aktuellen Betriebszustand verstehen können.
Datenquelle
Dieser Timestamp wird auf jedem Record während des Data Extraction, Transformation, and Loading (ETL) Prozesses generiert und gestempelt.
Beispiele
2024-05-21T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das Quellsystem, aus dem die Daten extrahiert wurden. Für diese Ansicht wird es 'Ivanti Cherwell' sein. | ||
|
Beschreibung
Dieses Attribut identifiziert das Ursprungssystem für die Event-Daten. In heterogenen Umgebungen hilft es, Daten aus verschiedenen Quellen zu unterscheiden. Für dieses spezifische Datenmodell wird es ein konstanter Wert sein, der anzeigt, dass die Daten von Ivanti Cherwell stammen.\n\nWährend es in einem Einzelsystemmodell statisch erscheinen mag, ist es entscheidend für Data Governance, Nachvollziehbarkeit und zukünftige Integrationen mit anderen Systemen. Es gewährleistet Klarheit über die Datenherkunft und hilft bei der Verwaltung der Datenqualität.
Bedeutung
Bietet wesentlichen Kontext zum Datenursprung, was für Data Governance, Fehlerbehebung und die Sicherstellung der Nachvollziehbarkeit entscheidend ist.
Datenquelle
Dabei handelt es sich typischerweise um einen statischen Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
Ivanti Cherwell
|
|||
|
Änderungsart
ChangeType
|
Die Klassifizierung der Änderung, z.B. 'Standard', 'Normal' oder 'Emergency'. | ||
|
Beschreibung
Change Type kategorisiert die Änderungsanfrage basierend auf ihrer Art, Dringlichkeit und Auswirkung. Gängige Typen umfassen Standard (vorab genehmigt, geringes Risiko), Normal (erfordert vollständige Bewertung und Genehmigung) und Emergency (erfordert sofortige Implementierung). Dieses Attribut ermöglicht eine segmentierte Analyse, um die Prozessperformance über verschiedene Kategorien hinweg zu vergleichen. Zum Beispiel kann es helfen festzustellen, ob Notfalländerungen einem anderen, schnelleren Pfad folgen oder ob Standardänderungen wirklich mit minimaler Reibung verarbeitet werden. Es ist entscheidend für das Dashboard 'Problematic Change Type Performance'.
Bedeutung
Die Segmentierung des Prozesses nach "Change Type" ist entscheidend, um die Leistung zu vergleichen und festzustellen, ob bestimmte Kategorien, wie z.B. 'Emergency', Engpässe (Bottlenecks) oder Abweichungen verursachen.
Datenquelle
Entspricht einem Klassifizierungsfeld, wahrscheinlich 'Change Type' oder 'Category' genannt, auf dem Change Request Business-Objekt.
Beispiele
StandardNormalNotfall
|
|||
|
Change Owner
ChangeOwner
|
Der User oder die Einzelperson, die derzeit für die Änderungsanfrage verantwortlich ist. | ||
|
Beschreibung
Der Change Owner ist die Person, die einer Änderungsanfrage in einer bestimmten Phase zugewiesen ist und dafür verantwortlich zeichnet. Dieses Attribut ändert sich oft, während die Anfrage ihren Lebenszyklus durchläuft, was auf eine Übergabe zwischen Personen hinweist.\n\nDie Analyse des Change Owners hilft, die Arbeitslast der Ressourcen zu verstehen und Engpässe (Bottlenecks) im Zusammenhang mit bestimmten Personen zu identifizieren. Sie ist auch grundlegend für die Analyse von Übergaben (Handoffs), die eine erhebliche Quelle für Verzögerungen sein können. Dieses Attribut unterstützt das Dashboard 'Change Handoff & Resource Utilization'.
Bedeutung
Verfolgt die individuelle Verantwortung und ermöglicht die Analyse von Arbeitslastverteilung, Übergabehäufigkeit und ressourcenspezifischen Engpässen (Bottlenecks).
Datenquelle
Typischerweise das Feld 'Owned By' oder 'Assigned To' im Change Request Business Object.
Beispiele
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Change Risk Level
ChangeRiskLevel
|
Die bewertete Risikostufe, die mit der Änderung verbunden ist, z.B. 'Niedrig', 'Mittel' oder 'Hoch'. | ||
|
Beschreibung
Change Risk Level ist eine Klassifizierung, die während der Bewertungsphase zugewiesen wird, um die potenziellen negativen Auswirkungen einer Änderung zu quantifizieren. Diese Bewertung beeinflusst oft den Genehmigungsprozess und den erforderlichen Prüfungsaufwand. Im Process Mining wird dieses Attribut verwendet, um die Konsistenz von Risikobewertungen zu analysieren und Risiko mit Prozessverhalten zu korrelieren. Zum Beispiel kann überprüft werden, ob Hochrisiko-Änderungen einem strengeren Genehmigungspfad folgen oder längere Implementierungszeiten haben. Es unterstützt direkt das Dashboard 'Change Risk Assessment Consistency'.
Bedeutung
Ermöglicht die Analyse, wie Risiken den Process Flow, Genehmigungszyklen und Erfolgsraten beeinflussen, und hilft sicherzustellen, dass Hochrisiko-Änderungen einer angemessenen Prüfung unterzogen werden.
Datenquelle
Dieser Wert ist in einem Feld 'Risk Level' oder einem ähnlichen Feld im Change Request Objekt gespeichert, typischerweise befüllt während der Risikobewertungsaktivität.
Beispiele
NiedrigMittelHochKritisch
|
|||
|
Change Status
ChangeStatus
|
Der aktuelle oder endgültige Status der Änderungsanfrage, z.B. 'Closed', 'Rejected' oder 'In Progress'. | ||
|
Beschreibung
Change Status gibt den Status einer Änderungsanfrage zu einem bestimmten Zeitpunkt oder ihr Endergebnis an. Es ist ein kritisches Attribut zum Verständnis der Case Resolution und zur Identifizierung von Ausnahmen. In der Prozessanalyse wird dieses Attribut verwendet, um nach spezifischen Ergebnissen zu filtern, wie z.B. der Analyse nur abgelehnter oder abgebrochener Änderungen. Es treibt KPIs wie die 'Change Request Rejection Rate' an und ist essenziell für das Verständnis der allgemeinen Gesundheit und Effizienz des Change Management Prozesses.
Bedeutung
Definiert das Ergebnis einer Änderungsanfrage und ermöglicht kritische Analysen von Ablehnungsraten, Abschlussraten und der Verteilung von offenen versus geschlossenen Cases.
Datenquelle
Dies entspricht dem Feld 'Status' des Change Request Business Object in Ivanti Cherwell.
Beispiele
GenehmigtAbgelehntGeschlossenStorniertGenehmigung ausstehend
|
|||
|
Change Team
ChangeTeam
|
Das Team oder die Gruppe, die derzeit für die Änderungsanfrage verantwortlich ist. | ||
|
Beschreibung
Das Change Team ist die Gruppe oder Abteilung, die der Änderungsanfrage zugewiesen ist. Ähnlich wie der Change Owner kann sich dies während des Prozesses ändern, was eine Übertragung der Verantwortung zwischen Teams anzeigt, z.B. vom Service Desk an ein Netzwerk-Engineering-Team.\n\nDieses Attribut ist wesentlich für die Analyse von Inter-Team-Übergaben und die Identifizierung systemischer Verzögerungen, die durch spezifische Teams verursacht werden. Es hilft, Fragen zu beantworten, welche Teams überlastet sind oder wo Kommunikationsprobleme auftreten, und unterstützt direkt die 'Change Handoff & Resource Utilization'-Analyse.
Bedeutung
Identifiziert die Verantwortlichkeit auf Teamebene, was entscheidend ist für die Analyse von Prozessengpässen, die Messung der Team-Performance und das Verständnis von Übergabeverzögerungen zwischen Gruppen.
Datenquelle
Diese Information wird normalerweise im Feld 'Owned By Team' oder einem ähnlichen Gruppen-Zuweisungsfeld im Change Request Objekt gespeichert.
Beispiele
NetzwerkbetriebDatenbankverwaltungAnwendungssupport
|
|||
|
Ziel-Abschlussdatum
TargetCompletionDate
|
Der geplante oder vereinbarte Termin für den Abschluss der Änderungsimplementierung. | ||
|
Beschreibung
Das Target Completion Date ist der Timestamp, bis zu dem die Änderung vollständig implementiert und verifiziert sein soll. Dieses Datum ist oft Teil eines Service Level Agreements (SLA) und dient als primärer Leistungsmaßstab.\n\nDieses Attribut ist essenziell für die Überwachung der Pünktlichkeit und der Einhaltung von Fristen. Es wird mit dem Actual Completion Date verglichen, um die KPIs 'On-Time Change Completion Rate' und 'Change SLA Adherence Rate' zu berechnen. Es hilft, proaktiv Änderungen zu identifizieren, die Gefahr laufen, ihre Ziele zu verfehlen.
Bedeutung
Bietet die Grundlage für die Messung der Pünktlichkeit und SLA-Einhaltung, welche kritische Indikatoren für Prozesseffizienz und Zuverlässigkeit sind.
Datenquelle
Dies ist typischerweise ein spezifisches Datumsfeld im Change Request Objekt, oft beschriftet mit 'Target Date', 'Due Date' oder 'SLA Target'.
Beispiele
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Ablehnungsgrund
ChangeRejectionReason
|
Eine textuelle Beschreibung oder Kategorie, die erklärt, warum eine Änderungsanfrage abgelehnt wurde. | ||
|
Beschreibung
Wenn eine Änderungsanfrage abgelehnt wird, erfasst dieses Attribut den vom Genehmiger angegebenen Grund. Dies kann eine Auswahl aus einer vordefinierten Liste oder eine Freitext-Erklärung sein. Diese Information ist entscheidend für das Dashboard 'Analyse abgelehnter Änderungsanfragen'. Durch die Kategorisierung und Analyse von Ablehnungsgründen können Organisationen häufige Probleme bei der Einreichung von Änderungen identifizieren, wie unvollständige Informationen, unzureichende Risikobewertung oder Geschäftskonflikte. Diese Erkenntnisse können genutzt werden, um die Qualität zukünftiger Änderungsanfragen zu verbessern.
Bedeutung
Bietet direkten Einblick, warum Änderungen fehlschlagen, und ermöglicht gezielte Verbesserungen des Einreichungs- und Bewertungsprozesses, um die Gesamtablehnungsrate zu reduzieren.
Datenquelle
Diese Daten werden oft in einem dedizierten Feld 'Rejection Reason' oder einem Notizfeld erfasst, das gefüllt wird, wenn der Status auf 'Rejected' geändert wird.
Beispiele
Unzureichende Details im ImplementierungsplanRisikobewertung unvollständigKonflikte mit anderen geplanten Änderungen
|
|||
|
Betroffener Service
ServiceAffected
|
Der primäre Business Service oder das Configuration Item (CI), das von der Änderung betroffen ist. | ||
|
Beschreibung
Dieses Attribut identifiziert den Haupt-IT-Service, die Anwendung oder das Infrastrukturelement, auf das die Änderungsanfrage abzielt. Es verknüpft den Change Management Prozess mit der breiteren IT Service Management Landschaft.\n\nDie Analyse nach Service Affected ist entscheidend für den KPI 'Top Problematic Change Types', da sie hilft, genau zu bestimmen, welche Services am häufigsten Änderungen unterliegen und welche mit hohen Ablehnungsraten oder Verzögerungen verbunden sind. Dies liefert wertvolle Einblicke für Service Owner, um die Stabilität zu verbessern und technische Schulden zu managen.
Bedeutung
Verknüpft Änderungen mit spezifischen Business Services und ermöglicht eine Analyse, um zu identifizieren, welche Services am instabilsten sind oder die problematischsten Änderungen hervorrufen.
Datenquelle
Dies ist typischerweise mit der Configuration Management Database (CMDB) verknüpft und in einem 'Primary CI'- oder 'Service'-Feld im Change Request Objekt gespeichert.
Beispiele
E-Mail-Dienst (Exchange)ERP-System (SAP)Core-Netzwerk-Switch (CISCO-4500X)
|
|||
|
Change Priority
ChangePriority
|
Die Prioritätsstufe der Änderungsanfrage, die deren Dringlichkeit und geschäftliche Auswirkungen angibt. | ||
|
Beschreibung
Change Priority ist eine Klassifizierung, die durch die Kombination von Dringlichkeit und Auswirkung einer Änderung bestimmt wird. Sie hilft Teams, ihre Arbeit zu priorisieren und Ressourcen effektiv zuzuweisen, um sicherzustellen, dass die kritischsten Änderungen zuerst behandelt werden. In der Analyse kann die Priorität verwendet werden, um zu sehen, ob hochpriorisierte Änderungen schneller als niedrigpriorisierte verarbeitet werden. Jede Abweichung von dieser Erwartung könnte auf Ineffizienzen oder Engpässe im Priorisierungs- oder Ausführungsprozess hinweisen.
Bedeutung
Hilft zu analysieren, ob der Prozess hochwirksame Änderungen korrekt priorisiert und ob diese Änderungen tatsächlich wie beabsichtigt beschleunigt werden.
Datenquelle
Typischerweise ein Feld namens 'Priority' im Change Request Objekt. Es kann manuell gesetzt oder aus Impact- und Dringlichkeitsfeldern abgeleitet werden.
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
|
|||
|
Change Submitter
ChangeSubmitter
|
Der User, der die Änderungsanfrage ursprünglich erstellt oder eingereicht hat. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, die die Änderungsanfrage initiiert hat. Dies kann sich vom Change Owner unterscheiden, der später im Prozess die Verantwortung für die Implementierung übernimmt.\n\nDie Analyse des Change Submitters kann helfen, Muster bezüglich der Anfragequalität zu identifizieren. Zum Beispiel könnte sie aufdecken, dass bestimmte Einzelpersonen oder Teams häufig unvollständige Anfragen einreichen, die zu Ablehnung oder Nacharbeit führen. Diese Erkenntnis kann genutzt werden, um gezielte Schulungen anzubieten und die Gesamtqualität der Einreichungen zu verbessern.
Bedeutung
Hilft, den Ursprung von Änderungsanfragen nachzuvollziehen, was die Analyse der Einreichungsqualität nach Einzelperson oder Team ermöglicht und Möglichkeiten für Schulungen identifiziert.
Datenquelle
Dies ist normalerweise das Feld 'Created By' oder 'Requested By' im Change Request Objekt.
Beispiele
Susan MillerDavid ChenMaria Garcia
|
|||
|
Freigabe-Durchlaufzeit
ApprovalCycleTime
|
Die berechnete Dauer von der Einreichung einer Änderung zur Genehmigung bis zum Erhalt der endgültigen Genehmigung. | ||
|
Beschreibung
Diese Metrik misst die verstrichene Zeit zwischen wichtigen Genehmigungsmeilensteinen. Sie wird auf Case-Ebene berechnet, indem die Zeitdifferenz zwischen dem Event 'Change Submitted For Assessment' und dem Event 'Change Approved by CAB' ermittelt wird.\n\nDiese berechnete Dauer ist die Kernmetrik für das Dashboard 'Change Approval Cycle Time' und den zugehörigen KPI. Die Analyse ihrer Verteilung hilft, Engpässe (Bottlenecks) in der Genehmigungsphase genau zu bestimmen, sei es im Zusammenhang mit spezifischen Genehmigern, Teams oder Änderungsarten.
Bedeutung
Misst direkt die Effizienz der Genehmigungsphase und hilft dabei, Verzögerungen bei der Autorisierung von Änderungen für die Implementierung zu identifizieren und zu eliminieren.
Datenquelle
Berechnet während der Daten-Nachverarbeitung oder innerhalb des Process Mining Tools durch Messung der Dauer zwischen den Timestamps spezifischer genehmigungsrelevanter Aktivitäten.
Beispiele
2 Tage 4 Stunden18 Stunden 30 Minuten5 Tage
|
|||
|
Geschäftseinheit
BusinessUnit
|
Die Geschäftseinheit oder Abteilung, die die Änderung angefordert hat oder von ihr profitieren wird. | ||
|
Beschreibung
Dieses Attribut verknüpft die Änderungsanfrage mit einem spezifischen Teil der Organisation, wie z.B. 'Finance', 'Marketing' oder 'Operations'. Dies liefert Geschäftskontext für einen ansonsten technischen Prozess.\n\nDie Analyse nach Business Unit ermöglicht einen Überblick darüber, wo der Bedarf an Änderungen entsteht. Sie kann bei Verrechnungsmodellen, dem Verständnis der Auswirkungen von IT-Änderungen auf verschiedene Geschäftsfunktionen und der Identifizierung helfen, ob bestimmte Einheiten komplexere oder verzögerte Änderungen als andere haben.
Bedeutung
Bietet Geschäftskontext und ermöglicht die Analyse von Änderungsbedarf, Auswirkungen und Leistung aus einer organisationalen Perspektive.
Datenquelle
Dies könnte ein Feld im Change Request Objekt sein oder aus dem User Profil des Anfragenden übernommen werden.
Beispiele
FinanzenPersonalwesenVertrieb und MarketingVorgänge
|
|||
|
Implementierungszykluszeit
ImplementationCycleTime
|
Die berechnete Dauer von Beginn bis Abschluss einer Änderungsimplementierung. | ||
|
Beschreibung
Diese Metrik quantifiziert die für die Implementierungsphase der Änderung benötigte Zeit. Sie wird als Dauer zwischen der Activity 'Change Implementation Started' und der Activity 'Change Implemented' berechnet.\n\nDieses Attribut wird verwendet, um den KPI 'Average Change Implementation Time' zu berechnen und unterstützt das Dashboard 'Change Implementation Flow & Delays'. Es hilft, Planungsverzögerungen von Ausführungsverzögerungen zu unterscheiden, wodurch Teams Verbesserungsmaßnahmen auf die technische Implementierungsarbeit selbst konzentrieren können.
Bedeutung
Isoliert die Leistung der eigentlichen Implementierungsphase und hilft, technische oder ressourcenbedingte Engpässe getrennt von Genehmigungsverzögerungen zu identifizieren.
Datenquelle
Berechnet im Process Mining Tool oder während der Datentransformation durch Ermittlung der Zeitdifferenz zwischen den Timestamps für Start- und End-Events der Implementierung.
Beispiele
4 Stunden 15 Minuten1 Tag 2 Stunden30 Minuten
|
|||
|
Pünktlicher Abschluss
IsOnTimeCompletion
|
Ein berechnetes Flag, das `true` ist, wenn die Änderung am oder vor dem Zieldatum abgeschlossen wurde. | ||
|
Beschreibung
Dies ist ein boolesches Attribut, das durch den Vergleich von 'ActualCompletionDate' <= 'TargetCompletionDate' abgeleitet wird. Es vereinfacht die Analyse, indem es einen klaren, binären Indikator für die pünktliche Leistung jeder Änderungsanfrage liefert.\n\nDieses Flag ist die Grundlage für die Berechnung des KPIs 'On-Time Change Completion Rate'. Es kann als Filter in Dashboards verwendet werden, um verspätete Änderungen leicht zu isolieren und zu analysieren und so gemeinsame Grundursachen für Verzögerungen zu identifizieren.
Bedeutung
Vereinfacht die Leistungsanalyse durch ein klares Erfolgs- oder Missergebnis beim Einhalten von Fristen und speist direkt die KPIs für den pünktlichen Abschluss.
Datenquelle
Dieses Attribut ist nicht im Quellsystem vorhanden. Es wird während der Datentransformation berechnet, indem 'ActualCompletionDate' <= 'TargetCompletionDate' verglichen wird.
Beispiele
truefalsch
|
|||
|
Tatsächliches Abschlussdatum
ActualCompletionDate
|
Der Timestamp, wann die Änderung tatsächlich implementiert und als abgeschlossen verifiziert wurde. | ||
|
Beschreibung
Das Actual Completion Date markiert den Zeitpunkt, zu dem die Implementierungsarbeiten für die Änderungsanfrage abgeschlossen wurden. Dies ist ein wichtiger Meilenstein, der mit der geplanten Frist verglichen wird, um die Leistung zu messen.\n\nDieses Attribut wird in Verbindung mit dem Target Completion Date verwendet, um festzustellen, ob eine Änderung pünktlich abgeschlossen wurde. Es ist eine grundlegende Eingabe zur Berechnung von KPIs wie der 'On-Time Change Completion Rate' und zur Analyse der Ursachen von Verzögerungen in der Implementierungsphase.
Bedeutung
Erfasst die tatsächliche Abschlusszeit, die notwendig ist, um On-Time-Lieferraten zu berechnen und das Ausmaß von Verzögerungen zu analysieren.
Datenquelle
Dieses Datum wird oft erfasst, wenn der Status der Änderungsanfrage auf 'Implemented' oder 'Completed' gesetzt wird. Es kann ein dediziertes Feld sein oder aus dem Timestamp dieser Statusänderung abgeleitet werden.
Beispiele
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
Change Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Änderung durch CAB genehmigt
|
Ein wichtiger Meilenstein, bei dem das Change Advisory Board (CAB) oder die benannte Autorität die Genehmigung erteilt, damit die Änderung fortfährt. Dies wird abgeleitet, wenn der Status der Änderungsanfrage auf 'Approved' aktualisiert wird. | ||
|
Bedeutung
Diese Activity ist der Endpunkt zur Messung der Genehmigungszykluszeit. Sie entblockt den Prozess, ermöglicht den Beginn der Planung und Implementierung und ist entscheidend für den Change Approval Cycle Time KPI.
Datenquelle
Abgeleitet aus der Audit-Historie des Change Request-Objekts, speziell durch Erfassung des Zeitstempels, wenn sich das Feld 'Status' in 'Approved' ändert.
Erfassen
Abgeleitet aus der Statusänderung zu 'Approved'.
Ereignistyp
inferred
|
|||
|
Änderung geplant
|
Diese Activity markiert den Zeitpunkt, zu dem das Implementierungsdatum und die Uhrzeit für die Änderung formell bestätigt und erfasst werden. Sie wird erfasst, wenn der Status auf 'Scheduled' aktualisiert wird. | ||
|
Bedeutung
Dies ist ein wichtiger Verpflichtungsmeilenstein. Er überführt die Änderung von einem genehmigten Konzept in eine geplante Aktion und ist eine Voraussetzung für die Implementierung.
Datenquelle
Abgeleitet aus der Historie des Change Request-Objekts durch Erfassung des Zeitstempels, wenn das Feld 'Status' auf 'Scheduled' aktualisiert wird.
Erfassen
Abgeleitet aus der Statusänderung zu 'Scheduled'.
Ereignistyp
inferred
|
|||
|
Änderung geschlossen
|
Diese Activity ist der finale, erfolgreiche Endpunkt des Change Management Prozesses. Sie wird erfasst, wenn der Status der Änderungsanfrage auf 'Closed' gesetzt wird, was bedeutet, dass alle Arbeiten abgeschlossen sind. | ||
|
Bedeutung
Als primärer Erfolgsendpunkt ist diese Aktivität essenziell für die Berechnung der End-to-End-Zykluszeit erfolgreich abgeschlossener Änderungen. Sie bestätigt, dass alle Prozessschritte abgeschlossen wurden.
Datenquelle
Dies wird aus dem Timestamp der finalen Statusänderung zu 'Closed' in der Audit-Historie des Change Request-Objekts abgeleitet.
Erfassen
Abgeleitet aus der endgültigen Statusänderung zu 'Closed'.
Ereignistyp
inferred
|
|||
|
Änderung implementiert
|
Dieser Meilenstein zeigt an, dass die technischen Arbeiten für die Änderung abgeschlossen wurden. Er wird erfasst, wenn der Status der Änderungsanfrage auf 'Implemented' oder einen ähnlichen Zustand, der die Verifizierung abwartet, aktualisiert wird. | ||
|
Bedeutung
Dies ist ein kritischer Erfolgsmeilenstein und eine wichtige Eingabe für die KPIs On-Time Change Completion Rate und Average Change Implementation Time. Es markiert das Ende der Ausführungsphase.
Datenquelle
Abgeleitet aus dem Audit-Log des Change Request-Objekts, unter Verwendung des Zeitstempels der Statusänderung auf 'Implemented' oder 'Pending Verification'.
Erfassen
Abgeleitet aus der Statusänderung zu 'Implemented'.
Ereignistyp
inferred
|
|||
|
Auswirkungen und Risiken bewertet
|
Diese Activity bedeutet den Abschluss der Risiko- und Auswirkungsanalyse für die Änderungsanfrage. Sie wird typischerweise abgeleitet, wenn der Status der Änderungsanfrage in einen Zustand übergeht, der die Bereitschaft zur Genehmigung anzeigt, z.B. 'Awaiting Approval'. | ||
|
Bedeutung
Die Verfolgung dieser Activity hilft, die Dauer der Bewertungsphase zu messen und stellt sicher, dass die Risikoanalyse konsistent vor der Genehmigung durchgeführt wird, was den KPI Risk Assessment Adherence Rate unterstützt.
Datenquelle
Abgeleitet aus der Historie des Change Request-Objekts. Dies wird zum Zeitpunkt erfasst, an dem das Feld 'Status' von 'Assessing' auf einen Status wie 'Awaiting CAB Approval' aktualisiert wird.
Erfassen
Abgeleitet aus der Statusänderung zu 'Awaiting CAB Approval'.
Ereignistyp
inferred
|
|||
|
Change Request erstellt
|
Diese Activity markiert die Initiierung einer neuen Änderungsanfrage im System. Sie wird typischerweise erfasst, wenn ein neuer Record im Change Request Business Object erstellt wird, wodurch der Startpunkt für den gesamten Prozess festgelegt wird. | ||
|
Bedeutung
Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Activity zu anderen zeigt die gesamte Lebenszyklusdauer und hilft, anfängliche Verzögerungen zu identifizieren.
Datenquelle
Dieses Event wird vom Erstellungs-Timestamp des Change Request Records erfasst. In Ivanti Cherwell ist dies typischerweise im Feld 'CreatedDateTime' des Change Request Business Object gespeichert.
Erfassen
Direkt vom Timestamp der Datensatzerstellung erfasst.
Ereignistyp
explicit
|
|||
|
Post-Implementation Review durchgeführt
|
Diese Activity bedeutet, dass eine formale Überprüfung der abgeschlossenen Änderung stattgefunden hat, um deren Erfolg zu bewerten und Lernerfahrungen zu erfassen. Sie wird oft durch eine Statusänderung zu 'Post Implementation Review' abgeleitet. | ||
|
Bedeutung
Die Verfolgung dessen stellt sicher, dass die Feedbackschleife bei Änderungen geschlossen wird. Sie ist essentiell für kontinuierliche Verbesserung und unterstützt direkt den Post-Implementation Review Rate KPI.
Datenquelle
Abgeleitet aus der Audit-Historie des Change Request-Objekts, wobei der Zeitstempel erfasst wird, wenn der 'Status' in einen Zustand wie 'Post Implementation Review' wechselt.
Erfassen
Abgeleitet aus der Statusänderung zu 'Post Implementation Review'.
Ereignistyp
inferred
|
|||
|
Änderung abgebrochen
|
Stellt einen Endzustand dar, in dem eine genehmigte oder in Bearbeitung befindliche Änderungsanfrage vor dem Abschluss zurückgezogen wird. Dieses Event wird erfasst, wenn der Status auf 'Cancelled' aktualisiert wird. | ||
|
Bedeutung
Dies ist ein alternativer Prozessendpunkt. Die Analyse, warum und wann Änderungen abgebrochen werden, kann Probleme bei der Planung, Ressourcenallokation oder sich ändernden Geschäftsprioritäten aufdecken.
Datenquelle
Abgeleitet aus der Audit-Historie durch Erfassung des Zeitstempels, wenn das Feld 'Status' des Change Request-Objekts auf 'Cancelled' aktualisiert wird.
Erfassen
Abgeleitet aus der Statusänderung zu 'Cancelled'.
Ereignistyp
inferred
|
|||
|
Änderung abgelehnt
|
Diese Activity repräsentiert die endgültige Entscheidung, die Änderungsanfrage während der Genehmigungsphase abzulehnen. Sie wird erfasst, wenn der Status der Änderungsanfrage auf 'Rejected' gesetzt wird. | ||
|
Bedeutung
Dies ist ein kritischer Fehlerendpunkt. Die Analyse abgelehnter Änderungen und deren Gründe hilft, die Qualität der ursprünglichen Anfragen zu verbessern und unterstützt den Change Request Rejection Rate KPI.
Datenquelle
Abgeleitet aus dem Zeitstempel, wenn das Feld 'Status' des Change Request-Objekts in der Audit-Historie auf 'Rejected' aktualisiert wird.
Erfassen
Abgeleitet aus der Statusänderung zu 'Rejected'.
Ereignistyp
inferred
|
|||
|
Änderung wartet auf Genehmigung
|
Diese Activity repräsentiert den Zeitraum, in dem eine Änderungsanfrage formal auf eine Entscheidung des Change Advisory Boards (CAB) oder einer anderen Genehmigungsinstanz wartet. Sie wird aus einem Status wie 'Pending Approval' oder 'Awaiting CAB' abgeleitet. | ||
|
Bedeutung
Dies ist eine kritische Wartezeit-Activity. Die Analyse ihrer Dauer hilft, Engpässe (Bottlenecks) im Genehmigungs-Workflow zu identifizieren, was eine häufige Ursache für Verzögerungen im Change Management ist.
Datenquelle
Erfasst vom Timestamp, wann das Feld 'Status' am Change Request Business-Objekt auf 'Pending Approval' oder einen äquivalenten Wert aktualisiert wird.
Erfassen
Identifiziert durch den Eintritt in den Status 'Pending Approval'.
Ereignistyp
inferred
|
|||
|
Änderung zur Bewertung eingereicht
|
Stellt die formale Einreichung einer neu erstellten Änderungsanfrage zur ersten Bewertung dar. Dies wird im Allgemeinen abgeleitet, wenn der Status der Änderungsanfrage von einem 'New'- oder 'Draft'-Zustand in einen Status wie 'Assessing' übergeht. | ||
|
Bedeutung
Diese Activity markiert den Beginn des formalen Änderungsprozesses nach der ersten Dateneingabe. Die Zeit zwischen Erstellung und Einreichung kann auf Schulungsbedarf der Benutzer oder Prozessreibung hinweisen.
Datenquelle
Abgeleitet aus dem Audit-Log oder der Historie des Change Request-Objekts durch Identifizierung des Zeitstempels, wenn das Feld 'Status' auf einen Wert wie 'Assessing' oder 'Submitted' wechselt.
Erfassen
Abgeleitet aus der Statusänderung von 'New' zu 'Assessing'.
Ereignistyp
inferred
|
|||
|
Änderungsimplementierung gestartet
|
Repräsentiert den Beginn der technischen Ausführung der Änderung. Dies wird typischerweise abgeleitet, wenn der Status der Änderungsanfrage auf 'In Progress' oder 'Implementing' gesetzt wird. | ||
|
Bedeutung
Diese Activity markiert den Beginn des Implementierungsfensters. Die Zeit zwischen dieser und 'Change Implemented' ist die tatsächliche Implementierungsdauer, eine Schlüsselkomponente der gesamten Zykluszeit.
Datenquelle
Abgeleitet aus der Audit-Historie des Change Request-Objekts. Es ist der Zeitstempel, wenn das Feld 'Status' auf einen Wert wie 'In Progress' oder 'Implementing' aktualisiert wird.
Erfassen
Abgeleitet aus der Statusänderung zu 'In Progress'.
Ereignistyp
inferred
|
|||
|
Änderungsverifizierung durchgeführt
|
Repräsentiert die Test- und Validierungsphase, um zu bestätigen, dass die Änderung erfolgreich war und keine nachteiligen Auswirkungen verursachte. Dies wird aus einer Statusänderung zu 'Verification' oder 'Testing' abgeleitet. | ||
|
Bedeutung
Die Analyse der Häufigkeit und Dauer dieser Aktivität stellt sicher, dass Qualitätssicherungsschritte nicht übersprungen werden. Es ist ein entscheidender Schritt zur Vermeidung von durch Änderungen verursachten Vorfällen.
Datenquelle
Erfasst vom Timestamp einer Statusänderung am Change Request-Objekt, wie z.B. dem Wechsel zu einem Status wie 'Verifizierung' oder 'User Acceptance Testing'.
Erfassen
Abgeleitet aus der Statusänderung zu 'Verification'.
Ereignistyp
inferred
|
|||
|
Implementierungsplan entwickelt
|
Markiert den Abschluss der detaillierten Planung für die Änderung, einschließlich der Definition von Aufgaben, Ressourcen und Rücksetzplänen. Dies wird oft abgeleitet, wenn die Änderung von 'Approved' zu 'Scheduled' wechselt. | ||
|
Bedeutung
Die Dauer dieser Activity zeigt die Effizienz der Änderungsplanungsphase auf. Verzögerungen hier können den gesamten Zeitplan der Änderung beeinflussen, selbst nach erteilter Genehmigung.
Datenquelle
Dies kann aus dem Timestamp einer Statusänderung von 'Approved' zu 'Scheduled' abgeleitet werden. Alternativ könnte es mit der Befüllung spezifischer Planungsfelder verknüpft sein.
Erfassen
Abgeleitet aus der Statusänderung von 'Approved' zu 'Scheduled'.
Ereignistyp
inferred
|
|||