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: KLangan
New Today: 60
New Yesterday: 49
Overall: 148404

People Online:
Visitors: 49
Members: 1
Total: 50 .

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 - Where does an RFC come from and go.
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Where does an RFC come from and go.

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
Flipper
Newbie
Newbie


Joined: Jun 14, 2005
Posts: 1

PostPosted: Wed Jun 15, 2005 6:50 am    Post subject: Where does an RFC come from and go. Reply with quote

We are having a disagreement concerning which process provides initial input to whom between Change Management and Release Management. From a Release Management perspective I say that we receive an RFC from Change Management as input and that starts our process. Change Management disagrees stating that the RFC comes from somewhere else to Release Management and Release Management submits a RFC to Change Management. Who is right?
Back to top
View user's profile
mrcasal
Newbie
Newbie


Joined: Apr 05, 2005
Posts: 17

PostPosted: Wed Jun 15, 2005 7:04 am    Post subject: Reply with quote

well, I think that RFC came from:

a/customer. He ask for some change in the infrastructure, in order to improve the business indicators.

b/problem management. Once you've identified and fixed a problem, you have you have to use a RFC, in order to solve the problem into the live enviroment.

RFC must be managed with change management process, once the RFC get the CAB approval, the release management have to deal with the RFC, overall in order to update the CMDB.
Back to top
View user's profile
blackbeard
Newbie
Newbie


Joined: Jan 07, 2005
Posts: 11

PostPosted: Fri Jun 17, 2005 7:12 pm    Post subject: Reply with quote

RFC's should be able to come from anywhere in the business, they would then go to the change manager for reviewing, filtering, prioritising and submission to the CAB. Only once the CAB have given approval would they then go to Release Management or out to a Project Team to move on to the Test and Build phases.
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Jun 19, 2005 3:23 am    Post subject: Reply with quote

It helps to think of an RFC as something that has varying levels of definition and clarity at its inception, depending on where it is raised.

As an output of Problem Management and RFC will be quite well defined, it will specify a change that has been identified as a solution to an error or other type of problem. An RFC may also be a request for new features, tachnolgies or processes coming from and end user or customer. At the point it is raised it would likely be unsuitable for direct input into the Change Management process - it may need to be coordinated with the development cycle of an application, or assessed against the budget, and the current IT plan. A service level management team would work with key technical staff to scope, and cost the change in negotiation with the customer.

Once it has been 'firmed' up it would go to a CAB for approval.

Of course some 'RFC' are trivial in that they are really Service Requests, or a like for like - ie replacing a failed CI with exatly the same - these are usually 'pre-approved' and implemented immediately - though it is critiacl that Change Management tracks them and ensures that Configuration Management process record the activity.

So change management identifies, defines, assesses and approves changes. That means in practical terms it identifies, defines, assesses and approves RFC - it doesn't 'change' anything. That's an 'operational' activity.

But there are usually a lot of related changes going on all the time - some based on RFC, but many based on project to continually develop the infrastructure, as well as application development for major services.

These changes have to be continually managed in a continual deployment cycle where the disruptions, dependencies, impacts, resource allocations etc are efficiently balanced - enter release management, which plans and coordinates the deployment of changes as a cycle of releases, which will include the testing, accpetance, rollback, etc plans and activities.

So release management doesn't take RFCs per-se as it's inputs - by the time they get to Release management they should really be called just 'changes' or perhaps 'approved' or 'planned' changes.

Depending on how the realtionship between production and development is set up, release management would be accepting 'changes' from the development cycle - but these would have had CAB involvment anyway, so would still be going from change to release management.

It is however a little counter-intuitive that 'change management' doesn't actually 'change' things Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Mon Jul 18, 2005 9:04 am    Post subject: Reply with quote

Ok... my two cents worth...

For Release scheduling and implementation, the only input into and out of Release Management is Change Management, in the form of approved RFC's.
Back to top
View user's profile Visit poster's website
Ian
Newbie
Newbie


Joined: Jul 26, 2005
Posts: 1
Location: Nottingham (UK)

PostPosted: Wed Jul 27, 2005 12:35 am    Post subject: Re: Where does an RFC come from and go. Reply with quote

Flipper wrote:
We are having a disagreement concerning which process provides initial input to whom between Change Management and Release Management. From a Release Management perspective I say that we receive an RFC from Change Management as input and that starts our process. Change Management disagrees stating that the RFC comes from somewhere else to Release Management and Release Management submits a RFC to Change Management. Who is right?


Flipper,

An RFC is raised in a number of ways :

Normally by a Customer within the business in response to business change or as a result of the activities of other ITIL management processes e.g.
in response to an incident or problem
as a result of capacity management activities etc etc.

I have a diagram of the change management process which may assist your understanding. If you would like a copy please e-mail me.

Ian McLeod (Manager's certificate, BS15000 Auditor/Consultant certificate)
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.