|
Here is the goal for ITIL Problem Management as quoted in the ITIL
publication Service Support:
The goal of Problem Management is to minimise the adverse
impact of Incidents and Problems on the business that are caused
by errors within the IT Infrastructure, and to prevent recurrence
of Incidents related to these errors. In order to achieve this
goal, Problem Management seeks to get to the root cause of
Incidents and then initiate actions to improve or correct the
situation.
The Problem Management process has both reactive and
proactive aspects. The reactive aspect is concerned with solving
Problems in response to one or more Incidents. Proactive Problem
Management is concerned with identifying and solving Problems and
Known Errors before Incidents occur in the first place.
Let us break this down into its fundamental components and see
what we can identify to help justify ITIL:
Minimise the frequency and impact of IT problems on the
business — this can be a contentious point because
traditionally IT departments have concentrated on performance
rather than quality and support rather than elimination. For
example too often Service Desks are set performance targets such
as a high level of incident solving on the first call without
being set targets for incident reduction. The result is that
instead of finding ways to reduce the number if incidents the
Service Desk is looking for simple incidents to fix on the first
call. This results in delays and frustration for the customer and
more staff on the Service Desk than is necessary.
Look to see whether you have clear targets and objectives to
reduce the number of incidents through Problem Management. If not,
look to see where you have reduced the number incidents over a
period, say one year. There are no industry figures available for
incident reduction due to Problem Management but figures of
between 30% and 70% are often quoted. So if you do not have any
constructive data to show Problem Management in your organization
the take 30% of your Service Desk costs as the potential savings.
Initiate actions to correct each situation — these
actions include; ‘work arounds’ or ‘circumnavigation actions’
which are required, for example, by the Service Desk to quickly
resolve incidents and the actions required to remove errors and
incidents permanently from the infrastructure. First let us look
at the ‘work arounds’. Do your Service Desk or second level
Support Groups provide clear instructions for ‘work around’s? Do
they communicate the ‘workarounds’ as soon as they have been
identified? Do they enter the information in your Support Data
Base or into your Knowledge Management technologies? If you answer
no to any of these questions then you are not initiating actions
to correct each situation.
In many organizations the only time that permanent solutions
are applied is if this is the only way to get the customer working
again. Too often if it can be solved quickly by the Service Desk
on the first call then no effort is made to find a permanent
solution, high first level call solving again. So do you perform
Problem Management and investigate all Incidents to identify
permanent solutions? If not look at your Service Desk data at some
of the most recurring incidents and identify how much you would
save by eliminating these incidents and you have more evidence for
your case for Problem Management.
Find the root cause of Incidents — this goal element for
Problem Management links closely to the previous element. However
true quality management comes from identifying the root cause of a
problem and then deciding whether the cost of eliminating the
problem is comparable to the benefits or savings from eliminating
the root cause. Therefore sometimes it will be decided that it is
cheaper to continue to allow the Service Desk to work around the
resulting incidents rather than eliminate the problem. Often the
root cause is misunderstood. For example according the Help Desk
Institute surveys between 30% and 50% of all Incidents that arrive
at the Service Desk are based around ‘How do I…’ where all the
technology is functional but knowledge is lacking. Often Service
Desks will create knowledge bases to solve this problem or create
FAQs for the same reason but the root cause is lack of customer
education and this is where the effort and finance should be
directed not locking the stable door after the horse has bolted.
Therefore you should be looking to see if you are looking for
the root cause for all incidents/problems and making sensible
business decisions on whether to permanently eradicate those
incidents/problems or not. If you are not then perform the same
actions described in the previous goal element. By the way if are
allowing errors to stay in the system for sensible business
reasons then the work arounds should be fully documented if not
again you are not performing Problem Management.
Prevent the recurrence of Incidents — again this relates
closely to the previous goal but the key here is timing and
determination. First do you have a policy that states that
incidents should be reduced whenever and wherever possible? If not
then you have a justification right there. Secondly when do you
decide to look at incidents with a view to reducing them? When
there are so many that you cannot cope or when an incident appears
for the first time? If you are not looking at each new incident
then you are not performing Problem Management.
Both reactive and proactive — Many organizations are
performing reactive Problem Management to a degree but few are
performing proactive Problem Management. All of the previous
elements in this section point to reactive Problem Management,
i.e. an incident has occurred and we will look at it. However very
few organizations are performing proactive Problem Management by
undertaking activities such as reviewing/analysing the Incident
Data Base or reviewing all changes or new systems to prevent
inherent incidents appearing. Do you perform analysis on your
Incident Data Base to identify trends that will reduce the number
of incidents? If not then you should cite this as a case of
providing poor customer quality. If you are note reviewing changes
and new systems then look at the last few changes/new systems that
failed, or created new incidents, and produce supporting evidence
by analysing how much time and money would have been saved if they
had worked successfully.
Generally Problem Management is not strong in most IT
departments but is often the one ITIL process that provides the
highest returns. So be ruthless when looking at the goals
described here and build a strong case for Problem Management. |
