Your Change Management Data Template

This attribute records the name of the activity that took place at a specific point in time for a change request. These activities are derived from status transitions, workflow steps, or specific log entries within Jira, such as 'Change Submitted For Review' or 'Implementation Started'.

Analyzing the sequence and frequency of these activities is the core of process mining. It allows for the discovery of the actual process flows, identification of bottlenecks between steps, and analysis of process variants against the standard operating procedure.

It defines the steps of the process, which is essential for discovering process maps, analyzing variants, and identifying bottlenecks.

Typically derived from the Jira issue history, specifically from status transitions or updates to custom fields that represent process milestones.

The Change Request ID is the primary key that uniquely identifies each change initiative within Jira Service Management. It serves as the case identifier for process mining, linking all events, status changes, and updates into a cohesive end-to-end process view.

In analysis, this ID allows for the reconstruction of the complete lifecycle of every change. It is essential for tracking individual changes through various stages like risk assessment, approval, implementation, and review. All metrics, KPIs, and dashboards rely on this attribute to correctly aggregate and correlate event data for a specific change.

This is the fundamental case identifier, making it possible to trace the full journey of a change request and analyze its performance.

This is the standard Jira Issue Key, found in the key field for issues of the Change request type.

The Start Time, or event timestamp, marks the precise date and time that an activity was recorded for a change request. Every activity in the event log, from creation to closure, has an associated timestamp.

This attribute is critical for all time-based analysis in process mining. It is used to calculate cycle times, durations between activities, waiting times, and to determine the sequence of events. It forms the basis for performance monitoring, SLA adherence calculations, and bottleneck identification.

This timestamp is the foundation for all performance and duration analysis, enabling the calculation of cycle times and identification of delays.

The timestamp of each entry in the Jira issue history log. For the creation event, this is the created field.

This attribute records the date and time when the data was last pulled from the source system. It represents the freshness of the data within the process mining tool.

Analyzing this attribute helps users understand how current the process data is, which is important for operational dashboards and real-time monitoring. It provides context for the analysis, ensuring that decisions are not made on stale data.

Indicates the freshness of the data, ensuring that analyses are relevant and based on up-to-date information.

This is a metadata field populated by the data extraction tool at the time of the data pull.

This attribute specifies the source system where the process data originated. For this context, the value is consistently 'Jira Service Management'.

In a broader enterprise context where data might be merged from multiple systems, this field is crucial for data lineage, troubleshooting, and understanding system-specific process variations. It ensures clarity on the origin of the data being analyzed.

Provides clear data provenance, which is essential when combining data from multiple systems or for auditing purposes.

This is a static value added during data extraction to label the origin of the dataset.

This is a calculated metric that measures the time elapsed between the 'Change Submitted For Review' activity and the 'Change Request Approved' activity. It isolates the approval phase of the change lifecycle for focused analysis.

This metric directly supports the 'Change Approval Cycle Time' dashboard and the corresponding KPI. It is used to identify bottlenecks in the approval process, whether they are with specific approval groups, change types, or risk levels. Reducing this time can significantly accelerate the overall change delivery process.

Directly measures the efficiency of the approval stage, helping to pinpoint and address delays in getting changes authorized.

Calculated by subtracting the timestamp of 'Change Submitted For Review' from the timestamp of 'Change Request Approved' for a given Change Request ID.

The Assignee is the individual user who is responsible for the current step or activity in the change management workflow. The assignee can change multiple times throughout the lifecycle of a change request as it moves between different people and teams.

This attribute is used to analyze workload distribution, identify user-specific bottlenecks, and understand resource allocation. The 'Change Team Activity Workload' dashboard relies on this data to show which individuals or groups are handling the most activities.

This helps analyze resource performance and workload distribution, identifying individual or team bottlenecks.

This is the standard assignee field on a Jira issue.

This attribute indicates the status of the change request, such as 'Awaiting Approval', 'In Progress', or 'Closed'. The status field in Jira is fundamental to its workflow engine, and changes to this field are primary drivers of the process flow.

Analyzing the status allows for tracking the progress of active changes and understanding the outcomes of completed ones, for example, 'Closed - Successful' versus 'Closed - Failed'. It is key to building throughput dashboards and analyzing rework loops where a status reverts to a previous state.

It provides a clear view of a change request's progress and final outcome, which is crucial for throughput and rework analysis.

This is the standard status field of a Jira issue. The available statuses are defined in the project's workflow configuration.

The Change Type categorizes the change request based on its nature, urgency, and impact. Common types include 'Standard' for pre-approved, low-risk changes, 'Normal' for routine changes requiring full approval, and 'Emergency' for urgent changes to fix incidents.

This attribute is essential for process analysis as different change types often follow different process paths and have different SLAs. It is used to calculate the 'Emergency Change Rate' KPI and to filter dashboards to compare the performance and risk associated with each type.

It enables segmentation of the process to analyze different workflows, such as standard vs. emergency changes, which have unique performance expectations and risks.

This is typically a custom field in Jira Service Management projects. The field name may vary but is often named 'Change Type'.

The Priority field helps teams determine the order in which to address change requests. It reflects a combination of impact and urgency and guides scheduling and resource allocation.

Analyzing priority allows for performance comparisons between high and low priority changes. For example, one can check if high-priority changes truly have shorter cycle times or if they get stuck in the same bottlenecks as other changes. This is valuable for optimizing resource focus and meeting business expectations.

Enables analysis of process performance based on business priority, ensuring that critical changes are being expedited as expected.

This is the standard priority field on a Jira issue.

The Risk Level is a mandatory assessment in most change management processes, categorizing the potential negative impact of a change. The level is determined during the risk assessment phase and often influences the required approval workflow.

In process mining, this attribute is critical for risk-based analysis. It supports the 'Risk Assessment Accuracy & Outcome' dashboard by correlating the initial risk with the actual outcome. It is also the primary dimension for the 'Change Failure Rate by Risk Level' KPI, helping to evaluate if high-risk changes are managed effectively.

Allows for analyzing if process controls and approval workflows are effective for different risk profiles, and helps correlate risk with change failure rates.

This is typically a custom field in Jira Service Management. Common names include 'Risk Level' or 'Impact'.

This is a calculated attribute that compares the actual resolution date of a change request with its 'Target Completion Date'. The result is a simple status, such as 'Met' or 'Breached'.

This provides a clear, at-a-glance indicator of performance for the 'Change SLA Performance Monitor' dashboard. It simplifies the creation of KPIs like 'Change SLA Adherence Rate' by pre-calculating the status for each case. This allows for easy filtering and aggregation to see which types of changes, teams, or services are most often associated with SLA breaches.

Provides a clear, binary outcome for SLA performance on each case, simplifying reporting and analysis of SLA adherence.

Calculated by comparing the timestamp of the final 'Change Closed' activity with the 'TargetCompletionDate' attribute.

This attribute stores the date by which the change request is expected to be completed to meet its SLA. It is the benchmark against which the actual completion time is measured.

This date is fundamental for monitoring performance against commitments. It is the basis for the 'Change SLA Performance Monitor' dashboard and the 'Change SLA Adherence Rate' KPI. By comparing the actual resolution date with this target, organizations can measure their service delivery effectiveness.

This is the primary data point for calculating SLA adherence and identifying which changes are at risk of breaching their deadlines.

This is often the duedate field in Jira or a value from a configured SLA metric in Jira Service Management.

This attribute links the change request to a specific business service defined in the Configuration Management Database (CMDB), such as 'Email Service' or 'Customer CRM'. This is a key concept for understanding the business impact of a change.

Analyzing changes by business service helps prioritize efforts and communicate impact to stakeholders. It allows for a view of which services are undergoing the most change, which are most at risk, and where change-related incidents are concentrated. This is vital for managing technical changes from a business-centric standpoint.

Connects technical changes to business impact, allowing for prioritization and risk analysis based on the criticality of the affected service.

This is often a custom field in JSM, frequently linked to Jira Assets (formerly Insight) or another CMDB.

This attribute captures the underlying reason for the change, such as 'New Feature Implementation', 'Bug Fix', or 'Infrastructure Upgrade'. It provides crucial context beyond the summary or description.

In analysis, the reason for a change can be correlated with other metrics like cycle time, failure rate, and risk level. This helps answer questions such as, 'Do changes related to bug fixes get approved faster than new feature implementations?' or 'Do infrastructure upgrades have a higher failure rate?'.

Provides business context that allows for deeper analysis by correlating the purpose of a change with its performance and outcome.

This is typically a custom field in Jira Service Management, often a select list or text field.

This calculated attribute identifies change requests that have been sent back to a previous stage for modifications, for example, moving from 'Awaiting Approval' back to 'Planning'. It signals that the initial submission was incomplete, incorrect, or did not meet the necessary criteria.

This flag is the basis for the 'Change Rework Rate' KPI and the 'Change Rework and Rejection Analysis' dashboard. By flagging rework cases, analysts can easily filter for them and investigate the root causes, such as poor initial planning, unclear requirements, or insufficient risk assessment.

Highlights process inefficiency by explicitly flagging cases that required extra, unplanned work, enabling analysis of the root causes of rework.

Calculated by analyzing the sequence of activities in the event log. A rework is detected if a later-stage activity is followed by an earlier-stage activity.

This attribute indicates whether the change resulted in a negative outcome, such as a production incident. This often involves linking the change request issue to one or more incident issues in Jira.

This data is essential for calculating the 'Post-Implementation Issue Rate' and 'Change Failure Rate' KPIs. It provides a direct measure of change quality and the effectiveness of the planning, testing, and risk assessment processes. Analyzing which changes lead to issues helps in refining controls and preventing future failures.

Directly measures the quality and success of a change by tracking whether it caused subsequent operational issues.

This is typically derived by checking for linked issues in Jira, specifically if a Change issue has 'is caused by' links from Incident issues.

The Reporter is the individual who created the change request issue in Jira. This is often the change owner or someone initiating the change on behalf of a team.

Analyzing the reporter can help identify which departments, teams, or individuals are initiating the most changes. It can be used to spot trends in change sources and provide feedback or training to groups that frequently submit incomplete or low-quality change requests.

Helps identify the sources of change requests, which can be analyzed to improve the quality of initial submissions.

This is the standard reporter field on a Jira issue.

When a change request is closed, the Resolution field provides specific information about the outcome. For example, 'Done' indicates success, while 'Won't Do' or 'Duplicate' provide other closure reasons. This provides more context than the 'Closed' status alone.

This attribute is essential for analyzing change success and failure rates. For instance, the 'Post-Implementation Issue Rate' KPI can be better understood by filtering for changes with a 'Failed' or 'Rolled Back' resolution. It helps distinguish successfully implemented changes from those that were canceled or rejected after approval.

Provides detailed context on the final outcome of a change, which is crucial for accurately calculating success and failure rates.

This is the standard resolution field in Jira, which is typically set when an issue moves to a 'Done' status category.

This attribute identifies the team assigned to work on the change. While Jira has an 'Assignee' field for individuals, a 'Team' field is often used to assign work to a functional group, such as 'Network Operations' or 'Database Administrators'.

This is crucial for the 'Change Team Activity Workload' dashboard. It allows for analysis of performance and bottlenecks at a team level, rather than just an individual level, which is often more useful for resource planning and management.

Facilitates workload and performance analysis at the team or department level, highlighting systemic bottlenecks.

This is usually a custom field in Jira, as there is no standard 'Team' field. It could be of type 'Group Picker' or a simple select list.