.png?width=250&height=56&name=stonewater-logo%20(1).png)
Section 2 - What is Problem Management?
Problem Management seeks to minimise and adverse impact of Incidents by preventing Incidents from happening. For Incidents that have already occurred, Problem Management works to prevent these Incidents from happening again.
ITIL defines a "Problem" as "the underlying cause of one or more Incidents"
Problem Management works closely with Incident Management, but it is not the same:
- Incident Management is about restoring services as quickly as possible (and within SLA) to ensure business continuity, sometimes by applying temporary solutions (workaround)
- Problem Management is tasked with analysing root causes and preventing Incidents from happening in the future
All Problems should be logged by DSP Team Members on behalf of the DSP customers as Problem Records (PRB Records) within DSP's ITSM (Cherwell) toolset, where their status can be tracked, and a complete historical record maintained.
Who can raise PRB Records?
While DSP Customers can view and update PRB Records from with the DSP ITSM Portal the creation of PRB records is restricted to DSP Staff Members. However, DSP customer can request a PRB record via an update on another ticket (such as a request for Root Cause Analysis). Alternatively customer can discuss the need for a PRB record as part of their regular meeting cycle.
Are Problem Record Progress Updates Included in DSP Service Reviews?
Yes, DSP present updates on PRB records (along with Incident / Request and Change) as part of the Service Review Process.
How do DSP categorise and Prioritise Problem Records?
The categorisation and prioritisation should be is uniformed with the approach used in Incident Management, to facilitate matching priorities between Incidents and Problems wherever possible. However – additional factors should be considered specific to Problem Management when determining the initial or changing the severity / priority of a Problem Record –
P1 = High risk of unmitigated recurrence of significant P1/P2 Incident if this action is not resolved where it is known the incident will remove critical services or business processes affecting the whole business or customer. The desired action is to directly address a root cause which will either completely prevent such incidents from recurring or greatly reduce their impact to a negligible level. Workaround / significant mitigation unavailable. Root Cause likely unknown.
P2 = Medium / high risk of unmitigated recurrence of a high priority P2 incident if this action is not resolved where it is known the incident will remove critical services or business processes affecting a key department, business process or subset of customers. The action directly addresses the root cause and will either significantly mitigate the impact of a recurrence or have a high chance of preventing a recurrence. Workaround or mitigation could be available but untested / inconsistent or time consuming to enact. Root cause may or may not be known but impact of repeat incident is less than a P1 (whole company / Production / All Customers).
P3 = Medium risk of recurrence of the incident but mitigated. The mitigation may not be optimised or a permanent fix. Root Cause likely to be known. No customer impact likely only affecting an internal department, function or process. Issue not likely Production availability impacting.
P4 = Low risk of recurrence of the incident but mitigated. The mitigation may not be optimised or a permanent fix. Root Cause known. No customer impact only affecting an internal user department, function or process. Issue not Production availability impacting.
