Your Problem Management Data Template

The Activity Name describes a single step in the problem management process, such as 'Problem Record Created', 'Root Cause Identified', or 'Permanent Fix Implemented'. These activities are recorded chronologically to build the story of how a problem was handled.

For process mining, this attribute is critical for constructing the process map, which visually represents the actual flow of work. Analyzing the sequence, frequency, and paths of these activities helps uncover deviations, bottlenecks, and inefficiencies in the problem resolution process.

This attribute defines the steps in the process, enabling the visualization and analysis of the process flow, including common paths and deviations.

Activity names are often derived from status change logs, audit trails, or event tables associated with the primary problem record.

Event Time, or timestamp, provides the chronological context for each activity in the problem's lifecycle. It is essential for sequencing events correctly and for calculating durations between different process steps.

In process mining, this attribute is used to order activities, discover the process model, and perform all time-based analysis. It is the basis for calculating key performance indicators like 'Avg Root Cause Investigation Time' and for identifying delays between steps, such as the handoff between identifying a root cause and initiating a change request.

The timestamp for each activity is crucial for ordering events and calculating all time-based metrics, such as cycle times and bottleneck durations.

This timestamp is usually located in an event log or audit trail table alongside the activity name and case identifier.

The Problem Record ID serves as the primary key for tracking the entire lifecycle of a problem from its creation to its final resolution. Each problem, which may be linked to multiple incidents, is assigned a unique ID to distinguish it from all other problems.

In process mining, this attribute is fundamental as it defines the case, allowing the tool to group all related activities into a single process instance. Analyzing process flows, identifying bottlenecks, and calculating case durations all depend on the correct identification of each unique problem record.

This is the essential Case ID that groups all related events, making it possible to trace the end-to-end journey of each problem investigation.

This identifier is typically found in the main problem or ticket table of the IT Service Management (ITSM) system.

This attribute records the date and time of the most recent data pull. It provides transparency into the freshness of the data being analyzed, ensuring that stakeholders understand the time frame covered by the analysis.

In dashboards and reports, this information is critical for context. It helps users know if they are looking at real-time information or a snapshot from a specific point in time, which affects the interpretation of metrics like 'Aged Problem Backlog'.

Provides crucial context on data freshness, ensuring that analyses and dashboards are interpreted correctly based on the last data refresh.

This timestamp is usually generated and stored by the data extraction, transformation, and loading (ETL) tool or script during data ingestion.

This attribute identifies the origin of the problem management data, for example, ServiceNow, Jira, or a homegrown ITSM tool. It is particularly important in environments where data from multiple systems is combined for a holistic analysis.

In a process mining context, Source System can be used as a filter to compare process performance and variations across different business units or platforms. It also aids in data validation and troubleshooting by providing context about where the data originated.

Identifies the data's origin, which is crucial for data validation and for comparing processes across different systems or organizational units.

This is typically a static value added during the data extraction process to label records from a specific source system.

This attribute links a problem to a specific component or service within the IT infrastructure, such as 'Email Service' or 'Customer Relationship Management Platform'. It provides critical business context to the technical issue.

In process mining analysis, the Affected Service allows for a business-centric view of the process. It helps answer questions like, 'Which services generate the most problems?' or 'What is our average resolution time for problems affecting critical financial systems?'. This context is crucial for prioritizing improvement efforts based on business impact.

Provides business context by linking technical problems to the services they impact, enabling prioritization based on business criticality.

This is typically linked from a Configuration Management Database (CMDB) and stored in a 'Configuration Item' or 'Service' field on the problem record.

Priority is a key attribute used to classify problems based on their business impact and urgency. It helps teams focus their efforts on the most critical issues first. Priority levels are often standardized, such as Critical, High, Medium, and Low.

In process analysis, Priority is a powerful dimension for filtering and comparison. Analysts can compare the process flow for high-priority problems versus low-priority ones to see if they are handled differently or more efficiently. It is also fundamental for SLA compliance analysis, as SLAs are often tied to priority levels.

Allows for segmenting analysis to compare how critical problems are handled versus routine ones, and is essential for measuring SLA adherence.

This is a standard field in the main problem record table of most ITSM platforms.

This metric counts how many times the responsibility for a problem was transferred. A high reassignment count often indicates process inefficiency, such as incorrect initial routing or a lack of clarity in team responsibilities.

In process mining, this is a key indicator of process friction. It can be used to identify 'ping-pong' scenarios where a problem bounces back and forth between teams. Analyzing cases with high reassignment counts can reveal knowledge gaps or process flaws that lead to significant delays and wasted effort.

Helps quantify process inefficiency by tracking excessive handoffs, which often point to incorrect routing, knowledge gaps, or unclear responsibilities.

This is often a counter field that is incremented on the problem record with each assignment change. It can also be calculated from the event log.

This attribute quantifies the impact of a problem by showing how many user-facing incidents it has caused. A problem with a high number of related incidents is typically more disruptive to the business.

This metric is a powerful tool for prioritization and impact analysis. In process mining, it can be used to correlate the number of incidents with investigation time or resolution priority. It helps organizations understand the scale of issues and justifies the resources spent on problem management by showing how many incidents are prevented by a single fix.

Quantifies the business impact of a problem, helping to prioritize investigations and measure the effectiveness of the resolution.

This value is often a calculated field on the problem record that counts the number of linked incident records.

Once an investigation is complete, the Root Cause Category is used to classify the fundamental reason for the problem, such as 'Software Defect', 'Hardware Failure', or 'Configuration Error'. This categorization is vital for strategic improvement.

This attribute is the cornerstone of the 'Root Cause Investigation Performance' dashboard. By analyzing the frequency of different root cause categories, organizations can identify recurring systemic issues and prioritize long-term fixes. It helps shift the focus from reactive problem solving to proactive prevention.

This is critical for strategic analysis, helping to identify systemic issues and trends in what is causing problems across the organization.

This information is usually captured in a dedicated field on the problem record, often filled in before or during the closure phase.

This boolean attribute provides a simple, direct indicator of whether a Service Level Agreement was met. It is typically set to true if the problem's resolution timestamp is later than its SLA Due Date.

As a direct outcome measure, this flag is extremely useful for high-level dashboarding and reporting. In process mining, it can be used to create conformance checks or to filter for all breached cases. Analyzing the process maps of breached versus non-breached problems can reveal patterns, bottlenecks, or specific activities that are common causes of SLA failure.

Provides a clear success or failure outcome for SLA compliance, making it easy to filter for and analyze the process paths that lead to breaches.

This is often a derived or calculated field, determined by comparing the resolution timestamp to the SLA Due Date.

The SLA Due Date sets a formal target for problem resolution. This target is usually determined based on the problem's priority and the terms defined in the service level agreement (SLA).

This attribute is essential for the 'SLA Compliance Overview' dashboard. By comparing the actual resolution time with the SLA Due Date, organizations can calculate SLA success rates. Process mining can further break this down to identify which process steps or teams are contributing most to SLA breaches.

Defines the resolution target, forming the basis for all SLA compliance measurement and reporting.

This date is typically calculated and stored on the problem record based on its creation time and priority.

The Support Group indicates which team is assigned to the problem. As a problem progresses, it may be reassigned between different groups, such as from a Level 2 support team to a specialized Network Engineering team.

This attribute is essential for analyzing team performance and inter-team handoffs. Process mining can highlight delays caused by reassignments, measure how long problems stay with each group, and identify which teams are most effective at resolving certain types of problems. It directly supports dashboards like 'Support Group Handoff Analysis'.

Crucial for analyzing team performance, identifying bottlenecks caused by handoffs, and understanding workload distribution across different teams.

This information is typically stored in the problem record's assignment history or main details table within the ITSM system.

This attribute identifies the specific person responsible for the problem at any point in time. While the Support Group defines the team, the Assigned User points to the individual agent, engineer, or coordinator handling the investigation.

Analyzing by Assigned User can help in understanding individual workloads, performance, and training needs. It can highlight if certain individuals are becoming bottlenecks or if work is not being distributed evenly within a team. This view is complementary to the support group analysis.

Enables analysis of individual workload and performance, helping to identify top performers or individuals who may require additional support or training.

This field is typically found in the main problem record table, often labeled as 'Assignee', 'Assigned To', or 'Coordinator'.

The Problem Status indicates the current stage of the problem in its workflow. It provides a snapshot of where the problem is at any given time, from initial logging to final resolution.

While the Activity Name captures the event of changing status, the Problem Status itself is useful for analyzing the current backlog. It allows for creating dashboards that show the number of open problems in each state, helping to manage workloads and identify records that are stuck in a particular phase for too long.

Indicates the current stage of a problem, which is essential for backlog analysis and identifying problems stalled in a specific phase.

This is a standard field on the main problem record table that is updated as the problem moves through its lifecycle.

This attribute creates a direct link between the problem management process and the change management process. It is used when a code change, hardware replacement, or other modification is required to resolve the problem's root cause.

Analyzing this link is key to understanding the 'Change Management Handoff Delay'. Process mining can measure the time from when a root cause is identified to when a change request is created, and from when the change is implemented to when the problem is finally closed. This helps identify inefficiencies in the interaction between the two processes.

Links the problem to its solution in change management, enabling analysis of handoff delays and the end-to-end resolution lifecycle.

This is typically a reference field on the problem record that links to the corresponding record in the change management system or module.

This attribute tracks whether a temporary solution has been made available to mitigate the impact of the problem while a permanent fix is being developed. This is a key milestone in the problem management lifecycle.

This is a critical attribute for the 'Workaround Effectiveness And Speed' dashboard. Process mining can be used to calculate the average time to provide a workaround, and subsequent analysis can correlate the provision of a workaround with a reduction in new related incidents. This helps measure the team's ability to quickly restore service, even before the root cause is fixed.

Indicates if service has been temporarily restored, allowing for analysis of how quickly the team can mitigate business impact.

This can be a boolean flag ('WorkaroundPublished'), or derived from the presence of text in a workaround details field.