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 - RFCs raised by Problem Management
Posted: Mon Oct 02, 2006 4:03 am Post subject: RFCs raised by Problem Management
Dear All,
In many charts showing the flow of problem management activities, and more precisely in the Error Control phase; they draw an arrow coming out of the "Record Error Resolution" activity labeled with "Raise an RFC", this arrow passes by the Post Implementation Review activity and ends at the closure phase.
I cannot understand why the RFC should be raised at the "Record Error Resolution" activity and not at the "Error Assessment" activity, the later makes more sense to me. Can you please elaborate by giving me your inputs and thoughts about that particular subject?
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Mon Oct 02, 2006 5:10 am Post subject:
Zaid,
Because until there is a resolution to the error, there can be no way to come up with a way to get rid of the error
For example, there has been a serious of BSD (Blue Screen of Death) happening to a bunch of PCs in the Graphics department. The Incident Team selects the Incidents for review by the PM team to determine whether a Problem record should be created.
The PM team decides that these incidents meet the criteria for a problem records..yadda yadda to the error control section...
The error is Assessed and it is determined that a RFC needs to be raised to do something which should fix the error.
The Assessment determines what needs to be done and the Record Error Resolution merely carries out the action.
Is that clear ? Also, these are questions you should be asking your instructor _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Clear enough, I am really sorry if the questions I am asking are causing any inconvenience. Indeed I can simply go ahead and send them to the instructor from whom I will get a single answer tailored in one way.
I was just trying to get the views of people with experience on the subject in their own particular explanation.
Below is my understanding of the Problem Management workflow. Hope it helps....
The two major phases of Problem management are:
1) Problem Control
The following steps are involved in this stage -
(a) Investigation & Diagnosis
(b) give the problem the tag as "error"
2) Error control
The following steps are involved in this stage -
(a) RCA
(b) Getting a permanent solution
(c) Change required ? - If yes then raise a RFC (follow the change management process) else update KEDB and close the problem ticket
(d) Giving the "error" the tag as "known error"
(e) Updating the KEDB
(f) Confirm & Close the problem ticket.
Just my 2 cents in here....
Cheerz
winz _________________ "Look at Frustration as a positive thing. It is the frustration that drives you to improve"
Hi!
I“m working right now on the implementation of a custom ITIL tool based on BMC Remedy. One of the question we had designing the tool was if ALL Problem Records should have an associated RFC, to be able to change it state to Closed.....
I mean, all problems closed with a structural solution should shoot an RFC ??(either it be a change model or a new one)
Well, if not, could u give an example of when it should not trigger an RFC?
One we have right now, is if the Change will cost too much money, and there is no way that Governance will approve it. I.e, it costs less to live with the problem (and use workarounds) than to fix problem.
Thanks Unviking, I see that. But , in the case that a solution was found, it always rises an RFC?? Or you may find a structural solution that may be applied without issuing an RFC (in that case, an example please)
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Thu Nov 09, 2006 7:18 am Post subject:
It is UKVIKING (John Hardesty) and yes.. if there is a solution to a problem record and it requires a configuration change, then yes, A Request for Change would be necessary.
However, if the solution does not involve a change to a configuration item, then it does not.
A CI can be a device, process, document etc _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I mean, all problems closed with a structural solution should shoot an RFC ??(either it be a change model or a new one)
Hmm, TBPS (The best practice says),
"The rectification of many hardware faults is carried out under incident control, and not via error control and Change Management. Any Changes to the specification of hardware should, however, be subject to the normal Change Management procedures" (chp 6.7.6, service support)
This opens the possibility that "structural" solutions are giving without opening a RFC, but ONLY after the Known Error has been identified. It seems that the RFC should be raised just when necessary; it appears PM should investigate if the solution changes a CI from one defined state to another, then it is a change, a RFC should be raised, otherwise don't.
I don't think ITIL idea was to create the PM process to enforce raising RFCs for every known error. Of course "structural" solutions (that embraces a change) can only be handled by CM in coordination with PM. But solutions can arise without RFCs.
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Mon Feb 12, 2007 8:22 pm Post subject:
Vincio
True. It depends on what the resolution is against what the solution is.
In my book, resolution is finding the root cause and getting rid of it permanently and solution means getting the thing to work again
If the resolution requires something to be added, changed, or deleted from the CMDB, then there has to be a change request
If the resolution does not require something in the CMDB to be added, changed or deleted, then no change is needed.
If the solution does not require something in the CMDB to be added, changed or deleted, then no change is needed.
If the solution does require something in the CMDB to be added, changed or deleted, then change is needed.
The issue is that most solutions can be done at the incident level - ie restore service - while the resolution is done at the problem level.
Rebooting a trouble server is a solution to the immediate issue but is not really a resolution to the underlying recurring issue.
However, somethimes the reboot solution is the only real recourse.
I know of a few servers which were rebooted on a periodic scheduled basis rather purchase more memory or upgrade CPU or hard drive - mostly because the kit is so old there are no parts and the ££££ to get a new one aint in the cards. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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
