Data Template: Incident Management

The Activity Name describes a distinct step or task performed as part of the incident management process. These activities represent the building blocks of the process map and can include automated system events, such as 'SLA Breach Detected', or manual user actions, like 'Agent Assigned' or 'Workaround Provided'.

For process mining analysis, this attribute is fundamental. It defines the nodes in the process graph, allowing analysts to visualize the flow of work, identify common pathways, discover bottlenecks, and analyze deviations from the standard procedure. The granularity and clarity of activity names directly impact the quality and depth of the insights that can be derived.

This attribute defines the steps in the process, enabling the visualization and analysis of the incident lifecycle flow.

Often derived from a combination of event logs, audit trails, status change records, or task description fields within the incident management system.

The Event Timestamp marks the exact moment an activity took place. Each activity within an incident's lifecycle should have a corresponding timestamp to establish a chronological sequence of events.

This attribute is critical for any time-based process mining analysis. It enables the calculation of cycle times between activities, the duration of specific steps, and the overall incident resolution time. By analyzing timestamps, organizations can identify bottlenecks, measure adherence to SLAs, and understand how process performance changes over time. It is the foundation for calculating key performance indicators like Average Resolution Time.

It provides the chronological order of events, which is essential for calculating durations, identifying bottlenecks, and analyzing process performance over time.

Found in event logs, audit history tables, or as a 'last modified' or 'creation date' on specific related records.

The Incident ID is a unique alphanumeric code that distinguishes one incident from all others within the system. It is generated upon the creation of a new incident and remains constant until the incident is permanently archived or deleted.

In process mining, the Incident ID is the cornerstone of the analysis, serving as the Case ID. It allows the software to stitch together all related events, status changes, and activities into a single, cohesive process instance. By grouping all events under a common Incident ID, analysts can accurately map the end-to-end journey of each incident, from its initial report to its final resolution and closure.

It is essential for linking all related activities and events together to reconstruct the end-to-end incident lifecycle for process mining.

This is the primary key for an incident and is typically found in the header or main record of every incident table or object.

The Last Data Update timestamp specifies when the data was most recently extracted or synchronized from the source system. This is a metadata field that reflects the freshness of the data being analyzed.

In process mining analysis, this attribute is important for understanding the timeliness of the insights generated. It helps users know if they are looking at real-time information or a snapshot from a previous point in time. This context is vital for operational monitoring and ensuring that decisions are based on current, relevant data.

It indicates the freshness of the data, ensuring that analysts understand how current their process analysis is.

This value is typically generated and stamped onto each record during the data extraction and transformation (ETL) process.

The Source System attribute identifies the origin of the data. In environments with multiple ITSM tools or integrated systems, this field helps distinguish records from different sources.

While not directly used in drawing the process map, this attribute is valuable for data validation and governance. It helps analysts trace data back to its origin, understand potential discrepancies between systems, and segment the analysis. For example, one could compare the incident management processes implemented in two different systems, such as ServiceNow and Jira, within the same organization.

It provides context for the data's origin, which is crucial for data validation, troubleshooting, and comparative analysis in multi-system environments.

This is often a static value added during the data extraction process or a field available in the source system's tables.

The Assigned Agent identifies the specific person responsible for an incident. While the Assigned Group points to the team, the agent is the individual performer working on the resolution.

This attribute allows for a more granular level of performance and workload analysis. By tracking assignments at the agent level, managers can assess individual productivity, identify training needs, and ensure a balanced distribution of work. In process mining, it can reveal complex reassignment patterns that might be hidden at the group level and helps in understanding individual contributions to resolution times.

It enables detailed analysis of individual workload, performance, and reassignment patterns within or between teams.

Found on the main incident record, this field is updated when an agent takes ownership or is assigned the incident.

The Assigned Group indicates which team is responsible for the incident at any given time. Incidents are often routed between different groups, such as the Level 1 Service Desk, a Level 2 Network team, or a Level 3 Application Support team.

This attribute is essential for handoff and workload analysis. Process mining can use this data to visualize the flow of incidents between teams, measure the time spent in each team's queue, and identify bottlenecks caused by frequent reassignments. It helps answer questions about team efficiency and collaboration, forming the basis for the Handoff and Reassignment Analysis dashboard.

It is critical for analyzing handoffs between teams, measuring queue times, and understanding team-specific performance and workload distribution.

This information is typically stored on the incident record and is updated every time the incident is assigned to a new team.

The Incident Category provides a structured way to classify incidents based on their nature. This is typically a hierarchical field that allows for progressively more detailed classification, helping to organize incidents into logical groups for reporting and analysis.

Categorization is vital for root cause and trend analysis. By analyzing process maps filtered by category, organizations can identify recurring issues and patterns associated with specific types of incidents. For example, the resolution process for a 'Software' incident might look very different from a 'Hardware' incident. This data fuels KPIs like Initial Categorization Accuracy and Recurring Incident Rate.

It is essential for root cause analysis, identifying trends in recurring incidents, and understanding how different types of issues are handled.

This is a standard, often mandatory, set of fields on the incident record used for classification.

The Incident Status indicates the stage of an incident at a specific point in time. It provides a high-level view of where the incident is in the resolution process. Common statuses include new, assigned, work in progress, pending, resolved, and closed.

This attribute is fundamental for process analysis as changes in status often define the activities in the process map. Analyzing the time spent in each status helps identify bottlenecks, such as incidents waiting for long periods in a 'Pending' state. It is also used to calculate the backlog of open incidents and track progress towards resolution.

It is key to understanding the incident's progress and is often used to generate activities for the process map. Analyzing time spent in each status helps locate delays.

Typically available as a primary field on the main incident record or in the incident's history log.

Priority is a key attribute used to determine the relative importance of an incident and the required speed of response. It is often derived from a combination of the incident's impact and urgency. Levels typically range from critical to low.

In process mining, analyzing incidents by priority allows for a deeper understanding of how the process handles different levels of urgency. Analysts can compare the resolution times for high-priority versus low-priority incidents to see if SLAs are being met and if resources are allocated effectively. It helps answer questions like, 'Are we truly handling our most critical incidents the fastest?'

It enables the analysis of process performance for different urgency levels, helping to verify if critical incidents are handled faster than non-critical ones.

Available as a standard field on the main incident record. It may be set manually or calculated automatically based on impact and urgency.

The Reporting Channel indicates the source of the incident submission. This attribute tracks how users are interacting with the support function, whether through direct contact methods like phone calls or automated methods like system monitoring alerts.

Analyzing the process based on the reporting channel can reveal important differences in efficiency. For example, incidents reported via a self-service portal might be resolved faster because they often contain more structured information upfront. This analysis helps organizations optimize their support channels and encourage the use of more efficient methods.

It helps analyze the efficiency and resolution paths of incidents based on their source, which can inform channel strategy and resource allocation.

This information is usually captured automatically or selected by the agent when an incident is created.

The Resolution Method describes the outcome of the incident and how it was resolved. This could be a standardized code or a free-text description of the actions taken. Examples include 'User education', 'Software patch applied', 'No fault found', or 'Duplicate incident'.

This attribute provides crucial context to the end of the process. In process mining, analyzing incidents by their resolution method helps in understanding the effectiveness of different solutions. It can highlight cases that are closed without a real fix or identify common resolution patterns for specific incident categories, which can then be used to build a knowledge base and improve First Contact Resolution rates.

It provides insight into how problems are being solved, which is key for identifying opportunities for automation, knowledge base improvement, and training.

Typically a field that is filled out by the support agent upon moving an incident to the 'Resolved' or 'Closed' status.

Severity defines the level of impact an incident has on the business. It answers the question of how serious the issue is, independent of its urgency. For example, a system-wide outage would be a high-severity incident, while a minor cosmetic bug would be low-severity.

Analyzing incidents by severity helps organizations understand which types of issues cause the most disruption. Process mining can reveal if high-severity incidents follow a different, more streamlined resolution path. This attribute is crucial for root cause analysis and prioritizing resources for proactive problem management to prevent the most severe incidents from recurring.

It helps in segmenting incidents to understand if high-impact issues are resolved differently or more efficiently than low-impact ones.

A standard field on the incident record, often used in conjunction with urgency to determine priority.

The Affected Service links an incident to a specific component in the IT infrastructure, such as a business application, server, or network device. This is often tied to a Configuration Management Database (CMDB).

This attribute provides critical business context to the incident. In process mining, it allows for analysis focused on the reliability of specific services or assets. Organizations can identify which services generate the most incidents, analyze their resolution processes, and prioritize problem management efforts to improve the stability of critical business services. It's a key element for understanding the broader business impact of IT incidents.

It connects incidents to specific business services or IT components, enabling analysis of which services are most prone to issues and what their impact is.

Typically linked from a Configuration Management Database (CMDB) or selected from a service catalog list on the incident form.

The Reassignment Count is a metric that tracks the number of handoffs an incident undergoes during its lifecycle. A high count often indicates inefficiency, incorrect initial routing, or a lack of knowledge within support teams.

This is a powerful attribute for process mining analysis. While process mining can visualize reassignments, having a pre-calculated count allows for easy filtering and KPI measurement. It is used directly in the Handoff and Reassignment Analysis dashboard and helps identify 'ping-pong' scenarios where tickets are passed back and forth between teams, leading to longer resolution times and user frustration.

This metric directly quantifies process inefficiency. High counts often correlate with longer resolution times and indicate issues with routing or team capabilities.

Often available as a standard counter field on the incident record. If not, it can be derived by counting the number of assignment changes in the incident's audit log.

The Requester is the individual who is experiencing the issue and initiated the incident report. This could be an internal employee or an external customer. The attribute can also capture the requester's department or organization.

Analyzing incidents by requester or requester department helps identify if specific groups of users are experiencing more issues than others. This can point to training needs or localized environmental problems. In process mining, it enables a user-centric view of the support process, helping to understand the experience of different user cohorts.

It allows for a user-centric analysis, helping to identify if certain users, departments, or locations are generating a disproportionate number of incidents.

A standard field on the incident record, typically populated with the user who created the ticket or on whose behalf it was created.

The SLA Status provides a snapshot of an incident's performance against predefined time targets, such as time to respond or time to resolve. Common statuses include 'In Progress', 'At Risk', or 'Breached'.

This attribute is a direct measure of service quality and is a critical input for the SLA Performance Overview dashboard. In process mining, it allows for the comparison of process flows for breached versus non-breached incidents. This helps to identify the specific activities, delays, or rework loops that are the primary drivers of SLA failures, enabling targeted process improvement efforts.

It is a direct measure of performance against targets. Analyzing breached incidents helps pinpoint the process failures that lead to poor service delivery.

This is typically a calculated field within the ITSM tool that is dynamically updated based on the incident's priority, age, and defined SLA rules.