Changes to CMDB

[dsemeniuk]

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.

[Guerino1]

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

[dboylan]

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

[dsemeniuk]

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.