Reactive Problem Management Process Flow

There are corresponding descriptions of each activity in the high level
Reactive Problem Management Process Flow diagram.

Problem Reporting

Role: Problem Reporter Problems can be reported by any group within the IT Enterprise organization that has the opportunity to recognize a situation that is likely to create incidents. The Service Desk or the Service Provider Group may recognize there is a problem because of multiple related incidents. Other groups may do trend analysis to identify potential recurring issues.

Problem Detection

Role: Problem Management Review Team Analysis of incidents as part of proactive Problem Management may result in the need to create a Problem Record so that the underlying fault can be investigated further.

Problems may be identified from the following activities: It is likely that multiple ways of detecting problems will exist in all organizations.
These will include:

  • Suspicion or detection of an unknown cause of one or more incidents by the Service Desk, resulting in a Problem Record being raised – the Service Desk may have resolved the incident but has not determined a definitive cause and suspects that it is likely to recur, so will raise a Problem Record to allow the underlying cause to be resolved. Alternatively, it may be immediately obvious from the outset that an incident, or incidents, has been caused by a major problem, so a Problem Record will be raised without delay.
  • Analysis of an incident by a technical support group which reveals that an underlying problem exists, or is likely to exist.
  • Automated detection of an infrastructure or application fault, using event/alert tools automatically to raise an incident which may reveal the need for a Problem Record.
  • Incident Matching
  • Trend Analysis

Problem Logging

Role: Problem Management Review Team Regardless of the detection method, all relevant information relating to the nature of the Problem must be

logged so that a full historical record is maintained. A cross-reference must be made to the incident(s) which initiated the Problem Record.

Typically, the following details are input during Problem Logging:

  • Unique reference number User details
  • Service details
  • Equipment details
  • Date/time initially logged
  • Priority and categorization details
  • Cross reference to related Incidents
  • Configuration Item details
    Priority and Categorization details
  • Description of incident symptoms that resulted in Problem identification
  • Details of diagnostic or attempted recovery actions taken

Problem Categorization

Role: Problem Management Review Team Problems must be categorized in the same way as incidents using the same codes defined in the Service Catalog, so that the true nature of the problem can be easily tied to the supported service, related incidents and for management reporting.

Problem Prioritization

Role: Problem Management Review Team Problems must be prioritized in the same way and for the same reasons as incidents – but the frequency and impact of related incidents must also be considered.

Before a problem priority can be set, the severity and impact need to be assessed. See the section labeled “Priority Determination”.

Investigation & Diagnosis

Role: Solution Provider Group Properly investigate, diagnose, test and verify the root cause of the Problem and determine the associated Configuration Item (CI). The speed and nature of this investigation will vary depending upon the priority. Problem analysis, diagnosis and solving techniques should be used to facilitate finding the root cause.


Role: Solution Provider Group The Known Error Database (KEDB) can be searched to match the Problem against any known errors and possible

workarounds. Existing workarounds should be identified and assessed as possible resolutions for Incidents related to the Problem.

This activity will also define new workaround(s), if feasible, to take the place of existing workaround(s), or to define a workaround if one does not exist. In cases where a workaround is found, it is important that the problem record remains open and details of the workaround are always documented within the Problem Record.

Create a Known Error Record

Role: Solution Provider Group Once the root cause has been determined, Configuration Item (CI) has been discovered and a workaround or permanent fix is identified, a Known Error record must be raised and recorded in the Known Error database so that if further incidents arise, they can be identified and related to the problem record.

Change Needed Decision?

Role: Solution Provider Group Once enough information is known about the root cause of a Problem, A decision will need to be made regarding the need to create a Request For Change (RFC). If an RFC is to be created, it will need to be submitted, scheduled, and approved following the predefined Change Management procedures.

Problem Resolution

Role: Solution Provider Group As soon as a resolution is found, it should be applied to resolve the Problem. This resolution may lead to initiation of an RFC and approval through that process before the resolution can be applied. In some cases, the cost and/or impact of resolving the Problem cannot be justified. In that case a decision may be made to leave the Problem open and continue to resolve subsequent Incidents using a validated workaround.

Problem Closure

Role: Solution Provider Group When a change has been implemented, confirmed resolved and the Post Implementation Review (PIR) has been conducted, the Problem Record should be formally closed.

A check should be performed at this time to ensure that the Problem record contains a full historical description of all events and if not, the Problem record should be updated.

Once a Problem record has been formally closed, any related Incident Records that are still open, should also be closed and the status of any related Known Error Records should be updated to show that the resolution has been applied.

Major Problem Decision?

Role: Problem Management Review Team Once a Problem has been resolved, a decision must be made regarding whether or not, the Problem qualifies as a Major Problem.

If a Problem is identified as a Major Problem, a formal Major Problem Review will be scheduled and performed to review the existing process, any changes that may be needed and how to prevent this or similar Problems from occurring in the future.

Major Problem Review

Role: Service Provider Group Managers & CTO When a Problem warrants a Major Problem Review, a meeting will be convened to identify what was done right, what was done wrong, what could be done better next time, and how to prevent the Problem from happening again.

Pre-register now!

GroupLink ITSM Problem Management’s beta release is scheduled for Q4 of 2021. Fill out the form below and we’ll you know when it becomes available.