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: VioletKa
New Today: 31
New Yesterday: 42
Overall: 231785

People Online:
Visitors: 141
Members: 1
Total: 142 .



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

Changes to CMDB

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

Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Jun 21, 2007 12:30 am    Post subject: Changes to CMDB Reply with quote

Topic: All changes to CIs must have an RFC is what we stated in our Configuration Management process.

But now there is some discussion on that statement may/should not hold true for some types of changes to the CI attributes within the CMDB

What do we do when:

1. When we order more licenses and need to update the Qty field

2. Need to make a change to the license description

3. Need to make a change to the software location


We are thinking these really don't need RFCs.

Thoughts on how to handle updates to the CIs in the CMDB on information like this?

Back to top
View user's profile
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Jun 21, 2007 1:05 am    Post subject: Reply with quote

Hello dsemeniuk,

Too many people get caught up in the letter of ITIL, as opposed to the spirit of ITIL. ITIL is meant to be a set of best practices and guidelines. The spirit is about things like "Running IT like a business", "Transparency", and "Accountability".

Using an RFC to track every possible change that an enterprise makes will not scale. However, the key is to understand and track the critical work involved in performing changes, only for the work that's critical enough for you to want to formally track. It doesn't even have to be through an RFC.

For example, capturing a "Requirement" or a "Defect" are both forms of implicit Requests for Changes. Why would I capture a Requirement if I didn't want to implement it? Why would I capture a Defect if I didn't want to fix it? These things (Requirements & Defects) can now be the drivers for Change. It doesn't "explicitly" have to be an RFC. Requirements & Defects, for example, are "implicit" RFCs. So, you've got to temper your ITIL implementation with a great deal of common sense, otherwise you'll be spending mroe time filling in RFC tickets than actually doing work.

In the example(s) you give, it's adequate to track who changed the data, when they changed, why they changed it, and what was changed. If you have this, it may be more than adequate for your enterprise.

You have to ask yourself, "When is enough enough?" People modify operational data in spreadsheets, all day every day. Do we ask for an RFC before they can modify a single cell in the spreadsheet? Of course not. It would be ridiculous to do so, yet many spreadsheets are definitely CIs. Therefore, the best we can do is draw lines that simply define what "good enough" is for our own enterprises.

I hope this helps.

My Best,

Frank Guerino, CEO
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Senior Itiler

Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sun Jul 01, 2007 2:00 pm    Post subject: Re: Changes to CMDB Reply with quote

I am assuming that you are tracking all these as attributes of your CI's. In which case, yes, you should have RFCs to record any changes to these attributes.

My question would be - Why would you not want these as RFCs?

If it is because your Change Management process has too much overhead, then you should consider reviewing the process. A mature Change Management process should have very little overhead.

In the way I envision a mature Change Management process, a Standard Change involves logging into the application, selecting a drop down menu and typing less than 10 words. Everything else should be captured auto-magically by the tool.

And in a mature Change Management process, the way the Changes break down should be according to the 80/20 rule -

80% of all Changes should be Standard Changes.
Of the remaining 20%, 80% of them should be Minor Changes.
The remaining Changes are Significant Changes.

If you follow this KPI for 100 random RFCs, it should break down like this:

80 are Standard Changes - pre-approved
16 are Minor Changes - approved after review by the Change Manager
4 are Significant Changes - require review by the CAB

So out of 100 RFCs only 4 make it to the CAB with their (understandable) overhead for approval.

The key here is that the Change process is the process that drives the updates to the CMDB. If you are bypassing the Change process, how is the Configuration process going to know to update the attributes of a CI?

I hope this helps,
Back to top
View user's profile

Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Jul 05, 2007 12:50 am    Post subject: Reply with quote

Thanks Don.

That all makes sense and I like it.

Can you provide a list of pre-approved (standard) changes that you have defined and use for your process?

I am starting to put together a document that will define our standard changes and get them implemented into our tool so they can be selected by the requestors when doing these types of changes and are automatically "mostly" filled out with the standard information based on the type of change they are doing and all they have to do is let us know (change management) when they will be doing the change and when it actually got completed (and of course the CIs that changed) so we have it all on record.

I can see this list becoming very big and just curious to see what other people have defined as standard changes.

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