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


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ubyfevu
New Today: 31
New Yesterday: 34
Overall: 231603

People Online:
Visitors: 127
Members: 1
Total: 128 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

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.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - RfCs and Changes, can they be treated as CIs themselves?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

RfCs and Changes, can they be treated as CIs themselves?

Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message

Joined: Nov 09, 2007
Posts: 2

PostPosted: Fri Nov 09, 2007 9:16 pm    Post subject: RfCs and Changes, can they be treated as CIs themselves? Reply with quote

Hello to everyone,

my question addresses the tracking of RfCs and Changes as CIs. Being documentations of a process themselves, should they be included in the CMDB?

thank you for your input,
kind regards,
Felipe H.
Back to top
View user's profile

Joined: Sep 15, 2006
Posts: 22

PostPosted: Fri Nov 09, 2007 11:12 pm    Post subject: Reply with quote

Yes the RFC can become a CI when it's created. Then you can start tying everything together in the CMDB (the benefit of relationships). Depends on your needs though.
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Wed Nov 14, 2007 2:44 am    Post subject: Reply with quote

Hi Felipe,

My question to you is 'why'? Individual RFC's and Changes are records, not processes, that simply contain information about the state of your infrastucture at a given point in time. You can treat a process document for managing RFC's and Changes as a CI, however, individual instances of RFC's and Changes should not be regarded as such.

Think of it this way: would you ever need to create an Incident, Change, Problem or an RFC against another Change ticket (no CI in the Change ticket, but the ticket itself?)

Hope this helps,


Back to top
View user's profile
Senior Itiler

Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Thu Nov 15, 2007 1:54 am    Post subject: Reply with quote

You can understand "CI" at two different levels, both of which you can make a case for reading the ITIL books.

1: Anything you need to manage information on in the course of delivering service is a CI. In this view, yes, RFCs, incidents, etc would all be CIs. The processes themselves are CIs. The documents defining the processes are CIs. Of course the records of the flow of the process are CIs. Smile This gives pac666's answer.

2: Anything within the scope of Change control is a CI. This aligns with the concept of populating the CMDB and bringing those CIs under change control at the same time. In this view, obviously RFCs are CIs because then you would have the ridiculous situation of having to raise an RFC in order to raise an RFC. (NB In this view processes and process documents are still CIs - you definitely apply change control and version numbering to them.) This gives Timo's answer.

To quote Timo, "information about the state of your infrastructure at a given point in time" is exactly what Configuration Management is all about.

However, most CMDB tools are designed to deal with definition 2 - CIs are managed entities. If you try to force things into a particular CMDB that it wasn't designed for you are asking for trouble. And this is the difficulty with Config Mgt today: CMDB tools vendors don't explain their designs in terms a customer can align with other process needs, or don't make them open and flexible. (Not easily. Anything can be accomplished with programming, they'll tell you.)
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Nov 15, 2007 2:25 am    Post subject: Reply with quote


Some software vendors call the service management application the CMDB. So the perception is that everything in the CMDB are CI's becuase what makes up a CMDB ... CI's.

I would not say that an RFC is a CI. You relate the RFC to a CI being the component that you are raising the change request against.

Processes can be stored as documentation classified CI's and put under change control.

You would audit CI's differently to RFC's and incidents. CI' are audited to validate the data for that CI. RFC's are audited to validate that the process was followed and that the information provided in the RFC is in line with what is expected.
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile

Joined: Nov 09, 2007
Posts: 2

PostPosted: Mon Nov 19, 2007 10:45 pm    Post subject: great replies Reply with quote

Hello again,

excellent answers from all of you, thank you.

@Michael: Yes you are absolutely right, changing individual Change Tickets or RFCs through other RFCs does not make much sense, and is not necessary, as a Change Process should itself include provisions to find alternative answers to a change in requirements (starting a new RFC, or looping inside the same Change Process)...
so yes, Change Tickets thus fall out of scope of Change Control and therefore should not be handled as CIs.. Yay for avoiding Gödelian entanglements Smile

but changing the Change process (a CI as all of you pointed out) itself through a RFC is sensible.
I was searching for the connection between these two databases (change tracking DB and CMDB), and it is in essence through these change processes.

All your answers made this clear, thanks again.

Kind regards,
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change 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

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.