For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Problem review / Incident review
Joined: Mar 16, 2006 Posts: 12 Location: Rennes, Brittany, Fr
Posted: Tue Apr 24, 2007 7:44 pm Post subject: Problem review / Incident review
Hello,
our organization is divided in two groups : support on one side and engineering on the other side. Most of the problems (anomalies) are posted by the support people in a database checked by the engineering people.
So, we do not have any incident review (a systematic review of a high volume of incidents) and the problem review is restricted to the management of the list of anomalies (analysis and resolution).
In order to move to ITIL, I do not really know what to do. Is Incident Review something compulsory to raise problems ? What would be the role of a Problem Review board : only review problems or to find underlying problems in a list of incidents ?
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Wed Apr 25, 2007 4:38 am Post subject:
So it looks like you have Incident mgmt and are trying to figure out whether you should implement an itil oriented problem mgmtm and how
First, you need to be able to have the support teams properly classify the incidents and the solutions used to restore service as well as the guidelines for when to recommend a incident to be considered for a problem
A problem review board is a combination of a resource allocation and prioritization mechanism to bdetermine which issues get dealt with first
If the incident involves the infamous Blue Screens of Death for Microsoft 4.0, NT , 2k or XP, then should you spend hours ... trying to solve the BSD or just upgrade to the next version or what
there are some incidents for which you will never find the root cause for nor the solution or the solution can not be found in a reasonable time frame
for example the unix clock is tracked in seconds, then converted into time from 1970 if I recall, the clock will get to 0 in 2030 or so....
There is a solution but... you have to wait til after 2030.... _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Apr 26, 2007 10:33 am Post subject: Re: Problem review / Incident review
Hello Nicolas,
Please find my comments, embedded below...
toutencarton wrote:
our organization is divided in two groups : support on one side and engineering on the other side. Most of the problems (anomalies) are posted by the support people in a database checked by the engineering people.
So, at this point you're already doing some Problem Management. Regardless of where these Problems come from, it's a good thing that they're being identified and put in front of engineering. They are typically the product and service owners of all infrastructure and the group who will ultimately be responsible for planning for, designing, building, deploying, and testing all fixes of the Problems. Production Operations will ultimately deploy to the Production environment at the end of that process.
Quote:
So, we do not have any incident review (a systematic review of a high volume of incidents) and the problem review is restricted to the management of the list of anomalies (analysis and resolution).
This is OK. At least you have a start with Problem Management. If you have a help desk that creates and manages Incidents, then you have Incident Management in place. You have already moved to ITIL. It's now a question of how mature do you want to become. You're implying that you'd like to mature by having a fully functional review of all Incidents to generate and manage Incident-related Problems. There are a number of ways to make this happen:
1) Make the Incident Manager responsible for sitting down and identifying trends, patterns, and anomolies in the Incident history that you build up and maintain. In essence, you're creating a Problem Manager role and making the Incident Manager perform the role.
2) Give the Incident data back to engineering and let them identify, track, and manage Incident-related trends, patterns, and anomolies for the products and services they own.
3) Create a separate Problem Manager role that you assign to a new person and let that person be responsible for identifying, tracking and managing Problems. This is the most expensive solution because it means hiring someone new.
Quote:
In order to move to ITIL, I do not really know what to do. Is Incident Review something compulsory to raise problems ? What would be the role of a Problem Review board : only review problems or to find underlying problems in a list of incidents ?
As stated, you already are performing ITIL functions. You're simply trying to mature/improve them, so I would stress because you're on a good path.
Yes, Incident review for the purpose of raising Problems is a part of ITIL. It is typically a Problem Management function. It doesn't matter who does the work. What's important is that someone is doing it.
The Problem Review Board would typically be a group of concerned stakeholders that perform the following functions:
1) Review existing problems for validation and identify if they're worth fixing or not (sometimes they're not)
2) Prioritize which problems are most/least important (provides and order for working on them for engineers)
3) Ensure that Problems are being assigned to appropriate Product & Service owners/organizations
4) Ensure that Problems and their states are being communicated out to the organizations they represent
5) Ensure that Product & Service Ownership teams are planning their Releases and Changes (usually through some form of Project Management functions)
6) Interact with the Product & Service Ownership teams to ensure collaborate on solutions and their timeframes
7) Identify and help drive Problem related reporting (measurements, KPIs, cost savings, quality improvements, customer satisfaction, etc.)
Remember Problem Management is nothing more than "Defect Tracking". All your Product and Service Owner teams are more than likely already doing this in some way, shape, or form. They're just doing it in a vertical fashion, typically only concerned about their own Products/Services. Problem Management, as described by ITIL, is more of a "horizontal" function that goes across all Products & Services. The most important parts of the process are:
1) That Problems/Defects are being identified (who cares if it's through a vertical or horizontal channel)
2) That they are being assigned to some group or person (to ensure that there is accountability for each and every one of them)
3) That the group/person they're assigned to is constantly working on a prioritized list to address them (to ensure that improvement Products and Services is constantly happening)
4) That the work is being communicated
5) That the work is being measured
6) That the measurements are being communicated
7) That you're enterprise is constantly trying to improve the process
Anyhow, I hope this helps.
My Best,
Frank _________________ [Edited by Admin to remove link]
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Tue May 01, 2007 7:21 pm Post subject:
Quote:
Is Incident Review something compulsory to raise problems ?
No, problems could also be raised by a Service manager who gets a lot of particular types of complaints from his customer during his service review meeting. They could be raised by engineers who discover an inherent defect in a service. They could be raised by the support guys who see a lot of similiar types of incident (although this is implicitly incident review).
Quote:
Guerino1 said...
1) Make the Incident Manager responsible for sitting down and identifying trends, patterns, and anomolies in the Incident history that you build up and maintain. In essence, you're creating a Problem Manager role and making the Incident Manager perform the role.
Be aware that this is not recommended by ITIL as there is an inherent conflict between the two roles. Incident managers want to get the service restored and hence the incident closed ASAP. Problem managers want to find a long term solution to the problem.
Problem management is better performed away from the excitement of incident management as the pressures of the latter may conflict with finding a proper solution to the problem rather than a quick fix to get the users up and running.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
