Should everyone be allowed to log problems

By ITIL® from Experience©

The 2011 Edition of ITIL® does not specify who should log problems1 . That being said, for Problem Management to be successful, it is critical that business rules are in place to govern who is can log problems in the ITSM Tool. Such rules also go a long way to ensure that Problem and Incident Management remains separate processes 2 3

ITIL® recognizes that “multiple ways of detecting problems will exist in all organizations”4 and that “the vast majority of problem records will be triggered in reaction to one of more incidents, and many will be raised or initiated via Service Desk staff5 .” (The emphasis is ours to highlight the distinction between “logging” and “raising/initiating.”)

As a single-point-of-contact having the Service Desk log reactive problems may work when it is structured as specialized groups with functional-escalations contained within the Service Desk itself (e.g. first-level, second-level). However, most service desk do not operate in this fashion and escalate incidents to another tier/group in operations.

Regardless of the type of Service Desk structure, a common mistake is to allow them or anyone providing support to log problems. As a result many problems are logged simply because someone reached the limit of their knowledge or because they could not find a corresponding record in the Known Error Database (if they bothered to search it). Thus, resources working on problems, which are typically the senior and most knowledgeable people, deal with trivial issues and essentially become an extension of first-line support. This severely undermines the value of Problem Management and inundates technical specialists with insignificant issues.

A better approach is to only allow the Configuration Item's owner or custodian group to log a problem for their CI6 , or at least to authorize it. In this fashion, they also “own” the problem record and can be held accountable for their life cycle. They also usually have the skills to quickly determine if the issue detected is a problem7 . Other benefits include:

• Filtering to ensure that only valid and valuable problems are logged
• Ability to identify and avoid duplicate problems from being logged
• Detect when a problem which fixed re-appear
• Acceptance of the problem and its related workload
• Accountability for the lifecycle of the problem record (e.g. their closure).

This method enables the logging of both reactive and proactive problems.

This is in line with ITIL® version 2’s guidance which states that:
“Problem Management staff should accept support requests only from authorised sources. Difficulties will arise if the process deals with requests from many sources since multiple reports of Incidents with the same cause may not be interpreted in the same way.”8

Proactive problem management can also raise/initiate a discussion with the CI owner when a trend has been identified.

Published on: 2018-01-13

Related:

• Should a problem be logged for every unexplained incident
• How to first introduce Problem Management
• Should a Problem be opened for every Major Incident
• When to use a RACI Matrix
• How to get people to log tickets

More on Problem Management

Category:
Implementation > People
ITIL Process > Problem Management

Disclaimer

Copyright 2018 - ITIL® from Experience© - D.Matte