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.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Jun 21, 2007 1:05 am Post subject:
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.
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Sun Jul 01, 2007 2:00 pm Post subject: Re: Changes to CMDB
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?
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.
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