ITIL Foundation Online Training - $47/mo Description: 14+ Hours, 200+ Practice Questions, Lifetime Access, 100% Online, Self-paced Click Here

10 Full ITIL Mock Exams for only $25/mo.Check if you are ready to take the ITIL Exam and crack it in the first attempt Click Here

Tuesday, March 13, 2012

The Problem Management process flow

The Problem Management process flow is the sequence of steps that are followed to handle a problem.
1. Inputs to the process - The inputs to Problem Management can come from a number of sources. These include Incident Management, Event Management and the Service Desk. Additionally, proactive Problem Management may identify Problems. Suppliers and other processes such as Release Management, Capacity Management and Availability Management may also become aware of Problems.
2. Problem detection - Problems can be detected in many ways. The Service Desk may believe that one or more Incidents are being caused by a particular Problem. Second-line support areas may identify a Problem when conducting Incident handling. Problems can also be detected automatically by the Service Management tools in use. Proactive Problem Management will identify problems often before any Incidents occur. Likewise, other processes such as Release Management and Availability Management will become aware of Problems.
3. Problem logging - It is crucial that the full details of the Problem are recorded. This will allow analysis to take place and will enable comparisons to be made between Problems. All Incidents caused by the Problem should be linked to the Problem record allowing the scope and scale of the impact to be ascertained easily. The date and the time that all Problems are logged must be recorded within the Problem record.
4. Problem categorization - It is important to categorize Problems and it is recommended that the same system is used as adopted by the Incident Management process for any particular organization. Correct and meaningful categorization will allow helpful metrics to be produced and enable proactive Problem Management to identify areas to concentrate on.
5. Problem prioritization - Problems should be prioritized in the same way as Incidents. For ex: A High urgency problem raised by senior management will be priority 1. Most IT Service companies have a matrix that they use to arrive at the priority of the problem taking multiple factors into consideration. They would be:
o Impact of the Problem
o Urgency of the Problem
o Who raised it

Target Problem resolution times will be assigned to each Priority level. These will have been agreed with the business and recorded in the SLA. One factor that will feed into the impact and urgency of Problems is the rate of reoccurrence.
Problem investigation and diagnosis - The aim of the investigation and diagnosis phase is to ascertain the root cause of the Problem. The priority allocated to the Problem should drive the number of resources working on the investigation and diagnosis. Priority should be reassessed during the lifetime of the Problem to ensure that it remains correct.

The figure below explains the Process Flow:

Problem Records must remain open when a workaround has been identified and the workaround should be detailed in the Problem record. Permanent fixes should still be progressed. However, there may be reasons why workarounds remain in place for some time.

These reasons include:
• A permanent fix is too risky
• A permanent fix is too costly
• The business impact of the Problem is not significant enough to justify further diagnosis at this time;
• The Problem will be permanently fixed by a new Release that is currently being planned.
Raising a Known Error Record - The Known Error Database is an important source of information for the Service Desk and Support groups handling Incidents and Problems. A Known Error Record should be raised when the diagnosis has been completed and especially when a workaround has been identified.
Problem resolution - Once a permanent fix has been identified, it should be implemented as soon as possible. However, there may be good reasons why this is not possible. The reasons are similar to the reasons why organizations live with workarounds and include cost and risk. Additionally, an immediate fix may require a service outage which is not justifiable in the short term. A Request For Change (RFC) should be raised and progressed for any required Change identified.
Problem closure - Problem Records should be closed once a Change has successfully been applied. It is important that the Problem Record stays open until it is certain that the Problem has been resolved. Checking that the Problem has been resolved should be undertaken via testing. It may take some time to ensure that a fix has been successful, for example it may be the next time a particular process is used such as end of day, end of month, end of quarter, year-end or end of tax year.
Major Problem Review- Whenever a Major Problem has occurred, a Major Problem Review should be undertaken. Each organization will have its own definition of a Major Problem based on the impact and urgency. It is crucial that these reviews look at lessons learnt rather than becoming ‘allocation of blame’ sessions. The output from a Major Problem Review ought to include what went well, what went badly, what could be done better in the future, how could the Problem have been prevented and how could the impact of the Problem have been reduced.

Prev: More on Problem Management

Next: Problem Solving Techniques

No comments:

Post a Comment


© 2013 by All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.


Popular Posts