Your Change Management Data Template

The Activity Name describes a distinct step or milestone in the change request lifecycle, such as 'Risk Assessment Completed' or 'Change Approved'. Each activity represents a point in time where an action was taken, a decision was made, or the process moved to a new stage.

This attribute is fundamental for building the process map. It defines the nodes in the process graph, allowing analysts to visualize the sequence of events, identify common pathways, and detect deviations from the standard procedure. Analyzing activities helps uncover bottlenecks, rework loops, and inefficient handoffs between different stages of the change process.

It defines the steps in the process, enabling the visualization of the process flow and the analysis of bottlenecks, rework, and deviations.

Usually located in an activity log, event history, or audit trail table associated with the change request.

The Change Request ID is a unique alphanumeric code assigned to each change request when it is created. It acts as the primary key for a single change case, linking all associated tasks, approvals, and logs from initiation to closure.

In process mining, this attribute is essential for reconstructing the end-to-end journey of each change. By grouping all events under a common Change Request ID, analysts can visualize process flows, calculate case durations, and analyze variations between different change lifecycles. It is the foundation upon which all case-level analysis is built, enabling a clear view of how individual changes progress through the system.

This ID is critical for tracking and correlating all events related to a single change, making it the cornerstone of process discovery and conformance checking.

Typically found in the header or primary record of a change request transaction.

The Event Start Time marks the beginning of an activity within the change request's lifecycle. This timestamp is crucial for sequencing events chronologically and for calculating the duration of activities and the overall case.

In process analysis, this attribute is used to order the activities correctly, forming the basis of the event log. It is essential for calculating all time-related metrics, such as cycle times between activities, waiting times, and total case duration. By analyzing these timestamps, organizations can identify which steps consume the most time and pinpoint opportunities for process acceleration.

This timestamp is essential for ordering events, discovering the process flow, and calculating all performance metrics like cycle times and waiting times.

Found in the event log or audit trail for the change request. It may be named 'Creation Date', 'Start Date', or simply 'Timestamp'.

The Last Data Update timestamp specifies the last time a particular record was pulled from the source system. This is a metadata attribute that is essential for managing the data pipeline and ensuring the freshness of the analysis.

This attribute helps data engineers and analysts understand the timeliness of the data they are working with. It is used to monitor the health of the data extraction process and to confirm that the process mining analysis is based on recent and relevant information. It is generally not used for process analysis itself but is critical for data governance and reliability.

Ensures data freshness and helps in monitoring the health of the data pipeline, which is vital for the reliability of the process analysis.

This timestamp is typically generated and added during the data extraction, transformation, and loading (ETL) process.

The Source System attribute identifies the origin of the event data. In environments with multiple ITSM tools or integrated systems, this field helps distinguish between data from different sources, ensuring data integrity and proper context.

While not always used in primary process flow analysis, it is invaluable for data validation and governance. It helps in troubleshooting data ingestion issues and can be used to compare process performance across different systems or business units if they use separate platforms. For example, a company might use one system for infrastructure changes and another for application changes.

Identifies the data's origin, which is crucial for data validation, troubleshooting, and analyzing processes that span multiple systems.

This information may be stored as a field in the source data or added during the data extraction and transformation (ETL) process.

The Affected Business Service identifies the core business capability, such as 'Email Service' or 'Online Banking', that the change will modify. This could also be a specific technical Configuration Item (CI), like a server or application, that supports a business service.

This attribute provides critical business context to the change management process. It allows analysis to be framed in terms of business impact rather than just IT activity. For example, analysts can identify which services are most frequently changed, which might indicate instability or a high rate of innovation. It also helps in prioritizing changes and assessing risk by linking technical changes to the business functions they support.

Links IT changes to business context, enabling analysis of which business services are most impacted by change activity and associated risks.

Found in the change request's main record, often linked from a Configuration Management Database (CMDB).

The Change Status indicates the phase of a change request at a specific point in time or its final outcome. Statuses typically correspond to major milestones in the process and provide a high-level view of progress.

This attribute can be used in two ways. As a snapshot attribute, it shows the current state of all open changes, which is useful for operational dashboards tracking throughput and backlogs. As an event attribute, a change in status can itself be considered an activity, helping to enrich the event log if detailed activity data is sparse. Analyzing status transitions helps understand the lifecycle and identify where changes get stuck.

It provides a snapshot of the change's progress, enabling analysis of bottlenecks, throughput, and the current state of the change backlog.

Found in the header record of the change request. Historical status changes may be found in an audit log.

The Change Type is a critical categorization that determines the required workflow, approval steps, and urgency of a change request. Standard changes are typically pre-approved and low-risk, Normal changes follow the full assessment and approval process, and Emergency changes require expedited handling due to an urgent business need.

Analyzing the process by Change Type is a core activity in change management analysis. It allows for comparing the performance and compliance of different change workflows. For instance, analysts can verify if Emergency changes truly follow a faster path or if Standard changes adhere to their simplified, pre-approved flow. This segmentation is key to understanding process variations and ensuring the right level of governance is applied.

This attribute is essential for segmenting analysis, as different change types have distinct, predefined process flows, approval requirements, and performance expectations.

Located in the main record or header data for the change request.

The Event End Time marks the conclusion of an activity. Paired with the Event Start Time, it allows for the precise calculation of the processing time for each step in the change lifecycle.

This attribute is fundamental for performance analysis. The difference between the start and end times reveals the 'processing time' of an activity, while the time between one activity's end and the next one's start reveals the 'waiting time'. This distinction is key to identifying whether delays are caused by long tasks or by idle periods between tasks, guiding targeted improvement efforts.

It enables the calculation of precise activity durations, helping to distinguish between value-adding processing time and non-value-adding waiting time.

Often found in the activity log or audit trail tables. If not available, it can sometimes be derived from the start time of the subsequent event.

The Change Priority is a classification used to determine the relative importance of a change request. It helps teams schedule and allocate resources effectively, ensuring that the most critical changes are addressed first. Priority is often calculated based on the change's potential impact on the business and the urgency of its implementation.

In process mining, priority is a powerful dimension for filtering and comparison. Analysts can investigate whether high-priority changes are actually processed faster than low-priority ones. Any discrepancies could indicate issues with resource allocation, approval bottlenecks for critical changes, or inconsistent adherence to prioritization rules.

Allows for analyzing whether high-priority changes are processed faster than low-priority ones, validating the effectiveness of prioritization policies.

Located in the main record or header data for the change request.

The Responsible Team identifies the group of people assigned to work on the change at a particular stage. This could be an assessment team, an approval board like the CAB, or the technical team performing the implementation.

This attribute is essential for analyzing resource allocation, workload distribution, and handoffs between teams. A social network analysis can reveal communication patterns and bottlenecks between different groups. By measuring the time spent with each team, organizations can identify which groups are overloaded or where delays frequently occur during transfers of responsibility.

This is crucial for analyzing handoffs between teams, identifying resource bottlenecks, and understanding workload distribution across the organization.

Found in the change request record or in the activity-level details. It may be called 'Assignment Group' or 'Team'.

The Responsible User is the specific person assigned to a change request or activity. This attribute provides a more granular view of workload and responsibility than the team-level assignment.

Analyzing data at the user level can help in performance management and identifying training opportunities. It can highlight individuals who are process experts or those who may be struggling with certain tasks. It is also used to analyze rework, for instance, to see if changes handled by certain individuals are more likely to be rejected or require remediation. However, care must be taken to use this information constructively and not for punitive measures.

Provides a granular view for analyzing individual workload and performance, helping to identify experts and potential training needs within teams.

Typically found in the change request record or in task-level details, often labeled as 'Assignee' or 'Assigned To'.

The Risk Level represents the assessed likelihood and potential negative impact of a change failing. This assessment influences the required level of testing, scrutiny, and approval. High-risk changes typically require a more rigorous review process compared to low-risk changes.

This attribute enables risk-based process analysis. It can be used to check if high-risk changes receive the appropriate level of review, such as review by a Change Advisory Board (CAB). It also allows for correlating risk level with outcomes, for example, to determine if high-risk changes have a higher failure rate, which might suggest the risk assessment or mitigation process needs improvement.

Enables analysis of whether process controls and approval workflows are correctly aligned with the assessed risk of the change.

Found in the header data or risk assessment details of a change request.

The Change Reason is a textual description that outlines the business driver behind the change request. It answers the question 'Why are we doing this?', providing context such as 'Security patch for critical vulnerability' or 'New feature to improve customer experience'.

While often a free-text field, this attribute can provide valuable qualitative insights when categorized or analyzed with text mining techniques. It helps in understanding the demand for changes from different parts of the business. For example, analysis might reveal that a large percentage of changes are driven by bug fixes, indicating potential issues with software quality, while another period might show a high number of changes related to strategic projects.

Provides business context for why changes are being initiated, helping to analyze the main drivers of change within the organization.

Typically found in the initial submission form or header details of the change request.

The Change Impact measures the potential effect of a change on business operations, services, or infrastructure. It is a key input, along with urgency, for determining the overall priority of the change. For example, a change impacting a critical customer-facing service has a high impact.

Analyzing by impact helps to ensure that changes affecting critical services are managed with appropriate care. It can be used in conformance checking to verify that high-impact changes always go through specific approval or testing stages. It also allows for performance comparisons, such as checking if high-impact changes take longer to implement due to more extensive review and testing.

Helps verify that changes with a high business impact follow more rigorous review and testing paths, ensuring proper governance.

Located in the main record or header data for the change request.

The Change Outcome Reason provides context for why a change request ended the way it did. For successful changes, it might be 'Successful'. For failed changes, it could be 'Unsuccessful - Rollback initiated'. For rejected or canceled changes, it gives the justification, such as 'Insufficient justification' or 'Canceled by requester'.

This attribute is crucial for root cause analysis of failed or rejected changes. By categorizing and analyzing these reasons, organizations can identify common failure patterns. For instance, if many changes are rejected for 'Incomplete information', it signals a need to improve the change submission process. This data helps in calculating and understanding KPIs like the Change Failure Rate and First-Pass Approval Rate.

Provides critical data for root cause analysis of failed, rejected, or canceled changes, helping to improve the quality of future change requests.

Found in the closure details of a change request record. It may be named 'Close Code', 'Resolution', or 'Rejection Reason'.

The Planned Completion Date is the deadline set for the change, often determined by business requirements or Service Level Agreements (SLAs). It serves as a benchmark for measuring the timeliness and performance of the change management process.

This attribute is essential for SLA performance analysis. By comparing the actual completion date with the planned date, organizations can calculate the On-Time Completion Rate, a key performance indicator. Analyzing the changes that miss their planned dates can help identify the root causes of delays, whether they are related to approval bottlenecks, resource constraints, or unrealistic planning.

This is a key attribute for measuring SLA compliance and on-time delivery, helping to identify the root causes for delays in the process.

Typically located in the header data of the change request.

The Change Urgency indicates how quickly a change needs to be implemented to meet business requirements. It reflects the time-criticality of the change, separate from its potential impact. A change might have low impact but high urgency, such as fixing a minor issue before a marketing campaign launches.

Urgency is a key component in calculating priority and is used to analyze the timeliness of the change management process. Analysts can investigate whether high-urgency changes are indeed processed more quickly. Comparing cycle times across different urgency levels can reveal if the process is responsive to business needs or if all changes are treated with the same speed, regardless of their time sensitivity.

Allows for analysis of process responsiveness to time-sensitive business needs by comparing cycle times across different urgency levels.

Located in the main record or header data for the change request.