Your Change Management Data Template

Ivanti Cherwell
Your Change Management Data Template

Your Change Management Data Template

This template provides a clear roadmap for collecting the essential data needed to analyze your Change Management process. It outlines the crucial attributes to gather, the key activities to track, and provides specific guidance for extracting this information from your source system. Use this resource to build a robust event log for your process mining initiatives.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance from Ivanti Cherwell
New to event logs? Learn how to create a process mining event log.

Change Management Attributes

These are the recommended data fields to include in your event log for comprehensive change management analysis and insightful process discovery.
5 Required 6 Recommended 9 Optional
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)
Required Recommended Optional

Change Management Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and performance measurement.
7 Recommended 7 Optional
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
Recommended Optional

Extraction Guides

How to get your data from Ivanti Cherwell