Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ElviaColan
New Today: 12
New Yesterday: 79
Overall: 149791

People Online:
Visitors: 65
Members: 3
Total: 68 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

RFCs raised by Problem Management

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
Ziad
Senior Itiler


Joined: Sep 27, 2006
Posts: 91

PostPosted: Mon Oct 02, 2006 4:03 am    Post subject: RFCs raised by Problem Management Reply with quote

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?

Thanks,
Z!
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Mon Oct 02, 2006 5:10 am    Post subject: Reply with quote

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
Back to top
View user's profile
Ziad
Senior Itiler


Joined: Sep 27, 2006
Posts: 91

PostPosted: Mon Oct 02, 2006 4:45 pm    Post subject: Reply with quote

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.

Thanks,
Z!
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Mon Oct 02, 2006 6:04 pm    Post subject: Reply with quote

no problem

as for the instructor and in here answers... yes i do understand your desire for detailed 'experience' based answers

please continue.

I did not mean to indicate that you should not ask in here..
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
winz
Itiler


Joined: Sep 27, 2006
Posts: 29

PostPosted: Mon Oct 30, 2006 8:23 pm    Post subject: Reply with quote

Hi Ziad,

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"
Back to top
View user's profile Send e-mail
DominguezS
Newbie
Newbie


Joined: Nov 07, 2006
Posts: 4

PostPosted: Tue Nov 07, 2006 9:59 pm    Post subject: Reply with quote

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?

Thanks!!!!!
Back to top
View user's profile
WendyB
Senior Itiler


Joined: Apr 03, 2006
Posts: 78

PostPosted: Tue Nov 07, 2006 11:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
DominguezS
Newbie
Newbie


Joined: Nov 07, 2006
Posts: 4

PostPosted: Wed Nov 08, 2006 1:23 am    Post subject: Reply with quote

Yes, but in that case it still rises an RFC.... then the RFC will not be approved during the Analysis phase because of the ROI ratio....

I mean, if there“s an example when a structural solution doen“t needs to rise an RFC....

Thanks anyway! Very Happy
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Wed Nov 08, 2006 4:34 am    Post subject: Reply with quote

DominiguezS

A problem record may never find a solution, therefore the problem record will stay forever

The problem & error control may never find a solution
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
DominguezS
Newbie
Newbie


Joined: Nov 07, 2006
Posts: 4

PostPosted: Wed Nov 08, 2006 8:26 pm    Post subject: Reply with quote

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)

Thanks again!
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Thu Nov 09, 2006 7:18 am    Post subject: Reply with quote

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
Back to top
View user's profile
vinicio
Newbie
Newbie


Joined: Feb 07, 2007
Posts: 2

PostPosted: Thu Feb 08, 2007 3:58 am    Post subject: Reply with quote

Quote:
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.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3320
Location: London, UK

PostPosted: Mon Feb 12, 2007 8:22 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.