The purpose of a Problem ticket is to manage the analysis process for either what happened during a Major Incident ticket or for analysis of recurring incidents that seem to be related. This article covers the following topics:
- What does Problem Management look like?
- When to Open a Problem Ticket
- What are the benefits of Problem Management?
What does Problem Management look like?
- Analyzing the root cause of Major Incidents or recurring incidents.
- Diagnosing and discovering the resolution to the underlying cause of Incidents.
- Ensuring that a resolution is implemented (often through Change Management) or a Known Error is documented.
When to Open a Problem Ticket
Open a Problem ticket for either of the following situations:
- For analysis of what happened during a Major Incident AFTER the Major Incident ticket has been resolved.
- Someone from the Tier 2 or Tier 3 team who took responsibility for the Major Incident should open a Problem ticket in consultation with a Service Owner or Responsible Group Manager.
- For analysis of recurring Incident tickets that show a trend in something not working correctly.
- Example: a number of Incident tickets have been opened for harddrive failure of a specific Dell laptop in use before the laptop warranty expired.
- Any technician can technically open a Problem ticket when they have noted a trend but should do so only after consulting a Service Owner or Responsible Group Manager.
See Create a Problem Ticket for specific instructions on opening and working through a Problem ticket.
What are the benefits of Problem Management?
- Improved organizational efficiency by ensuring that Problems are prioritized correctly according to impact, urgency, and severity.
- Elimination of incidents before they impact services through proactive Problem management.
- Prevention of known errors recurring or occurring elsewhere across the system.
- A known error is a Problem that has been successfully diagnosed and either a work-around or permanent resolution has been identified. Known errors should be documented in a Knowledge Base article to capture the resolution so it can be shared across the organization and with the user community.