Problem management - AbsoluteAstronomy.com

This article is about Problem Management Process, as defined by ITIL.

ITIL

Itil

Itil may mean:*Atil or Itil, the ancient capital of Khazaria*Itil , also Idel, Atil, Atal, the ancient and modern Turkic name of the river Volga.ITIL can stand for:*Information Technology Infrastructure Library...

defines a problem as the cause of one or more incidents

Incident management

Incident Management refers to the activities of an organization to identify, analyze and correct hazards. For instance, a fire in a factory would be a risk that realized, or an incident that happened...

.

Problem Management is the process responsible for managing the lifecycle of all problems. The primary objectives of Problem Management

Problem management

This article is about Problem Management Process, as defined by ITIL.ITIL defines a problem as the cause of one or more incidents.Problem Management is the process responsible for managing the lifecycle of all problems...

are to prevent problems and resulting incidents from happening, to eliminate recurring incidents, and to minimize the impact of incidents that cannot be prevented.

Scope

Problem Management includes the activities required to diagnose the root cause

Root cause

A root cause is rarely an initiating cause of a causal chain which leads to an outcome or effect of interest. Commonly, root cause is misused to describe the depth in the causal chain where an intervention could reasonably be implemented to change performance and prevent an undesirable outcome.In...

of Incident Management

Incident management

and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially Change Management

Change management

Change management is a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state. It is an organizational process aimed at helping employees to accept and embrace changes in their current business environment....

and Release Management

Release management

The release management process is a relatively new but rapidly growing discipline within software engineering of managing software releases....

.

Problem Management will also maintain information about problems and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of Incident Management over time. In this respect, Problem Management has a strong interface with Knowledge Management

Knowledge management

Knowledge management comprises a range of strategies and practices used in an organization to identify, create, represent, distribute, and enable adoption of insights and experiences...

, and tools such as the Known Error Database will be used for both. Although Incident Management and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related incidents and problems.

Value to business

Problem Management works together with Incident Management and Change Management to ensure that IT service availability and quality are increased. When incidents are resolved, information about the resolution is recorded. Over time, this information is used to speed up the resolution time and identify permanent solutions, reducing the number and resolution time of incidents. This results in less downtime and less disruption to business critical systems.

Additional value is derived from the following:

Higher availability of IT services
Higher productivity of business and IT staff
Reduced expenditure on workarounds or fixes that do not work
Reduction in cost of effort in fire-fighting or resolving repeat incidents.

Process activities, methods and techniques

Problem Management consists of two major processes:

Reactive Problem Management, which is generally executed as part of Service Operation
Proactive Problem Management which is initiated in Service Operation, but generally driven as part of Continual Service Improvement (CSI).

Problem detection

Suspicion or detection of a cause of one or more incidents by the Service Desk, resulting in a Problem Record being raised – Service Desk may have resolved the incident but has not determined a definitive cause and suspects that it is likely to recur.
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.
A notification from a supplier or contractor that a problem exists that has to be resolved.
Analysis of incidents as part of proactive Problem Management: watch-bulletins, releases, relevant papers

Problem logging

All the relevant details of the problem must be recorded so that a full historic record exists. This must be date and time stamped to allow suitable control and escalation. A cross-reference must be made to the incident(s) which initiated the "Problem Record":

User details
Service details
Equipment details
Date/time initially logged
Priority and categorization details
Incident description
Details fo all diagnostic or attempted recovery actions taken.

Problem categorization

Problems must be categorized (severity/priority) in the same way as incidents in order to trace a problem. Prioritize a problem implies to keep into account the impact of the incidents and the frequency of the occurrences.
Problem priorization should take into account the severity of the problems. From an infrastructure point of view we can have:

Can the system be recovered, or does it need to be replaced?
How much will it cost?
How many people will be involved to fix the problem?
How long will it take to fix the problem?
How many additional resources will be involved?

Problem investigation and diagnosis

The result of an investigation for a problem will be a root cause diagnosis or a RCA report. The resolution should be the sum of the appropriate level of resources and skills used to find it.
There are a number of useful problem solving techniques that can be used to help diagnosis and resolved problems.

The CMS must be used to help determinate the level of impact and to assist in pinpointing the point of failure. *The Known Error Database or KEDB should be accessed and checked in order to find out if the problem has occurred in the past, if so a resolution should be already in place.
The Chronological analysis, the events that trigged the problem will be checked in chronological order in order to have a timeline of events. The purpose is to see which event trigger the next event and so on, or to rule out some possible events.

The Pain Value Analysis contains a broader view of the impact of an incident or a problem on the business. Rather than analysing the number of incidents/problems of a particular type in a particular time interval, the technique focus on in-depth analysis of what level of pain has been caused to the business by these incidents/problems. A formula to calculate the level of pain should take into account:

the number of people affected
the duration of the downtime caused
the cost to the business

The Kepner and Tregoe method it's used to investigate deeper-rooted problems. They defined the following stages:

defining the problem
describing the problem in terms of identity, location, time (duration) and size (impact)
establishing possible causes
testing the most probable cause
verifying the true cause

Pareto Analysis is a technique for separating important potential causes from trivial issues. The following steps should be taken:

Form a table listing the causes and their frequency as a percentage
Arrange the rows in the decreasing order of importance of the causes (the most important cause first)
Add a cumulative percentage column to the table
Create a bar chart with the causes, in order of their percentage of total
Draw a line at 80% on the Y-axis, then drop the line at the point of intersection with the X-axis. From the chart you can see the primary causes for the network failures. These should be targeted first.

Network failures
Causes Percentage of total Computation % Cumulative
Network Controller 35 0+35% 35
File corruption 26 35% + 26% 61
Server OS 6 61%+6% 67%

	Network failures
Causes	Percentage of total	Computation %	Cumulative
Network Controller	35	0+35%	35
File corruption	26	35% + 26%	61
Server OS	6	61%+6%	67%

Known Error Record

After the investigation is complete and a workaround (or even a permanent solution) has been found, a Known Error Record must be raised and place in the Known Error Database in order to identify and resolve further similar problems. The main purpose is to restore the affected service as soon as possible with a minimal impact on the business.

A good practice would be to raised a Known Error Record even earlier in the investigation - just for information purposes.

Major Problem Review

A good practice is to have a review for all major problems.
The review should examine:

The correct steps taken
The problems encountered during the implementation of the solution
The need to improve
Prevent the recurrence of further similar incidents
3-Party/Vendor/Supplier involved in the implementation

The knowledge learned from the review should be incorporated into a service review with the business customer to ensure that the customer is aware of the actions taken and the plans to prevent future similar incidents from occurring.This helps to improve customer satisfaction and assure the business that Service Operations is handling major incidents responsibly and actively working to prevent their future recurrence.