Your Change Management Data Template
Your Change Management Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance from Ivanti Cherwell
Change Management Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity Name
ActivityName
|
The name of the specific event or task that occurred at a point in time within the change management process. | ||
|
Description
The Activity Name describes a specific step or milestone within the lifecycle of a change request, such as 'Change Submitted For Assessment' or 'Change Approved by CAB'. These activities form the nodes in the discovered process map. In analysis, this attribute is fundamental for visualizing the process flow, identifying the sequence of events, and detecting deviations from the standard procedure. It is used to calculate transition times between activities and understand where delays occur.
Why it matters
This attribute is crucial for discovering and visualizing the actual process flow, allowing for the identification of bottlenecks, rework loops, and non-compliant paths.
Where to get
Generated from status changes, journal entries, or specific event logs related to the Change Request object in Ivanti Cherwell.
Examples
Change Submitted For AssessmentChange Awaiting ApprovalChange Implemented
|
|||
|
Change Request ID
ChangeRequestId
|
The unique identifier for a single change request case, grouping all related activities from initiation to closure. | ||
|
Description
The Change Request ID is the primary key that uniquely identifies each change initiative throughout its lifecycle. It serves as the case identifier in process mining, linking all events, such as submission, assessment, approval, and implementation, into a single, cohesive process instance. Analyzing data using the Change Request ID allows for a complete end-to-end view of the change management process. This enables the tracking of individual changes, calculation of total cycle times, and identification of process deviations or bottlenecks specific to each request.
Why it matters
This is the essential case identifier that connects all related events, making it possible to trace the entire journey of a change request and analyze its performance.
Where to get
This is typically the primary identifier of the Change Request business object in Ivanti Cherwell.
Examples
CR-105421CR-105422CR-105423
|
|||
|
Event Time
EventTime
|
The timestamp indicating when a specific activity or event occurred for the change request. | ||
|
Description
Event Time, also known as the timestamp, records the exact date and time that an activity took place. This temporal data is essential for ordering events chronologically and forms the basis for all time-based process mining analysis. This attribute is used to calculate durations between activities, measure overall case cycle times, and identify waiting times or delays in the process. It is fundamental for creating dashboards that monitor performance against time-based targets, such as the Change Approval Cycle Time.
Why it matters
This timestamp is the foundation for all performance and duration analysis, enabling the calculation of cycle times, identification of bottlenecks, and monitoring of SLAs.
Where to get
Typically found in status change logs, audit trails, or journal entry timestamps associated with the Change Request object in Ivanti Cherwell.
Examples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating when the data for this event was last extracted or refreshed from the source system. | ||
|
Description
This attribute records the date and time when the data was last pulled from Ivanti Cherwell. It does not represent an event in the process itself but is metadata about the freshness of the data. This is important for dashboard consumers to understand how current the analysis is. It helps in managing data refresh schedules and ensures that decisions are based on data of a known age.
Why it matters
Indicates the freshness of the data, which is critical for users to trust the analysis and understand its relevance to the current state of operations.
Where to get
This timestamp is generated and stamped on each record during the data extraction, transformation, and loading (ETL) process.
Examples
2024-05-21T02:00:00Z
|
|||
|
Source System
SourceSystem
|
The system of record from which the data was extracted. For this view, it will be 'Ivanti Cherwell'. | ||
|
Description
This attribute identifies the originating system for the event data. In heterogeneous environments, it helps distinguish data from different sources. For this specific data model, it will be a constant value indicating the data comes from Ivanti Cherwell. While it may seem static in a single-source model, it is crucial for data governance, traceability, and future integrations with other systems. It ensures clarity on data provenance and helps in managing data quality.
Why it matters
Provides essential context about the data's origin, which is crucial for data governance, troubleshooting, and ensuring traceability.
Where to get
This is typically a static value added during the data extraction and transformation process to label the dataset's origin.
Examples
Ivanti Cherwell
|
|||
|
Change Owner
ChangeOwner
|
The user or individual currently responsible for the change request. | ||
|
Description
The Change Owner is the person assigned to and accountable for the change request at a specific stage. This attribute often changes as the request moves through its lifecycle, indicating a handoff between individuals. Analyzing the Change Owner helps in understanding resource workload and identifying bottlenecks related to specific individuals. It is also fundamental for analyzing handoffs, which can be a significant source of delays. This attribute supports the 'Change Handoff & Resource Utilization' dashboard.
Why it matters
Tracks individual responsibility, enabling analysis of workload distribution, handoff frequency, and resource-specific bottlenecks.
Where to get
Typically the 'Owned By' or 'Assigned To' field in the Change Request business object.
Examples
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Change Risk Level
ChangeRiskLevel
|
The assessed risk level associated with the change, such as 'Low', 'Medium', or 'High'. | ||
|
Description
Change Risk Level is a classification assigned during the assessment phase to quantify the potential negative impact of a change. This assessment often influences the approval process and the level of scrutiny required. In process mining, this attribute is used to analyze the consistency of risk assessments and to correlate risk with process behavior. For example, one can check if high-risk changes follow a more rigorous approval path or if they have longer implementation times. It directly supports the 'Change Risk Assessment Consistency' dashboard.
Why it matters
Enables analysis of how risk impacts the process flow, approval cycles, and success rates, helping to ensure that high-risk changes receive appropriate scrutiny.
Where to get
This value is stored in a 'Risk Level' or similar field on the Change Request object, typically populated during the risk assessment activity.
Examples
LowMediumHighCritical
|
|||
|
Change Status
ChangeStatus
|
The current or final status of the change request, such as 'Closed', 'Rejected', or 'In Progress'. | ||
|
Description
Change Status indicates the state of a change request at a given point in time or its final outcome. It is a critical attribute for understanding case resolution and identifying exceptions. In process analysis, this attribute is used to filter for specific outcomes, such as analyzing only rejected or cancelled changes. It powers KPIs like the 'Change Request Rejection Rate' and is essential for understanding the overall health and efficiency of the change management process.
Why it matters
Defines the outcome of a change request, enabling critical analyses on rejection rates, completion rates, and the distribution of open versus closed cases.
Where to get
This corresponds to the 'Status' field on the Change Request business object in Ivanti Cherwell.
Examples
ApprovedRejectedClosedCancelledAwaiting Approval
|
|||
|
Change Team
ChangeTeam
|
The team or group currently responsible for the change request. | ||
|
Description
The Change Team is the group or department assigned to the change request. Similar to the Change Owner, this can change throughout the process, indicating a transfer of responsibility between teams, such as from the service desk to a network engineering team. This attribute is essential for analyzing inter-team handoffs and identifying systemic delays caused by specific teams. It helps answer questions about which teams are overloaded or where communication breakdowns occur, directly supporting the 'Change Handoff & Resource Utilization' analysis.
Why it matters
Identifies team-level responsibility, which is key for analyzing process bottlenecks, measuring team performance, and understanding handoff delays between groups.
Where to get
This information is usually stored in the 'Owned By Team' or a similar group assignment field on the Change Request object.
Examples
Network OperationsDatabase AdministrationApplication Support
|
|||
|
Change Type
ChangeType
|
The classification of the change, such as 'Standard', 'Normal', or 'Emergency'. | ||
|
Description
Change Type categorizes the change request based on its nature, urgency, and impact. Common types include Standard (pre-approved, low-risk), Normal (requires full assessment and approval), and Emergency (requires immediate implementation). This attribute allows for segmented analysis to compare process performance across different categories. For instance, it can help determine if emergency changes follow a different, faster path or if standard changes are truly processed with minimal friction. It is key for the 'Problematic Change Type Performance' dashboard.
Why it matters
Segmenting the process by Change Type is crucial for comparing performance and identifying if specific categories, like 'Emergency', are causing bottlenecks or deviations.
Where to get
Corresponds to a classification field, likely named 'Change Type' or 'Category', on the Change Request business object.
Examples
StandardNormalEmergency
|
|||
|
Target Completion Date
TargetCompletionDate
|
The planned or agreed-upon deadline for the completion of the change implementation. | ||
|
Description
The Target Completion Date is the timestamp by which the change is expected to be fully implemented and verified. This date is often part of a Service Level Agreement (SLA) and serves as a primary benchmark for performance. This attribute is essential for monitoring timeliness and adherence to deadlines. It is compared against the actual completion date to calculate the 'On-Time Change Completion Rate' and 'Change SLA Adherence Rate' KPIs. It helps in proactively identifying changes that are at risk of missing their targets.
Why it matters
Provides the baseline for measuring on-time performance and SLA adherence, which are critical indicators of process efficiency and reliability.
Where to get
This is typically a specific date field on the Change Request object, often labeled 'Target Date', 'Due Date', or 'SLA Target'.
Examples
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Actual Completion Date
ActualCompletionDate
|
The timestamp when the change was actually implemented and verified as complete. | ||
|
Description
The Actual Completion Date marks the moment the implementation work for the change request was finished. This is a key milestone that is compared against the planned deadline to measure performance. This attribute is used in conjunction with the Target Completion Date to determine if a change was completed on time. It is a fundamental input for calculating KPIs like 'On-Time Change Completion Rate' and for analyzing the causes of delays in the implementation phase.
Why it matters
Captures the actual completion time, which is necessary to calculate on-time delivery rates and analyze the magnitude of delays.
Where to get
This date is often recorded when the change request status is moved to 'Implemented' or 'Completed'. It may be a dedicated field or inferred from the timestamp of that status change.
Examples
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
Approval Cycle Time
ApprovalCycleTime
|
The calculated duration from when a change was submitted for approval to when it received final approval. | ||
|
Description
This metric measures the time elapsed between key approval milestones. It is calculated at the case level by finding the time difference between the 'Change Submitted For Assessment' event and the 'Change Approved by CAB' event. This calculated duration is the core metric for the 'Change Approval Cycle Time' dashboard and the associated KPI. Analyzing its distribution helps pinpoint bottlenecks in the approval phase, whether they are related to specific approvers, teams, or change types.
Why it matters
Directly measures the efficiency of the approval phase, helping to identify and eliminate delays in getting changes authorized for implementation.
Where to get
Calculated during data post-processing or within the process mining tool by measuring the duration between the timestamps of specific approval-related activities.
Examples
2 days 4 hours18 hours 30 minutes5 days
|
|||
|
Business Unit
BusinessUnit
|
The business unit or department that requested or will benefit from the change. | ||
|
Description
This attribute associates the change request with a specific part of the organization, such as 'Finance', 'Marketing', or 'Operations'. This provides business context to an otherwise technical process. Analyzing by Business Unit allows for a view of where the demand for change originates. It can help in chargeback models, understanding the impact of IT changes on different business functions, and identifying if certain units have more complex or delayed changes than others.
Why it matters
Provides business context, enabling analysis of change demand, impact, and performance from an organizational perspective.
Where to get
This could be a field on the Change Request object, or inherited from the requester's user profile.
Examples
FinanceHuman ResourcesSales and MarketingOperations
|
|||
|
Change Priority
ChangePriority
|
The priority level of the change request, indicating its urgency and business impact. | ||
|
Description
Change Priority is a classification determined by combining the urgency and impact of a change. It helps teams prioritize their work and allocate resources effectively, ensuring that the most critical changes are addressed first. In analysis, priority can be used to see if high-priority changes are processed faster than low-priority ones. Any deviation from this expectation could indicate inefficiencies or bottlenecks in the prioritization or execution process.
Why it matters
Helps analyze if the process correctly prioritizes high-impact changes and if those changes are truly expedited as intended.
Where to get
Typically a field named 'Priority' on the Change Request object. It may be set manually or derived from impact and urgency fields.
Examples
1 - Critical2 - High3 - Medium4 - Low
|
|||
|
Change Submitter
ChangeSubmitter
|
The user who initially created or submitted the change request. | ||
|
Description
This attribute identifies the person who initiated the change request. This may be different from the Change Owner, who takes responsibility for its implementation later in the process. Analyzing the Change Submitter can help identify patterns related to request quality. For example, it might reveal that certain individuals or teams frequently submit incomplete requests that lead to rejection or rework. This insight can be used to provide targeted training and improve the overall quality of submissions.
Why it matters
Helps trace the origin of change requests, allowing for analysis of submission quality by individual or team and identifying opportunities for training.
Where to get
This is usually the 'Created By' or 'Requested By' field on the Change Request object.
Examples
Susan MillerDavid ChenMaria Garcia
|
|||
|
Implementation Cycle Time
ImplementationCycleTime
|
The calculated duration from when a change implementation started to when it was completed. | ||
|
Description
This metric quantifies the time taken for the implementation phase of the change. It is calculated as the duration between the 'Change Implementation Started' activity and the 'Change Implemented' activity. This attribute is used to calculate the 'Average Change Implementation Time' KPI and supports the 'Change Implementation Flow & Delays' dashboard. It helps distinguish planning delays from execution delays, allowing teams to focus improvement efforts on the technical implementation work itself.
Why it matters
Isolates the performance of the actual implementation phase, helping to identify technical or resource-based bottlenecks separate from approval delays.
Where to get
Calculated in the process mining tool or during data transformation by finding the time difference between implementation start and end event timestamps.
Examples
4 hours 15 minutes1 day 2 hours30 minutes
|
|||
|
Is On Time Completion
IsOnTimeCompletion
|
A calculated flag that is true if the change was completed on or before its target date. | ||
|
Description
This is a boolean attribute derived by comparing the 'ActualCompletionDate' with the 'TargetCompletionDate'. It simplifies analysis by providing a clear, binary indicator of on-time performance for each change request. This flag is the basis for calculating the 'On-Time Change Completion Rate' KPI. It can be used as a filter in dashboards to easily isolate and analyze late changes, helping to identify common root causes for delays.
Why it matters
Simplifies performance analysis by providing a clear success or failure outcome for meeting deadlines, directly powering on-time completion KPIs.
Where to get
This attribute is not in the source system. It is calculated during data transformation by comparing 'ActualCompletionDate' <= 'TargetCompletionDate'.
Examples
truefalse
|
|||
|
Rejection Reason
ChangeRejectionReason
|
A textual description or category explaining why a change request was rejected. | ||
|
Description
When a change request is rejected, this attribute captures the reason provided by the approver. This could be a selection from a predefined list or a free-text explanation. This information is vital for the 'Rejected Change Request Analysis' dashboard. By categorizing and analyzing rejection reasons, organizations can identify common problems with change submissions, such as incomplete information, inadequate risk assessment, or business conflicts. These insights can be used to improve the quality of future change requests.
Why it matters
Provides direct insight into why changes fail, enabling targeted improvements to the submission and assessment process to reduce the overall rejection rate.
Where to get
This data is often captured in a dedicated 'Rejection Reason' field or a notes field that is populated when the status is changed to 'Rejected'.
Examples
Insufficient detail in implementation planRisk assessment incompleteConflicts with other scheduled changes
|
|||
|
Service Affected
ServiceAffected
|
The primary business service or configuration item (CI) impacted by the change. | ||
|
Description
This attribute identifies the main IT service, application, or piece of infrastructure that the change request targets. It links the change management process to the broader IT service management landscape. Analyzing by Service Affected is crucial for the 'Top Problematic Change Types' KPI, as it helps pinpoint which services are most frequently undergoing changes, and which ones are associated with high rejection rates or delays. This provides valuable insights for service owners to improve stability and manage technical debt.
Why it matters
Links changes to specific business services, enabling analysis to identify which services are most unstable or generate the most problematic changes.
Where to get
This is typically linked from the Configuration Management Database (CMDB) and stored in a 'Primary CI' or 'Service' field on the Change Request object.
Examples
Email Service (Exchange)ERP System (SAP)Core Network Switch (CISCO-4500X)
|
|||
Change Management Activities
| Activity | Description | ||
|---|---|---|---|
|
Change Approved by CAB
|
A key milestone where the Change Advisory Board (CAB) or designated authority grants approval for the change to proceed. This is inferred when the change request status is updated to 'Approved'. | ||
|
Why it matters
This activity is the endpoint for measuring the approval cycle time. It unblocks the process, allowing planning and implementation to begin, and is crucial for the Change Approval Cycle Time KPI.
Where to get
Inferred from the audit history of the Change Request object, specifically capturing the timestamp when the 'Status' field changes to 'Approved'.
Capture
Inferred from status change to 'Approved'.
Event type
inferred
|
|||
|
Change Closed
|
This activity is the final, successful end point of the change management process. It is captured when the change request status is set to 'Closed', indicating all work is complete. | ||
|
Why it matters
As the primary success endpoint, this activity is essential for calculating the end-to-end cycle time of successfully completed changes. It confirms that all process steps have concluded.
Where to get
This is inferred from the timestamp of the final status change to 'Closed' in the Change Request object's audit history.
Capture
Inferred from the final status change to 'Closed'.
Event type
inferred
|
|||
|
Change Implemented
|
This milestone indicates that the technical work for the change has been completed. It is captured when the change request status is updated to 'Implemented' or a similar state pending verification. | ||
|
Why it matters
This is a critical success milestone and a key input for the On-Time Change Completion Rate and Average Change Implementation Time KPIs. It marks the end of the execution phase.
Where to get
Inferred from the audit log of the Change Request object, using the timestamp of the status change to 'Implemented' or 'Pending Verification'.
Capture
Inferred from status change to 'Implemented'.
Event type
inferred
|
|||
|
Change Request Created
|
This activity marks the initiation of a new change request in the system. It is typically captured when a new record is created in the Change Request business object, establishing the starting point for the entire process. | ||
|
Why it matters
This is the primary start event for the process. Analyzing the time from this activity to others reveals the total lifecycle duration and helps identify front-end delays.
Where to get
This event is captured from the creation timestamp of the Change Request record. In Ivanti Cherwell, this is typically stored in the 'CreatedDateTime' field of the Change Request business object.
Capture
Captured directly from the record creation timestamp.
Event type
explicit
|
|||
|
Change Scheduled
|
This activity marks the point at which the implementation date and time for the change are formally confirmed and recorded. It is captured when the status updates to 'Scheduled'. | ||
|
Why it matters
This is a key commitment milestone. It transitions the change from an approved concept to a planned action and is a prerequisite for implementation.
Where to get
Inferred from the history of the Change Request object by capturing the timestamp when the 'Status' field is updated to 'Scheduled'.
Capture
Inferred from status change to 'Scheduled'.
Event type
inferred
|
|||
|
Impact and Risk Assessed
|
This activity signifies the completion of the risk and impact analysis for the change request. It is typically inferred when the change request status transitions to a state indicating readiness for approval, such as 'Awaiting Approval'. | ||
|
Why it matters
Tracking this activity helps measure the duration of the assessment phase and ensures that risk analysis is consistently performed before approval, supporting the Risk Assessment Adherence Rate KPI.
Where to get
Inferred from the history of the Change Request object. This is captured at the timestamp the 'Status' field is updated from 'Assessing' to a status like 'Awaiting CAB Approval'.
Capture
Inferred from status change to 'Awaiting CAB Approval'.
Event type
inferred
|
|||
|
Post-Implementation Review Conducted
|
This activity signifies that a formal review of the completed change has taken place to assess its success and capture lessons learned. It is often inferred by a status change to 'Post Implementation Review'. | ||
|
Why it matters
Tracking this ensures that the feedback loop is closed on changes. It is essential for continuous improvement and directly supports the Post-Implementation Review Rate KPI.
Where to get
Inferred from the audit history of the Change Request object, capturing the timestamp when the 'Status' moves into a state like 'Post Implementation Review'.
Capture
Inferred from status change to 'Post Implementation Review'.
Event type
inferred
|
|||
|
Change Awaiting Approval
|
This activity represents the period when a change request is formally pending a decision from the Change Advisory Board (CAB) or another approval authority. It is inferred from a status like 'Pending Approval' or 'Awaiting CAB'. | ||
|
Why it matters
This is a critical wait-time activity. Analyzing its duration helps identify bottlenecks in the approval workflow, which is a common source of delay in change management.
Where to get
Captured from the timestamp when the 'Status' field on the Change Request business object is updated to 'Pending Approval' or an equivalent value.
Capture
Identified by the entry into the 'Pending Approval' status.
Event type
inferred
|
|||
|
Change Cancelled
|
Represents a terminal state where an approved or in-progress change request is withdrawn before completion. This event is captured when the status is updated to 'Cancelled'. | ||
|
Why it matters
This is an alternative process endpoint. Analyzing why and when changes are cancelled can reveal issues with planning, resource allocation, or shifting business priorities.
Where to get
Inferred from the audit history by capturing the timestamp when the 'Status' field on the Change Request object is updated to 'Cancelled'.
Capture
Inferred from status change to 'Cancelled'.
Event type
inferred
|
|||
|
Change Implementation Started
|
Represents the beginning of the technical execution of the change. This is typically inferred when the change request status is moved to 'In Progress' or 'Implementing'. | ||
|
Why it matters
This activity marks the start of the implementation window. The time between this and 'Change Implemented' is the actual implementation duration, a key component of the overall cycle time.
Where to get
Inferred from the audit history of the Change Request object. It is the timestamp when the 'Status' field is updated to a value like 'In Progress' or 'Implementing'.
Capture
Inferred from status change to 'In Progress'.
Event type
inferred
|
|||
|
Change Rejected
|
This activity represents the terminal decision to reject the change request during the approval phase. It is captured when the change request status is set to 'Rejected'. | ||
|
Why it matters
This is a critical failure endpoint. Analyzing rejected changes and the reasons for them helps improve the quality of initial requests and supports the Change Request Rejection Rate KPI.
Where to get
Inferred from the timestamp when the 'Status' field on the Change Request object is updated to 'Rejected' in the audit history.
Capture
Inferred from status change to 'Rejected'.
Event type
inferred
|
|||
|
Change Submitted For Assessment
|
Represents the formal submission of a newly created change request for initial evaluation. This is generally inferred when the status of the change request moves from a 'New' or 'Draft' state to a status like 'Assessing'. | ||
|
Why it matters
This activity marks the beginning of the formal change process after initial data entry. The time between creation and submission can indicate user training needs or process friction.
Where to get
Inferred from the audit log or history of the Change Request object by identifying the timestamp when the 'Status' field changes to a value like 'Assessing' or 'Submitted'.
Capture
Inferred from status change from 'New' to 'Assessing'.
Event type
inferred
|
|||
|
Change Verification Performed
|
Represents the testing and validation phase to confirm that the change was successful and did not cause any adverse effects. This is inferred from a status change to 'Verification' or 'Testing'. | ||
|
Why it matters
Analyzing this activity's frequency and duration ensures that quality assurance steps are not skipped. It's a crucial step for preventing change-induced incidents.
Where to get
Captured from the timestamp of a status change on the Change Request object, such as moving to a 'Verification' or 'User Acceptance Testing' status.
Capture
Inferred from status change to 'Verification'.
Event type
inferred
|
|||
|
Implementation Plan Developed
|
Marks the completion of detailed planning for the change, including defining tasks, resources, and backout plans. This is often inferred when the change moves from 'Approved' to 'Scheduled'. | ||
|
Why it matters
The duration of this activity reveals the efficiency of the change planning phase. Delays here can impact the overall change timeline, even after approval is granted.
Where to get
This can be inferred from the timestamp of a status change from 'Approved' to 'Scheduled'. Alternatively, it could be tied to the population of specific planning fields.
Capture
Inferred from status change from 'Approved' to 'Scheduled'.
Event type
inferred
|
|||