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?

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)

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.

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)

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.

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)