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: RPantoja
New Today: 11
New Yesterday: 164
Overall: 131244

People Online:
Visitors: 42
Members: 2
Total: 44 .

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


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

etc...

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?

Thanks.
Back to top
View user's profile
Guerino1
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
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
dboylan
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,
Don
Back to top
View user's profile
dsemeniuk
Itiler


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.

Thanks.
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 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.