About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
incident management , IT service management , ITIL , ITSM , problem management , service desk , service management , supportworld
No Result Found
I have had the opportunity to assist several IT organizations in designing and implementing a best-practice problem management process. Inevitably, this question always came up, “When should a problem record be opened?”
Problem management is one of the two IT service management processes we refer to as “service resolution and restoration” processes. The other process is incident management. When performed well, problem management is an indication of a more mature IT service provider. While incident management is focused on restoring normal service operation as quickly as possible, problem management focuses on determining the root cause of one or more incidents, identifying temporary workarounds, and applying permanent fixes so that incidents don't happen again. This would imply that an incident needs to first occur before a problem record can be opened. However, this is not necessarily so.
The scope of problem management includes two different aspects: reactive problem management and proactive problem management. Reactive problem management seeks to identify the underlying cause of one or more reported and recorded incidents as they occur, while proactive problem management seeks to identify and prevent potential incidents before the customer is impacted, in essence “resolving” the incident that never occurred. Proactive problem management looks for trends and patterns and is used to foresee and correct errors in the infrastructure before the manifestation of incidents. Thus it is possible that an incident record may not exist at the time a problem record is opened.
What I have seen most often happen in IT organizations when first standing up a formal problem management process, is that technical staff are hesitant and unsure as to when to open a problem record, so few get opened. To address this challenge, you will want to develop a clear list of the criteria for when a problem record must be opened. The following is a suggested list for when to open a problem record:
Other triggers for opening a problem record reactively may include:
Triggers for opening a problem record proactively may include:
Another question that is often asked is, “Who should open a problem record?” Problems may be identified via a number of different sources:
A problem record can be opened by the service desk or by any technical support group member. The problem record should be opened by whoever first discovers or suspects that a problem may exist. From a reactive problem management perspective, an incident record must be opened first and the incident record linked to the problem record. There is much industry debate as to whether the service desk should be allowed to open a problem record. I believe they should, but under the following conditions or criteria:
Given the above criteria, there is no reason why the service desk should not be able to open a problem record and assign it to an appropriate technical support group.
I suggest the following reports be created to ensure that problem records are being opened appropriately (per your defined policy and organization-specific criteria):
To have an effective problem management process, you must define when a problem record should be opened, who can open a problem record, and ensure appropriate reports are produced from the process. As I close this article, I will leave you with a few helpful hints:
This article is based on material presented in Problem Management: A Practical Guide , by Jim Bolton and Buff Scott III
Buff Scott III has more than 30 years of experience in the IT industry. He’s a versatile leader with extensive management experience, and he’s an accredited ITIL v3 Expert, ITIL Trainer, and HDI Faculty member. Among his many other skills and accomplishments, Buff’s been designing and implementing ITIL processes since 2001, and he specializes in business and IT process reengineering.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The APMG-International Service Catalogue and Swirl Device logo is a trade mark of The APM Group Limited.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
WEB DEVELOPMENT PARTNER