| nicole2/07/2008 11:53:34 AM |
In our Autumn "ITIL in the Real World" Newsletter, we posted an article on "When Should I raise a Problem Record?". Due to the favorable response we received, I've posted the detail below:
Are there any specific guidelines about when one should raise a problem record? I've heard various arguments - purists say you should raise a problem record for every incident, and i've also heard "If it's likely to reoccur" and "if the incident(s) is/are causing impact".
As seems to be always the case with ITIL, there is no single answer to this that suits everyone. Beware of the
ITIL zealots who insist that all incidents must be linked to a problem record. If someone reports a fault with a 10 year old monitor, why do anything other than replace it? It is not worth investigating a root cause.
If, however, there were 10 such failures within a 2-week period, it might well be worth generating a problem record that would generate a scan of the CMDB to find out how many old monitors were still in use, with a view to proactively replacing them with new ones, before they fail.
Each organisation needs to define its own triggers for entering the Problem Management process. Some of these should be the same for all organisations while others will be different.
I would apply the following principles:
1. ALL major incidents should have problem records created. They need to have post mortem reviews and the business has every right to expect that the root cause has been investigated and appropriate corrective, preventive and/or mitigation action taken. Major incidents are any severity 1 and possible severity 2 incidents.
2. Where a number of apparently similar incidents have been detected and they have had a significant ulative impact, it is also a good indicator that root cause investigation is appropriate and a problem record can be established. This is a decision that needs to be agreed between Incident and Problem Management and could be done as part of a daily or weekly operations meeting.
3. Where ysis of incident data (trend, Pareto, etc) reveals a potential ‘hidden’ problem, it should be investigated.
4. Whenever a vendor notifies a service provider of a security flaw or other significant deficiency in a product (hardware or software) then it is a good idea to track the corrective/preventive action via a problem record.
5. Problems detected during testing that are not rectified at the time that a release is accepted into production.
6. When an audit or review highlights a deficiency or opportunity for improvement, this could also be tracked as a problem. Sources could be:
·Internal and external audit reports
·Post mortem and post-implementation reviews
·Process reviews (e.g. ysis of management information
·Service reviews with customers
·Customer satisfaction surveys
· Reports of ITSCM plan tests
7. Causes of common incidents and service requests – because known errors for these can serve as FAQs and self-help resources.
8. When a defined amount of support effort has been expended in incident investigation. One organisation told me that they had a rule that whenever two hours or longer had been spent investigating an incident, they created a problem record to doent details of the investigation and capture lessons learnt. This ensured that the same investigation did not need to be repeated if a similar incident occurred in the future.
I hope this helps! |
