Your Change Management Data Template
Your Change Management Data Template
- Recommended attributes to collect
- Key activities to track for accurate process discovery
- Guidance for extracting data from ServiceNow
Change Management Attributes
| 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
|
|||
Change Management Activities
| 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
|
|||