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: K7718
New Today: 48
New Yesterday: 68
Overall: 139806

People Online:
Visitors: 66
Members: 1
Total: 67 .

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 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
fhernand
Newbie
Newbie


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
pac666
Itiler


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
Timo
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,

Thanks,

Michael
Back to top
View user's profile
JoePearson
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
Mark-OLoughlin
Senior Itiler


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

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

Hi,

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
fhernand
Newbie
Newbie


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,
Felipe
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 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.