Loading...
 

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 23


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


Quote:
One of the tests of leadership is the ability to recognize a problem before it becomes an emergency - Arnold H. Glasow

More Quotes



Related:

More on Problem Management


Category:
Implementation > People
ITIL Process > Problem Management


1. ITIL® Service Operation, 2011 Edition, Section 4.4.5.2 Problem logging, p. 103
2. “A critical challenge exists in making sure that the two processes incident and problem management have formal interfaces and common working practices.” ITIL® Services Operations, Section 4.4.9 Challenges and risks, 2011 Edition, p. 109.
3. “Problem Management differs from Incident Management in that its main goal is the detection of the underlying causes of an Incident and their subsequent resolution and prevention. In many situations this goal can be in direct conflict with the goals of Incident Management where the aim is to restore the service to the Customer as quickly as possible, often through a Work-around, rather than through the determination of a permanent resolution (for example, by searching for structural improvements in the IT infrastructure, in order to prevent as many future Incidents as possible).” ITIL® Service Support, 2000, Paragraph 6.3.1, p. 97
4. ITIL® Service Operation, 2011 Edition, Section 4.4.5.1 Problem detection, p.103 and Section 4.4.6.1 Triggers, p. 106
5. Ibid, Section 4.4.6.1 Triggers, p. 106
6. Typically a Configuration Item “include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.” ITIL® glossary and abbreviations, 2011 https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf
7. A problem is defined as: the underlying cause of one or more incidents. (ITIL® Service Operation, 2011 Edition, p.97)
8. Service Support, 2000, Section 6.5.3 p. 100.



Disclaimer


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