Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: May 08, 2008 Posts: 39 Location: South West
Posted: Thu May 15, 2008 6:54 pm Post subject: Re: Problem Management Inputs
entivo wrote:
Section 6.2 (p95) of the blue book lists one of the inputs of Problem Management as "Configuration details from the CMDB".
What does this mean?
Surely this is a straight forward understanding?
The whole point of having a CMDB is to understand relationships, I don't do problem management, but keeping it simple, I'm assuming you can help do some root cause analysis in some instances using the information you have stored within your CMDB.
The CMDB will have some sort of feed into every Service Management function as it tends to be the Service aManagement tool that almost all the other fucktions revolve around. I know this has been changed for V3, however it certianly will be considered an important input to Problem Management.
Joined: May 21, 2008 Posts: 2 Location: Auckland, New Zealand
Posted: Thu May 22, 2008 1:19 pm Post subject:
The CMDB should hold information about the CI's, e.g. incident and change records as well as the relationships with other CIs. All of which are very useful for problem management trending. E.g. a certain change to the CI, or a change to a related CI, both of could cause incidents. Definitely making trending and problem analysis a lot easier!!
Joined: May 23, 2008 Posts: 18 Location: Toronto, ON, Canada
Posted: Sat May 24, 2008 12:35 am Post subject:
Two cents here... I am just beginning to develop the PM process at our organization and I recently presented the following inputs as part of the scope for our process.
Reactive:
1. Major incidents
2. Incidents as a result of Change (failed change)
3. Incidents as a aresult of Project (failed project)
4. Customer complaints (yes this is part of problem management)
Proactive:
1. Incident ticket trends
2. Change ticket trends
3. process trends
4. CMDB (use data mining efforts to identify trends or anamoloies about your CI's - physical and logical)
Joined: May 23, 2008 Posts: 18 Location: Toronto, ON, Canada
Posted: Thu May 29, 2008 11:04 pm Post subject:
Once you have implemented a process it is important to supplement the process with continuous improvement. One of the things I am doing with problem management is to analyze these requests to understand what is being asked for and why so that this can be used as input to processes yet to be developed. I am also looking to understand our willingness to change (i.e. how many requests were accepted, why were they accepted or why were they not?) One of the great things about proactive problem management is that you are essentially data mining to identify trends and issues that are not readily apparent. I believe problem management (the proactive part) can quantitatively teach us a lot about how we operate as a business, information which senior management can use to affect strategic change to better the IS organization.
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Fri May 30, 2008 1:58 am Post subject:
Brian,
I see.
Well, as you've mantioned "process trends", I assumed that ITIL processes were included, while the processes improve themselves as they run. I mean there are lessons learned in each process reviews.
Other processes also have their ways to improve like using the TQM.
I just don't want process owners to develop a habit of thinking "Oh, we have the proactive problem management who takes care of improvement so let them do it". Funny, isn't it?
Joined: May 23, 2008 Posts: 18 Location: Toronto, ON, Canada
Posted: Fri May 30, 2008 2:37 am Post subject:
Hi Asril,
Agreed. It is not Problem Management's role, responsibility or accountability for leading continuous improvement. If you are a v2 ITIL shop then it is up to each process manager to manage this on their own and if you are v3 ITIL shop then continuous improvement is a foundation process and this process will enable a consistent approach and application of continuous improvement that can be monitored and audited if needed.
Now all that said, for problem management, we are interested in the data created by continuous improvement so that it can be analyzed as I mentioned before.
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