become-itil-foundation-certified-abhinav-kaiser(www.ebook-dl.com)

7.5.4.1 What Is a Problem?
Chapter 7 ■ Service Operations
The ITIL service operations publication offers the following definition of a problem:
A problem is the underlying cause of one or more incidents.
In simple terms, there are incidents where the fix is yet to be found. The resolution
of these incidents is not possible as the root cause of the incident is unknown. This is
similar to a doctor prescribing medicines; if he does not know what the cause of certain
symptoms are, he will not be on a strong footing to prescribe medicines. Likewise,
to resolve incidents, the technical resolver groups must know the root cause of the
problems. If they do not know the root cause, they start to shoot in the dark by asking
users to restart machines, uninstall and reinstall software, and do other needless activities
that most often amount to a waste of time and resources. But if the principles of problem
management were to be applied and the root cause identified, the solution would follow
as a matter of routine.
A problem gets raised when the root cause of an incident is unknown. Or a bunch of
incidents with a common thread are unable to be resolved as the underlying root cause is
yet to be identified.
7.5.4.1.1 Incidents vs. Problems
It is my experience that many IT professionals in the IT service management industry
use the terms incident and problem interchangeably. This does more harm than good,
especially if you are working in an organization that takes shape after ITIL, and especially
if you are preparing for the ITIL Foundation exam. In this section, I will differentiate
the two terms with examples, so as you move forward toward the process and other
key terminology, there shouldn’t be any doubt in the difference between incidents and
problems.
Incidents are raised due to loss or degradation of services. They are raised by users,
IT staff, or event management tools. When incident resolution is not possible, as the
underlying root cause is unknown, the IT team will raise a problem.
In some instances, IT staff may resolve incidents without understanding the root
cause. In such cases, a problem ticket is raised as well. For example, as a resolution step,
the server is rebooted, and the incident gets resolved. However, the underlying cause of
why the incident happened in the first place will remain a conundrum.
Remember that users and event management tools don’t raise problems, but
generally speaking, they can only come through the incident. Although, in a mature IT
environment, you can configure event management tools to look for specific patterns of
events and subsequently raise problems on the back of them. But, let’s keep this discussion
out of the scope and restrict problems to be derived only on the back of incidents.
Let’s consider the example of a software application that crashes when it is initiated.
The user raises an incident to fix this issue. The software resolution team tries to start
the application in safe mode, uninstall and reinstall the application, and finally make
changes to the operating system registry, but to no avail. When all hopes fail, they provide
a heads-up to the problem management process to find the root cause and provide a
permanent solution.
179