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?
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?
Leave a Reply