Your Change Management Data Template

ServiceNow
Your Change Management Data Template

Your Change Management Data Template

This template provides a structured approach to collecting the essential data required for effective process mining of your Change Management workflow. It outlines recommended attributes and activities to track, along with practical guidance for data extraction. Use this resource to prepare your data for comprehensive analysis and optimization.
  • Recommended attributes to collect
  • Key activities to track for accurate process discovery
  • Guidance for extracting data from ServiceNow
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 a comprehensive analysis of your change management process.
3 Required 7 Recommended 10 Optional
Name Description
Change Request ID
ChangeRequestNumber
The unique identifier for a change request, serving as the primary case ID for grouping all related events.
Description

The Change Request ID is the cornerstone of the change management process analysis. It is a unique number assigned to each change request, such as 'CHG0030001', that links all activities, approvals, and tasks together.

In process mining, this attribute is used to reconstruct the end-to-end journey of every individual change. It allows analysts to trace the complete lifecycle from creation to closure, providing a coherent view of how each change progresses through the system. Analyzing processes grouped by this ID is essential for calculating cycle times, identifying rework loops, and understanding process variants.

Why it matters

This ID is essential for tracking the entire lifecycle of a change, enabling a complete analysis of process flow, duration, and compliance for each request.

Where to get

ServiceNow table: change_request, Field: number

Examples
CHG0030001CHG0030045CHG0030112
Event Time
EventTime
The precise timestamp when a specific activity or event occurred.
Description

Event Time records the exact date and time that an activity was performed or a status change was registered. This timestamp is critical for ordering events chronologically and for all duration-based analysis.

In process mining, this attribute enables the calculation of cycle times, processing times, and waiting times between activities. It is essential for dashboards that analyze performance, such as Change Approval Cycle Time and End-to-End Change Process Flow. Accurate timestamps are the foundation for identifying delays and measuring process efficiency against SLAs.

Why it matters

This timestamp is crucial for sequencing events correctly and calculating all time-based metrics, including cycle times, durations, and SLA adherence.

Where to get

ServiceNow table: sys_audit, Field: sys_created_on. This provides the timestamp for each recorded change.

Examples
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
Activity Name
ActivityName
The name of a specific event or task that occurred within the change management process.
Description

The Activity Name describes a discrete step or status change in the lifecycle of a change request. Examples include 'Change Awaiting Assessment', 'Approval Requested', and 'Change Implemented'. These activities form the nodes in the discovered process map.

Analyzing these activities allows for a detailed examination of the process flow. By tracking the sequence and frequency of activities, organizations can identify common paths, deviations from the standard process, and bottlenecks where changes frequently stall. This is fundamental for visualizing the process and calculating metrics like transition times between steps.

Why it matters

It forms the backbone of the process map, allowing for visualization of the process flow, identification of bottlenecks, and analysis of deviations.

Where to get

Derived from changes in the 'state' field or other key status fields in the 'change_request' table, often captured in the 'sys_audit' table.

Examples
Change ApprovedImplementation StartedChange ClosedChange Canceled
Assignment Group
AssignmentGroup
The team or group responsible for the change request.
Description

The Assignment Group indicates which team is currently responsible for the change request, such as 'CAB Approval', 'Network Engineering', or 'Database Administrators'. This is a critical dimension for analyzing process performance across different functional areas.

This attribute is used to measure team-level efficiency, identify bottlenecks within specific groups, and analyze the effectiveness of handoffs between teams. Dashboards like 'Cross-Functional Handoff Efficiency' and 'Change Implementation Throughput' rely heavily on this data to pinpoint delays caused by inter-team dependencies.

Why it matters

Enables performance analysis by team, highlighting group-specific bottlenecks and measuring the efficiency of handoffs between different functional areas.

Where to get

ServiceNow table: change_request, Field: assignment_group

Examples
CAB ApprovalNetwork TeamServer SupportDatabase Administrators
Change State
ChangeState
The current or historical state of the change request, such as 'Assess', 'Authorize', 'Implement', or 'Closed'.
Description

The Change State attribute represents the status of a change request at a given point in time. It provides a high-level summary of where the change is in its lifecycle. Unlike the Activity, which represents a specific event, the State is the condition resulting from that event.

In analysis, Change State is used to categorize cases and understand their outcomes. It is fundamental for filtering changes, for example, to analyze only 'Closed' changes or investigate why many changes are stuck in the 'Authorize' state. It directly supports KPIs like Change Failure Rate when a 'Failed' state exists.

Why it matters

Provides a snapshot of the change request's status, enabling analysis of outcomes, case filtering, and identification of stalled changes.

Where to get

ServiceNow table: change_request, Field: state

Examples
AssessAuthorizeScheduledImplementReviewClosedCanceled
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, risk, and approval requirements. Standard changes are pre-approved, Normal changes follow the full process, and Emergency changes use an expedited path.

This is a fundamental dimension for process analysis, as different change types have distinct, legitimate process models. Comparing the performance of Normal vs. Emergency changes can reveal important insights about process adherence and efficiency. It is also used in dashboards like 'Risk Assessment Standardization' to ensure similar changes are treated consistently.

Why it matters

Allows for segmentation of analysis, as different change types follow different authorized process flows and have unique performance expectations.

Where to get

ServiceNow table: change_request, Field: type

Examples
StandardNormalEmergency
Configuration Item
ConfigurationItem
The specific IT component, service, or system that is the subject of the change.
Description

The Configuration Item (CI) is the asset from the Configuration Management Database (CMDB) that will be affected by the change. This could be a server, a software application, a network device, or a business service.

This attribute provides critical context for the change. In process mining, it allows for analysis to be segmented by the type of asset being changed. For example, the 'Change Testing Duration Analysis' dashboard uses this attribute to compare testing times for different applications or systems, helping to identify which CIs are associated with longer testing cycles.

Why it matters

Provides essential business context, allowing analysis to be filtered by the affected application, service, or system to identify component-specific issues.

Where to get

ServiceNow table: change_request, Field: cmdb_ci

Examples
SAP ERPOracle Database 19cEmail ServiceWebServer-01
End Time
EndTime
The timestamp when an activity concluded. It is often derived from the start time of the subsequent activity.
Description

The End Time marks the completion of an activity. While source systems often log the start of an event, the end time is frequently inferred. It is typically calculated as the timestamp of the next activity in the sequence for the same case.

This attribute is essential for calculating the duration of each activity, known as processing time. Understanding how long each step takes is fundamental to identifying bottlenecks and inefficiencies in the process. For the final activity in a case, the End Time is the same as the Start Time.

Why it matters

Enables the calculation of activity processing time, which is crucial for identifying bottlenecks and measuring the duration of specific process steps.

Where to get

This attribute is typically calculated during data transformation by taking the StartTime of the next event for the same CaseId.

Examples
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Priority
Priority
The priority level of the change request, determined by its impact and urgency.
Description

Priority indicates the importance of a change request and determines the order in which it should be addressed. It is often derived from the impact and urgency of the change, with values like 'Critical', 'High', 'Moderate', and 'Low'.

Analyzing by priority is essential for ensuring that high-priority changes are processed faster than low-priority ones. It supports the 'Critical Change Performance' dashboard by allowing analysts to track cycle times and failure rates specifically for the most important changes. Any deviation where low-priority changes are completed faster than high-priority ones indicates a problem in resource allocation or process execution.

Why it matters

Crucial for evaluating if resources are correctly allocated to the most critical changes and for monitoring their performance separately.

Where to get

ServiceNow table: change_request, Field: priority

Examples
1 - Critical2 - High3 - Moderate4 - Low
Risk Level
RiskLevel
The assessed risk level of the change, such as 'High', 'Moderate', or 'Low'.
Description

The Risk Level is the output of the risk assessment process for a change request. It quantifies the potential for adverse consequences if the change is implemented, helping to determine the required level of scrutiny and approval.

This attribute is key for the 'Risk Assessment Standardization' dashboard, where it's used to check if similar changes receive consistent risk ratings. Analyzing process flows by risk level can also reveal if high-risk changes are correctly following a more rigorous approval and testing path compared to low-risk changes, which is a key compliance check.

Why it matters

Essential for compliance analysis and ensuring that high-risk changes receive the appropriate level of scrutiny and follow a more rigorous process.

Where to get

ServiceNow table: change_request, Field: risk

Examples
HighModerateLow
Assigned To User
AssignedToUser
The individual user responsible for the change request at a specific point in time.
Description

This attribute identifies the specific person assigned to work on the change request. This can change multiple times throughout the lifecycle as the request moves between different stages and teams.

Analyzing by user helps in understanding workload distribution, individual performance, and identifying training needs. It is also key for analyzing handoffs, particularly when combined with the Assignment Group, to see how efficiently work is passed between individuals.

Why it matters

Helps track individual user workload and performance, and is crucial for analyzing handoff delays between different resources.

Where to get

ServiceNow table: change_request, Field: assigned_to

Examples
Beth AnglinDavid LooAbel Tuter
Close Code
CloseCode
A code indicating the outcome when the change request was closed, such as 'Successful' or 'Unsuccessful'.
Description

The Close Code provides a final disposition for a completed change request. It formally records whether the change was implemented successfully, with issues, or was rolled back.

This attribute is a direct input for the 'Change Failure Rate' KPI. By analyzing the distribution of close codes, organizations can quantify the success of their change initiatives. Filtering the process map for changes with an 'Unsuccessful' close code is a powerful technique for root cause analysis, revealing common process patterns that lead to failure.

Why it matters

Directly measures the outcome of a change, providing the primary data needed to calculate the change failure rate and analyze the root causes of failed changes.

Where to get

ServiceNow table: change_request, Field: close_code

Examples
SuccessfulSuccessful with IssuesUnsuccessful / Rolled Back
Cycle Time
CycleTime
The total time elapsed from the creation to the closure of a change request.
Description

Cycle Time is a case-level metric that measures the total duration of a change request's lifecycle. It is calculated as the difference between the timestamp of the very first event and the timestamp of the very last event for a given change request.

This is a critical KPI for measuring overall process velocity. It is used in the 'End-to-End Change Process Flow' dashboard to provide a high-level view of process performance. Analyzing cycle time trends and comparing them across different dimensions like Change Type or Priority helps organizations identify opportunities for strategic process improvement.

Why it matters

Measures the end-to-end duration of the change process, providing a key indicator of overall process velocity and efficiency.

Where to get

Calculated at the case level during data analysis by subtracting the minimum StartTime from the maximum StartTime for each CaseId.

Examples
60480012096002592000
Impact
Impact
The potential effect of the change on business operations, rated on a scale such as High, Medium, or Low.
Description

Impact measures the potential effect on the business if the change request is not handled correctly. It is a key input, along with Urgency, for determining the overall Priority of the change.

Analyzing by Impact helps to ensure that changes affecting critical services are managed with appropriate care. It is used in the 'Critical Change Performance' dashboard to isolate and monitor changes with a high business impact. It is also used to verify risk assessment consistency, ensuring that high-impact changes are not assigned a low risk level without justification.

Why it matters

Helps prioritize changes based on their potential business effect and is used to validate that high-impact changes are managed with proper diligence.

Where to get

ServiceNow table: change_request, Field: impact

Examples
1 - High2 - Medium3 - Low
Is Rework
IsRework
A boolean flag that is true if an activity represents a repeat of a previous step in the same case.
Description

This calculated attribute identifies activities that constitute rework. Rework occurs when the process has to loop back to a step that was already completed, such as a change being rejected after approval and sent back for reassessment.

This flag is crucial for quantifying process inefficiency. It directly supports the 'Change Rework Rate' KPI and the 'Change Failure and Rework Analysis' dashboard. By filtering for activities where 'Is Rework' is true, analysts can isolate and study the causes of rework, such as incomplete initial assessments or changing requirements, and take action to reduce waste.

Why it matters

Directly quantifies process inefficiency by flagging repeated work, helping to identify and address the root causes of process loops and wasted effort.

Where to get

Calculated during data transformation by detecting if the same activity (or an earlier one in the standard flow) has already occurred for the given CaseId.

Examples
truefalse
Last Data Update
LastDataUpdate
The timestamp indicating when the data for this record was last refreshed from the source system.
Description

This attribute provides the timestamp of the last data extraction. It is a metadata field that is critical for understanding the freshness of the data being analyzed.

Analysts use this timestamp to confirm they are working with up-to-date information and to understand the data's recency. It is especially important for operational dashboards that monitor ongoing process performance, ensuring that decisions are not based on stale data.

Why it matters

Indicates data freshness, ensuring that analyses and dashboards are based on current and relevant information.

Where to get

This is a metadata field generated during the data extraction and transformation (ETL) process, indicating the time of the data pull.

Examples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Processing Time
ProcessingTime
The duration of a single activity, calculated as the difference between its End Time and Start Time.
Description

Processing Time, also known as activity duration, measures the time spent actively working on a specific task. It is calculated by subtracting the activity's Start Time from its End Time.

This calculated metric is fundamental for performance analysis. It allows for the identification of the most time-consuming steps in the process, which are often the primary targets for optimization efforts. Dashboards analyzing testing duration or risk assessment cycle time are directly based on this metric for the relevant activities.

Why it matters

Measures the duration of individual activities, making it possible to pinpoint the most time-consuming steps that are prime candidates for optimization.

Where to get

Calculated during data transformation: EndTime - StartTime.

Examples
259200360086400
SLA State
SlaState
The status of the change request relative to its Service Level Agreement (SLA), such as 'On Track', 'At Risk', or 'Breached'.
Description

SLA State indicates whether the change request is progressing within the timeframes defined by its SLA. This status can be tracked at each stage of the process.

This attribute is essential for monitoring compliance with service level commitments. It is the primary data source for the 'Change SLA Performance Overview' dashboard and the 'Change SLA Adherence Rate' KPI. Analyzing where and why SLAs are breached allows the organization to address systemic delays and improve service delivery predictability.

Why it matters

Provides a direct measure of performance against deadlines, enabling proactive monitoring and analysis of SLA breaches to improve service delivery.

Where to get

This can be sourced from the 'task_sla' table in ServiceNow, which tracks SLAs related to tasks like change requests, or calculated based on due date fields.

Examples
On TrackAt RiskBreached
Source System
SourceSystem
The system from which the data was extracted, typically 'ServiceNow'.
Description

This attribute identifies the origin of the process data. While in this case it is expected to be ServiceNow, it is a crucial field for data governance and for scenarios where data from multiple systems might be merged.

In analysis, it ensures data lineage is clear and helps in validating the data's source. For organizations with multiple ITSM tools or integrated systems, this attribute allows for filtering and comparing processes across different platforms.

Why it matters

Provides clear data lineage, ensuring that the origin of the process data is documented, which is vital for data governance and multi-system analysis.

Where to get

This is typically a static value added during the data extraction and transformation (ETL) process.

Examples
ServiceNowServiceNow_PRODSNOW_ITSM
Urgency
Urgency
The speed at which a change needs to be resolved, rated on a scale such as High, Medium, or Low.
Description

Urgency defines how quickly a change needs to be implemented. It reflects the time sensitivity of the request from a business perspective. Along with Impact, it is used to calculate the overall Priority.

While Priority is the primary field for analysis, Urgency provides additional context. It can be used to investigate why certain changes are marked as urgent and whether the process accommodates them effectively without compromising stability. It helps answer questions about whether the organization is too often in a reactive, high-urgency mode.

Why it matters

Provides context on the time sensitivity of a change, helping to analyze whether the process effectively handles time-critical requests.

Where to get

ServiceNow table: change_request, Field: urgency

Examples
1 - High2 - Medium3 - Low
Required Recommended Optional

Change Management Activities

These are the key process steps and milestones to capture in your event log for accurate change management process discovery.
7 Recommended 6 Optional
Activity Description
Change Approved
The change request has received all necessary authorizations to proceed to the scheduling and implementation phases. This is a critical milestone, captured when the final approval is granted and the 'approval' field is set to 'approved'.
Why it matters

This milestone concludes the approval phase. It is essential for measuring approval cycle times and identifying bottlenecks in the decision making process.

Where to get

Inferred from the 'approval' field of the change_request table changing to 'approved'. The timestamp is sourced from the audit history for this change.

Capture

Capture the timestamp when the 'approval' field becomes 'approved'.

Event type inferred
Change Canceled
The change request has been withdrawn or aborted at some point before implementation was completed. This is an alternative end state captured when the state is set to 'Canceled'.
Why it matters

Analyzing canceled changes can reveal process inefficiencies, such as requests being created unnecessarily or being stuck in approval for too long, becoming obsolete.

Where to get

Inferred from the 'state' field in the change_request table being set to 'Canceled'. The timestamp is captured from the audit log for this state change.

Capture

Capture the timestamp when the 'state' field is updated to 'Canceled'.

Event type inferred
Change Closed
The change request has been successfully completed, reviewed, and is now considered finished. This is the primary success endpoint for the process and is captured when the change state moves to 'Closed'.
Why it matters

This activity marks the successful completion of the change lifecycle. It is the end event for measuring end to end process duration and SLA adherence.

Where to get

Inferred from the 'state' field in the change_request table being set to 'Closed'. The timestamp is taken from the audit history for this final state change.

Capture

Capture the timestamp when the 'state' field is updated to 'Closed'.

Event type inferred
Change Implemented
The implementation work has been completed, and the change is ready for review, verification, or testing. This activity is inferred when the state of the change request moves from 'Implement' to 'Review'.
Why it matters

This is a critical milestone that concludes the implementation phase. It is a key event for calculating the 'Change Failure Rate' and 'Change Rework Rate' KPIs.

Where to get

Inferred from a state transition out of 'Implement' to a subsequent state like 'Review'. The timestamp is captured from the audit history of the 'state' field in the change_request table.

Capture

Identify when the 'state' field changes from 'Implement' to 'Review'.

Event type inferred
Change Request Created
This activity marks the creation of a new change request record in the system. It is the official start of the change management process and is captured when a new entry is inserted into the change_request table.
Why it matters

This is the primary start event for the process. Analyzing the time from this activity to others reveals the total lead time and helps identify delays at the very beginning of the process.

Where to get

This event corresponds to the record creation timestamp (sys_created_on) in the ServiceNow change_request table.

Capture

Use the sys_created_on timestamp from the change_request table.

Event type explicit
Change Scheduled
The approved change has been assigned a planned start and end date and is now officially on the implementation calendar. This is inferred when the change request state moves to 'Scheduled'.
Why it matters

This activity separates the planning and approval stages from the active implementation phase. The time spent in this state can indicate delays between approval and the start of work.

Where to get

Inferred from a 'state' field change in the change_request table to 'Scheduled'. The timestamp is captured from the corresponding audit log entry.

Capture

Track state field changes to 'Scheduled' in the change_request table's audit history.

Event type inferred
Risk And Impact Assessed
Represents the completion of the risk and impact analysis for the change request. This is a crucial milestone before seeking approval and is often inferred when the change moves out of an 'Assess' state into an 'Authorize' or 'Awaiting Approval' state.
Why it matters

Tracking the duration of the assessment phase is key to the 'Avg. Risk Assessment Cycle Time' KPI. It helps standardize the assessment process and identify where analyses are taking too long.

Where to get

Inferred from the 'state' field in the change_request table transitioning from 'Assess' to 'Authorize'. The event timestamp is captured from the audit log of this state change.

Capture

Identify when the 'state' field changes from 'Assess' to a subsequent state like 'Authorize'.

Event type inferred
Approval Requested
This activity signifies that the change request has been formally submitted for approval, typically to a manager or a Change Advisory Board (CAB). This event is captured when the approval status of the change request is set to 'requested'.
Why it matters

This marks the beginning of the approval cycle. Measuring the time from this event to 'Change Approved' directly calculates the 'Average Change Approval Time' KPI.

Where to get

Inferred from the 'approval' field in the change_request table changing to 'requested'. The timestamp is recorded from the sys_audit table for this field.

Capture

Timestamp of when the 'approval' field in the change_request table is set to 'requested'.

Event type inferred
Change Awaiting Assessment
The change request has been submitted and is now waiting for technical and business assessment. This is typically inferred when the change request's state transitions to 'Assess' or a similar status, indicating it has left the draft phase.
Why it matters

This activity helps measure the initial handoff time from requestor to the assessment team. Delays here can indicate issues with initial data quality or resource availability for assessment.

Where to get

Inferred from a change in the 'state' field in the change_request table, typically to a value like 'Assess'. The timestamp is taken from the audit history (sys_audit) for this field change.

Capture

Track state field changes to 'Assess' in the change_request table's audit history.

Event type inferred
Change Rejected
The change request has been denied by an approver or the CAB. This activity represents a terminal state for the request unless it is reworked and resubmitted. It is captured when the 'approval' field is set to 'rejected'.
Why it matters

Tracking rejections helps identify common reasons for denial, such as incomplete information or high risk. This analysis can improve the quality of future change submissions.

Where to get

Inferred from the 'approval' field in the change_request table changing to 'rejected'. The timestamp is captured from the audit history.

Capture

Capture the timestamp when the 'approval' field becomes 'rejected'.

Event type inferred
Change Reopened
The change request has been moved back to a previous state, such as 'Implement' or 'Assess', after reaching a later stage. This event is inferred from a non-linear state transition and signifies rework.
Why it matters

This activity is crucial for identifying rework loops and calculating the 'Change Rework Rate'. Frequent reopening events indicate issues with implementation quality, testing, or planning.

Where to get

Inferred by analyzing the sequence of state changes in the change_request audit history. A transition from a later state (e.g., 'Review') to an earlier state (e.g., 'Implement') indicates a reopen event.

Capture

Detect a non-sequential, backward transition in the 'state' field's history.

Event type inferred
Implementation Started
Work has actively begun on implementing the change. This is captured when the change request's state is updated to 'Implement', signifying the transition from planning to execution.
Why it matters

This marks the start of the hands on implementation work. It is the starting point for measuring the 'Average Implementation Duration' KPI and analyzing team efficiency.

Where to get

Inferred from the 'state' field in the change_request table changing to 'Implement'. The timestamp is taken from the audit log for this state transition.

Capture

Capture the timestamp of the state change to 'Implement' from the change_request audit history.

Event type inferred
Review In Progress
A post-implementation review (PIR) is being conducted to determine if the change was successful and met its objectives. This is captured when the change request state is set to 'Review'.
Why it matters

Analyzing the duration of the review phase helps identify delays in validating change success. It also highlights non-compliant changes where this step is skipped.

Where to get

Inferred from the 'state' field in the change_request table changing to 'Review'. The timestamp is sourced from the audit log for this state change.

Capture

Capture the timestamp of the state change to 'Review' from the change_request audit history.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from ServiceNow